ما اکنون عناصر یک راهحل را در اختیار داریم و مفهوم خود را تا جایی ریسکزدایی (de-risked) کردهایم که اطمینان داریم گزینه خوبی برای ارائه به یک تیم است. اما این مفهوم هنوز در ذهن ما یا در برخی طراحیهای دشوار برای خواندن روی وایتبورد یا دفترچهمان باقی مانده است. اکنون باید این مفهوم را به شکلی درآوریم که دیگران بتوانند آن را درک، هضم و پاسخ دهند.
اینجاست که میگوییم "بسیار خوب، این آماده است تا به عنوان یک پیچ (pitch) نوشته شود". در این فصل، مؤلفههای یک پیچ را بررسی کرده و نمونههای کاملاً توسعهیافتهای از پروژههای واقعی در بیسکمپ (Basecamp) را نشان خواهیم داد.
هدف از پیچ، ارائه یک "شرط بالقوه خوب" (good potential bet) است. این اساساً یک ارائه (presentation) است. مؤلفههای آن شامل تمام چیزهایی است که هم برای ثبت کارهای انجامشده تا کنون نیاز داریم و هم برای ارائه آنها به شکلی که افرادی که پروژهها را برنامهریزی میکنند، بتوانند یک "شرط آگاهانه" (informed bet) ببندند.
پنج مؤلفه وجود دارد که همیشه میخواهیم در یک پیچ گنجانده شود:
• مشکل (Problem) — ایده خام، یک مورد استفاده (use case)، یا چیزی که دیدهایم و ما را به کار بر روی آن سوق میدهد.
• میل و زمانبندی (Appetite) — چه مقدار زمان میخواهیم صرف کنیم و این چگونه راهحل را محدود میکند.
• راهحل (Solution) — عناصر اصلی که به آنها رسیدهایم، به شکلی ارائه شدهاند که مردم بتوانند فوراً آنها را درک کنند.
• گودال خرگوش (Rabbit holes) — جزئیاتی درباره راهحل که ارزش اشاره دارند تا از مشکلات جلوگیری شود.
• ممنوعهها (No-gos) — هر چیزی که به طور خاص از مفهوم حذف شده است: عملکرد یا موارد استفادهای که عمداً برای تطابق با زمانبندی یا قابل مدیریت کردن مشکل پوشش نمیدهیم.
مؤلفه ۱. مشکل
ارائه همزمان مشکل و راهحل از اهمیت حیاتی برخوردار است. این نکتهای آشکار به نظر میرسد، اما تعجبآور است که تیمها – حتی تیمهای خود ما – اغلب با فرض اینکه دلیل ساخت یک چیز واضح است، مستقیماً به سراغ راهحل میروند.
شیرجه زدن مستقیم به "چه چیزی بسازیم" – یعنی راهحل – خطرناک است. بدون مشکل، شما هیچ مبنایی برای بحث در مورد خوب یا بد بودن این راهحل ایجاد نمیکنید. "اضافه کردن تب به برنامه iPad" ممکن است برای طراحان UI جذاب باشد، اما چه چیزی مانع از تبدیل شدن بحث به یک مناظره طولانی درباره رویکردهای مختلف UI میشود؟ بدون یک مشکل خاص، هیچ آزمونی برای ارزیابی مناسب بودن وجود ندارد تا قضاوت شود کدام راهحل بهتر از دیگری است.
تعریف مشکل به ما امکان میدهد بعداً، زمانی که وقت پیچ کردن ایده یا شرط بستن (betting) روی آن فرا میرسد، مکالمهای واضحتر داشته باشیم. راهحل ممکن است بینقص باشد، اما اگر مشکل فقط برای مشتریانی رخ دهد که به عنوان نامناسب برای محصول شناخته شدهاند، چه؟ ممکن است شش هفته را صرف یک راهحل مبتکرانه کنیم که فقط به درصد کمی از مشتریان که نرخ حفظ پایینی دارند، سود میرساند. ما میخواهیم بتوانیم آن بحث مربوط به تقاضا را جدا کنیم تا زمان را صرف یک راهحل خوب که به افراد مناسب سود نمیرساند، نکنیم.
اینکه تا چه حد باید مشکل را توضیح دهید، بستگی به میزان زمینهی مشترک (context) شما با افرادی دارد که متن را میخوانند. بهترین تعریف مشکل شامل یک داستان خاص و منفرد است که نشان میدهد چرا وضعیت موجود کار نمیکند. این به شما یک مبنا (baseline) میدهد تا مناسب بودن را در برابر آن آزمایش کنید. افراد قادر خواهند بود راهحل را در برابر این مشکل خاص – یا راهحلهای دیگر در صورت بروز بحث – بسنجند و قضاوت کنند که آیا آن داستان با راهحل جدید، نتیجه بهتری خواهد داشت یا خیر.
مؤلفه ۲. میل و زمانبندی (Appetite)
میتوانید "میل و زمانبندی" (appetite) را به عنوان بخش دیگری از تعریف مشکل در نظر بگیرید. ما نه تنها میخواهیم این مورد استفاده را حل کنیم، بلکه میخواهیم راهی برای انجام آن در شش هفته، نه سه ماه، یا – در مورد یک پروژه دسته کوچک (small batch project) – دو هفته، نه تمام شش هفته، پیدا کنیم.
بیان زمانبندی در پیچ از مکالمات غیرسازنده جلوگیری میکند. همیشه یک راهحل بهتر وجود دارد. سؤال این است که اگر ما فقط به اندازه کافی برای صرف دو هفته زمان برای این کار در حال حاضر اهمیت میدهیم، این راهحل خاص چگونه به نظر میرسد؟
هر کسی میتواند راهحلهای گران و پیچیده پیشنهاد دهد. رسیدن به یک ایده ساده که در یک جعبه زمانی کوچک (small time box) جای میگیرد، نیازمند کار و بینش طراحی است. بیان زمانبندی و پذیرش آن به عنوان یک محدودیت، همه را در این فرآیند شریک میکند.
مؤلفه ۳. راهحل
مانند راهحلهای بدون مشکل، گاهی اوقات شرکتها روی مشکلاتی شرط میبندند که راهحلی ندارند. مثلاً: "واقعاً باید پیدا کردن چیزها را در بخش پیامها آسانتر کنیم. مشتریان از آن شکایت دارند".
این برای پیچ کردن یا شرط بستن آماده نیست. یک مشکل بدون راهحل، کاری "شکلنیافته" (unshaped) است. دادن آن به یک تیم به معنای سوق دادن تحقیق و کاوش به سطح اشتباه است، جایی که مجموعهی مهارتها (skillsets)، محدودیت زمانی و پروفایل ریسک (ریسک کم در مقابل ریسک بالا/پر دنباله - thin vs. heavy tailed) همه ناهماهنگ هستند.
اگر راهحل وجود ندارد، کسی باید برگردد و کار شکلدهی (shaping work) را در مسیر شکلدهی (shaping track) انجام دهد. فقط زمانی برای شرط بستن آماده است که مشکل، زمانبندی (appetite) و راهحل با هم جمع شوند. سپس میتوانید تناسب بین مشکل و راهحل را بررسی کرده و قضاوت کنید که آیا این یک شرط خوب است یا خیر.
به آنها کمک کنید تا ببینند
در مرحله "عناصر"، مهم بود که ایدهها را در سطح مناسبی از انتزاع (abstraction) ترسیم کنیم تا سرعت کار کاهش نیابد و هیچ یک از ایدههایی که در گوشههای ذهن و نوک زبانمان ظاهر میشدند، از دست نروند.
هنگام نوشتن پیچ نیز باید با سطح مناسبی از جزئیات ترسیم کنیم. در اینجا چالش کمی متفاوت است. ما زمان داریم تا سرعت خود را کم کنیم و یک ارائه مناسب آماده کنیم. باید در سطح بالا (high level) بمانیم، اما کمی ملموستر (concreteness) از زمانی که تنها یا با یک همکار کار میکردیم، جزئیات اضافه کنیم. افرادی که پیچ را میخوانند و به نقاشیها نگاه میکنند، بدون زمینه زیاد، باید ایده را "درک کنند".
ما به ملموستر شدن نیاز داریم، اما نمیخواهیم طراحی را با وایرفریمها (wireframes) یا ماکاپهای با جزئیات بالا (high-fidelity mocks) بیش از حد مشخص کنیم. اینها طراحانی را که بعداً کار را انجام میدهند، محدود خواهند کرد (box in). همچنین خطر منحرف شدن بحث (side-tracking) به موضوعاتی مانند رنگ، نسبتها یا طرحبندی وجود دارد که هیچ ربطی به کار شکلدهی واقعی که انجام دادهایم، ندارند.
در عین حال، نمودارهای اولیه دستی (hand-written breadboards) کیفیتی دارند که "شما باید آنجا میبودید تا درک کنید". برای افرادی که مرحله به مرحله توسعه نمودار اولیه دستی را ندیدهاند، ممکن است شبیه به آش درهمبرهمی از کلمات و فلشها به نظر برسد.
بنابراین، ما به تکنیکهایی نیاز داریم تا به مردم کمک کنیم ایده را ببینند، در حالی که بیش از حد وارد جزئیات بیربط نمیشویم.
اسکچهای جاسازیشده (Embedded sketches)
فرض کنید نمودار اولیه دستی (breadboard) شما از جلسه شکلدهی به این شکل بوده است:
ممکن است مردم در تجسم اینکه این قابلیتهای جدید (affordances) کجا روی داشبورد (Dashboard) قرار میگیرند، مشکل داشته باشند. میتوانیم یک کادر جدید روی داشبورد ترسیم کنیم تا آن را واضحتر کنیم:
اما ما هنوز از مردم میخواهیم بیش از حد تصور کنند. ارزشش را دارد که یک مرحله پایینتر رفته و جزئیات با ماژیک ضخیم (fat-marker detail) را اضافه کنیم:
این کار دیدن عناصر و ارزیابی وضوح نمایش ویژگی در داشبورد را آسانتر میکند. نکته منفی این است که ما وارد برخی تصمیمات طرحبندی (layout decisions) شدهایم که بهتر بود از آنها اجتناب میکردیم. طراحان باید در پیدا کردن طرحی متفاوت از کادر تقسیمشده با خط عمودی، آزاد باشند. ما در اینجا در پیچ، سلب مسئولیتی اضافه میکنیم که به طراحان یادآوری میکند که چه میزان آزادی عمل دارند.
این نمونهای از انتخاب جزئیات بصری بیشتر است زیرا برای "فروختن مفهوم" به آن نیاز داریم. خوشبختانه، در سایر بخشهای مفهوم، نیازی به تصمیمات بصری زیادی نخواهیم داشت. این یک "نقطه کلیدی" (linchpin) در طراحی بود که همه باید آن را به طور ملموس میدیدند تا آن را "درک کنند".
اسکچهای ماژیک ضخیم حاشیهنویسی شده (Annotated fat marker sketches)
گاهی اوقات ایدهها ذاتاً بصری هستند یا کمی پیچیدهتر از آنند که در یک نمودار اولیه دستی شماتیک (schematic breadboard) بیان شوند. اسکچهای ماژیک ضخیم میتوانند در یک پیچ بسیار مؤثر باشند؛ فقط باید بیشتر دقت کنید که آنها را به طور واضح برچسبگذاری کنید.
ترسیم مجدد اسکچ روی iPad – همچنان با اندازه قلم ضخیم – خوب عمل میکند. میتوانید از رنگهای مختلف برای جدا کردن برچسبها از بخشهای اصلی اسکچ استفاده کنید.
یا ممکن است برخی "توضیحات فراخوان" (call-outs) را اضافه کنید تا امکان بحث در مورد عناصر خاص را فراهم کنید.
مؤلفه ۴. گودال خرگوش (Rabbit holes)
گاهی اوقات پرداختن به یک "گودال خرگوش" (rabbit hole) فقط به چند خط متن نیاز دارد. به عنوان مثال، در پروژه فرم پرداخت فوق، "شکلدهندگان" (shapers) میخواستند یک راهحل خاص برای نحوه ایجاد URLها را مشخص کنند. URLها هرگز برای نسخه ۱ پروژه روی دامنههای سفارشی قرار نمیگرفتند. این نوعی از چیزهاست که برای مفهوم اصلی حیاتی نیست، اما توضیح دادن آن یک "گودال خرگوش" بالقوه را برطرف میکند.
مؤلفه ۵. ممنوعهها (No Gos)
در نهایت، اگر چیزی وجود دارد که ما در این مفهوم انجام نمیدهیم، خوب است که در اینجا به آن اشاره کنیم. در مورد پروژه فرم پرداخت، تیم از قبل تصمیم گرفت که هیچ نوع ویرایش WYSIWYG (آنچه میبینید همان چیزی است که دریافت میکنید) را برای فرم مجاز ندانند. کاربران فقط میتوانستند یک لوگو ارائه دهند و متن هدر را در یک صفحه "سفارشیسازی" جداگانه شخصیسازی کنند. WYSIWYG ممکن است از نظر برخی افراد بهتر باشد، اما با توجه به زمانبندی (appetite)، مهم بود که این مورد را به عنوان "ممنوعه" (no-go) علامتگذاری کنیم.
نمونهها
در اینجا دو نمونه از پیچ های واقعی آورده شده است.
این پیچ برای گروهبندی تسکها (to-dos) با نشان دادن راهکاری که مردم در طراحی فعلی استفاده میکنند، آغاز میشود. سپس تمام ایدههای اصلی برای فعال کردن گروهبندی اختیاری تسکها را ترسیم میکند.
این پیچ برای تغییر نحوه کار نوتیفیکیشنها با دو ویدئو برای نشان دادن مشکل شروع میشود. کادرهای سیاه در انتها تجسمی از دادههای رفتار کاربر هستند که از یک تصمیم در پیچ پشتیبانی میکند.
آماده برای ارائه
گام بعدی این خواهد بود که اثبات کنیم این پیچ یک "شرط ارزشمند" (bet worth making) را توصیف میکند. این میتواند به چند روش اتفاق بیفتد.
ما به طور پیشفرض ارتباط نامتقارن (asynchronous communication) را ترجیح میدهیم و تنها در صورت لزوم به زمان واقعی (real-time) ارتقا میدهیم. این به هر کس حداکثر زمان تحت کنترل خود را برای انجام کار واقعی میدهد. این بدان معناست که اولین قدم برای ارائه یک پیچ، ارسال متن کامل با تمام مؤلفههای فوق در مکانی است که ذینفعان بتوانند آن را در زمان خود بخوانند. این کار "میز تصمیمگیری" (betting table) را کوتاه و پربار نگه میدارد. در شرایط ایدهآل، همه زمان کافی برای خواندن پیچ را از قبل دارند. و اگر در برخی موارد این امکانپذیر نباشد، پیچ آماده است تا برای یک فروش سریع زنده (live sell) ارائه شود.
ما چگونه آن را در بیسکمپ انجام میدهیم
ما پیچ ها را به عنوان پیامها (Messages) در بیسکمپ ارسال میکنیم. ما یک "دسته پیام" (Message Category) با عنوان "پیچ" ایجاد کردهایم تا بتوانیم به راحتی آنها را پیدا کنیم. پیچ ها در یک "تیم" (Team) به نام "استراتژی محصول" (Product Strategy) پست میشوند که افراد حاضر در "میز تصمیمگیری" (betting table) میتوانند به آن دسترسی داشته باشند.
هنگامی که نیاز به گنجاندن یک اسکچ ماژیک ضخیم در یک پیچ داریم، آن را روی iPad (با استفاده از Notability) ترسیم کرده و یک اسکرینشات میگیریم.
ویرایشگر متن بیسکمپ وارد کردن تصاویر و افزودن کپشن به آنها را آسان میکند تا در جریان پیچ معنی پیدا کنند.
افراد به طور نامتقارن (asynchronously) روی پیچ نظر میدهند. نه برای "بله" یا "خیر" گفتن – این در "میز تصمیمگیری" اتفاق میافتد – بلکه برای یافتن ایرادات یا کمک به اطلاعات از دست رفته.
مدیر ارشد فنی ما (CTO) با افکار فنی خود به پیچ پاسخ میدهد
در فصل بعدی، فرآیند "شرطبندی" (betting process) را با جزئیات بیشتری بررسی خواهیم کرد تا ببینیم پیچ ها به کجا میروند و چگونه آنها را به پروژههای برنامهریزیشده تبدیل میکنیم.
