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