خواندن ۱۰ دقیقه·۴ ماه پیش

۱۳. تصمیم بگیرید چه زمانی متوقف شوید - کتاب Shape Up

وقتی به پایان یک چرخه نزدیک می‌شویم، تکنیک‌هایی که تا اینجا پوشش دادیم، تیم را در موقعیت خوبی قرار می‌دهند تا کار را تمام کرده و آن را عرضه (ship) کنند. کار شکل‌گرفته (shaped work) به آنها guard rails داد تا از گمراه شدنشان جلوگیری کند. آنها هر scope را به صورت جداگانه یک به یک ادغام کردند تا کار نیمه‌تمام روی زمین نماند. و همه مهم‌ترین مشکلات حل شده‌اند، چون آنها آن ناشناخته‌ها (unknowns) را هنگام توالی‌بندی کار، اولویت‌بندی کردند.

با این حال، همیشه کار بیشتر از زمان است. عرضه به موقع (shipping on time) به معنای عرضه کردن چیزی ناقص است. همیشه دلشوره (queasiness) دارید وقتی به کارتان نگاه می‌کنید و از خودتان می‌پرسید: آیا این به اندازه کافی خوب است؟ آیا این آماده عرضه (release) است؟.

مقایسه با بیس‌لاین (baseline)

طراحان و برنامه‌نویسان همیشه می‌خواهند بهترین کار خود را انجام دهند. فرقی نمی‌کند که دکمه در مرکز صفحه فرود (landing page) باشد یا دو صفحه پایین‌تر در صفحه تنظیمات (settings screen)، طراح بهترین توجه خود را به آن معطوف خواهد کرد. و بهترین برنامه‌نویسان می‌خواهند که کد بیس (code base) مانند یک کل منسجم (cohesive whole) باشد، که کاملاً از نظر منطقی سازگار بوده و تمام اج کیس (edge case)ها را پوشش دهد.

غرور نسبت به کار برای کیفیت و روحیه مهم است، اما باید آن را به سمت هدف درست هدایت کنیم. اگر به دنبال یک طراحی ایده‌آل و بی‌نقص باشیم، هرگز به آن نخواهیم رسید. در عین حال، نمی‌خواهیم استانداردهای خود را پایین بیاوریم. چگونه تصمیم بگیریم (make the call) که آنچه داریم به اندازه کافی خوب است و به جلو حرکت کنیم؟.

جابجایی نقطه مقایسه کمک کننده است. به جای مقایسه با ایده‌آل (comparing up)، به سمت بیس‌لاین (baseline) مقایسه کنید—یعنی واقعیت فعلی برای مشتریان. مشتریان امروز، بدون این فیچر (feature)، چگونه این مشکل را حل می‌کنند؟. چه راه‌حل موقتی (workaround) آزاردهنده‌ای وجود دارد که این فیچر آن را از بین می‌برد؟. مشتریان چقدر دیگر باید چیزی را که کار نمی‌کند تحمل کنند یا منتظر راه حلی باشند، فقط به این دلیل که ما مطمئن نیستیم آیا طراحی A بهتر از طراحی B است؟.

دیدن اینکه کار ما تا اینجای کار بهتر از جایگزین‌های فعلی است، باعث می‌شود احساس بهتری نسبت به پیشرفتمان داشته باشیم. این ما را ترغیب می‌کند تا در مورد چیزهایی که سرعت ما را کم می‌کنند، تصمیم بگیریم. کمتر به خودمان مربوط است و بیشتر به ارزش برای مشتری. این تفاوت بین "هرگز به اندازه کافی خوب نیست" و "بهتر از آن چیزی است که اکنون دارند" است. می‌توانیم بگوییم: "خب، این کامل نیست، اما قطعاً کار می‌کند و مشتریان احساس خواهند کرد که این یک پیشرفت بزرگ برای آنهاست".

کاهش اسکوپ (scope) با مقایسه به سمت بیس‌لاین به جای مقایسه با یک ایده‌آل کامل

محدودیت‌ها، ترید-آف (trade-off)ها را تحریک می‌کنند

به یاد بیاورید که "شرط شش هفته‌ای" (six-week bet) یک سرکیت بریکر (circuit breaker) دارد—اگر کار انجام نشود، پروژه اتفاق نمی‌افتد.

