معرفی
سرپرست فنی معمولاً پس از کسب تجربه عملی و قابل‌اتکا در توسعه و تحویل نرم‌افزار به این نقش نزدیک می‌شود، نه صرفاً با گذراندن یک دوره مدیریتی. این نقشه راه در هشت گام طراحی شده و از تقویت قضاوت فنی آغاز می‌شود و به مهارت‌هایی مانند بازبینی کد، طراحی سیستم، برنامه‌ریزی تحویل، هدایت فرایند حل مسئله و رشد فنی اعضای تیم می‌رسد.
دامنه مسئولیت‌های سرپرست فنی
دامنه نقش Technical Lead در همه سازمان‌ها یکسان نیست. در بعضی تیم‌ها، تمرکز اصلی این نقش بر معماری و کیفیت فنی است ولی در تیم‌های دیگر، برنامه‌ریزی تحویل، منتورینگ، هماهنگی با تیم محصول و پاسخ‌گویی به رخدادهای عملیاتی نیز بخشی از مسئولیت‌های آن محسوب می‌شود.
مدیریت مستقیم اعضای تیم هم لزوماً بر عهده سرپرست فنی نیست. در برخی سازمان‌ها Tech Lead مسئولیت هدایت فنی را بر عهده دارد و مدیریت افراد به Engineering Manager یا نقش دیگری سپرده می‌شود. بنابراین، پیش از ارزیابی یک موقعیت شغلی باید مشخص کنید این نقش دقیقاً چه مسئولیت‌ها و اختیاراتی دارد.
زمان‌بندی و میزان تمرین
مجموع تمرین‌های پیشنهادی این مسیر حدود ۵۸۰ ساعت است. این عدد برآورد آموزشی همین نقشه راه محسوب می‌شود و زمان واقعی پیشرفت به تجربه قبلی، پیچیدگی پشته فنی و میزان دسترسی شما به پروژه‌ها و تیم‌های واقعی بستگی دارد.
ازآنجاکه بخش مهمی از مهارت‌های این نقش در موقعیت‌های واقعی شکل می‌گیرند، مطالعه منابع آموزشی به‌تنهایی کافی نیست. بهتر است در کنار یادگیری، مسئولیت تصمیم‌های فنی، بازبینی تغییرات و پیگیری مشکلات یک پروژه واقعی را نیز به‌تدریج بر عهده بگیرید.
پیش‌نیازهای ورود به مسیر
پیش از شروع این مسیر بهتر است در یکی از حوزه‌های بک‌اند، فرانت‌اند، توسعه موبایل، داده یا زیرساخت تجربه عملی داشته باشید و چند قابلیت یا تغییر واقعی را از مرحله توسعه تا تحویل دنبال کرده باشید.
عنوان رسمی Mid-level یا Senior به‌تنهایی معیار مناسبی برای سنجش آمادگی ورود به این نقش نیست. مهم‌تر از عنوان شغلی این است که بتوانید درباره طراحی، تست، ریسک‌ها و پیامدهای تغییرات فنی قضاوت کنید و دلایل تصمیم‌های خود را برای دیگران توضیح دهید.
عمق فنی و همکاری میان حوزه‌ها
این مسیر شما را به یک زبان برنامه‌نویسی یا فناوری خاص محدود نمی‌کند. سرپرست فنی باید در حوزه اصلی فعالیت تیم خود عمق فنی کافی داشته باشد و همزمان بتواند با متخصصان حوزه‌های مرتبط درباره موضوعاتی مانند API، داده، تست، امنیت، استقرار، مشاهده‌پذیری و بدهی فنی گفت‌وگو کند.
البته این گستردگی به معنای مالکیت یا پیاده‌سازی شخصی همه بخش‌ها نیست. وظیفه اصلی سرپرست فنی این است که وابستگی‌های میان بخش‌های مختلف سیستم را درک کند، تصمیم‌های فنی را هماهنگ سازد و مطمئن شود مسائل مهم بدون مسئول مشخص باقی نمی‌مانند.
ارزیابی فرصت‌های شغلی و تفاوت عنوان‌ها
هنگام بررسی فرصت‌های شغلی، عنوان‌هایی مانند «رهبر فنی»، «تک لید» و Technical Lead را صرفاً براساس نام آن‌ها با یکدیگر مقایسه نکنید. شرح مسئولیت‌ها را به‌دقت بخوانید تا مشخص شود این نقش چه میزان اختیار در حوزه‌هایی مانند معماری، بازبینی کد، تحویل نرم‌افزار، عملیات و مدیریت افراد دارد.
همچنین، بررسی کنید تصمیم نهایی هر حوزه بر عهده چه کسی است و سرپرست فنی تا چه اندازه در تصمیم‌های محصولی و سازمانی مشارکت می‌کند. این بررسی کمک می‌کند فرصت‌هایی را انتخاب کنید که با تجربه، مهارت‌ها و مسیر حرفه‌ای موردنظر شما تناسب بیشتری دارند.
مخاطبان نقشه راه
این مسیر برای توسعه‌دهندگان میان‌رده یا ارشدی است که در یک حوزه فنی، تجربه تحویل نرم‌افزار دارند و می‌خواهند مسئولیت هدایت تصمیم‌های فنی یک تیم را بپذیرند. برای فردی که تازه برنامه‌نویسی را شروع کرده مناسب نیست و ابتدا باید در یک بخش فنی، تجربه عملی قابل اتکا بسازید.
دستاورد پایانی
در پایان مسیر می‌توانید یک مسئله محصول را به طراحی فنی و برنامه تحویل تبدیل کنید، ریسک‌های معماری و عملیاتی را توضیح دهید، بازبینی کد مؤثر انجام دهید، تصمیم‌ها را مستند کنید و توسعه‌دهندگان دیگر را بدون تبدیل‌شدن به گلوگاه راهنمایی کنید. این توانایی‌ها شما را برای پذیرش مسئولیت سرپرست فنی در یک تیم نرم‌افزاری آماده می‌کند، نه لزوماً مدیریت مستقیم افراد.
پیش‌نیازها
پیش از شروع، بهتر است با موارد زیر آشنا باشید.
- مهارت برنامه‌نویسی Programming
- مهارت برنامه‌نویسی شیءگرا Object-Oriented Programming
- مهارت الگوریتم و ساختمان داده Algorithms and Data Structures
- مهارت کنترل نسخه Version Control
- مهارت اشکال‌زدایی نرم‌افزار Software Debugging
- مهارت تست نرم‌افزار Software Testing
- مهارت ارتباطات فنی Technical Communication
- تجربه تحویل حداقل چند قابلیت واقعی در یک محصول یا پروژه نرم‌افزاری
- تسلط کاربردی به یک زبان و پشته فنی اصلی
- توانایی خواندن مستندات فنی انگلیسی
- آشنایی عملی با فرایند کار تیمی و درخواست ادغام
مسیر یادگیری شغل سرپرست فنی
-
۹۰ ساعت
تثبیت عمق فنی در یک حوزه توسعه
هدف گام: از توسعه‌دهنده‌ای که فقط وظیفه‌ها را انجام می‌دهد به فردی تبدیل شوید که علت انتخاب راهکار و پیامدهای آن را می‌فهمد.
سرپرست فنی نمی‌تواند همه فناوری‌ها را عمیق بداند، اما باید در پشته اصلی تیم خود مرجع قابل اتکایی باشد. یک حوزه اصلی مانند بک‌اند، فرانت‌اند، موبایل، داده یا زیرساخت را انتخاب کنید و در همان حوزه، کدنویسی قابل نگهداری، اشکال‌زدایی و تست را در سطحی فراتر از انجام وظیفه تمرین کنید.
روی خواندن پایگاه کدهای موجود کار کنید. پیش از تغییر هر بخش، جریان داده، قراردادهای وابسته و حالت‌های خطا را پیدا کنید. هدف این گام افزایش تعداد فناوری‌های رزومه نیست، بلکه ساختن قضاوت فنی در یک دامنه مشخص است.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
خواندن و تحلیل پایگاه کد موجودتفکیک مسئولیت در ماژول‌هامدیریت خطا و حالت‌های مرزینوشتن تست برای رفتارهای مهمتشخیص بدهی فنی در کدپروژه پیشنهادی: یک قابلیت نیمه‌تمام یا پرخطا را در یک پروژه موجود انتخاب کنید. پیش از تغییر، وابستگی‌ها و سناریوهای شکست را بنویسید؛ سپس قابلیت را همراه با تست و توضیح کوتاه تصمیم‌های فنی تکمیل کنید.
معیار پایان گام: می‌توانید برای یک تغییر متوسط، اجزای درگیر، ریسک‌ها، تست‌های لازم و دلیل انتخاب راهکار را پیش از کدنویسی توضیح دهید.
دوره پیشنهادی
-
۵۰ ساعت
ساختن عادت تحویل تیمی و کنترل نسخه
هدف گام: کار فنی را به تغییرهای کوچک، قابل بازبینی و قابل بازگشت تبدیل کنید.
سرپرست فنی باید جریان تحویل را درک کند، زیرا بسیاری از تأخیرها از کدنویسی ناشی نمی‌شوند. وابستگی پنهان، تغییر بزرگ و بدون تست یا درخواست ادغام مبهم معمولاً مسئله اصلی است. تغییرها را کوچک نگه دارید، پیام‌های ثبت تغییر معنادار بنویسید و برای هر درخواست ادغام، هدف، راه تست و ریسک را روشن کنید.
در تیم‌هایی که از GitLab یا GitHub استفاده می‌کنند، قواعد شاخه‌بندی و تأیید درخواست ادغام را با نیاز محصول هماهنگ کنید. فرایند نباید آن‌قدر سخت باشد که همه کارها به تأیید یک نفر وابسته شوند.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
طراحی تغییرهای کوچک و قابل بازگشتنوشتن شرح درخواست ادغامحل تعارض در کنترل نسخهتعریف معیار پذیرش تغییرمدیریت بازخورد در بازبینی کدپروژه پیشنهادی: برای پروژه گام قبل، قالب درخواست ادغام، قواعد نام‌گذاری شاخه‌ها و یک چک‌لیست بازبینی طراحی کنید. سه تغییر مستقل را با این قواعد ثبت و بازبینی کنید.
معیار پایان گام: می‌توانید یک درخواست ادغام را با توضیح هدف، اثر تغییر، روش تست و برنامه بازگشت ارائه کنید و بازخوردی مشخص و محترمانه بدهید.
دوره پیشنهادی
-
۵۵ ساعت
یادگیری بازبینی کد برای کاهش ریسک
هدف گام: بازبینی کد را از یافتن سلیقه‌های شخصی به ارزیابی درستی، طراحی، تست و پیامد عملیاتی تبدیل کنید.
بازبینی کد مسئولیت مشترک کیفیت است، نه ابزار کنترل فردی. ابتدا مسئله و معیار پذیرش را بخوانید، سپس درستی رفتار، مرزهای ماژول، پوشش تست، امنیت پایه و اثر تغییر بر سرویس‌های وابسته را بررسی کنید.
برای تغییرهای کم‌ریسک، بازخورد کوتاه و قابل اقدام بدهید. برای تغییرهای معماری یا داده‌ای، جلسه کوتاه طراحی برگزار کنید تا اختلاف در متن درخواست ادغام طولانی نشود. از خود بپرسید آیا این بازخورد واقعاً مانع خطا یا هزینه نگهداری می‌شود یا فقط ترجیح شخصی شماست.
مهارت‌ها
ابزارها
مفاهیم تکمیلی
تفکیک بازخورد ضروری از سلیقه کدنویسیارزیابی پوشش سناریوهای خطابررسی سازگاری با قراردادهای موجوداولویت‌بندی ایرادهای بازبینیمدیریت اختلاف‌نظر در بازبینیپروژه پیشنهادی: پنج درخواست ادغام متن‌باز یا تمرینی را بازبینی کنید. برای هرکدام، بازخوردها را به ضروری، پیشنهاد بهبود و پرسش دسته‌بندی کنید و برای دو مورد، سناریوی تست تکمیلی بنویسید.
معیار پایان گام: می‌توانید دلیل فنی هر بازخورد را توضیح دهید، راه اصلاح پیشنهاد کنید و بدون تمرکز بر جزئیات کم‌اهمیت، ریسک‌های اصلی را پیدا کنید.
-
۱۱۰ ساعت
طراحی سیستم و تصمیم‌گیری معماری
هدف گام: برای مسئله‌های محصول، راهکارهایی طراحی کنید که محدودیت مقیاس، داده، وابستگی و عملیات را آشکار کنند.
طراحی سیستم و معماری نرم‌افزار از انتخاب الگوی مشهور شروع نمی‌شود. ابتدا نیازهای کارکردی، حجم تقریبی استفاده، داده‌های حساس، نیازهای پایداری و محدودیت زمان تحویل را روشن کنید. سپس گزینه‌ها را با هزینه نگهداری و ریسک هرکدام مقایسه کنید.
روی مرزبندی ماژول‌ها، قرارداد API، مالکیت داده، مدیریت خطا و مشاهده‌پذیری تمرین کنید. ابزار و الگوی پیاده‌سازی را از پشته اصلی خود انتخاب کنید: ممکن است یک تیم بک‌اند به پایگاه داده، کش و کانتینر نیاز داشته باشد، در حالی که تیم فرانت‌اند یا موبایل بیشتر بر مرز کلاینت، قرارداد API، عملکرد و انتشار تمرکز می‌کند. در تیم‌های کوچک ممکن است راهکار ساده و یکپارچه بهتر باشد. در سامانه‌های دارای چند سرویس، جداسازی باید با دلیل عملیاتی و مالکیت روشن همراه شود. پیچیدگی زودهنگام، نشانه بلوغ معماری نیست.
مهارت‌ها
طراحی سیستم و معماری نرم‌افزارطراحی و توسعه APIسیستم‌های توزیع‌شدهپایش و مشاهده‌پذیری سامانه‌هامعماری امنیت نرمافزارمفاهیم تکمیلی
تبدیل نیاز محصول به محدودیت فنیمرزبندی ماژول‌ها و سرویس‌هاطراحی قراردادهای APIمالکیت و سازگاری دادهتحمل خطا و بازیابی سرویسثبت تصمیم معماریپروژه پیشنهادی: برای یک سامانه رزرو، فروش یا مدیریت سفارش، سند طراحی تهیه کنید که شامل نیازها، نمودار اجزا، قراردادهای اصلی، مدل داده، سه ریسک مهم و مقایسه دست‌کم دو راهکار باشد. یک بخش کلیدی آن را با ابزارهای متناسب با پشته اصلی خود پیاده‌سازی و ارزیابی کنید.
معیار پایان گام: می‌توانید یک تصمیم معماری را با نیازها، گزینه‌های ردشده، پیامدهای عملیاتی و برنامه کاهش ریسک مستند و برای تیم توضیح دهید.
-
۶۰ ساعت
برنامه‌ریزی تحویل و مدیریت ریسک فنی
هدف گام: کار بزرگ و مبهم را به بخش‌های قابل تحویل، قابل آزمون و قابل پیگیری تبدیل کنید.
سرپرست فنی زمان را به‌تنهایی تخمین نمی‌زند؛ با توسعه‌دهندگان، محصول و زیرساخت، ابهام‌ها و وابستگی‌ها را آشکار می‌کند. یک قابلیت بزرگ را به برش‌های ارزشمند تقسیم کنید تا نسخه اولیه زودتر قابل استفاده یا آزمایش باشد.
در Jira یا ابزار مشابه، کارهای فنی پنهان مانند مهاجرت داده، تست، پایش، مستندسازی و برنامه بازگشت را کنار کارهای ظاهری ثبت کنید. هنگام فشار زمانی، حذف آگاهانه دامنه محصول با تصمیم ثبت‌شده بهتر از حذف پنهانی تست یا کنترل‌های حیاتی است.
مهارت‌ها
برنامه‌ریزی تحویل فنی نرم‌افزارتعریف و مدیریت نیازمندی‌های محصولمدیریت بک‌لاگ محصولمدیریت ذی‌نفعانکاربست اصول و روش‌های چابکابزارها
مفاهیم تکمیلی
شکستن قابلیت به برش‌های قابل تحویلشناسایی وابستگی‌های بین‌تیمیثبت فرض‌ها و ابهام‌هامدیریت ریسک انتشارتعریف برنامه بازگشت تغییراولویت‌بندی بدهی فنیپروژه پیشنهادی: یک قابلیت فرضی مانند پرداخت، اعلان یا جست‌وجو را به بک‌لاگ فنی تبدیل کنید. وابستگی‌ها، ریسک‌ها، معیار پذیرش، برنامه انتشار مرحله‌ای و کارهای پس از انتشار را ثبت کنید.
معیار پایان گام: می‌توانید برای یک قابلیت بزرگ، دامنه نسخه نخست، وابستگی‌ها، ریسک‌های مهم و ترتیب تحویل را با ذی‌نفعان توافق و ثبت کنید.
-
۶۵ ساعت
پایش تولید و هدایت حل مسئله
هدف گام: در رخدادهای تولید، به جای واکنش پراکنده، تشخیص، کاهش اثر، بازیابی و یادگیری تیمی را هدایت کنید.
سرپرست فنی لازم نیست تنها فرد پاسخ‌گو به رخداد باشد، اما باید بداند کدام نشانه‌ها برای تشخیص مسئله مهم‌اند و چگونه تیم را حول یک مسیر بررسی هماهنگ کند. از سازوکارهای ثبت خطا، لاگ، سنجه و ردگیری موجود در پشته تیم استفاده کنید تا فرضیه‌ها با شواهد آزموده شوند.
نوع ابزار پایش به محیط وابسته است. در یک سرویس بک‌اند ممکن است داشبورد متریک و هشدار اهمیت بیشتری داشته باشد؛ در فرانت‌اند یا موبایل، خطاهای سمت کاربر، عملکرد انتشار و گزارش کرش می‌توانند نقطه شروع باشند. پس از رخداد، تحلیل را به سرزنش افراد تبدیل نکنید. خط زمانی، اثر بر کاربر، علت‌های فنی و فرایندی، اقدام اصلاحی و مالک هر اقدام را ثبت کنید. اگر تیم زیرساخت یا دواپس مستقل دارد، مرز مسئولیت و مسیر تشدید رخداد را از قبل روشن کنید.
مهارت‌ها
مفاهیم تکمیلی
تعریف شاخص‌های سلامت سرویستحلیل شواهد رخدادردگیری مسئله میان اجزاکاهش اثر رخدادتحلیل پس از رخداد بدون سرزنشتبدیل خطا به اقدام پیشگیرانهپروژه پیشنهادی: برای قابلیت پروژه خود، شاخص‌های سلامت و دو هشدار یا کنترل تشخیصی متناسب با پشته تیم تعریف کنید. سپس یک خرابی کنترل‌شده مانند کندی پاسخ، خطای انتشار یا اختلال وابستگی را شبیه‌سازی و گزارش رخداد شامل خط زمانی، علت و اقدام اصلاحی بنویسید.
معیار پایان گام: می‌توانید با اتکا به شواهد، اثر یک رخداد را محدود کنید، وضعیت را شفاف گزارش دهید و اقدام‌های پیشگیرانه قابل پیگیری تعریف کنید.
-
۵۵ ساعت
رشد دادن توسعه‌دهندگان و تسهیل تصمیم گروهی
هدف گام: دانش و مسئولیت فنی را در تیم توزیع کنید تا کیفیت به یک نفر وابسته نماند.
منتورینگ در نقش سرپرست فنی، پاسخ‌دادن به همه پرسش‌ها نیست. برای هر عضو، مسئله‌ای متناسب با سطح او انتخاب کنید، زمینه و معیار کیفیت را توضیح دهید و پس از انجام کار بازخورد مشخص بدهید. به جای بازنویسی فوری کد دیگران، پرسش‌هایی مطرح کنید که مسیر تحلیل را روشن کند.
جلسه‌های طراحی، مرور رخداد و انتقال دانش را با دستور جلسه و خروجی مشخص برگزار کنید. در اختلاف‌نظر فنی، مسئله، شواهد، محدودیت‌ها و تصمیم نهایی را ثبت کنید. هدف، اجماع مصنوعی نیست و هدف تصمیمی قابل اجرا با مسئولیت روشن است.
مهارت‌ها
منتورینگ فنی توسعه‌دهندگان نرم‌افزاررهبری فنی تیم نرم‌افزارتسهیل‌گری تیمحل تعارض در تیم‌های محصول و نرم‌افزارارتباطات فنیابزارها
مفاهیم تکمیلی
بازخورد فنی قابل اقدامواگذاری تدریجی مسئولیتطراحی جلسه فنی مؤثرثبت تصمیم و مالک اقداممدیریت اختلاف‌نظر فنیانتقال دانش درون تیمپروژه پیشنهادی: یک جلسه طراحی ۴۵ دقیقه‌ای برای مسئله پروژه برگزار کنید. پیش‌خواندنی، دستور جلسه، گزینه‌های تصمیم و صورت‌جلسه را آماده کنید. سپس یک توسعه‌دهنده کم‌تجربه‌تر را در تکمیل یک تغییر مشخص راهنمایی کنید.
معیار پایان گام: می‌توانید جلسه‌ای را به تصمیم و اقدام مشخص برسانید و به جای گرفتن کار از دیگران، رشد فنی آن‌ها را با بازخورد قابل اجرا تقویت کنید.
-
۹۵ ساعت
هدایت یک قابلیت از مسئله تا انتشار
هدف گام: همه مهارت‌های مسیر را در یک تجربه کامل و قابل ارائه از رهبری فنی ترکیب کنید.
یک قابلیت واقعی در پروژه شخصی، متن‌باز یا تیم فعلی انتخاب کنید که بیش از یک جزء داشته باشد. از تعریف مسئله و نیازمندی شروع کنید، طراحی را ثبت کنید، کار را میان چند تغییر قابل بازبینی تقسیم کنید و کیفیت، انتشار و پایش را در برنامه قرار دهید.
در این گام باید هم عمق فنی خود را نشان دهید و هم توانایی ایجاد شفافیت برای دیگران را. اگر در حوزه‌ای مانند داده، هوش مصنوعی، موبایل یا زیرساخت فعالیت می‌کنید، پروژه را در همان حوزه اجرا کنید. اصول رهبری فنی مشترک‌اند، اما تصمیم‌های معماری و عملیات باید با تخصص اصلی شما سازگار باشند.
مهارت‌ها
رهبری فنی تیم نرم‌افزارطراحی سیستم و معماری نرم‌افزاربرنامه‌ریزی تحویل فنی نرم‌افزاربازبینی کدمنتورینگ فنی توسعه‌دهندگان نرم‌افزارپایش و مشاهده‌پذیری سامانههاابزارها
مفاهیم تکمیلی
هدایت چرخه کامل تحویل قابلیتهماهنگی طراحی و اجراکنترل کیفیت پیش از انتشارثبت بدهی فنی و تصمیم‌هاپایش پس از انتشارمرور نتیجه و بهبود فرایندپروژه پیشنهادی: یک قابلیت چندبخشی را با سند نیازمندی، سند طراحی، بک‌لاگ، درخواست‌های ادغام، گزارش بازبینی، برنامه انتشار، شواهد پایش متناسب با پشته و گزارش پس از انتشار تحویل دهید. در صورت امکان، دست‌کم یک هم‌تیمی در اجرا یا بازبینی مشارکت کند.
معیار پایان گام: یک مجموعه مستند و قابل بررسی دارید که نشان می‌دهد قابلیت را از ابهام اولیه تا انتشار و پایش، با تصمیم‌ها و مسئولیت‌های روشن هدایت کرده‌اید.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما می‌تواند کمتر یا بیشتر باشد.
ابزارهای مسیر
در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.
خطاهای رایج مسیر
موارد زیر تصویری کلی از این بخش برای این مسیر ارائه می‌کنند.
-
تلاش برای تبدیل شدن به متخصص همه فناوری‌ها
یک حوزه فنی اصلی را عمیق نگه دارید و در حوزه‌های مجاور، توانایی گفت‌وگو و ارزیابی بسازید. سرپرست فنی باید برای تصمیم‌گیری شواهد جمع کند، نه اینکه شخصاً همه اجزا را پیاده‌سازی کند.
-
تأیید کردن همه درخواست‌های ادغام
قواعد بازبینی و سطح ریسک را شفاف کنید. تغییرهای عادی را میان اعضای تیم توزیع کنید و وقت خود را برای تغییرهای معماری، داده‌ای، امنیتی یا پرریسک نگه دارید.
-
جایگزین کردن منتورینگ با بازنویسی کد دیگران
به جای گرفتن کنترل کار، مسئله، معیار کیفیت و مسیر بررسی را توضیح دهید. بازخورد را به یک تغییر مشخص وصل کنید و فرصت اصلاح را به خود فرد بدهید.
-
انتخاب معماری پیچیده پیش از شناخت مسئله
پیش از انتخاب فناوری یا الگو، نیازها، محدودیت‌ها، حجم استفاده، مالکیت داده و هزینه عملیاتی را ثبت کنید. برای هر تصمیم مهم، دست‌کم یک گزینه ساده‌تر را نیز مقایسه کنید.
-
نادیده گرفتن کارهای فنی پنهان در برنامه تحویل
تست، مهاجرت داده، پایش، مستندسازی، امنیت و برنامه بازگشت را در بک‌لاگ ثبت کنید. حذف این کارها باید تصمیمی آگاهانه و موقت باشد، نه نتیجه فشار زمان.
-
گفتن «بستگی دارد» بدون روشن‌کردن معیار تصمیم
در گفت‌وگو با محصول و تیم، عامل‌های تصمیم را نام ببرید، مانند ریسک انتشار، محدودیت زمان، داده حساس، ظرفیت تیم و هزینه نگهداری. سپس توصیه خود و پیامد آن را شفاف بیان کنید.
-
مدیریت رخداد با سرزنش افراد
گزارش پس از رخداد را بر خط زمانی، شواهد، نقص کنترل‌ها و اقدام‌های اصلاحی متمرکز کنید. اقدام‌ها باید مالک و زمان پیگیری داشته باشند.
چک‌لیست آمادگی شغلی
چک‌لیست زیر کمک می‌کند هیچ نکته مهمی را از قلم نیندازید:
- می‌توانم یک مسئله محصول را به نیازهای فنی، ریسک‌ها و کارهای قابل تحویل تبدیل کنم.
- می‌توانم برای یک تغییر مهم، گزینه‌های طراحی و پیامدهای هر گزینه را مستند کنم.
- می‌توانم درخواست‌های ادغام را بر اساس ریسک، درستی، تست و نگهداری‌پذیری بازبینی کنم.
- می‌توانم بدون تبدیل‌شدن به گلوگاه، مسئولیت بازبینی و تصمیم‌گیری را در تیم توزیع کنم.
- می‌توانم در یک رخداد تولید، شواهد فنی را جمع کنم و مسیر کاهش اثر را هماهنگ سازم.
- می‌توانم تصمیم‌ها، قراردادها و دانش فنی را به شکلی قابل استفاده برای تیم ثبت کنم.
- می‌توانم به یک توسعه‌دهنده بازخورد فنی مشخص بدهم و مسئولیت را مرحله‌به‌مرحله واگذار کنم.
- می‌توانم محدودیت‌ها و ریسک‌های فنی را برای مدیر محصول و ذی‌نفعان غیر فنی توضیح دهم.
- یک نمونه مستند از هدایت یک قابلیت، از طراحی تا انتشار و پایش، دارم.
پرسش‌های پرتکرار
اگر درباره این مسیر پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
برای سرپرست فنی شدن باید چند سال برنامه‌نویسی کرده باشم؟
عدد ثابتی وجود ندارد، زیرا دامنه محصول و پیچیدگی تیم‌ها متفاوت است. معیار مهم‌تر این است که چند بار مسئولیت تحویل تغییرهای پیچیده را پذیرفته باشید، بتوانید درباره طراحی و ریسک قضاوت کنید و دیگران را در انجام کار توانمند سازید. صرف سابقه زمانی، بدون تجربه مسئولیت فنی، کافی نیست.
آیا باید بک‌اند، فرانت‌اند و دواپس را همزمان یاد بگیرم؟
خیر. ابتدا در یک حوزه اصلی عمیق شوید. سپس در حدی از حوزه‌های مجاور یاد بگیرید که بتوانید وابستگی‌ها، ریسک‌ها و زبان مشترک تیم را بفهمید. سرپرست فنی فرانت‌اند، بک‌اند یا موبایل ممکن است عمق تخصص متفاوتی داشته باشد.
آیا سرپرست فنی باید مدیر افراد هم باشد؟
نه لزوماً؛ تفاوت مسئولیت سرپرست فنی و مدیر افراد در صفحه شغل سرپرست فنی توضیح داده شده است.
برای تمرین رهبری فنی اگر تیم ندارم چه کار کنم؟
یک پروژه چندبخشی انتخاب کنید و خروجی‌های رهبری فنی را تولید کنید: سند طراحی، بک‌لاگ، درخواست ادغام، چک‌لیست بازبینی، برنامه انتشار و گزارش رخداد تمرینی. مشارکت در پروژه متن‌باز یا همکاری با یک یا دو توسعه‌دهنده نیز فرصت بهتری برای تمرین بازخورد و تصمیم گروهی ایجاد می‌کند.
آیا گواهینامه خاصی برای سرپرست فنی شدن لازم است؟
پیش از صرف زمان یا هزینه برای گواهینامه، شرح هر فرصت شغلی را بررسی کنید و از کارفرما درباره الزامات آن بپرسید. برای نشان‌دادن آمادگی، نمونه‌های قابل بررسی از طراحی فنی، تحویل قابلیت، بازبینی کد و همکاری تیمی معمولاً از گواهینامه به‌تنهایی گویاترند.
چه زمانی از توسعه‌دهنده ارشد به سرپرست فنی نزدیک شده‌ام؟
معیارهای تفاوت این دو نقش در صفحه شغل سرپرست فنی آمده است. در این مسیر، توانایی هدایت یک قابلیت کامل با تصمیم‌ها و مسئولیت‌های روشن را تمرین کنید.
