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