چگونه توسعه دهندگان می‌توانند یک پروژه شکست خورده را نجات دهند؟

فرض کنید یک پروژه در شرف شکست خوردن است. همه احساس می‌کنند که پروژه در مهلت تعیین شده پایان نمی‌یابد. اما در نهایت این برنامه به موقع و بدون اشکال منتشر می‌شود. چنین چیزی چگونه امکان پذیر است؟

من می‌خواهم داستانی واقعی راجع به یک پروژه بلند پروازانه دو ماهه که تیم ما به پایان رسانده، برای شما تعریف کنم. سفری بسیار پرتنش، چالش برانگیز و پر از غافلگیری که توسعه دهندگان رهبران آن بودند.

قصد دارم فاش کنم که چرا اوضاع خراب شد و چگونه توانست با تصمیمات هوشمندانه تیم فرانت-اند موفق به حرکت در مسیر خود شود.

پروژه

این پروژه به منظور جلوگیری از ارائه ابهامات، عمدا از دیدگاه فرانت-اند تفسیر می‌شود.

کسانی که درگیر آن بودند:

• صاحب محصول
• تیم فرانت-اند (2 توسعه دهنده)
• تیم بک-اند (2 توسعه دهنده)
• تیم تضمین کیفی (2 تست کننده)
• طراح تجربه کاربری
• مدیر محتوا

در مجموع 9 نفر از 6 بخش برای پیش بردن پروژه به مدت دو ماه (حدود 9 هفته) اختصاص داده شدند. طراحی تجربه کاربری از قبل انجام شده بود، بنابراین در کل مدت زمان محسوب نشده است.

موضوع پروژه

شرکت‌های در حال رشد معمولا در استخدام‌های جدید و تغییر در ساختار سلسله مراتب سرمایه گذاری می‌کنند. از هر 9 نفر، 2 نفر کارمند جدید (صاحب محصول و طراح) بودند، 2 نفر یک سال سابقه کار در سازمان را داشتند و از هر 6 تیم، 3 نفر تازه کار در حالی که بقیه تا حدودی با سابقه بودند.

تیم طراحی تجربه کاربری تازه تأسیس به طور گسترده بر رابط کاربری پشتیبانی شده در Figma متمرکز بود و کارهای آن توسط یک مدیر محتوا که تازه به دپارتمان ملحق شده بود، پشتیبانی می‌شد. به علاوه پیاده سازی برنامه‌ سازمانی با مالکیت محصول برای ما جدید بود، ضمن اینکه این وظایف قبلا توسط یک مدیر پروژه انجام می‌شد.

اما وظیفه من چه بود؟ احتمالا جواب را می‌دانید. بله من عضو تیم تازه تاسیس توسعه دهنده‌های فرانت-اند بودم. تا این لحظه در تیم‌های مختلفی شرکت داشتم که به منظور پیشبرد اهداف و ترقی محصولات اختصاصی تلاش می‌کردیم.

نکته مهم: محیط پویا، همکاران جدید و ساختار جدید شرکت یعنی ترکیبی خطرناک برای پروژه‌های بلند پروازانه با مهلت محدود.

هدف پروژه

هدف از برنامه این بود که مشتریان بتوانند به راحتی داده‌های به اشتراک گذاشته شده را پیدا کرده و بر روی آنها کار کنند.

برای اینکه کار پیچیده‌تر شود باید تمام خدمات، محصولات افزودنی و موارد کاربر را در طول فرایند توسعه به خود اختصاص دهد.

چه چیزی پروژه را به خطر انداخت

پس از گرفتن پروژه، بلافاصله وارد روند کار شدم و هیچ ایده‌ای درباره آن نداشتم. تمام جلسات برنامه ریزی از قبل انجام شده بود و تیم‌ها هم شکل گرفته بودند. در همان زمان، این کار به عهده افراد بود که به نوعی خودشان را سازماندهی کرده و راه خود را پیدا کنند. من احساس استرس و اضطراب زیادی داشتم:

هیچ اطلاعاتی برای شروع وجود نداشت، هیچ تنظیم اولیه‌ای در کار نبود و احتمالا مهمترین نکته عدم رهبری و مدیریت بود. برای پر کردن این خلا بسیاری از کارهای مدیریت پروژه طبیعتا به تیم فرانت-اند اختصاص داده شد، بنابراین به زمان بیشتری برای هماهنگی نیاز داشت.

نکته مهم: غالبا شکست خوردن پروژه وابسته به چند عامل مشترک می‌باشد. نیکلاس زاکاس در یکی از خبرنامه‌های اخیر خود به نام "تفکر در مورد اشتباهات" آنها را اینگونه گروه بندی کرده است: مهارت‌ها، شانس و اطلاعات پنهان. چنین ترکیبی بر نتیجه تأثیرگذار است وهمه آنها بطور کلی برای چنین پروژه‌هایی کاربرد دارند.

با چند استثنا می‌توانید میزان مهارت خود را برای تصمیم گیری کنترل کنید و همچنین برای کشف اطلاعات پنهان تلاش کنید (البته گاهی اوقات مشخص نیست که در کجا باید جستجو کرد)، شانس هم کاملا از کنترل شما خارج است.

به داستان برگردیم، باید اعتراف کنم که این یک میدان مین از اطلاعات پنهانی بود که تا زمان انتشار نهایی ظاهر می‌شد. تمام مهارت‌های مورد نیاز وجود داشت و حتی بیشتر از آن. هیچ اتفاق غیرمنتظره‌ای هم رخ نداد. تنها کشف و مقابله با فرضیات اشتباه متداول‌ترین گلوگاه پروژه بود.

چه چیزی باعث پنهان شدن اطلاعات شد:

1. عدم رهبری

نبود یک رهبر و یک نمونه در دسترس منجر به حواس پرتی‌های مکرر در مدیریت فعالیت‌های سازمانی شد.

2. عدم دانش کافی

نبود درک کافی از روند کار به ویژه توسط کارمندان جدید با تغییرات در فرایند توسعه ارتباط مستقیم دارد.

3. الزامات ناقص

وجود شکاف در دانش افراد منجر به الزامات نامشخص یا خیلی محدودی می‌شود که ناشی از عدم مشارکت فعال افراد با درک مساله خوب در مرحله برنامه ریزی است.

4- تیم‌های متعدد

اگر افراد در یک پروژه کاربردی قرار بگیرند، لازم است شش تیم مختلف هماهنگ شود.

البته همه این مفاهیم ما را ناامید نکرد، بلکه ما را مجبور به پرداختن به حوزه‌های مشکل‌ساز هم در کد و هم در مدیریت کرد.

ممکن است بپرسید چرا توسعه دهندگان باید بار سازمانی را تقسیم کنند؟ آیا نمی‌توان به راحتی آن را به یک PO یا شخصی از مدیریت منتقل کرد؟ بالاخره این وظیفه آنهاست و شما فقط کد می‌نویسید، درست است؟ این سوالات را بارها از آنها پرسیده‌ایم. با این وجود پروژه توسط تیم توسعه دهنده هدایت شد و ما مسئول آن بودیم.

بار سنگین روی دوش توسعه دهندگان

هر زمان که تیمی در معرض شکست قرار می‌گیرد، بهترین راهکار این است که به توسعه دهندگان با تجربه اجازه دهید کار را به عهده بگیرند. این باید تا زمانی ادامه یابد که روند با یک سرعت طبیعی با مراحل برنامه ریزی و تکرار اجرا شود.

Extreme Programming (XP) در پاسخ به مشکلاتی که نیازهای آن تغییر می‌کند ایجاد شد. مشتریان ممکن است تصوری راجع به آنچه سیستم باید انجام دهد نداشته باشند. ممکن است سیستمی داشته باشید که انتظار می‌رود عملکرد آن هر چند ماه یکبار تغییر کند. در بسیاری از محیط‌های نرم‌افزاری تغییر الزامات به صورت پویا انجام می‌شود. این زمانی است که روش XP موفق خواهد شد.

