توسعه نرم‌افزار چابک با نگاه «محصول‌محور»

قصه از کجا شروع شد؟

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

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

جلسات OKR

در همین راستا و برای جلسات OKR شرکت، تیم راهبری (من یکی از اعضای تیم راهبری ابر آروانم)، دو تا پیشنهاد جدید آورد:

تغییر اول: در جلسات OKR از بچه‌ها خواستیم به جای اینکه مدیرمحصول‌ها و تیم‌لید‌ها فقط حرف بزنند و بقیه نگاه کنند (و البته گاهی توی گوشی‌هاشون باشند یا چرت بزنند) هر آیتم (Key Result) رو یکی از بچه‌ها شرح بده و بگه چه اقداماتی برای به نتیجه رسیدن یا نرسیدن اون هدف انجام شده.

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

اتصال تیم‌ها به همدیگه رو یکی از همکارانم (فاطمه خوشبخت) بر اساس ۳ اصل انتخاب کرد:

• تیم‌هایی که با هم تعارض دارند.
• تیم‌هایی که از هم دورند و از هم بی‌خبرند.
• تیم‌های فنی/اجرایی که تعارض ذاتی دارند.

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

پس اول باید با پاسخی کوتاه از این پرسش شروع کنیم، اصلن چرا باید محصول‌محور باشیم؟ پاسخ‌ دادن به این سوال ابعاد مختلفی داره، که احتمالن از حوصله این یادداشت خارجه، اما تلاش می‌کنم به اختصار به برخی از جنبه‌هاش پاسخ بدم.

آجر می‌چینم یا کلیسا می‌سازم؟

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

موضوعی که من تلاش می‌کردم به اعضای تیم‌های آروان انتقال بدم همین موضوع ساده بود. من گفتم مهم نیست شما بهترین Frontend Developer یا بهترین System Developer هستید، مهم نیست طراح UI/UX اید یا Devops و ... شما:

۱- از نظر Agile Development همگی عضو Development Team هستید.

۲- از نظر ساختار هولاکراسی عضوی از دایره (Circle) تولید محصول هستید.

پس اول از همه باید به محصولتون فکر کنید. شماها روزانه با هم Daily می‌رید و درباره بهبود کیفیت محصول، تولید فیچرهای جدید یا بازطراحی بخشی از محصول باهم هم‌فکری، طراحی و اجرا می‌کنید(یا بهتر بگم «باید» این طور طراحی و اجرا کنید)، پس من باید به درستی انتظار داشته باشم که همگی روی OKR کل تیم تسلط داشته باشند و از به نتیجه رسیدن اون که همون به نتیجه رسیدن محصوله (در محیط Production، نه تست، نه Staging و نه کامپیوتر شخصی)، مطلع و مسلط باشند.

به همین خاطر من سعی کردم به همکارانم بگم شماها اسم خودتون رو بگذارید Product Engineer، و این بهترین اسم برای توضیح کاری هست که می‌کنید. یاد بازی commandos میوفتم. درسته که شما ممکنه بهترین بمب‌گذار، بهترین دونده، بهترین غواص یا بهترین تک‌تیر‌انداز باشید، اما نباید فراموش کنید، در آخر شما یک کماندو هستید که برای ماموریت ارزشمندی کنار هم جمع شدید.

۱- توسعه چابک به جای مسابقه‌ی دوی امدادی

نمی‌دونم هنوز تیم‌هایی هستند که به صورت دوی امدادی نرم‌افزار تولید می‌کنند یا نه؟ اما خاطرات گذشته هنوز با ماست. یک تیم «پایگاه داده»، یک تیم «برنامه‌نویس» (خداروشکر اون موقع هنوز Backend از Front جدا نشده بود) یک تیم «تحلیل‌گر» و ...

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

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

شاید این ۲ فراز از «مانیفست چابک» به خوبی اهمیت این موضوع رو نشون بده. ما تیم‌های خودسازمان‌دهنده‌ای باید داشته باشیم که «توسعه دهنده»ها فارغ از توانمندی‌هاشون همگی عضوی از تیم توسعه هستند و تلاش می‌کنند درچابک‌ترین حالت، بهترین محصول رو پدید بیارند.

۲- ساختار هولاکراسی و مفهوم تیم

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

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

مهم نیست در ساختار شما به چه اسمی صدا میشن، مهم اینه که در بیشتر ساختارها این مفهوم مشترکه و افراد هم رده با همدیگه اعضای یک تیم متفاوت رو می‌سازند. این اعضا در یک ساختار سلسله مراتبی ممکنه ۳ تا ۵ باشند، اما در ساختار آروان (که بالاتر تصویرش رو می‌تونید ببینید) از ۲۲ نفر تشکیل شدن.

در نتیجه انتظار می‌ره این افراد با همدیگه بالاترین سطح تعاملات رو داشته باشند، از دامنه (Domain) همدیگه مطلع باشند و بتونن در تعامل با همدیگه کمک کنند تا اهداف (Purpose) کل دایره محقق بشه.

مارکس و از خود بیگانه شدن آدم‌ها:

ممکنه برنامه‌نویس‌ها دیگه من رو از خودشون ندونن :) ولی از ۱۱ سالگی پیوسته در حال برنامه‌نویسی بودم، و الان که در ۳۳ سالگی این مطلب رو دارم می‌نویسم سال‌هاست که در محیط‌های توسعه محصول کار کرده‌ام. تجربیات این سال‌ها به من یک سوگیری داده که ممکنه خیلی منصفانه نباشه، اما خیلی هم دور از واقعیت نیست:

ممکنه بیشتر برنامه‌نویس‌ها درونگرا نباشند، اما احتمالن بیشتر برنامه‌نویس‌ها دوست دارند درونگرا به نظر برسند.

به خاطر همین وقتی از این موضوعات حرف می‌زنی افراد زیادی هستند که باهاش زاویه دارند، اون‌ها دوست دارن در لاک خودشون بمونن، Task ها رو (حتی نه Story ها رو) تحویل بگیرند و به خوبی تحویل بدهند، نه بیشتر و نه کمتر.

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

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

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

در نهایت...

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

ولی من تصور می‌کنم این نوع نگاه برای تمام ذی‌نفع‌ها، بیشینه ترین نفع رو خواهد داشت.

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