برنامه‌ریزی مهندسی در مقابل برنامه‌ریزی مدیریتی

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

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

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

حالا می خواهم دنیای برنامه ریزی رو از نگاه توسعه دهندگان و از نگاه مدیران براتون شفاف تر کنم و در مورد دغدغه های که در هر دو دنیا گفتگو کنیم:

دنیای برنامه ریزی به عنوان توسعه دهنده (سازنده)

توسعه دهنده کسی هست که با استفاده از دانش عمیقش در توسعه فنی، در دوره‌های بلند مدت محصولی رو میسازه. اصولا تمرکزش روی ساختن هست و باید تا حد امکان از گسیختگی (interrupt) های کاری بدور باشه تا بهره‌وری بیشتری داشته باشه. این بخش دست هنرمندان و استادکارانی هست که باید بدونیم micro-manage براشون مثل آفت می‌مونه. نحوه تعامل با این سازندگان و استادکاران هم هنر خاص خودش رو داره که اگر درک متقابل از روحیه افراد و کاری که داره انجام میشه رو داشته باشید میتونید از این خان گذر کنید.

دنیای برنامه‌ریزی به عنوان مدیر

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

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

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

جلسات:‌ جایی که هر دو جهان با هم برخورد می‌کنند

جلسه‌ها بهترین(راحت‌ترین) ابزاری هست که یک مدیر می‌تواند،‌تیم خود و تیم‌های تحت تاثیر خود را با هم Align کند. برعکس، جلسه های مداوم و تکراری برای سازندگان، بسان موانعی هستند که تنها آنها را از ددلاین های قول داده شده دور می‌کنند.

حالا چطور این دو مدل کار را در جلسه مدیریت کنیم؟

جواب: بسیار سخت است، اما قابل اجراست. قطعا هر تیمی بایستی به ازای اندازه بلوغ خود میتواند دست به کارهای دموکراتیک بزند، عموما در تیم های نابالغ همیشه یک تصمیم گیرنده که دارای نفوذ بیشتری در میان مدیران ارشد دارد، برای تصمیم گیری (فصل الخطاب) قرار داده می شود. بارها تجربه ثابت کرده که تیم هایی که همیشه یک نفر کتبا و شفاها در آنها مدعی گرفتن تصمیم آخر هست، در بلند مدت به ستوه آمده اند و به مجموعه ای از افراد بی هدف تبدیل شده اند.

صادقانه حدود دوسالی هست که معتقد شدم که جلسات موثر برای تعادل در نیاز افراد برنامه ساز و افرادی که برنامه ریزی مدیریتی قرار دارند، بسیار مهم هستند و البته اینجاست که هر دو جهان با هم برخورد می کنند.

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

ازین رو برای همواره برای یک مدیر فنی، چالش ارتباط تیم ها برای پیشبرد و برداشتن تعهد برای خلق محصول در زمان معین، بزرگتر از چالش تکنولوژی و High-Available نگه داشتن سرویس های یک شرکت می شود.

باشد که گفته هایی که در ذهنم می آمد به درد شما دوستان عزیز هم خورده باشد.

ارادتمند آرش کرمی