این تیم را مجبور به انجام ترید-آف (trade-off) می‌کند. وقتی کسی می‌گوید "آیا بهتر نیست اگر..." یا یک اج کیس (edge case) دیگر پیدا می‌کند، ابتدا باید از خود بپرسد: آیا برای این کار زمان هست؟. بدون یک ددلاین (deadline)، آنها به راحتی می‌توانند پروژه را برای تغییراتی که واقعاً شایسته زمان اضافی نیستند، به تأخیر بیندازند.

ما از تیم‌هایمان انتظار داریم که به طور فعالانه ترید-آف انجام دهند و اسکوپ (scope) را زیر سوال ببرند، به جای اینکه کارها را به زور و با فشار تمام کنند. ما خودمان کار را برای خودمان ایجاد می‌کنیم. ما باید هر کار جدیدی را که پیش می‌آید، قبل از پذیرفتن آن به عنوان یک ضرورت، زیر سوال ببریم.

اسکوپ (scope) مثل چمن رشد می‌کند

اسکوپ (scope) به طور طبیعی رشد می‌کند. اسکوپ کریپ (Scope creep) (افزایش ناخواسته اسکوپ) تقصیر مشتریان بد، مدیران بد، یا برنامه‌نویسان بد نیست. پروژه‌ها در مقیاس ماکرو (macro scale) مبهم هستند. تا زمانی که وارد کار نشوید، نمی‌توانید تمام جزئیات ریز (micro-details) یک پروژه را ببینید. سپس نه تنها پیچیدگی‌هایی را که پیش‌بینی نمی‌کردید کشف می‌کنید، بلکه انواع چیزهایی را نیز می‌بینید که می‌توانند رفع شوند یا بهتر از وضعیت فعلی‌شان شوند.

هر پروژه‌ای پر از اسکوپ است که به آن نیاز نداریم. هر بخش از یک محصول نیازی نیست که به یک اندازه برجسته (prominent)، سریع و صیقلی (polished) باشد. هر یوز کیس (use case) به یک اندازه رایج (common)، حیاتی (critical)، یا هم‌راستا با بازاری که قصد فروش به آن را داریم، نیست.

اوضاع اینگونه است. به جای تلاش برای متوقف کردن رشد اسکوپ، ابزارها، اختیار و مسئولیت را به تیم‌ها بدهید تا آن را دائماً کاهش دهند.

کاهش اسکوپ (scope) به معنای کاهش کیفیت نیست

انتخاب و گزینش اینکه چه چیزهایی را اجرا کنیم و تا چه اندازه پیش ببریم، حفره‌ای در محصول ایجاد نمی‌کند. تصمیم‌گیری، محصول را بهتر می‌کند. محصول را در برخی چیزها بهتر می‌کند، نه در همه چیز. سخت‌گیری در مورد اسکوپ، محصول را متفاوت می‌کند. متمایز کردن هسته از اجزای فرعی، ما را در فضای رقابتی حرکت می‌دهد و باعث می‌شود نسبت به سایر محصولاتی که انتخاب‌های متفاوتی داشته‌اند، شباهت یا تفاوت بیشتری پیدا کنیم.

وریبل اسکوپ (variable scope) به معنای فدا کردن کیفیت نیست. ما در مورد کیفیت کد، طراحی بصری، متن‌های (copy) موجود در اینترفیس (interface)هایمان، و پرفورمنس (performance) تعاملاتمان، بسیار سخت‌گیر هستیم. ترفند این است که از خودمان بپرسیم چه چیزهایی واقعاً مهم هستند، چه چیزهایی تاثیرگذارند (move the needle)، و چه چیزهایی برای یوز کیس‌های اصلی که قصد حل آنها را داریم، تفاوت ایجاد می‌کنند..

همرینگ (Scope hammering)

مردم اغلب در مورد "کم کردن" اسکوپ (scope) صحبت می‌کنند. ما از کلمه‌ای حتی قوی‌تر—همرینگ (hammering) (کوبیدن)—استفاده می‌کنیم تا قدرت و نیرویی را که برای بارها و بارها کوبیدن اسکوپ لازم است تا در تایم باکس (time box) جا بگیرد، منعکس کنیم.

همانطور که در طول یک پروژه به چیزهایی برای اصلاح، اضافه کردن، بهبود یا طراحی مجدد می‌رسیم، از خود می‌پرسیم:

