اولین قدم در شکل‌دهی، تعیین مرزها برای چیزی هست که می‌خوایم انجام بدیم. گفت‌وگوهایی که انجام می‌دیم کاملاً متفاوت خواهد بود اگر افراد فکر کنن داریم درباره یک بهینه‌سازی کوچک صحبت می‌کنیم یا یک ریدیزاین اساسی.
صحبت درباره ساخت یک فیچر همیشه با یک ایده خام شروع می‌شه، مثل این که “مشتری‌ها درخواست نوتیفیکشن گروهی رو دارن.” قبل از اینکه وارد جزئیات و راه‌حل‌ها بشیم، باید اول یه چارچوب کلی برای بحث مشخص کنیم تا گفت‌وگو سازنده بشه.
تعیین میزان اشتیاق
گاهی اوقات یه ایده فوراً ما رو هیجان‌زده می‌کنه. توی این مواقع باید این هیجان رو کنترل کنیم و بررسی کنیم که آیا واقعاً این چیزی هست که می‌خوایم براش وقت بذاریم یا نه. اگه بدون فکر کردن به ارزش اون ایده جلو بریم، ممکنه همگی سریعاً منابع‌مون رو بهش اختصاص بدیم یا وارد بحث‌های طولانی بشیم که در نهایت هیچ جایی نمی‌رسن.
برخی ایده‌های دیگه کمتر هیجان‌انگیزن و بیشتر شبیه یه چالشن که ما درخواستش رو ندادیم. مثلاً مشتری‌ها تقاضای یه تقویم دارن؛ ما خیلی علاقه‌ای به ساختنش نداریم، اما احساس می‌کنیم باید کاری در مورد این درخواست مشتری‌ها انجام بدیم.
چه از هیجان در آستانه ورود به یه پروژه باشیم، چه با بی‌میلی واردش بشیم، بهتره صریحاً تعیین کنیم چقدر از وقت و توجه‌مون رو براش اختصاص می‌دیم. آیا این چیزی هست که با یه رفع مشکل سریع حل بشه؟ آیا این یه ایده بزرگه که ارزش داره یه چرخه کامل براش وقت بذاریم؟ آیا لازمه برای انجامش ریدیزاین انجام بدیم؟ یا فقط زمانی روش فکر می‌کنیم که بتونیم به عنوان یه تغییر کوچیک پیادش کنیم؟
ما به این مفهوم «اشتیاق» می‌گیم. می‌تونید اشتیاق رو مثل یه بودجه زمانی برای یه تیم استاندارد در نظر بگیرید. معمولاً اشتیاق رو به دو اندازه تعریف می‌کنیم:
- سایز کوچک: این یه پروژه‌ست که یه تیم شامل یک نفر طراح و یکی دو نفر برنامه‌نویس می‌تونن توی یکی دو هفته بسازنش. این پروژه‌ها رو با هم ترکیب می‌کنیم تا به یه چرخه شش هفته‌ای برسیم (بعداً بیشتر توضیح می‌دم).
- سایز بزرگ: این پروژه برای تیمی با همین اندازه شش هفته کامل زمان می‌بره.
تو موارد نادری که اسکوپ پروژه اونقدر بزرگه که توی یه پروژه شش‌هفته‌ای نمی‌گنجه، سعی می‌کنیم با محدودتر کردن تعریف مشکل، اونو کوچک‌تر کنیم. اگه باز هم نتونیم اسکوپ رو کم کنیم، یه بخش قابل‌توجه از پروژه رو جدا می‌کنیم که بتونیم طوری شکل‌دهی رو انجام بدیم که توی اشتیاق شش‌هفته‌ای بگنجه.
زمان ثابت، اسکوپ متغیر
اشتیاق کاملاً با برآورد فرق داره. برآوردها با طراحی شروع می‌شن و به یه عدد ختم می‌شن. اما اشتیاق با یه عدد شروع می‌شه و به یه طراحی ختم می‌شه. ما از اشتیاق به عنوان یه محدودیت خلاقانه در فرایند طراحی استفاده می‌کنیم.
این اصل، که بهش «زمان ثابت، اسکوپ متغیر» می‌گن، کلید موفقیت در تعریف و تحویل پروژه‌هاست. مثلاً این کتاب رو در نظر بگیرین. وقتی همیشه می‌تونید چیزهای بیشتری اضافه کنید، توضیحات بیشتری بدید یا بخش‌هایی که نوشتید رو بهتر کنید، سخته که یه کتاب رو منتشر کنید. اما وقتی یه ضرب‌الاجل داشته باشید، ناگهان مجبور می‌شید تصمیم بگیرید. وقتی یه هفته به پایان کار مونده، می‌تونم بین اصلاح اشتباهات تایپی یا اضافه کردن یه بخش جدید به یه فصل انتخاب کنم. این کشمکش بین زمان، کیفیت و اسکوپ هست. من نمی‌خوام کتابی با اشتباهات تایپی منتشر کنم، پس ترجیح می‌دم اسکوپ رو کم کنم و بخش جدید رو کنار بذارم. اگه فشار ضرب‌الاجل نباشه، شاید این تصمیم رو نگیرم. اگه اسکوپ قابل تغییر نبود، مجبور می‌شدم اون بخش اضافی رو هم اضافه کنم. و در این صورت وقتی برای اصلاح مشکلات کیفی نمی‌موند.
ما این اصل رو توی همه مراحل فرایند اعمال می‌کنیم؛ از شکل دادن پروژه‌های احتمالی گرفته تا ساختن و تحویل دادن اون‌ها. اول، اشتیاق تعیین می‌کنه چه نوع راه‌حلی رو توی فرایند شکل‌دهی طراحی کنیم. بعداً، وقتی کار رو به تیم می‌سپاریم، زمان محدود اون‌ها رو مجبور می‌کنه تصمیم بگیرن که چه چیزی برای پروژه اساسی هست و چه چیزی حاشیه‌ای یا غیرضروریه.
«خوب بودن» نسبیه
تعریف مطلقی برای «بهترین» راه‌حل وجود نداره. بهترین همیشه نسبیه و به محدودیت‌های شما بستگی داره. بدون محدودیت زمانی، همیشه می‌تونید نسخه بهتری داشته باشید. بهترین غذا شاید یه منوی شام کامل با همه‌ی مخلفات باشه. اما وقتی گرسنه هستید و عجله دارید، هات‌داگ یه گزینه‌ی ایده‌آله.
مقدار زمانی که برای اشتیاق تعیین می‌کنیم، ما رو به راه‌حل‌های مختلفی می‌رسونه. می‌تونیم توی نسخه مفصل، یه سری ستون‌های دیتابیس رو مدل‌سازی کنیم، یا توی نسخه ساده فقط یه textarea ارائه بدیم. می‌تونیم صفحه اصلی رو دوباره طراحی کنیم تا یه ویژگی جدید رو جا بدیم، یا می‌تونیم اون رو به یه صفحه دیگه منتقل کنیم که محدودیت‌های طراحی کمتری داره. ما فقط می‌تونیم یه راه‌حل رو «خوب» ارزیابی کنیم، وقتی می‌دونیم چقدر زمان برای اون می‌خوایم بذاریم و چقدر برامون اهمیت داره.
پاسخ به ایده‌های خام
پاسخ پیش‌فرض ما به هر ایده‌ای که مطرح می‌شه باید این باشه: «جالبه. شاید یه روزی.» یعنی یه «نه» ملایم که همه گزینه‌ها رو باز نگه می‌داره. ما اون ایده رو به یه فهرست کاری نمی‌فرستیم. بهش زمان می‌دیم تا ببینیم آیا واقعاً مهمه و چه جنبه‌هایی داره.
زوده که توی اولین برخورد «بله» یا «نه» بگیم. حتی اگه هیجان‌زده هم باشیم، نباید تعهدی بدیم که هنوز کامل نفهمیدیم. باید روی ایده کار کنیم تا زمانی که به اندازه کافی شکل بگیره و بتونیم براش منابع اختصاص بدیم. اگه همیشه به درخواست‌های ورودی «بله» بگیم، در نهایت کوهی از کارها داریم که هر روز مرتفع‌تر می‌شه.
خیلی مهمه که در برخورد با ایده‌ها خونسرد و مثل یه پوکر باز عمل کنیم. نباید ایده‌ای رو که هنوز درکش نکردیم رد کنیم. ممکنه فردا اطلاعات جدیدی به دست بیاد که دیدمون رو نسبت به اون تغییر بده. از طرف دیگه، نشون دادن شور و اشتیاق زیاد همون اول کار، می‌تونه انتظاراتی ایجاد کنه که بعد از بررسی همه کارها، نتونیم بهش عمل کنیم.
مسئله رو محدودش کنید
علاوه بر تعیین میزان اشتیاق، معمولاً باید درک خودمون از مسئله رو هم واضح‌تر و دقیق‌تر کنیم.
یه بار یکی از مشتریان از ما خواست قوانین پیچیده‌تری برای دسترسی به فایل‌ها اضافه کنیم. اجرای درخواستش به راحتی می‌تونست شش هفته طول بکشه. ولی به جای اینکه درخواستش رو مستقیم قبول کنیم، عمیق‌تر بررسی کردیم. معلوم شد کسی یه فایل رو بدون اینکه بدونه برای بقیه هم از دسترس خارج می‌شه، بایگانی کرده بود. به جای اینکه قانونی برای جلوگیری از بایگانی کردن بعضی افراد بذاریم، متوجه شدیم می‌تونیم یه هشدار روی عملکرد بایگانی بذاریم که پیامدهاش رو توضیح بده. این یه تغییر یه روزه‌س به جای یه پروژه شش هفته‌ای.
یه مثال دیگه، همون «نمای تقویم» از فصل قبلیه. همه می‌دونن نمای تقویم چیه. ولی وقتی اونو باز کردیم، کلی مسائل و تصمیمات ناشناخته نمایان شد که به شدت اسکوپ پروژه رو تحت تأثیر می‌ذاشت. اگه بخوایم فقط شش هفته وقت بذاریم به جای شش ماه برای ساختن یه تقویم بزرگ، چطوری محدودش کنیم؟
تو این حالت، به جای اینکه بپرسیم «چه چیزی می‌تونیم بسازیم؟»، می‌پرسیم «واقعاً چه مشکلی وجود داره؟» درسته، یه تقویم به نظر خوب میاد. ولی چی باعث شده این درخواست مطرح بشه؟ توی کدوم قسمت دقیقاً کار مشتری بدون این چیزی که درخواست کرده مختل شده؟
مطالعه موردی: تعریف «تقویم»
در مورد درخواست تقویم، با مشتری‌ای که این ویژگی رو خواسته بود تماس گرفتیم. به جای اینکه بپرسیم چرا تقویم می‌خواد و چه شکلی باید باشه، ازش پرسیدیم چه زمانی به فکرش رسیده که تقویم لازم داره؟ در اون لحظه داشت چه کاری انجام می‌داد که باعث شد این نیاز براش پیش بیاد؟
او به ما گفت که در یک دفتر کار می‌کنه که یه تقویم بزرگ روی دیوار گچی کشیده شده. همکارانش زمان ملاقات با مشتری‌ها رو برای اتاق‌های جلسه روی اون تقویم علامت می‌زدند. یه روز که از خونه کار می‌کرد، یه مشتری تماس گرفت و ازش خواست یه جلسه رو تنظیم کنه. مجبور شد به دفتر بره تا تقویم دیواری رو چک کنه. تو مسیر ترافیک وحشتناکی بود و در نهایت هم یه فضای خالی مناسب برای مشتری پیدا نکرد. اگه می‌تونست از خونه با کامپیوترش تقویم رو ببینه، می‌تونست یه ساعت تو ترافیک صرفه‌جویی کنه و کلی هم اعصابش راحت‌تر می‌شد.
نکته‌ای که فهمیدیم این نبود که “تقویم رو کامپیوتری کنیم”—این خیلی واضح بود. چیزی که یاد گرفتیم این بود که برای این کاربرد خاص، دیدن “فضاهای خالی” مهم بود نه انجام همه کارهایی که یه تقویم انجام می‌ده.
این داستان و داستان‌های مشابه به ما یه نقطه شروع مشخص برای طراحی داد. Basecamp نمایی از رویدادها به شکل agenda داشت. این نما برای لیست کردن ددلاین‌ها و نکات مهم خوب بود اما برای زمان‌بندی منابع مناسب نبود، چون نمی‌تونستی فضاهای خالی رو ببینی. ما نیاز رو از “انجام همه کارهای یه تقویم” به “کمکم کن فضاهای خالی رو ببینم تا زمان مناسب رو پیدا کنم” محدود کردیم.
هنوز راه‌حل نداشتیم. اما حالا احساس می‌کردیم که مشکلی داریم که به اندازه کافی مشخص شده تا ایده‌ای رو جرقه بزنه که توی اسکوپ ما جا بشه. این ما رو به ایده ساده‌تر “Dot Grid” از فصل قبل هدایت کرد.
اگه نتونیم یه نقطه درد خاص یا کاربرد مشخص رو پیدا کنیم چی؟ میزان اشتیاق ما می‌تونه همچنین به ما بگه که یه موضوع چقدر ارزش تحقیق کردن داره. اگه الان خیلی در اولویت نباشه و نتونیم مشکل رو به خوبی درک کنیم، ازش می‌گذریم و روی چیز دیگه‌ای کار می‌کنیم. شاید در آینده درخواست یا داستان جدیدی مطرح بشه که دید بهتری از مشکل به ما بده.
حواست به ایده‌های کلی باشه
وقتی با ایده‌های نامشخص سر و کار داریم، بدترین اون‌ها “طراحی مجدد” یا “بازنویسی”هایی هستند که بر اساس یک مشکل یا کاربرد مشخص ایجاد نشدن. وقتی کسی چیزی مثل “ریدیزاین بخش فایل‌ها” رو پیشنهاد می‌کنه، این بیشتر شبیه به یه پروژه پراکنده است تا یک پروژه مشخص. خیلی سخت می‌شه فهمید منظورش چیه، از کجا شروع می‌شه و کجا تموم می‌شه. یه نقطه شروع سازنده‌تر اینه: “باید دوباره به بخش فایل‌ها فکر کنیم چون اشتراک‌گذاری چند فایل مراحل زیادی داره.” حالا می‌تونیم بپرسیم: چه چیزی درست کار نمی‌کنه؟ در چه زمینه‌ای مراحل زیادی داره؟ کدوم قسمت‌های طراحی موجود می‌تونن همون‌طور بمونن و کدوم قسمت‌ها باید تغییر کنن؟
مرزها مشخص شدند
وقتی که سه چیز داریم: ایده اولیه، میزان اشتیاق (apetite)، و یک درک واضح از مسئله، حالا آماده‌ایم که به مرحله بعدی برویم و عناصر یک راه‌حل را تعریف کنیم.
پاسخ‌ها (0 )