به یاد داشته باشید که ما کار را برای یک بازه زمانی مشخص (fixed time window) شکل میدهیم. ممکن است از تجربه خود اطمینان داشته باشیم که عناصری که در فصل قبلی به آنها پرداختیم، در محدوده "اشتها" یا "بازه" (شش هفته) قابل ساخت هستند. اما باید دقیقتر نگاه کنیم، چون تنها یک نقص در مفهوم (hole in the concept) میتواند کل پروژه را از مسیر خارج کند. فرض کنید روی پروژه شرطبندی میکنیم و یک تیم آن را به عهده میگیرد. اگر آنها با یک مشکل پیشبینی نشده (unanticipated problem) روبرو شوند که حل آن دو هفته طول بکشد، یک سوم از بودجه را از دست دادهاند!
حتی بدتر، گاهی اوقات با مشکلاتی روبرو میشوید که نه تنها پروژه را به تأخیر میاندازند، بلکه راهحل مشخصی هم ندارند. ما یک بار روی پروژهای شرطبندی کردیم تا نحوه نمایش پروژهها به مشتریان در صفحه اصلی Basecamp را بازطراحی کنیم. ما فرض کردیم طراح آن را حل خواهد کرد؛ در فاز شکلدهی (shaping phase) کاری نکردیم تا تأیید کنیم که یک رویکرد عملی (viable approach) وجود دارد. وقتی پروژه شروع شد، معلوم شد که مشکل بسیار سختتر از آن چیزی بود که انتظار داشتیم. هیچکدام از ما نتوانستیم یک راهحل طراحی مناسب را در شش هفتهای که بودجهبندی کرده بودیم، پیدا کنیم. در نهایت مجبور شدیم پروژه را رها کرده و بعداً دوباره در مورد آن فکر کنیم.
البته همیشه ناشناختههایی وجود خواهند داشت. به همین دلیل است که ما بسیاری از روشهای بخش سه را به کار میگیریم تا تیمها مشکلات صحیح را به ترتیب صحیح حل کنند و فضایی برای موارد پیشبینی نشده باقی بگذارند. اما این به این معنی نیست که نباید به دنبال دامهایی (pitfalls) باشیم که میتوانیم از قبل پیدا کنیم و آنها را قبل از شرطبندی روی پروژه از بین ببریم. قبل از اینکه یک پروژه شکلگرفته را برای شرطبندی ایمن تلقی کنیم، باید تا حد امکان عاری از نقص (free of holes) باشد.
از نظر ریسک، یک کار به خوبی شکلگرفته (well-shaped work) شبیه یک توزیع احتمال باریکدُم (thin-tailed probability distribution) به نظر میرسد. شانس کمی وجود دارد که یک هفته بیشتر طول بکشد، اما فراتر از آن، عناصر راهحل به اندازه کافی تعریف شده و آشنا هستند که دلیلی برای طولانیتر شدن آن وجود ندارد.
با این حال، اگر در مرحله شکلدهی (shaping) هر گونه Rabbit Hole (مشکلات پیچیده و عمیق) وجود داشته باشد – ناشناختههای فنی، مشکلات طراحی حل نشده، یا وابستگیهای متقابل بدفهمیده شده – پروژه میتواند چندین برابر زمان اولیه مورد انتظار طول بکشد تا تکمیل شود. در این حالت، دم سمت راست نمودار کشیده میشود.
ما میخواهیم ناشناختهها و مشکلات دشوار را از پروژه حذف کنیم تا توزیع احتمال ما تا حد امکان باریکدُم باشد. این به معنای پروژهای است با بخشهای مستقل و به خوبی درک شده که به روشهای شناخته شدهای با هم ترکیب میشوند.
پرداختن به جزئیات عناصر راهحل، یک فرآیند سریع و اکتشافی بود. بیشتر جنبه وسعت را داشت تا عمق. در این مرحله، ما سرعت را کم میکنیم و به صورت انتقادی به آنچه ارائه کردهایم نگاه میکنیم. آیا چیزی را از قلم انداختهایم؟ آیا فرضیات فنیای داریم که منطقی نیستند؟
یکی از راههای تجزیه و تحلیل راهحل این است که یک مورد استفاده (use case) را به صورت حرکت آهسته بررسی کنیم. با توجه به راهحلی که طراحی کردهایم، کاربر دقیقاً چگونه از نقطه شروع به نقطه پایان میرسد؟ کند کردن و اجرای این سناریو میتواند شکافها یا بخشهای گمشدهای را که نیاز به طراحی دارند، آشکار کند.
سپس باید قابلیت اجرایی هر بخشی را که فکر میکنیم حل کردهایم، زیر سوال ببریم. از خودمان سوالاتی میپرسیم مانند:
• آیا این کار نیازمند تلاش فنی جدیدی است که قبلاً هرگز انجام ندادهایم؟
• آیا در مورد نحوه کنار هم قرار گرفتن اجزا فرضیاتی داریم؟
• آیا فرض میکنیم یک راهحل طراحی وجود دارد که خودمان نتوانستهایم آن را ارائه دهیم؟
• آیا تصمیم دشواری وجود دارد که باید از قبل آن را مشخص کنیم تا تیم را به مشکل نیندازد؟
به عنوان مثال، زمانی که پروژه "To-Do Groups" را تعریف کردیم، ایده جداکنندهها (dividers) را در فهرست کارها معرفی کردیم:
ما ایده جداکنندهها را دوست داشتیم و منطق "Loose" در مقابل "Grouped" برای ما قابل درک بود. اما وقتی دقیقتر نگاه کردیم، متوجه شدیم که به نحوه نمایش آیتمهای تکمیل شده (completed items) نپرداختهایم. در طراحی موجود، چند آیتم آخر تکمیل شده در زیر لیست نمایش داده میشدند. آیا اکنون باید آیتمهای تکمیل شده را به جای انتهای لیست، در انتهای هر گروه رندر کنیم؟ یا باید نمایش آیتمهای تکمیل شده را در پایین لیست ادامه دهیم و همان مجموعه جداکنندهها را در بخش آیتمهای تکمیل شده تکرار کنیم؟ آیا باید نحوه رسیدگی به آیتمهای تکمیل شده را به طور کامل بازنگری کنیم؟
این یک نقص در مفهوم (hole in the concept) بود. اگر به آن نمیپرداختیم، یک مشکل طراحی عمیق را به تیم منتقل میکردیم و به طور غیرمنطقی از آنها میخواستیم که راهحلی تحت فشار ضربالاجل پیدا کنند. مسئولانه نیست که یک گره درهمتنیدهای از وابستگیهای متقابل را به تیم بدهید و سپس از آنها بخواهید که آن را در یک بازه زمانی کوتاه و مشخص باز کنند.
ما از تجربه میدانستیم که تغییر نحوه رندر شدن کارهای تکمیل شده (completed to-dos) پیامدهای پیچیدهای در تجربه کاربری (UX)، مسیریابی (navigation) و عملکرد (performance) دارد. برای از بین بردن عدم قطعیت در پروژه، تصمیم گرفتیم یک راهحل را در مفهوم شکلگرفته دیکته کنیم. ما آیتمهای تکمیل شده را دقیقاً همانطور که قبلاً کار میکردند، باقی میگذاشتیم. به جای گروهبندی یا تقسیمبندی آنها، فقط نام گروه را به هر آیتم تکمیل شده اضافه میکردیم. این شاید کمی نامرتب به نظر میرسید، اما ما این بدهبستان (trade-off) را توجیه کردیم: این کار مشکل را به شدت ساده میکرد و ما همچنان میتوانستیم آیتمهای تکمیل شده یک گروه را در صفحه جزئیات گروه نمایش دهیم.
این از آن دست بدهبستانهایی است که وقتی تحت فشار در حال کار در چرخه هستید، تصمیمگیری در مورد آن دشوار است. دلایل زیادی وجود دارد که چرا یک طراحی متفاوت یا بازنگری عمیقتر در مورد کارهای تکمیل شده میتواند به صورت عینی بهتر باشد. چرا امتحان نکنیم که آنها را در هر گروه رندر کنیم؟ یک طراح ممکن است به درستی فکر کند: "شاید اگر کمی بیشتر با سبکبندیها آزمایش کنم، بتوانم آنها را بهتر ترکیب کنم". آنها به راحتی میتوانند چند روز از چند هفتهی کمی که در اختیار دارند را در یک بنبست هدر دهند.
به عنوان شکلدهنده (shapers)، ما کمتر به طراحی نهایی و بیشتر به کیفیت اساسی و ریسک فکر میکنیم. با مفهوم سازشیافته (compromised concept)، ما تمام عناصری را که پروژه را ارزشمند میکردند – یعنی گروههای آیتمهای ناتمام – حفظ میکنیم و بخش بزرگی از ریسک را از بین میبریم.
در مرحله بعدی، هنگامی که طرح اولیه (pitch) این پروژه را مینویسیم، این "وصله" (patch) خاص را به عنوان بخشی از مفهوم برجسته خواهیم کرد. به این ترتیب، هیچ کس در مراحل بعدی درگیر آن نخواهد شد.
از آنجایی که همه اعضای تیم میخواهند بهترین کار خود را انجام دهند، البته به دنبال پوشش تمام موارد استفاده (use cases) خواهند بود و آنها را ضروری تلقی میکنند. با افزایش آشنایی تیم با کنترل دامنه (scope hammering) (به بخش "تصمیم بگیرید چه زمانی متوقف شوید" مراجعه کنید)، این موضوع بهبود مییابد. اما هنوز هم ایده خوبی است که مواردی را که صراحتاً پشتیبانی نمیکنید، مشخص کنید تا پروژه کاملاً در محدوده "اشتها" (بازه زمانی) باقی بماند.
برای مثال، ما روی ایدهای برای اطلاعرسانی به گروههایی از افراد در Basecamp کار کردیم. به جای انتخاب تیک پنج برنامهنویس به صورت تک به تک، میتوانستید فقط روی "Programmers" کلیک کنید و آنها برای اطلاعرسانی انتخاب میشدند. همانطور که به محصول نگاه کردیم، مکانهای زیادی را دیدیم که این نوع رفتار ممکن است منطقی باشد. اگر به شما اجازه میدهیم هنگام ارسال پیام یک گروه را انتخاب کنید، چرا هنگام اختصاص یک کار (to-do) یا منشن کردن افراد در اتاق چت این امکان نباشد؟
ما برای هدف این پروژه تصمیم گرفتیم که ارزش اصلی، محدود کردن افرادی بود که باید در مورد یک پیام مطلع شوند. ما صراحتاً موارد دیگر را به عنوان "خارج از محدوده (out of bounds)" برای پروژه مشخص کردیم و بر روی هدفی که میخواستیم تمرکز کردیم: یک جریان سریعتر برای ارسال پیام.
ممکن است بخشهایی از راهحل وجود داشته باشند که در مرحله طراحی اولیه (sketching phase) درباره آنها هیجانزده شدیم اما واقعاً ضروری نیستند. هنگامی که ویژگی "To-Do Groups" را طراحی کردیم، فکر کردیم که کدگذاری رنگی گروهها (color-code groups) عالی خواهد بود. شکی نیست که صفحه با برچسبهای گروهی کدگذاری شده با رنگ، جالبتر به نظر میرسید و این ویژگی ممکن بود مفیدتر نیز باشد. اما ما تصمیم گرفتیم این را به عنوان غیر ضروری علامتگذاری کرده و آن را از هسته پروژه حذف کنیم. میتوانستیم آن را به عنوان یک "خوب است که داشته باشیم (nice-to-have)" به تیم یادآوری کنیم، اما همه باید با این فرض شروع کنند که این ویژگی بدون آن نیز ارزشمند است.
تا این مرحله، شکلدهی یک فعالیت پشت درهای بسته (closed-door activity) بوده است. قبل از اینکه آماده شوید ایده را برای اشتراکگذاری گستردهتر بنویسید، ممکن است به ورودی در مورد برخی بخشهای مفهوم که کاملاً از آنها مطمئن نیستید، نیاز داشته باشید. ممکن است یک فرض فنی (technical assumption) وجود داشته باشد که نیاز دارید با کسی که کد را بهتر میفهمد، تأیید کنید. یا شاید میخواهید مطمئن شوید که دادههای کاربری (usage data) با فرضیهای که در مورد رفتار فعلی مشتری دارید، در تضاد نیست.
این زمان خوبی است که چند متخصص فنی را جمع کرده و ایده را با آنها در میان بگذارید. به آنها بگویید که این فقط یک ایده است. این چیزی است که شما به عنوان یک شرطبندی بالقوه (potential bet) در حال شکلدهی آن هستید، نه چیزی که هنوز در حال اجراست. حال و هوا دوستانه-همدست است: "این چیزی است که من به آن فکر میکنم... اما هنوز آماده نیستم که به کسی نشان دهم... شما چه فکر میکنید؟"
از سوال ساده "آیا این ممکن است؟" برحذر باشید. در نرمافزار، همه چیز ممکن است اما هیچ چیز رایگان نیست. ما میخواهیم بدانیم آیا این کار در محدوده "اشتها" (بازه زمانی) که برای آن شکلدهی میکنیم، ممکن است یا خیر. به جای پرسیدن "آیا X را میتوان انجام داد؟"، بپرسید "آیا X در ۶ هفته ممکن است؟". این یک سوال بسیار متفاوت است.
در مورد محدودیتهایی که این راهحل را با توجه به "اشتها" خوب میکند صحبت کنید، تا آنها در حفظ اندازه پروژه مد نظر شما شریک باشند. و تأکید کنید که به دنبال ریسکهایی هستید که میتوانند پروژه را منفجر کنند. این فقط یک مکالمه "شما چه فکر میکنید" نیست – ما واقعاً به دنبال بمبهای ساعتی هستیم که ممکن است پروژه را پس از تعهد به یک تیم، منفجر کنند.
سعی کنید "خاک رس را مرطوب نگه دارید". به جای نوشتن یک سند یا ایجاد یک اسلایدشو، آنها را به یک تخته وایتبرد دعوت کنید و عناصر را همانطور که قبلاً کار کردهاید، دوباره ترسیم کنید و مفهوم را از ابتدا بسازید. کاملاً به مفهومی که قبلاً کار کردهاید پایبند باشید تا بازخورد روی کاری که قبلاً انجام دادهاید، دریافت کنید. سپس پس از اینکه کار انجام شده خود را پوشش دادید، آن را باز کنید و از آنها دعوت کنید تا بازبینیهایی را پیشنهاد دهند. با دیدن این مفهوم، آیا آنها بینشی در مورد چگونگی سادهسازی شدید یا رویکرد متفاوت به مشکل دارند؟
بسته به نحوه پیشرفت مکالمه، ممکن است رویکرد خود را تأیید کرده باشید یا مشکلاتی را کشف کرده باشید که شما را به دور دیگری از شکلدهی بازمیگرداند.
در پایان این مرحله، ما عناصر راهحل، وصلهها (patches) برای Rabbit Hole های احتمالی، و حصارهایی در اطراف مناطقی که خارج از محدوده (out of bounds) اعلام کردهایم، داریم. ما از یک راهحل تقریباً شکلگرفته با ریسک بالقوه به یک ایده محکم رسیدهایم که اکنون امیدواریم در آینده روی آن شرطبندی کنیم.
این بدان معناست که ما آماده انتقال از شکلدهی خصوصی و دریافت بازخورد از حلقه داخلی (inner-circle) به ارائه ایده در میز شرطبندی (betting table) هستیم. برای انجام این کار، ما آن را در قالبی مینویسیم که مرزها را مشخص کرده و راهحل را به وضوح بیان میکند تا افراد با آگاهی کمتر نیز بتوانند آن را درک و ارزیابی کنند. این "طرح اولیه (pitch)" سندی خواهد بود که از آن برای لابی کردن برای منابع، جمعآوری بازخورد گستردهتر در صورت لزوم، یا صرفاً ثبت ایده برای زمانی که زمان مناسبتر است در آینده، استفاده خواهیم کرد.
