چابک دو مسیره؛ راه‌حلی برای «واسه‌‌ی این کارها وقت نداریم!»

مانیفست «چابک» (Agile) در سال ۲۰۰۱ منتشر و عمومی شد. علت اصلی محبوبیت این قواعد و ارزش‌ها، افزایش بهره‌وری تیم‌های cross-functional در توسعه‌ی محصول بود. اما به‌زودی طراح‌ها متوجه شدن که انجام فرآیندهای طراحی تجربه‌ی کاربر به شکل قدیمی در قالب‌هایی که بر مبنای این قواعد شکل می‌گرفتن، مثل دویدن به دنبال قطاریه که همیشه سریع‌تر از اون‌ها حرکت می‌کنه.

در این پست توضیح می‌دم که چطور در دیوار به‌مرور روش‌هایی رو شکل دادیم که فرآیندهای اکتشاف و توسعه بتونن در دو مسیر موازی با هم در تیم‌های محصولی پیش برن.

سناریوی شکست: اصلاً شما ارزش دیزاین رو نمی‌دونید!

وقتی از توسعه‌ی سریع تکنولوژی و شکل‌گیری محصولات جدید برای رقابت با هم در میدان «جذب مشتری و رسیدن به درآمد» حرف می‌زنیم، باید بپذیریم که هر کسب‌وکاری «مقرون به صرفه» بودن تمام فعالیت‌هاش رو لحاظ کنه. توسعه‌دهندگان نیروهای گرونی برای کسب‌وکارهای نوپا هستن، پس بی‌کار و معطل‌موندنشون هزینه‌ی گزافی خواهد بود.

از طرف دیگه طراحان باتجربه‌ای که بتونن به بازکردن کلاف سردرگم مسائل و شفاف‌کردن ابهام‌ها کمک کنن و جریان کارهای موازی رو با کیفیت بالایی مدیریت کنن هم برای اغلب شرکت‌های کوچیک گرون و کمیاب هستن. پس این شرکت‌ها سراغ طراحانی می‌رن که دانش و تجربه‌ی کمتر و نیاز به یادگیری بیشتری دارن.

اما معمولاً با حجم کار بسیار زیاد، اجازه‌ی نفس‌کشیدن به این طراحان داده نمی‌شه تا خودشون رو در زمینه‌ی اکتشاف، حل مسئله، دانش محصولی و «نه گفتن» به کارهایی که در راستای «نیاز کاربران» و در نتیجه «رشد کسب‌وکار» نیست، تقویت کنند. چون همیشه مشغول دویدن به‌دنبال قطار توسعه‌ی محصول هستن. (این تمثیل رو از John Schrag قرض گرفتم)

حاصل تداوم این مشکل، طراحانی هستن که فکر می‌کنن ارزش کارشون در سازمان شناخته نمی‌شه و انگیزه‌شون رو برای رشد از دست می‌دن. همچنین کارها بیشتر فرمایشی و با محوریت حدس و گمان یا دنبال‌کردن رقبا شکل می‌گیرن، فرآیندهای دیزاین که قراره به نفع کاربران و در راستای اهداف بیزینس خلق ارزش کنن بالغ نمی‌شن و در نتیجه این سازمان برای افراد باتجربه‌تر جذابیتی نخواهد داشت. چرخه‌‌ای که تکرارش رو در اکثر شرکت‌ها شاهد هستیم.

زمان‌خریدن برای فرآیند اکتشاف با جلو افتادن از توسعه

برای حل ریشه‌ی این مشکل، لازمه که برای اکتشاف و تعریف مسائل و آزمودن راه‌حل‌هامون زمان بخریم. البته نه به این معنی که بقیه‌ی اعضای تیم منتظر بشینن تا ما کارمون رو انجام بدیم. بلکه باید برنامه‌ریزی‌ای متناسب با بهره‌وری حداکثری همه‌ی تخصص‌ها به‌طور همزمان داشته باشیم.

فرآیند طراحی و توسعه‌ی محصول در تیم‌های محصولی دیوار در قالب Dual-Track Agile انجام می‌شه. طراحان در مسیر اکتشاف (Discovery) با مدیرمحصول، تحلیلگر داده و پژوهشگر، و در مسیر تحویل و توسعه (Delivery) با توسعه‌دهندگان و QA همکاری می‌کنن. برای هماهنگ‌شدن این دو مسیر، نیازه که فاصله‌ی زمانی منطقی‌ای بینشون باشه.

حداقل فاصله‌ی زمانی فرآیند دیزاین و توسعه باید چقدر باشه؟

طی این سال‌ها تجربه‌هامون نشون داد که زمان ایده‌آل برای فاصله‌ی بین شروع دیزاین یک استوری تا شروع دلیوری باید حدود دو اسپرینت (sprint) یا یک‌ماه باشه. چون:

