تحویل محصول (Shipping) اگه مراقب نباشید، در واقع میتونه کارهای جدیدی ایجاد کنه. انتشار فیچرها (Feature releases) درخواستهای فیچر (feature requests) جدیدی رو به دنبال دارن. مشتریها میگن: «خب، عالیه، اما اون چیز دیگهای که میخواستیم چی شد؟». باگها (Bugs) پیدا میشن. پیشنهاداتی برای بهبودها دریافت میشه. همه روی چیز جدید تمرکز دارن و بهش واکنش نشون میدن.
فیدبک (Feedback) میتونه مخصوصاً شدید باشه اگه فیچری که شما تحویل دادین، جریانهای کاری (workflows) موجود رو تغییر بده. حتی تغییرات صرفاً بصری هم گاهی اوقات باعث مقاومت شدید میشن. یه اقلیت کوچکی از مشتریها ممکنه بیش از حد واکنش نشون بدن و چیزایی مثل «خرابش کردید! برگردونیدش!» بگن.
مهمه که خونسرد باشید و از واکنشهای عجولانه (knee-jerk reactions) پرهیز کنید. چند روزی بهش زمان بدید و بذارید فروکش کنه. قاطع باشید و یادتون باشه چرا اصلاً این تغییر رو ایجاد کردید و این تغییر به چه کسی کمک میکنه.
وسوسهانگیزه که در پاسخ به فیدبک، متعهد به ایجاد تغییرات بشیم، اما اینطوری دیگه برای سیکل (cycle) بعدی یک صفحه تمیز (clean slate) ندارید. یادتون باشه: اینها فقط ایدههای خام (raw ideas) هستن که دارن میان. روش مدیریت اونها اینه که با یک «نه» ملایم برخورد کنید. گفتن «نه» به این معنی نیست که دیگه نمیتونید بهشون فکر کنید و شاید اونها رو به پروژههای آینده شکل بدید. از اون طرف، گفتن «بله» آزادی شما رو در آینده سلب میکنه. این مثل گرفتن دِین (debt) هست.
یادتون باشه، چیزی که شما همین الان تحویل دادید (shipped)، یک «شرط شش هفتهای» (six-week bet) بود. اگه این بخش از محصول به زمان بیشتری نیاز داره، پس نیازمند یک «شرط» جدید هست. اجازه بدید درخواستها یا باگهایی که تازه به وجود اومدن، در «میز شرطبندی» (betting table) بعدی با همه چیزهای دیگه رقابت کنن تا مطمئن بشید که از نظر استراتژیک مهم هستن.
اینجا ما به نقطه اول برمیگردیم. ایدههای خامی که تازه از فیدبک مشتری اومدن، هنوز قابل اجرا (actionable) نیستن. اونها باید شکل داده بشن (shaped). اونها همون ورودیهای خامی هستن که در مرحله اول فرآیند شکلدهی (shaping process)، یعنی «تعیین محدودیتها» (Set Boundaries)، در موردشون صحبت کردیم.
اگه یک درخواست واقعاً مهمه، میتونید اون رو در سیکل بعدی به بالاترین اولویت در مسیر شکلدهی (shaping track) تبدیل کنید. روی چیز دیگهای برای ساخت توسط تیمها شرطبندی کنید و از اون زمان برای شکل دادن صحیح ایده جدید استفاده کنید. بعد، وقتی شش هفته تموم شد، میتونید در میز شرطبندی (betting table) دفاع کنید و نسخه شکلگرفته (shaped version) پروژه رو برای بیشترین شانس موفقیت برنامهریزی کنید.
