بسته به اینکه در حال بهبود یک محصول موجود هستیم یا در حال ساخت محصولی جدید، انتظارات متفاوتی در مورد آنچه در طول چرخه شش هفتهای اتفاق میافتد، خواهیم داشت.
این موضوع ما را به تأمل در جایگاه خود در مسیر توسعه محصول دعوت میکند تا بر اساس آن، تصمیمگیری کنیم.
هنگامی که قابلیتهای جدیدی را به یک محصول موجود اضافه میکنیم، فرآیند استاندارد Shape Up را دنبال میکنیم: شکلدهی به کار، شرطبندی (تخصیص زمان و منابع) بر روی آن، و سپردن آن به یک تیم برای ساخت. انتظار داریم تیم تا پایان چرخه، نسخهای از کار شکلدهی شده را تکمیل و عرضه کند.
در مورد یک محصول موجود، تمام کد و طراحی موجود که قرار نیست تغییر کند، نوعی فضای خالی را تعریف میکند که قابلیت جدید در آن جای خواهد گرفت. شکلدهی و ساخت در این حالت، شبیه به ساختن یک قطعه مبلمان برای خانهای است که از قبل ساخته شده است.
محصولات جدید متفاوت هستند. در حالی که اضافه کردن به یک محصول موجود مانند خرید یک کاناپه برای اتاقی با ابعاد ثابت است، توسعه محصول جدید مانند کشف محل قرارگیری دیوارها و فونداسیون است تا ساختمان بتواند سرپا بماند.
ما سه فاز کاری را هنگام ساخت یک محصول جدید از ابتدا مشاهده کردهایم. در هر فاز، نحوه شکلدهی و انتظارات ما در مورد نحوه کار تیمی در طول چرخه، متفاوت است. این فازها در طول چندین چرخه اتفاق میافتند، اما ما همچنان فقط یک چرخه را در هر بار شرطبندی (تخصیص زمان و منابع) میکنیم.
در اولین مراحل یک محصول جدید، ایده ما فقط یک نظریه یا یک جرقه است. ما نمیدانیم آیا مجموعه قابلیتهایی که تصور میکنیم در واقعیت منسجم خواهند بود یا خیر، و تصمیمات فنی در مورد نحوه مدلسازی آنها در کد، حتی کمتر روشن هستند.
این به معنای وجود مقدار زیادی کار ضایعاتی است. ممکن است در نیمه راه پیادهسازی یک قابلیت تصمیم بگیریم که آن چیزی نیست که میخواهیم و به جای آن رویکرد دیگری را امتحان کنیم.
به عبارت دیگر، ما نمیتوانیم به طور قابل اعتماد از قبل آنچه را میخواهیم شکلدهی کنیم و بگوییم: "این چیزی است که ما میخواهیم. انتظار داریم پس از شش هفته آن را عرضه کنیم.". ما باید با ساختن آن یاد بگیریم که چه میخواهیم.
ما این مرحله را حالت R&D مینامیم و به سه روش آن را تنظیم میکنیم.
• به جای شرطبندی (تخصیص زمان و منابع) بر روی یک pitch (پیشنهاد) به خوبی شکلدهی شده، عمدتاً زمان را برای اسپایکینگ (بررسی و نمونهسازی اولیه) برخی از قطعات کلیدی ایده محصول جدید شرطبندی (تخصیص) میکنیم. شکلدهی در این مرحله بسیار مبهمتر است زیرا انتظار داریم با ساختن یاد بگیریم.
• به جای واگذاری کار به یک تیم ساخت جداگانه، افراد ارشد ما تیم را تشکیل میدهند. دیوید (CTO) نقش برنامهنویسی را بر عهده میگیرد و با جیسون (CEO و طراح) یا یک طراح ارشد با راهنمایی جیسون کار میکند. این موضوع به دو دلیل ضروری است. اولاً، وقتی خودتان نمیدانید چه میخواهید، نمیتوانید کار را به دیگران واگذار کنید. ثانیاً، تصمیمات معماری تعیینکننده آنچه در آینده محصول امکانپذیر خواهد بود هستند – آنها "سوراخهایی" را تعریف میکنند که قابلیتهای آینده در آنها جای میگیرند. در این فاز، تیم باید دیدگاه محصول را حفظ کند و بتواند تأثیرات بلندمدت تصمیمات طراحی را ارزیابی کند.
• در نهایت، انتظار نداریم در پایان یک چرخه R&D چیزی را عرضه کنیم. هدف اسپایکینگ (بررسی و نمونهسازی اولیه) است، نه عرضه. در بهترین حالت، مقداری UI (رابط کاربری) و کد خواهیم داشت که به عنوان پایهای برای کارهای بعدی عمل میکند. هدف این است که یاد بگیریم چه چیزی کار میکند تا بتوانیم به یک ساختار باربر (load-bearing structure) متعهد شویم: تصمیمات اصلی کد و UI که فرم محصول را در آینده تعریف خواهند کرد.
ما نمیتوانیم تنها با یک چرخه کار R&D چیزی را به مشتریان عرضه کنیم. اما همچنان بیش از یک چرخه را در یک زمان متعهد نمیشویم. ممکن است از چرخه اول متوجه شویم که هنوز آماده پرداختن به محصول نیستیم. یا ممکن است کشف کنیم که شهود ما درست بوده و محصول در حال شکلگیری است. بسته به اینکه چگونه پیش میرود، چرخه به چرخه تصمیم میگیریم که آیا زمان غیررسمی را در حالت R&D ادامه دهیم یا خیر.
اگر پس از چند چرخه R&D همچنان "گرمتر" (نزدیکتر به موفقیت) شویم، در نهایت به نقطهای میرسیم که مهمترین تصمیمات معماری اتخاذ شدهاند. محصول آن چند کار اساسی را که آن را تعریف میکنند، انجام میدهد، و پایه و اساس برای دهها کار دیگری که باید قبل از عرضه به مشتریان انجام دهیم، گذاشته شده است.
با وجود این ساختار، تیم ارشد میتواند افراد دیگری را برای مشارکت وارد کند. این همان تغییر به حالت Production (تولید) است، جایی که در چرخههای رسمی با فازهای شکلدهی، شرطبندی و ساخت مشخص کار میکنیم. حالت Production مانند کار بر روی یک محصول موجود است: سابقه تعیین شده توسط کار R&D به مشارکتکنندگان جدید امکان میدهد تا تشخیص دهند که عملکرد جدید در کجا قرار میگیرد و چگونه با کل سیستم هماهنگ میشود.
• شکلدهی دوباره عمدی است. کار شکلدهی شده آنچه را که انتظار داریم در پایان چرخه ببینیم، توصیف میکند.
• تیمی که پروژهها را میسازد دیگر به گروه ارشد محدود نمیشود. امکان شرطبندی (تخصیص زمان و منابع) بر روی چندین تیم به طور موازی (اگر در دسترس باشند) و پوشش دادن زمینههای بیشتر فراهم میشود.
• عرضه (shipping) هدف است، نه اسپایکینگ (spiking). اما چون محصول هنوز به صورت عمومی برای مشتریان در دسترس نیست، "عرضه" را متفاوت تعریف میکنیم. عرضه به معنای ادغام (merging) در پایگاه کد (codebase) اصلی و انتظار عدم نیاز به تغییر مجدد آن است.
از آنجایی که ما در پایان هر چرخه به مشتریان چیزی عرضه نمیکنیم، گزینه حذف قابلیتها از نسخه نهایی قبل از راهاندازی را حفظ میکنیم. این بدان معناست که ما هنوز میتوانیم تجربی عمل کنیم. میتوانیم شش هفته را برای یک قابلیت شرطبندی (تخصیص زمان) کنیم بدون اینکه بدانیم آیا آن را در محصول نهایی میخواهیم یا خیر. این مشکلی نیست تا زمانی که انتظارات را برای تیم ساخت تنظیم کنیم: ما نمیتوانیم پیشبینی کنیم که در نسخه نهایی چه چیزی میخواهیم، و حاضریم این چرخه را به خطر بیندازیم تا بهترین تلاش خود را برای ایده انجام دهیم.
در مرحله نهایی قبل از راهاندازی محصول جدید، ما تمام ساختار را کنار میگذاریم. ما این را حالت Cleanup (پاکسازی) مینامیم. این یک حالت بیقید و بند است (free-for-all). ما به اندازه کافی محصولات جدید ساختهایم تا یاد بگیریم که همیشه چیزهایی هستند که فراموش میکنیم، چیزهایی که از دست میدهیم، جزئیاتی که درست نیستند، و باگهایی که در طول چرخههای R&D و Production نفوذ میکنند.
چیزی در مورد قرار دادن انگشت روی دکمه راهاندازی وجود دارد که مو را به تن سیخ میکند. همه چیز ناگهان "واقعی" میشود. چیزهایی که قبلاً نادیده میگرفتیم، با اهمیت جدیدی برایمان خودنمایی میکنند.
به همین دلیل ما مقداری ظرفیت را در انتها برای موارد پیشبینی نشده در نظر میگیریم. در حالت Cleanup:
• هیچ شکلدهیای (shaping) وجود ندارد. این چرخه از نظر ماهیت به "حل سریع اشکالات" (bug smash) که در فصل قبلی ذکر شد، نزدیکتر است. رهبری در طول چرخه در رأس کار قرار میگیرد، توجه را به آنچه مهم است جلب میکند و حواسپرتیها را از بین میبرد.
• مرزهای تیمی مشخصی وجود ندارد. همه برای کمک هر طور که میتوانند، وارد عمل میشوند.
• کار به طور مداوم و در کوچکترین قطعات ممکن "عرضه" (به پایگاه کد اصلی ادغام) میشود.
انضباط همچنان مهم است. ما باید خودمان را کنترل کنیم تا مطمئن شویم روی موارد ضروری (must-have) کار میکنیم، نه فقط روی تردیدهایمان که ما را به تأخیر در راهاندازی ترغیب میکنند. Cleanup نباید بیشتر از دو چرخه طول بکشد.
Cleanup همچنین مرحلهای است که رهبری تصمیمات "نسخه نهایی" را میگیرد. سطح (surface area) کوچکتر در یک V1 (نسخه اول) به معنای سوالات کمتر برای پاسخگویی، پشتیبانی کمتر، و تعهد کمتر برای نگهداری نامحدود است. گاهی اوقات لازم است همه قابلیتها را به صورت یکپارچه ببینیم تا قضاوت کنیم که بدون چه چیزی میتوانیم زندگی کنیم و چه چیزی ممکن است قبل از عرضه به مشتریان نیاز به بررسی عمیقتر داشته باشد.
ما تقویم Dot Grid (به فصل 2 مراجعه کنید) را برای Basecamp، که یک محصول موجود است، ساختیم. پروژه را شکلدهی کردیم، شش هفته برای آن شرطبندی (تخصیص زمان) کردیم، یک تیم آن را ساخت، و سپس مستقیماً آن را به مشتریان عرضه کردیم.
در سال 2020، پس از دو سال توسعه، یک اپلیکیشن و سرویس ایمیل جدید به نام HEY را راهاندازی کردیم. HEY برای سال اول توسعه خود در حالت R&D قرار داشت. تیمی متشکل از سه نفر، جیسون (CEO)، دیوید (CTO) و یوناس (طراح ارشد)، طیف گستردهای از ایدهها را قبل از استقرار بر روی هسته اصلی بررسی کردند. نزدیک به یک سال چرخههای حالت Production (تولید) دنبال شد، جایی که تمام تیمهای Basecamp مجموعه قابلیتهای HEY را تکمیل کردند. ما با دو چرخه Cleanup (پاکسازی) به پایان رسیدیم و به طور قابل توجهی مجموعه قابلیتها را برای راهاندازی در جولای 2020 کاهش دادیم.
به طور دقیق، همپوشانی بین حالت R&D و Production پس از آن سال اول وجود داشت. Basecamp به اندازه کافی شرکت بزرگی بود که تیم ارشد میتوانست پروژههای حالت Production را در بخشهایی از برنامه که تثبیت شده بودند، شکلدهی و واگذار کند، در حالی که خودشان به کشف قلمروهای جدید در حالت R&D ادامه میدادند.
هر شرطبندی (تخصیص زمان و منابع) بر روی HEY به صورت تک به تک انجام شد. "میز شرطبندی" (گروه تصمیمگیرنده) در طول آن چند چرخه اولیه R&D نمیدانست که قرار است دو سال روی HEY کار کند. به تدریج آنها اعتماد به نفس در ایده پیدا کردند و "اشتهای" (میل و تمایل به سرمایهگذاری) بزرگتری برای اینکه چند چرخه حاضرند روی HEY صرف کنند، پیدا کردند. اما هیچ تعهد مشخصی در مورد آنچه در آن چرخهها قرار میگرفت، ندادند. و برگرداندن توجه به Basecamp، محصول موجود ما، همیشه روی میز بود.
مثال سوم یک منطقه خاکستری را نشان میدهد. وقتی قابلیت Hill Charts را در Basecamp ساختیم (به فصل 13 مراجعه کنید)، هیچ ایدهای نداشتیم که آیا کارساز خواهد بود یا خیر. Basecamp یک محصول موجود بود، و شرطبندی (تخصیص زمان و منابع) بر روی عرضه این قابلیت آزمایشی به مشتریان، بیش از حد خطرناک به نظر میرسید. بنابراین پروژه را بیشتر شبیه یک شرطبندی (تخصیص) در حالت Production بر روی یک محصول جدید چارچوببندی کردیم. ما یک نسخه اولیه را شکلدهی کردیم که فقط به اندازه کافی برای استفاده خودمان کارآمد بود. انتظار نداشتیم آن را بدون انجام یک چرخه اضافی، به مشتریان عرضه کنیم. این یک ریسک بود: ما یک چرخه را شرطبندی (تخصیص) کردیم، نه دو چرخه. اگر کارساز نبود، آن را کنار میگذاشتیم. اگر چیز مهمتری پیش میآمد، ممکن بود هرگز چرخه دوم را برنامهریزی نکنیم. اما در نهایت پس از چرخه اول احساس اطمینان کردیم. پروژهای را برای تکمیل آن شکلدهی کردیم، تصمیم گرفتیم یک چرخه دیگر شرطبندی (تخصیص) کنیم، و سپس آن را به مشتریان عرضه کردیم.
در اینجا برخی از سوالات رایجی که ممکن است از افراد در "میز شرطبندی" (گروه تصمیمگیرنده) بشنوید، زمانی که در مورد اینکه کدام پروژهها را باید انتخاب کرد بحث میکنند، آورده شده است:
درست مانند نگارش pitch (پیشنهاد پروژه)، ما همیشه دقت میکنیم که مشکل و راهحل را از هم جدا کنیم. اگر مشکل ارزش حل کردن نداشته باشد، راهحل مهم نیست.
البته، هر مشکلی که مشتریان را تحت تأثیر قرار دهد، اهمیت دارد. اما ما باید انتخابهایی انجام دهیم زیرا همیشه مشکلات بیشتری نسبت به زمان برای حل آنها وجود خواهد داشت. بنابراین، مشکلات را در برابر یکدیگر میسنجیم. آیا این مشکل در حال حاضر مهمتر از آن مشکل است؟
نحوه قضاوت مشکلات توسط افراد حاضر در "میز" (گروه تصمیمگیرنده) به دیدگاه، نقش و دانش آنها بستگی دارد. به عنوان مثال، یک مشکل ممکن است بخش کوچکی از مشتریان را تحت تأثیر قرار دهد اما بار نامتناسبی را بر پشتیبانی تحمیل کند. بسته به میزان مواجهه شما با پشتیبانی و اینکه بر کدام جنبه از کسبوکار تمرکز دارید، ممکن است این موضوع را متفاوت ارزیابی کنید.
گاهی اوقات یک راهحل که بیش از حد پیچیده یا گسترده است، ممکن است سوالاتی را در مورد مشکل ایجاد کند. آیا واقعاً باید این همه تغییر در سراسر برنامه ایجاد کنیم؟ آیا مشکل را به اندازه کافی دقیق درک کردهایم؟ شاید راهی برای محدود کردن آن وجود داشته باشد تا 80% سود را از 20% تغییر به دست آوریم.
خوب است که ما یک راهحل شکلدهی شده در یک بازه زمانی معقول، مانند دو یا شش هفته، داشته باشیم. اما ممکن است همچنان در مورد اینکه آیا ارزش آن زمان را دارد، بحث کنیم. فرض کنید یک ذینفع (stakeholder) میگوید علاقهای به صرف شش هفته برای یک pitch (پیشنهاد) خاص ندارد. مذاکره میتواند از آنجا به چند جهت پیش برود:
• شاید مشکل به اندازه کافی خوب بیان نشده باشد، و اطلاعاتی وجود دارد که شکلدهنده (shaper) میتواند همین الان به گفتگو اضافه کند تا نظر را تغییر دهد. به عنوان مثال، "بله، اغلب اتفاق نمیافتد، اما وقتی اتفاق میافتد، مردم به قدری در مورد آن صحبت میکنند که واقعاً وجهه ما را خدشهدار میکند." یا "شاید پیش پا افتاده به نظر برسد، اما پشتیبانی باید 11 مرحله زمانبر را طی کند تا به راهحل برسد."
• گاهی اوقات گفتن "نه" به تعهد زمانی، در واقع گفتن نه به چیز دیگری است. شاید چیزی در مورد راهحل یا پیادهسازی فنی وجود دارد که آنها دوست ندارند. پرسیدن "اگر میتوانستیم آن را در دو هفته انجام دهیم چه حسی داشتید؟" میتواند نشان دهد که مسئله آنقدرها هم به زمان مربوط نیست. CTO ممکن است پاسخ دهد، "من نمیخواهم وابستگی دیگری را به آن بخش از برنامه وارد کنم."
• اگر علاقه خیلی کم باشد، شکلدهنده (shaper) ممکن است ایده را رها کند.
• شکلدهنده (shaper) ممکن است به میز طراحی (drawing table) بازگردد و یا روی یک نسخه کوچکتر (برای اشتهای کمتر) کار کند و یا تحقیقات بیشتری انجام دهد اگر معتقد است مشکل قانعکننده است اما به اندازه کافی برای ارائه آن آماده نبوده است.
آیا راهحل جذاب است؟
ممکن است مشکل مهم و "اشتها" (زمان و منابع تخصیصیافته) نیز مناسب باشد، اما درباره راهحل اختلافنظر وجود داشته باشد.
به عنوان مثال، اضافه کردن عناصر رابط کاربری به صفحه، هزینهای نامرئی دارد: از دست دادن "فضای واقعی" (real estate). یک دکمه در گوشه صفحه اصلی ممکن است مشکل را کاملاً حل کند. اما آن فضای واقعی ارزشمند است. اگر اکنون آن را واگذار کنیم، در آینده نمیتوانیم از آن استفاده کنیم. آیا ما آن را برای حل این مشکل خاص خیلی ارزان میفروشیم؟
اگر کسی یک راهحل طراحی فوری ارائه دهد، مانند "چطور است آن دکمه را به جای آن به یک منوی اقدام منتقل کنیم،" ممکن است در مورد آن بحث کنیم. اما به طور کلی، ما از انجام کارهای طراحی یا بحث در مورد راهحلهای فنی برای بیش از چند لحظه در "میز شرطبندی" (گروه تصمیمگیرنده) اجتناب خواهیم کرد. اگر متوجه شویم که بیش از حد در جزئیات (in the weeds) وقت میگذرانیم، به خودمان یادآوری میکنیم "خب، ما اینجا طراحی نمیکنیم" و به سطح بالا بازمیگردیم.
آیا زمان مناسب است؟
نوع پروژهای که میخواهیم در مرحله بعد انجام دهیم، میتواند به پروژههایی که اخیراً انجام دادهایم بستگی داشته باشد. شاید مدت زیادی است که با یک قابلیت جدید، خبری مهمی منتشر نکردهایم. یا شاید قابلیتهای جدید زیادی ساختهایم و احساس میکنیم که زمان رفع برخی درخواستهای مشتریان دیرینه فرا رسیده است. یا اگر تیمها دو چرخه اخیر را در یک بخش از برنامه گذراندهاند، اگر ما پروژه دیگری از همان نوع کار را برنامهریزی کنیم، روحیه آنها ممکن است افت کند.
همه اینها دلایلی هستند که ممکن است یک پروژه را رد کنیم، حتی اگر به خوبی شکلدهی شده و ارزشمند باشد. پروژه عالی است؛ فقط زمان مناسب نیست.
آیا افراد مناسب در دسترس هستند؟
به عنوان بخشی از فرآیند شرطبندی (تخصیص زمان و منابع)، ما به طور خاص انتخاب میکنیم که چه کسی چه نقشی را در هر تیم ایفا خواهد کرد. یعنی، یک پروژه را با یک تیم کوچک خاص متشکل از یک طراح و یک یا دو برنامهنویس جفت میکنیم. ما یک تیم "محصول اصلی" (Core Product) متشکل از طراحان و برنامهنویسان داریم و هنگام برنامهریزی تیمها برای هر چرخه از آن مجموعه انتخاب میکنیم. تیم برای کل چرخه با یکدیگر کار خواهد کرد و سپس چرخه بعدی میتواند ترکیبی متفاوت از افراد باشد.
پروژههای مختلف به تخصصهای متفاوتی نیاز دارند. شاید برای این یکی به برنامهنویسی فرانتاند (front-end) بیشتری نیاز داشته باشیم. یا این یکی دیگر قرار است باعث "افزایش دامنه" (scope creep) زیادی شود، بنابراین به کسی نیاز داریم که در "محدود کردن دامنه" (scope hammer) خوب باشد.
نوع کاری که هر شخص انجام داده است نیز عامل دیگری است. کسی که رشته طولانی از پروژههای "بچ کوچک" (small batch) را انجام داده است، ممکن است ترجیح دهد یک "بچ بزرگ" (big batch) را به عهده بگیرد، یا برعکس.
و در نهایت، همیشه کمی "تقویم تتریس" (Calendar Tetris - برنامهریزی پیچیده بر اساس زمانبندی افراد) با در دسترس بودن افراد وجود دارد. تعطیلات یا مرخصیهای بلندمدت (sabbaticals) بر پروژههایی که میتوانیم در چرخه آینده برنامهریزی کنیم، تأثیر میگذارد.
ما دیدهایم که برخی شرکتهای دیگر از مدلی متفاوت استفاده میکنند که به جای اختصاص پروژهها به افراد، به اعضای تیم اجازه میدهند پروژههایی را که میخواهند روی آنها کار کنند، انتخاب کنند. از نظر فرهنگی، ما بیش از حد از جلسات گریزان هستیم که این مرحله اضافی را انجام دهیم. اما شنیدهایم که برای برخی تیمها میتواند به خوبی کار کند زیرا تیمهای پروژه کمی بیشتر "با انگیزه" (buy-in) هستند.
پیام شروع را منتشر کنید
پس از انجام شرطبندیها (تصمیمگیریها)، یکی از اعضای "میز شرطبندی" (گروه تصمیمگیرنده) پیامی مینویسد که به همه میگوید برای چرخه بعدی روی کدام پروژهها شرطبندی کردهایم و چه کسانی روی آنها کار خواهند کرد.
تصویر: جیسون (Jason) تصمیمات گرفته شده برای چرخهی بعدی را با یک پیام Basecamp اعلام میکند.
