آدم درست را — روی کاغذ — بلدی پیدا کنی. حالا هر کس را کجا می‌گذاری و چه کسی مسئول چیست؟ وسوسه این است که ساختار را دشمن خلاقیت بدانی. ممکن است زیاده‌روی به بوروکراسی برسد؛ ولی تعریف یک سلسله‌مراتب، یا حداقل قواعد و انتظارها در تیم فلت، استرس و تعارض را کم می‌کند: همه می‌دانند چه کاره‌اند و به که گزارش می‌دهند. مسیر رشد هم معلوم می‌شود — بعد از این نقش، کجا می‌روند؟
اول شکل ایده‌آل را بکش، نه تیم فعلی را
اولین کار: چیدمان ایده‌آل تیم توسعه را روی کاغذ بیاور. چه کسی به چه کسی وصل است؟ چه کسی در کدام تیم است؟ چه کسی به که گزارش می‌دهد؟ این تمرین دربارهٔ تیم فعلی نیست. برای سازمانی که داری، چه ساختاری معنی می‌دهد؟
روی این نقشه باید روشن باشد:
- چه کسی به که گزارش می‌دهد
- مرز یک شغل با شغل دیگر، و یک تیم با تیم دیگر چیست
- **سلسله‌مراتب کلی** چیست و **سلسله‌مراتب زمینه‌ای** چیست
مثال سلسله‌مراتب کلی: Director of Engineering با همهٔ دولوپرها One-on-one می‌گذارد؛ یعنی همه Direct Report او هستند. مثال سلسله‌مراتب زمینه‌ای: یک Lead فقط روی همان پروژه Lead است. روی آدم‌های دیگر «رئیس دائمی» نیست؛ در آن Context هست.
و صریح بنویس تیم‌ها **full-stack**اند یا Front-end از Back-end جداست. بدون این تصمیم، بقیهٔ نقشه در هواست.
شکلی که در Tighten کار می‌کند
مت می‌گوید معلم است، پس باید بگوید چه چیزی را بکشی — دست‌کم برای تیم‌های full-stack لاراول، و با تجربهٔ Tighten و تیم‌هایی که Tighten کمک کرده ساخته شوند.
شکل: **یک CTO یا Director of Engineering** بالای سازمان، بعد حدود **سه تا پنج تیم کوچک**، هر کدام **دو تا سه** دولوپر full-stack. در هر تیم یک Lead یا Senior. همه کد می‌نویسند و همه Review می‌کنند — هر سه نفر پروژه، هم نویسنده هم Reviewer.
Lead بیشتر معمار است و نقطهٔ رجوع سؤال فنی. همچنین ارتباط‌گر اصلی با Project Manager یا Product Owner یا Account Owner — همان لید غیر فنی. اگر مشتری در کار باشد، مکالمه با مشتری را هم او جلو می‌برد.
فیچر — یا دسته فیچر — به **یک تیم** می‌رسد. Project Manager با technical lead کار را خرد می‌کنند: چه کارهایی هست، چطور تقسیم شود. بعد برنامه‌نویس‌ها می‌نشینند؛ گاهی Pair، گاهی Solo. هر کس کد می‌نویسد و کد دیگری را Review می‌کند. در نهایت **buck stops here** کیفیت فنی همان پروژه با Lead است. ولی همیشه یک آدم از جنس CTO بالای سرش هست: «یک نگاه به این بینداز» یا چک‌این منظم.
گرانش اندازه: ۳، ۱۲، ۵۰، ۲۰۰
Tighten می‌توانست خیلی بزرگ‌تر شود — یک بار هم شد. نقطه‌ای که این شکل دیگر معنی نداد، نقطه‌ای بود که مت از آن متنفر شد. از کار قبلی‌اش با سازمان‌های غیرانتفاعی یاد گرفته بود فرهنگ در سقف‌های اندازه عوض می‌شود. عددها نزد همه یکی نیست، ولی اغلب از **۳ و ۱۲ و ۵۰ و ۲۰۰** حرف می‌زنند. تا یک سقف، همه‌چیز جور است؛ بالای آن باید سیستم عوض شود. بین سقف‌ها هم گرانش هست: برای ۱۲ خیلی بزرگی و برای ۵۰ خیلی کوچک — پس فشار می‌آید بپری به اندازهٔ بعدی.
اگر روزی تیم بزرگ‌تری لازم باشد، مت همان واحد را تکثیر می‌کند: سه تا پنج تیمِ دو-سه‌نفره، چند بار. یک تودهٔ دوازده‌نفره نمی‌سازد.
دو لیدر در هر تیم: technical lead و process lead
هر تیم حداقل دو نوع لیدر می‌خواهد. می‌توانند یک نفر باشند؛ در Tighten جدا هستند.
**technical lead** تصمیم معماری می‌گیرد، اگر مسئلهٔ Style پیش بیاید او می‌بُرد، جهت فنی را تعیین می‌کند، و از سمت فنی در Planning شرکت می‌کند. لازم نیست لیدر روابط عمومی باشد. رشد آدم‌های تیم برایش ارزشمند است، ولی شغلش تعامل با محصول و بیزنس و مشتری نیست. جهت کد و معماری است. Review می‌کند — البته مت معتقد است همه باید Review کنند. تعاملی‌ترین کارش بیرون از تیم داخلی، حضور در Planning با مشتری یا محصول است، از زاویهٔ فنی.
**process lead** در Tighten همان Project Manager است: جلسه، Burndown، تایم‌لاین، کارِ «کار را پیش بردن». خط اول ارتباط با مشتری را هم او می‌گیرد و جلسه‌های مشتری را جلو می‌برد. مت دوست دارد این نقش کمی UX بلد باشد — دیاگرام و Wireframe سبک. اگر UX سنگین لازم شد، طراح حرفه‌ای می‌آورند. فرایند داخلی هم با اوست: چک‌این، تایم‌لاین، ثبت کار.
و یک لایه بالاتر، مخصوص پروژه نیست ولی چون حرف رهبری است باید گفته شود: **بالاترین لیدر فنی سازمان باید فنی باشد و قدرت / Agency داشته باشد.** باید بفهمد Tech Debt چیست، و بتواند برای توقف موقت توسعهٔ محصول بجنگد. اگر Director یا VP of Engineering یا CTO روزمره با تیم نیست ولی سلسله به او می‌رسد، و یا حرف بدهی را نمی‌فهمد یا می‌فهمد و در برابر بقیهٔ مدیران ارشد زورش نمی‌رسد، کارش را نمی‌تواند بکند.
| کار | technical lead | process lead | دولوپر تیم | Director of Engineering |
|---|---|---|---|---|
| معماری فیچر | A | I | C | C |
| خرد کردن تسک با PM | C | A | C | I |
| نوشتن کد | C | I | R | I |
| Code Review | A / R | I | R | C |
| جلسه و Burndown | I | A | C | I |
| خط اول مشتری | C | A | I | I |
| Wireframe سبک | C | R | I | I |
| کیفیت نهایی تحویل | A | C | R | C |
| جنگ برای Tech Debt | C | I | C | A |
R = انجام می‌دهد، A = پاسخگو است (buck stops here)، C = مشورت، I = مطلع. در Tighten کیفیت فنی پروژه با Lead است؛ CTO در دسترس می‌ماند.
چرا full-stack و چرا کوچک و چرا حداکثر یک junior
شکل‌های دیگر وجود دارند. مت این را ترجیح می‌دهد و دلیل دارد؛ تو می‌توانی چیز دیگری انتخاب کنی اگر برای سازمانت معنی بدهد.
**full-stack به‌جای جدا کردن Front-end و Back-end.** حتی تیمی که یک Front-end و یک Back-end دارد بهتر از دو سیلو جداست — ولی باز هم هر فیچر و هر باگ باید از مرز رد شود. فرایند اضافه، رفت‌وبرگشت، Cycle طولانی‌تر، زمان تا Production بیشتر. اگر همه full-stack باشند، تعریف فیچر می‌آید، دو طرف را می‌سازند، می‌رود QA و Production — در حد **روز**. با تیم جدا، همان فرایند دو بار طی می‌شود و روزها به **هفته** تبدیل می‌شود. این اصطکاک را روی هر فیچر ضرب کن.
**تیم کوچک به‌جای تیم بزرگ.** در تیم کوچک کسی قایم نمی‌شود. شغلت را می‌دانی، Buddyات را می‌شناسی، با او Partner می‌شوی. در تیم بزرگ گوشه‌هایی ساخته می‌شود که کار پیش نمی‌رود، یا کسی پشت «آن سه نفر کار را می‌کنند» قایم می‌شود که بلد نیست. هرچه تیم بزرگ‌تر و بی‌ساختارتر، بیشتر شبیه **mob دوازده‌نفره**: همه یک کار می‌کنند، Assignment فردی دارند، ولی معلوم نیست چه کسی کد که را Review می‌کند، کدام تکه مال کیست، با که Pair کنی. در تیم کوچک نقش هر کس در هر لحظه روشن است.
**حداکثر یک junior روی پروژه؛ حداکثر یک junior به ازای دو برنامه‌نویس.** Junior کمی ظرفیت اضافه می‌کند، ولی از ظرفیت Senior برمی‌دارد. چهار Junior کنار یک Senior برابر سه دولوپر اضافه نیست؛ برابر چهار نفر کار ضعیف است به‌علاوهٔ Seniorای که تقریباً تمام‌وقت پرستاری می‌کند. مت برنامهٔ کارآموزی را دوست دارد و برای Pipeline نسل بعد حیاتی می‌داند. اشتباه بزرگ این است که برای صرفه‌جویی، انبوه Junior روی یک Senior یا پنج Senior و بیست Junior بریزی.
از صفر، یا با تیم موجود
نقشهٔ ایده‌آل را کشیدی. دو حالت داری.
**از صفر.** اول فنی‌ترین آدم را استخدام کن: CTO یا Senior فنی. فرهنگ، جهت فنی، و استاندارد را او می‌سازد. راه فرار موقت: نقش را با Tighten یا پیمانکار Senior پر کن تا سطح پایین‌تر را استخدام کنی — ولی junior نگیر تا حداقل **یک تیم توسعهٔ کاملِ در حال کار** داشته باشی. حتی اگر Tighten را آوردی، Senior داخلی را زودتر بیاور نه دیرتر.
**تیم موجود.** اول گفتیم تیم فعلی را نادیده بگیر؛ آن تجمل تمام شد. آدم را فقط به‌خاطر Seniority یا مهارت فنی به رهبری هل نده. ببین چقدر به شکل ایده‌آل می‌خورند. اگر نمی‌خورند، موقتاً جایشان را جور کن — برای این آدم، برای حالا — و برنامه بگذار به جایی برسند که باید باشند. ممکن است برای همه کار نکند. ممکن است دولوپر کم‌کار زیاد داشته باشی. موقعیت ناجوری است و مت امیدوار است این دوره به اخراج آدم‌ها منجر نشود؛ ولی ساختار باید برای سازمان کار کند. هرجا شد، از داخل Promote کن نه اینکه لیدر غریبه از بیرون بیاوری. آدم داخلی نحوهٔ کارت را می‌فهمد، و بقیه می‌بینند ورود در سطح پایین بن‌بست نیست.
نیاز امروز نیاز پنج سال بعد نیست. سیستم می‌تواند با تیم، با نیاز، و با فهم تو از شکل ایده‌آل عوض شود. چابک بمان، منعطف بمان، و همین سؤال را تکرار کن: شکل ایده‌آل تیم ما امروز چیست؟
به زبان ساده
تیم ایده‌آل را روی کاغذ بکش: چند تیم کوچک فول‌استک، هر کدام لید فنی و لید فرایند، حداکثر یک جونیور.
مثال واقعی
شکل Tighten: یک Director of Engineering و سه تا پنج تیم دو-سه‌نفره. وقتی از این اندازه رد شدند، فرهنگ به‌هم ریخت؛ اگر بزرگ‌تر شوند همین واحد را تکرار می‌کنند نه یک تیم ۱۲ نفره.