۱- لازمه که در صورت تغییر اولویت‌ها فرصت کافی برای تغییر جهت داشته باشیم.

۲- ممکنه توسعه‌دهندگان زمان لازم برای توسعه‌‌ی یک استوری (story) رو بیشتر از چیزی که در واقعیت طول کشیده تخمین زده باشن. این باعث می‌شه استوری‌های قبلی زودتر دلیور بشن و نیاز به دیزاین بعدی داشته باشیم تا تیم معطل نمونه.

۳- ممکنه دیزاینرها زمان لازم برای دیزاین یک استوری رو کمتر از چیزی که لازمه تخمین زده باشن. چون طی فرآیند طراحی ممکنه زوایای نادیده‌ای رو ببینیم، مجبور بشیم تصمیم‌های جدید بگیریم و برای این‌کار به زمان بیشتری نیاز داشته باشیم.

۴- فرصت انجام تست کاربردپذیری و تکرارکردن (iterate) داشته باشیم. چون راه‌حل پیشنهادی اولیه لزوماً همیشه موفق نیست.

۵- دیزاینر بتونه برای انجام کارهای غیرمنتظره یا بدون قطعیت فضای تنفس داشته باشه. مثلاً بتونه با خیال راحت مرخصی بگیره یا بتونه برای استخدام یا منتورشیپ دیزاینر جدید وقت بذاره.

چرا دیزاین نباید بیشتر از یک‌فصل با توسعه فاصله داشته باشه؟

۱- غلط‌بودن فرضِ «ثبات»:
فرضِ ثبات یعنی تصور کنیم که شرایط فعلی یک مسئله تا آینده‌ی مشخصی قراره هیچ تغییری نکنن. در صورتی که چنین فرضی در طراحی و توسعه‌ی محصولات دیجیتال از اساس غلطه.
مثلاً در دیوار ممکنه تصمیم‌گیرنده‌ها (مثل مدیر محصول) تغییر کنن، اهداف و اولویت‌های تیمی یا محصولی عوض بشه، یا حتی شرایط چپترها طوری تغییر کنه که منابعی که در اختیار داشتیم رو دیگه نداشته باشیم.

۲- در نظر گرفتن هزینه‌ی فرصت:
هزینه‌ی فرصت یعنی وقتی چند مورد برای انتخاب داریم، با انتخاب یکی دستاوردها و منفعت‌های احتمالی بقیه‌ رو از دست می‌دیم. مثلاً وقتی از وقت‌گذاشتن دیزاینر روی کاری صحبت می‌کنیم که تصمیم برای توسعه‌ش سه ماه بَعد انجام می‌شه، یعنی پذیرفتیم کارهای دیگه‌ای که می‌تونن نفع سریع‌تری به محصول و تیم‌ها برسونن رو رها کنیم.

۳- سخت‌شدن مشارکت اعضای تیم در فرآیند طراحی:
چون توسعه‌دهندگان مشغول پیاده‌سازی استوری دیگه‌ای هستن و برای اون‌ها مشارکت در ایده‌پردازی و بررسی راه‌حل‌های جدید، به‌معنی وقت‌گذاشتن روی کارهای غیرفوریه. وقتی مشارکت اعضای تیم کم بشه، نمی‌تونیم امکان‌پذیری پیاده‌سازی دیزاین رو در تسک‌هایی که اطمینان از زیرساخت فنی مهمه بسنجیم. در نتیجه ساختارمون بیشتر شبیه design agency و کار پروژه‌ای می‌شه تا تیم cross-functional.

۴- فراموش‌شدن جزئیات مسئله:
وقتی بعد از گذشت چنین زمان طولانی‌ای بالاخره نوبت پیاده‌سازی استوری می‌شه، تعامل با توسعه‌دهنده‌ها و QA نیازه و این برای دیزاینر مثل اینه که دوباره با مسئله مواجه شده. هزینه‌ی switch هم زیاده چون همزمان تمرکزش روی حل مسئله‌ی دیگه‌ایه.

در مطالب آینده توضیح می‌دم که چطور این ساختار در قالب برنامه‌ریزی‌های استراتژی سالانه و اهداف فصلی شرکت می‌شینه و چه نقاط کنترلی روی تقویم شرکت برای هماهنگی همه‌ی تیم‌ها و عملکردها وجود داره.

اگر به این موضوع علاقه‌مند هستید، لطفاً هم دنبالمون کنید و هم از تجربیات و سؤالاتتون برامون بنویسید. نظراتتون می‌تونه به جهت‌دهی مطالبی که به اشتراک می‌ذاریم کمک مؤثری بکنه. حتماً می‌خونیم و پاسخ می‌دیم.