ما شرطهایمان را بستیم و اکنون زمان آن است که چرخه بعدی را آغاز کنیم. تیم چگونه شروع به کار میکند؟
ما با واگذاری وظایف (tasks) به کسی شروع نمیکنیم. هیچکس نقش «وظیفه دهنده» یا «معمار» را بازی نمیکند که پروژه را برای اجرا توسط دیگران به قطعات تقسیم کند.
تقسیم پروژه به وظایف (tasks) از ابتدا، مانند این است که طرح (pitch) را از یک کاغذ خردکن رد کنید. همه فقط قطعات جدا شده را دریافت میکنند. ما میخواهیم پروژه در طول کل فرآیند «کامل» باقی بماند تا هرگز تصویر بزرگتر را از دست ندهیم.
در عوض، ما به تیم اعتماد میکنیم که کل پروژه را بر عهده بگیرد و در محدوده طرح (pitch) کار کند. تیم وظایف (tasks) و رویکرد خود را برای کار تعریف خواهد کرد. آنها استقلال کامل خواهند داشت و از قضاوت خود برای اجرای طرح (pitch) به بهترین شکل ممکن استفاده خواهند کرد.
تیمها عاشق آزادی بیشتر برای پیادهسازی یک ایده به روشی هستند که خودشان بهترین میدانند. افراد با استعداد دوست ندارند مانند «code monkeys» یا مسئولین تیکت رفتار شوند.
پروژهها همچنین زمانی بهتر پیش میروند که به تیم مسئولیت مراقبت از کل کار داده شود. هیچکس نمیتواند در ابتدای یک پروژه پیشبینی کند که دقیقاً چه کاری باید انجام شود تا همه قطعات به درستی در کنار هم قرار گیرند. آنچه روی کاغذ کار میکند تقریباً هرگز دقیقاً همانطور که در عمل طراحی شده، کار نمیکند. طراحان و برنامهنویسانی که کار واقعی را انجام میدهند در بهترین موقعیت برای اعمال تغییرات و تنظیمات یا تشخیص قطعات گمشده هستند.
هنگامی که وظایف (tasks) فردی به تیمها واگذار میشود، هر فرد میتواند قطعه کوچک خود را بدون احساس مسئولیت برای قضاوت در مورد اینکه چگونه همه قطعات با هم هماهنگ میشوند، اجرا کند. برنامهریزی از پیش شما را نسبت به واقعیت در طول مسیر کور میکند.
به یاد داشته باشید: ما به تیمها آزادی مطلق برای ابداع یک راهحل از صفر را نمیدهیم. ما شکلدهی (shaping) را انجام دادهایم. ما مرزها را تعیین کردهایم. اکنون قرار است به تیم اعتماد کنیم تا طرح کلی (outline) از طرح (pitch) را با تصمیمات واقعی طراحی و پیادهسازی پر کند.
اینجاست که تلاشهای ما برای تعریف پروژه در سطح انتزاعی مناسب – بدون جزئیات زیاد – نتیجه میدهد. با استعداد و دانش خود از جزئیات، تیم به محصول نهایی بهتری دست خواهد یافت تا آنچه ما میتوانستیم با تلاش برای تعیین فرم نهایی از پیش به دست آوریم.
در پایان چرخه، تیم کار خود را استقرار (deploy) خواهد داد. در مورد یک تیم Small Batch با چند پروژه کوچک برای چرخه، آنها هر یک را به صلاحدید خود تا زمانی که قبل از پایان چرخه اتفاق بیفتد، استقرار (deploy) خواهند داد.
این محدودیت ما را به شرطبندیهایمان وفادار نگه میدارد و به Circuit Breaker احترام میگذارد. پروژه باید در زمان بودجهبندی شده ما انجام شود؛ در غیر این صورت، تمایل و بودجه ما بیمعنی خواهد بود.
این همچنین بدان معنی است که هرگونه آزمایش و QA (کنترل کیفیت) باید درون چرخه اتفاق بیفتد. تیم با محدود کردن (scoping off) ضروریترین جنبههای پروژه، به پایان رساندن آنها زودتر، و هماهنگی با QA این را فراهم خواهد کرد. (بیشتر در این باره بعداً توضیح داده خواهد شد.)
برای اکثر پروژهها، ما در مورد زمانبندی مستندات راهنما، بهروزرسانیهای بازاریابی، یا اطلاعیهها به مشتریان سختگیر نیستیم و انتظار نداریم که اینها در طول چرخه اتفاق بیفتند. اینها از منظر ریسک «دم-نازک» (thin-tailed) هستند (یعنی هرگز 5 برابر بیشتر از آنچه فکر میکنیم طول نمیکشند) و عمدتاً توسط تیمهای دیگر مدیریت میشوند. ما اغلب به این بهروزرسانیها رسیدگی میکنیم و یک اطلاعیه درباره ویژگی جدید را در طول Cool-down پس از چرخه منتشر میکنیم.
ما پروژه را با ایجاد یک پروژه Basecamp جدید و اضافه کردن تیم به آن آغاز میکنیم. سپس اولین کاری که انجام میدهیم، ارسال مفهوم شکلدهی شده (shaped concept) به تابلوی پیام (Message Board) است. ما یا طرح (pitch) اصلی یا یک نسخه خلاصهشده (distilled) از آن را ارسال خواهیم کرد.
از آنجایی که تیمهای ما از راه دور هستند، ما از اتاق چت در پروژه Basecamp برای ترتیب دادن یک تماس شروع کار (kick-off call) استفاده میکنیم.
این تماس به تیم فرصت میدهد تا هرگونه سؤال مهمی که از متن نوشته شده (write-up) واضح نیست را بپرسد. سپس، با درک تقریبی از پروژه، آنها آماده شروع کار هستند.
کار در چند روز اول شبیه «کار» نیست. هیچکس وظایف (tasks) را علامت نمیزند. چیزی استقرار (deployed) نمیشود. هیچ خروجی (deliverables) برای مشاهده وجود ندارد. اغلب حتی ارتباط زیادی بین اعضای تیم در چند روز اول وجود ندارد. ممکن است نوع عجیبی از سکوت رادیویی وجود داشته باشد.
چرا؟ زیرا هر فردی سر خود را پایین انداخته و در تلاش است تا بفهمد سیستم موجود چگونه کار میکند و کدام نقطه شروع بهترین است. همه مشغول یادگیری اوضاع و آشنایی با محیط هستند.
تیم در حال یافتن نقطه شروع
برای مدیران مهم است که به این مرحله احترام بگذارند. تیمها نمیتوانند بلافاصله وارد یک پایگاه کد (code base) شوند و شروع به ساخت قابلیتهای جدید کنند. آنها باید با کد مربوطه آشنا شوند، طرح (pitch) را با دقت بررسی کنند و برخی از بنبستهای کوتاه را طی کنند تا یک نقطه شروع پیدا کنند. دخالت کردن یا درخواست وضعیت (status) از آنها خیلی زود به پروژه آسیب میزند. این کار زمانی را از تیم میگیرد که برای یافتن بهترین رویکرد به آن نیاز دارند. کاوش به هر حال باید اتفاق بیفتد. درخواست پیشرفت قابل مشاهده تنها آن را به زیرزمین میبرد. بهتر است به تیم قدرت دهیم تا صراحتاً بگویند «هنوز دارم میفهمم چگونه شروع کنم» تا مجبور نباشند این کار مشروع را پنهان یا disguised کنند.
به طور کلی، اگر سکوت پس از سه روز شروع به شکستن نکرد، آن زمان مناسبی است که وارد عمل شوید و ببینید چه خبر است.
از آنجایی که به تیم پروژه و نه وظایف (tasks) داده شده است، آنها باید خودشان وظایف (tasks) را ابداع کنند. در اینجا ما به تفاوت مهمی بین وظایفی که فکر میکنیم در ابتدای یک پروژه باید انجام دهیم و وظایفی که کشف میکنیم در حین انجام کار واقعی باید انجام دهیم، اشاره میکنیم.
تیم به طور طبیعی با برخی وظایف (tasks) فرضی شروع میکند – آنهایی که صرفاً با فکر کردن به مشکل، فرض میکنند باید انجام دهند. سپس، با شروع کار عملی، انواع چیزهای دیگری را کشف میکنند که از قبل نمیدانستیم. این جزئیات غیرمنتظره بدنه اصلی پروژه را تشکیل میدهند و گاهی اوقات سختترین چالشها را به وجود میآورند.
تیمها با انجام کار واقعی وظایف (tasks) را کشف میکنند. برای مثال، طراح یک دکمه جدید روی رابط دسکتاپ اضافه میکند اما سپس متوجه میشود که جای واضحی برای آن در نسخه وبویو موبایل وجود ندارد. آنها یک وظیفه (task) جدید ثبت میکنند: فهمیدن چگونگی نمایش دکمه در موبایل. یا اولین نسخه از طراحی دارای سلسله مراتب بصری خوبی است، اما سپس طراح متوجه میشود که نیاز به متن توضیحی بیشتری در مکانی دارد که طرح (layout) را به هم میزند. دو وظیفه (task) جدید: تغییر طرح (layout) برای جای دادن متن توضیحی؛ نوشتن متن توضیحی.
اغلب یک وظیفه (task) در فرآیند انجام کاری نامرتبط ظاهر میشود. فرض کنید یک برنامهنویس در حال کار بر روی مهاجرت پایگاه داده (database migration) است. هنگام نگاه کردن به مدل (model) برای درک ارتباطات (associations)، ممکن است با یک متد (method) مواجه شود که نیاز به بهروزرسانی برای قسمت دیگری از پروژه در آینده دارد. او میخواهد یک وظیفه (task) برای بهروزرسانی آن متد (method) بعداً یادداشت کند.
راه واقعی برای فهمیدن اینکه چه کاری باید انجام شود، شروع به انجام کار واقعی است. این به معنای آن نیست که تیمها با ساخت هر چیزی شروع میکنند. آنها باید ابتدا چیزی معنادار برای ساخت انتخاب کنند. چیزی که مرکزی برای پروژه باشد و در عین حال به اندازه کافی کوچک باشد تا به صورت end-to-end – با UI (رابط کاربری) کارآمد و کد کارآمد – در چند روز انجام شود.
در فصلهای بعدی به این خواهیم پرداخت که تیم چگونه آن هدف را انتخاب میکند و با هم کار میکند تا یک spike کاملاً یکپارچه (integrated) را به مرحله اجرا برساند.
