چندی پیش، در یکی از گفتگوهایم، بحثی مطرح شد که همیشه برای من چالشبرانگیز بوده:
آیا باید خیلی سریع دست به اقدام زد، یا قبل از هر حرکتی، زمان کافی برای یادگیری و کشف گذاشت؟ در این بحث، خیلیها از مفهوم Fail Fast دفاع میکردند — یعنی شکست سریع برای یادگیری سریع.
این سوال باعث شد تصمیم بگیرم نظر Kent Beck را جویا شوم. چرا کنت بک؟ اصطلاح Fail Fast در اصل از دنیای TDD آمده و چون TDD بهواسطه متد XP وارد جریان اصلی توسعه نرمافزار شد، این اصطلاح بهتدریج به یکی از مفاهیم رایج در مکالمات Agile تبدیل شد. من این سوال را مستقیماً در یک پیام در لینکدین از او پرسیدم و خوشبختانه او با حوصله و مهربانی پاسخ داد.
جواب او برای من بسیار روشنگر بود. او نوشت:
“In uncertain conditions, the emphasis is on learning, not production. Production comes as a side effect of learning.”
«در شرایط نامطمئن، تأکید بر یادگیری است، نه تولید. تولید فقط یک نتیجه جانبی از یادگیری است.»
این جمله، برای من یک نقطه عطف فکری بود. برداشت شخصی من از این حرف این است که در دنیای امروز، که پر از عدم قطعیت و تغییرات سریع است، اگر یادگیری را مقدم بر اجرا ندانیم، خیلی زود درگیر ساختنهای بیهدف و خروجیهای کمارزش میشویم.
این مقاله، ادامه همین مسیر فکری و برداشتهای شخصی من است: چرا باید یادگیری را قبل از اجرا قرار دهیم، چه خطراتی در کمین ماست، و چطور میتوانیم با ابزارها و رویکردهای درست، محصولاتی بسازیم که واقعاً برای کاربران ارزشمند باشند.
یادگیری پیش از Do (اجرا): چرا؟
بعد از دریافت آن جمله کوتاه، برای من خیلی واضح شد که در دنیای محصول و نرمافزار، بهویژه در شرایط پر از عدم قطعیت، یادگیری (Learning) همیشه باید مقدم بر Do (اجرا) باشد. این یک شعار یا توصیه انگیزشی نیست؛ بلکه یک نیاز واقعی برای بقا و رشد است.
در بسیاری از تیمها، زمانیکه افراد بدون درک عمیق از مشکل یا نیاز واقعی کاربر وارد مرحله اجرا میشوند، خیلی زود با چرخهای از اصلاحات پرهزینه، دوبارهکاریهای مکرر، سنگین شدن محصول، افت کارایی (Performance)، افزایش بدهی فنی (Technical Debt) و نارضایتی کاربران مواجه میشوند.
در نگاه اول، «سریع شروع کردن» جذاب به نظر میرسد. با این حال، وقتی نتایج بررسی میشود، اغلب مشخص میشود که زمان، انرژی و منابع زیادی صرف شده، بدون آنکه ارزشی واقعی تولید شده باشد.
یادگیری پیش از اجرا به این معناست که پیش از ساختن، بفهمیم دقیقاً چه مشکلی قرار است حل شود (Why)، چه چیزی باید ساخته شود (What)، و کاربر یا مشتری واقعی چه کسی است (Persona). این شفافیت باعث میشود تیم با دید کاملتری وارد مسیر ساخت شود، و از ساختنهای بیجهت و پرهزینه پرهیز کند.
چرخه دمینگ (PDCA) و یادگیری تدریجی
یکی از مدلهایی که به من کمک کرد تا اهمیت یادگیری پیش از اجرا را بهتر درک کنم، چرخه دمینگ یا PDCA Cycle است. این چرخه در اصل برای بهبود مستمر طراحی شده و در دنیای محصول و نرمافزار، مخصوصاً در شرایط پر از عدم قطعیت، نقش بسیار کلیدی و ارزشمندی دارد.
این چرخه از چهار مرحله اصلی تشکیل میشود:
- Plan (برنامهریزی): تعریف مشکل، شناسایی فرضیات و طراحی یک قدم اولیه برای یادگیری
- Do (اجرا): عملی کردن طرح و جمعآوری دادهها
- Check (بررسی): تحلیل نتایج، مقایسه با فرضیات، دریافت بازخورد
- Act (اصلاح): بهبود یا تغییر مسیر بر اساس آموختهها
در این مدل، Plan بهمعنای طراحی کامل نیست، بلکه بهمعنای درک مسئله و آمادهسازی بهاندازه کافی است. بر خلاف مدلهای سنتی مدیریت پروژه، که برنامهریزی را یک مرحله ثابت و کامل در ابتدای پروژه میدانند، در PDCA برنامهریزی امری زنده و پویاست که هدفش یادگیری و کاهش ریسک است.
در این رویکرد، تیمها از خطر Over-Planning یا زیادی آمادهسازی دور میمانند و به جای طراحی همهچیز از ابتدا، مسیر را بهصورت تدریجی و تکراری اصلاح میکنند.
چرخه دمینگ به من یاد داد که یادگیری نیز مانند محصول، باید Incremental (تدریجی) و Iterative (تکراری) باشد. بهجای تلاش برای دانستن همهچیز از ابتدا، باید قدمبهقدم جلو رفت، بازخورد گرفت، و اصلاح کرد.
اهمیت Discovery و مدل Continuous Discovery در کتاب Strategize
یکی از منابعی که نگاه من به فرآیند کشف (Discovery) و تولید محصول را کاملتر کرد، كتاب Strategize نوشته Roman Pichler بود. در این کتاب، او مسیر تبدیل ایده به محصول را در چهار مرحله معرفی میکند:
- Idea
- Discovery & Strategy
- Development
- Product
بسیاری از تیمها بدون توجه به مرحله دوم، یعنی Discovery، مستقیماً از ایده وارد توسعه میشوند. نتیجه چنین مسیری معمولاً محصولاتی است که کار نمیکنند، مسئلهای را حل نمیکنند، یا برای کاربر ارزشی ندارند.
در مرحله Discovery، ما به سوالهایی اساسی پاسخ میدهیم:
- مشکل واقعی چیست؟
- مشتری یا کاربر چه کسی است؟
- چه ارزشی میخواهیم ایجاد کنیم؟
- آیا این ایده با اهداف بازار و استراتژی کسبوکار هماهنگ است؟
در کتاب Strategize از میخوانیم که فرآیند کشف (Discovery)، همانند توسعه محصول، باید بهصورت Iterative (تکراری) و با نگاه Continuous Discovery (کشف مداوم) بازنگری و توسعه یابد. او توضیح میدهد که در هر تکرار، با جمعآوری فیدبک، بازنگری استراتژیها، و در صورت نیاز، اعمال تغییرات در سطح Product، Roadmap یا Backlog، میتوانیم تصویر شفافتری از نیاز و راهحل بهدست بیاوریم.
این نگاه به من یادآوری میکند که Discovery یک مرحله اولیه نیست، بلکه یک فرایند مداوم است.
تلهها و سندرومها: وقتی یادگیری نادیده گرفته میشود
وقتی یادگیری از مسیر توسعه محصول حذف میشود، تیمها بهمرور وارد الگوهایی میشوند که بیشتر از آنکه بر پایه ارزش باشند، بر پایه ساختن مداوم و تحویل سریع بنا شدهاند. دو مفهوم مهم که این وضعیت را توصیف میکنند، Feature Factory و Build Trap هستند.
- در Feature Factory، تمرکز اصلی تیمها روی افزایش خروجی است — تعداد بیشتر فیچر، تحویل بیشتر، و حرکت مداوم. اما هیچکس نمیپرسد این تحویلها چه اثری داشتهاند، چه تغییری در رفتار کاربر ایجاد کردهاند، یا اصلاً استفاده شدهاند یا نه.
- در Build Trap، ساختن به هدف تبدیل میشود. تیم یا سازمان بدون آنکه بداند دقیقاً چرا چیزی را میسازد، صرفاً بر اساس فرضیات داخلی یا فشار زمانی، به توسعه ادامه میدهد. در چنین حالتی، تحویل محصول جایگزین یادگیری و بررسی اثربخشی میشود.
نشانههایی که میتوانند زنگ خطر باشند:
- نبود زمان برای Discovery
- تحویل فیچرها از بالا به پایین، بدون بررسی
- عدم دریافت فیدبک از کاربران واقعی
- اندازهگیری موفقیت صرفاً با سرعت تحویل
با استفاده از کشف مداوم (Continuous Discovery)، بازخورد کاربران (User Feedback)، و بازنگری مداوم در استراتژیها (Ongoing Strategy Review)، میتوان تیم را دوباره وارد چرخهی بهبود مستمر (Continuous Improvement Cycle) کرد و تمرکز را از صرفاً ساختن، به ساختنِ ارزشمند (Value-Driven Delivery) بازگرداند.
جلسه Scrum در Refinement: آمادهسازی، نه پیشبینی
در Scrum، جلسهای بهنام رسمی «Refinement» وجود ندارد، اما تقریباً همه تیمهای پویا، آن را بهعنوان بخشی ضروری از فرایند خود اجرا میکنند.
Refinement جایی است که تیم، پیش از ورود به Sprint Planning، تلاش میکند آیتمهای Backlog را تا حدی بررسی و شفاف کند که بتوان درباره آنها تصمیم گرفت. در این مرحله، تمرکز بر شفافسازی «چه چیزی» و «چرا» است — نه چگونگی دقیق پیادهسازی.
وقتی تیم بدون Refinement وارد اسپرینت میشود، اغلب این مشکلات دیده میشود:
- جلسات برنامهریزی
- اسپرینت (Sprint Planning) طولانی، بیتمرکز و خستهکننده
- بوجود آمدن Sprint Goal مبهم یا غیرواقعی
- حجم بالای آیتمهای ناقص در انتهای اسپرینت
هدف از Refinement، برنامهریزی کامل نیست، بلکه رسیدن به سطحی از وضوح است که تصمیمگیری و شروع کار را ممکن کند. این یک فعالیت یادگیریمحور است، نه پیشبینی آینده.
در بسیاری از تیمها، این گفتگوها به آیتمهای N+1 یا حتی N+2 هم گسترش پیدا میکند — یعنی آیتمهایی که ممکن است در یکیدو اسپرینت آینده وارد برنامه شوند. این کار باعث میشود تیم همیشه کمی جلوتر از زمان حال فکر کند، اما بدون اینکه وارد فضای Over-Planning یا قفل شدن روی طرحهای ثابت شود.
Refinement به تیم کمک میکند که حرکتش مبتنی بر یادگیری باشد، نه صرفاً انجام وظایف؛ و این یعنی پیوند مستقیم با مفهوم یادگیری پیش از اجرا.
یادگیری، پیشنیاز حرکت معنادار
همهچیز از یک سوال ساده شروع شد:
آیا باید سریع حرکت کنیم و بعد یاد بگیریم، یا قبل از هر حرکت، زمانی برای یادگیری بگذاریم؟
جوابی که از Kent Beck گرفتم — «در شرایط نامطمئن، تأکید بر یادگیری است، نه تولید» — برای من فقط یک جمله نبود. تبدیل شد به خط فکریای که در بسیاری از تجربههای من در توسعه محصول، تیمسازی، تصمیمگیری و حتی تفکر استراتژیک، کاربرد و یا تطابق دارد.
در طول این مقاله سعی کردم نشان دهم که چرا Learning پیش از Do (اجرا)، نه فقط یک اصل نظری، بلکه یک نیاز عملی در دنیای امروز است.
در طول این مقاله سعی کردم نشان دهم که چرا Learning پیش از Do (اجرا)، نه فقط یک اصل نظری، بلکه یک نیاز عملی در دنیای امروز است.
از چرخه دمینگ (PDCA) گرفته تا مدل پیشنهادی Roman Pichler در کتاب Strategize، و حتی تجربههای رایج در تیمهای چابک، همه و همه بر یک اصل مشترک تأکید دارند: یادگیری باید مداوم، تکراری و متصل به عمل باشد.
در غیاب این یادگیری، تیمها خیلی راحت وارد دامهایی مثل Feature Factory یا Build Trap میشوند؛ جایی که ساختن به خودی خود هدف میشود، نه خلق ارزش.
در مقابل، رویکردهایی مثل Continuous Discovery، استفاده از User Feedback، و بازنگریهای تدریجی در Strategy، تیم را در یک چرخه سالم و رو به رشد نگه میدارند — چرخهای که در آن «ساختن»، نتیجه طبیعی و منطقی «یادگیری» است، نه جایگزین آن.
امروز اگر بخواهم یک جمله کلیدی را همیشه در ذهنم نگه دارم، همان جملهای است که این مقاله با آن آغاز شد:
«در شرایط نامطمئن، تأکید بر یادگیری است، نه تولید. تولید فقط یک نتیجه جانبی از یادگیری است.»
