نقشهٔ راه تک‌لید: تمرین‌های قابل‌مشاهده برای توسعه‌دهندهٔ ارشد

رسیدن از «توسعه‌دهندهٔ ارشد» به «تک‌لید» با یادگرفتن یک ابزار جدید انجام نمی‌شود؛ مجموعه‌ای از رفتارها و عادت‌هاست که باید در عمل نشان داده شود. این مقاله بر پایهٔ سه چارچوب عمومی نقش tech lead (GitLab، GOV.UK و Redgate) و پژوهش re:Work دربارهٔ رفتارهای مدیران (خوانده‌شده ۱۹ اکتبر ۲۰۲۶) مهارت‌ها را در پنج حوزه می‌آورد و برای هر حوزه تمرین‌های قابل‌مشاهده پیشنهاد می‌دهد. تقسیم‌بندی، تمرین‌ها و ترتیب پیشنهاد نویسنده است و زمان قطعی ندارد. تعریف نقش در هر سازمان متفاوت است؛ پیش‌نیاز مهم گفتگو با مدیرتان دربارهٔ انتظارات است. برای تعریف نقش، مقالهٔ «تک‌لید کیست» در این سری را ببینید و برای ریسک و برنامه‌ریزی برنامه‌ریزی پروژه نرم‌افزاری را.

اول انتظار نقش را روشن کنید

GitLab می‌گوید tech lead نقشی موقت و مرتبط با پروژه است و مدیر نیست؛ Redgate مدیریت افراد را بخشی از نقش می‌داند. پس قبل از هر برنامهٔ رشد، با مدیر خود روشن کنید: در شرکت ما tech lead چه مسئولیت‌هایی دارد؟ چه تصمیم‌هایی با اوست؟ چطور موفقیتش سنجیده می‌شود؟ بدون این، ممکن است برای نقشی تمرین کنید که سازمان از شما نمی‌خواهد.

پنج حوزه

تصمیم فنی و معماری

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

برنامه‌ریزی و شکستن کار

GOV.UK می‌گوید بخش قابل‌توجهی از وقت tech lead صرف نوشتن کارت‌هاست: چه کاری، چرا، چه زمینه‌ای و گاهی معیار پذیرش. تیم باید بتواند هر کارت را بردارد و بداند دانش لازم را از کجا بیاورد. تمرین: یک کار بزرگ را به کارت‌هایی بشکنید که هر کدام مستقل و قابل بازبینی است، و از یک هم‌تیمی بخواهید یکی را بدون پرسش از شما انجام دهد؛ اگر نتوانست، کارت مبهم بوده است.

ریسک و تحویل

GitLab «مدیریت ریسک» را شناسایی، ارزیابی و مدیریت ریسک‌های فنی مؤثر بر تحویل می‌داند و Redgate از شناسایی زودهنگام ریسک و اعلام صادقانهٔ تغییرات پیش از از دست رفتن مهلت صحبت می‌کند. تمرین: برای پروژهٔ جاری فهرست ریسک بنویسید (احتمال تقریبی، اثر، اقدام، صاحب) و هر هفته مرورش کنید. معیار: حداقل یک ریسک را پیش از وقوع شناسایی و کاهش داده باشید و بتوانید نمونه نشان دهید.

رشد تیم و سلامت آن

GOV.UK به onboarding، گفتگوی منظم برای فهمیدن حال تیم و فراهم‌کردن فرصت‌ها اشاره می‌کند، و می‌گوید در جلسه‌ها باید به نقش هر نفر توجه کرد و به کسانی که راحت‌تر صحبت نمی‌کنند فرصت داد. Redgate رفتارهایی مثل «ایجاد امنیت روانی» و «واگذاری برای رشد و تحویل» را نام می‌برد. پژوهش re:Work هم مربی‌گری و توانمندسازی بدون micromanagement را از رفتارهای مدیران مؤثر می‌داند. تمرین: برای هر عضو یک هدف یادگیری بپرسید و یک کار مناسب به او بسپارید که کمی فراتر از راحتی‌اش باشد، با حمایت کافی؛ بعد نتیجه را با او بررسی کنید. معیار: عضو بتواند بگوید از این کار چه آموخت.

ارتباط با ذی‌نفعان

