منتورینگ (Mentoring)

مشکل: دو راه اشتباه

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

رضا می‌تواند دو اشتباه رایج بکند:

1. رها کردن. «هر سؤالی داشتی بپرس.» بعد سرش با کار خودش گرم می‌شود. امید خجالت می‌کشد که مدام بپرسد. سه روز روی خطایی گیر می‌کند که جوابش پنج دقیقه بود.
2. انجام دادن به جای او. هر بار که امید گیر می‌کند، رضا صفحه کلید را می‌گیرد و مشکل را حل می‌کند. کار سریع جلو می‌رود. ولی سه ماه بعد امید هنوز بدون رضا نمی‌تواند کار کند.

در هر دو حالت، تیم یک برنامه‌نویس مستقل به دست نمی‌آورد. در حالت دوم، رضا هم خسته می‌شود، چون همه سؤال‌ها به او می‌رسد.

منتور چه کاری می‌کند؟

هدف منتور یک جمله است: امید باید روزی بدون من هم بتواند کار کند. هر کاری که منتور می‌کند، باید به این هدف کمک کند.

منتور خوب بین معلم و کوچ جابه‌جا می‌شود. برای یک ابزار کاملاً تازه، معلم است. برای مشکلی که امید می‌تواند خودش حل کند، کوچ است.

هفته اول: زمین را آماده کن

بیشتر آدم‌ها در هفته اول قضاوت می‌کنند که تیم چقدر کمک‌کننده است. یک چک‌لیست ساده:

1. روز اول، پروژه روی سیستمش اجرا شود. اگر این کار یک روز کامل طول می‌کشد، مشکل از مستندات تیم است، نه از امید. هر جا گیر کرد، از او بخواه مستند را درست کند.
2. هفته اول، یک تغییر کوچک تا Production برود. مثلاً اصلاح یک متن یا یک باگ کوچک. امید کل مسیر را یک بار می‌بیند: شاخه، Pull Request، بازبینی، CI و استقرار.
3. یک نقشه کلی بده. سرویس‌های اصلی فروشگاه کدام‌اند؟ داده سفارش کجا است؟ یک تصویر روی تخته از صد صفحه مستند بهتر است.
4. بگو چه کسی چه چیزی را می‌داند. «سؤال پرداخت را از مینا بپرس.» این‌طوری همه سؤال‌ها به تو نمی‌رسد.
5. یک قرار ثابت بگذار. مثلاً هر روز ده دقیقه در هفته اول. سؤال‌ها جمع می‌شوند و امید حس نمی‌کند مزاحم است.

پله‌های کمک

کمک نباید همیشه یک اندازه باشد. با پیشرفت امید، کمک کمتر می‌شود.

1. من انجام می‌دهم، تو نگاه کن. رضا اولین endpoint را می‌سازد و بلند فکر می‌کند. «اول تست را می‌نویسم، چون …»
2. با هم انجام می‌دهیم. برنامه‌نویسی دونفره (Pair Programming). صفحه کلید دست امید است. رضا مسیر را نگاه می‌کند و سؤال می‌پرسد. به این دو نقش راننده (Driver) و راهنما (Navigator) می‌گویند.
3. تو انجام بده، من نگاه می‌کنم. امید endpoint بعدی را خودش می‌سازد. رضا فقط در بازبینی کد نظر می‌دهد.
4. تو تنها. امید کار را خودش برمی‌دارد و انجام می‌دهد. حتی می‌تواند به نفر تازه بعدی کمک کند.

سؤال به جای جواب

امید می‌گوید: «تست شکست می‌خورد.» ساده‌ترین کار این است که جواب را بگویی. ولی این کار یک هزینه پنهان دارد.

چند سؤال که تقریباً همیشه کمک می‌کنند:

