اولین قدم در شکلدهی، تعیین مرزها برای کاری است که قصد انجامش را داریم. مکالمات ما کاملاً متفاوت خواهد بود اگر افراد تصور کنند که ما در مورد یک بهبود کوچک صحبت میکنیم یا یک بازطراحی بزرگ.
بحث در مورد ساخت یک قابلیت همیشه با یک ایده خام شروع میشود، مثلاً «مشتریان درخواست نوتیفیکیشنهای گروهی دارند.» قبل از اینکه همگی وارد بحثهای مفصل و بیپایان برای راهحلها شویم، باید ابتدا شرایط کلی گفتگو را تعیین کنیم تا مثمر ثمر باشد.
گاهی اوقات یک ایده بلافاصله ما را هیجانزده میکند. در این صورت، باید این هیجان را با بررسی اینکه آیا واقعاً میتوانیم زمانی را به آن اختصاص دهیم یا خیر، تعدیل کنیم. اگر برای تفکر در مورد ارزش ایده توقف نکنیم، ممکن است همه به سرعت یا به تخصیص منابع متعهد شویم یا وارد بحثهای طولانی در مورد راهحلهای بالقوهای شویم که به جایی نمیرسند.
ایدههای دیگر کمتر هیجانانگیز هستند و بیشتر شبیه یک چالش ناخواسته به نظر میرسند. مشتری یک تقویم میخواهد؛ ما واقعاً تمایلی به ساخت آن نداریم، اما احساس میکنیم باید کاری در مورد این درخواست انجام دهیم.
چه مشتاق باشیم و چه تمایلی به شروع نداشته باشیم، تعیین صریح اینکه این موضوع چقدر از زمان و توجه ما را میطلبد، کمککننده است. آیا این موضوع ارزش یک راهحل سریع را دارد، اگر بتوانیم آن را مدیریت کنیم؟ آیا این یک ایده بزرگ است که ارزش یک چرخه (Cycle) کامل را دارد؟ آیا برای جای دادن آن، آنچه را که داریم بازطراحی خواهیم کرد؟ آیا فقط در صورتی آن را در نظر میگیریم که بتوانیم آن را به عنوان یک تغییر کوچک پیادهسازی کنیم؟
ما این را اشتها (Appetite) مینامیم. میتوانید اشتها را به عنوان یک بودجه زمانی برای یک تیم با اندازه استاندارد در نظر بگیرید. ما معمولاً اشتها را در دو اندازه تعیین میکنیم:
• دستهبندی کوچک (Small Batch): این پروژهای است که یک تیم شامل یک طراح و یک یا دو برنامهنویس میتواند در یک یا دو هفته بسازد. ما اینها را با هم در یک چرخه شش هفتهای دستهبندی میکنیم (جزئیات بیشتر بعداً).
• دستهبندی بزرگ (Big Batch): این پروژه برای تیمی با همین اندازه، شش هفته کامل زمان میبرد.
در موارد نادری که دامنه (Scope) آنقدر بزرگ است که یک پروژه شش هفتهای قابل تصور نیست، تلاش میکنیم با محدود کردن تعریف مسئله، آن را کوچکتر کنیم. اگر باز هم نتوانیم دامنه را کوچک کنیم، بخش معناداری از پروژه را جدا خواهیم کرد که میتوانیم آن را متناسب با اشتهای شش هفتهای شکل دهیم.
زمان ثابت، دامنه متغیر (Fixed Time, Variable Scope)
اشتها (Appetite) کاملاً با تخمین (Estimate) متفاوت است. تخمینها با یک طراحی شروع میشوند و با یک عدد به پایان میرسند. اشتهاها با یک عدد شروع میشوند و با یک طراحی به پایان میرسند. ما از اشتها به عنوان یک محدودیت خلاقانه در فرآیند طراحی استفاده میکنیم.
این اصل، که «زمان ثابت، دامنه متغیر» نامیده میشود، کلید موفقیت در تعریف و ارائه پروژهها است. این کتاب را به عنوان مثال در نظر بگیرید. ارائه یک کتاب دشوار است وقتی همیشه میتوانید مطالب بیشتری اضافه کنید، بیشتر توضیح دهید یا آنچه را که از قبل وجود دارد بهبود بخشید. وقتی مهلت (Deadline) دارید، ناگهان مجبور به تصمیمگیری میشوید. با یک هفته باقی مانده، میتوانم بین رفع غلطهای املایی یا افزودن بخش جدیدی به یک فصل، یکی را انتخاب کنم. این همان کشش بین زمان، کیفیت و دامنه است. من نمیخواهم کتابی با غلطهای املایی شرمآور منتشر کنم، بنابراین انتخاب میکنم دامنه را با حذف بخش اضافی کاهش دهم. بدون فشار مهلت ثابت، من این بده بستان را انجام نمیدادم. اگر دامنه متغیر نبود، مجبور بودم بخش اضافی را اضافه کنم. در این صورت، وقتی برای رفع مشکلات کیفی باقی نمیماند.
ما این اصل را در هر مرحله از فرآیند، از شکلدهی پروژههای بالقوه گرفته تا ساخت و ارائه آنها، به کار میبریم. اولاً، اشتها تعیین میکند که چه نوع راهحلی را در طول فرآیند شکلدهی طراحی کنیم. بعداً، وقتی کار را به یک تیم واگذار میکنیم، زمانبندی ثابت (Time Box) آنها را وادار میکند تا در مورد اینکه چه چیزی برای پروژه اصلی است و چه چیزی جانبی یا غیرضروری، تصمیمگیری کنند.
هیچ تعریف مطلقی برای «بهترین» راهحل وجود ندارد. بهترین، نسبی و وابسته به محدودیتهای شماست. بدون محدودیت زمانی، همیشه یک نسخه بهتر وجود دارد. شاید بهترین غذا یک شام ده قسمتی باشد. اما وقتی گرسنه و عجله دارید، یک هاتداگ عالی است.
میزان زمانی که برای اشتهای خود تعیین میکنیم، ما را به راهحلهای متفاوتی هدایت خواهد کرد. ما میتوانیم در نسخه پیشرفته، یک مجموعه کامل از ستونهای پایگاه داده را مدلسازی کنیم، یا فقط یک فیلد متنی ساده در نسخه ساده ارائه دهیم. میتوانیم صفحه اصلی (Landing Page) را برای جای دادن یک قابلیت جدید بازطراحی کنیم، یا آن را به صفحهای با محدودیتهای طراحی کمتر منتقل کنیم. ما تنها میتوانیم «راهحل خوب» را در چارچوب میزان زمان و اهمیتی که میخواهیم صرف کنیم، قضاوت کنیم.
پاسخ پیشفرض ما به هر ایدهای که مطرح میشود باید این باشد: «جالب است. شاید روزی...». به عبارت دیگر، یک «نه» بسیار ملایم که همه گزینههای ما را باز نگه میدارد. ما آن را در بکلاگ (Backlog) قرار نمیدهیم. به آن فضا میدهیم تا بتوانیم بفهمیم آیا واقعاً مهم است و چه چیزی را ممکن است در بر داشته باشد.
گفتن «بله» یا «خیر» در اولین برخورد خیلی زود است. حتی اگر هیجانزده باشیم، نباید تعهدی را بپذیریم که هنوز آن را درک نکردهایم. باید روی ایده کار کنیم قبل از اینکه به اندازه کافی شکل بگیرد تا بتوانیم منابع را روی آن شرطبندی کنیم. اگر همیشه به درخواستهای دریافتی «بله» بگوییم، در نهایت با کوهی از کار روبرو خواهیم شد که فقط بزرگتر میشود.
مهم است که خونسرد و کمی بیتفاوت (Poker Face) باشیم. نمیخواهیم ایدهای را که درک نمیکنیم، رد کنیم. ممکن است فردا اطلاعات جدیدی به دستمان برسد که باعث شود آن را متفاوت ببینیم. از سوی دیگر، نشان دادن شور و اشتیاق زیاد بلافاصله میتواند انتظاراتی را ایجاد کند که این اتفاق خواهد افتاد. ممکن است نتوانیم به آن متعهد شویم پس از اینکه آن را در بستر سایر کارهایی که میخواهیم انجام دهیم، قرار دادیم.
علاوه بر تعیین اشتها، معمولاً باید درک خود از مشکل را محدودتر کنیم.
یک بار مشتری از ما قوانین دسترسی پیچیدهتری درخواست کرد. ساخت تغییری که او میخواست به راحتی میتوانست شش هفته طول بکشد. به جای پذیرش درخواست به ظاهر، عمیقتر کاوش کردیم. معلوم شد که شخصی فایلی را آرشیو کرده بود بدون اینکه بداند این فایل برای سایر کاربران سیستم ناپدید میشود. به جای ایجاد قانونی برای جلوگیری از آرشیو کردن توسط برخی افراد، متوجه شدیم میتوانیم یک اخطار روی خود عملیات آرشیو قرار دهیم که تأثیر آن را توضیح دهد. این یک تغییر یک روزه است به جای یک پروژه شش هفتهای.
مثال دیگر، «نمای تقویم» از فصل قبلی است. همه میدانند نمای تقویم چیست. اما باز کردن آن، تعداد زیادی ناشناخته و تصمیماتی را آشکار کرد که میتوانست به شدت بر دامنه تأثیر بگذارد. اگر فقط میخواهیم شش هفته به جای شش ماه برای ساخت یک تقویم عظیم صرف کنیم، چگونه آن را محدود میکنیم؟
در این حالت، از پرسیدن «چه چیزی میتوانیم بسازیم؟» به «چه چیزی واقعاً مشکل دارد؟» تغییر مسیر میدهیم. مسلماً، یک تقویم خوب به نظر میرسد. اما چه چیزی این درخواست را هدایت میکند؟ دقیقاً در کدام نقطه، جریان کاری فعلی فرد بدون این چیزی که درخواست میکند، دچار مشکل میشود؟
در مورد درخواست تقویم، با مشتری که این قابلیت را خواسته بود، تماس گرفتیم. به جای پرسیدن اینکه چرا یک تقویم میخواهد و چه شکلی باید باشد، از او پرسیدیم چه زمانی به یک تقویم نیاز پیدا کرد. او مشغول چه کاری بود که فکر درخواست تقویم به ذهنش رسید؟
او به ما گفت که در دفتری کار میکند که یک تقویم بزرگ روی دیوار تخته سیاه کشیده شده بود. همکارانش زمان ملاقات با مشتریان در چند اتاق جلسه را روی تقویم علامتگذاری میکردند. یک روز او از خانه کار میکرد. یک مشتری تماس گرفت و از او خواست که جلسهای را برنامهریزی کند. او مجبور شد به دفتر رانندگی کند تا تقویم دیواری را ببیند. ترافیک در مسیر وحشتناک بود و در نهایت هیچ فضای خالیای که برای مشتریاش مناسب باشد، وجود نداشت. اگر میتوانست از طریق کامپیوترش در خانه، نقاط خالی روی تقویم را بررسی کند، میتوانست یک ساعت از ترافیک و بسیاری از ناامیدیها را صرفهجویی کند.
بینش (Insight) این نبود که «تقویم را کامپیوتری کنیم»—این بدیهی است. آنچه ما آموختیم این بود که «دیدن فضاهای خالی» نکته مهم برای این مورد استفاده (Use Case) بود، نه «انجام هر کاری که یک تقویم انجام میدهد». این داستان و داستانهای مشابه آن، یک خط مبنای مشخص برای طراحی به ما داد. Basecamp یک نمای دستور کار (Agenda View) برای رویدادها داشت. برای فهرست کردن مهلتها و نقاط عطف اصلی کار میکرد، اما برای برنامهریزی منابع مناسب نبود زیرا نمیتوانستید فضاهای خالی را در آن ببینید. ما نیاز را از «انجام هر کاری که یک تقویم انجام میدهد» به «کمک به من برای دیدن فضاهای خالی تا بتوانم بفهمم چه زمانی چیزی را برنامهریزی کنم» محدود کردیم.
هنوز راهحلی نداشتیم. اما حالا احساس میکردیم مشکلی داریم که به اندازه کافی مشخص است تا ایدهای را جرقه بزند که بتواند در اشتهای ما جای بگیرد. این ما را به مفهوم سادهتر «شبکه نقطهای (Dot Grid)» از فصل گذشته هدایت کرد.
اگر نتوانیم یک نقطه درد (Pain Point) مشخص یا مورد استفاده را کشف کنیم، چه میشود؟ اشتهای ما همچنین میتواند به ما بگوید چقدر تحقیق ارزشمند است. اگر در حال حاضر حیاتی نیست و نمیتوانیم مشکل را درک کنیم، از آن صرف نظر میکنیم و روی چیز دیگری کار میکنیم. شاید در آینده یک درخواست یا داستان جدید ظاهر شود که بینش بهتری نسبت به مشکل به ما بدهد.
وقتی صحبت از ایدههای نامشخص میشود، بدترین موارد «بازطراحیها (Redesigns)» یا «بازسازیها (Refactorings)» هستند که با یک مشکل یا مورد استفاده واحد هدایت نمیشوند. وقتی کسی چیزی شبیه «بازطراحی بخش فایلها» را پیشنهاد میکند، این یک کیسه محتویات متفرقه (Grab-Bag) است، نه یک پروژه. فهمیدن اینکه به چه معناست، از کجا شروع میشود و کجا به پایان میرسد، بسیار دشوار خواهد بود. اینجا یک نقطه شروع پربارتر است: «باید بخش فایلها را بازنگری کنیم زیرا اشتراکگذاری چندین فایل مراحل زیادی را میطلبد.». حالا میتوانیم بپرسیم: چه چیزی کار نمیکند؟ در چه زمینهای مراحل زیادی وجود دارد؟ کدام بخشهای طراحی موجود میتوانند دست نخورده باقی بمانند و کدام بخشها نیاز به تغییر دارند؟
یک نشانه آشکار از یک کیسه محتویات متفرقه، برچسب «2.0» است. ما در گذشته اشتباه کردیم و یک پروژه «فایلها 2.0» را بدون در نظر گرفتن واقعی معنای آن شروع کردیم. هیجان ما برای بهبود بخش بزرگی از برنامه، بر ما غلبه کرد. میدانستیم قابلیت فایلهای ما مشکلات زیادی دارد، اما از خودمان نپرسیدیم که دقیقاً قرار است چه کاری انجام دهیم. پروژه آشفته از آب درآمد چون نمیدانستیم «تکمیل شده» چه شکلی است. ما با تقسیم پروژه به پروژههای کوچکتر، مانند «پیشنمایشهای بهتر فایل» و «رنگهای سفارشی پوشه»، بهبود یافتیم. ما برای هر پروژه اشتها و انتظارات روشنی تعیین کردیم و آنها را با موفقیت ارائه دادیم.
وقتی هر سه مورد را داشته باشیم—یک ایده خام، یک اشتها، و یک تعریف محدود از مشکل—آمادهایم تا به مرحله بعدی برویم و عناصر یک راهحل را تعریف کنیم.
