چند وقتیه ذهنم درگیر این مسئله است که آیا واقعا آب اسکرام و طراحی محصول توی یک جوی می‌ره یا نه؟
آیا باید همراه با تیم فنی و محصول توی اسپرینت‌ها کار کرد؟ یا باید یکی دو اسپرینت جلوتر از تیم بود؟ آیا باید به صورت جداگانه اسپرینت داشت؟ آیا اصلا طراحی محصول توی اسکرام می‌گنجه؟
بعد از کلی فکر کردن و خوندن و حتی تلاش برای فراموش کردن این مسئله ، به این نتیجه رسیدم که این هم مانند همه مسائل دنیای محصول، جواب قطعی و نسخه‌ی پیچیده‌ای نداره. ضمن اینکه تعریف مشخص و جهان‌شمولی برای همه وظایف طراح محصول هم وجود نداره، و این تعریف برای هر موقعیت شغلی منوط به فاکتورهایی مثل تجربه قبلی، تیم فعلی، محصول فعلی و... فرق داره. بعضی بیشتر به سمت طراحی رابط کاربری بعضی بیشتر به سمت تجربه کاربری کشیده می‌شن. اگر می‌خواهید نظر من رو درباره طراح محصول بدونید این مطلب من رو، که برای ۲ سال پیشه، بخونید. کما بیش هنوز درسته.
برگردیم به بحث رقص اسکرام و طراحی محصول، شاید حتی این موضوع در اکثر مواقع اصلا به اسکرام و دیزاین ربطی نداره و در واقع هر دوی اینها با مشکل بزرگتری مواجه هستند. خلاصه فاکتورهای زیاد دخیل هستن و سعی کردم در این مطلب آروم آروم تصویر کلی از موقعیت رو نشون بدم.
امروز مطلبی می‌خوندم از یکی از فعالین اسکرام که در این رابطه سعی کرده بود با زبان شیرین اکثر اجایل‌کوچ‌ها (که باور دارن این اسکرامِ واقعی نیست و این شما و برداشتتون از اسکرامه که مشکل داره)، این مشکل رو با یه راه حل ساده حل کنه. کامنت‌های این مطلب رو هم خوندم و دیدم تنها من نیستم که فکرم درگیر شدنی یا نشدنی بودن این مسئله است.
وقتی با یک اسکرام مستر، مربی چابک یا چیف اسکرام آفیسر (یا هر اسم دیگه‌ای) بحث کنیم می‌بینیم که همه چیز شدنیه و همه مسائل قابل حلن. شاید همون لحظه انرژی بگیریم و بریم ساختار تیم و محصول رو بازنگری کنیم، یک جلسه فوری بگذاریم و این ایده‌های محشر رو با تیم در میون بگذاریم و بعد از اینکه باور کردیم مشکل از خودمونه، با شرمندگی همه مثل شوالیه‌های عدالت دست‌ها و شمشیرهامون رو روی میز بذاریم و برای اسپرینت بعدی سعی کنیم همه مسائل رو حل کنیم. ولی مطمئنم در رتروی یکی دو اسپرینت بعدی باز هم شروع به غر زدن خواهیم کرد.
سال‌هاست هم به عنوان طراح و هم مدیر محصول و هم در یکی دو مورد به عنوان صاحب کسب و کار فعالیت کردم و سعی کردم دیزاین رو توی مفهوم اسکرام جا بدم، در بعضی موارد یا زمان‌ها موفق بودم و در بعضی نه.
به نظر من واقعیت اینه که اسکرام، یک زیربنا و فریم‌ورک خیلی ساده ولی محکم، فوق‌العاده و اثبات شده برای تولید محصولیه که بک‌لاگش مشخص باشه.
فکر می‌کردم شاید این موضوع فقط در ایران اتفاق می‌افته، ولی الان هم که در یک استارتاپ خارجی کار می‌کنم که در حال تبدیل شدن به یونیکورنه و بیش از ۱۶ تیم محصول مجزا و ۱۶ نفر طراح محصول و ۲۰۰ نفر تیم تکنولوژی داره، باز هم این مشکل رو می‌بینم. البته که نه به اندازه ایران. چرا؟ در آخرای مطلب بهش می‌پردازم.
به هرحال بعد از همه این سال‌ها و تلاش‌ها می‌بینم که بیشتر در مواقعی که Specها و جزئیات محصول به طور کامل مشخص نبودن این تلاش برای گنجاندن دیزاین در اسکرام ناموفق بود.
اما مشخص نبودن Spec ها عموما به دلیل کم‌کاری یا کم تخصصی یا نادانی نیست. در بسیاری موارد ماهیت محصول به تدریج و در حین طراحی/تولید، یا بعد از عرضه اولین نسخه و با فیدبک بازار کامل میشه، بارها این اتفاق می‌افته که بعد از دیدن طراحی، برداشت‌ها تغییر می‌کنه و مسیر جدیدی ایجاد میشه، که این تغییرات روند رو به تعویق می‌اندازه یا بهم می‌زنه. بارها میشه که یک عامل خارجی (مثل قوانین جدید، رقیب جدید و..) باعث میشه تصمیمات جدید گرفته بشه -و درسته که اجایلیتی یعنی واکنش سریع به همین اتفاقات- اما چیزی که نادیده گرفته میشه اینه که تصمیم جدید یعنی طراحی جدید، یعنی تست‌های کاربری جدید، یعنی فیدبک جدید و خیلی کارهای جدید دیگه. درواقع تصمیمات جدید و فوری همیشه -همیشه- درصد بالایی از ابهام و عدم قطعیت رو با خودشون دارن که معمولا در ابتدا نادیده گرفته می‌شن. و این ابهام‌ها معمولا خودشون رو بعد از طراحی و وقتی که برنامه‌ریزی کردی پیاده سازی رو شروع کنی نشون می‌دن.
یک نکته مهم دیگر هم اینه که دیزاین فقط «مال» طراح‌ها نیست و خیلی از موارد هست که تیم فنی نقش مهمی در طراحی ایفا می‌کنن و یک سری گره‌های دیزاین و ابهام‌های تجربه کاربری وقتی حل میشه که دولوپر و دیزاینر با هم سعی و خطا می‌کنن، نتیجه کارشون رو می‌بینن و تصمیم‌گیری می‌کنن که این باز هم توی اسکرام یا دقیق‌تر در مفهوم اسپرینت سخت می‌گنجه.
احتمالا می‌گید که همه این شک و تردیدها باید توسط مدیر محصول و دیزاینر و قبل از ورود به مرحله تولید حل بشه و هر وقت خیالتون راحت شد کار رو به تیم فنی بسپرید. اگر اجایل‌کوچ هستید هم که قطعا می‌گید برای همه این مسائل راه حل از قبل موجوده و شما برداشتتون از اسکرام اشتباهه.
درست می‌گید اسکرام گسترده‌تر از محدوده‌ی تیم فنیه، و درست همینجاست که مشکل اکثر تیم‌ها و شرکت‌ها نمایان میشه. برای حل کردن این موضوع بیرون از تیم فنی و بردن این مفهوم به لایه‌های قبل‌تر (مثل مدیر محصول و طراح محصول) مفاهیمی مثل دیزاین اسپرینت اومدن که سعی می‌کنن مدیریت محصول رو به سمتی ببرن که قبل از تولید و عرضه گسترده محصول، از دنیای واقعی فیدبک بگیریم و مسئله رو شفاف‌تر ببینیم و راه‌حل‌ها رو دقیق‌تر کنیم. خیلی جذابن ولی باز در دنیای واقعی و درحال پیشرفت ما، چقدر تیم‌های محصول به این مسائل پایبندن؟ آیا ما اصلا تیم‌های محصول مستقل و قدرتمند در شرکت‌های متوسط و کوچیک داریم؟ تیمی که مسئول پیدا کردن نیازهای مشتری و پیدا کردن راه‌حل باشه؟ به نظر من اکثر تیم‌های محصول (شامل مدیر، مالک و طراح محصول) فقط مترجم خواسته‌ها و برداشت‌های رادیکال صاحب کسب و کار برای تیم فنی هستند. یعنی نقشی در کشف مسئله و پیدا کردن راه حل ندارند (می‌دونم خیلی نظر رادیکالیه، ولی قبول کنید اکثر محصولی‌ها این کار رو می‌کنن)، درواقع چاره‌ی دیگه‌ای ندارند چون صاحب کسب و کار و سرمایه‌گذارها اونقدر بالغ نیستن که این تصمیمات رو به کس دیگه‌ای بسپارن یا حتی از دانش اونها در تصمیم‌گیری خودشون استفاده کنن. بیشتر فعالیت حل مسئلهی تیم محصول به چارچوب ایده‌پردازی در یک اپلیکیشن یا وبسایت محدود میشه و درباره خلق ارزش و طراحی یک ارزش برای مشتری از ابتدا تا انتها (خارج و داخل چارچوب اپ یا وبسایت) رو شامل نمی‌شه.
تیم‌هایی رو دیدم که این مسئله رو سعی کردن حل کنن، و دیگه مسائلی رو به تیم فنی می‌سپرن که تا درصد بالایی از صحت راه حلش اطمینان دارن و طراحی محصول کامل و دقیق تست شده و آماده‌ی پیاده‌سازیه، عموما در شرکت‌هایی هست که از مرحله‌های بحرانی رد شدن و تیم محصول قدرتمندی ساختن، یا اینکه در مرحله‌ای از بلوغ محصولشون هستند که دیگه تصمیم‌ها و چرخش‌های ناگهانی و همینطور ابهامی در نوع ارزشی که ارائه می‌کنن وجود نداره یا در موارد نادر صاحب کسب و کار به قدری بالغ بوده که کار رو به کاردان سپرده، یا اینکه بعد از کلی اتلاف وقت و هزینه به خودش و همه ثابت کرده که توی تصمیم‌گیری برای کاربر خوب نیست و بلخره ول کرده?.
فرض بگیریم که مشکلاتی که در فهم اسکرام هست، با کمک و تلاش اجایل کوچ و دل دادن همه اعضای تیم‌ها حل بشه و شوالیه‌های عدالت کارشون رو درست انجام بدن، تا وقتی یکی از وضعیت‌های اورژانسی یا خارج از برنامه اتفاق بی‌افتن، اینجاست که متوجه یک مشکل دیگه در لایه‌ی قبل‌تر می‌شیم. همون لایه‌ی مالک کسب و کار، مدیرعامل، سرمایه‌گذار و... اینجا جاییه که من بارها دیدم اجایل‌کوچ‌ها و اسکرام کاملا شکست خوردن. همه زیرساخت‌ها رو آماده کردن، ماه‌‌ها با تیم کلنجار رفتن و تونستن فرهنگ اجایل رو ایجاد بکنن ولی درست در لحظه‌ای که همه‌چی آماده حرکت کردنه، توسط مدیرعامل، سرمایه‌گذار و... تحت فشار قرار می‌گیرن، تصمیم‌ها عوض میشه، و دوباره چرخه معیوب میشه و انگشت اتهام به سمت اسکرام‌مستر و اجایل کوچ می‌چرخه.
اینجا اتفاقا نمی‌خواهم که مشکل کار نکردن اسکرام و طراحی محصول رو بندازم گردن مالک کسب و کار و سرمایه‌گذار. اگر به اندازه‌ی کافی در اکوسیستم(هم ایران هم خارج از ایران) کار کرده باشید می‌بینید که اکثر تصمیم‌های مهم و جهت‌گیری‌ها رو اشخاص دیگه تعیین می‌کنن. بعضی وقتا خوب، بعضی وقتا بد. من شخصا به این باور دارم که یک محصول هر چقدر هم دارای بهترین تیم محصول و فنی باشه، در نهایت کاملا در جهت فکری صاحب(ین) اصلیش حرکت می‌کنه و شبیه اون(ها) میشه. و همیشه اونها تصمیم درست رو (از دید ما) نمی‌گیرن.
بهرحال کماکان دنیای محصول از قوانین بیزینسی قدیمی پیروی می‌کنه و روابط، رقابت، قدرت، تبلیغات و شیطنت بخش مهمی از اونه. پس خیلی طبیعیه که همه تصمیمات رو مدیر محصول و طراح محصول بر اساس نیازهای واقعی مشتری نمی‌گیرن و برخی موارد هم باید توسط مالک با فشار اعمال بشه (من هم خیلی آرمانی فکر می‌کنم و از این دخالت‌ها متنفرم ولی خب تجربه می‌گه باید بعضی وقتها موافق نبود ولی عمل کرد).
شاید در خارج از ایران، در لایه مدیرعامل/سرمایه‌گذار مشکلات کمتری هست و مالک‌ها و سرمایه‌گذارها بالغ‌تر هستند و خوب باعث می‌شن چرخ‌دنده‌ها به درستی و با آرامش کافی بچرخن. البته ناگفته نماند که معمولا آدم‌هایی هم به اون طبقه از زنجیره‌ی تصمیم‌گیری رسیده‌ان که تجربه و دانش کافی برای این کار رو دارن. نکته مهم‌تر اینکه سرمایه بیشتری هم هست و باعث میشه نگرانی بابت اتلاف هزینه برای روغن‌کاری این چرخ‌دنده‌ها وجود نداشته باشه.
حالا که یه‌کم وضعیت رو توضیح دادم، می‌تونم بگم که اسکرام باید در تمام سازمان جریان داشته باشه تا باعث بشه همه چرخ‌دنده‌ها درست کار کنن. در این حالتِ ایده‌آل، تیم طراحی محصول به اندازه کافی آزادی عمل داره و بخش اعظم کارش خارج از اسکرام انجام میشه و همیشه جلوتر از تیم فنی در حال مکاشفه، پیدا کردن مسائل و راه‌حل‌ها هستند و خوراک برای تصمیم‌گیری‌های کلان مدیران ارشد محصول و مدیران ارشد‌تر و حتی سرمایه‌گذار تولید می‌کنند، و پس از اینکه تصمیم گرفته شد و مسیر مشخص شد، می‌تونه در غالب اسکرام به پیاده‌سازی بصری و ارتباط با تیم فنی برای پیاده‌سازی نهایی بپردازه.
به هرحال مسئلهی هر سازمان می‌تواند کار نکردن یک یا چند تا از این چرخ‌دنده‌ها باشه، چرا؟ چون دنیا جای بی‌نقصی نیست. و البته که درست کار کردن چرخ‌دنده کوچک اما مهمی مثل مدیرعامل/سرمایه‌گذار می‌تونه همه تعاریف رو خراب کنه و همه ناراضی باشند.
سوال اول این بود که آیا آب اسکرام و طراحی محصول توی یک جوی می رن یا نه؟ اما الآن سوال اصلی اینه که آیا آب محصول (فنی/اسکرام/طراحی) با مالکین کسب و کار توی یک جوی می‌رن یا نه؟ و شاید سوال بعدی اینه که کانفلیکت طراحی و مدیریت محصول با قوانین بیزینس سنتی چجوری باید حل بشه؟
در نهایت اینکه توی این مطلب تلاشی برای پیدا کردن راه حل نمی‌بینید و سعی کردم که کسی برداشت نکنه با اسکرام و اجایل مشکل دارم، بلکه تو این متن بیشتر سعی کردم نشون بدم چطور فاکتورهای مختلف در سطوح مختلف می‌تونن اسکرامِ فوق‌العاده رو تحت تاثیر قرار بدن. باور دارم همین کلنجار رفتن‌ها برای مستقر کردن یک فریم‌ورک مثل اسکرام از هیچ‌کار نکردن بهتره و حتی شاید تنها راه ممکن فعلی باشه. شاید باید به عنوان مدیر محصول، طراح محصول و اجایل کوچ باید بیشتر سعی کنیم تا اخلاق مالکین کسب و کار رو تغییر بدیم. شاید در آینده که خودمون مالک یک کسب و کار شدیم این مشکلات رو توی خودمون و تیممون نداشته باشیم. تا اون روز بهترین گزینه اینه که سعی کنیم با داده، آمار و حقایق بعد از هر آزمون و خطا، دانش خودمون و مدیرمون رو برای ساخت محصول بالاتر ببریم.
پی‌نوشت: نقش تیم مارکتینگ رو به طور کل در این فرآیندها نادیده گرفتم، چون خودش به اندازه کافی مبحثیه.
