چگونه یک لانچ موفق و به موقع داشته باشیم

مقدمه

در چرخه تولید نرم‌افزار درک نیاز مشتری عذاب آور است چرا که تعداد زیادی مشتری با نیاز ها و دیدگاه های متفاوت وجود دارند و ما میخواهیم همه آن ها را جذب کنیم و بهترین باشیم، از طرفی طراحی محصول هم دشوار است چرا که پلتفرم های زیادی در اندازه های مختلف وجود دارند و سطح درک و هوش کاربران هم در استفاده از آنها متفاوت است، توسعه و دولپ هم بسیار پیچیده است زیرا تعداد زیادی تکنولوژی و فریمورک و ابزار وجود دارد که باید با هم هماهنگ شوند و سپس با نیاز ما هماهنگ شوند. تست کردن هم به خاطر حجم بالای کار تکراری خسته کننده است و ریلیز کردن یا همان عرضه محصول در محیط واقعی هم به خاطر ریسک های بالا معمولا پر از دردسر و مشکل است است. از طرف دیگر  تیم های پشتیبان مانند تیم marketing و  مالی و call center و… هم حضور دارند که نقش تک تک آنها حیاتی است و هر نقصی در هر کدام از این تیم ها به شدت به چشم می‌آید و خروجی نهایی را تحت تاثیر قرار میدهد.

همه اینها را گفتم که بدانیم ما در حال انجام یک کار گروهی با دقت بالا هستیم که قرار است در یک بازار رقابتی بزرگ موفق باشد و محدودیت های زمانی شدیدی نیز داریم که باید به آن پایبند باشیم! این همان چیزی است که به آن کار در یک محیط پیچیده (complex) میگوییم.

در تیم اسکرام بیشترین بار مدیریت این پیچیدگی بر عهده مالک محصول یا همان Product owner است و ما در اینجا سعی میکنیم نکاتی را بررسی کنیم که به او و کل تیم کمک میکند تا در همین شرایط سخت و پیچیده، نتیجه ای دلچسب و جذاب را بدست آورند.

به دنبال اهداف بروید و نه فیچر ها

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

عقل سلیم حکم میکند که در این شرایط شما باید مسئله صفحه انتخاب آدرس را حل کنید که ممکن است به خاطر هزینه بالای ارسال و یا طراحی بد صفحات باشد  که در نهایت مشتری قطعی شما را پرانده باشد.

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

جزییات اهمیتی ندارند

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

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

1. تمام توان تیم را به کار گیرید که در هر کم و زیاد کردن اطلاعات انبار و فاکتور و سفارش همه مجدد بررسی شوند تا دیگر این مشکل پیش نیاید.
2. تنها در زمان صدور فاکتور نهایی موجودی انبار را با تعداد وارد شده کاربر بررسی کنید و در صورت مغایرت به او خطا نشان دهید.
3. هر زمان این مشکل پیش آمد پشتیبان با مشتری تماس بگیرد و مشکل را توضیح دهد و بگوید میتواند تعداد کمتر را بفرستد و پول اضافه را برگرداند.

شما در درجه اول باید توالی بروز این مشکل را پیدا کنید. اگر مثلا هر ماه 2-5 بار این اتفاق می‌افتد بهترین کار راه حل سوم است اگر هفته ای چند بار این مورد را دارید راه حل دوم و اگر بعد از اجرای راه حل دوم همچنان موارد بالا بود و تعداد خطا های نمایش داده شده بالا رفت و مشتری شما را از فرایند خرید خارج کرد طبیعتا باید سراغ اجرای راه حل اول بروید.

ممکن است بگویید این چه کاریست چرا از اول مشکل را به بهترین شکل حل نکنیم؟ جواب این سوال این است که شما با زمان زیاد گذاشتن برای حل این مشکل در حقیقت دارید کار های مهمتری را عقب میاندازید که اگر آنها زودتر انجام شوند ارزش بیشتری برای شما ایجاد خواهند کرد.

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

برای درک بهتر به تصویر زیر دقت کنید:

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

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

وابستگی ها و موارد پر ابهام را حسابرسی کنید

در شرکت‌های بزرگ که چندین تیم دارند و محصول نهایی حاصل همکاری چند تیم مختلف هستند معمولا از فریم ورک های scaled agile مانند safe استفاده میکنند که به تیم ها کمک میکند با هم برنامه ریزی و کار کنند.

در این فریم ورک های scaled agile یک نکته مهم وجود دارد و آن این است که بین کار های تیم های مختلف وابستگی وجود دارد یعنی مثلا انجام کار 1 در تیم A وابسته به این است که تیم B کار 2  را انجام داده باشد. این .ابستگی متقابل بین تیم ها و کار ها باید مرتب پایش و بررسی شوند تا به حداقل ممکن برسند.

پایش و بررسی این وابستگی ها با استفاده از روش هایی مثل Program Board or Dependency Board در اسکرام بزرگشده و یا Story Map قابل انجام است.

تیم را خسته نکنید

