-->
چابک مدرن برای استارتاپ‌ها

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

هم‌خوان کنید در:

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

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

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


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

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

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

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

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

استیو دِنینگ

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

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

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

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

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

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

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

استیو دِنینگ

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

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

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

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

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

کشفِ مشتری

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

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

استیو دِنینگ

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

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

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

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

خلقِ تغییر

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

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

استیو دِنینگ

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

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

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

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

دقیقه‌ی ۲۴:۲۰ تا ۲۷:۴۲ از ویدئو

توسعه‌ی ناب

سخن پایانی

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

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

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

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

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

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

هم‌خوان کنید در:
سهیل صمدزاده

سهیل صمدزاده

من سهیل صمدزاده؛ مشاور چابک سازی گروه‌های نرم‌افزاری، توسعه‌دهنده، مدیر محصول نرم‌افزاری و وبلاگ نویس هستم. به فنّاوری و تفکرات چابک در توسعه نرم‌افزار علاقه‌مندم و سعی می‌کنم در اینجا خُرده دانش‌هایم را با شما به اشتراک بگذارم.


دیدگاه‌های شما ارزشمند‌اند...

اولین نفری باشید که دیدگاه می‌گذارد.

خبر بده وقتی
avatar
1024

وی‌پی‌دیسکاز

به کانال تلگرام آیلِتـــ بپیوندید!

t_logo

آیلِتـــ هر ماه در صندوق ایمیل شما: