حالا که تعدادی شرطبندی (bets) بالقوه خوب در قالب «پیشنهاد» (pitches) داریم، زمان آن رسیده است که در مورد اینکه کدام پروژهها را برنامهریزی کنیم، تصمیم بگیریم.
تعهد دادن زمان و نیروی انسانی دشوار است اگر نتوانیم به راحتی تعیین کنیم چه کسی و برای چه مدت در دسترس است. هنگامی که افراد به دلیل پروژههای همپوشاننده در زمانهای مختلفی در دسترس هستند، برنامهریزی پروژه به یک بازی آزاردهنده «تتریس تقویمی» (Calendar Tetris) تبدیل میشود. کار کردن در چرخهها این مشکل را به شدت ساده میکند. یک چرخه به ما یک اندازه استاندارد برای پروژه، هم برای شکلدهی (shaping) و هم برای برنامهریزی (scheduling) میدهد.
برخی شرکتها از چرخههای دو هفتهای (که به آنها "اسپرینت" (sprints) نیز میگویند) استفاده میکنند. ما دریافتیم که دو هفته برای انجام هر کار معناداری خیلی کوتاه است. بدتر از آن، چرخههای دو هفتهای به دلیل سربار (overhead) برنامهریزی، فوقالعاده پرهزینه هستند. میزان کاری که در دو هفته انجام میدهید، ارزش ساعتهای جمعی صرف شده در اطراف میز برای "برنامهریزی اسپرینت" یا هزینه فرصت (opportunity cost) شکستن شتاب (momentum) همه برای تجدید قوا را ندارد.
این ما را به امتحان چرخههای طولانیتر سوق داد. ما چرخهای میخواستیم که به اندازه کافی طولانی باشد تا یک پروژه کامل، از ابتدا تا انتها، به پایان برسد. در عین حال، چرخهها باید به اندازهای کوتاه باشند که بتوان پایان را از ابتدا دید. افراد نیاز دارند احساس کنند که ضربالاجل (deadline) در حال نزدیک شدن است تا بتوانند تعویضها (trade-offs) را انجام دهند. اگر ضربالاجل در ابتدا خیلی دور و انتزاعی باشد، تیمها به طور طبیعی سرگردان میشوند و زمان را به طور ناکارآمدی استفاده میکنند تا زمانی که ضربالاجل شروع به نزدیک شدن و واقعی شدن کند.
پس از سالها آزمایش، ما به شش هفته رسیدیم. شش هفته به اندازه کافی طولانی است تا کاری معنادار را به پایان برسانیم و هنوز هم به اندازه کافی کوتاه است تا بتوانیم پایان را از ابتدا ببینیم.
اگر چرخههای شش هفتهای را پشت سر هم اجرا میکردیم، هیچ زمانی برای نفس کشیدن و فکر کردن درباره کارهای بعدی وجود نداشت. پایان یک چرخه بدترین زمان برای ملاقات و برنامهریزی است؛ زیرا همه بیش از حد مشغول نهایی کردن پروژهها و گرفتن تصمیمات دقیقه آخری برای ارسال به موقع هستند.
بنابراین، پس از هر چرخه شش هفتهای، ما دو هفته را برای cool-down برنامهریزی میکنیم. این دورهای است که هیچ کار برنامهریزی شدهای ندارد و در آن میتوانیم نفس بکشیم، در صورت نیاز ملاقات کنیم و در مورد کارهای بعدی فکر کنیم.
در طول cool-down، برنامهنویسان و طراحان در تیمهای پروژه آزادند که روی هر چیزی که میخواهند کار کنند. پس از تلاش سخت برای ارسال پروژههای شش هفتهای خود، آنها از داشتن زمانی که تحت کنترلشان است، لذت میبرند. آنها از این زمان برای رفع باگها (bugs)، کشف ایدههای جدید، یا امتحان کردن امکانات فنی جدید استفاده میکنند.
علاوه بر استانداردسازی طول چرخههایمان، ما نوع پروژهها و تیمهایی را که روی آنها شرطبندی میکنیم نیز تقریباً استاندارد میکنیم.
تیمهای پروژه ما شامل یک طراح و دو برنامهنویس یا یک طراح و یک برنامهنویس هستند. یک نفر QA (کنترل کیفیت) که تستهای یکپارچهسازی (integration testing) را در اواخر چرخه انجام میدهد، به آنها میپیوندد.
این تیمها یا کل چرخه را روی یک پروژه کار خواهند کرد، یا در طول چرخه روی چندین پروژه کوچکتر کار خواهند کرد. تیمی را که کل چرخه را روی یک پروژه میگذراند، تیم "دسته بزرگ" (big batch team) و تیمی را که روی مجموعهای از پروژههای کوچکتر کار میکند، تیم "دسته کوچک" (small batch team) مینامیم. پروژههای دسته کوچک معمولاً هر کدام یک یا دو هفته طول میکشند. پروژههای دسته کوچک به صورت جداگانه برنامهریزی نمیشوند. این به عهده تیم دسته کوچک است که چگونگی مدیریت کار را طوری بیابد که همه آنها قبل از پایان چرخه ارسال شوند.
حالا که یک روش استاندارد برای فکر کردن درباره ظرفیت داریم، میتوانیم در مورد چگونگی تصمیمگیری برای برنامهریزی صحبت کنیم.
میز شرطبندی (The betting table)
میز شرطبندی، جلسهای است که در طول cool-down برگزار میشود و در آن ذینفعان (stakeholders) تصمیم میگیرند در چرخه بعدی چه کاری انجام دهند. شرطبندیهای بالقوه برای بررسی، یا پیشنهادهای جدیدی (new pitches) هستند که در شش هفته گذشته شکل گرفتهاند، یا احتمالاً یک یا دو پیشنهاد قدیمیتر که کسی مشخصاً تصمیم به احیای آنها گرفته است. همانطور که در فصل گذشته گفتیم، هیچ "پاکسازی" (grooming) یا بکلاگ (backlog) برای سازماندهی وجود ندارد. فقط چند گزینه خوب شکلگرفته برای بررسی وجود دارد.
میز شرطبندی ما در Basecamp متشکل از مدیرعامل (CEO) (که در مورد محصول حرف آخر را میزند)، مدیر ارشد فناوری (CTO)، یک برنامهنویس ارشد، و یک استراتژیست محصول (خودم) است.
زمان مدیران ارشد (C-level) فقط در قطعات کوچک در دسترس است، بنابراین فضایی از "وقت را هدر ندهید" حاکم است و جلسه به ندرت بیش از یک یا دو ساعت طول میکشد. همه از قبل فرصت داشتهاند که پیشنهادها را در زمان خود بررسی کنند. گفتگوهای یک به یک (one-on-one) اتفاقی در هفتههای قبل نیز معمولاً مقداری زمینه (context) فراهم میکنند. به محض شروع تماس، همه چیز به بررسی گزینههایی که به میز رسیدهاند و گرفتن تصمیمات مربوط میشود.
خروجی این تماس، یک برنامه چرخه (cycle plan) است. بین همه افراد حاضر، دانش در مورد اینکه چه کسی در دسترس است، اولویتهای کسبوکار کدامند، و اخیراً چه نوع کاری انجام دادهایم، وجود دارد. همه اینها به فرآیند تصمیمگیری درباره اینکه چه کاری انجام شود و چه کسی برنامهریزی شود (در ادامه بیشتر در مورد آن صحبت خواهیم کرد) کمک میکند.
بالاترین افراد در شرکت حضور دارند. هیچ "گام دومی" برای اعتبارسنجی برنامه یا گرفتن تأیید وجود ندارد. و هیچ کس دیگری نمیتواند پس از آن وارد عمل شود تا در کار برنامهریزی شده دخالت یا وقفه ایجاد کند.
این "buy-in" از بالاترین سطوح برای چرخش صحیح چرخهها ضروری است. جلسه کوتاه است، گزینهها به خوبی شکل گرفتهاند و تعداد نفرات کم است. وقتی این معیارها برآورده شوند، میز شرطبندی به مکانی برای اعمال کنترل بر جهت محصول تبدیل میشود، به جای نبردی برای منابع یا درخواستی برای اولویتبندی. با چرخههایی به اندازه کافی طولانی برای پیشرفت معنادار و کاری که به طور واقعبینانه ارسال خواهد شد، میز شرطبندی به مدیران ارشد (C-suite) احساس "کنترل داشتن" را میدهد که از روزهای اولیه نداشتهاند.
ما در مورد "شرطبندی" به جای "برنامهریزی" صحبت میکنیم، زیرا انتظارات متفاوتی را ایجاد میکند.
اول، شرطبندیها پرداخت (payout) دارند. ما فقط یک بازه زمانی (time box) را با وظایف پر نمیکنیم تا پر شود. ما دو هفته را صرف یک قابلیت (feature) نمیکنیم و امیدوار به پیشرفت افزایشی نیستیم. ما عمداً کار را در یک جعبه شش هفتهای شکل میدهیم تا در پایان چیزی معنادار به پایان برسد. "پیشنهاد" (pitch) یک پرداخت مشخص را تعریف میکند که شرطبندی را ارزشمند میکند.
دوم، شرطبندیها تعهد (commitments) هستند. اگر شش هفته شرطبندی کنیم، متعهد میشویم که کل شش هفته را به تیم اختصاص دهیم تا منحصراً روی آن چیز بدون وقفه کار کند. ما سعی نمیکنیم هر ساعت از زمان یک برنامهنویس را بهینه کنیم. ما به حرکت بزرگتر پیشرفت در کل محصول پس از شش هفته نگاه میکنیم.
سوم، یک شرطبندی هوشمند حداکثر ضرر (cap on the downside) دارد. اگر روی چیزی شش هفته شرطبندی کنیم، بیشترین چیزی که میتوانیم از دست بدهیم شش هفته است. ما به خودمان اجازه نمیدهیم وارد وضعیتی شویم که برای چیزی که ارزش آن قیمت را ندارد، چندین برابر تخمین اولیه را صرف کنیم.
بیایید این دو نکته آخر را دقیقتر بررسی کنیم.
اگر بگوییم شش هفته اختصاص میدهیم اما بعد اجازه دهیم یک تیم برای کار روی چیز دیگری کنار گذاشته شود، واقعاً یک شرطبندی نیست.
وقتی شرطبندی میکنید، به آن احترام میگذارید (honor it). ما اجازه نمیدهیم تیم متوقف شود یا برای انجام کارهای دیگر کنار گذاشته شود. اگر افراد با درخواستها تیم را متوقف کنند، تعهد ما شکسته میشود. ما دیگر کل شش هفته را به تیمی که کارش برای شش هفته زمان شکل داده شده بود، نمیدهیم.
وقتی افراد "فقط چند ساعت" یا "فقط یک روز" را درخواست میکنند، فریب نخورید. شتاب (Momentum) و پیشرفت (progress) چیزهای مرتبه دومی هستند، مانند رشد یا شتاب. نمیتوانید آنها را با یک نقطه توصیف کنید. به یک منحنی بیوقفه از نقاط نیاز دارید. وقتی کسی را برای یک روز برای رفع باگ یا کمک به تیمی دیگر کنار میگذارید، فقط یک روز را از دست نمیدهید. شتابی را که آنها ایجاد کرده بودند و زمانی را که برای بازگرداندن آن لازم است، از دست میدهید. از دست دادن ساعت اشتباه میتواند یک روز را از بین ببرد. از دست دادن یک روز میتواند یک هفته را از بین ببرد.
اگر در طول آن شش هفته چیزی پیش آمد چه؟ ما همچنان تیم را متوقف نمیکنیم و تعهد را نمیشکنیم. حداکثر زمانی که باید صبر کنیم، شش هفته است قبل از اینکه بتوانیم روی مشکل یا ایده جدید اقدام کنیم. اگر چرخه بگذرد و آن چیز هنوز مهمترین کار باشد، میتوانیم برای آن چرخه روی آن شرطبندی کنیم. به همین دلیل بسیار مهم است که فقط یک چرخه جلوتر شرطبندی کنیم. این کار گزینههای ما را برای پاسخگویی به این مسائل جدید باز نگه میدارد. و البته، اگر یک بحران واقعی باشد، همیشه میتوانیم ترمز را بکشیم. اما بحرانهای واقعی بسیار نادر هستند.
ما این زمان بیوقفه را با یک سیاست دشوار اما فوقالعاده قدرتمند ترکیب میکنیم. تیمها باید کار را در مدت زمان تعیین شده به پایان برسانند. اگر آنها تمام نکردند، به طور پیشفرض پروژه تمدید نمیشود. ما عمداً یک ریسک ایجاد میکنیم که پروژه — همانطور که پیشنهاد شده بود — اتفاق نخواهد افتاد. این سخت به نظر میرسد اما برای همه افراد درگیر بسیار مفید است.
اول، خطر پروژههای خارج از کنترل را از بین میبرد. ما در ابتدا وقتی پروژه شکل گرفت و پیشنهاد شد، اشتهای خود را تعریف کردیم. اگر پروژه فقط شش هفته ارزش داشت، صرف دو، سه یا ده برابر آن احمقانه خواهد بود. تعداد بسیار کمی از پروژهها از نوع "به هر قیمتی" هستند و باید فوراً اتفاق بیفتند. ما این را مانند یک قطعکننده مدار (circuit breaker) میبینیم که تضمین میکند یک پروژه سیستم را اضافه بار (overload) نمیکند. یک پروژهای که بیش از حد طول میکشد، هرگز ما را متوقف نمیکند یا جلوی پروژههای جدیدی که ممکن است مهمتر باشند را نمیگیرد.
دوم، اگر یک پروژه در شش هفته به پایان نرسد، به این معنی است که ما در مرحله شکلدهی اشتباهی مرتکب شدیم. به جای سرمایهگذاری زمان بیشتر در یک رویکرد بد، قطعکننده مدار ما را وادار میکند تا مشکل را دوباره چارچوببندی کنیم (reframe). میتوانیم از مسیر شکلدهی (shaping track) در شش هفته بعدی برای ارائه یک راهحل جدید یا بهتر استفاده کنیم که از هر "چالشی" (rabbit hole) که در تلاش اول گرفتار آن شدیم، جلوگیری کند. سپس پیشنهاد جدید را در میز شرطبندی بررسی خواهیم کرد تا ببینیم آیا واقعاً شانس موفقیت ما را تغییر میدهد، قبل از اینکه شش هفته دیگر را به آن اختصاص دهیم.
در نهایت، قطعکننده مدار تیمها را تشویق میکند تا مالکیت بیشتری بر پروژههای خود داشته باشند. همانطور که در فصل بعدی خواهیم دید، تیمها مسئولیت کامل اجرای پروژهها را بر عهده میگیرند. این شامل تصمیمگیری در مورد جزئیات پیادهسازی و انتخاب اینکه کجا دامنه (scope) را کاهش دهند میشود. نمیتوانید بدون تصمیمگیریهای دشوار در مورد اینکه کجا متوقف شوید، کجا مصالحه کنید، و چه چیزی را حذف کنید، چیزی را ارسال کنید. یک مهلت سخت و شانس عدم ارسال، تیم را تشویق میکند تا به طور منظم سوال کند که چگونه تصمیمات طراحی و پیادهسازی آنها بر دامنه تأثیر میگذارد.
اگر تیمها در چرخه شش هفتهای متوقف نمیشوند، چگونه با باگهایی که پیش میآیند کنار بیاییم؟
اول باید عقبنشینی کنیم و فرضیات خود را در مورد باگها زیر سوال ببریم.
هیچ چیز خاصی در مورد باگها وجود ندارد که آنها را به طور خودکار از هر چیز دیگری مهمتر کند. صرف اینکه چیزی یک باگ است، به ما بهانهای برای قطع کار خود یا دیگران نمیدهد. تمام نرمافزارها باگ دارند. سوال این است: شدت آنها چقدر است؟ اگر در یک بحران واقعی باشیم – دادهها از بین میروند، برنامه متوقف میشود، یا بخش بزرگی از مشتریان چیز اشتباهی را میبینند – آنگاه همه چیز را رها میکنیم تا آن را رفع کنیم. اما بحرانها نادر هستند. اکثریت قریب به اتفاق باگها میتوانند شش هفته یا بیشتر صبر کنند، و بسیاری از آنها حتی نیازی به رفع شدن ندارند. اگر سعی کنیم هر باگ را از بین ببریم، هرگز تمام نخواهیم شد. اگر مجبور باشید اول تمام دنیا را درست کنید، نمیتوانید چیز جدیدی ارسال کنید.
با این حال، هیچ کس باگ را دوست ندارد. ما همچنان راههایی برای برخورد با آنها میخواهیم. سه استراتژی برای ما کارساز بوده است.
از cool-down استفاده کنید. از هر برنامهنویسی بپرسید که آیا چیزهایی هست که ای کاش میتوانست به عقب برگردد و آنها را درست کند، و آنها لیستی برای نشان دادن به شما خواهند داشت. دوره cool-down بین چرخهها به آنها زمان میدهد تا دقیقاً همین کار را انجام دهند. شش هفته زمان زیادی برای انتظار برای اکثر باگها نیست، و دو هفته در هر شش هفته در واقع به زمان زیادی برای رفع آنها اضافه میشود.
آن را به میز شرطبندی بیاورید. اگر یک باگ برای رفع شدن در طول cool-down خیلی بزرگ باشد، میتواند برای منابع در میز شرطبندی رقابت کند. فرض کنید یک فرآیند بکاند (back-end process) برنامه را کند میکند و یک برنامهنویس میخواهد آن را از یک گام همزمان (synchronous) به یک کار ناهمزمان (asynchronous job) تغییر دهد. برنامهنویس میتواند برای رفع آن استدلال کند و راهحل را در یک پیشنهاد (pitch) شکل دهد. سپس به جای قطع کردن کار دیگر، افراد حاضر در میز شرطبندی میتوانند یک تصمیم عمدی بگیرند. زمان همیشه باید به صورت استراتژیک استفاده شود. تفاوت بزرگی بین تأخیر انداختن در کار دیگر برای رفع یک باگ در مقابل تصمیمگیری از پیش اینکه باگ ارزش زمان صرف شده برای رفع آن را دارد، وجود دارد.
یک "Bug Smash" برنامهریزی کنید. سالی یک بار – معمولاً در حدود تعطیلات – ما یک چرخه کامل را به رفع باگها اختصاص میدهیم. ما آن را "Bug Smash" مینامیم. تعطیلات زمان خوبی برای این کار است زیرا انجام یک پروژه عادی دشوار است وقتی افراد در سفر هستند یا مرخصی میگیرند. تیم میتواند به صورت خودسازماندهنده (self-organize) عمل کند تا مهمترین باگها را انتخاب کرده و مسائل طولانیمدت در فرانتاند (front-end) یا بکاند را حل کند.
کلید مدیریت ظرفیت، دادن یک سطح پاک به خود در هر چرخه است. این به معنای فقط شرطبندی یک چرخه در هر بار و هرگز منتقل نکردن تکههای کار قدیمی بدون اینکه ابتدا آنها را شکل داده و به عنوان یک شرطبندی بالقوه جدید در نظر بگیریم، است.
حداکثرسازی گزینههای ما در آینده بسیار حیاتی است. ما نمیدانیم در شش هفته آینده چه اتفاقی خواهد افتاد. ما نمیدانیم چه ایده درخشانی ظاهر خواهد شد یا چه درخواست فوری ممکن است پدیدار شود.
حتی اگر نوعی نقشه راه (road map) در ذهنمان در مقیاس زمانی بالاتر از چرخهها داشته باشیم، آن را در ذهنمان و در بحثهای فرعی (side-channel discussions) نگه میداریم. هر شش هفته ما میآموزیم که چه چیزی کار میکند و چه چیزی کار نمیکند، چه چیزی مهم است و چه چیزی نیست. نگه داشتن گزینه باز هیچ ضرری ندارد و از در دسترس بودن برای اقدام بر روی چیزهای غیرمنتظره سود کلانی به دست میآید.
در مورد پروژههایی که نمیتوانند در یک چرخه انجام شوند چه؟ در آن صورت ما همچنان فقط شش هفته در هر بار شرطبندی میکنیم. فرض کنید ما قابلیتی را تصور میکنیم که دو چرخه طول میکشد تا ارسال شود. ما ریسک خود را با شکلدهی یک هدف شش هفتهای مشخص، با چیزی که کاملاً ساخته شده و در پایان آن شش هفته کار میکند، به شدت کاهش میدهیم. اگر اینطور که انتظار میرود پیش رفت، احساس خوبی خواهیم داشت که شش هفته بعدی را همانطور که در ذهنمان تصور کرده بودیم، شرطبندی کنیم. اما اگر اینطور نشد، میتوانیم پروژه بسیار متفاوتی را تعریف کنیم. یا میتوانیم کار چند چرخهای را متوقف کنیم و کار فوری که پیش آمده را انجام دهیم. نکته مهم این است که ما همیشه مشخص میکنیم که پایان آن چرخه چگونه به نظر میرسد و گزینههای خود را برای تغییر مسیر باز نگه میداریم.