Redgate تأکید می‌کند tech lead باید تیم را برای ذی‌نفعان نمایندگی کند و زمینه را به تیم برگرداند، و سطح جزئیات را با مخاطب تنظیم کند. تمرین: گزارش وضعیت دو پاراگرافی برای مدیر محصول بنویسید: چه شد، چه ریسکی داریم، به چه کمکی نیاز داریم. معیار: خواننده بدون پرسش اضافی بتواند تصمیم بگیرد.

تعادل بین کدنویسی و رهبری

Redgate این را «Balances Leading and Building» می‌نامد: آن‌قدر درگیر کار فنی بمانید که اعتبار فنی داشته باشید، ولی گلوگاه تحویل نشوید. GOV.UK هم می‌گوید لازم نیست بر همه چیز نظارت کند. تمرین: هر ماه بررسی کنید آیا کار تیم منتظر کد یا بازبینی شماست یا نه، و اگر هست، کار را واگذار یا بازبینی را تقسیم کنید.

مثال ساختگی از یک برنامهٔ سه‌ماهه

توسعه‌دهندهٔ ارشد فرضی با مدیرش انتظار نقش را می‌نویسد. ماه اول: سند تصمیم فنی و شکستن یک کار بزرگ. ماه دوم: فهرست ریسک و برنامهٔ onboarding برای عضو جدید. ماه سوم: گزارش وضعیت منظم و واگذاری بازبینی. در پایان با مدیر دربارهٔ مثال‌های عینی هر مورد گفتگو می‌کند. مثال ساختگی است و زمان‌بندی توصیه نیست.

اشتباهات رایج

• شروع بدون روشن‌کردن انتظار نقش.
• تلاش برای حفظ همهٔ مسئولیت‌های کدنویسی قبلی.
• تصمیم‌گیری بدون ثبت دلیل.
• مدیریت افراد با micromanagement.
• گزارش بدون ریسک و بدون درخواست مشخص.
• خود را گلوگاه کردن.

ثبت شواهد برای گفتگوی رشد

نقش tech lead را معمولاً با شواهد عینی تأیید می‌کنند، نه با ادعا. Redgate در توصیف بسیاری از رفتارها از عبارت «می‌تواند به یک نمونهٔ مشخص اشاره کند» استفاده می‌کند؛ مثلاً در مورد رسیدن به تصمیم پس از اختلاف، یا حذف کار کم‌ارزش با ذکر دلیل. این الگو برای شما هم مفید است: یک فایل ساده نگه دارید و هر ماه چند نمونهٔ عینی ثبت کنید. هر نمونه سه چیز داشته باشد: چه وضعیتی بود، چه کاری کردید و چه نتیجه‌ای گرفتید. نمونه می‌تواند شکست هم باشد؛ آنچه آموخته‌اید ارزشمند است.

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

در نهایت، از مدیر و هم‌تیمی‌ها بازخورد مستقیم بخواهید و آن را بدون دفاع بشنوید. پژوهش re:Work ارتباط مؤثر و مربی‌گری را از رفتارهای مدیران مؤثر می‌شمارد؛ بازخورد گرفتن و نشان‌دادن اینکه بر اساس آن عمل می‌کنید، خودش تمرین همین رفتارهاست. این‌ها توصیهٔ نویسنده است و تضمین ارتقا یا نتیجهٔ مشخصی ندارد.

چک‌لیست

1. انتظار نقش با مدیر مکتوب و روشن شده است.
2. یک سند تصمیم فنی با گزینه‌ها و دلیل نوشته شده است.
3. کارها به کارت‌های مستقل شکسته می‌شود.
4. فهرست ریسک با صاحب و اقدام مرور می‌شود.
5. برای هر عضو هدف رشد و کار مناسب مشخص است.
6. تیم به شما برای تصمیم و بازبینی گلوگاه نیست.

منابع و مراجع

• Tech Lead at GitLab — The GitLab Handbook، 2026-10-19.
• Responsibilities of a Tech Lead — GOV.UK Developer Documentation، 2026-10-19.
• Tech Lead — Redgate Progression Framework — Redgate، 2026-10-19.
• Following the data: The research behind great managers — Google re:Work، 2026-10-19.