مدیران با نیت خوب، تمایلی به پرسیدن وضعیت کارها ندارند. این کار ناخوشایند است، شبیه به غر زدن به نظر میرسد، و وقتی مجبور میشوند سوالات پیگیری بپرسند تا کاملاً از وضعیت مطلع شوند، حتی بدتر هم میشود.
مدیران ترجیح میدهند بتوانند خودشان هر زمان که نیاز دارند وضعیت را مشاهده کنند. در فصل گذشته دیدیم که چگونه سازماندهی To-doها به Scopes به تیم کمک میکند تا بر کار مسلط بماند. اما این به طور مستقیم به مدیر کمک نمیکند. چند مشکل در To-doها وجود دارد که باعث میشود برای قضاوت وضعیت کافی نباشند.
لیستی را تصور کنید که چند مورد تکمیل شده و هیچ مورد ناتمامی در آن باقی نمانده است. این میتواند به معنای اتمام کل کار باشد. اما همچنین میتواند به این معنی باشد که تیم میداند کار بیشتری وجود دارد اما هنوز وظایف را تعریف نکرده است.
گاهی اوقات یک تیم در اوایل پروژه یک Scope را تعریف میکند بدون اینکه آن را با وظایف پر کند. این نشان میدهد که کاری باید انجام شود اما وظایف واقعی هنوز کشف نشدهاند.
یا به انجام QA (کنترل کیفیت) در پایان یک Scope فکر کنید. تمام وظایف انجام شدهاند. چیز دیگری برای انجام دادن نیست. سپس عمل تست، Scope را با وظایف جدید برای مشکلات یافت شده پر میکند.
این به مفهوم وظایف تصوری در مقابل وظایف کشف شده برمیگردد. در تصور سادهلوحانه ما از لیستی که از قبل برنامهریزی شده، کسی آن را با مواردی پر میکند که به تدریج تیک میخورند. در واقعیت، مسائل با درگیر شدن در مشکل کشف میشوند. این بدان معناست که لیستهای To-do در واقع با پیشرفت تیم رشد میکنند.
اگر در زمان t2 سعی میکردیم قضاوت کنیم که پروژه چقدر پیش رفته است، گمراه میشدیم. از دید یک شخص بیرونی (outsider)، هیچ راهی برای دانستن اینکه آیا تعداد وظایف باقیمانده کم میشود یا زیاد، وجود ندارد. برای دانستن این موضوع، به بستر و جزئیات بیشتری از کار در داخل Scope نیاز دارید تا بفهمید انجام آن وظایف خاص چه معنایی دارد و آیا وظایف دیگری ممکن است هنوز در راه باشند.
برخی از تیمها تلاش میکنند تخمینهایی را به وظایف یا Scopes خود پیوست کنند تا وضعیت را گزارش دهند. مشکل تخمینها این است که بسته به ماهیت کاری که تخمین زده میشود، معنای بسیار متفاوتی دارند.
فرض کنید دو وظیفه دارید که هر دو تخمین زده شدهاند چهار ساعت زمان ببرند. اگر یکی از وظایف چیزی باشد که تیم ده بار در گذشته انجام داده است، میتوانید به تخمین اطمینان داشته باشید. فرض کنید وظیفه دیگر چیزی است که تیم هرگز قبلاً انجام نداده است، یا وابستگیهای مبهمی دارد. این کار ممکن است در صورت پیش رفتن همه چیز به خوبی، چهار ساعت طول بکشد، اما به دلیل ناشناختههای موجود در آن، ممکن است تا دو یا سه روز به طول انجامد. نوشتن «۴ ساعت، یا شاید ۳ روز» به عنوان تخمین، معنیدار نیست.
با درک این موضوع، ما راهی برای مشاهده وضعیت پروژه بدون شمارش وظایف و بدون تخمینهای عددی ابداع کردیم. ما این کار را با تغییر تمرکز از آنچه انجام شده یا انجام نشده، به آنچه ناشناخته است و آنچه حل شده است، انجام میدهیم. برای امکانپذیر ساختن این تغییر، از استعاره "تپه" استفاده میکنیم.
هر قطعه کار دو فاز دارد. ابتدا فاز "سربالایی" است که در آن رویکردمان و کاری که قرار است انجام دهیم را مشخص میکنیم. سپس، زمانی که میتوانیم تمام کار درگیر را ببینیم، فاز "سرازیری" یا همان اجرای کار است.
بیایید از یک مثال روزمره استفاده کنیم تا حس تپه را درک کنیم.
فرض کنید در حال برنامهریزی برای میزبانی یک مهمانی شام هستید. تاریخ را تعیین کردهاید، اما هنوز چند هفته مانده و شما هنوز به این فکر نکردهاید که چه چیزی بپزید. هیچ ایدهای ندارید که نوع غذای مهمانی چه خواهد بود یا چه غذایی را باید درست کنید. این شما را در ابتدای تپه، در پایین سمت چپ، قرار میدهد.
سپس به این فکر میکنید که چه کسانی حضور دارند و متوجه میشوید که چند نفر گیاهخوار هستند. این برخی گزینهها (مانند کباب کردن) را حذف میکند اما هنوز گزینههای زیادی باقی میگذارد. هم غذای ایتالیایی و هم هندی را در نظر میگیرید. فکر میکنید غذای هندی ممکن است برای پخت و پز لذتبخشتر باشد، با گزینههای گیاهخواری جذابتر. بنابراین تصمیم میگیرید به دنبال دستور پختهای هندی بگردید.
در این مرحله، سوال «پروژه چند درصد تکمیل شده است؟» حتی معنی هم نمیدهد. و اگر کسی از شما بپرسد که خرید و آمادهسازی چقدر طول میکشد، شما نمیتوانستید پاسخ دهید زیرا هنوز غذایی را انتخاب نکردهاید. پاسخ این خواهد بود: «کمی کار برای مشخص کردن نوع غذا انجام دادهام، اما هنوز آن را به یک غذای خاص محدود نکردهام». ما میتوانیم این را با قرار دادن شما در نیمه راه بخش «در حال فهمیدن» (figuring it out) تپه نشان دهیم.
سپس کمی جستجو آنلاین انجام میدهید و کتابهای دستور پخت خود را مرور میکنید. میخواهید دستوری را پیدا کنید که جالب باشد اما نیازی به مواد اولیه خیلی سخت پیدا کردن نداشته باشد. روی یک دستور پخت به توافق میرسید و لیست خرید را آماده میکنید.
اکنون شما در موقعیتی بسیار متفاوت از قبل قرار دارید. حس شما از «هنوز مطمئن نیستم دارم چه میکنم» به «اکنون میدانم چه کاری باید انجام دهم» تغییر میکند. شما در بالای تپه هستید.
از این نقطه دید، میتوانید تمام مراحل باقیمانده را ببینید. حتی منطقی است که تخمین بزنید کل کار چقدر طول میکشد («ببینم… یک ساعت برای خرید خواربار، ۳۰ دقیقه آمادهسازی، ۴۵ دقیقه پخت…»).
روز قبل از مهمانی شام، به فروشگاه میروید و مواد اولیه را میخرید. این شما را به سمت سرازیری حرکت میدهد. به اتمام کار نزدیکتر شدهاید.
سپس نوبت کار آمادهسازی و پخت غذا میرسد.
پس از اتمام غذا، فقط کمی کار باقی مانده است: تمیزکاری.
توجه کنید که چگونه تپه نشان میدهد کار در مراحل مختلف چه حسی دارد. فاز سربالایی پر از عدم قطعیت، ناشناختهها و حل مسئله است. فاز سرازیری با قطعیت، اعتماد به نفس، دیدن همه چیز و دانستن اینکه چه کاری باید انجام داد، مشخص میشود.
میتوانیم تپه را با مفهوم Scopes از فصل قبل ترکیب کنیم. Scopes زبان پروژه («پیدا کردن»، «پاسخ دادن») را به ما میدهند و تپه وضعیت هر Scope را توصیف میکند («سربالایی»، «سرازیری»).
برای مشاهده وضعیت Scopes، میتوانیم هر یک را با رنگی متفاوت روی تپه نمایش دهیم.
این یک نمای کلی از پروژهای برای پیادهسازی رویدادهای تکرارشونده در Basecamp است. در اینجا، «Future-applying edits» یک Scope است که هنوز در حال کار روی آن است و ناشناختههای قابل توجهی برای حل کردن دارد. دو Scope دیگر هیچ ناشناخته معناداری ندارند و «Global recurring events» به اتمام نزدیکتر است.
ما یک قابلیت انحصاری برای Basecamp ساختیم تا نمودارهای تپه (hill charts) را ایجاد و با چند کلیک آنها را بهروزرسانی کند. اعضای تیم، که درک کاملی از وضعیت کار دارند، به طور خودکار Scopes را به موقعیت مورد نظر میکشند و یک بهروزرسانی جدید ذخیره میکنند که در پروژه ثبت میشود (برای جزئیات بیشتر به «چگونه Shape Up را در Basecamp پیادهسازی کنیم» مراجعه کنید).
برای مدیران، قابلیت مقایسه وضعیتهای گذشته، قابلیت برجسته (killer feature) است. این نه تنها وضعیت کار را نشان میدهد، بلکه نحوه حرکت کار را نیز نمایش میدهد.
با این دیدگاه ثانویه، مدیران میتوانند قضاوت کنند که چه چیزی در حال حرکت است و چه چیزی گیر کرده است. آنها میتوانند ببینند تیم کدام مشکلات را برای حل انتخاب کرده و چقدر زمان در هر مرحله از ناشناخته به شناخته شده و سپس به اتمام، صرف کرده است.
این گزارش به اولین مقصد مدیر تبدیل میشود، هر زمان که در مورد یک پروژه احساس نگرانی میکنند. از آنجایی که این یک ابزار Self-serve (خودخدمتی) است، نیازی به قطع کردن کار تیم با سوالات ناخوشایند وضعیت نیست. و در مواردی که چیزی درست به نظر نمیرسد، مدیر میتواند مستقیماً وارد گفتگو درباره بخش مربوطه از کار شود. «به نظر میرسد ‘Autosave’ مدتی است که در حال سربالایی بوده. ناشناختهای که جلوی آن را گرفته چیست؟». مدیر میتواند روی این بخش خاص از پروژه کارگاه برگزار کند بدون اینکه ابتدا مجبور باشد آن را از سایر مواردی که طبق انتظار پیش میروند، جدا کند.
هیچکس نمیخواهد دست خود را بلند کند و به مدیریت بگوید «من نمیدانم چگونه این مشکل را حل کنم». این باعث میشود تیمها عدم قطعیت را پنهان کرده و ریسک را انباشته کنند. لحظاتی که کسی گیر کرده یا درجا میزند، محل بزرگترین ریسکها و فرصتهاست. اگر این لحظات را زود تشخیص دهیم، میتوانیم با کمک یک فرد ارشد یا با بازنگری مفهوم، آنها را برطرف کنیم. اگر آنها را تشخیص ندهیم، مشکلات حل نشده میتوانند تا جایی در چرخه باقی بمانند که پروژه را به خطر بیندازند.
نمودار تپه به همه اجازه میدهد تا ببینند کسی ممکن است گیر کرده باشد، بدون اینکه او واقعاً آن را بیان کند. یک نقطه که حرکت نمیکند، عملاً یک دست بلند شده است: «ممکن است مشکلی اینجا وجود داشته باشد».
هنگامی که این موضوع شناسایی شد، زبان سربالایی/سرازیری، گفتگو را تسهیل میکند. کمتر در مورد شخص است (به نظر میرسد گیر کردهای!) و بیشتر در مورد کار است. سوال این است: چه چیزی را میتوانیم حل کنیم تا آن را از تپه عبور دهیم؟.
گاهی اوقات بررسی یک Scope گیر کرده نشان میدهد که اصلاً گیر نکرده است. مشکل در نحوه ترسیم خطوط Scope بوده است.
در اینجا موردی را میبینید که Scope «Notify» برای مدت طولانی روی تپه گیر کرده بود.
وقتی با تیم صحبت کردیم، معلوم شد که کار به خوبی پیش میرفته است. مشکل این بود که «Notify» یک چیز واحد نبود. این شامل سه بخش مختلف بود: طراحی یک ایمیل، ارسال ایمیل در Back-end، و نمایش اعلان در یک منوی درونبرنامهای (in-app menu). تیم عمدتاً کد مربوط به ارسال ایمیل را به پایان رسانده بود. طراحی ایمیل تقریباً مشخص شده بود. اما آنها کار روی نمایش درونبرنامهای را شروع نکرده بودند. نمیشد گفت که آیا «Notify» به طور کلی از تپه عبور کرده یا نه، زیرا بخشهایی از آن عبور کرده بودند و بخشهایی نه.
راه حل در چنین مواردی این است که Scope را به Scopes کوچکتر تقسیم کنیم که بتوانند مستقل حرکت کنند.
اکنون تیم میتواند هر نقطه را حرکت دهد تا به طور دقیق نشان دهد کار در چه وضعیتی قرار دارد.
مزیت در سطح دوم (second order) ظاهر میشود. با تفکیک Scopes، آنها میتوانند به طور مستقل در طول زمان حرکت کنند. اکنون تیم میتواند پیشرفت بیشتری را با دفعات بیشتری نسبت به قبل نشان دهد.
برخی از تیمها هنگام استفاده اولیه از نمودار تپه با "عقبگرد" (backsliding) مشکل دارند. آنها یک Scope را حل شده میدانند، آن را به بالای تپه منتقل میکنند، و بعداً مجبور میشوند آن را به عقب برگردانند وقتی یک ناشناخته غیرمنتظره کشف میکنند.
وقتی این اتفاق میافتد، اغلب به این دلیل است که کسی کار سربالایی را با سر خود (ذهنی) به جای دستان خود (عملی) انجام داده است. ابداع یک رویکرد در ذهن شما فقط اولین گام سربالایی است. ما اغلب یک نظریه در مورد نحوه حل چیزی داریم—«من فقط از آن API استفاده خواهم کرد»—و سپس واقعیت پیچیدهتر از آب درمیآید. خوب است که یکسوم اول سربالایی را به معنای «من به این موضوع فکر کردهام»، یکسوم دوم را به معنای «رویکرد خود را تأیید کردهام»، و یکسوم نهایی تا قله را به معنای «آنقدر با آنچه ساختهام پیش رفتهام که باور ندارم ناشناخته دیگری وجود داشته باشد» در نظر بگیرید.
علاوه بر دیدن وضعیت کار، میتوانیم از نمودار تپه برای اولویتبندی کارها استفاده کنیم—اینکه کدام مشکلات را به چه ترتیبی حل کنیم.
برخی Scopes پرخطرتر از دیگران هستند. دو Scope را تصور کنید: یکی شامل Geocoding (کدگذاری جغرافیایی) دادههاست—چیزی که تیم هرگز قبلاً انجام نداده است. دیگری طراحی و پیادهسازی یک اعلان ایمیلی است. هر دو ناشناخته دارند. هر دو از پایین تپه شروع میشوند. اینجا جایی است که تیم از خود میپرسد: اگر در پایان چرخه زمان کم بیاوریم، کدام یک از اینها را میتوانیم به راحتی — علیرغم ناشناختهها — به سرعت آماده کنیم، و کدام یک ممکن است سختتر از آنچه فکر میکنیم باشد؟.
این تیم را ترغیب میکند تا پرخطرترین کار را ابتدا به سمت سربالایی حرکت دهد. هنگامی که به سربالایی رسیدند، آن را همانجا رها میکنند و به دنبال هر چیز بسیار مهم دیگری میگردند قبل از اینکه کار سرازیری را به اتمام برسانند. بهتر است چند Scope حیاتی را در اوایل پروژه به بالای تپه برسانید و «ریزهکاریها» (screw-tightening) را برای بعد بگذارید.
کار برای پر کردن زمان موجود گسترش مییابد. اگر تیم ابتدا با قالب ایمیل شروع کند، به راحتی میتوانند هفتهها را صرف تکرار روی متن یا ایجاد بهترین طراحی ایمیل ممکن کنند. اما آنها نیازی به انجام این کار ندارند. نسخهای از قالب ایمیل وجود دارد که میتواند در یک روز در هفته آخر آماده شود و کافی خواهد بود. از طرف دیگر، Geocoder ممکن است مشکلات جدیدی را ارائه دهد که تیم بتواند برای هفتهها با آنها دست و پنجه نرم کند. آنها نمیخواهند این غافلگیری در پایان چرخه رخ دهد.
روزنامهنگاران مفهومی به نام «هرم معکوس» (inverted pyramid) دارند. ایده این است که مقالات آنها با ضروریترین اطلاعات در بالا شروع میشوند، سپس جزئیات و اطلاعات پسزمینه را به ترتیب اهمیت کمتر اضافه میکنند. این به طراحان روزنامههای چاپی اجازه میدهد تا بخش حیاتی داستان را در صفحه اول قرار دهند و در صورت نیاز بخش پایانی را بدون از دست دادن هیچ چیز ضروری حذف کنند.
تیمهای کارآمد به همین شیوه، حل مسئله خود را اولویتبندی میکنند. آنها ابتدا مهمترین مشکلات را با بیشترین ناشناختهها انتخاب میکنند، آنها را به بالای تپه میرسانند و کارهایی را که روزمره یا کمترین نگرانی را دارند، برای آخر میگذارند.
با نزدیک شدن به پایان چرخه، تیمها باید کارهای مهم را به پایان رسانده و مجموعهای از «مواردی که خوب است داشته باشیم» (nice to haves) و «شایدها» را باقی بگذارند. این ما را به فصل بعدی، یعنی تصمیمگیری درباره زمان توقف، میرساند.
