اصول شیپینگ¶
فصل ۲ از کتاب شیپآپ منبع: Shape Up - Principles of Shaping
در زمان شیپینگ کار، باید آن را در مرحله صحیحی از مفهومی بودن نگه داریم: نه بیش از اندازه مبهم و نه بیش از اندازه صریح. مدیران محصول معمولا در یکی از این موارد افراط میکنند.
وایر فریم ها بیش از اندازه صریح هستند¶
زمانی که راهبران طراحی، مستقیم به سراغ وایرفریم یا موک آپ عین واقعیت (high-fidelity mockups) میروند، جزعیات بیش از اندازه ای را زودتر از زمانی که باید، تعریف میکنند. این کار هیچ فضایی برای خلاقیت به طراحان نمیدهد. یک دوست این موضوع را اینگونه بیان میکرد:
من وایر فریم را به طراحم میدهم و پس از آن به او میگویم: “من میدانم که تو این را در نظر میگیری اما این چیزی نیست که از تو میخواهم آن را طراحی کنی! من میخواهم تو دوباره درباره آن فکر کنی.” انجام دادن این کار زمانی که چیزی تا این حد صریح به طراح میدهید، خیلی سخت میشود.
مشخص کردن بیش از انداره دیزاین همچنین منجر به خطاهای تخمین میشود. بر خلاف چیزی که به نظر میرسد، هر چه کار را دقیق تر مشخص کنید، تخمین دادن برای زمان انجام آن سختتر خواهد شد. زیرا درستکردن سطح رویی، نیازمند این است که پیچیدگیها و جزعیات پنهان زیادی حل شوند که در موکآپ قابل مشاهده نبودند. اگر که اسکوپ متغییر نباشد، تیم نمیتواند بر روی تصمیمات طراحی، که مشخص میشود هزینه ای بیش از ارزش خود دارند، بازنگری انجام دهد.
کلمات بیش از اندازه مفهومی هستند¶
در انتهای دیگر این طیف، پروژه های که بیش از اندازه مبهم هستند نیز کاری از پیش نمیبرند. وقتی پروژه در چند کلمه تعریف شود، هیچکس نمیفهمد که چه معنایی دارد. “ساختن یک تقویم” یا “اضافه کردن اعلانات گروه” به نظر محسوس میآیند اما دقیقا مستلزم چه چیزهایی هستند؟ اعضای تیم به اندازه کافی اطلاعات ندارند که معامله کنند. آن ها نمیدانند چه چیزی را در نظر بگیرند و از چه چیزی صرفنظر کنند.یک برنامهنویس که در شرایط مشابهی کار کرده بود میگفت:
شما باید یک ذهن خوان باشید تا مشکل را بدون داشتن هیچ زمینه ای حل کنید. مثل این ماند که : ما زمانی که آن را ببینیم متوجه میشویم چه میخواسته ایم!
تخمین زدن زمان انجام پروژه ای که کمتر از حد لازم مشخص شده باشد، طبیعتا از کنترل خارج میشود زیرا هیچ چهارچوبی که تعیین کند چه چیزی خارج از اسکوپ است وجود ندارد.
بررسی موردی: تقویم جدول-نقطه ای¶
بایید نگاهی به یک نمونه بیندازیم که چطور باید یک پروژه را در حد صحیحی از جزعیات شیپ کنیم. ما ورژن 3 basecamp را بدون فیچر تقویم راه انداختیم. در این نسخه ما فیچر “برنامه زمانی” را داشتیم که فقط لیستی از رویداد ها را یکی پس از دیگری نمایش میداد و هیچ جدول روزانه، ماهانه و یا سالانهای برای آن وجود نداشت. زمان کوتاهی پس از راه اندازی، مشتری ها درخواست کردند که یک تقویم به basecamp اضافه کنید. ما قبلتر روی ساختن تقویمها کار کرده بودیم و میدانستیم که تا چه حد کار پیچیده و پرچالشی است. این کار به راحتی میتوانست بیش از 6 ماه از ما زمان بگیرد تا بتوانیم تقویمی مناسب طراحی کنیم.
نمونه ای از چیزهایی که ساختن تقویم را پیچیده میکرد این هاست:
- کشیدن و رها کردن (Dragging and dropping) رویداد ها بین بخش ها و جابجا کردن آنها
- جا کردن رویداد های چند روزه در اطراف گوشه های صفحه
- نماهای متفاوت برای مقیاسهای ماهانه، هفتگی و روزانه
- کشیدن گوشه رویداد برای زیاد یا کم کردن زمان آن
- رنگ بندی کردن رویداد ها برای دستهبندیهای مختلف
- حل کردن چالش کار کردن با تقویم در محیط های متفاوت دسکتاپ و موبایل
ورژنهای قبلی بیسکمپ دارای تقویم بودند اما فقط ۱۰٪ مشتریها از آن استفاده میکردند. برای همین ما به این اندازه اشتها نداشتیم که شش ماه زمان روی تقویم صرف کنیم. اما از طرف دیگر، اگر میتوانستیم کاری انجام دهیم که این دسته از مشتریان را در یک چرخه ششهفتهای راضی کند، قادر به اجرای آن بودیم.
با صرف کردن هفته بر روی این کار ما فقط میتوانستیم یک دهم چیزی را پیاده کنیم که مردم از آن به عنوان تقویم یاد میکنند. اما سوال مهم اینجا بود: کدام یک دهم را باید پیاده سازی میکردیم؟
ما مقداری تحقیق (که در بخش بعدی به آن اشاره میکنیم) انجام دادیم و مورد استفاده مشکلی که میخواستیم آن را حل کنیم، دقیق تر مشخص کردیم. سرانجام به یک مفهوم امیدوار کننده رسیدیم که آن را از تقویم گوشیهای موبایل الهام گرفته بودیم. ما میتوانستیم یک نمای دو ماهه جدولی به صورت read-only بسازیم و در روزهایی که رویداد در آن وجود داشت، برای هر رویداد یک نقطه نمایش دهیم. لیست رویداد ها در زیر تقویم نمایش داده میشد و با کلیک کردن بر روی روزی که دارای نقطه بود، نمای لیست به رویداد های مربوط به آن روز اسکرول میشد. ما اسم این تقویم را جدول نقطه ای گذاشتیم.
جدول نقطه ای یک تقویم کامل نبود. ما امکان کشیدن و رها کردن رویداد بین روزها را به کاربر نمیدادیم. ما یک رویداد چند روزه را میان روزها نمیکشیدیم: فقط نقطه ها را تکرار میکردیم. رنگ بندی مجزا برای دسته بندی رویداد ها وجود نداشت. ما به علت آگاهیمان از مورد استفاده این فیچر، به این معاملات و کم کردن امکانات راضی بودیم.
در تصویر زیر میزان جزعیاتی را که ما برای تعریف کردن راه حل از آن استفاده کردیم مشاهده میکنید:
با نگاه کردن به آن متوجه میشوید که تا چه اندازه زمخت است و تا اندازه جزعیات در نظر گرفته نشده است. طراح فضای زیادی دارد که تصمیم بگیرد این مفهوم باید چه شکلی باشد و چه احساسی را منتقل کند. به طور همزمان با نگاه کردن به آن متوجه میشوید که تا چه اندازه ایده مشخص شده است. خیلی شفاف است که این مفهوم چگونه کار میکند و برای ساخته شدن به چه چیزهایی نیاز دارد، چه چیزهایی را شامل میشود و چه چیز هایی را شامل نمیشود.
در پایان پروژه، کاری که طراحان و برنامه نویسان پیاده سازی کردن، تصویر زیر بود:
این مثال کوچک برخی ویژگی های یک کار شیپ شده را نشان میدهد.
ویژگی اول: زمخت است¶
در مرحله شیپ کردن، کار زمخت است. هر کسی با نگاه کردن به آن میتواند بگوید که کار ناتمامی است. آن ها فضاهای خالی را که میتوانند برای پر کردن آن از خلاقیت خود استفاده کنند میبینند. کاری که زیاد از حد خوب تعریف شده باشد، خیلی زود بقیه را به جزعیات اشتباهی متعهد میکند. طراحان و برنامهنویسان به فضا نیاز دارند تا بتوانند قضاوتها و تبحر خودشان را پیادهسازی کنند. در این شرایط میتوانند آستین های خودشان را بالا بزنند و معاملات واقعی را که پدیدار میشوند کشف کنند.
ویژگی دوم: حل شده است¶
کار شیپ شده در عین حالی که زمخت و تمام نشده است، بر روی آن فکر شده است. تمامی عناصر اصلی راه حل، در حد مختصری تعریف شده و به هم متصل هستند. کار به تسکهای خرد ریز نشده است اما کلیت راهحل را بیان کرده است. با این حال چالش ها هنوز ممکن است اتفاق بیفتند و کوه یخ خود را نشان دهد اما مسیر مشخصی برای انجام دادن کار تعریف شده است. تمامی سوال ها و حفره های خرگوشی(در بخش بعد درباره حفره خرگوش توضیح خواهم داد) که میتوانستیم با آن مواجه شویم حذف شده و ریسک پروژه کاهش یافته است
ویژگی سوم: چهارچوب دارد¶
در آخر، کار شیپ شده نشان میدهد که چهکاری باید و چهکاری نباید انجام شود. به تیم میگوید که چهزمانی دست نگه دارند. اشتهای مشخصی وجود دارد - زمانی که تیم اجازه دارد بر روی پروژه خرج کند تا آن را به اتمام برساند. به اتمام رساندن پروژه در زمان تعیین شده نیازمند این است که اسکوپ محدود شده باشد و چیز های به خصوصی رها شده باشند. در کنار هم، زمختی به تیم فضا میدهد که پروژه را با تمام جزعیات انجام دهند در حالی که راه حل و چهارچوبها مانند یک نرده عمل میکنند تا تیم از آن خارج نشود. چهارچوبها ریسک پروژه را کم و به تلاشهای تیم جهتدهی میکنند. آنها تضمین میکنند که تیم، چیز بیش از اندازه ای نسازد، سرگردان نشود و بر روی چیزی گیر نکند.
چه کسانی شیپ میکنند؟¶
شیپینگ کاری خلاقانه و تلفیقی است. این کار نیازمند ترکیب کردن ایده های طراحی با احتمالات فنی و اولویتهای کسبوکار است. برای انجام این کار نیاز است یک نفر به همه این مسائل مسلط باشد یا با تیمی شامل یک یا دو نفر دیگر همکاری کنید.
شیپینگ مرحله اول طراحی کار است. مفهوم شیپ شده یک طراحی تعاملی با زاویه دید کاربر است. تعیین میکند که فیچر چه چیزی است، چگونه کار میکند و چطور در جریان فعلی جای میگیرد.
برای شیپ کردن کار نیازی نیست شما یک برنامه نویس باشید اما نیاز است دانش فنی داشته باشید. شما باید توانایی این را داشته باشید که قضاوت کنید انجام دادن چه چیزی ممکن است، چه چیزی آسان است و چه چیزی سخت است. داشتن دانش درباره نحوه کار سیستم به شما کمک میکند فرصتها و موانع پیادهسازی ایدهتان را ببینید.
همچنین این کار یک کار استراتژیک است. تنظیم کردن اشتها و پیدا کردن راهحل نیازمند این است که نسبت به مشکل نگاهی انتقادی داشته باشید. میخواهیم چه چیزی را حل کنیم؟ چرا این موضوع اهمیت دارد؟ چهچیزی نشان میدهد که ما در حل مشکل موفق شدهایم؟ کدام مشتریان تحت تاثیر قرار میگیرند؟ انجام دادن این کار به جای کار دیگر چه هزینهای در بر دارد؟ شیپینگ فرآیندی دربسته و خلاقانه است. شما ممکن است در زمان پیاده سازی طرح بر روی کاغذ یا وایت برد، با یک همکار تنها باشید. در آنجا نماهای زمختی در مقابل شما قرار دارند که هیچ کس خارج از اتاق نمیتواند آن را درک کند. در زمان کار کردن با یک همکار، شما باید سریع باشید؛ باید بتوانید سریعاً صحبت کنید و از یک موقعیت به موقعیت دیگر بپرید. این کار تا حدی محرمانه، زمخت و سریع است.
دو مسیر¶
شما نمیتوانید شیپ کردن کار را همزمان با پیادهسازی انجام دهید. زیرا کار شیپنشده ذاتاً پرریسک و ناشناخته است. به همین علت ما دو مسیر کاملاً جدا داریم: یکی برای شیپ کردن و دیگری برای ساختن. در طول هر چرخه ششهفتهای، تیم کاری را پیادهسازی میکند که از قبل کاملاً شیپ شده و تیمی دیگر همزمان چیزی را شیپ میکند که میتواند برنامه چرخه بعدی باشد. شیپینگ مسیری محرمانه است و نباید تا زمانی که عناصر آن برای شرطبندی مشخص نشده است با بقیه اعضای تیم در میان گذاشته شود. این به کسانی که شیپ میکنند این انتخاب را میدهد که این کار را در طبقه در حال انجام کار (work-in-progress) قرار دهند یا زمانی که متوجه شدند عملی نیست، آن را رها کنند.
مراحل شیپینگ¶
شیپینگ 4 مرحله اصلی دارد که در بخش های بعد در مورد هرکدام توضیح میدهیم:
- چهارچوب ها را مشخص کنید: اول از همه باید بفهمیم ایده خام چقدر ارزش وقت گذاشتن بر روی آن را دارد و چگونه باید مشکل را تعریف کنیم. این کار به ما چهارچوب اساسی را میدهد که کار را در قالب آن شیپ کنیم.
- حدود تقریبی عناصر را مشخص کنید: سپس زمان کار خلاقانه اسکچ کردن راهحل میرسد. ما این کار را مفهومیتر از وایرفریمها انجام میدهیم تا سریعتر انجام شود و گستره کافی از احتمالات را بررسی کرده باشیم. خروجی این مرحله یک ایده است که میتواند مشکل را در حد اشتها حل کند اما تمام جزعیات پیادهسازی نشده است.
- ریسک ها و حفرههای خرگوش را مشخص کنید: زمانی که فکر میکنیم یک راه حل پیدا کرده ایم، نگاه عمیق تری به آن میاندازیم تا حفرهها ی خرگوش و سوالات بیجوابی را که منجر به لغزش تیم میشوند پیدا کنیم. ما راهحل را اصلاح میکنیم و چیزهایی که لازم نیستند را از آن کم میکنیم یا بخشهای گیج کننده آن را مشخصتر میکنیم تا از گیرکردن تیم و هدر رفتن زمان جلوگیری کنیم.
- ارائه را بنویسید: زمانی که مطمعن شدیم کار به اندازه کافی شیپ شده است تا بتوانیم بر روی آن شرط بندی کنیم، آن را سرجمع کرده و یک متن توضیحی برای آن مینویسیم که به آن “ارائه” میگوییم. ارائه خلاصه ای از مشکل، اضطرار، راه حل، حفره های خرگوش و محدودیت ها است. ارائه بر روی میز شرط بندی میرود تا به آن رسیدگی شود. اگر که پروژه مورد قبول واقع شود، از ارائه برای توضیح دادن پروژه به تیم استفاده میکنیم.