در مسیر کلی مهندسی نرم‌افزار، یک نخ نامرئی وجود دارد که تمامی پروژه‌ها، شکست‌ها و چالش‌ها را به هم پیوند می‌دهد. این نخ، مردم هستند. به‌عنوان فردی با پیشینه مهندسی، از حل معماهای پیچیده و رفع مشکلات لذت می‌برم. اما پیچیده‌ترین، جذاب‌ترین و در نهایت رضایت‌بخش‌ترین جنبه سفر من همیشه مدیریت افراد بوده است. من در گذشته شخص اجتماعی‌ای نبودم—این مهارتی نبود که به‌طور طبیعی داشته باشم. مجبور بودم بسیار مطالعه کنم، یاد بگیرم، روش‌های مختلف را امتحان کنم و بسیاری از مسائل را به‌صورت آنی حل کنم، اما همچنان این بخش از شغلم برایم رضایت‌بخش‌ترین بخش است.
این راهنما حاصل تعاملات، گفت‌وگوها و تجربیات بی‌شمار من است. چیزهایی که در آن‌ها شکست خورده‌ام. این یک عصاره از درس‌های آموخته شده و یک نقشه راه است که به شما، مدیران مهندسی امروز، کمک می‌کند تا آب‌های پرتلاطم مدیریت مهندسان نرم‌افزار دشوار را هدایت کنید.
برخی افراد، توسعه‌دهندگان را «برف‌دانه» می‌نامند—آن‌ها درخشان، نظر‌دار و از بسیاری جهات منحصربهفرد هستند. مدیریت آن‌هایی که از سایر مهندسان چندان متمایز نیستند، آسان است. اما من تمرکزم بیشتر بر روی کارکنان دشوار خواهد بود تا مدیریت کلی تمام توسعه‌دهندگان.
چرا تمرکز بر روی افراد دشوار، ممکن است بپرسید؟ خب، ساده است. وقتی همه چیز به‌خوبی پیش می‌رود، وقتی تیم شما مانند یک ماشین خوب کار می‌کند، نیازی به راهنما ندارید. زمانی که با تضادها، برخوردهای ناشی از غرور، افراد مستقل یا یکی از اعضای تیم که به وظایف خود عمل نمی‌کند، اصطکاک ایجاد می‌کند یا صرفاً نمی‌تواند هماهنگ شود، مواجه می‌شوید، نیاز به قطب‌نما دارید. و این همان چیزی است که این راهنما سعی دارد باشد.
در بخش‌های بعدی، به انواع مختلف کارمندان دشوار که ممکن است با آن‌ها روبرو شوید، خواهیم پرداخت—از افراد اهمال‌کار و مستقل گرفته تا افرادی که همیشه منفی هستند و بیش‌ازحد وعده می‌دهند. سناریوهای معمولی را بررسی می‌کنیم، رفتارهای آن‌ها را توصیف کرده و مهم‌تر از همه، راهکارهایی برای مدیریت مؤثر این افراد ارائه می‌دهیم.
همچنین به اهمیت تکنیک‌های ارتباطی مانند ارتباط بدون خشونت (Nonviolent Communication) نیز اشاره خواهم کرد. مراحل اجرای برنامه بهبود عملکرد و زمان مناسب برای تشدید مسائل و جدایی از افراد نیز بررسی خواهد شد.
این راهنما یک عصای جادویی نیست که تمام چالش‌های مدیریتی شما را حل کند. اما نقطه آغازی است. این راهنما بسیار ذهنی است و تجربه شما ممکن است متفاوت باشد. این مجموعه‌ای از بینش‌ها و توصیه‌هاست که امیدوارم به شما کمک کند تا مدیر بهتری برای تیم خود باشید، حتی اگر برخی از اعضا، افرادی چندان خوشایند برای همکاری نباشند.
پس بیایید این سفر را با هم آغاز کنیم. بیایید با خدمه خود این دریاهای متلاطم را هدایت کنیم و چالش‌ها را به فرصت‌هایی برای رشد تبدیل کنیم. همان‌طور که هر دریانورد باتجربه‌ای خواهد گفت، این طوفان‌ها هستند که یک کاپیتان خوب را می‌سازند، نه دریای آرام.
مدیریت مؤثر افراد معمولی
قبل از اینکه به مدیریت مهندسان دشوار بپردازیم، ابتدا بیایید بر روی مدیریت افرادی تمرکز کنیم که چندان غیرمعمول نیستند. “معمولی” به اکثریت اعضای تیم شما اشاره دارد که روزانه سر کار می‌آیند، وظایف خود را انجام می‌دهند و به موفقیت تیم کمک می‌کنند—آن‌ها حرفه‌ای‌های شایسته‌ای هستند که از نظر ذهنی در وضعیت سالمی به سر می‌برند و نیازی به توجه ویژه ندارند. نه مشکلی دارند، نه تعارضی، نه نیاز خاصی. این افراد ستون فقرات تیم شما را تشکیل می‌دهند و احتمالاً ۹۰٪ افرادی که با آن‌ها ملاقات و همکاری می‌کنید، همین افراد خواهند بود.
من از یک استراتژی ساده برای اطمینان از خوشحالی این نوع کارمندان استفاده می‌کنم—اعتماد، رشد، راحتی.
اعتماد
اعتماد به آن‌ها برای انجام کارهای درست
- فرض بر هوشمندی: همیشه فرض را بر این بگذارید که اعضای تیم شما باهوش هستند و تصمیمات آگاهانه خواهند گرفت. این طرز فکر، محیطی از احترام ایجاد کرده و افراد را توانمند می‌سازد تا ابتکار عمل داشته باشند. حتی بهتر است فرض کنید که آن‌ها از شما باهوش‌تر هستند و ممکن است چیزی بدانند که شما نمی‌دانید. شما احتمالاً آن‌ها را استخدام کرده‌اید، پس مگر اینکه افرادی ضعیف‌تر از خودتان استخدام کنید (و امیدوارم چنین نکنید)، باید فرض کنید که ایده‌های بهتری نسبت به شما دارند.
- خودمختاری مسئولانه: به آن‌ها آزادی بدهید تا تصمیم بگیرند و اقدام کنند. پاسخگو نگه‌داشتن آن‌ها برای این تصمیمات، بسیار سازنده‌تر از زیر سؤال بردن هر حرکت آن‌هاست. خودمختاری با بهای مسئولیت‌پذیری همراه است و باید به‌صراحت بیان شود. هر کاری که می‌خواهید انجام دهید، اما مسئولیت اشتباهات هم با شماست.
- اجازه به اشتباهات قابل‌اصلاح: اعتماد به معنای اجازه دادن به وجود فضای اشتباه است. البته، منظور من توسعه‌دهندگان ارشد با دسترسی‌های ویژه نیست که فرمان‌های مخرب مانند
rm -rfرا روی سرور اجرا کنند یا پایگاه داده تولید را حذف کنند و بعد بگویند “اشتباه شد”—این موارد نیاز به اقدام اصلاحی دارد. اشتباهات را می‌توان به دو بخش تقسیم کرد: اشتباهاتی که قابل‌اصلاح هستند و اشتباهاتی که قابل‌اصلاح نیستند. اشتباهات قابل‌اصلاح هر چیزی است که می‌توانید برای آن گزارشی بنویسید، یک جلسه بررسی برگزار کنید و با درس‌هایی که گرفته‌اید به مسیر خود ادامه دهید. اشتباهات غیرقابل‌اصلاح شامل مواردی مانند مرگ افراد، انفجار یا ورشکستگی شرکت است. به آن‌ها اجازه دهید اشتباهاتی مرتکب شوند که شرکت بتواند از آن‌ها بازیابی کند و به آن‌ها کمک کنید تا از این اشتباهات بیاموزند. بعدا: به این داستان هشداردهنده در مورد یک دیپلوی ناموفق که در ۴۵ دقیقه شرکتی را ورشکسته کرد و نظرات سایت HackerNews در مورد آن رجوع کنید.
رشد
چالش‌هایی برای بهتر شدن
- چالش مداوم: اعضای تیم خود را به‌طور مرتب از منطقه راحتی‌شان خارج کنید. منظور این نیست که آن‌ها را به پروژه‌هایی پرتاب کنید که هیچ دانشی درباره آن‌ها ندارند و انتظار عملکرد عالی داشته باشید. بلکه، آن‌ها را تشویق کنید تا وظایفی را انجام دهند که توانایی‌هایشان را کمی فراتر از حد معمول گسترش دهد. این کار باعث رشد آن‌ها می‌شود.
- تحسین و قدردانی: دستاوردهای آن‌ها را بشناسید. نقاط عطفی که می‌توانند به آن برسند را به آن‌ها نشان دهید و زمانی که به آن‌ها رسیدند، همراهشان جشن بگیرید—چه از طریق پاداش‌های مالی و چه با اعلام عمومی موفقیت‌هایشان. این کار نه‌تنها روحیه آن‌ها را بالا می‌برد، بلکه انگیزه می‌دهد تا هدف‌های بزرگ‌تری را دنبال کنند.
- بازخورد سازنده و مسیر شفاف: درحالی‌که تحسین ضروری است، به همان اندازه مهم است که به نقاط ضعف آن‌ها نیز پرداخته شود. هیچ‌کس کامل نیست و برخی از ما در زمینه‌هایی بهتر از دیگران عمل می‌کنیم. بااین‌حال، تمرکز باید بر بهبود نقاط قوت و اصلاح نقاط ضعف باشد. اگر در الگوریتم‌ها قوی هستند اما در پایگاه داده‌ها ضعف دارند، زمان آن رسیده که در پایگاه داده عمیق شوند. اگر در وظایف کوچک خوب هستند اما در پروژه‌های بزرگ مشکل دارند، زمان یادگیری معماری نرم‌افزار است. در هر صورت، بازخورد باید ابزاری برای رشد باشد، نه سلاحی برای انتقاد.
راحتی
ایجاد یک محیط کاری راحت
- محدود کردن وقفه‌ها: به وقت و تمرکز آن‌ها احترام بگذارید. از جلسات و وقفه‌های غیرضروری اجتناب کنید. ارتباطات غیرهمزمان را بپذیرید، به‌طوری‌که اعضای تیم بتوانند در زمانی که برایشان مناسب است پاسخ دهند. این کار باعث افزایش کارایی و احترام به ریتم کاری افراد می‌شود. اگر چرخ‌ها در حال چرخیدن هستند، نیازی به وقفه ایجاد کردن نیست. بگذارید افراد کارشان را انجام دهند.
- فرآیندهای روان: اطمینان حاصل کنید که تمامی فرآیندهای جانبی، از ابزارهای نرم‌افزاری گرفته تا وظایف اداری، کارآمد، کاربرپسند و بدون ایجاد وقفه (مانند مورد بالا) باشند. یک محیط عملیاتی روان باعث کاهش ناامیدی شده و به اعضای تیم اجازه می‌دهد بر کار اصلی خود متمرکز شوند.
- کمتر فکر کردن، بیشتر خلق کردن: ازآنجاکه مهندسان نرم‌افزار بیشتر خلاق هستند، هرچقدر تصمیمات غیرضروری کمتری خارج از پروژه خود بگیرند، تصمیمات بهتری در داخل پروژه خواهند گرفت. به‌جای اینکه خودشان فکر کنند “آیا فردا روز کاری است یا نه”، این اطلاعات را به‌راحتی در دسترس قرار دهید. به‌جای اینکه بخواهند بفهمند از کجا باید تنقلات تهیه کنند، تنقلات را آماده کنید. ایده را متوجه شدید.
فهرست بالا می‌تواند محرکی باشد که تیم شما را به یک سطح جدید از بهره‌وری برساند. این موارد، فرصت‌های ساده‌ای هستند که می‌توانند جوی مثبت ایجاد کنند که در هر خط کدی که نوشته می‌شود، جریان پیدا می‌کند. این اقدامات کیفیت نرم‌افزاری که تیم شما تولید می‌کند را افزایش داده و اطمینان می‌دهد که هر محصولی که ارائه می‌دهید، بهترین کیفیت ممکن را دارد.
اما بیایید حقیقت را کتمان نکنیم—رهبر مؤثر بودن در یک تیم مهندسی نرم‌افزار بدون چالش نیست. شما با انسان‌هایی سر و کار دارید که هرکدام شخصیت‌ها، نقاط قوت، ضعف‌ها و ویژگی‌های منحصربهفرد خود را دارند.
یکی از رایج‌ترین و اغلب دلهره‌آورترین چالش‌ها، مواجهه با کارکنان دشوار است. چه کدنویس درخشانی باشد که نمی‌تواند ضرب‌الاجل‌های خود را رعایت کند، چه مهندس باتجربه‌ای که در کار تیمی مشکل دارد، یا تازه‌کاری با استعداد که همیشه منفی است—با افراد زیادی روبرو خواهید شد که برای اطمینان از حفظ بهره‌وری همه، به همدلی و درک بیشتری نیاز دارند.
بیایید انواع مهندسان نرم‌افزار دشوار را بررسی کنیم، رفتارهای آن‌ها را بشناسیم و استراتژی‌های عملی برای مدیریت آن‌ها را یاد بگیریم. زیرا در پایان روز، فقط ساختن نرم‌افزارهای عالی مهم نیست؛ بلکه داشتن تیمی شاد و پویا در مسیر این ساختن نیز اهمیت دارد.
مهندسین نرم‌افزار مشکل
من از واژه «مشکل» استفاده می‌کنم تا میان کارمندانی که همه چیز برایشان به‌خوبی پیش می‌رود و آن‌هایی که نیاز به تلاش بیشتری دارند، تمایز قائل شوم.
چرا درک انواع مختلف کارمندان مشکل‌ساز مهم است؟ به این شکل به آن فکر کنید: اگر قصد رفع اشکال (debug) یک قطعه کد را دارید، ابتدا باید بفهمید که هر خط کد چه کاری انجام می‌دهد، درست است؟ به همین ترتیب، برای رسیدگی و مدیریت رفتارهای مشکل‌ساز به‌طور مؤثر، ابتدا باید این رفتارها، انگیزه‌هایشان و تأثیر آن‌ها بر تیم را درک کنید.
در این بخش، انواع مختلفی از کارمندان مشکل‌ساز را که ممکن است در یک تیم مهندسی نرم‌افزار با آن‌ها مواجه شوید، بررسی خواهیم کرد. هرکدام از این انواع چالش‌ها و فرصت‌های منحصربه‌فردی برای رشد و بهبود ارائه می‌دهند. با درک این رفتارها، می‌توانید آن‌ها را به‌طور مؤثر مدیریت کنید و موانع احتمالی را به سکوی پرشی برای دستیابی به تیمی هماهنگ‌تر و پربازده‌تر تبدیل کنید.
می‌خواهم تأکید کنم که برخی از سناریوها اغراق‌شده هستند و من یک استاد ارتباطات نیستم. بنابراین، اگر مثال‌های بهتری دارید، لطفاً در نظرات مطرح کنید. بسیار سپاسگزار خواهم بود.
فرد اهمال‌کار
این صحنه را تصور کنید: یک هفته به انتشار نسخه اصلی نرم‌افزار مانده است. تیم شما پر از جنب‌وجوش است، در حال تکمیل کارهای نیمه‌تمام و انجام آخرین آزمایش‌ها. اما یک نفر در تیم، بیایید او را جو (Joe) بنامیم، هنوز بخش مهمی از پروژه را تکمیل نکرده است. با وجود یادآوری‌های مکرر، جو همیشه بهانه‌ای دارد — ساخت (build) زمان زیادی می‌برد یا اینکه «روی سیستم من کار می‌کند اما در محیط استیجینگ مشکل دارد» — و همیشه وعده می‌دهد که «فردا» آن را درست خواهد کرد. این یک نمونه کلاسیک از فرد اهمال‌کار است.
اهمال‌کاران تمایل دارند وظایف را به تأخیر بیندازند و اغلب روی کارهای کم‌اهمیت‌تر تمرکز می‌کنند و کارهای حیاتی را نادیده می‌گیرند. آن‌ها ممکن است در مدیریت زمان ضعیف باشند و معمولاً زمان لازم برای تکمیل وظایف را دست‌کم می‌گیرند. این رفتار می‌تواند به از دست رفتن ضرب‌الاجل‌ها، افزایش استرس تیم و ایجاد ریسک‌های احتمالی برای پروژه منجر شود.
مدیریت فرد اهمال‌کار به تعادلی میان قاطعیت و حمایت نیاز دارد. ضرب‌الاجل‌های واضح تعیین کنید و به‌طور مرتب پیشرفت او را بررسی کنید. او را نسبت به این ضرب‌الاجل‌ها پاسخگو کنید. به او در اولویت‌بندی وظایف کمک کنید و در صورت نیاز، آموزش‌های مدیریت زمان ارائه دهید. اطمینان حاصل کنید که او به‌طور روزانه ابزارهای مدیریت پروژه را با پیشرفت انجام‌شده به‌روزرسانی می‌کند.
به یاد داشته باشید، هدف کنترل‌گری نیست، بلکه راهنمایی آن‌ها به سمت عادات کاری بهتر است.
گرگ تنها
این صحنه را تصور کنید: تیم شما در حال طوفان فکری برای یک ویژگی جدید است. ایده‌ها در حال پرواز هستند و انرژی بالاست. اما یک نفر، بیایید او را لیزا (Lisa) بنامیم، بی‌صدا نشسته و مشارکتی نمی‌کند. بعداً متوجه می‌شوید که لیزا بدون بحث با تیم، خودش شروع به کار روی این ویژگی کرده است. او تصور کرده که خودش بهترین روش را برای حل مشکل می‌داند. این یک سناریوی کلاسیک گرگ تنها است.
گرگ‌های تنها فرض می‌کنند که آن‌ها شایسته‌ترین فرد هستند و ترجیح می‌دهند به‌تنهایی کار کنند و اغلب در برابر تلاش‌های گروهی مقاومت می‌کنند — یعنی چرا باید به کمک کسی که به‌مراتب از شما پایین‌تر است نیاز داشته باشید؟ معمولاً، آن‌ها فقط برای گفتن اینکه «من می‌توانستم این کار را در سه روز انجام دهم» در بحث‌های تیمی شرکت می‌کنند. درحالی‌که اتکای آن‌ها به خود می‌تواند گاهی یک دارایی باشد، اما می‌تواند به نبود انسجام و ناهماهنگی با اهداف تیم نیز منجر شود. و از همه مهم‌تر — دیگران از کار با گرگ‌های تنها لذت نمی‌برند.
من گرگ‌های تنها را به‌عنوان افرادی با ذهنیت نوجوانانه می‌بینم. آن‌ها در این طرز فکر گیر کرده‌اند که خودشان باهوش‌ترین و حرفه‌ای‌ترین برنامه‌نویسان هستند.
دو راه برای مدیریت گرگ تنها وجود دارد — یا پذیرش یا وادار کردن به همکاری. پذیرش گرگ‌های تنها به این معنی است که این فرد برای کسب‌وکار شما ارزش بسیار بالایی دارد و راحت نگه‌داشتن او از روحیه کلی تیم مهم‌تر است. توصیه نمی‌شود، اما اگر گرگ تنها از نظر شما یک مهندس 100x است، این یک معامله ممکن است.
مدیریت گرگ تنها شامل ایجاد فرهنگ همکاری اجباری است. آن‌ها را تشویق کنید که ایده‌های خود را در جلسات به اشتراک بگذارند و به‌طور مستقیم‌تر در تصمیمات تیمی مشارکت کنند. بهتر است آن‌ها را در تیمی قرار دهید که در آن از نظر سطح دانش در بالاترین جایگاه نباشند. برایشان یک منتور تعیین کنید تا به آن‌ها کمک کند خود را در نوری متفاوت ببینند. به آن‌ها وظایفی محول کنید که نیاز به همکاری دارند و از همه مهم‌تر — نقد سازنده‌ای از رفتارشان ارائه دهید و قوانینی برای همکاری تعیین کنید — آن‌ها می‌توانند در همان سطح بمانند یا از این ذهنیت گرگ تنها عبور کنند و به برنامه‌نویسی حتی بهتر تبدیل شوند که دیگران از کار با او لذت ببرند.
منفی‌نگر
این صحنه را تصور کنید: تیم شما در جلسه‌ای برای بحث درباره یک پروژه جدید است. حسی از هیجان در هوا وجود دارد و شور و شوق موج می‌زند. اما یک نفر، بیایید او را مارک (Mark) بنامیم، به نظر می‌رسد که در هر ایده یک مشکل پیدا می‌کند و در هر برنامه یک نقص. او دائماً روی جنبه‌های منفی تمرکز می‌کند، به ندرت راه‌حلی ارائه می‌دهد و فکر می‌کند همه چیز غیرممکن است و وضعیت موجود کاملاً خوب است. این یک نمونه معمولی از فرد منفی‌نگر است.
اول از همه — دیدن مشکلات در ایده‌ها ذاتاً مشکلی ندارد. مسئله بیشتر نحوه بیان منفی مشکل است. اگر چالشی وجود داشته باشد که برای تحقق ایده باید بر آن غلبه کرد، افراد منفی‌نگر معمولاً می‌گویند به دلیل X غیرممکن است، نه اینکه «ما می‌توانیم آن را عملی کنیم اگر X و Y را انجام دهیم که تلاش قابل‌توجهی می‌طلبد، اما همچنان ممکن است.»
افراد منفی‌نگر تمایل دارند بیش‌ازحد روی جنبه‌های منفی موقعیت‌ها تمرکز کنند و راه‌حل‌های احتمالی را نادیده بگیرند. آن‌ها ممکن است زیاد شکایت کنند، در برابر تغییر مقاومت کنند و منفی‌نگری را در تیم گسترش دهند. این رفتار می‌تواند روحیه تیم را تضعیف کرده و خلاقیت و نوآوری را مختل کند. «چرا ما را مجبور می‌کنند X را انجام دهیم؟ آه، من اوضاع فعلی را دوست دارم.»
مدیریت فرد منفی‌نگر شامل درک دیدگاه آن‌ها است — از موضعی که «هیچ‌چیزی نباید راحتی مرا تحت تأثیر قرار دهد، هرچه بیشتر مشکلات پیدا کنم، کمتر باید کاری انجام دهم و کمتر از منطقه راحتی خود خارج می‌شوم.» این منفی‌نگری باید به‌طور مستقیم و خصوصی موردبحث قرار گیرد و از آن‌ها خواسته شود به‌جای مشکلات، راه‌حل ارائه دهند. تعاملات مثبت را تشویق کنید و به آن‌ها یادآوری کنید که تغییر به هر صورت اتفاق می‌افتد و اگر آن‌ها همچنان روی جنبه‌های منفی تمرکز کنند، امور بدون آن‌ها پیش خواهد رفت. اگر رفتار ادامه یابد، ممکن است نیاز به دخالت منابع انسانی یا بررسی اینکه آیا این کارمند برای تیم مناسب است یا نه، ضروری باشد.
وعده‌دهنده بیش‌ازحد
این صحنه را تصور کنید: شما در حال برنامه‌ریزی برای انتشار نسخه جدید نرم‌افزار هستید. یکی از اعضای تیم، بیایید او را سارا (Sarah) بنامیم، وعده می‌دهد که یک عملکرد پیچیده را ظرف یک ماه ارائه دهد. از اعتمادبه‌نفس او تحت تأثیر قرار می‌گیرید، اما دو هفته پس از اینکه به شما گفت «همه چیز عالی است، دارم روی آن کار می‌کنم»، عملکرد موردنظر هنوز کامل نشده است؛ حتی بدتر، فقط حدود 20 درصد آن انجام شده.
کسانی که زیاد قول می‌دهند معمولاً توسعه‌دهندگان جوان‌تری هستند که هنوز زیاد به تاریخ‌های تحویل پایبند نبوده‌اند و هنوز در حال یادگیری میزان کاری هستند که می‌توانند انجام دهند و با چه سرعتی.
مدیریت یک کسی که زیاد قول می‌دهد شامل تعیین انتظارات واقعی همراه با اعضای تیم است — پیدا کردن یک تاریخ تحویل مناسب برای این کار بزرگ که باید ساخته شود و تقسیم آن به وظایف معنادار (همراه با اعضای تیم) — و بعد از آن، همه توافق می‌کنند که هر کدام از این بخش‌ها چقدر زمان می‌برد. فکر نمیکنم راهی برای کمک به آن‌ها برای انجام تعهدات دقیق‌تر غیر از تجربه بیشتر وجود داشته باشد. اگر یک توسعه‌دهنده ارشد باشد — مسئولیت تاریخ‌های تحویلی که خودشان تعیین کرده‌اند را از آن‌ها بخواهید. آن‌ها را تشویق کنید که در مورد هر چالشی که با آن روبرو هستند، زود و با شفافیت ارتباط برقرار کنند.
همه‌چیزدان‌ها
سناریوی احتمالی: شما در یک جلسه تیمی هستید و دارید درباره یک مشکل پیچیده صحبت می‌کنید. اعضای تیم راه‌حل‌هایی پیشنهاد می‌دهند، درباره مزایا و معایب بحث می‌کنند، و همکاری سازنده‌ای در جریان است. اما ناگهان کسی، بیایید او را الکس (Alex) بنامیم، صحبت می‌کند و می‌گوید که دیگر کافی است، همه احمق هستند، همه راه‌حل‌ها مزخرف‌اند و تنها راه‌حل او درست است. نباید به راه‌حل او شک کنید یا نقصی در آن پیدا کنید، چون کسی باهوش‌تر از او نیست. او با شدت ایده‌های دیگران را رد می‌کند و از پذیرش بازخورد امتناع می‌ورزد. این فرد، همان همه‌چیزدان کلاسیک است.
این ویژگی بسیار شبیه گرگ تنها است، با این تفاوت که آن‌ها اصرار ندارند تنها کار کنند — بلکه اصرار دارند که تنها راه‌حل آن‌ها اجرا شود و مورد تحسین قرار گیرد.
همه‌چیزدان‌ها معمولاً متکبر و ذهن‌بسته هستند. آن‌ها اغلب توانایی شنیدن دیگران را ندارند و به شدت در برابر تغییر یا ایده‌های جدید مقاومت می‌کنند. همان‌طور که می‌توانید تصور کنید، این رفتار برای دیگران که می‌خواهند با ایده‌ها کلنجار بروند و بهترین راه‌حل را پیدا کنند، بسیار آزاردهنده است. در مجموع، این رفتار خلاقیت را سرکوب می‌کند، همکاری تیمی را مختل می‌سازد و محیط کاری خصمانه‌ای ایجاد می‌کند.
هیچ‌کس از همکاری با همه‌چیزدان‌ها لذت نمی‌برد. آن‌ها هر پیشنهادی برای بهبود، حتی کوچک‌ترین آن را، خاموش می‌کنند. تصور کنید کسی که عقده برتری دارد — هر اشاره‌ای به ناقص بودن ایده‌اش منجر به بحثی دفاعی می‌شود.
چگونه با همه‌چیزدان‌ها رفتار کنیم؟ اولین قدم، پرداختن مستقیم به این رفتار در یک جلسه خصوصی است — آن‌ها احتمالاً از نقاط ضعف خود بی‌خبرند، چون فکر می‌کنند همه کارهایشان بی‌عیب است. این مقاله را برایشان بفرستید و از آن‌ها بخواهید بررسی کنند که آیا خود را در این توصیف می‌بینند یا نه. پس از مواجهه، بر احترام متقابل و ذهن‌باز بودن تأکید کنید — همه ایده‌ها، حتی اگر به نظر کامل بیایند، باید مورد بحث و بررسی قرار گیرند. فقط در این صورت است که می‌توان از صحت یک راه‌حل مطمئن شد. آن‌ها را تشویق کنید که همیشه درخواست بازخورد کنند.
اگر رفتار ادامه یافت، هشدار رسمی بدهید و در صورت نیاز، HR را در جلسه درگیر کنید.
نوع ساکت
سناریو: تیم شما در حال بحثی پرانرژی برای طوفان فکری و ایده‌پردازی برای یک ویژگی جدید و جذاب است. همه در بحث شرکت دارند به جز یک نفر. بیایید او را امیلی (Emily) بنامیم. او ساکت نشسته و در بحث مشارکت نمی‌کند. بعدها متوجه می‌شوید که ایده فوق‌العاده‌ای داشته، اما احساس راحتی نکرده که آن را مطرح کند. این یک سناریوی کلاسیک از نوع ساکت است.
می‌خواهم تاکید کنم که این نوع رفتاری ربطی به جنسیت ندارد، اما لازم است اشاره کنم که توسعه‌دهندگان زن اغلب در شرایطی که فرهنگ تیم شبیه به باشگاه برادری است و بلندترین صداها بیشترین ارزش را دارند، برای بیان نظر خود با چالش بیشتری روبه‌رو می‌شوند.
نوع ساکت عموماً درون‌گرا است و ممکن است در برقراری ارتباط مشکل داشته باشد. حتی اگر فوراً مسائل راه‌حل را ببیند، ممکن است فکر کند: «ارزشش را ندارد که نگرانی‌ها را مطرح کنم و با کسی مخالفت کنم.» آن‌ها اغلب افکارشان را برای خود نگه می‌دارند که می‌تواند منجر به سوءتفاهم یا از دست دادن فرصت‌های همکاری شود.
این نوع رفتار معمولاً نتیجه یک فرهنگ سمی است که در آن تعارضات به شیوه‌ای سالم حل نمی‌شوند و بنابراین همه از آن‌ها اجتناب می‌کنند به جای این که مستقیماً با آن‌ها روبه‌رو شوند. این همچنین نشان می‌دهد که سایر الگوهای «بد» نیز در تیم حضور دارند، مانند همه‌چیزدان.
مدیریت نوع ساکت شامل ایجاد محیطی امن و فراگیر و تشویق دیگران به صحبت کردن حتی در صورت بروز تعارض ایده‌ها است. بحث‌های سالم باید به طور منظم اتفاق بیفتند تا همه ببینند بیان نظرات چیزی نیست که باید از آن ترسید. روش‌ها و پلتفرم‌های مختلفی برای برقراری ارتباط فراهم کنید — جلسات یک‌به‌یک، جلسات گروه‌های کوچک، چت‌های گروهی، یا بحث از طریق ایمیل — که ممکن است برای آن‌ها راحت‌تر باشد.
اما مهم‌تر از همه، مشارکت‌های آن‌ها را به رسمیت بشناسید و قدردانی کنید تا حتی اگر صدای بلندی در جمع ندارند، احساس کنند که جزئی از تیم هستند.
کمال‌گرا
سناریو: فرض کنید یکی از اعضای تیم شما یک Pull Request ثبت می‌کند. بیایید او را تام (Tom) بنامیم. شما شروع به بررسی کد می‌کنید — کد خوب نوشته شده و کار می‌کند، اما *تام* راضی نیست. او روزها وقت صرف کرده تا آن را اصلاح و کامل کند، و در نهایت آن را به یک خط کد تبدیل کرده است. مشکل چیست؟ کارهای دیگر در حال انباشته شدن هستند، ضرب‌الاجل‌ها نزدیک می‌شوند، و کدی که فقط برای تام جذاب است، باعث تأخیر می‌شود. این یک کمال‌گرای کلاسیک است.
کمال‌گراها اغلب فارغ‌التحصیلان تازه‌کار هستند. آن‌ها تمایل دارند روی جزئیات کوچک تمرکز کنند، اغلب به هزینه چشم‌پوشی از تصویر کلی. ممکن است با اصول KISS (ساده نگه داشتن سیستم) و تفویض کار مشکل داشته باشند و استانداردهای بسیار بالا، و گاهی غیرواقع‌بینانه، برای خود و دیگران داشته باشند. در ذهن آن‌ها، کدنویسی هنر است و نباید هنگام خلق یک اثر هنری عجله کنند. این رفتار منجر به ناکارآمدی، از دست رفتن ضرب‌الاجل‌ها و افزایش استرس برای کل تیم می‌شود.
چگونه یک کمال‌گرا را مدیریت کنیم؟ ساده است. انتظارات آن‌ها از خودشان را کاهش دهید، به آن‌ها کمک کنید روی مهم‌ترین چیزها تمرکز کنند — یک راه‌حل عملی که بیش از حد پیچیده نباشد، شبیه شعر نوشته نشده باشد، و در دو سال آینده قابل نگهداری باشد. آن‌ها را تشویق کنید راه‌حل‌های ساده را در اولویت قرار دهند و استانداردهای واقع‌بینانه‌ای تعیین کنند. از آن‌ها بخواهید برای “آمادگی” کد نظر دوم بگیرند.
در صورت نیاز، روی مدیریت زمان آن‌ها کار کنید و کتاب‌هایی پیشنهاد دهید که عادت‌های کدنویسی مؤثری ایجاد کنند.
نوع غیرقابل‌اعتماد
سناریو: شما پروژه‌ای با یک ضرب‌الاجل فشرده مدیریت می‌کنید. یکی از اعضای تیم شما، بیایید او را آنا (Anna) بنامیم، مسئول بخش مهمی از پروژه است. با وجود این که بارها اطمینان داده که کار را به موقع تمام می‌کند، ضرب‌الاجل می‌رسد و می‌گذرد و کار هنوز ناقص است. این یک سناریوی کلاسیک از نوع غیرقابل‌اعتماد است.
کارمندان غیرقابل‌اعتماد با تأخیر مداوم شناخته می‌شوند — همیشه دیر می‌کنند، کارهای ناقص تحویل می‌دهند و جلسات را از دست می‌دهند. آن‌ها فاقد تعهد، انضباط یا مهارت‌های مدیریت زمان هستند. یا شاید هر سه را به طور همزمان نداشته باشند. عملکرد ناپایدار آن‌ها می‌تواند باعث بی‌اعتمادی و ناامیدی در تیم شود و به طور بالقوه (به احتمال زیاد) جدول زمانی پروژه را به خطر بیندازد.
مدیریت نوع غیرقابل‌اعتماد شامل تعیین انتظارات واضح و مسئولیت‌پذیر کردن آن‌ها است — یعنی ارائه هشدار رسمی پس از اولین حادثه. در اولین حادثه، بازخوردی در مورد تأثیر رفتارشان بر تیم و پروژه بدهید. اگر این عادت ادامه یافت، برنامه‌ای برای بهبود عملکرد تنظیم کنید و در مورد اقدامات انضباطی آینده شفاف توافق کنید. به یاد داشته باشید، قابلیت اطمینان بخش کلیدی یک تیم با عملکرد بالا است و رسیدگی به مسائل به موقع و مؤثر اهمیت دارد.
اگر با کارمندان غیرقابل‌اعتماد برخورد نکنید، به تیم خود که تلاش می‌کنند مؤثر باشند و روی آن‌ها حساب باز می‌کنند، ظلم می‌کنید. اعضای تیم باید زمان خود را صرف پیدا کردن راه‌هایی برای دور زدن آن‌ها کنند، نه همکاری با آن‌ها.
محرک تعارض
تصور کنید: تیم شما در حال کار هماهنگ بر روی یک پروژه است، اما یک نفر، بیایید او را جیک (Jake) بنامیم، به نظر می‌رسد از ایجاد تعارض لذت می‌برد. او از کد دیگران شوخی می‌کند، به افراد طعنه می‌زند، و اغلب باعث شروع بحث‌ها، پخش شایعات یا ایجاد محیطی خصمانه می‌شود. این یک سناریوی کلاسیک از محرک تعارض است.
محرک‌های تعارض معمولاً بحث‌برانگیز، پرخاشگر و مختل‌کننده هستند. آن‌ها از درام لذت می‌برند و محیط کاری سمی ایجاد می‌کنند. این رفتار می‌تواند منجر به کاهش روحیه تیمی، افزایش استرس و کاهش بهره‌وری شود.
به نظر من تنها یک راه برای مدیریت چنین کارمندانی وجود دارد، با پرداختن فوری به رفتارشان در یک جلسه خصوصی، و تأکید بر اهمیت حفظ حرفه‌ای‌گری و سیاست تحمل صفر برای چنین رفتارهایی در آینده. اگر ادامه یافت سریع رابطه را قطع کنید و نگاهتان را برنگردانید. نگه داشتن آن‌ها در تیم، تلاش اضافی است. به یاد داشته باشید، یک تیم سالم یک تیم با عملکرد بالا است و تعارض‌های سمی باید به سرعت و مؤثر حل شوند.
کارمند سوخته
سناریو: یکی از بهترین‌های تیم شما، بیایید او را لیزا (Lisa) بنامیم، نشانه‌هایی از سوختگی نشان می‌دهد. او در سال گذشته عالی کار کرده است، هر مرحله‌ای را با موفقیت پشت سر گذاشته، اما اخیراً ساعت‌های طولانی کار می‌کند، ضرب‌الاجل‌ها را از دست می‌دهد و به نظر می‌رسد از تیم جدا شده است. او دیگر همان فرد پرانرژی و انگیزه‌دار سابق نیست. این یک سناریوی کلاسیک از کارمند سوخته است.
من کارمند سوخته را به عنوان “کارمند بد” نمی‌بینم، اما آن‌ها هنوز می‌توانند تأثیر منفی داشته باشند — آن‌ها کسانی هستند که باید به کمک آن‌ها بشتابید و مطمئن شوید که دوباره می‌توانند درخشش داشته باشند.
کارمندان سوخته علائم خستگی، بدبینی و کاهش کارایی حرفه‌ای را نشان می‌دهند. آن‌ها با مشکل مواجه می‌شوند تا ضرب‌الاجل‌ها را رعایت کنند، پایین‌ترین میزان خروجی را در تیم دارند و اشتباهات بیشتری نسبت به گذشته مرتکب می‌شوند.
مدیریت کارمند سوخته شامل پرداختن به مشکل با همدلی و نگرانی زیاد است. پیشنهاد دهید که آن‌ها تعطیلات بگیرند یا به مرخصی طولانی بروند. بر تعادل کار و زندگی تأکید کنید و منابعی برای مدیریت استرس فراهم کنید.
به یاد داشته باشید، اعضای تیم شما باارزش‌ترین دارایی شما هستند و رفاه آن‌ها باید همیشه در اولویت باشد.
نکات ارتباطی
مدیریت کارمندان دشوار یعنی پیدا کردن راه‌هایی برای اطمینان از اینکه شما و کارمندان‌تان موفق می‌شوید، حتی اگر شرایط علیه شما باشد. یک ابزار که به طور خاص حیاتی است: ارتباطات. در یک تیم مهندسی نرم‌افزار، ارتباطات واضح و مؤثر نه تنها یک ویژگی خوب است؛ بلکه یک نیاز اساسی است. ارتباطات ضعیف دلیل شکست تیم‌ها است.
به این فکر کنید. چقدر دیده‌اید که یک پروژه به دلیل یک سوءتفاهم ساده از مسیر خود خارج شده باشد؟ چند تعارض می‌توانست با ارتباطات بهتر جلوگیری شود؟ چند ایده عالی در شلوغی ارتباطات ضعیف از بین رفته است؟
ارتباط غیرخشونت‌آمیز
یکی از ابزارهای ارتباطی که من آن را بسیار مفید یافتم، ارتباط غیرخشونت‌آمیز (NVC) است. این روش ارتباطی که توسط روان‌شناس مارشال روزنبرگ توسعه یافته، ترویج همدلی و درک متقابل را هدف قرار می‌دهد.
در اصل، NVC شامل چهار مرحله است: مشاهده، احساس، نیاز و درخواست.
- مشاهده شامل بیان حقایقی است که بر رفاه ما تأثیر می‌گذارند.
- احساس بیان این است که ما چگونه نسبت به آنچه مشاهده کرده‌ایم احساس می‌کنیم.
- نیاز بیان چیزی است که ما به آن نیاز داریم یا ارزشی است که باعث ایجاد احساسات‌مان می‌شود.
- درخواست شامل درخواست واضح از چیزی است که می‌خواهیم بدون اینکه آن را تحمیل کنیم.
در یک زمینه مدیریتی، NVC می‌تواند تحول‌آفرین باشد. این روش می‌تواند به شما کمک کند تا با تیم خود به طور مؤثر ارتباط برقرار کنید، مشکلات را به شیوه‌ای سازنده حل کنید و روابط مثبت و قوی بسازید.
بیشتر از این در مورد این قضیه صحبت نمیکنم با این همه چند لینک برای خواندن در اختیار شما قرار می‌دهم.
- https://www.dave-bailey.com/blog/nonviolent-communication
- https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X
گوش دادن فعال و همدلی
به عنوان یک مدیر، نقش شما تنها صحبت کردن نیست؛ بلکه گوش دادن هم هست. گوش دادن فعال یک مهارت اساسی است که شامل تمرکز کامل بر سخنران، درک پیام او و پاسخ‌دهی با تفکر است. این تنها شنیدن کلمات نیست؛ بلکه فهمیدن احساسات، ایده‌ها و افکاری است که پشت کلمات قرار دارند.
شریک تجاری من که یک فروشنده عالی است، این قانون را دارد — بعد از اینکه کسی صحبتش تمام شد، چند ثانیه صبر کن تا پاسخ بدهی، افکارت را مرتب کن و آنچه را که گفتند پردازش کن، و فقط زمانی که مطمئن شدی همه آنچه که می‌خواستند بگویند را گفته‌اند، پاسخ بده.
گوش دادن فعال می‌تواند از طریق بازگویی، پرسش‌های باز و نشان دادن همدلی بهبود یابد. همدلی، توانایی درک و به اشتراک گذاشتن احساسات دیگران، نقش حیاتی در مدیریت ایفا می‌کند. پرورش همدلی شامل باز بودن برای دیدگاه‌های دیگران، نشان دادن علاقه واقعی به تجربیات آن‌ها و پاسخ دادن با مهربانی و درک است. به طور ساده، قبل از اینکه کسی را به عنوان یک “کارمند دشوار” قضاوت کنید، خود را به جای او بگذارید و از دیدگاه او نگاه کنید. با او صحبت کنید، گوش دهید، چون همه ما انسانیم.
نقش شما فقط رهبری نیست؛ بلکه حمایت، درک و الهام بخشیدن هم هست.
قدم بعدی چیست؟
پس از شناسایی و درک انواع کارمندان دشوار در تیم خود و برقراری ارتباط مؤثر با آن‌ها، سوال پیش می‌آید که قدم بعدی چیست؟ گزینه‌ها چیست؟ این بخش شما را از مراحل بعدی، از جمله پیاده‌سازی برنامه‌های بهبود عملکرد (PIP) تا افزایش مشکلات در صورت لزوم، راهنمایی خواهد کرد.
برنامه‌های بهبود عملکرد (PIP)
اگر پس از بسیاری از جلسات 1:1 با فرد، نتوانستید راه‌حلی پیدا کنید که به نفع هر دو طرف باشد — کارمند و شرکت — و آن‌ها هنوز به رفتار خود ادامه می‌دهند، وقت آن رسیده است که مسئله را به صورت رسمی مطرح کنید.
یک برنامه بهبود عملکرد (PIP) یک سند رسمی است که مشکلات عملکردی یک کارمند را شرح می‌دهد و مراحلی که او باید برای بهبود بردارد را مشخص می‌کند. این یک ابزار افزایش درجه است که می‌تواند به مدیران کمک کند تا مسائل عملکردی را به شکلی ساختارمند و حمایتی برطرف کنند.
PIP ممکن است زمانی ضروری باشد که عملکرد یک کارمند به طور مداوم با انتظارات همخوانی نداشته باشد، علی‌رغم بازخورد و مربی‌گری. این مرحله زمانی است که مداخلات غیررسمی‌تر منجر به بهبود نشده باشند.
اجرای PIP شامل چند مرحله است — ابتدا مشکلات عملکردی را به وضوح مشخص کنید و انتظارات بهبود را تعریف کنید. سپس اهداف واقعی، قابل اندازه‌گیری و یک جدول زمانی برای دستیابی به آن‌ها تنظیم کنید. منابع و حمایت‌هایی برای کمک به کارمند جهت بهبود فراهم کنید و جلسات پیگیری منظم ترتیب دهید تا پیشرفت‌ها بررسی شود.
نظارت بر پیشرفت بسیار مهم است. بازخورد منظم می‌تواند به کارمند کمک کند تا متوجه شود کجا پیشرفت کرده و کجا هنوز نیاز به کار دارد. به یاد داشته باشید که هدف از PIP مجازات نیست، بلکه حمایت از کارمند در فرایند تغییر و بهبود عملکرد او است.
برای مثال، یک مطالعه موردی را در نظر بگیرید. یکی از مهندسان تیم ما به طور مداوم ضرب‌الاجل‌ها را از دست می‌داد و بلیط‌ها را به عنوان “تمام شده” علامت‌گذاری می‌کرد که بعداً از طرف QA به عنوان کارهای ناتمام باز می‌گشت. ما یک PIP اجرا کردیم و انتظارات روشن و قوانینی سخت‌گیرانه برای تغییر رفتار او تعریف کردیم. جلسات منظم پیگیری به او کمک کرد که در مسیر باقی بماند و طی چند ماه، عملکردش به طور قابل توجهی بهبود یافت. درس‌های کلیدی؟ رسمی کردن این فرایند — بسیار مفید است. مثل دریافت جریمه پلیس؛ مردم معمولاً وقتی متوجه می‌شوند که وضعیت جدی‌تر شده است، واکنش نشان می‌دهند.
زمانی برای افزایش مشکل
گاهی اوقات، علی‌رغم بهترین تلاش‌های شما، ممکن است یک مشکل نیاز به افزایش درجه داشته باشد. این می‌تواند به دلیل مشکلات مداوم عملکردی، رفتار نادرست جدی یا اگر رفتار کارمند تأثیر منفی بر تیم بگذارد (مثل محرک تعارض) باشد.
مستندسازی مسئله بسیار مهم است. سوابق مشکلات عملکردی، مراحل انجام شده برای رسیدگی به آن‌ها و واکنش کارمند را نگهداری کنید. این مستندات می‌تواند تصویری واضح از مشکل و تلاش‌های انجام شده برای حل آن ارائه دهد.
هنگام افزایش مشکل، از دستورالعمل‌های سازمان خود پیروی کنید. این ممکن است شامل صحبت با منابع انسانی یا مدیریت ارشد باشد. به یاد داشته باشید که افزایش مشکل به معنای شکست شما به عنوان یک مدیر نیست. این یک قدم به سوی حل مسئله‌ای است که از کنترل شما خارج شده است. هدف آن اطمینان از ایجاد یک محیط کاری مثبت و تولیدی برای کل تیم است.
زمانی برای جدایی
یک زمان خواهد رسید که علی‌رغم تمام تلاش‌ها برای بهبود وضعیت، روشن می‌شود که کارمند برای تیم یا سازمان مناسب نیست. این یک درک دشوار است و باید با دقت و جدیت به آن نگاه کرد.
اخراج باید زمانی در نظر گرفته شود که رفتار یا عملکرد کارمند به طور مداوم و به طور قابل توجهی زیر انتظارات باشد، علی‌رغم بازخوردهای مکرر، مربی‌گری و حمایت‌ها. دلایل دیگر ممکن است شامل رفتار نادرست شدید یا ناهماهنگی آشکار با ارزش‌ها یا فرهنگ شرکت باشد.
اخراج آخرین راه‌حل است و باید تنها زمانی در نظر گرفته شود که تمام گزینه‌های دیگر به پایان رسیده باشد. این تصمیم می‌تواند تأثیر زیادی بر فرد و تیم بگذارد، بنابراین مهم است که با دقت و احترام به آن پرداخته شود.
فرآیند باید شفاف، منصفانه و شفاف باشد. باید کارمند را در یک جلسه خصوصی و رو در رو از تصمیم آگاه کنید و دلایل اخراج را به وضوح توضیح دهید. حتی اگر فکر می‌کنید آن‌ها “کارمند بدی” هستند، باید با احترام و کرامت با آن‌ها برخورد کنید. در صورت امکان از آن‌ها حمایت کنید و بازخوردی برای کمک به آن‌ها در شغل‌های آینده‌شان ارائه دهید.
مدیریت کارمندان دشوار تنها به رسیدگی به عادت‌های مشکل‌ساز محدود نمی‌شود؛ بلکه درک این رفتارها، ارتباط مؤثر و هدایت اعضای تیم به سوی بهبود است.
همه باید فرصت دومی برای بهتر شدن داشته باشند.