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

مقدمه

در چرخه تولید نرم‌افزار درک نیاز مشتری عذاب آور است چرا که تعداد زیادی مشتری با نیاز‌ها و دیدگاه‌های متفاوت وجود دارند و ما می‌خواهیم همه آن‌ها را جذب خود کنیم و بهترین باشیم، از طرفی طراحی محصول هم دشوار است چرا که پلتفرم‌های زیادی در اندازه‌های مختلف وجود دارند و سطح درک و هوش کاربران هم در استفاده از آن‌ها متفاوت است، از طرفی روند توسعه و دولوپ هم بسیار پیچیده است زیرا تعداد زیادی تکنولوژی و فریمورک و ابزار وجود دارد که باید ابتدا با همدیگر هماهنگ شده و سپس با نیاز ما هماهنگ شوند. تست کردن هم به خاطر حجم بالای کار تکراری، خسته کننده است و ریلیز کردن یا همان عرضه محصول در محیط واقعی هم به خاطر ریسک‌های بالا معمولا پر از دردسر و مشکل است. از طرف دیگر تیم‌های پشتیبان مانند تیم 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 کنند. 

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