بایدهای مدیریت پروژه: سادگی را بر پیچیدگی ترجیح دهید!
من میگم توی دکمههای مایکروویو یک دکمه اهمیت داره: “افزودن یک دقیقه“
برای جوشاندن یک فنجان آب برای قهوه، سه بار فشارش میدم. برای ذوب کردن پنیر یک بار. برای گرم کردن نان، یک بار دکمه “افزودن یک دقیقه” رو فشار میدم و بعدش کافیه درب ماکروویو را پس از 15 ثانیه باز کنم.
شاید به نظر برسه که “مایکروویو یک دکمهای” جایی در ذهن کمیتهی طرحریزی نداشته باشه اما نظر من متفاوته. میتونم از امکانات مایکروویوم که هرگز استفاده نشده این نتیجه رو بگیرم که کمیتهی طرحریزی، پیچیدگی را بر سادگی ترجیح داده. البته ممکنه اونها “پیچیدگی” رو با مفهوم”پر از ویژگیها” جایگزین و یا پوشش بدن.
هرگز هیچ فردی با هدف ساخت محصولی پیچیده شروع به کار نمیکنه. پیچیدگی به طور تصادفی به وجود میاد.
فرض کن من یک تکه پیتزای سرد دارم که میخوام گرمش کنم. براساس دستورالعمل سازنده، باید دکمه “منو” را فشار بدم. حالا گزینههای “پخت سریع” یا “گرم کردن مجدد” رو میبینم (وای! خیلی گرسنمه، نمیدونم گزینه “پخت سریع”، سریعتره یا گزینه “گرم کردن مجدد”؟)
تازه! مرحله بعد سوال و جواب با مایکروویو ادامه داره! انتخاب از بین گزینههای “نوشیدنی”، “پاستا”، “پیتزا”، “بشقاب غذا”، “سس” یا “سوپ” هستش. (“پیتزا” را انتخاب میکنم، هرچند داخل بشقابه و روی اون سس ریختم!)
تازه حالا باید یکی از گزینههای”1 برش”، “2 برش”، “3 برش”، یا “4 برش” را انتخاب کنم! نمیدونم این بازجویی چقدر طول میکشه! اینجاست که دیگه بیخالش میشم و دکمه کنسل رو میزنم و میرم سراغ همون دکمه “افزودن یک دقیقه”. خلاص.
خب این موضوعات چه ارتباطی به ساخت و توسعه نرمافزار داره؟!
تا جایی که به من مربوط میشه، وبسایت آمازون فقط یک دکمه داره: “خرید با یک کلیک”. البته که در خرید اول از این وبسایت باید آدرس و شماره کارت اعتباری خودم را وارد میکردم، اما الان به اندازه یک کلیک با خرید فوری فاصله دارم! مگه نه؟!
نرمافزارها به طور کلی مشکلات پیچیده را حل میکنند. سوال اینه که چه میزان از این پیچیدگی رو به کاربر نهایی تحمیل میکنی؟ آیا نرمافزارت پیچیدگی رو بیشتر میکنه؟ نرمافزار عالی عموما پیچیدگیهایی داره. شما به عنوان یک مدیر پروژه نرمافزاری، پیچیدگی را کاهش میدید یا افزایش؟
بهترین مدیر پروژه، پیچیدگی را برای همه طرفهای ذینفع (برنامه نویسان، کاربران نهایی، مدیران) حذف میکنه و هیچ وقت پیچیدگی رو افزایش نمیده.
🚦 از آنجایی که کاربران نهایی نیازهای به ظاهر متناقضی ایجاد میکنند، وظیفهتون کمک به رفع آنهاست و نه این که این نیازها رو کورکورانه به توسعه دهندگان انتقال بدید.
🚦 از آنجایی که سازندگان نرم افزار، دلایل فنی مبهمی را برای ناتوانی در انجام یک الزام بیان میکنند، وظیفه شما اینه که پیچیدگی رو کم کنید و اطلاعات کافی به کاربران نهایی ارایه بدید تا به آنها در انتخاب مسیر متفاوت کمک کنید.
راستی!
📍 استفاده از اپلیکیشن مدنظر شما چقدر ساده است؟
📍 چقدر آسونه که یک ویژگی جدید به برنامه خودت اضافه کنی؟
📍 درخواست یک ویژگی جدید چه میزان ساده است؟
📍 گزارش یک مشکل (باگ) برای رفع آن چطور؟
📍 استقرار نسخه جدید نرم افزار چطور؟ شاید برگشتن به نسخه قبلی به این دلیل که نسخه جدید مشکل دارد را ترجیح میدهید!
ذینفعان پروژه اغلب موضوعات را بیشتر از آنچه باید باشه پیچیدهتر می کنند که یکی از دلایل رایج شکست پروژههای نرمافزاریه. تیم پروژه باید بتونن اهداف و کارهای پروژه رو کامل تجسم کنن. اگرچه، ذینفعان میتوانند تو ذهنشون پروژه رو تو چند مرحله ساده و جادویی انجام بدن. اونا فکر میکنند که به سرعت و به راحتی به راه حل نهایی میرسن، مهم هم نیست چقدر پیچیده باشه.
ذینفعان نباید یک پروژه نرمافزاری را به یک هیولای صلب، غول پیکر و انعطاف ناپذیر تبدیل کنن. در عوض، اونا باید به تیم فناوری اطلاعات اجازه بدن تا پروژه رو شبیه یک پیاز بسازن و تو هر لایه بلوغش رو افزایش بدن. جایگزین دیگهای براش در دنیای واقعی نیست. باوجود کامل بودن الزامات، همیشه تغییر وجود داره.
اگر نرمافزارتون به اندازه کافی انعطاف پذیر نیست که بتونه به سرعت با نیازهای در حال تغییر سازگار بشه، این پروژه حتی قبل از شروعش مرده.
برای ساده نگه داشتن چیزها، این نکات کلیدی رو به خاطر داشته باش:
💡 الزامات را ساده کن!
تحلیلگران کسب و کار اغلب راه حل خاصی را که به ذهنشون میرسه رو با نیاز واقعی مشتری بر اساس یک نیاز تجاری قاطی میکنن. با این که نیاز واقعی ممکنه بسیار ساده باشه، شاید شکاف ارتباطی بین تحلیلگران کسب و کار و برنامه نویسان/ توسعه دهندگان، به خاطر این وجود داشته باشه که هیچ کدومشون واقعاً نمیدونه دیگری چه میکنه.
تحلیل گران کسب و کار الزامات رو با شکلهای نمودار درختی تعریف میکنن. الزام اصلی، هدف ساده و بدیهی کل پروژه است. الزامات کلانتر در شاخههای بالاتر به الزامات کوچکتر در شاخههای کوچک سطح پایین شکسته میشوند. این روند در نمودار درختی تا زمانی تکرار میشه که هر الزام به صورت واضح مشخص شده باشه. نرمافزارهای Mind-map میتونن برای مستندسازی الزامات با استفاده از این روش استفاده بشن.
به محض این که مجموعه کوچکی از الزامات مشخص شدن، توسعه نرمافزار میتونه آغاز بشه
💡 فرآیندهای توسعه چابک را دنبال کن!
به محض شناسایی مجموعه کوچکی از الزامات، تیم توسعه میتونه فوری نمونهسازی رو شروع کنه. هنگامی که نمونه اولیه در دسترس باشه، ذینفعان میتونن آزمایش کنن و بازخورد ارائه بدن. بازخورد مشتری تضمین میکنه که الزامات دقیق هستند و همچنین به شناسایی شکافهایی که در الزامات ایجاد شده است کمک میکنه. شکافها به نیازمندیهای جدید تبدیل میشن، توسعه دهندگان دوباره نمونه سازی میکنن و این چرخه ادامه پیدا میکنه. هر چرخه باید تا حد امکان کوتاه باشه- معمولا بیش از دو تا سه هفته نیست.
این چرخه، با تعریف “مجموعه کوچکی از الزامات”، “تولید یک نمونه اولیه” و “دریافت بازخورد”، تضمین میکنه که همه ذینفعان پروژه همیشه در یک سطح هستن و همه با آنچه در حال جریانه، راحت باشن. با پیروی از این تکنیکها، هر پروژه نرمافزاری میتونه به یک نتیجه موفقیت آمیز برسه. مخصوصا زمانی که موفقیت در قالب مشتری راضی و نرمافزاری کارا تعریف شده باشه که دلیل و چرایی که بخاطرش پروژه تعریف شده را برآورده کرده باشه.
خلاصه اینکه:
سادگی تصادفی اتفاق نمیافته. نیازه که به صورت فعالانه ترویج داده بشه. پیچیدگی زمانی اتفاق میافته که بهش توجه نکنی.
©️ توجه: کلیه حقوق این پست مربوط به شرکت راهبران سیستم رستاک بوده و کپی، نقل قول و یا چاپ مطالب در سایتها، شبکه های اجتماعی و یا بصورت کتاب و جزوه بدون ذکر منبع پیگرد قانونی دارد.