اگر شما از لپتاپ خود بیش از اندازه کار بکشید فرسوده و خراب میشود و تازه لپتاپ یک موجود زنده با اراده نیست و یک ماشین است. انسان به مراتب نیاز های پیچیده تر و بیشتری نسبت به ماشین دارد. اضافه کاری های زیاد، فشار کاری بالا و Practice های مشابه بازدهی تیمی شما  را در طولانی مدت کاهش میدهد و نه افزایش. 

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

فرض کنید یک دولپر هستید و کشش و ظرفیت انجام 30 واحد کار را دارید حالا مدیر محصول سعی می‌کند در جلسه پلنینگ با فشار آوردن 50 واحد کار به شما بدهد. اسپرینت بعدی سعی میکنید با بزرگنمایی 30 واحد کار را 50 واحد نشان دهید تا فشار را بردارید و اینجاست که شفافیت کم و دروغ زیاد میشود و افراد را عادت میدهید به دروغ گفتن. در گام های بعدی مدیر محصول شروع که بیشتر فشار آوردن میکند که موجب ایجاد تنش در تیم میشود و در نهایت هم دولپر با پایین ترین سزح کیفی ممکن کار را تمام میکند که بدهی فنی زیادی ایجاد می‌کند و  در نهایت هزینه آن را خودتان در آینده پرداخت می‌کنید.

در هر اسپرینت یک فیچر حتی کوچک را ریلیز کنید

داشتن یک مدیریت خوب و یک زیرساخت خوب برای ریلیز اپلیکیشن بسیار با اهمیت است به طوریکه بتواتید در انتهای هر اسپرینت با کمترین زمان و هزینه یک نسخه جدید عرضه کنید تا هم مشتری شما تغییرات تدریچی را حس کند و هم تیم شما انگیزه برای ادامه دادن را داشته باشد. 

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

آماده تغییر باشید

در اسکرام یا هر متدولوژی اجایل دیگری تیم ها یک هدف را در بازار نشانه می‌گیرند و گام های رسیدن به آن را طراحی می‌کنند و شروع به توسعه می‌کنند، به طور مثال در اسکرام هر گام به صورت یک sprint در می‌آید و افراد تیم شروع به انجام هر گام میکنند تا انتهای هر اسپرینت در جلسه Sprint Review آن گام انجام شده را به stakeholder ها نشان دهند و بازخورد بگیرند.

در جلسه review این جمله زیاد شنیده می‌شود:

دستتون درد نکنه بابت زحمات و همه چیز خیلی خوب شده ولی نیازه که بعضی بخش ها عوض بشن

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

نکته مهم در اسکرام این است که انجام شدن کار یا همان مرحله done به معنای تمام شدن کار نیست بلکه ممکن است بارها و بارها تغییر انجام شود تا به نتیجه مورد انتظار برسیم و تازه بعد از آن دوباره ممکن است نیاز بازار تغییر کند و ما مجبور شویم دوباره تغییر کنیم تا با نیاز بازار هماهنگ شویم و این چرخه همانطور که در تصویر زیر مشخص است تا ابد ادامه دارد.

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

برای اینکه این  تناقض (conflict) حل شود در درجه اول باید با جزییات از چرایی و اهمیت بالای این تغییرات بگویید تا اهمیت موضوع را درک کنند بعد از آن باید پلن توسعه شفاف برای تیم داشته باشید یعنی تیم بداند چه چیز هایی قرار است در آینده اضافه شود که از حالا فکر آن را بکند و معماری سیستم  را متناسب با آن هماهنگ کند و در گام آخر باید سعی کنید خود تیم توسعه را در فرآیند تصمیم گیری تاثیرگذار باشد و صرفا تصمیمات را ابلاغ نکنید.

بین تیم های مختلف ارتباط دوستانه برقرار کنید

یک بیزینس یا همان کسب و کار اجزای بسیاری دارد که باید در کنار هم درست کار کنند تا ثمر دهد و سود کند، یکی از این تیم ها تیم توسعه نرم افراری است و بقیه تیم ها مانند پشتیبانی، بازاریابی، لجیستیک، فروش، مالی، حقوقی و… هم نقش زیادی در تجربه کاربر و مشتری دارند. 

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

برای برقراری این ارتباط برگزاری دوره ها و کلاس های مشترک آموزشی متقابل و یا مسابقات و بازی های رقابتی مثل پانتومیم و مافیا و… یا اردو های خارج از شرکت بسیار مفید خواهد بود.

به تیم توسعه زمان تنفس بدهید

زمانی که نرم افزار شما یک مرحله جدی رار رد میکند و یک قابلیت کلیدی اضافه میکند معمولا زمانی نیاز است تا این قابلیت جدید حسابی تست شود و مشتری از آن استفاده کند و فیدبک دهد. در کنار این بخش های دیگر شرکت هم معمولا باید با نسخه جدید هماهنگ شوند و این ها بسته به نوع فیچر جدید ممکن است از 4 روز تا 3 ماه طول بکشد. بهتر است این زمان به تیم توسعه داده شود تا در این مدت به جای توسعه یک فیچر جدید به رفع باگ و حل مشکلات ریلیز مشغول شود و جزییاتی که کم اهمیت بودند و اجرایشان عقب افتاده بود را پیاده کنند یا بدهی های فنی خود را حل کنند یا زمانی را صرف یادگیری و آپدیت شدن با تکنولوژی یا همان R&D کنند. 

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