اشتباهات رایجی که در تیم‌های توسعه می‌بینیم

در درس‌های قبل مت بیشتر از چیزهایی گفت که کار کرده‌اند — و اغلب همان‌ها را از دیدن نسخهٔ خراب‌شان ساخته. گاهی باید صریح اسم مشکل را بگذاری و بگویی لطفاً این کار را نکن. دوازده نمونه، چهار دسته: مسائل رهبری، مسائل تیم، برنامه‌ریزی فنی، و پاسخ غلط به مشکل.

مسائل رهبری

**۱. رهبر غیرفنی سازمان فنی.** رهبر سازمان فنی باید از نظر فنی شایسته باشد: در ارشدترین سطح مهندسی یا برنامه‌نویسی — نه لزوماً CEO، اما Director of Engineering یا CTO باید تکنولوژیست باشد، نه مدیری که تکنولوژی سرگرمی‌اش است. ترجیحاً مهندس؛ اگر تیم برنامه‌نویسی است، ترجیحاً برنامه‌نویس.

ساخت تیم مولد با رهبر غیرفنی غیرممکن نیست؛ درد غیرضروری است. کسی که باید سرعت را با پایداری عوض کند، technical debt بردارد تا ددلاین بخورد، یا از کد زیبا به‌نفع کسب‌وکار بگذرد، اگر آن تجربه را نداشته باشد هم نمی‌تواند درست دفاع کند هم نمی‌داند کی باید فشار بیاورد.

قابل‌قبول‌ترین سازش: رهبر ارشدی که به ارشدترین برنامه‌نویس‌های واقعی احترام می‌گذارد، حرف‌شان را باور می‌کند و برایشان می‌جنگد.

**۲. CTO جدید که می‌خواهد همه‌چیز را دور بریزد.** در استارتاپ و اسکیل‌آپ رایج است: با یک استک MVP و POC ساخته‌اند؛ وقت «بزرگ شدن» و آوردن C-suite می‌رسد؛ CTOای می‌گیرند که در استک فعلی کار نمی‌کند. در مصاحبه جذاب است. اولین کار: همه‌چیز افتضاح است، برنامه‌نویس‌های شغل قبل را می‌آورم، در استک محبوب‌مان بازنویسی می‌کنیم.

آنچه از دست می‌رود: معمولاً فقط MVP نبوده — نسخهٔ اولیهٔ هسته، با **منطق کسب‌وکار کدشده** داخل اپ. تیم فعلی هم اغلب بیرون می‌رود چون «آدم‌های او» نیستند و استک جدید را بلد نیستند. رابطه و دانش‌شان می‌پرد. نتیجه معمولاً **۶ تا ۱۲ ماه عقب‌گرد** است. CTO قول چند ماه می‌دهد. در تاریخ، بازنویسی **هرگز** سریع و بهتر طبق آن وعده تمام نشده.

اگر استک و اپ کار می‌کند و تا اینجا شرکت را نگه داشته، رهبر فنی **داخل همان استک** بگیر. اگر استک Laravel است و گیر کرده‌ای، به مت بگو؛ کسی را پیدا می‌کند قبل از اینکه کل چیز را دور بریزی.

مسائل تیم

**۳. Superman developer / ارشد ۱۰برابری.** تنها فوق‌مولد است؛ نمی‌تواند در تیم کار کند یا سیستمی بسازد که دیگران بخواهند یا بتوانند نگه دارند. عمدی یا نه، کل بهره‌وری و رشد فنی تیم را کند می‌کند چون کم‌کم همه‌چیز باید از او یا سیستم‌های او رد شود. گله می‌کند نمی‌تواند مرخصی برود — و تو حتی شکرگزار زحمتش می‌شوی. سازمان اگر به یک نفر گره بخورد مقیاس‌پذیر و سالم نیست. هیچ کارمندی، هرقدر مولد، نباید choke point کل سیستم باشد.

**۴. تیم پر از جونیور.** دلایل آشنا: نیروی ارزان، پیدا کردنشان آسان است، نیت خوبِ پایپ‌لاین شاگردی، و گاهی جونیور خوش‌صحبت در نقش میانی. تهش تیم بدهی است: آدم‌های توانا را پایین می‌کشد، پول حرام می‌کند، کل تیم را بد نشان می‌دهد — و همان چند توانا دیگر نمی‌توانند هم منتور کنند هم کد خودشان را بنویسند.

جونیور ارزشمند است: دیدگاه تازه (هرچه سابقه بیشتر، احتمال پس‌زمینهٔ یکسان بیشتر)، و صنعت بدون کسی که جونیور استخدام کند جونیورِ دیروز را ندارد. **حداکثر یک جونیور در برابر دو باتجربه.** تیم را با آن‌ها پر نکن.

**۵. ارزانِ اغلب آفشور: یک‌چهارم حقوق، نصف خروجی، برد؟** حتی اگر سه‌چهارم خروجی یا همان تعداد خط با یک‌چهارم هزینه باشد، نمی‌ارزد. ارزان دلیل دارد — مثل ماشین یا غذا یا لباس ارزان. ظاهر ممکن است شبیه باشد؛ گوشه‌ها بریده می‌شود: اسپاگتی، معماری غیرقابل‌دوام، حفرهٔ امنیتی. آدم توانا را به‌اندازهٔ ارزشش بپرداز.

**۶. Mythical Man-Month و Brooks's Law.** فرد بروکس، ۱۹۷۵: اضافه کردن آدم به پروژهٔ دیر، دیرترش می‌کند. هشت نفر و چهار ماه مانده؛ هشت نفر دیگر اضافه نمی‌کند که دو ماهه تمام شود. تشبیه بچه: نه ماه یک نفر؛ نه نفر یک‌ماهه بچه نمی‌سازند. آنبوردینگ، ارتباط، اصطکاک بین‌نفر — همیشه هزینه دارند؛ **آخر پروژهٔ دیر** بدترین جا برایشان است.