با بهره گیری از XP همکاری فنی ما پیشگام شد، زیرا ما می دانستیم که QA و بک-اند به خوبی آن را درک می‌کنند و تیم فرانت-اند می‌تواند بازخورد‌های سریع را ارائه دهد. ما به رابط کاربری نزدیکتر هستیم و به اندازه کافی انعطاف داریم تا تغییرات را ایجاد کنیم.

این حرکت درستی بود. شرایطی از این دست باید فوق العاده تلقی شود و هر زمان ممکن باشد از آن اجتناب شود. هیچ چیز بهتر از انجام کاری نیست که شما به عالی‌ترین روش اجرا کنید، با اینکه PM پیوندهای بین تیمی را مدیریت می‌کند.

واقعیت دردناک این است که اکثر شرکت‌ها از هیچ روش ساختاری پیروی نمی‌کنند یا فریمورک‌هایی مانند SCRUM یا Kanban را اعمال نمی کنند. من یکی از طرفداران Kanban هستم، حتی مزایای اندک آن نیز کافی است تا بتواند سازمان‌ها را مجاب کند که آن را امتحان کنند. علی رغم گفتگوهای بی پایان و سرمایه گذاری‌های کلان در فریمورک‌هایی مانند SCRUM، اکثر شرکت‌ها حتی اگر متوجه این موضوع نباشند، به XP تکیه می‌کنند که با مسئولیت‌های توسعه دهندگان با PM، بازاریابی، سئو، طراحی و ... همپوشانی دارد و این تصادفی نیست.

استراتژی توسعه دهندگان برای مقابله با موانع

خلاصه‌ای از اصول عملی در زیر ذکر شده است:

ما در قسمت فرانت-اند یک استراتژی انعطاف پذیر برای مقابله با عدم اطمینان پروژه ایجاد کردیم و به سرعت متوجه شدیم که داشتن یک کد عالی فقط برای موفقیت کافی نیست.

همکاران من افراد ماهری بودند که به ندرت با چالش‌های فنی روبه رو می‌شدند، هرچند که اتفاقات پراکنده (مانند بحران Covid-19) بسیار غیر قابل پیش بینی می‌باشد و آماده سازی برای آن دشوار است. با توجه به این نکته، تمرکز استراتژی در درجه اول معامله با اطلاعات پنهان و به حداقل رساندن تأثیرات منفی آن از پروژه است.

حل مرحله به مرحله هر مشکل در نهایت باعث کشف اطلاعات بیشتر در روند کار می‌شود و در کنار آن ابزارهای مفیدی برای رسیدگی به درخواست‌های تغییر ورودی در اختیار شما قرار می‌دهد.

بیایید دقیق تر مشکلات پیش رو را مورد بررسی قرار دهیم.

هیچ رهبری واضحی وجود ندارد

من تصمیم گرفتم که در مورد این پروژه پیشگیرانه عمل کنم و جلسه‌ای آغاز کردم تا همه چیز را سازمان دهم و اعتماد به نفس تیم را بالا ببرم. دستور کار این بود:

- الزامات پروژه

- تقسیم کار بین اعضا

- وظایف فرانت-اند

- پایگاه کد پروژه

- کانال‌های ارتباطی

- ارزیابی و برآورد

این فرصتی بود برای این که با هم آشنا شویم و سرانجام احساس می‌کردیم پروژه در حال حرکت است. علاوه بر این، جلسات همگام سازی منظم برای بحث در مورد موانع، پیشرفت یا اطلاعات جدید برگزار می‌شد.

عدم دانش کافی

بدیهی است که QA و تیم بک-اند بیشتر موارد اساسی را به خوبی درک می‌کنند. دو فعالیت در این وضعیت کمک کننده بود:

- تکرارهای کوتاه سریع و انتشارهای اولیه

استقرارها روزانه انجام می‌شد تا QA و بک-اند همیشه چیزی قابل استفاده برای انجام داشته باشند.

- جلسات همگام سازی مکرر

این کار برای بحث درباره هر یافته جدیدی از آخرین انتشار و تبدیل آنها به کارهای توسعه است.

الزامات ناقص

الزامات ناقص اغلب با طراحی نهایی رابط کاربری پوشیده می‌شوند و معمولا وقتی QA دست خود را روی نمونه اولیه فرانت-اند می‌گذارد، دیر به نتیجه می‌رسد.

