💡🌱 چرا بیشتر برنامه‌های توسعه شکست می‌خورند؟ مشکل موقعیت‌یابی اشتباه!

وقتی آقای الف، (یک دولوپر از نظر مهارت فنی، جونیور، ولی با ۱۲ سال تجربه) برنامه یادگیری سال جدیدش رو برای من فرستاد تا نظرم رو بگم؛ لیستش از الگوهای طراحی مایکروسرویس تا هوش‌مصنوعی تا... رو در برداشت. ازش پرسیدم: «آخرین باری که یک Pull Request یا Merge Request دادی که به بخش محدودی از نرم‌افزار بهینگی کارایی یا ساختاری اضافه کرده باشه (و نه فقط خواسته‌ی تسک) و کامنت‌های بیسیک هم از دید دولوپرهای ارشد نگرفته باشه کِی بوده؟ پاسخ صریح و مطمئنی نداشت! این دقیقاً جاییه که اکثر برنامه‌های توسعه، چه فردی، تیمی یا سازمانی، شکست می‌خورن: ما به جای شناخت دقیق موقعیت فعلی، مستقیم سراغ مقصد می‌ریم. مشکل: ما نمی‌دانیم واقعاً کجا ایستاده‌ایم.

تصور کنید می‌خواهید از تهران به اصفهان بروید، اما GPS موقعیت فعلی‌تون را اشتباه تبریز نشون می‌ده. هر مسیری که انتخاب کنید، اشتباهه، نه به خاطر مقصد، بلکه به خاطر نقطه شروع. سه سناریوی واقعی از موقعیت‌یابی اشتباه:

1️⃣ سناریو ۱: دولوپر جونیور، آقای الف
موقعیت واقعی: کدهاش هنوز فراتر از خواسته‌ها نیست، متدهاش بنا به دانش کم، و نه ضرورت و اقتضای شرایط، بیش از ۸۰ خط می‌شن، استفاده بجا از الگوهای طراحی رو نمی‌دونه.

موقعیت ادراک‌شده: آمادگی برای یادگیری معماری‌های پیچیده، فریب عدد سال‌های تجربه، فریب آشنایی با عنوان مفاهیم پیشرفته

نتیجه: سه ماه وقت صرف یادگیری DDD می‌کنه، اما کدهایش همون if/else تودرتوی قبلی با اسامی fancy است. API چت‌جی‌پی‌تی صدا می‌زنه، توهم دانش GenAI داره.

هزینه: ۳۶۰ ساعت وقت + frustration + از دست دادن فرصت یادگیری Clean Code، کسب توهم بیشتر که مثل یک دیوار محکم جلو یادگیری صحیح و به‌جا رو ازش می‌گیره!

2️⃣ سناریو ۲: تیم توسعه (یک استارتاپ ۱۵ نفره)

موقعیت واقعی: Code coverage زیر ۳۰٪، هیچ integration test ندارن، deployment تقریبا دستی است، تیم آلوده به وایب‌کدینگ مخفی شده.

موقعیت ادراک‌شده: آماده رفتن به microservices، توانایی تحویل فیچر و توسعه سریع‌تر (وهم وایب‌کدینگ بدون سنجش میزان کد کثیف و ناکارآمد و ناهمگون)

نتیجه: شش ماه صرف split کردن monolith شد، اما debugging چندبرابر شد چون observability ندارند، روز به روز درک کدها سخت‌تر شده، هر اصلاح با وایب‌کدینگ موجب خطا و مشکل در جای دیگه می‌شه.

هزینه: ۶ ماه × ۱۵ نفر × میانگین حقوق = حداقل ۴.۵ میلیارد تومن + velocity کمتر شده

3️⃣ سناریو ۳: مدیر محصول تازه‌کار

موقعیت واقعی: هنوز نمی‌دونه چطوری یک user story خوب بنویسه یا backlog prioritize کنه

موقعیت ادراک‌شده: آماده طراحی استراتژی سه‌ساله محصول

نتیجه: یک سند ۴۰ صفحه‌ای strategy که هیچ‌وقت اجرا نمی‌شه، چون execution از پایه مشکل داره، مدیران فریفته‌ی محتوای غیرواقعی سند شدن

هزینه: اعتماد تیم + فرصت تمرکز روی مهارت‌های بنیادی

فریمورک سه‌مرحله‌ای برای موقعیت‌یابی صحیح

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

مرحله ۲: Gap Analysis (محاسبه فاصله واقعی) حالا که موقعیت فعلی رو می‌دونید، باید بفهمید دقیقاً یک سطح بالاتر کجاست. نه دو سطح، نه سه سطح؛ فقط یک سطح. این مفهوم را Vygotsky، روان‌شناس روس، دهه ۱۹۳۰ ذیل Zone of Proximal Development (ZPD) تعریف کرده (اگر دوست داشتید بیشتر بخونید). و نشون می‌ده یادگیری فقط در یک باند باریک اتفاق می‌افته:

خیلی آسون » Comfort Zone (یادگیری صفر)
کمی چالش‌برانگیز » Learning Zone (یادگیری حداکثر) ← ZPD همینجاست
خیلی سخت » Panic Zone (یادگیری صفر)

مرحله ۳: Action Planning (طراحی گام اول قابل اجرا) بعد از شناخت موقعیت و تعیین گام بعدی، باید یک برنامه خیلی کوچیک طراحی کنید که در عمل اجرا شدنی باشه.

آمار: ۶۸٪ از مهاجرت‌ها به microservices در سازمان‌هایی که بلوغ کافی نداشتن، منجر به کاهش productivity شد (منبع: ThoughtWorks Technology Radar 2019)
یا ۷۵٪ از برنامه‌های یادگیری سال نو تا پایان فوریه رها می‌شن! (منبع: University of Scranton research) دلیل اصلی: اهداف خیلی بالاتر از سطح فعلی

خلاصه اینکه: فقط یک سؤال از خودتان بپرسید: «اگر بخوام امروز به کسی ثابت کنم دقیقا در چه سطحی هستم، چه عددی یا fact مشخصی می‌تونم نشون بدم؟ و این عدد با چه معیار و سنگ محکی سنجیده شده؟»

اگر پاسخ روشنی ندارید، قبل از هر برنامه‌ریزی دیگه‌ای، اول موقعیت‌یابی کنید.