پروداکت استوری: ضد الگو ها در توسعه محصولات چابک

ضد الگوها Anti-Patterns مواردی هستند که روی توسعه محصولات اثر منفی می گذارند. ما در مدیریت محصول با متدولوژی اجایل از ابزار های متفاوتی استفاده می کنیم که همه آنها میتوانند به ما در رسیدن به موفقیت کمک کنند. اما لازم است با خطراتی که می توانند محصولی که بسیار خوب برنامه ریزی شده را خراب کنند، آشنا باشیم.ممکن است خطرات زیاد و از جنبه های مختلف برای محصولات وجود داشته باشد که ما حتی روحمان از وجود آنها اطلاعی ندارد و پیش خود فکر می کنیم که همه چیز به صورت کاملا درستی در حال پیشرفت است. تنها در صورت شناخت این موارد است که می توانیم برای کاهش اثرات آنها اقداماتی انجام دهیم.براساس تجربه من، تمامی این موارد باعث به وجود آمدن پیامد های منفی می شود و اگر بخواهیم آنها را به صورت اجمالی دسته بندی کنیم، میتوانیم بگوییم بخشی از آنها مربوط به مدیریت، برخی مربوط به معماری و برخی مربوط به عدم ایجاد زبان مشترک و فهم دقیق از منظور صحبتهای افراد است.در این مطلب بر مواردی که در دسته بندی مشکلات مدیریتی قرار میگیرند تمرکز بیشتری خواهیم داشت. هرچند لازم است توجه داشته باشیم این موارد و مشکلات می‌توانند در سازمان ها و تیم ها متفاوت بوده و حتی گسترده تر از مواردی باشند که به آنها اشاره می کنیم.بیشتر مشکلاتی که در زمینه مدیریت وجود دارد پیرامون مسائلی است که افراد در آن دخیل هستند و کمتر شامل مشکلات سیستمی و ساختاری می شوند هرچند که آنها را نمیتوانیم نادیده بگیریم. تمرکز اصلی ما بر مواردی خواهد بود که متاثر از رفتار و تصمیم گیری های افراد،‌ محصولات با شکست مواجه می شوند.ناتوانی در تحلیل:اولین موردی که به آن اشاره می کنم زمانی اتفاق می افتد که اعضای تیم در تجزیه و تحلیل مشخصات و نیازمندی ها با مشکل مواجه می شوند. مدیران محصول (یا مالکان محصول) بخاطر تلاش زیادی که برای تجزیه و تحلیل کامل نیازمندی های مشتریان انجامم می دهند نمی‌توانند در مورد جهت و PLC (چرخه عمر محصول) تصمیم بگیرند. به این دلیل که نیاز می دانند تا تمامی تجزیه و تحلیل های اولیه را به درستی انجام دهند.در این شرایط دو اتفاق می افتد، یا نیاز مندی ها به صورت صحیح تحلیل نشده و به صورت ناقص در اختیار تیم توسعه قرار می گیرد، یا زمان زیادی صرف تجزیه و تحلیل نیاز ها می شود (علاقه به بی نقص بودن) و باعث می‌شود تا زمان اثر مخرب خود را بر توقف فعالیت های تیم توسعه گذاشته و این خطر را ایجاد کند که احتمالا نیازمندی ها در طی این زمان طولانی دستخوش تغییرات خواهند شد.این عامل روی تیم توسعه اثر منفی خواهد گذاشت زیرا با بوجود آمدن فاصله در برنامه های کاریشان و به ثمر ننشستن تلاش هایی که انجام می دهند، دچار ناامیدی می شوند. توجه داشته باشید تیم توسعه همواره این آمادگی را دارد که در جهت آنالیز انجام شده توسط شما، در مسیر توسعه گام بردارد اما زمانی که شما این گام‌ها را براساس آنالیز خود به صورت ناقص تعریف کرده باشید و یا زمان بیش از اندازه را صرف بی نقص بودن آن کرده باشید، در حقیقت ریتم منظم ورودی های لازم برای فعالیت تیم توسعه را با فواصل خالی مواجه کرده اید و یا برای آنها کارهای دوباره و چند باره تراشیده اید.تجزیه و تحلیل ایده آل گرایانه زمانی رخ می دهد که شما در انتخاب یک مسیر برای شروع، شجاعت و اطمینان کافی را ندارید. متاسفانه این مورد بیشتر در تیم هایی رخ می دهد که مدیران یا مالکان محصول به صورت جداگانه از سایر مالکان و مدیران محصول فعالیت می کنند و به صورت منظم به اشتراک گذاری اطلاعات و دیدگاه ها در میان آنها اتفاق نمی افتد. (فرد گرایی به جای کار تیمی) در نتیجه دیدگاه محدود و انفرادی در مدیران و مالکان محصول ایجاد شده و قدرت تصمیم گیری بهتر که تحت تاثیر خرد جمعی حاصل می شود را از آنها سلب می کند.در حقیقت توسعه محصول به صورتIterative به همین دلیل در چارچوب اجایل مورد استفاده قرار می گیرد. تا هر گونه اشکال و اشتباهی در تحلیل های انجام شده، بوسیله ارائه نسخه های پشت سر هم Working Productsقابل رصد و اصلاح باشد.فراموش نکنیم نیاز نیست همه چیز را از ابتدا بدانیم حتی اگر Domain Expert هستیم ممکن است مواردی باشد که در وسعت دید ما نباشند و ما را دچار خطا کنند. توسعه محصول به صورت Iterative به شما انعطاف پذیری خوبی می دهد تا در بازه های کوتاه بتوانید با اصلاح موارد اشتباه، انتخاب های درستی انجام دهید و در نتیجه به سمت محصولی بهتر گام بردارید. به این نکته هم توجه کنید که تیم های توسعه نرم افزار از پیشرفت هایی که بدست می آورند و دیده شدن تلاش هایی که می کنند بسیار خوشحال و پر انرژی خواهند بود.تاکید زیاد بر چیزایی که بعدا خیلی بدردبخور هستند ولی الان نه چندان:این موردبه این معنی است که بر روی مواردی که باید در فاز ها/اسپرینت های بعدی به انجام آنها فکر کنیم، تاکید زیادی صورت بگیرد. در این حالت میتوان گفت که اولویت بندی به درستی انجام نشده است، مثال ساده آن این است که زمان و توانایی بسیار با ارزش توسعه دهنده‌ها روی مواردی صرف می شوند که در حال حاضر ضرورتی ندارند و ارزش چندانی ایجاد نمی‌کنند.در صورتی که این اشکال وجود داشته باشد، تیم ها پس از هر اسپرینت، تعدادی فیچر نرم افزاری پراکنده با اولویت های مختلف توسعه داده اند که در کنار هم، ایجاد هماهنگی و همخوانی درستی برای ارائه بعنوان Working Product نمی کند.در این شرایط وظیفه مدیران یا مالکان محصول به خوبی روشن می شود که لازم است برای شفاف سازی نیازمندی های ذینفعال و همچنین همکاری با آنها برای تعیین اولویت های هر مورد، تلاش بیشتری انجام دهند.تاثیر فکر شاخص بر تفکر گروه:یکی از باگ های کار تیمی این مورد است. از نظر علم روانشناسی "افراد تمایل بیشتری به پیروی از نظرات مطرح شده در گروه را دارند" و این جمله به این معناست که حتی اگر نظری مخالف با اکثریت گروه داشته باشند ترجیح می دهند درباره آن صحبت نکنند و از راهی که گروه پیش گرفته، پیروی کنند.این مساله اکثرا زمانی رخ می دهد که فردی با دانش بیشتر و یا با شیوه رفتار برجسته تر، نظرات خود را به گونه ای بیان می کند که باعث ساکت شدن افراد دیگر می شود و صحبت پیرامون موضوع در آن لحظه خاتمه می‌یابد.سکوت افراد حاضر در جلسه به این معنا نیست که آنها تمایلی برای ابراز نظر های خود ندارند بلکه با شرایط پیش آمده، ترجیح می دهند نظر خود را برای جلوگیری از هر گونه برخورد احتمالی، نزد خود نگه دارند.افراد ساکت، همان همکاران ما هستند که تجربه های بسیار با ارزش و متفاوتی دارند و موضوعات را از دیدگاه های مختلفی می بینند و می توانند با نظرات ارزشمند خود به ما در زمینه فعالیت گروهی و توسعه محصول بسیار کمک کنند.بنابراین یکی دیگر از توانایی های مهم افراد حاضر در تیم ها به زمینه های Soft Skill بر می‌گردد، تا بتوان عملکرد افراد در انجام کار تیمی را به حداکثر رساند و همچنین افراد در بیان حرف ها و نظرات خود طوری عمل کنند که باعث سکوت افراد نشوند.یکی از راهکار هایی که برای جلوگیری از بروز این مشکل، این است که راه حل ها به صورت جداگانه توسط هر فرد تعریف شود. حتی در سازمان های بزرگ برای ارائه راه حل ها، تیم ها به صورت جداگانه با هم کار می کنند و در نهایت راه حل های خود را ارائه می دند.همین کار را می توانیم به صورت انفرادی نیز انجام بدیم. در موارد خاصی که میدانیم نظر جمعی و تفکری بالاتر از فکر یک نفر مورد نیاز است (که امیدوارم در سازمان ها همیشه به این صورت باشد) افراد به صورت جداگانه راهکار ها یا نظرات خود را می نویسند و سپس تمامی آنها را جمع آوری می کنیم و تک تک روی آنها بحث خواهیم کرد.پی نوشت:میل برای نوشتن این مطلب از اتفاقاتی که در محل کارم رخ میداد برای من ایجاد شد. اولین شرکتی که در صنعت IT تجربه می کردم با بسیاری از این موارد رو بعنوان فرهنگ طبیعی خود پذیرفته بود. پس از مدتی جستجو در اینترنت با آقای Bradley Poulette آشنا شدم که در مورد کلید واژه این مجموعه مشکلات من را راهنمایی کردن. بعد از اون به جمع آوری موضوعات پرداختم که لیست نهایی رو با راهنمایی خود ایشون اصلاح کردم. در نهایت ایشون دوره مدیریت محصول نرم افزاری که به صورت آنلاین داشتند را به من معرفی کردن که بخشی از این مطالب رو هم در اونجا ارائه دادند. به نوعی این پنج پست ویرگول مجموعه ای از این مسائل بود. پایان قسمت اول http://vrgl.ir/UokFT http://vrgl.ir/7bI5b http://vrgl.ir/05BAu http://vrgl.ir/0Dyzz