چگونه یک نقشه راه چابک بسازیم؟

نقشه راه چه کمکی به ما می‌کند؟

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

ولی یک نقشه راه چگونه می‌تواند برای آینده برنامه‌ریزی کند و در عین حال چابک هم باشد؟ چگونه بین نیازهای کسب و کار و توانایی ساختن، آزمودن، تکرار و سبک ماندن مصالحه می‌کنیم؟

نقشه راه چیست؟

” یک برنامه برای آینده، عموما با هدفی مشخص”  دیکشنری آکسفورد لرنرز

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

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

محدوده[2]، پیچیدگی[3] و اولویت[4].

چگونه یک نقشه راه را توصیف کنیم؟

محدوده

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

رویکرد رایج ساختن حداقل محصول قابل ارائه[5] و سپس توسعه آن است. با این حال، هرگز یک حداقل محصول که به خودی خود ارزشی تولید نمی‌کند نسازید زیرا اگر اولویت‌ها تغییر کنند، شما با محصولی که هیچ ارزشی برای کسب و کار یا محصول ایجاد نمی‌کند تنها خواهید ماند.

پیچیدگی

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

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

• پیچیدگی پروژه
• دانش کدبیس[6] (مجموعه سورس کدهای) تیم
• بدهی فنی[7] (هزینه انجام کارهای آسان در کوتاه مدت در مقابل کارهای پیچیده تر در دوره‌ای طولانی)
• پراکندگی تمرکز

یک رویکرد خوب این است که حداقل محصول قابل ارائه (MVP) به بخش‌های کوچکتری شکسته شود و اندازه هر بخش با کمک مهندسان تخمین زده و در صورت لزوم این کار تکرار شود. سپس حاشیه خطا به هر تخمین کلی افزوده گردد تا ایده‌ای از چارچوب زمانی[8] قابل ارائه شکل گیرد.

اولویت

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

یک روش، محاسبه هزینه انتشار با تأخیر[9] است که برای مقایسه فیچرها که مشکلات متفاوتی را حل می‌کنند خوب کار می‌کند. اگر منابع کافی داشته باشید، می‌توانید دو صف کار را به صورت موازی به اجرا درآورید. در آن صورت، برای مثال می‌توانید 20% توان تیم را بر روی فیچرهای کوچک یا بدهی فنی بگذارید.

فارغ از اینکه چگونه موضوع اولویت بندی را حل می‌کنید، باید تکلیف منزلتان را بنویسید! هیچ چیز را بدون در نظر گرفتن محدوده و پیچیدگی اولویت‌بندی نکنید.

…و اینگونه است که نقشه راه را چابک می‌سازید

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

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

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

نهایتاً به تیم خود و کسب و کار یادآوری کنید که  این نقشه راه در طول زمان تغییر خواهد کرد و تنها ابزاری است برای نمایش کارتان و تعامل در خصوص برنامه‌هایی که دارید. یک نقشه راه در واقع یک داکیومنت زنده است.

نمونه‌ای از نقشه راه در حال تغییر را در تصویر زیر می‌بینید:

الف) نقشه راه قدیمی

ب) نقشه راه پس از به روز رسانی

[1] Gantt Chart

[2] Scope

[3] Complexity

[4] Priority

[5] MVP: Minimum Viable Product

[6] Codebase: In software development, a codebase (or code base) is a collection of source code used to build a particular software system, application, or software component. Typically, a codebase includes only human-written source code files

[7] Technical debt: In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

[8] Time Frame

[9] Delaying release

نویسنده: Chloé Rozenbaum

ترجمه :مهدی صدقی فروز استرآبادی