معرفی
این نقشه راه برای توسعه‌دهنده باتجربه‌ای طراحی شده است که می‌خواهد توانایی‌های لازم برای مدیریت یک تیم مهندسی نرم‌افزار را به‌صورت مرحله‌ای یاد بگیرد و تمرین کند. این مسیر برای آموزش برنامه‌نویسی از صفر نیست و فرض می‌کند پیش‌تر در فرایندهایی مانند توسعه، بازبینی کد، انتشار یا نگهداری نرم‌افزار مشارکت داشته‌اید.
تفاوت مدیر مهندسی نرم‌افزار با سرپرست فنی
مدیر مهندسی نرم‌افزار (Engineering Manager) با سرپرست فنی (Technical Lead) یکسان نیست. در این نقش، تمرکز معمولاً از مشارکت فنی فردی به موفقیت تیم، رشد اعضا، تحویل مؤثر، هماهنگی و ایجاد محیط مناسب برای انجام کار منتقل می‌شود.
بااین‌حال، دامنه مسئولیت‌ها در همه شرکت‌ها یکسان نیست. در تیم‌های کوچک، مدیر مهندسی ممکن است همچنان بخشی از زمان خود را صرف کدنویسی، بازبینی کد یا تصمیم‌گیری‌های معماری کند، اما در سازمان‌های بزرگ‌تر، تمرکز او معمولاً بیشتر بر مدیریت افراد، برنامه‌ریزی، هماهنگی و بهبود عملکرد تیم است.
ساختار مسیر یادگیری
این نقشه راه در هشت گام تنظیم شده است. ابتدا قضاوت فنی و درک چرخه توسعه و تحویل نرم‌افزار را تقویت می‌کنید. سپس به‌تدریج مهارت‌هایی مانند مدیریت افراد، حفظ کیفیت در سطح تیم، ارتباط با ذی‌نفعان، استخدام و بهبود فرایندهای کاری را تمرین خواهید کرد.
ترتیب گام‌ها به‌گونه‌ای است که ابتدا پایه فنی و شناخت فرایندهای مهندسی تثبیت شود و بعد مهارت‌های مدیریتی موردنیاز برای هدایت یک تیم توسعه پیدا کنند.
زمان‌بندی و محدودیت تمرین‌های آموزشی
مجموع زمان پیشنهادی برای گام‌های این نقشه راه حدود ۳۶۰ ساعت است. این عدد صرفاً برآورد آموزشی همین مسیر است و نباید آن را معیاری استاندارد برای آمادگی مدیریت یک تیم در نظر گرفت.
بخشی از مهارت‌های این نقش فقط در تجربه واقعی شکل می‌گیرند. برگزاری گفت‌وگوهای فردی، مدیریت تعارض، تصمیم‌گیری درباره عملکرد اعضای تیم و هدایت افراد در شرایط دشوار را نمی‌توان به‌طور کامل با مطالعه یا تمرین‌های زمان‌بندی‌شده جایگزین کرد. بنابراین، بهتر است یادگیری مفاهیم را با فرصت‌های عملی برای پذیرفتن مسئولیت‌های تیمی همراه کنید.
ابزارهای موردنیاز در مسیر
ابزارهای معرفی‌شده در این مسیر جنبه پیشنهادی دارند و انتخاب آن‌ها باید با توجه به ساختار و نیازهای تیم انجام شود. در فهرست زیر به چند مورد اشاره کرده‌‌ایم:
Jira یا ابزارهای مشابه: برای پیگیری جریان کار، مشاهده وضعیت وظایف و شناسایی ریسک‌های تحویل.
Confluence یا Notion: برای مستندسازی تصمیم‌ها، فرایندها و دانش تیمی.
GitHub یا GitLab: برای مشاهده فرایند توسعه، بازبینی کد و همکاری فنی اعضای تیم.
ابزارهای پایش و مشاهده‌پذیری: برای بررسی وضعیت سرویس‌ها و محصولات عملیاتی، به‌ویژه زمانی که تیم مسئول نگهداری و پشتیبانی آن‌ها نیز هست.
هدف از یادگیری این ابزارها صرفاً تسلط بر امکانات آن‌ها نیست، بلکه باید بتوانید از اطلاعاتی که در اختیار می‌گذارند برای تصمیم‌گیری بهتر، رفع موانع و بهبود عملکرد تیم استفاده کنید.
خروجی مورد انتظار از این مسیر
در پایان این نقشه راه باید بتوانید علاوه بر درک تصمیم‌های فنی، مسئولیت‌های مدیریتی یک تیم مهندسی را نیز بهتر ارزیابی و هدایت کنید. این موضوع، از رشد و عملکرد اعضای تیم گرفته تا برنامه‌ریزی تحویل، هماهنگی با ذی‌نفعان و بهبود شیوه انجام کار را شامل می‌شود.
هدف نهایی، تبدیل‌شدن به مدیری نیست که صرفاً وظایف را توزیع و پیشرفت آن‌ها را پیگیری می‌کند، بلکه باید بتوانید شرایطی فراهم کنید که تیم با کیفیت مناسب، همکاری مؤثر و درک روشنی از اولویت‌ها به اهداف خود برسد.
مخاطبان نقشه راه
این مسیر برای توسعه‌دهندگان ارشد و رهبران فنی نوشته شده است که تجربه واقعی تحویل نرم‌افزار دارند و می‌خواهند مسئولیت رشد افراد، سلامت تیم و تحویل قابل‌پیش‌بینی را بپذیرند. برای فردی که هنوز تجربه توسعه حرفه‌ای یا همکاری نزدیک با تیم نرم‌افزار ندارد، ابتدا مسیر توسعه‌دهندگی مناسب‌تر است.
دستاورد پایانی
پس از طی این مسیر، می‌توانید یک تیم توسعه را از نظر ظرفیت، کیفیت، ریسک و تحویل هدایت کنید، جلسه‌های یک‌به‌یک و بازخورد مؤثر برگزار کنید، با محصول و ذی‌نفعان درباره اولویت‌ها و بدهی فنی مذاکره کنید و برای استخدام، رشد و ارزیابی توسعه‌دهندگان فرایند قابل‌اجرا بسازید. آمادگی نهایی به تجربه عملی هدایت افراد در محیط کار وابسته است، نه صرفاً گذراندن آموزش‌ها.
پیش‌نیازها
پیش از شروع، بهتر است با موارد زیر آشنا باشید.
- مهارت برنامه‌نویسی Programming
- مهارت طراحی سیستم و معماری نرم‌افزار System Design and Software Architecture
- مهارت کنترل نسخه Version Control
- مهارت بازبینی کد Code Review
- مهارت تضمین کیفیت نرم‌افزار Software Quality Assurance (SQA)
- مهارت ارتباطات فنی Technical Communication
- مهارت کاربست اصول و روش‌های چابک Agile Practices
- تجربه عملی تحویل و نگهداری حداقل یک محصول یا سامانه نرم‌افزاری
- تجربه همکاری روزمره با توسعه‌دهندگان، مدیر محصول و تیم تست
- انگلیسی فنی برای خواندن مستندات و منابع تخصصی
- آمادگی برای مسئولیت‌پذیری درباره نتیجه تیم، نه فقط خروجی فردی
مسیر یادگیری شغل مدیر مهندسی نرم‌افزار
-
۲۰ ساعت
ارزیابی فاصله از توسعه‌دهندگی تا مدیریت
هدف گام: مشخص کردن شکاف‌های فنی، رفتاری و عملیاتی پیش از پذیرش مسئولیت مدیریت افراد.
ابتدا تجربه خود را در سه محور بررسی کنید: تحویل نرم‌افزار، هدایت همکاران و همکاری با محصول. مدیر مهندسی لازم نیست بهترین برنامه‌نویس تیم باشد، اما باید بتواند ریسک معماری، کیفیت، وابستگی‌ها و ظرفیت را تشخیص دهد.
فهرستی از موقعیت‌های واقعی بسازید که در آن‌ها تصمیم فنی گرفته‌اید، بازبینی کد انجام داده‌اید، به همکار کمک کرده‌اید یا مانع تحویل را رفع کرده‌اید. سپس برای هر محور، شواهد و نقطه ضعف خود را ثبت کنید. برای ثبت ارزیابی و برنامه ۹۰ روزه، از Notion یا Google Docs استفاده کنید. انتخاب ابزار مهم نیست، اما سند باید قابل‌به‌روزرسانی و قابل‌اشتراک با منتور یا مدیر باشد.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
تفاوت مسئولیت فردی و مسئولیت نتیجه تیممرز نقش مدیر مهندسی و سرپرست فنیشناسایی شکاف شایستگی‌های مدیریتیثبت شواهد اثرگذاری فنی و تیمیپروژه پیشنهادی: یک ارزیابی یک‌صفحه‌ای از آمادگی خود بنویسید که شامل سه تجربه واقعی، سه شکاف مهارتی و یک برنامه ۹۰ روزه برای گرفتن مسئولیت‌های رهبری کوچک باشد.
معیار پایان گام: می‌توانید با مثال‌های واقعی توضیح دهید در کدام بخش‌های تحویل، رشد افراد و هماهنگی تیمی توانمندید و برای هر شکاف، اقدام مشخصی دارید.
دوره پیشنهادی
-
۵۰ ساعت
تقویت قضاوت فنی و درک چرخه تحویل
هدف گام: توانایی گفت‌وگو درباره معماری، کیفیت و ریسک تحویل بدون ورود به مدیریت جزئی کدنویسی.
مدیر مهندسی باید بتواند تصمیم‌های فنی را به پیامدهای زمان، هزینه، پایداری و تجربه کاربر متصل کند. روی خواندن طراحی‌های فنی، تشخیص وابستگی‌ها، بررسی بدهی فنی و تحلیل رخدادهای عملیاتی تمرکز کنید.
در این مرحله، قرار نیست در همه فناوری‌ها متخصص شوید. هدف، ساختن چارچوب قضاوت است: چه زمانی بازطراحی لازم است، چه زمانی راه‌حل ساده‌تر کافی است و چه ریسکی باید پیش از انتشار به ذی‌نفعان اعلام شود. اگر تیم از Confluence استفاده می‌کند، سند تصمیم را در همان فضا ثبت کنید، Grafana برای دیدن روند شاخص‌های عملیاتی و GitLab برای بررسی جریان تغییرها و بازبینی‌ها مفید است.
مهارت‌ها
طراحی سیستم و معماری نرم‌افزاربرنامه‌ریزی تحویل فنی نرم‌افزارتضمین کیفیت نرم‌افزارپایش و مشاهده‌پذیری سامانه‌هاارتباطات فنیابزارها
مفاهیم تکمیلی
تبدیل تصمیم معماری به ریسک تحویلشناسایی و اولویت‌بندی بدهی فنیتحلیل وابستگی‌های بین‌تیمیتعریف معیارهای انتشار امنمرور رخداد و یادگیری پس از خطاپروژه پیشنهادی: برای یک قابلیت واقعی یا فرضی، سند تصمیم فنی تهیه کنید که گزینه‌ها، وابستگی‌ها، ریسک‌های انتشار، راه کاهش ریسک و معیار موفقیت را توضیح دهد.
معیار پایان گام: می‌توانید یک تصمیم فنی را برای مخاطب غیرفنی توضیح دهید و میان کیفیت، زمان تحویل و هزینه نگهداری معامله آگاهانه انجام دهید.
دوره پیشنهادی
-
۴۵ ساعت
یادگیری برنامه‌ریزی تحویل و مدیریت جریان کار
هدف گام: تبدیل هدف محصول به برنامه تحویل واقع‌بینانه با ظرفیت، وابستگی و ریسک مشخص.
مدیریت مهندسی به معنای تخصیص خشک تسک‌ها نیست. ابتدا کار را به خروجی‌های قابل‌تحویل، وابستگی‌ها و فرض‌های قابل‌آزمون تقسیم کنید. سپس همراه تیم ظرفیت تقریبی، ریسک‌های فنی و نیازهای کیفیت را بررسی کنید.
از داده‌های جریان کار برای گفت‌وگوی بهتر استفاده کنید، نه برای فشار بر افراد. زمان چرخه، حجم کار در جریان، باگ‌های باز و تأخیرهای تکرارشونده می‌توانند نشانه گلوگاه باشند اما بدون شنیدن زمینه تیم، معیار مناسبی برای قضاوت عملکرد فردی نیستند. Jira یا ابزار مشابه را برای مشاهده وضعیت کار و وابستگی‌ها به کار ببرید، Microsoft Excel زمانی مناسب است که بخواهید ظرفیت، روند تأخیر یا ریسک‌ها را در یک تحلیل سبک جمع‌بندی کنید، Confluence نیز محل ثبت فرض‌ها و تصمیم‌های برنامه تحویل است.
مهارت‌ها
برنامه‌ریزی تحویل فنی نرم‌افزارکاربست اصول و روش‌های چابکتحلیل جریان کار و سنجه‌های چابکمدیریت ریسک پروژهمدیریت ذینفعانابزارها
مفاهیم تکمیلی
ظرفیت‌سنجی تیم توسعهمدیریت کار در جریانشناسایی گلوگاه‌های تحویلمدیریت وابستگی‌های فنیگزارش ریسک و تغییر دامنهتعریف پیش‌نیازهای انتشارپروژه پیشنهادی: برای یک انتشار شش‌هفته‌ای، برد کار، جدول ظرفیت، فهرست وابستگی‌ها و گزارش هفتگی ریسک طراحی کنید. در پایان، یک بازنگری کوتاه از تفاوت برنامه و نتیجه بنویسید.
معیار پایان گام: می‌توانید برنامه تحویل را با فرض‌ها و ریسک‌های آشکار ارائه کنید و هنگام تغییر شرایط، دامنه یا زمان‌بندی را شفاف بازبینی کنید.
دوره پیشنهادی
-
۵۵ ساعت
ساختن مهارت مدیریت افراد و بازخورد
هدف گام: برگزاری گفت‌وگوهای یک‌به‌یک، بازخورد مشخص و برنامه رشد برای توسعه‌دهندگان.
تغییر اصلی از سرپرست فنی به مدیر مهندسی، انتقال تمرکز از راه‌حل به افراد و سیستم تیم است. جلسه یک‌به‌یک محل گزارش وضعیت تسک نیست؛ باید برای شناخت انگیزه، موانع، بازخورد دوطرفه و رشد حرفه‌ای استفاده شود.
بازخورد را بر مشاهده مشخص، اثر رفتار و انتظار آینده بنا کنید. در مسائل عملکردی، استاندارد موفقیت، حمایت لازم و زمان بازبینی را روشن کنید. گفت‌وگوهای دشوار را به تعویق نیندازید، اما بدون شواهد و شنیدن دیدگاه فرد نیز قضاوت نکنید. از Notion یا Google Docs فقط برای ثبت برنامه رشد، توافق‌های قابل‌پیگیری و یادداشت‌هایی استفاده کنید که نگهداری آن‌ها با رعایت محرمانگی ضروری است.
مهارت‌ها
مدیریت عملکرد کارکنانمنتورینگ فنی توسعه‌دهندگان نرم‌افزارارتباط با کارکنان و گفت‌وگوهای دشوارحل تعارض در تیم‌های محصول و نرم‌افزارتسهیل‌گری تیمابزارها
مفاهیم تکمیلی
ساختار جلسه یک‌به‌یکبازخورد رفتاری و قابل‌اقدامتدوین برنامه رشد فردیگفت‌وگو درباره عملکرد ضعیفمدیریت تعارض در تیم توسعهحفظ محرمانگی گفت‌وگوهای فردیپروژه پیشنهادی: برای دو شخصیت فرضی در یک تیم توسعه، برنامه رشد سه‌ماهه بنویسید و برای هرکدام سه سناریوی بازخورد، پرسش‌های جلسه یک‌به‌یک و معیار پیگیری تعریف کنید.
معیار پایان گام: می‌توانید جلسه یک‌به‌یک را با هدف روشن اداره کنید، بازخورد قابل‌اقدام بدهید و رشد فرد را بدون تبدیل‌شدن به کنترل‌گر جزئی پیگیری کنید.
دوره پیشنهادی
-
۴۵ ساعت
هدایت کیفیت، بازبینی کد و پایداری
هدف گام: ساختن سازوکارهای تیمی برای حفظ کیفیت بدون ایجاد گلوگاه مدیریتی.
کیفیت نرم‌افزار فقط وظیفه تیم تست نیست. مدیر مهندسی باید توافق تیم درباره بازبینی کد، تست، مالکیت سرویس، رسیدگی به رخداد و پرداخت بدهی فنی را به فرایندهای قابل‌اجرا تبدیل کند.
به‌جای تأیید شخصی همه تغییرها، معیارهای تصمیم و مالکیت روشن بسازید. GitLab یا GitHub را متناسب با مخزن سازمان برای بررسی روند درخواست‌های ادغام و بازبینی انتخاب کنید. Jenkins یا ابزار تحویل مستمر موجود تیم برای مشاهده وضعیت خط لوله انتشار است. Prometheus داده خام شاخص‌های سرویس را فراهم می‌کند و Grafana برای دیدن داشبورد و تشخیص روند خطا یا افت عملکرد به کار می‌رود؛ اگر تیم سرویس عملیاتی ندارد، این دو ابزار ضرورت ندارند.
مهارت‌ها
بازبینی کدتضمین کیفیت نرم‌افزارتست نرم‌افزاریکپارچه‌سازی و تحویل مستمرپایش و مشاهده‌پذیری سامانه‌هابهبود مستمر فرایند تیمابزارها
مفاهیم تکمیلی
تعریف استاندارد بازبینی کدمالکیت سرویس و پاسخ‌گویی عملیاتیسیاست پرداخت بدهی فنیتحلیل خطاهای پس از انتشارطراحی بازنگری پس از رخدادتعادل سرعت تحویل و پوشش تستپروژه پیشنهادی: برای یک تیم فرضی، پلی‌بوک کیفیت شامل معیار درخواست ادغام، حداقل انتظار تست، فرایند رسیدگی به رخداد و روش اولویت‌بندی بدهی فنی تهیه کنید.
معیار پایان گام: می‌توانید فرایند کیفیتی طراحی کنید که مالکیت آن میان اعضای تیم توزیع شده باشد و اثر آن با شاخص‌های عملیاتی قابل بررسی باشد.
-
۴۰ ساعت
هم‌راستاسازی با محصول و ذی‌نفعان
هدف گام: بیان محدودیت‌ها و انتخاب‌های فنی به زبان تصمیم‌های محصول و کسب‌وکار.
مدیر مهندسی باید اختلاف میان خواسته محصول و ظرفیت فنی را به گفت‌وگویی سازنده تبدیل کند. به‌جای پاسخ مبهم «نمی‌شود»، گزینه‌ها را با هزینه، ریسک، زمان تقریبی و پیامد کیفیت ارائه کنید.
تصمیم‌ها، توافق‌ها و تغییرهای مهم را مکتوب کنید. Confluence یا ابزار مستندسازی مشترک برای ثبت تصمیم‌ها مناسب است؛ Jira یا ابزار مدیریت کار برای پیوند تصمیم با کارهای قابل‌پیگیری استفاده می‌شود. Google Slides و Microsoft Teams فقط زمانی مفیدند که سازمان از آن‌ها برای ارائه وضعیت و هماهنگی جلسه استفاده می‌کند. جایگزین‌های سازمانی نیز همان کارکرد را دارند.
مهارت‌ها
مدیریت ذی‌نفعانارتباطات فنیتعریف و مدیریت نیازمندی‌های محصولتدوین نقشه راه و اولویت‌بندی محصولارتباطات و گزارش‌دهی پروژهابزارها
مفاهیم تکمیلی
تبدیل محدودیت فنی به گزینه تصمیممدیریت انتظار ذی‌نفعانمستندسازی تصمیم‌های فنیمذاکره درباره دامنه و زمان تحویلشفاف‌سازی مسئولیت میان تیم‌هاگزارش وضعیت بدون پنهان‌کردن ریسکپروژه پیشنهادی: برای یک درخواست محصول با زمان محدود، یادداشت تصمیمی بنویسید که سه گزینه اجرایی، پیامد هر گزینه، ریسک‌ها و پیشنهاد نهایی شما را بیان کند.
معیار پایان گام: می‌توانید در جلسه با محصول یا مدیریت، محدودیت فنی را به زبان اثر کسب‌وکاری توضیح دهید و توافق‌های حاصل را قابل‌پیگیری مستند کنید.
-
۳۵ ساعت
تمرین استخدام، ورود و شکل‌دهی تیم
هدف گام: طراحی فرایند منصفانه برای ارزیابی، انتخاب و راه‌اندازی توسعه‌دهندگان جدید.
استخدام مدیر مهندسی فقط سنجش مهارت کدنویسی نیست. باید بدانید تیم چه مسئله‌ای دارد، کدام شایستگی واقعاً کم است و مصاحبه چگونه می‌تواند شواهد مرتبط با آن شایستگی را جمع کند.
برای هر موقعیت، معیار ارزیابی و نشانه‌های قابل‌مشاهده تعریف کنید. پس از انتخاب، برنامه ورود عضو جدید باید دسترسی‌ها، شناخت محصول، اولین خروجی کوچک، منتور و زمان بازخورد را پوشش دهد. Google Forms و Google Sheets می‌توانند برای کارت امتیاز و ثبت منظم شواهد مصاحبه به کار روند. Confluence برای راهنمای ورود و GitLab برای نخستین تغییر کوچک عضو جدید کاربرد دارد. ابزارها را با سامانه‌های داخلی سازمان جایگزین کنید، اما معیارهای ارزیابی را یکسان نگه دارید.
مهارت‌ها
جذب و استخدام کارکنانانتخاب و ارزیابی کارکنانمنتورینگ فنی توسعه‌دهندگان نرم‌افزارارتباطات فنیمدیریت عملکرد کارکنانابزارها
مفاهیم تکمیلی
تعریف شایستگی برای نقش فنیطراحی مصاحبه ساختاریافتهکالیبره‌کردن ارزیابانثبت شواهد و تصمیم استخدامیطراحی برنامه ورود ۳۰ روزهتعیین منتور و نخستین خروجی عضو جدیدپروژه پیشنهادی: برای استخدام یک توسعه‌دهنده بک‌اند فرضی، کارت امتیاز مصاحبه، پرسش‌های رفتاری و فنی، راهنمای ارزیاب و برنامه ورود ۳۰ روزه طراحی کنید.
معیار پایان گام: می‌توانید نیاز استخدامی را به شایستگی‌های قابل‌ارزیابی تبدیل کنید و برای ورود عضو جدید برنامه‌ای با مسئول و خروجی روشن بسازید.
دوره پیشنهادی
-
۷۰ ساعت
رهبری عملی یک بهبود تیمی
هدف گام: ترکیب مهارت‌های آموخته‌شده در یک مسئله واقعی و نشان‌دادن اثر قابل‌مشاهده بر تیم یا تحویل.
برای آمادگی مدیریت مهندسی، یک مسئله محدود اما واقعی انتخاب کنید: کاهش زمان بازبینی کد، شفاف‌کردن برنامه انتشار، بهبود رسیدگی به رخداد، راه‌اندازی جلسه‌های یک‌به‌یک یا کاهش یک گلوگاه مشخص. مسئله را با داده و گفت‌وگو با افراد تعریف کنید، نه با فرض شخصی.
چرخه بهبود را کامل اجرا کنید: وضعیت آغازین، هدف، اقدام‌های کوچک، مسئول‌ها، بازبینی دوره‌ای و نتیجه. Jira یا ابزار مشابه برای مشاهده تغییر جریان کار، Confluence برای ثبت فرض‌ها و درس‌آموخته‌ها، Microsoft Excel برای مقایسه داده آغازین و نتیجه و GitLab برای بررسی اثر تغییر بر روند بازبینی یا تحویل کاربرد دارد. اگر اختیار رسمی مدیریت ندارید، این تمرین را در نقش سرپرست فنی، منتور یا تسهیل‌گر انجام دهید.
مهارت‌ها
مدیریت مهندسی نرم‌افزاررهبری فنی تیم نرم‌افزاربهبود مستمر فرایند تیمتحلیل جریان کار و سنجه‌های چابکمدیریت ذی‌نفعانمدیریت عملکرد کارکنانابزارها
مفاهیم تکمیلی
تعریف مسئله با شواهدطراحی آزمایش بهبود فرایندتسهیل‌گری جلسه بازنگریاندازه‌گیری اثر تغییرمدیریت مقاومت در برابر تغییرمستندسازی درسآموختههاپروژه پیشنهادی: یک پروژه بهبود ۶ تا ۸ هفته‌ای در تیم خود یا یک تیم شبیه‌سازی‌شده اجرا کنید و گزارش نهایی شامل مسئله، داده آغازین، اقدام‌ها، بازخورد تیم، نتیجه و اقدام بعدی تهیه کنید.
معیار پایان گام: یک نمونه مستند از بهبود تیمی دارید که در آن مسئله، تصمیم‌ها، مشارکت افراد و اثر نهایی به‌صورت قابل‌بررسی ثبت شده است.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما می‌تواند کمتر یا بیشتر باشد.
ابزارهای مسیر
برای آشنایی بهتر با این مسیر، توجه به موارد زیر می‌تواند مفید باشد.
خطاهای رایج مسیر
در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.
-
تبدیل‌شدن به گلوگاه همه تصمیم‌ها
برای بازبینی کد، تصمیم‌های فنی و رسیدگی به رخداد، مالک و معیار تصمیم مشخص کنید. اگر همه کارها برای تأیید شما متوقف می‌شوند، مسئولیت را توزیع کنید و به‌جای کنترل جزئی، نتیجه و ریسک را پیگیری کنید.
-
سنجش افراد با شاخص‌های جریان کار
زمان چرخه، تعداد درخواست‌های ادغام یا تسک‌های بسته‌شده را برای کشف گلوگاه فرایند به کار ببرید، نه رتبه‌بندی افراد. عملکرد فرد را با انتظار نقش، کیفیت همکاری و شواهد چندمنبعی بررسی کنید.
-
نادیده گرفتن بدهی فنی تا زمان بحران
بدهی فنی را با اثر آن بر خطا، سرعت تغییر، هزینه نگهداری یا ریسک امنیتی ثبت کنید. برای پرداخت آن ظرفیت مشخص بگذارید و اولویت را همراه محصول تعیین کنید.
-
برگزاری جلسه یک‌به‌یک به شکل گزارش تسک
بخش عمده جلسه را به موانع، بازخورد، انگیزه، رشد و رابطه کاری اختصاص دهید. وضعیت پروژه را در ابزار مدیریت کار یا جلسه تیمی پیگیری کنید.
-
قول دادن زمان تحویل بدون بررسی تیم
پیش از تعهد، برآورد تیم، وابستگی‌ها، نیاز تست و ریسک انتشار را بررسی کنید. هنگام ابهام، گزینه‌های دامنه و زمان را همراه پیامد هرکدام مطرح کنید.
-
کپی کردن فرایندهای شرکت‌های بزرگ
هر فرایند را با مسئله مشخص شروع کنید. تیم کوچک ممکن است به مستندات سبک و جلسه کوتاه نیاز داشته باشد، نه لایه‌های متعدد تأیید و گزارش‌دهی.
-
عقب انداختن گفت‌وگوهای دشوار
بازخورد را نزدیک به رخداد، بر پایه مشاهده مشخص و با انتظار آینده بیان کنید. پیش از نتیجه‌گیری، دیدگاه فرد و موانع محیطی را بشنوید.
چک‌لیست آمادگی شغلی
موارد زیر را یک‌به‌یک بررسی کنید تا چیزی جا نماند:
- می‌توانم ریسک‌های فنی، وابستگی‌ها و ظرفیت را به برنامه تحویل واقع‌بینانه تبدیل کنم.
- می‌توانم جلسه یک‌به‌یک منظم برگزار کنم و برای رشد هر توسعه‌دهنده اقدام مشخص تعریف کنم.
- می‌توانم بازخورد رفتاری، روشن و قابل‌اقدام بدهم و گفت‌وگوهای دشوار را مدیریت کنم.
- می‌توانم درباره بدهی فنی، کیفیت و زمان تحویل با مدیر محصول مذاکره کنم.
- می‌توانم فرایند بازبینی کد، تست و رسیدگی به رخداد را بدون گلوگاه‌شدن خودم بهبود دهم.
- می‌توانم با داده‌های جریان کار، گلوگاه تیم را تشخیص دهم و آن را با ارزیابی فردی اشتباه نگیرم.
- می‌توانم برای یک نقش فنی، معیار استخدام، مصاحبه ساختاریافته و برنامه ورود طراحی کنم.
- می‌توانم یک بهبود تیمی را از تعریف مسئله تا سنجش نتیجه مستند و هدایت کنم.
پرسش‌های پرتکرار
در این بخش، به تعدادی از پرسش‌های رایج درباره این مسیر پاسخ داده شده است.
گام‌ها را دقیقاً به همین ترتیب انجام دهم؟
ترتیب پیشنهادی مهم است، زیرا مدیریت افراد و بهبود تیمی بر قضاوت فنی و درک جریان تحویل تکیه دارد. اگر هم‌اکنون مسئولیت مدیریت افراد دارید، می‌توانید گام چهارم را زودتر تمرین کنید؛ اما گام پایانی را پس از انجام دست‌کم چند تمرین در گام‌های قبل اجرا کنید.
پروژه نهایی را در تیم واقعی انجام دهم یا شبیه‌سازی‌شده؟
تیم واقعی ارزش بیشتری دارد، چون باید با محدودیت، مقاومت، داده ناقص و بازخورد افراد کار کنید. اگر به چنین تیمی دسترسی ندارید، پروژه شبیه‌سازی‌شده را با داده فرضی اما معیارهای روشن اجرا کنید و آن را جایگزین کامل تجربه عملی ندانید.
آیا گواهینامه برای طی‌کردن این نقشه راه لازم است؟
این نقشه راه بر ساختن شواهد عملی تمرکز دارد: برنامه تحویل، سند تصمیم، برنامه رشد، فرایند کیفیت و پروژه بهبود تیمی. گواهینامه می‌تواند در یادگیری ساختارمند کمک کند، اما به‌تنهایی جایگزین این شواهد و تجربه هدایت تیم نیست.
چقدر زمان لازم است تا برای این نقش آماده شوم؟
مجموع زمان تخمینی گام‌ها ۳۶۰ ساعت است. برای فردی با پیش‌زمینه توسعه حرفه‌ای که هفته‌ای ۸ تا ۱۲ ساعت زمان می‌گذارد، بخش آموزشی حدود ۸ تا ۱۱ ماه طول می‌کشد. تمرین پروژه نهایی و دریافت بازخورد واقعی معمولاً زمان کل را به حدود ۴۰۰ تا ۵۰۰ ساعت می‌رساند.
معیار پایان این نقشه راه چیست؟
وقتی بتوانید یک مسئله تحویل یا کیفیت را با شواهد تعریف کنید، افراد و ذی‌نفعان را در تصمیم مشارکت دهید، اقدام‌ها را پیگیری کنید و اثر تغییر را مستند نشان دهید، به معیار اصلی مسیر نزدیک شده‌اید. چک‌لیست آمادگی صفحه را نیز برای مرور شکاف‌های باقی‌مانده استفاده کنید.
مدیر مهندسی باید همه فناوری‌های تیم را بلد باشد؟
خیر. او باید برای پرسیدن سؤال درست، تشخیص ریسک و ارزیابی معامله‌های فنی، درک کافی داشته باشد. تخصص عمیق در همه اجزای سامانه ضروری نیست اما واگذاری کامل قضاوت فنی بدون فهم زمینه نیز برای این نقش خطرناک است.
آموزش‌های مرتبط در فرادرس
-
آموزش مهندسی نرم افزار پیشرفته
-
آموزش رهبری و مدیریت در کسب و کار + گواهینامه
-
آموزش مدیریت پروژه با متدولوژی چابک + گواهینامه
-
آموزش کاربرد رفتار سازمانی و اصول مدیریت در تیم سازی + گواهینامه
-
آموزش مهندسی نرم افزار 1 + گواهینامه
-
آموزش مدیریت چابک در جلسات + گواهینامه
-
آموزش مدل های فرایند در مهندسی نرم افزار (رایگان)
