“make it warmer” یکی از تکنیک های طراحی و ساخت نرم افزار است که در آن به بررسی زبان طراحی سیستم
می پردازد.
به بیانی ساده تر، یعنی باید زبان یک سیستم اداری ( یا هر سیستمی که می خواهید کارهای آن را نرم افزاری کنید ) ، بلد باشید. این تکنیک هم یکی از تکنیک های فاز نیازسنجی نرم افزار یا Software Requirement است.
دوست داشتم که به شیوه خودم آن را بیان کنم. اما کمی که فکر کردم دیدم در یکی از کتاب هایم این تیکنیک به صورت یک داستان آمده است.
کتاب user story applied نوشته Mike Cohn یکی از بهترین کتاب های موجود در بازار برای ساخت نرم افزار است. در این کتاب تکنیک ها و روش هایی بسط و شرح داده شده است که در آن به چگونگی فهم بهتر زبان یک کاربر نابرنامه ساز پرداخته شده است.
اگر بخواهم که کتاب را در یک جمله توصیف کنم ، این عبارت را که برگرفته از خود کتاب است ، استفاده می کنم.
Software requirements is a communication problem
بگذارید داستانی را که گفته بودم برایتان بنویسم.
این داستان از زبان خود Mike Cohn در همین کتابی که معرفی کردم ، نوشته شده است.
I remember many years ago being told a story about a child at bath time. The child’s father has filled the bath tub and is helping his child into the water. The young child, probably two or three years old, dips a toe in the water, quickly removes it, and tells her father “make it warmer.” The father puts his hand into the water and is surprised to find that, rather than too cold, the water is already warmer than what his daughter is used to.
After thinking about his child’s request for a moment, the father realizes they are miscommunicating and are using the same words to mean different things. The child’s request to “make it warmer” is interpreted by any adult to be the same as “increase the temperature.” To the child, however, “make it warmer”
meant “make it closer to the temperature I call warm.”
در ادامه هم برای اینکه کمی مطلب اختصاصی تر شود این گونه توضیح میدهد که :
Software requirements is a communication problem. Those who want the new software (either to use or to sell) must communicate with those who will build the new software. To succeed, a project relies on information from the heads ofvery different people: on one side are customers and users and sometimes analysts, domain experts and others who view the software from a business or organizational perspective; on the other side is the technical team.
If either side dominates these communications, the project loses. When the business side dominates, it mandates functionality and dates with little concern that the developers can meet both objectives, or whether the developers understand
exactly what is needed.
When the developers dominate the communications, technical jargon replaces the language of the business and the developers
lose the opportunity to learn what is needed by listening. What we need is a way to work together so that neither side dominates and
so that the emotionally-fraught and political issue of resource allocation becomes a shared problem. Projects fail when the problem of resource allocation falls entirely on one side.