• آیا این برای فیچر (feature) جدید یک "ماست-هَو (must-have)" (باید-داشته-باشیم) است؟

• آیا می‌توانیم بدون این، محصول را عرضه (ship) کنیم؟

• چه اتفاقی می‌افتد اگر این کار را انجام ندهیم؟

• آیا این یک مشکل جدید است یا یک مشکل از قبل موجود که مشتریان قبلاً با آن زندگی می‌کنند؟

• چقدر احتمال دارد این مورد یا شرایط اتفاق بیفتد؟

• وقتی این مورد اتفاق می‌افتد، کدام مشتریان آن را می‌بینند؟ آیا اصلی است—که توسط همه استفاده می‌شود—یا بیشتر یک اج کیس (edge case) است؟

• در صورت وقوع این مورد یا شرایط، تأثیر واقعی آن چیست؟

• وقتی چیزی برای یک یوز کیس (use case) خاص خوب کار نمی‌کند، آن یوز کیس چقدر با مخاطبان مورد نظر ما هم‌راستا است؟

ددلاین (deadline) ثابت ما را به پرسیدن این سوالات ترغیب می‌کند. وریبل اسکوپ (variable scope) ما را قادر می‌سازد تا بر اساس آنها عمل کنیم. با تراشیدن و همرینگ (hammering) کردن اسکوپ، ما فقط روی کارهایی که برای عرضه چیزی موثر و قابل افتخار در پایان تایم باکس (time box) نیاز داریم، متمرکز می‌مانیم.

در طول چرخه، از تیم‌هایمان خواهید شنید که هنگام کشف کارها در مورد ماست-هَو (must-have)ها و نایس-تو-هَو (nice-to-have)ها صحبت می‌کنند. ماست-هَوها به عنوان تسک (task)ها روی اسکوپ ثبت می‌شوند. اسکوپ تا زمانی که آن تسکها تمام نشوند، "انجام‌شده" (done) تلقی نمی‌شود. نایس-تو-هَوها می‌توانند پس از اتمام اسکوپ روی آن باقی بمانند. آنها با یک علامت تیلده (~) در جلو مشخص می‌شوند. این تسکها کارهایی هستند که اگر تیم در پایان زمان اضافی داشت انجام می‌شوند و در غیر این صورت حذف می‌شوند. معمولاً هرگز ساخته نمی‌شوند. عمل علامت‌گذاری آنها به عنوان یک نایس-تو-هَو، همان همرینگ اسکوپ (scope hammering) است.

یک اسکوپ تکمیل شده با یک نایس-تو-هَو (که با "˜" مشخص شده) که هرگز به اتمام نرسید

QA (کیفیت سنجی) برای اج‌ها (edges) است

در اندازه فعلی Basecamp (میلیون‌ها کاربر و حدود دوازده نفر در تیم محصول)، ما یک نفر مسئول کیو اِی (QA) داریم. آنها در اواخر چرخه وارد می‌شوند و به دنبال اج کیس (edge case)هایی خارج از عملکرد اصلی (core functionality) می‌گردند.

کیو اِی می‌تواند توجه خود را به اج کیسها محدود کند زیرا طراحان و برنامه‌نویسان مسئولیت کیفیت اولیه کار خود را بر عهده می‌گیرند. برنامه‌نویسان تست‌های خود را می‌نویسند و تیم با هم کار می‌کند تا اطمینان حاصل کند که پروژه طبق آنچه شکل گرفته (shaped) عمل می‌کند. این ناشی از دادن مسئولیت کل پروژه به تیم است، به جای اختصاص تسک (task)های فردی به آنها (به فصل ۹، "واگذاری مسئولیت" مراجعه کنید).

سال‌ها ما یک نقش کیو اِی نداشتیم. سپس پس از اینکه پایگاه کاربری (user base) ما به اندازه مشخصی رشد کرد، دیدیم که اج کیسهای کوچک شروع به تأثیرگذاری بر صدها یا هزاران کاربر به صورت مطلق (in absolute numbers) کردند. اضافه کردن مرحله کیو اِی اضافی به ما کمک کرد تا تجربه آن کاربران را بهبود بخشیم و بار نامتناسبی را که برای تیم پشتیبانی ایجاد می‌کردند، کاهش دهیم.