1. «پیام خطا دقیقاً چه می‌گوید؟» خیلی وقت‌ها جواب در خود پیام است، ولی کسی آن را کامل نخوانده است.
2. «تا الان چه چیزهایی را امتحان کردی؟» این نشان می‌دهد امید چطور فکر می‌کند.
3. «انتظار داشتی چه اتفاقی بیفتد؟» فرق انتظار و واقعیت، جای مشکل را نشان می‌دهد.
4. «کوچک‌ترین کدی که این مشکل را نشان می‌دهد چیست؟» این یک مهارت مهم اشکال‌زدایی است.
5. «اگر من نبودم، کجا را نگاه می‌کردی؟» این سؤال استقلال را تمرین می‌دهد.

یک قانون هم برای امید بگذار: «اول خودت تلاش کن. اگر بعد از مثلاً سی دقیقه پیشرفت نکردی، حتماً بپرس.» این قانون هر دو اشتباه را حل می‌کند: هم گیر کردن طولانی، هم پرسیدن بدون فکر.

کار مناسب: کمی سخت‌تر

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

در فروشگاه، مسیر امید می‌تواند این باشد:

1. ماه اول. لیست علاقه‌مندی‌ها: یک ویژگی کامل ولی ساده، با دیتابیس و API.
2. ماه دوم. فرستادن ایمیل وقتی کالای لیست علاقه‌مندی موجود شد. اولین کار با رویداد و صف پیام، با کمک رضا.
3. ماه سوم. بهبود سرعت صفحه علاقه‌مندی‌ها. امید خودش مشکل را پیدا می‌کند و راه حل را در یک سند کوتاه پیشنهاد می‌دهد.

بازخورد: مشخص، زود، درباره کار

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

1. موقعیت. کجا و کی؟ «در بازبینی دیروز.»
2. رفتار. دقیقاً چه کاری انجام شد؟ چیزی که دیدی، نه برداشت خودت. «تست حالت لیست خالی نبود»، نه «بی‌دقتی».
3. اثر. این رفتار چه نتیجه‌ای داشت؟ «صفحه برای کاربرهای تازه خراب شد.»

بعد از این سه قدم، گفتگو را باز کن: «دفعه بعد چطور می‌توانیم این را زودتر پیدا کنیم؟» شاید جواب یک تغییر در چک‌لیست تیم باشد، نه فقط در کار امید.

همین قالب برای تعریف هم کار می‌کند: «در جلسه دیروز (موقعیت)، طراحی‌ات را با یک تصویر ساده توضیح دادی (رفتار). همه تیم در ده دقیقه موافقت کردند (اثر).» تعریف مشخص می‌گوید دقیقاً چه کاری را ادامه دهد.

جلسه یک‌به‌یک و فضای امن

یک جلسه منظم کوتاه، مثلاً هر دو هفته نیم ساعت، جایی است که امید می‌تواند چیزهایی بگوید که در جلسه تیم نمی‌گوید. این جلسه مال امید است، نه گزارش کار.

چند سؤال خوب برای این جلسه:

1. «این دو هفته چه چیزی یاد گرفتی؟»
2. «کجا گیر کردی یا حس کردی وقتت هدر رفت؟»
3. «دوست داری شش ماه بعد چه کاری بلد باشی؟»
4. «من چه کاری را می‌توانم بهتر انجام دهم؟»

همه این‌ها فقط وقتی کار می‌کند که امید احساس امنیت کند. یعنی بداند که گفتن «نمی‌دانم» یا «اشتباه کردم» به ضررش نیست. منتور این فضا را با رفتار خودش می‌سازد:

1. خودش بگوید «نمی‌دانم». «این را نمی‌دانم. بیا با هم پیدا کنیم.»
2. اشتباه‌های خودش را تعریف کند. «من یک بار کل جدول سفارش‌ها را روی Production قفل کردم. این‌طوری یاد گرفتم.»
3. بعد از خطا، دنبال مقصر نگردد. سؤال این است «چه چیزی اجازه داد این اتفاق بیفتد؟»، نه «چه کسی این کار را کرد؟».

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