زمانی که کار را شکل میدهیم (shape)، باید آن را در سطح مناسبی از انتزاع انجام دهیم: نه خیلی مبهم و نه خیلی ملموس. مدیران محصول اغلب در یکی از این دو افراط اشتباه میکنند.
زمانی که رهبران طراحی مستقیم سراغ وایرفریمها یا ماکاپهای با جزئیات بالا میروند، جزئیات زیادی را خیلی زود تعریف میکنند. این کار فضایی برای خلاقیت طراحان باقی نمیگذارد. یکی از دوستان این موضوع را اینگونه بیان کرد:
من یک وایرفریم به طراح میدهم و بعد به او میگویم: «میدانم که داری به این نگاه میکنی، اما این چیزی نیست که میخواهم طراحی کنی. میخواهم آن را دوباره فکر کنی!» انجام این کار وقتی داری یک چیز ملموس به آنها میدهی، سخت است.
مشخص کردن بیش از حد طراحی همچنین منجر به خطاهای برآورد میشود. هرچند ممکن است غیرمنتظره به نظر برسد، اما هرچه کار مشخصتر باشد، برآورد آن سختتر میشود. این به این دلیل است که دقیقاً انجام دادن یک رابط کاربری ممکن است نیازمند حل پیچیدگیهای پنهان و جزئیات پیادهسازی باشد که در ماکاپ قابل مشاهده نبودهاند. وقتی دامنه کار (scope) متغیر نباشد، تیم نمیتواند تصمیم طراحیای را که معلوم میشود هزینهاش بیشتر از ارزشش است، بازنگری کند.
در سوی دیگر طیف، پروژههایی که بیش از حد مبهم هستند نیز کار نمیکنند. وقتی یک پروژه در چند کلمه تعریف میشود، هیچکس نمیداند دقیقاً به چه معناست. عباراتی مانند «ساخت یک نمای تقویم» یا «اضافه کردن اعلانهای گروهی» معقول به نظر میرسند، اما دقیقاً چه چیزی را شامل میشوند؟ اعضای تیم اطلاعات کافی برای تصمیمگیری در مورد مبادلات (trade-offs) را ندارند. آنها نمیدانند چه چیزی را شامل کنند یا چه چیزی را کنار بگذارند. یک برنامهنویس که در چنین وضعیتی کار کرده بود، گفت:
شما دارید مشکلی را بدون هیچ زمینهای حل میکنید. باید ذهنخوان باشید. انگار که: «وقتی ببینیم، میفهمیم چیست.»
در مورد برآورد، پروژههایی که به درستی مشخص نشدهاند به طور طبیعی از کنترل خارج میشوند، زیرا هیچ مرز مشخصی برای تعیین آنچه خارج از دامنه (out of scope) است، وجود ندارد.
بیایید به مثالی نگاه کنیم که چگونه یک پروژه را در سطح مناسبی از جزئیات شکل دهیم.
ما نسخه سوم بیسکمپ (Basecamp) را بدون قابلیت تقویم راهاندازی کردیم. این نسخه یک ویژگی «برنامه (schedule)» داشت که فقط رویدادها را یکی پس از دیگری بدون هیچ نوع شبکه ماهانه، هفتگی یا روزانه فهرست میکرد.
اندکی پس از راهاندازی، مشتریان شروع به درخواست «اضافه کردن تقویم» به بیسکمپ کردند. ما قبلاً تقویم ساخته بودیم و میدانستیم که چقدر پیچیده هستند. ساخت یک تقویم مناسب به راحتی میتواند شش ماه یا بیشتر طول بکشد.
اینها از جمله مواردی هستند که یک تقویم را پیچیده میکنند:
• کشیدن و رها کردن رویدادها بین سلولها برای جابجایی آنها
• پیچیدن رویدادهای چندروزه به دور لبه صفحه نمایش
• نماهای مختلف برای مقیاسهای زمانی ماهانه، هفتگی یا روزانه
• کشیدن لبه یک رویداد برای تغییر مدت زمان آن
• کدگذاری رنگی رویدادها برای دستهبندیهای مختلف
• مدیریت انتظارات مختلف برای تعاملات دسکتاپ در مقابل موبایل
نسخههای قبلی بیسکمپ تقویم داشتند، و تنها حدود ۱۰ درصد از مشتریان از آنها استفاده میکردند. به همین دلیل ما تمایلی به صرف شش ماه روی تقویم نداشتیم. از طرف دیگر، اگر میتوانستیم کاری انجام دهیم تا آن دسته از مشتریانی که به ما نامه مینوشتند را در یک چرخه شش هفتهای راضی کنیم، آماده بودیم آن را انجام دهیم.
با تنها شش هفته زمان کاری، ما میتوانستیم تنها حدود یکدهم آنچه مردم وقتی میگویند «تقویم» به آن فکر میکنند را بسازیم. سوال این شد: کدام یکدهم؟
ما تحقیقاتی انجام دادیم (که در فصل بعدی مورد بحث قرار میگیرد) و یک مورد استفاده (use case) را که میخواستیم حل کنیم، محدود کردیم. در نهایت به یک مفهوم امیدوارکننده رسیدیم که از تقویمهای روی تلفنها الهام گرفته شده بود. ما میتوانستیم یک نمای شبکهای دوماهه و فقط خواندنی بسازیم. هر روزی که رویدادی داشت، برای هر رویداد یک نقطه (dot) خواهد داشت. لیستی از رویدادها زیر تقویم ظاهر میشد و با کلیک روی روزی که نقطه داشت، رویدادهای آن روز به نمایش درمیآمدند. ما آن را شبکه نقطهای (Dot Grid) نامیدیم.
شبکه نقطهای یک تقویم با تمام قابلیتها نبود. ما اجازه کشیدن رویدادها بین روزها را نمیدادیم. رویدادهای چندروزه را در سراسر شبکه گسترش نمیدادیم؛ فقط نقاط را تکرار میکردیم. هیچ کدگذاری رنگی یا دستهبندی برای رویدادها وجود نداشت. ما با تمام این مبادلات (trade-offs) راحت بودیم، زیرا درک کاملی از مورد استفاده داشتیم.
این سطح از جزئیات بود که ما برای تعریف راهحل استفاده کردیم:
![[تصویر: طرح اولیه مفهوم Dot Grid که بسیار ساده و شامل خطوط و نقاط است]](https://files.virgool.io/upload/users/9304/posts/vfmebvgfikmf/hwuhlapqeuma.png)
توجه کنید که طرح چقدر اولیه است و چه جزئیات زیادی حذف شدهاند. طراح فضای زیادی برای تفسیر نحوه ظاهر و حس این طرح داشت.
در عین حال، توجه کنید که ایده چقدر خاص است. بسیار واضح است که چگونه کار میکند، چه چیزی باید ساخته شود، چه چیزی شامل میشود و چه چیزی حذف میشود.
در پایان پروژه، کار تکمیلشدهای که طراحان و برنامهنویسان ایجاد کردند، اینگونه به نظر میرسید:
![[تصویر: اسکرینشات Dot Grid در زمان راهاندازی که شامل نمای تقویم دو ماهه با نقاط و لیست رویدادها در پایین است]](https://files.virgool.io/upload/users/9304/posts/vfmebvgfikmf/lccffsq5ibpt.png)
این مثال کوچک چند ویژگی کار شکلیافته را برجسته میکند.
کار در مرحله شکلدهی خام و اولیه است. هر کسی با نگاه کردن به آن میتواند تشخیص دهد که ناتمام است. آنها میتوانند فضاهای باز را ببینند که کمکهایشان در آنجا قرار خواهد گرفت. کاری که خیلی ریزبینانه و زودتر از موعد باشد، همه را به جزئیات اشتباه متعهد میکند. طراحان و برنامهنویسان به فضای کافی نیاز دارند تا قضاوت و تخصص خود را هنگام شروع کار و کشف تمام مبادلات واقعی که پدیدار میشوند، به کار گیرند.
با وجود خام و ناتمام بودن، کار شکلیافته به طور کامل مورد تفکر قرار گرفته است. تمام عناصر اصلی راهحل در سطح کلان وجود دارند و به یکدیگر متصل میشوند. کار تا سطح وظایف فردی مشخص نشده است، اما راهحل کلی به طور کامل توضیح داده شده است. در حالی که ممکن است همچنان غافلگیریهایی رخ دهد و مشکلات پنهانی (icebergs) ظاهر شوند، جهتگیری واضحی وجود دارد که نشان میدهد چه کاری باید انجام شود. هر گونه سوال باز یا مسیرهای فرعی (rabbit holes) که از ابتدا قابل پیشبینی بودند، حذف شدهاند تا خطر پروژه کاهش یابد.
در نهایت، کار شکلیافته نشان میدهد که چه کاری نباید انجام شود. به تیم میگوید کجا متوقف شود. یک اشتها یا سقف زمانی مشخص (appetite) وجود دارد – میزان زمانی که تیم مجاز به صرف آن روی پروژه است. تکمیل پروژه در این مدت زمان ثابت، نیازمند محدود کردن دامنه (scope) و حذف موارد خاص است.
در مجموع، خام بودن کار، فضایی برای تیم باقی میگذارد تا تمام جزئیات را حل و فصل کند، در حالی که راهحل و مرزها مانند نردههای محافظ عمل میکنند. آنها خطر را کاهش میدهند و تلاشهای تیم را هدایت میکنند، و اطمینان میدهند که آنها بیش از حد نمیسازند، سرگردان نمیشوند یا گیر نمیکنند.
شکلدهی کاری خلاقانه و یکپارچهساز است. این کار نیازمند ترکیب ایدههای رابط کاربری با امکانات فنی و اولویتهای کسبوکار است. برای انجام این کار، باید خودتان این مهارتها را به عنوان یک متخصص همهکاره داشته باشید یا با یک یا دو نفر دیگر همکاری کنید.
شکلدهی در درجه اول کار طراحی است. مفهوم شکلیافته، یک طراحی تعاملی (interaction design) است که از دیدگاه کاربر دیده میشود. این کار مشخص میکند که ویژگی چه کاری انجام میدهد، چگونه کار میکند و کجا در جریانهای موجود قرار میگیرد.
برای شکلدهی نیازی نیست برنامهنویس باشید، اما باید سواد فنی داشته باشید. باید بتوانید قضاوت کنید چه چیزی ممکن است، چه چیزی آسان است و چه چیزی سخت. دانش در مورد نحوه عملکرد سیستم به شما کمک میکند فرصتها یا موانع پیادهسازی ایده خود را ببینید.
این کار همچنین کاری استراتژیک است. تعیین سقف زمانی و ارائه یک راهحل مستلزم این است که در مورد مشکل منتقدانه فکر کنید. چه مشکلی را میخواهیم حل کنیم؟ چرا اهمیت دارد؟ چه چیزی موفقیت محسوب میشود؟ کدام مشتریان تحت تأثیر قرار میگیرند؟ هزینه انجام این کار به جای کار دیگر چقدر است؟
شکلدهی یک فرآیند خلاقانه و پشت درهای بسته است. ممکن است تنها باشید و روی کاغذ طرح بزنید یا در کنار یک همکار صمیمی جلوی وایتبورد باشید. نمودارهای اولیه و نامفهوم در مقابل شما خواهند بود که هیچکس خارج از اتاق قادر به تفسیر آنها نخواهد بود. هنگام کار با یک همکار، سریع حرکت میکنید، رک و راست صحبت میکنید و از یک موقعیت امیدوارکننده به دیگری میپرید. این نوع کار خصوصی، اولیه و خام است.
نمیتوان کار شکلدهی را واقعاً زمانبندی کرد، زیرا ذاتاً کار شکلنگرفته پرخطر و ناشناخته است. به همین دلیل ما دو مسیر جداگانه داریم: یکی برای شکلدهی و دیگری برای ساخت. در هر چرخه شش هفتهای، تیمها کاری را میسازند که قبلاً شکل گرفته است و شکلدهندگان روی کارهایی کار میکنند که تیمها احتمالاً در چرخههای آینده خواهند ساخت. کار در مسیر شکلدهی خصوصی نگه داشته میشود و با تیم گستردهتر به اشتراک گذاشته نمیشود مگر اینکه تعهد به سرمایهگذاری (bet) روی آن انجام شده باشد. این امر به شکلدهندگان این امکان را میدهد که کار در حال انجام را کنار بگذارند یا زمانی که نتیجه نمیدهد، آن را رها کنند.
شکلدهی چهار مرحله اصلی دارد که در چهار فصل بعدی به آنها خواهیم پرداخت.
• تعیین مرزها. ابتدا مشخص میکنیم که ایده خام چقدر زمان میارزد و چگونه مشکل را تعریف کنیم. این کار مرزهای اساسی را برای شکلدهی به ما میدهد.
• عناصر را به صورت اولیه طرحریزی کنید. سپس کار خلاقانه طرحریزی یک راهحل میآید. این کار را در سطح انتزاعی بالاتری نسبت به وایرفریمها انجام میدهیم تا سریع حرکت کنیم و طیف وسیعی از امکانات را بررسی کنیم. خروجی این مرحله، ایدهای است که مشکل را در محدوده سقف زمانی (appetite) حل میکند، اما بدون تمام جزئیات دقیق.
• خطرات و مسیرهای فرعی را بررسی کنید. هنگامی که فکر کردیم راهحلی داریم، با دقت آن را بررسی میکنیم تا حفرهها یا سوالات بیپاسخی را پیدا کنیم که میتوانند تیم را به مشکل بیندازند. راهحل را اصلاح میکنیم، چیزهایی را از آن حذف میکنیم، یا جزئیات را در نقاط دشوار خاص مشخص میکنیم تا از گیر افتادن یا اتلاف وقت تیم جلوگیری کنیم.
• پیشنهاد (Pitch) را بنویسید. هنگامی که فکر کردیم آن را به اندازه کافی برای احتمال سرمایهگذاری شکل دادهایم، آن را با یک نوشته رسمی به نام پیشنهاد (pitch) بستهبندی میکنیم. این پیشنهاد مشکل، محدودیتها، راهحل، مسیرهای فرعی و محدودیتها را خلاصه میکند. پیشنهاد برای بررسی به میز سرمایهگذاری (betting table) میرود. اگر پروژه انتخاب شود، پیشنهاد میتواند در شروع پروژه (kick-off) برای توضیح پروژه به تیم مجدداً استفاده شود.