بنابراین، ما کیو اِی را به عنوان یک "ارتقاء" (level-up) می‌بینیم، نه یک دروازه (gate) یا نقطه بازرسی (check-point) که همه کارها باید از آن عبور کنند. با کیو اِی وضعیت ما بسیار بهتر از بدون آن است. اما ما برای عرضه فیچر (feature)های با کیفیت که طبق انتظار کار می‌کنند، به کیو اِی وابسته نیستیم.

کیو اِی تسک (task)های کشف شده‌ای را ایجاد می‌کند که به طور پیش‌فرض همگی نایس-تو-هَو (nice-to-have) هستند. تیم طراح-برنامه‌نویس آنها را تریاژ (triage) می‌کند و بسته به شدت و زمان موجود، برخی از آنها را به ماست-هَو (must-have) ارتقاء می‌دهد. دقیق‌ترین روش برای انجام این کار این است که مسائل ورودی کیو اِی را در یک لیست کارهای جداگانه (to-do list) جمع‌آوری کنید. سپس، اگر تیم تصمیم گرفت که یک مسئله ماست-هَو است، آن را به لیست مربوط به اسکوپ (scope)ای که تحت تأثیر قرار می‌دهد، منتقل می‌کنند. این به تیم کمک می‌کند تا ببیند که اسکوپ تا زمانی که مسئله برطرف نشود، تمام نشده است.

ما کد ریویو (code review) را نیز به همین روش در نظر می‌گیریم. تیم می‌تواند بدون انتظار برای کد ریویو، محصول را عرضه (ship) کند. هیچ چک-پوینت (check-point) رسمی (formal) وجود ندارد. اما کد ریویو کارها را بهتر می‌کند، بنابراین اگر زمان باشد و منطقی به نظر برسد، یک نفر ارشد ممکن است کد را بررسی کرده و بازخورد دهد. این بیشتر در مورد بهره‌برداری از یک فرصت آموزشی است تا ایجاد یک مرحله در فرآیند ما که هر بار باید اتفاق بیفتد.

چه زمانی یک پروژه را تمدید کنیم

در موارد بسیار نادر، پروژه‌ای را که از ددلاین (deadline) خود گذشته است، برای چند هفته تمدید می‌کنیم. چگونه تصمیم می‌گیریم چه زمانی یک پروژه را تمدید کنیم و چه زمانی اجازه دهیم سرکیت بریکر (circuit breaker) کار خود را انجام دهد؟.

اولاً، تسک (task)های باقی‌مانده باید ماست-هَو (must-have)های واقعی باشند که در برابر هر تلاشی برای همرینگ اسکوپ (scope hammer) کردنشان مقاومت کرده‌اند.

ثانیاً، کار باقی‌مانده باید کاملاً "سرازیری" (all downhill) باشد. هیچ مشکل حل‌نشده؛ هیچ سوال بی‌جوابی. هر کار "سربالایی" (uphill work) در پایان چرخه به یک نادیده‌گرفتن (oversight) در شکل‌دهی (shaping) یا یک نقص (hole) در مفهوم اشاره دارد. ناشناخته‌ها برای شرط‌بندی (bet) بسیار پرخطر هستند. اگر کار سربالایی است، بهتر است در چرخه بعدی کار دیگری انجام دهیم و پروژه مشکل‌دار را به مرحله شکل‌دهی (shaping) بازگردانیم. اگر راه حل مناسبی برای رفع نقص پیدا کردید، می‌توانید در آینده دوباره روی آن زمان بیشتری سرمایه‌گذاری (bet) کنید.

حتی اگر شرایط برای تمدید پروژه فراهم باشد، ما همچنان ترجیح می‌دهیم منظم باشیم و "اشتها" (appetite) تعیین شده برای بیشتر پروژه‌ها را اجرا کنیم. کول‌داون (cool-down) دو هفته‌ای معمولاً فضای کافی (slack) را برای تیمی که کمی ماست-هَو بیش از حد دارد، فراهم می‌کند تا قبل از شروع چرخه بعدی، محصول را عرضه (ship) کند. اما این نباید به عادت تبدیل شود. رسیدن به کول‌داون (یعنی استفاده از زمان کول‌داون برای اتمام پروژه) یا به مشکلی در فرآیند شکل‌دهی (shaping) اشاره دارد یا به مشکل عملکردی (performance problem) در تیم.