در این سال ها در برخورد با نحوه مدیریت مدیران عامل، بارها با این سناریو مواجه شده‌ام که مدیری با نیت خوب، فکر می‌کند دارد «مدیریت اثربخش» انجام می‌دهد اما نتیجه، تنش و فرسایش رابطه با تیم توسعه است.

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

اگر یکی از موقعیت‌های زیر برایتان آشناست، ادامه این مطلب را از دست ندهید:

🔸 از یکی از اعضای تیم خواستید «یه تغییر کوچیک» بدهد و در جواب شنیدید: «حداقل دو هفته طول می‌کشه!»

🔸 در جلسات فنی فقط سرتان را تکان می‌دهید که یعنی «بله، متوجهم»  در حالی که واقعا نیستید

🔸 تیم گران‌ قیمت توسعه، حتی از یک درخواست ساده برای آپدیت وضعیت پروژه هم دلخور می‌شود

🔸 احساس می‌کنید انگار دارید با آدم‌ هایی از یک دنیای کاملا متفاوت حرف می‌زنید

ذهن توسعه‌ دهنده‌ها واقعا متفاوت است

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

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

اما دقیقا همین ساختار ذهنی خاص است که کدنویسی را چنین کاری پیچیده و ارزشمند می‌کند.

کدنویسی مثل نوشتن یک رمان چندلایه است

برنامه‌نویس‌ ها در هنگام نوشتن کد، مدل‌ های ذهنی بسیار پیچیده و به‌هم‌ پیوسته‌ای را در ذهن‌ شان نگه می‌دارند.

درست مثل نویسنده‌ای که در حال نوشتن رمانی با ده‌ها خط داستانی است با این تفاوت که اگر او چیزی را فراموش کند، شاید فقط داستان کمی از ریتم بیفتد ولی اگر توسعه‌ دهنده نکته‌ای را از قلم بیندازد  ممکن است کل سیستم دچار مشکل شود.

برای همین است که آن‌ها به زمان تمرکز بدون وقفه (Uninterrupted Focus Time) نیاز دارند.

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

برنامه‌ ریزی مدیرها در برابر سازنده‌ها

پل گراهام (Paul Graham)، از چهره‌ های برجسته سیلیکون‌ ولی و هم‌بنیان‌گذار Y Combinator، در مقاله‌ای مشهور این تضاد را به‌خوبی توضیح می‌دهد.

او می‌گوید:

🔹مدیرها بر اساس «تقویم ساعتی» کار می‌کنند: جلسه ۱۰ تا ۱۱، بعدش جلسه ۱۱:۳۰ تا ۱۲ و همین‌ طور تا آخر روز.

🔹ولی توسعه‌دهنده‌ها و برنامه نویسان برای ورود به جریان کاری نیاز به بازه‌ های زمانی چند ساعته بدون وقفه دارند؛ چیزی که گراهام آن را برنامه‌ی زمانی سازنده‌ها (Maker’s Schedule) می‌نامد.

یک جلسه‌ی ۳۰ دقیقه‌ای در ساعت ۱۱ صبح می‌تواند کل بازدهی یک بعدازظهر را از بین ببرد  و این یکی از بدترین کارهایی است که مدیرعامل یا مدیر محصول می‌تواند انجام دهد یعنی جلسات پراکنده وسط روز که تمرکز تیم فنی را کاملا به هم می‌ریزد.

هزینه حواس پرتی بالاست

یک توسعه‌ دهنده‌ی خوب (سنیور) می تواند تا ۱۵ برابر بازدهی بیشتری نسبت به یک برنامه نویس متوسط داشته باشد.

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

و تجهیزات هم در همین دسته‌ اند. یک لپ‌ تاپ سریع برای توسعه‌ دهنده چیزی فراتر از یک ابزار است؛ یعنی چندین ساعت بازدهی بیشتر در هر هفته. برای من ممکن است یک مک‌ بوک صرفا نماد تجمل باشد ولی برای برنامه‌ نویس ابزار حیاتی است.

راهنمای سریع برای مدیران عامل 

✅ کارهایی که باید انجام دهید:

🔹استخدام بهترین برنامه نویسانی که توان مالی‌اش را دارید

🔹فراهم کردن ابزار و تجهیزاتی که بهره‌وری‌ شان را بالا می‌برد

🔹زمان‌های بدون وقفه برای تمرکز عمیق فراهم کنید

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

❌ کارهایی که باید از آن‌ها اجتناب کنید:

🔹با «یه سوال کوچیک» وسط کار سراغشان نروید

🔹از آن‌ ها انتظار نداشته باشید سریع بین موضوعات مختلف جا به‌ جا شوند (Context Switching)

🔹جلسات را در ساعات اوج تمرکز برگزار نکنید