- به کارگیری نمونه‌های اولیه ناقص

انتشار نمونه‌های اولیه قابل استفاده با متن‌های ساختگی به منظور ایجاد یک حلقه بازخورد سریع، ایده خوبی است زیرا ممکن است ماژول‌های نهایی هنوز وجود نداشته باشد و متن‌های اصلی آماده تولید هستند.

- اصل DRY را بشکنید

اصل DRY در هنگام کار با پیش نیازهایی که مرتبا تغییر می‌کنند، جایی که یک پایگاه کد WET مداخلات سریع و تقریبا بدون عوارض جانبی را ایجاد می‌کند، فایده‌ای ندارد.

- آن را کاملا تست کنید

استانداردهای تست را بدون توجه به هر چیزی حفظ کنید، چرا که نسخه‌های بدون اشکال را تضمین می‌کنند. نوشتن تست برای هر ویژگی جدید یا یک مورد حاشیه‌ای مهم است، زیرا از سطح اطمینان ما در به هم ریختگی موارد اضافه یا حذف ویژگی جدید بهره می‌برد.

تیم‌های متعدد

این موضوعی است که به هر طریقی باید از آن اجتناب شود یا در صورت عدم امکان، برای مدت کوتاهی بسیار خردمندانه از آن استفاده شود.

چگونه تیم فرانت-اند خسارت هماهنگی را جبران کرد:

- تقسیم وظایف بین یکدیگر

من و همکارانمم با تشکیل شیفت هنگام سازماندهی جلسات همگام سازی و مدیریت حلقه‌های تکرار، این بار را تقسیم کردیم.

- راه اندازی کانال‌های ارتباطی مستقیم

این کار در Slack برای همه موارد از به روزرسانی وضعیت و بحث در مورد نیازها گرفته تا برنامه ریزی جلسات انجام شد.

خلاصه‌ای از بهترین تجارب

در زیر خلاصه‌ای از اصول عملی برای مقابله با برخی از گلوگاه‌های پروژه آورده شده است.

- برگزاری جلسه آشنایی: به منظور ایجاد اعتماد به نفس و کاهش استرس.

- برگزاری جلسات همگام سازی منظم: با دادن فرصتی به افراد برای اشتراک گذاشتن ایده‌ها شرایط را بهبود می‌بخشد.

- پرهیز از تکرار مکررات: موجب گرفتن بازخورد سریع می‌شود.

- انتشار یک نمونه اولیه: با این کار به ایرادات اصلی قبل از موعد پروژه پی می‌برید.

- ایجاد تغییرات همراه با refactoring: منجر به کیفیت کد بالا و تغییرات سریعتر در آینده می‌شود.

- تست مرحله به مرحله: اشکالات را به حداقل رسانده و باعث منتشر شدن یک محصول بدون مشکل می‌شود.

- تقسیم وظایف مدیریتی: چند وظیفه‌ای را کاهش می‌دهد و اجازه می‌دهد تا روی چالش‌های مهمتر تمرکز کنید.

جمع بندی

باید اعتراف کنم که برای این پروژه هیچ کار اضافه‌ای نکردم. این باعث ایجاد حس موفقیت کاذب می‌شود که به نوبه خود شما را فریب می‌دهد تا اشتباهات مشابهی را دفعات بعد تکرار کنید.

نتایج شگفت آوری با استفاده از استراتژی فوق به دست آمد و می‌خواهم اعداد و ارقامی را ذکر کنم. این پروژه 9 هفته به طول انجامید، اما از نظر وظایف و کارهای انجام شده سنگین به نظر می‌رسید. پس از انتشار، هیچ باگی گزارش نشد. استقرار را انجام داده و کار را تمام کردیم.

پروژه‌های XP هنگامی که با سایر پروژه‌های موجود در محیط سازمانی یکسان مقایسه می‌شوند، به اتفاق آرا بهره وری بیشتر برنامه نویس را گزارش می‌کنند.

این راهنمای کوچک را به خاطر بسپارید، تا پروژه‌هایتان به خطر نیافتد.

منبع