همان منطق روی پروژهٔ دیر نیست هم می‌نشیند: هر پروژه اندازهٔ ایده‌آل دارد. آدم اضافه رایگان نیست. از جایی به بعد هزینهٔ فرایند و ارتباط از سودی که از سرعت می‌گیری بیشتر می‌شود.

مسائل برنامه‌ریزی فنی

**۷. کپی FAANG و AWS.** microservices یا Kubernetes چون از حرف AWS تریلیون‌دلاری آمد. مسائل و گزینه‌های تیم ۵ نفره مسائل تیم ۵۰۰ نفره نیست. میکروسرویس برای auth وقتی ۵۰ نفر فقط روی auth کار می‌کنند معنا دارد. اگر auth یکی از ۲۲ دغدغهٔ **یک نفر** است، جدا کردنش دیپلوی را سخت‌تر می‌کند، برنچ فیچر را سخت‌تر، ارتباط را سخت‌تر، و باگ یک فیچر را دو سه برابر سخت — چون باید چند ریپو را هماهنگ کنی.

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

**۹. shiny object syndrome در معماری.** در روزمره همان حواس‌پرتی «جدید و براق» است؛ در برنامه‌ریزی معماری خطرناک‌تر است: فرض که جدیدتر یعنی بهتر. می‌شود HTML سمت سرور؛ پس حتماً Next.js چون جدیدتر و سکسی‌تر است. یکی از مهم‌ترین معیارها: تیم چه بلدی است، و بقیهٔ اپ با چه ساخته شده. هیچ‌وقت مدرن‌سازی وقتی استک مرده ممنوع نیست؛ سمت احتیاط بایست. جدید یعنی قضاوت مختل، تجربهٔ کمتر، ابزار و پشتیبانی کمتر.

**۱۰. رسیدن به پیچیدگی.** پسرعموی شیء براق: سیستم ساده مشکل دارد، پس جواب پیچیدگی است. تقریباً هرگز. مدل‌های به‌هم‌ریخته یعنی repository لازم داری؟ شاید فقط مدل‌ها را مرتب کن. پوشه‌ها پر شده یعنی DDD کامل؟ شاید فقط پوشه را مرتب کن. اول داخل سیستم سادهٔ فعلی حل کن. وگرنه همان مشکلات — که از نادانی یا کم‌کاری تیم آمده نه لزوماً از سادگی سیستم — را به سیستمی سخت‌تر، پراصطکاک‌تر، سخت‌تر برای تازه‌وارد تزریق می‌کنی.

پاسخ‌های غلط به مشکل

**۱۱. پیچیدگی فرایند.** همان وسوسهٔ پیچیدگی، این‌بار روی کار نه روی کد. تسکینگ درد دارد → فوراً Scrum Master استخدام کن و نه ماه تیم را روی قالب Scrum بازآموزی کن. مت می‌گوید یک لحظه **رهبری کن** — نه از سر تحقیر، یعنی تشخیص قدم بعد را تفویض نکن. با تیم حرف بزن، بفهم چه خراب است، بپرس همان‌طور که در کد پرسیدی: داخل سیستم فعلی حل می‌شود؟

مشتری شکایت می‌کند آپدیت کافی نیست. می‌توانی سیستم تیکت عظیم با burndown پیکسل‌پرفکت بخری که کل شیوهٔ انتخاب و ردیابی کار را عوض کند؛ یا از تیم بخواهی آخر روز چند بولت در Slack دربارهٔ کارشان بنویسند. همهٔ فرایند بد نیست. **همهٔ فرایند هزینه دارد.** پیچیده بودن، گران بودن، یا علامت تجاری بعد از اسم، یعنی راه‌حل مشکلات قبلی نیست.

**۱۲. حرف خوب، عقب‌نشینی وقتی گران است.** خانواده هستیم، انعطاف داریم، پاداش می‌دهیم — تا وقتی هزینه ندارد رئیس محبوبی. وقتی گران یا سخت شد، خلف وعده. این سوءاستفاده از سیستمی است که از قبل به نفع رهبر چیده شده. چیزی را تعهد نکن مگر وقتی برایت گران تمام شد هم پایش بایستی. همان صداقت فصل ۱.

پایان دوره

این هم فهرست دوازده‌تایی، هم پایان کل دوره. مت امیدوار است این مسیر برایت ارزشمند بوده باشد: چیزی یاد داده باشد، یا چیزی را که خودت می‌کردی یا باور داشتی تأیید کرده باشد. امیدش این است که بیرون بروی با این حس که از وقتی شروع کردی **تواناتر یا مطمئن‌تر** در رهبری هستی.

اگر سؤال یا نگرانی داری یا در مسیرت کمک می‌خواهی، به مت سر بزن: **@StaufferMatt** در توییتر، یا اگر مستقیم لازم داری **matt@tighten.com**. خوشحال می‌شود کمک کند.

به زبان ساده

دوازده تله: لید غیر فنی، بازنویسی CTO جدید، سوپرمن، تیم جونیور، ارزانِ دورکار، نفر-ماه افسانه‌ای، کپی AWS، نادیده‌گرفتن بدهی فنی، شیء براق، پیچیدگی اضافه، اسکرام به‌جای حرف زدن، وعده وقتی سخت شد.

مثال واقعی

CTO تازه‌وارد استک را عوض می‌کند و ۶ تا ۱۲ ماه برمی‌گردی. قانون بروکس ۱۹۷۵ هنوز کار می‌کند. اگر قول انعطاف دادی، وقتی گران شد هم باید نگهش داری — همان Integrity فصل ۱.