🔹گمان نکنید لپ‌ تاپ برنامه‌نویس نباید گران‌ تر از لپ‌ تاپ مدیرعامل باشد!

🔹اگر مدیر عامل یا مدیر محصول هستید و با تیم فنی کار می‌کنید  درک این تفاوت‌ های ذهنی و کاری می‌تواند مسیر همکاری را متحول کند.

🔹گاهی فقط با یک تغییر در زمان‌بندی جلسات، تیم‌تان از هم‌پاشیده نمی‌شود بلکه پرواز می‌کند.

۱. تفاوت بین اعتماد به تیم و رها کردن تیم

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

🔹اعتماد به تیم یعنی به تخصصشون احترام بذاری ولی همچنان شفافیت خروجی و پایش پیشرفت رو حفظ کنی.

🔹رها کردن یعنی “ولش کن، خودشون بلدن” و این باعث میشه اشکالات دیر فهمیده بشه.

۲. مهارت ترجمه بین زبان بیزینس و زبان فنی

مدیرمحصول باید نقش مترجم رو بازی کنه. اغلب تنش‌ها بین تیم فنی و مدیریت ارشد از این ناشی می‌شه که زبان همو متوجه نمی شوند.

🔹وقتی مدیر می‌گه: «سریع یه فیچر ساده اضافه کن» تیم فنی ممکنه به‌ جای «سادگی از نظر ظاهر» پیچیدگی فنی پشت اون رو ببینه.

🔹وقتی تیم می‌گه: «این فیچر باگ‌داره»، ممکنه مدیر نفهمه که این یعنی «ممکنه تجربه کاربری بشدت آسیب ببینه.»

۳. خطر مدیریت با ذهنیت “تولید صنعتی”

بعضی مدیران هنوز با ذهنیت «خط تولید کارخانه» تیم برنامه نویسی رو می‌چینن.
یعنی:
“یه نفر تسک بده → یه نفر بسازه → یکی تست کنه → تموم شد”

در حالی که توسعه نرم‌افزار بیشتر شبیه حل مسئله خلاقانه‌ است و نه مونتاژ قطعات ثابت.

۴. انگیزه‌های درونی تیم فنی رو بشناسید

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

🔹حس کنن دارند کار بی‌معنا انجام می‌دن

🔹ایده‌هاشون شنیده نشه

🔹حس نکنن بخشی از «چشم‌انداز بزرگ‌تر» هستن

۵. نشانه‌های نارضایتی تیم فنی رو زود تشخیص بده

خیلی وقتا قبل از اینکه تیم به نقطه‌ی انفجار برسه نشانه‌هایی دیده می‌شه:

🔹مشارکت در جلسات کمتر می‌شه

🔹تغییرات کوچیک با مقاومت مواجه می‌شن

🔹ایمیل‌ها یا پیام‌ها دیرتر جواب داده می‌شن

🔹درخواست برای تغییر تیم یا پروژه بالا می‌ره

۶. خطر قهرمان‌سازی از یک توسعه‌دهنده

گاهی یک توسعه‌دهنده‌ی خیلی قوی تبدیل می‌شه به «منبع همه‌چیز». این آدم می‌تونه عملکرد تیم رو بالا ببره ولی اگر سیستم رو بر پایه اون فرد بچینید در نبودش کل سیستم آسیب می‌بینه.

۷. فیدبک گرفتن از تیم فنی (نه فقط  بازخورد دادن)

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

🔹«کدوم بخش کار من باعث می‌شه تمرکزت از بین بره؟»

🔹«اگر جای من بودی چی رو در همکاری با تیم تغییر می‌دادی؟»

جمع‌بندی

همکاری با برنامه نویسی ها، یک مهارت آموختنی است

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

👨‍💻 توسعه‌دهنده‌ها نه آدم‌های عجیب و غریبی‌اند و نه موجوداتی از سیاره‌ای دیگر. آن‌ ها فقط در یک مدل ذهنی کاملا متفاوت کار می‌کنند که اگر آن را بشناسید می‌توانید نه‌ تنها از تعارض‌ ها جلوگیری کنید، بلکه تیم‌تان را به نقطه اوج برسانید.

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

✅ احترام به زمان تمرکز
✅ شفافیت در خروجی‌ها
✅ جلسات هدفمند
✅ فیدبک دوطرفه
✅ و پرهیز از قهرمان‌سازی

همه‌ی این‌ها فقط تاکتیک نیستند؛ ابزارهایی هستند برای ساختن اعتماد واقعی و پایداری تیم.

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

پس قدم اول را بردارید؛
با گفت‌وگو، مشاهده و اصلاح سبک مدیریت‌تان.

در دنیای امروز، رهبرانی که زبان تیم فنی را بلد باشند، نه‌ تنها پروژه‌های بهتری می‌سازند بلکه سازمان‌های بهتری هم می‌سازند.