به‌صورت کلی در کارهایی که جنبه‌ی تحویل‌دادنی، اونم توی کوتاه‌مدت به کارفرما رو دارند، معمولا درخواست تغییرات زیاده. مثلا طراحی رابط‌کاربری یک وب‌سایت. اگه شغل‌تون این باشه، یا خودتون به عنوان کارفرما سفارش طراحی یک وب‌سایت رو داده باشید، احتمالا جمله‌ی «می‌شه لوگوش رو یکم بزرگ‌تر کنی؟» باید به گوش‌تون آشنا بیاد. این مورد نسبت به موارد دیگه خیلی توچشم‌تره! واقعا من نمی‌دونم مگه واتس رانگ ویت د لوگو؟:دی

حرفی که بنده با کارفرمایان عزیز دارم، اینه که در نظر داشته باشید به احتمال زیاد اون طراح با توجه به یک سری پارامتر، به این نتیجه رسیده که سایز لوگو باید اون مقدار باشه. لذا لیو د لوگو اِلون. و حرفی که با طراحان دارم اینه که قبل از اینکه کنترل خودتون رو از دست بدین و لوگو رو با همون فرمت PNG توی چشم کارفرما بکنید، این نکته یادتون بیاد که کارفرما احتمالا تخصصی توی طراحی و اصول اون نداره؛ همون‌طور که احتمالا شما سر از تخصص و شغل اون در نمیارید. خب پس چه کنیم؟ یه لحظه صبر کنید من یک لیوان آب بخورم.

خب داشتم می‌گفتم. راستش دوتا راه‌حل  خیلی منطقی و کارآمد برای این مشکل وجود داره: نیازسنجی اولیه‌ی کامل و گذاشتن محدودیت برای پذیرفتن درخواست تغییرات. بریم که ریز بشیم توش.

به دو دلیل دارین این عکس رو می‌بینید. یکی اینکه یه استراحتی به چشماتون بدین، یکیم این که کم‌کم داریم می‌رسیم به این روزها.

جنگ اول، به از صلح آخر: نیازسنجی دقیق و کامل

توی مهندسی نرم‌افزار یک مبحث خیلی مهم داریم به‌اسم مهندسی نیازمندی‌ها. این مبحث انقدر مهمه که، معمولا نیازسنجی ناقص مهم‌ترین فاکتوریه که توی شکست خوردن یک پروژه نرم‌افزاری نقش داره. همون‌طور که از اسمش مشخصه توی این مرحله از توسعه‌ی نرم‌افزار مشخص می‌شه ما از سیستم چی می‌خوایم؟ قراره چه قابلیت‌هایی داشته باشه؟ خب مشخصه که هرچی نیازسنجی ما دقیق‌تر و کامل‌تر باشه، به سیستمی که مورد انتظارمون بوده نزدیک‌تر می‌شیم.

وقتی کلمه‌ی نیازسنجی رو می‌شنویم، شاید اینجوری فکر کنیم که این وظیفه به‌عهده‌ی کارفرماست. یعنی این خود کارفرماست که باید به ما بگه چی می‌خواد. خب این تفکر خیلی بی‌راه نیست، منتها نکته‌ای که باید در نظر بگیریم اینه که بیش‌تر وقت‌ها مشتری یا کارفرما نمی‌دونه که چی می‌خواد، یا حداقل به‌طور دقیق نمی‌دونه چی می‌خواد. یادمون نره که این یک مورد کاملا طبیعیه و با راه‌حل‌های مخصوص به خودش باید حل‌اش کرد.

چیزی در دنیا نیست که بی‌نهایت باشد: اعمال محدودیت برای درخواست تغییرات

یه جمله هست از «توماس ساول»، اقتصاددان آمریکایی، که می‌گه:

[qut]درس اول اقتصاد کمیابی است: چیزی در جهان نمی‌توان یافت که فراوان باشد و نیاز همگان را برآورده کند.[/qut]

از اون‌جایی که توی پروژه‌های نرم‌افزاری، کار ما تازه بعد از تحویل پروژه است که شروع می‌شه؛ یکی از حیاتی‌ترین کارهایی که باید انجام بدیم، اینه که در مورد محدودیت‌های این‌چنینی با کارفرما صحبت کنیم. این مورد، معمولا توی قرداد با مشخص کردن مدت پشتیبانی پوشش داده می‌شه.

باز هم می‌خوام از جنبه‌ی خوب قضیه نگاه کنم و بگم که مشتری حق داره هی درخواست تغییرات داشته باشه؛ اگر ما از قبل این رو مشخص نکرده باشیم. کلا ما انسان‌ها دوست داریم همه‌چیز همیشه باشه، حالا می‌خواد هرچی باشه. اما وقتی کارفرما در جریان محدودیت‌ها باشه، دیگه همچین اتفاقی نمی‌افته. مثلا محدودیت در تعداد دفعاتی کی می‌شه درخواست تغییرات داشت. یا مثلا محدودیت در نوع تغییرات درخواستی.

امیدوارم از پست استفاده کرده باشید.