بستر بهره‌وری دولوپر

بهره‌وری تیم توسعه یک فرمول جادویی نیست. مت استافر می‌گوید خروجی وقتی می‌آید که آدم درست را در جای سالم بگذاری و ابزار و فرایند را به دستش بدهی. برای همین ویدیوی فرهنگ اول آمد: از آدم غلط، محیط ناسالم، یا تیمی که ارزش‌ها و هدف را نمی‌فهمد، نمی‌شود انتظار Productivity داشت. وقتی آن‌ها را داری، تازه نوبت بستر کار است.

چرا رهبری کلید است

رهبری سازمان سقف بهره‌وری را تعریف می‌کند. کار اول لیدر، استخدام آدم خوب است — همان چیزی که درس‌های آدم‌ها و فرهنگ رویش ایستاده‌اند. کار دوم، بعد از اینکه آدم خوب را پیدا کردی: **اعتماد**.

لیدر ترسیده پیش‌فرضش کنترل است. در همه‌چیز دخالت می‌کند، همه‌چیز را اندازه می‌گیرد، و انرژی‌اش را می‌گذارد روی Cover Your Ass. جملهٔ ناگفته‌اش این است: «باید مطمئن شوم بد نیستند.» اگر به‌جایش بگویی «این‌ها آدم‌های خوبی‌اند و کار خوب می‌کنند»، انرژی‌ات می‌رود روی یک سؤال مفیدتر: چطور کار خوب را برایشان آسان‌تر کنم؟

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

رهبری بد متریک می‌فروشد؛ رهبری خوب خروجی می‌خواهد

رهبری بد دنبال عدد است: چند Commit؟ چند خط کد؟ چقدر از فلان قانون سخت‌گیرانه پیروی کردی؟ رهبری خوب دنبال خروجی واقعاً ارزشمند است — و هم‌زمان مراقب آدم‌هاست.

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

One-on-one و Slack: جایی که آسیب را می‌شنوی

لیدر خوب از چیزهایی که اصلاً نمی‌دانست باخبر می‌شود — عمدتاً از One-on-one. سؤال‌های درست این‌هاست: چه چیزی ممکن است بهره‌وری را بزند؟ چطور بردارمش؟ چه حمایتی ظرفیت و شادی تو را بالا می‌برد؟

اگر در One-on-one خوب گوش بدهی — یا در Slack خوب نگاه کنی — کوهی از آسیب را پیدا می‌کنی که می‌توانی در برطرف کردنشان شریک شوی. دولوپرها معمولاً از چیزهایی که کارشان را مختل می‌کند به‌شدت عصبانی‌اند. مت کمتر دولوپری دیده که بخواهد سر کار بیاید و هیچ کار نکند. می‌خواهند کارشان محترم باشد، به‌عنوان متخصص دیده شوند، و فضا داشته باشند کار کنند. وقتی این‌ها نیست، خودشان می‌گویند: فقط می‌خواهم کار خوبی بکنم که به مشتری برسد، و به‌خاطر X و Y و Z نمی‌توانم. عالی — حالا یک مانع داری که باید با آن بجنگی.

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

نمونهٔ دستور جلسه — کوتاه، قابل تکرار، ضد Status Report:

# One-on-one — ۲۰ تا ۳۰ دقیقه
(هفتگی یا دو هفته یک‌بار)

## ۱. انسان (۳–۵ دقیقه)
- این هفته انرژی‌ات چطور بود؟ خواب، خانواده، بیرون از کار.
- چیزی هست که بخواهم از تقویمت بردارم؟

## ۲. اصطکاک بهره‌وری (۱۰ دقیقه)
- این هفته چه چیزی جلوی «نشستن و انجام کار» را گرفت؟
- جلسه، ایمیل، Timesheet، گزارش، ساعت اجباری؟
- یک مانع که من تا جلسهٔ بعد بتوانم حذف کنم؟

## ۳. فضا و اعتماد (۵ دقیقه)
- جایی هست که حس کنی کنترل می‌شوی نه حمایت؟
- روی چه کاری می‌خواهی Flow کنی و چه چیزی قطعش می‌کند؟

## ۴. رشد (۵ دقیقه)
- چه چیزی می‌خواهی یاد بگیری؟ چه کمکی از من می‌خواهی؟

## بستن
- یک Action برای من، یک Action برای تو.
- جلسهٔ بعد همان را چک می‌کنیم — نه تعداد Commit.

دو شرط استخدام برای بهره‌وری

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

1. کسی را استخدام کن که نشان داده می‌تواند یاد بگیرد و خودش را آموزش دهد. منتظر نمی‌ماند کسی بغلش را بگیرد؛ رشد را خودش جلو می‌برد. 2. کسی را استخدام کن که بتوانی به او اعتماد کنی. تست ذهنی: کار را می‌سپاری، ناپدید می‌شوی، او می‌تواند ول کند — و تو می‌دانی که وقتی برگردی کار انجام شده است.

بعد همین آدم‌ها را در محیطی بگذار که هم یاد بگیرند هم مورد اعتماد باشند: یادگیرنده را کمک کن یاد بگیرد، آدم قابل‌اعتماد را واقعاً اعتماد کن. دیگر لازم نیست تمام روز نگران دانش و قابلیت‌اطمینان‌شان باشی. خودشان Powerhouse می‌شوند و انرژی لیدر آزاد می‌شود.

آسیب‌های رایج: هر چیزی غیر از نشستن و کار کردن

One-on-one جای آسیب‌های خاص تیم توست. ولی چند آسیب تقریباً همه‌جا تکرار می‌شود.

