۱۰ قانون مدیریت پروژهٔ نرمافزاری که واقعاً به کار میان
خلاصهٔ کاملتر
این مقاله ۱۰ قانون عملی برای مدیریت پروژهٔ نرمافزاری رو جمع کرده که همهشون حول یه هستهٔ مشترک میچرخن: اسپکِ اولیه فقط یه حدسه دربارهٔ چیزیه که مشکل رو حل میکنه، و تقریباً همیشه غلطه. به گفتهٔ نویسنده، یه پروژه وقتی موفقه که مشکل رو حل کنه، نه وقتی مو به مو با اسپک اولیه بخونه؛ پس مهمترین کار اینه که تیم قبل از شروع، خودِ مشکل رو بفهمه تا بتونه با کشف اطلاعات جدید راهحل رو عوض کنه.
قانون دوم و سوم دربارهٔ scope و تاریخان. نویسنده معتقده scope رو نمیشه قبل از شروع کار دونست، فقط میشه بهمرور «کمتر غلط» کردش؛ چون درست اول کار کمترین اطلاعات رو داری. نتیجهٔ منطقیش اینه که نمیتونی همزمان تاریخ و scope رو ثابت نگه داری: اگه تاریخ ثابته، scope باید انعطافپذیر باشه و بتونی کار رو کم کنی؛ اگه scope ثابته (مثل یه الزام قانونی)، تاریخ باید شناور باشه. اگه رو هر دوتاش پافشاری کنی، تنها متغیری که برای معامله میمونه کیفیته.
قانون چهارم یکی از مهمترینهاست: محصول رو به شکل نسخههای کارآمدِ پشتسرهم بساز، نه چند تکهٔ موازی که آخر کار به هم وصل بشن. اولین نسخه باید کوچیکترین چیزی باشه که از اول تا آخر کار کنه، حتی اگه بعضی قدمها هنوز دستی باشن. مثالش سیستمِ وارد کردن مخاطب از فایل CSV هست: نسخهٔ اول میتونه فقط یه consumer باشه که یه فایلِ دستیآپلودشده رو تو S3 پردازش میکنه، بدون API یا داشبورد، ولی همون الان کار میکنه. جملهای که نویسنده روش تأکید میکنه: همیشه میتونی یه محصولِ کوچیکِ کارکننده رو منتشر کنی، ولی یه محصولِ کارنکن رو هرچقدر هم enterprise به نظر برسه نمیتونی.
قانون پنجم و ششم نگاه رو از مهندسی به کل کسبوکار باز میکنن. یه تصمیم مهندسی که برای مهندسی جواب میده ولی فروش، بازاریابی، قیمتگذاری، پشتیبانی یا عملیات رو خراب میکنه، تصمیم مهندسیِ خوبی نیست. همینطور، قابلیت بهرهبرداری (operability) چیزی نیست که بعد از پروژه بیاد؛ خودش یکی از خروجیهای پروژهست. تیم باید بتونه بفهمه محصول کار میکنه یا نه، دلیل خرابی رو بفهمه و بدون ریسک اضافه تغییر بده؛ یعنی مانیتورینگ، هشدار، مستندات و راهی برای برگردوندن یه دیپلویِ بد باید بخشی از کار باشن.
چند قانون آخر دربارهٔ اولویتبندی و شفافیتن. نویسنده میگه اهمیت یه فرض به هزینهٔ غلط بودنشه، نه به راحتیِ اثبات درست بودنش، پس ریسکیترین فرضها رو باید اول تست کرد. backlog هم نباید نقشههای قدیمی رو نگه داره، چون در واقع داره «نادانیِ زمان نوشتن نقشه» رو حفظ میکنه؛ بهتره کوچیک بمونه و taskها نزدیک به زمان انجامشون نوشته بشن. اگه وضعیت پروژه فقط تو ذهن آدمها باشه، هر کسی یه نسخهٔ متفاوت از پروژه رو تو سرش داره، پس باید یه جای واحد (مثلاً یه board) باشه که همه وضعیت فعلی رو یکجور ببینن.
قانون دهم همهچیز رو جمع میکنه: پروژهای که مشکل رو زود حل کنه فقط میتونه بهتر بشه، و پروژهای که راهحل رو برای آخر نگه داره فقط میتونه دیر بشه. امنترین راه برای رسیدن به ددلاین اینه که مشکل رو قبل از رسیدنِ ددلاین حل کنی؛ اونوقت بقیهٔ زمان میشه فرصتِ بهترکردن محصول، نه زمانی که بقای پروژه بهش وابستهست.
نکات کلیدی:
- موفقیت یعنی حل مشکل، نه تطابق با اسپک اولیه که تقریباً همیشه غلطه
- نمیشه همزمان تاریخ و scope رو ثابت نگه داشت؛ وگرنه کیفیت قربانی میشه
- محصول رو به شکل نسخههای کارآمدِ پشتسرهم بساز، نه تکههای موازی
- قابلیت بهرهبرداری و تصمیمهای سازگار با فروش و پشتیبانی، بخشی از خودِ پروژهان
- ریسکیترین فرضها رو زود تست کن و وضعیت پروژه رو تو یه جای واحد و شفاف نگه دار
