تقاضای تولیدشده: چرا تیمی که نجات پیدا کرده باز زیر آواره
خلاصهٔ کاملتر
لارسون هشت سال پیش نظریهای دربارهٔ نجات تیمهای در حال دستوپا زدن نوشته بود که چهار مرحله داشت. تیمی عقبموندهست اگه هر هفته بکلاگش از هفتهٔ قبل بلندتر باشه — راهحل: استخدام بیشتر. تیمی داره آبتنی میکنه اگه کار حیاتیش رو انجام بده ولی نتونه بدهی فنی رو بپردازه یا پروژهٔ تازه شروع کنه — راهحل: کمکردن کار موازی.
تیمی در حال پرداخت بدهیه وقتی بالاخره میتونه سراغ بدهی فنی بره ولی هنوز پیشرفت کند حس میشه — راهحل اینه که مسیر رو ادامه بده، چون واقعاً داره جواب میده و فقط باید تا آخر کندن ادامه بدی. و تیمی نوآوره وقتی بدهی فنیش پایین و پایداره، روحیه بالاست و بیشتر کار داره نیاز تازهٔ کاربر رو جواب میده.
نویسنده میگه هنوز این مدل رو خیلی ارزشمند میدونه، ولی یک ظرافت توش کمه که خیلی از تیمها تو محیطهای پررشد باهاش برخورد میکنن: تقاضای سرکوبشده و تقاضای تولیدشده. تقاضای سرکوبشده یعنی کاری که به دستت نمیرسه، چون آدمها دیگه از تو کمک نمیخوان. تقاضای تولیدشده وقتیه که پیشرفت یک تیم روبهبهبود دیده میشه و اون تقاضای سرکوبشده به تقاضای واقعی تبدیل میشه.
نتیجهش گیجکننده و حتی دلسردکنندهست: تیمی که مشکل داشته میتونه با موفقیت بازسازی بشه، بخش زیادی از بکلاگش رو تموم کنه، و کمی بعد دقیقاً بهاندازهٔ بدترین دوران خودش زیر آب باشه. تیم همهچیز رو درست انجام داده، کلی کار واقعاً ارزشمند تحویل داده، و بازم همونجاست.
مثال ملموسش تیم Customer Operations Engineering خودشونه که یک سال پیش اصلاً وجود نداشت و کارهاش لای تسکهای یک تیم بزرگتر اولویتبندی میشد — یعنی پروژههای خیلی ارزشمندی داشتن که هیچوقت نیرو بهشون تخصیص داده نمیشد. بعد از جداکردنش به یک تیم مستقل، پروژههایی مثل بازطراحی ابزار داخلی و یکپارچهسازی Sierra برای IVR رو انجام دادن و خوب هم جواب داد. و دقیقاً بهخاطر همین موفقیت، حالا درخواستهای خیلی بیشتری دارن و تیم از یک سال پیش هم عقبتره.
راهحل به گفتهٔ خود نویسنده چندان بدیع نیست: باید دوباره کل چرخه رو بری، و شاید بار سوم و چهارم؛ تا وقتی کل بکلاگ تقاضای سرکوبشده رو رو کنی. اون این رو شبیه مسئلهٔ حوادث نهفته میدونه که باعث میشه برنامههای مؤثر قابلیت اتکا در ظاهر شکستخورده به نظر برسن، چون دارن ذخیرهٔ حوادث نهفتهٔ قبلی رو تخلیه میکنن. چالش واقعی تو اون لحظه اینه که به خودت، تیمت و مدیریت ثابت کنی مسیر درسته و فقط وقت میبره.
نکتهٔ آخر و کاربردی مقاله اینه که میشه تا حدی حدس زد کدوم تیم روی بکلاگ پنهان نشسته: تیمهایی با رابط باریک — مثلاً تیمی که فقط صفهای داخلی رو فراهم میکنه — بعد از تمومکردن بکلاگ اولیه تقاضای تولیدشدهٔ زیادی نمیبینن. ولی تیمهای با رابط گسترده مثل عملیات مشتری یا تجربهٔ توسعهدهنده تقریباً همیشه روی یک بکلاگ عظیم و فعلاً نامرئی نشستن.
نکات کلیدی:
- مدل چهارمرحلهای: عقبمونده، آبتنی، پرداخت بدهی، نوآور
- تقاضای سرکوبشده یعنی درخواستهایی که چون تیم ضعیف بوده اصلاً مطرح نشدن
- موفقیت تیم اون تقاضا رو بیدار میکنه و دوباره غرقش میکنه
- راهحل، تکرار چرخهٔ بازسازیه تا بکلاگ پنهان تموم بشه
- تیمهای با رابط گسترده بیشترین تقاضای پنهان رو دارن