**ساعت اجباری که به زندگی نمی‌خورد.** بهره‌وری روی تقویم شرکت رخ نمی‌دهد؛ روی زندگی آدم رخ می‌دهد. اگر هر روز ساعت ۳ باید بچه را از School Bus برداری و می‌توانی همان یک ساعت را شب جبران کنی، شغل منعطف یعنی بدون استرس ناپدید می‌شوی و با شکرگزاری برمی‌گردی. مجبور کردن به میز در آن ساعت، استرس خانواده می‌سازد نه خروجی.

**جلسه.** جلسه بهره‌وری را می‌زند. تا می‌توانی حذفش کن.

**هر چیزی که کار اصلی نیست:** Timesheet، گزارش کار، ایمیل. در ادامهٔ دوره باز هم از این‌ها حرف می‌زنیم. اصل ساده است: آدم را آماده و بدون حواس‌پرتی بنشان و بگو همان کاری را بکن که برایش استخدام شده. هر چیز بیرون از این، ضرر بهره‌وری است و باید حداقل شود.

چهار کار برای وقتی که می‌نشینند کد بزنند

فرض کن محیط انسانی درست است. حالا وقتی دولوپر می‌نشیند پشت میز، چقدر طول می‌کشد تا کد باکیفیت بیرون بدهد؟ چقدر وقت بالای هر پروژه، هر Pull Request، هر Review، هر برنامه‌ریزی هدر می‌رود؟ چهار قدم ساده این اصطکاک را کم می‌کند.

ویدیوهای بعدی فرایند تسک و تکنولوژی Tighten را باز می‌کنند. اینجا فقط مزه است — ولی برای بهره‌وری همین مزه واجب است.

**۱. روی تکنولوژی خساست نکن.** لپ‌تاپ، کیبورد، مانیتور، صندلی، IDE، ابزار SQL — هرچه برای کار لازم است. این‌ها چکش و ارّه و متر نجارند. ابزار خوب به‌تنهایی دولوپر خوب نمی‌سازد؛ ولی از دولوپر خوب، بدون ابزار درست، حداکثر بهره‌وری نمی‌گیری. لازم نیست همیشه جدیدترین مدل؛ لازم هم نیست همه‌چیز رایگان باشد.

**۲. Clone و Run در حد دقیقه.** راهنمای شفاف: ماشین جدید، کلون ریپو، بالا آمدن پروژه — در چند دقیقه، نه چند روز.

**۳. فرایند واضح.** Checkout، Branch، ساخت و Reviewِ Pull Request — هرچه روشن‌تر، هر بار اصطکاک کمتر.

**۴. تعریف «کد خوب».** همه باید سریع بفهمند حداقل استاندارد چیست. احتمال نوشتن کد خوب بالا می‌رود، وقت Review خود و دیگران پایین می‌آید، و **bikeshedding** تقریباً می‌میرد: وقت تلف‌کردن سر «بهترین راه» به‌جای انجام خودِ کار.

چک‌لیست ماشین جدید — همان مورد ۲ را عملی می‌کند:

# New machine setup
هدف: از جعبه تا `clone` و Run، در حد دقیقه نه روز.

## سخت‌افزار (خساست ممنوع)
- [ ] لپ‌تاپ با RAM/CPU کافی برای IDE + مرورگر + کانتینر
- [ ] مانیتور خارجی
- [ ] کیبورد و ماوس راحت
- [ ] صندلی قابل تنظیم — کمرت ابزار کار است

## ابزار روزانه
- [ ] IDE مورد علاقه (PhpStorm / VS Code / …)
- [ ] ابزار SQL (TablePlus / Sequel Ace / …)
- [ ] Git + SSH key + دسترسی GitHub
- [ ] دسترسی Slack و تقویم تیم

## ریپو باید در چند دقیقه بالا بیاید
- [ ] README با دستور واحد: `make up` یا `./bin/setup`
- [ ] `.env.example` کامل؛ بدون مقدار جادویی در ذهن فلان ارشد
- [ ] `composer install` / `npm install` / migrate / seed
- [ ] تست دود: صفحهٔ لوکال باز شود، لاگین نمونه کار کند
- [ ] دسترسی Staging و لاگ — نه فقط لوکال

## روز اول تمام است اگر
- [ ] یک تست را سبز دیده‌ای
- [ ] یک Pull Request نمونه را خوانده‌ای
- [ ] می‌دانی Branch را از کجا می‌سازی و Review را برای که می‌فرستی

هستهٔ این درس

بقیهٔ دوره ابزار و فرایند را دانه به دانه می‌آورد. این ویدیو مهم‌ترین تکه را گفت: آدم خوب، قابل‌اعتماد، و رشدکرده پیدا کن؛ بعد به‌جای اینکه تمام انرژی‌ات را بگذاری مطمئن شوی «کارشان را می‌کنند»، منابع رشد بده و بگذار آدم خوب بودنشان را خرج کنند. انرژی لیدر می‌رود روی ساختن فرصت‌هایی که همان کار خوب را بیشتر و بهتر کنند — نه روی اندازه‌گیری ترس.

به زبان ساده

آدم درست را استخدام کن، اعتماد کن، اصطکاک را بردار. میکرومدیریت یعنی رهبری ترسیده.

مثال واقعی

اگر ساعت ۳ باید بچه را از سرویس برداری، برو و شب یک ساعت جبران کن. جلسه و تایم‌شیت و ایمیل دشمن Flow هستند. ماشین نو باید در چند دقیقه clone و اجرا شود.