حالا که یک پیشنهاد (pitch) نوشتیم، کجا میرود؟ به بکلاگ (backlog) نمیرود.
بکلاگها بار سنگینی هستند که نیازی به حمل آنها نداریم. دهها و در نهایت صدها تسک (task) روی هم انباشته میشوند که همه میدانیم هرگز برای آنها وقت نخواهیم داشت. انباشته شدن فزاینده آنها به ما احساسی میدهد که گویی همیشه عقب هستیم، در حالی که اینطور نیست. فقط به این دلیل که کسی یک ایده را سه ماه پیش مهم میدانست، به این معنی نیست که باید بارها و بارها به آن نگاه کنیم.
بکلاگها اتلافکنندههای بزرگ زمان نیز هستند. زمانی که صرف بازبینی، سازماندهی و پالایش مداوم ایدههای قدیمی میشود، همه را از پیشرفت در پروژههای به موقع که واقعاً اکنون اهمیت دارند، بازمیدارد.
پس به جای آن چه کار میکنیم؟ قبل از هر چرخه شش هفتهای، یک میز شرطبندی (betting table) برگزار میکنیم که در آن ذینفعان (stakeholders) تصمیم میگیرند در چرخه بعدی چه کاری انجام دهند. در میز شرطبندی، آنها به پیشنهادهایی (pitches) از شش هفته گذشته نگاه میکنند — یا هر پیشنهادی که کسی عمداً آن را احیا کرده و دوباره برای آن لابی کرده باشد.
چیز دیگری روی میز نیست. هیچ لیست غولآسایی از ایدهها برای بازبینی وجود ندارد. هیچ زمانی صرف سازماندهی یک بکلاگ از ایدههای قدیمی نمیشود. تنها چند گزینه خوب شکلگرفته و کمریسک برای بازبینی وجود دارد. پیشنهادها، شرطبندیهای بالقوه هستند.
با وجود تنها چند گزینه و یک چرخه شش هفتهای، این جلسات کمتعداد، کوتاه و به شدت پربار هستند.
اگر تصمیم بگیریم روی یک پیشنهاد شرطبندی کنیم، آن وارد چرخه بعدی برای ساخت میشود. اگر این کار را نکنیم، آن را رها میکنیم. چیزی برای پیگیری یا نگه داشتن نداریم.
اگر پیشنهاد عالی بود، اما زمان مناسب نبود چه؟ هر کسی که میخواهد دوباره از آن حمایت کند، به سادگی آن را به طور مستقل — به شیوه خود — پیگیری میکند و سپس شش هفته بعد برای آن لابی میکند.
ما مجبور نیستیم بین یک بکلاگ پرزحمت و به خاطر نسپردن هیچ چیز از گذشته، یکی را انتخاب کنیم. هر کسی همچنان میتواند پیشنهادها (pitches)، باگها (bugs)، درخواستها یا کارهایی را که میخواهد انجام دهد، به طور مستقل و بدون یک بکلاگ مرکزی پیگیری کند.
• تیم پشتیبانی میتواند لیستی از درخواستها یا مسائلی که بیشتر از بقیه پیش میآیند، نگه دارد.
• تیم محصول ایدههایی را پیگیری میکند که امیدوارند در چرخههای آتی بتوانند آنها را شکل دهند.
• برنامهنویسان لیستی از باگهایی را که مایلند در صورت داشتن وقت، آنها را رفع کنند، نگهداری میکنند.
هیچ بکلاگ یا لیست مرکزی واحدی وجود ندارد و هیچ یک از این لیستها ورودی مستقیم به فرآیند شرطبندی (betting process) نیستند.
جلسات منظم اما کمتعداد یک به یک (one-on-one) بین دپارتمانها به تبادل ایدهها (cross-pollinate) برای کارهای بعدی کمک میکند. به عنوان مثال، پشتیبانی میتواند به تیم محصول درباره مسائل اصلی که مشاهده میکنند، اطلاع دهد، که تیم محصول سپس میتواند آن را به طور مستقل به عنوان پروژههای بالقوه برای شکلدهی پیگیری کند. شاید تیم محصول تنها یکی از آن مسائل اصلی را برای کار در حال حاضر انتخاب کند. سپس، در یک جلسه یک به یک آتی، پشتیبانی میتواند دوباره برای چیزی که هنوز توجهی به آن نشده، لابی کند.
این رویکرد مسئولیت اولویتبندی و پیگیری کارها را پخش میکند و آن را قابل مدیریت میسازد. افراد از دپارتمانهای مختلف میتوانند از هر چیزی که به نظرشان مهم است دفاع کنند و از هر روشی که برایشان کارآمد است برای پیگیری آن چیزها استفاده کنند — یا نکنند. به این ترتیب گفتگو همیشه تازه است. هر چیزی که بازگردانده میشود، با یک زمینه (context)، توسط یک شخص و با یک هدف بازگردانده میشود. همه چیز مرتبط، به موقع و مربوط به لحظه است.
اغراق در ارزش ایدهها آسان است. حقیقت این است که ایدهها ارزان هستند. آنها همیشه ظاهر میشوند و به صورت انبوه جمع میشوند.
ایدههای واقعاً مهم به شما بازخواهند گشت. آخرین باری که یک ایده واقعاً عالی و الهامبخش را فراموش کردید، کی بود؟ و اگر خیلی جالب نباشد — شاید یک باگ (bug) که مشتریان گهگاه با آن مواجه میشوند — زمانی که مشتری دوباره شکایت کند یا مشتری جدیدی به آن برخورد کند، دوباره به توجه شما بازخواهد گشت. اگر آن را یک بار بشنوید و دیگر هرگز نشنوید، شاید واقعاً مشکلی نبوده است. و اگر مدام درباره آن بشنوید، انگیزه پیدا میکنید تا راه حلی برای آن شکل دهید و برای زمان شرطبندی (betting time) روی آن در چرخه بعدی، پیشنهاد دهید.
