چابکِ مُدرن برای استارتاپ‌ها

در فوریه سال ۲۰۰۱ تعدادی از نخبگان و مهندسان نرم‌افزار در یک دورهمیِ تفریحی در اسنوبِرد ایالت یوتا – آمریکا، در مورد روش‌های سبک‌وزن توسعۀ نرم‌افزار باهم گفتگو می‌کردند. نتیجۀ این گفتگو، انتشار بیانیه‌ای برای توسعۀ چابک نرم‌افزار بود. از آن تاریخ، بیش از پانزده سال گذشته است. متدها و تجربیات متعددی از چابک، آزموده شده و چارچوب‌های گوناگونی برای پیاده‌سازی آن خلق‌شده است. شرکت‌ها و سازمان‌های بزرگی روش‌های چابک را پذیرفته و از آن استفاده کرده‌اند و نتایج درخشانی هم به دست آورده و هنوز هم به استفاده از آن ادامه می‌دهند.

پیش‌فرض من در ادامه این است که شما با بیانیۀ چابک آشنایی داشته و قبلاً از متدهای چابک در پروژه‌های نرم افزاریِ غیر استارتاپی استفاده کرده‌اید.

در طول متن به بخش‌هایی از سخنرانی کِنت بِک در کنفرانس Startup Lessons Learned 2010 اشاره‌شده است. کل سخنرانی را در ویدئوی زیر می‌توانید ببینید.


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

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

چشم‌انداز تیمی و انضباط

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

در فضای آن سال‌ها (۲۰۰۱) این تفکر که افراد و تعاملاتِ بین آن‌ها از فرآیندها و ابزارها مهم‌ترند خود یک حرکت انقلابی و قدمی بلند به‌سوی توسعه بوده است. ازاین‌رو در بیانیۀ چابک اذعان شد که افراد و تعاملات بالاتر از فرآیندها و ابزارها است.

استیو دِنینگ

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

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

[دست‌کم در محیط‌های استارتاپی]، چشم‌اندازِ تیمی و انضباط بالاتر از افراد و تعاملات [است]

دقیقۀ ۱۶:۰۰ تا ۱۹:۱۱ از ویدئو

یادگیریِ معتبر

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

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

استیو دِنینگ

مشکل اصلی در دنیای استارتاپ‌ها، عدم دانشِ افراد در نحوۀ توسعۀ نرم‌افزار نیست. اتفاقاً چون‌که می‌دانند چگونه باید نرم‌افزار تولید کرد، تصمیم به توسعۀ یک ایده گرفته‌اند. عمدتاً مشکل و سؤال اساسی این است که چگونه برای سرویس یا نرم افزاری که نوشته‌اند، مشتری دست‌به‌نقد بیابند؟ مشتری که حاضر باشد به ازای پرداخت پول، از سرویس تولیدشدۀ آن‌ها استفاده کند! در این فضا، تکیه‌بر نرم افزاری که کار می‌کند، نمی‌تواند پاسخگوی این مشکل باشد. ایجاد فرصتی برای استنتاج‌هایی اعتبارسنجی شده نسبت به بازار، که باعث جذب و رضایت مشتری در استارتاپ‌ها می‌شود، حلال مشکلات است.

فرهنگ و جنبش‌های جدید چابک، مثل دوآپز (DevOps)، سعی دارند این خلأ‌ها را پوشش دهند. یادگیریِ اعتبارسنجی شده و معتبر، روشی برای اندازه‌گیری پیشرفت است که از طریق سعی و خطای یک ایدۀ اولیه و سپس اعتبارسنجی نتایج با شاخص‌هایی حقیقی که از قبل برای موفقیت تعیین‌شده‌اند، محقَق می‌شود.

ازاین‌رو کِنت بِک نتیجه‌گیری می‌کند که:

[دست‌کم در محیط‌های استارتاپی]، یادگیریِ معتبر بالاتر از نرم‌افزار کار کننده و مستندات جامع [است]

دقیقۀ ۱۹:۲۳ تا ۲۲:۳۵ از ویدئو

کشفِ مشتری

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

در سال ۲۰۰۱ این طرز فکر که در دنیای پیچیده و مدام در حال تغییرِ توسعه نرم‌افزار، مشارکت مداوم با مشتری از تلاش برای کشف جزئیات ریزِ نرم‌افزار در ابتدای کار مهم‌تر است، قدمی بلند به شمار می‌رفته است.

استیو دِنینگ

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

درنهایت، کِنت بِک نتیجه‌گیری می‌کند که:

[دست‌کم در محیط‌های استارتاپی]، پایش و کشف مشتری بالاتر از مشارکت با مشتری یا مذاکرات قراردادی [است]

دقیقۀ ۲۲:۳۵ تا ۲۴:۰۵ از ویدئو

خلقِ تغییر

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

در سال ۲۰۰۱ پافشاری بر این ایده که نرخِ وقوعِ تغییرات [در توسعه نرم‌افزار] بیشتر از آن است که بتوان از یک طرح ثابت پیروی کرد، قدمی بلند و شجاعانه به شمار می‌رفته است.

استیو دِنینگ

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

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

به همین دلیل کِنت بِک معتقد است:

[دست‌کم در محیط‌های استارتاپی]، خلقِ تغییر بالاتر از پاسخگویی به تغییرات یا پیروی از یک طرح [است]

دقیقۀ ۲۴:۲۰ تا ۲۷:۴۲ از ویدئو
Build-measure-learn (BML) چابکِ مُدرن برای استارتاپ‌ها

سخن پایانی

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

چشم‌انداز تیمی و انضباط بالاتر از افراد و تعاملات (بالاتر از فرآیندها و ابزارها)

یادگیریِ معتبر بالاتر از نرم‌افزار کار کننده (بالاتر از مستندات جامع)

کشفِ مشتری بالاتر از مشارکت مشتری (بالاتر از مذاکرات قراردادی)

خلقِ تغییر بالاتر از پاسخگویی به تغییرات (بالاتر از پیروی از یک طرح)

پیشنهاد می‌کنم به‌منظور آشنایی بیشتر با فضای حاکم بر چابکِ مُدرن و چالش‌های آن، گزارشِ‌ استیو دِنینگ از پنلِ AgileEurope2016، را نیز مطالعه کنید.

👋

2 پاسخ

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

    1. با بخش اول دیدگاهتون موافقم تا حدودی، و با بخش دوم مخالف 🙂

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

      چابک بودن، حداقلِ یک تیم استارتاپی است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *