پروژهٔ نرم‌افزاری چقدر از وقت ما را می‌گیرد؟
مدیر عملیات هستید و مدیرعامل گفته شرکتی را پیدا کنید که سامانهٔ انبار را بسازد. پیمانکار با اطمینان گفته: «شما کاری ندارید، فقط نظر بدهید.»
دو ماه بعد، هفته‌ای چند ساعت از وقتتان صرف جلسه، تست، جواب دادن به پرسش‌هایی شده که فقط شما می‌دانید، و پیدا کردن کسی که اجازهٔ تصمیم دارد. کار روزانه‌تان هنوز سر جایش است.
این مقاله دربارهٔ آن بخش کار است که هیچ‌وقت در پیشنهاد نیامد: وقت شما. عدد نمی‌دهیم: ساعت‌ها به اندازهٔ پروژه، سازمان و آدم‌ها فرق می‌کند، و عددی که از جایی به جای دیگر برود گمراه‌کننده است. چیزی که می‌دهیم شکل آن است: چه کسی، در کدام مرحله، چقدر بیشتر یا کمتر.
اینکه کارفرما چه باید تحویل بدهد، یعنی داده و دسترسی و آدم تصمیم‌گیر، در مقالهٔ دیگری آمده. این‌جا از زمان می‌گوییم.
چهار نقش، نه یکی
پروژه با «کارفرما» پیش نمی‌رود؛ با چند آدم مشخص:
تصمیم‌گیر. کسی که می‌تواند بگوید «بله، این را بسازید» یا «نه، حذفش کنید» و تصمیمش پس گرفته نمی‌شود. اغلب مدیرعامل یا مدیری که بودجه دارد.
صاحب فرایند. کسی که می‌داند کار الان چطور انجام می‌شود، با همهٔ استثناها. نه لزوماً مدیر؛ اغلب کسی در میانهٔ سازمان که سال‌ها همین کار را کرده.
کاربران نماینده. چند نفر از آدم‌هایی که واقعاً با سامانه کار می‌کنند. نه همه؛ نماینده.
رابط فنی. کسی که دسترسی‌ها، شبکه، سرور و سامانه‌های موجود را می‌شناسد. در شرکت‌های کوچک ممکن است همان «کسی که کامپیوترها را درست می‌کند» باشد.
اگر این نقش‌ها روی یک نفر جمع شده‌اند، آن یک نفر باید بداند که چند شغل دارد.
هر مرحله چه کسی را می‌خواهد
این جدول شکل کلی است، نه عدد. «زیاد» یعنی در آن مرحله، این نقش باید جدی در دسترس باشد.
| مرحله | تصمیم‌گیر | صاحب فرایند | کاربران | رابط فنی |
|---|---|---|---|---|
| شناخت نیاز | متوسط | زیاد | متوسط | کم |
| طراحی | متوسط | زیاد | متوسط | کم |
| ساخت | کم، ولی سریع | متوسط، پاسخ به پرسش | کم | متوسط |
| آزمون و پذیرش | متوسط | زیاد | زیاد | متوسط |
| راه‌اندازی و آموزش | زیاد | زیاد | زیاد | زیاد |
| پس از راه‌اندازی | کم | متوسط | متوسط | متوسط |
دو چیز در این جدول بیشتر از بقیه غافلگیر می‌کند.
مرحلهٔ ساخت سبک به نظر می‌رسد و سبک نیست. وقت زیادی نمی‌خواهد، ولی پاسخ سریع می‌خواهد. «این فیلد اجباری است یا نه؟» یک جملهٔ دو ثانیه‌ای است. اگر دو روز طول بکشد تا جواب برسد، آن برنامه‌نویس به کار دیگری رفته و بازگشتش خودش هزینه دارد.
پذیرش پرکارترین بخش کاربران است. سامانه‌ای که در جلسهٔ نمایش خوب بود، با داده‌ٔ واقعی و دست‌های واقعی چیزهایی نشان می‌دهد که کسی ندیده بود. این تست را فقط خود کاربران می‌توانند انجام دهند و باید در برنامهٔ کاری‌شان جا باز شود، نه در حاشیه‌اش.
چهار چیزی که پروژه را از سمت ما کند می‌کند
این فهرست را برای کارفرما نوشته‌ایم، چون از طرف پیمانکار گفتنش آسان است و شنیدنش سخت.
تصمیم دیر. «باید با مدیرعامل صحبت کنم» هفتهٔ بعد. اگر تصمیم‌گیر در جلسه نیست، پیمانکار یا منتظر می‌ماند یا حدس می‌زند، و حدس غلط بعداً بازسازی می‌خواهد.
چند تصمیم‌گیر. وقتی سه نفر هر کدام حق وتو دارند و باهم هماهنگ نیستند، هر تغییر از یکی، تغییر برای بقیه می‌شود (تغییر دامنهٔ پروژه). یک نفر را مسئول کنید و اختیارش را به پیمانکار اعلام کنید.
تغییر نظر بدون قیمت. تغییر خودش بد نیست؛ بی‌اعلام بودن و بی‌هزینه فرض شدنش مشکل است. هر تغییر یک جمله دارد: چه چیزی عوض شد، و چه چیزی را به تأخیر می‌اندازد.
در دسترس نبودن در لحظه‌های مهم. هفتهٔ پذیرش، مدیرانی که نمایش را تأیید کرده‌اند مسافرت‌اند، یا کاربران در اوج فصل کاری. تقویم کار خودتان را در همان آغاز نشان بدهید.
کارهایی که از شما برمی‌آید
- یک نفر را مسئول بنامید که اختیار تصمیم‌های روزمره را دارد و می‌داند چه چیزی باید بالا برود.
- یک جلسهٔ ثابت و کوتاه هفتگی بگذارید. نه برای گزارش‌دهی؛ برای اینکه پرسش‌های باز بسته شود.
- قاعدهٔ پاسخ بگذارید: پرسش‌های ساده در همان روز کاری جواب می‌گیرند، و پرسش‌هایی که نیاز به تصمیم دارند تاریخ مشخص.
- تقویم پذیرش را همان اول بنویسید: کدام هفته‌ها کاربران آزادند و کدام هفته‌ها نه.
- از پیمانکار بخواهید که هر هفته بنویسد چه چیزی از شما منتظر است. اگر چیزی نمی‌نویسد، یا منتظر چیزی نیست یا گزارش نمی‌دهد؛ هر دو را باید بدانید.
سؤالی که در جلسهٔ اول بپرسید
از هر پیمانکاری بپرسید: «در هر مرحله، دقیقاً چه کسی از طرف ما، به چه مدت، چه می‌خواهید؟» اگر جواب «خیلی چیزی نمی‌خواهیم» بود، یا پروژه‌ای بسیار کوچک است یا این پرسش را هنوز جدی نگرفته‌اند. برآورد زمان بدون جواب این پرسش، نصف قصه است.
و اگر خودتان کارفرمایید، این برگ را پیش از امضا پر کنید: نقش‌ها، نام‌ها، تقویم. اگر نتوانستید، پروژه آمادهٔ شروع نیست؛ این را بهتر است همان روز بدانید تا ماه سوم.
تاریخ‌های مشخص را عمداً ننوشته‌ایم؛ هیچ مقاله‌ای نمی‌تواند برای پروژهٔ شما تاریخ بدهد. چیزی که می‌شود نوشت، سهم شماست از آن.