مدیریت تیم
هایلایتهای علی امیدیان
این فصل را خواندم و موارد زیر به نظرم برای مدیریت تیمهای فنی مفید و کاربردی بود. هر نکته به بخش مرتبط در متن لینک شده است. برای کاملتر شدن مسیر مطالعه، فصل ۴؛ ساختن تیم و فصل ۵؛ مصاحبه و آنبوردینگ نیز ادامه طبیعی این موضوع هستند.
- در تیم، «من» وجود ندارد. 💡 موفقیت تیم از اولویت دادن به نتیجه جمعی بر اعتبار فردی شروع میشود.
- کار تیمی رؤیا را عملی میکند. 💡 همکاری، ایده را به نتیجهای تبدیل میکند که یک نفر بهتنهایی به آن نمیرسد.
- در اتحاد قدرت است. 💡 همراستایی افراد، توان پراکنده را به نیرویی مؤثر تبدیل میکند.
- هیچکدام از ما به اندازه همه ما باهوش نیست. 💡 تنوع تجربه و زاویه دید، کیفیت تصمیمهای تیم را بالاتر میبرد.
- تیم: با هم، همه بیشتر دستاورد میآورند. 💡 ارزش تیم در دستاوردی است که اعضا با همکاری یکدیگر میسازند.
- کار تیمی همان چیزی است که افراد معمولی را قادر به نتایج غیرمعمول میکند. 💡 ساختار و همکاری درست میتواند ظرفیت افراد معمولی را چند برابر کند.
- با این حال، برای اهداف این کتاب، روی هدفها و دلایلی تمرکز میکنیم که برای موفق بودن باید از منظر تیمها فکر کنید. دلیل بسیار ساده است: نمیتوانید همه کارها را خودتان انجام دهید. 💡 رهبری مقیاسپذیر با تفویض اختیار و پذیرفتن محدودیت توان فردی آغاز میشود.
- برای موفقیت یک تیم، باید خواستههای خود، مسئولیتهای تیم و خروجی مورد انتظار را روشن کنید. 💡 تیم زمانی مستقل عمل میکند که مسئولیت، انتظار و خروجی آن شفاف باشد.
- تیم موجودیتی است که باید خروجی مشخصی تولید کند، با کیفیت و سطحی از قابلیت اتکا که بتوانید به آن وابسته باشید، چون خروجی آن تیم ورودی فرایند یا سیستم دیگری خواهد بود. تیم خوب تیمی است که بتواند برای خودش فکر کند، مسئولیت لازم را بپذیرد و برای تصمیمگیری مستقل در پی تحقق هدف اصلی خود اختیار داشته باشد. 💡 تیم خوب علاوه بر تحویل خروجی، اختیار تصمیمگیری و مسئولیت نتیجه را هم دارد.
- micromanager کسی است که باید بر تکتک جنبههای افراد زیر دستش نظارت کند، دقیقا شرح دهد چیزی چگونه باید انجام شود، هر گام را بررسی کند و بهطور کلی مزاحم مسیر شود. 💡 ریزمدیریت استقلال را از بین میبرد و مدیر را به گلوگاه تیم تبدیل میکند.
- وقتی به هر یک از تیمهای خود نگاه میکنید، فهرستی از انتظارات و الزاماتی بسازید که از آنها دارید؛ این منشور آنهاست. 💡 منشور تیم مرز مسئولیتها و تعریف موفقیت را برای همه روشن میکند.
- وقتی این منشور را ساختید و فهمیدید، میتوانید بر اساس تجربه خود از آنچه جواب داده، یا اگر شرکت در حال تغییر جهت است و نیاز به تمرکز دوباره دارد، سراغ تغییر بروید. وقتی عضو تازهای به تیم میپیوندد، باید خیلی زود بداند نقش تیمش بهعنوان یک جمع چیست و خودش چه بخشی از آن را تشکیل خواهد داد. بهعنوان یک آزمون کوچک، اگر همین حالا از همه اعضای یک تیم مشخص بپرسید هدفشان را در یک جمله بگویند، چند پاسخ متفاوت میگیرید؟ 💡 همفهمی درباره هدف، آزمون سادهای برای تشخیص تیم واقعی از مجموعهای از افراد است.
- برای موفقیت یک تیم، ابتدا باید هدف داشته باشد. این هدف منشور است. سپس باید منابع لازم برای اجرای آن منشور را داشته باشد. 💡 هدف روشن بدون منابع کافی اجرایی نمیشود؛ منشور و ظرفیت باید کنار هم باشند.
- یک تیم محکم و قوی باید بتواند از دست دادن هر عضو منفردی را تحمل کند، بیآنکه خروجی تیم بهعنوان یک کل آسیب ببیند. 💡 تابآوری تیم یعنی دانش و مسئولیت به یک فرد کلیدی وابسته نماند.
- مواد آنبوردینگ/آموزش: همانند فرایند آنبوردینگ به شرکت، یک تیم باید مواد آنبوردینگ و آموزشی مخصوص خودش را داشته باشد، خاص هدف همان تیم. مثلا اگر این تیم، تیم انتشار باشد، آموزش حول ابزارهای مشخصی خواهد بود که استفاده میکنند، مثلا Jenkins/SonarQube. 💡 آنبوردینگ اختصاصی تیم، زمان رسیدن عضو تازه به بهرهوری را کوتاه میکند.
- پایگاه دانش: این روزها سخت است شرکتی پیدا کنید که نوعی ویکی یا مخزن سند نداشته باشد، هرچند اینکه چقدر خوب نگهداری یا بهروزرسانی میشوند بحث دیگری است. اما پایگاه دانش لازم نیست فقط سند باشد؛ میتواند ویدئو هم باشد، که بسته به حوزهای که میخواهید ثبت کنید گاهی تولید آن سریعتر است. 💡 دانش ثبتنشده با خروج افراد از دست میرود؛ قالب آن میتواند متن یا ویدئو باشد.
- فرایندها/ساختار تعریفشده: برای اینکه تیم کار کند، باید ساختار داشته باشد. ساختار نباید ضمنی یا فرضی باشد، بلکه باید درست مستند و منتقل شود تا همه قواعد را برای رسیدن به نتیجه موفق دنبال کنند. برای تیم توسعه، این میتواند استانداردهای کدنویسی و قالببندی و شیوه استفاده از کنترل نسخه هنگام کار روی تیکتها باشد. 💡 فرایندهای مکتوب، کیفیت اجرا را از حافظه و سلیقه افراد مستقل میکنند.
- بیایید از همان ابتدا این را روشن کنیم: هیچ ساختار کاملی برای تیم ما وجود ندارد. چیزی که برای یک تیم جواب میدهد لزوما برای تیم دیگر جواب نمیدهد. عوامل زیادی وارد تصمیم ساختاری میشوند، از جمله فرهنگ شرکت، شخصیت اعضا، خلقوخوها، اهمیت کار و اینکه آیا درگیری با مشتری وجود دارد یا نه. 💡 ساختار تیم باید متناسب با مسئله، فرهنگ و مرحله رشد سازمان انتخاب شود.
- با دانستن اینکه برای مؤثر بودن نمیتوانید تیمهایی بزرگتر از هفت نفر داشته باشید، باید راهی برای تقسیم و غلبه پیدا کنید که برای گروه شما معنا داشته باشد. 💡 تیمهای کوچکتر ارتباط مؤثرتر و مالکیت روشنتری دارند.
- تلاش برای جا دادن همه در یک سلسلهمراتب مشترک، بیش از آنچه حل کند مشکل ایجاد میکند، چون باید آنقدر چابک باشید که با محیطی پیچیده و در حال تغییر سازگار شوید. 💡 ساختار انعطافپذیر در محیط پیچیده بهتر از سلسلهمراتب یکسان برای همه عمل میکند.
- یکی از مهمترین چیزهایی که باید به آن مسلط شوید این است که چگونه تیم خود را حول ساختاری طراحی میکنید که به افراد اجازه تکامل، رشد و فهمیدن انتظارات را بدهد. یکی از وجوه آن عنوان ساده است؛ تیم خود را چه خواهید نامید؟ اهمیت عنوان را دستکم نگیرید. هرکس هرچقدر هم ادعا کند عنوان برایش مهم نیست، واقعا اهمیت میدهد، حتی اگر جسارت ظاهریاش نگذارد اعتراف کند. عنوان نشان افتخار، دستاورد و بررسی وضعیت پیشرفت حرفهای فرد است. 💡 معماری مسیر شغلی بهاندازه معماری فنی برای حفظ و رشد افراد اهمیت دارد.
- متأسفانه استاندارد یا مقیاس جهانیای وجود ندارد که بتوانیم توانایی افراد را در شرکتهای مختلف بهطور مؤثر مقایسه کنیم. عنوانهایی مانند «Senior» میتوانند از شرکتی به شرکت دیگر طیف گستردهای از مهارتها و ویژگیها را معنا دهند. Senior در یک شرکت ممکن است در شرکت دیگر Junior یا Associate محسوب شود. 💡 عنوان شغلی بدون تعریف سطح و انتظار، معیار قابل اتکایی برای توانایی نیست.
- عنوان مجموعهای از ویژگیها را در خود دارد که هم استنباط میشوند و هم القا. 💡 عنوان هم پیام داخلی دارد و هم انتظاری بیرونی درباره جایگاه فرد ایجاد میکند.
- مسئولیتها 💡 هر عنوان باید محدوده مسئولیت مشخص و قابل سنجشی داشته باشد.
- تجربه 💡 سطح شغلی باید بازتاب تجربه قابل اثبات باشد، نه فقط مدت حضور.
- حقوق 💡 عنوان و جبران خدمات باید با یکدیگر همخوان باشند.
- ارشدیت 💡 ارشدیت با اثرگذاری پایدار و استقلال در عمل سنجیده میشود.
- شناخت صنعتی 💡 عنوانهای استاندارد، جایگاه فرد را برای بازار و همکاران قابل فهم میکنند.
- عنوان سطحی از اطمینان را در شنونده ایجاد میکند. به عنوانهایی فکر کنید که بیرون از صنعت خود میشنویم و بیدرنگ به ما احساس آسودگی میدهند. مثلا آیا هنگام بستن کمربند در هواپیما راحتتر هستید وقتی خلبان خود را «Captain» معرفی میکند، نه «Junior Pilot»؟ نمیخواهیم از هیچ «Junior»ی بشنویم، چون این کمبود تجربه، کمبود ارشدیت و کمبود مسئولیت را القا میکند، در حالی که روی باند حرکت میکنیم و آماده پرتاب به هوا هستیم. 💡 واژههای عنوان شغلی روی اعتماد و برداشت مخاطب اثر مستقیم دارند.
- برخی سازمانهای دیگر از «Director» بهعنوان نشانهای از ارشدیت استفاده میکنند، که میتواند گیجکننده باشد؛ چون در بریتانیا به جای «Chief Executive Officer» از عنوان «Managing Director» استفاده میشود. 💡 معنای عنوانها میان کشورها و سازمانها متفاوت است و باید با دقت انتخاب شود.
- عنوان «Director» در بریتانیا پیامد حقوقی هم دارد، زیرا چنین فردی در اسناد ثبت شرکت، از نظر قانونی بهعنوان یکی از مسئولان و متولیان شرکت ثبت میشود. تجربه را با عنوان اشتباه نگیرید؛ پنج سال کار کردن در سطح Junior، کسی را Senior نمیکند. 💡 پیش از اعطای عنوان، پیامد حرفهای و حتی حقوقی آن را بررسی کنید.
- ترفیع بیش از حد سریع: ترفیعها باید کم و با فاصله باشند و هرگز نباید در نتیجه یک برد یا رویداد منفرد انجام شوند. 💡 ترفیع باید نتیجه عملکرد پایدار باشد، نه واکنش به یک موفقیت مقطعی.
- عنوان به جای افزایش حقوق: وقتی باید به کسی پاداش دهید اما بودجه ندارید، تغییر عنوان وسوسهانگیز است. همه کاری که این میکند این است که به او دلیلی میدهد تا دنبال نقشهایی با عنوان مشابه و پولی که باید بگیرد بگردد. نمیتوانید به یک Senior همان حقوقی را بدهید که به یک Junior میدهید. 💡 عنوان جای افزایش حقوق را نمیگیرد و ناهماهنگی آن ریسک خروج فرد را بیشتر میکند.
- پاداش دادن به طول خدمت با عنوان: فقط چون کسی ۲۰ سال با شرکت بوده، اگر معیارها را برآورده نکرده باشد خودبهخود Senior نمیشود. این موضوع ارتباط نزدیکی با افزایش پیوسته حقوق کسی دارد فقط چون بهموقع حاضر شده است. هر دو نتیجه مشکلات بزرگی ایجاد میکنند و یکی از رایجترین مشکلاتی هستند که CTOهای تازهکار به ارث میبرند. 💡 وفاداری ارزشمند است، اما ارتقا همچنان باید بر معیارهای روشن تکیه کند.
- بیش از حد هوشمندانه بودن با عنوانها: هرچقدر هم وسوسهانگیز باشد، به عنوانهایی بچسبید که در صنعت شناختهشدهاند. این کار نه تنها جذب نیرو را آسانتر میکند، بلکه به تیم فعلی خودتان هم حس تعلق به جامعهای بزرگتر میدهد و برای مشتریان قابل فهم است. 💡 عنوانهای شناختهشده جذب نیرو و درک جایگاه افراد را سادهتر میکنند.
- اگر تیمهای موجود را به ارث میبرید، غیرمعمول نیست که برخی مدیران تیم شما مهارتهای مدیریتی کم داشته باشند یا آموزش رسمی ندیده باشند. آنها در حین کار یاد گرفتهاند و احتمالا تا حد زیادی سبک خود را بر تنها چارچوب مرجع واقعیشان مدل کردهاند: رئیس خودشان. حالا آن رئیس شما هستید. شیوه مدیریت شما، امیدوارانه، بهعنوان راهنمایی برای دیگران دیده خواهد شد. این را در ذهن داشته باشید، بهویژه وقتی روزگار سخت یا پراسترس است، چون هر کاری که میکنید به یاد سپرده و هنگام مدیریت تیمهایشان کپی خواهد شد. من همیشه از خودم میپرسم: آیا از کار کردن برای خودم خوشحال میشدم؟ برای ثبت، زمانهایی در مسیر حرفهایام بوده که باید به آن پاسخ منفی میدادم. 💡 رفتار مدیر ارشد الگویی است که مدیران تیم، بهخصوص زیر فشار، از آن کپی میکنند.
- هر تیم ممکن است بسته به نقش کلی خود در گروه شما و تجربه مدیر، قواعد تعامل کمی متفاوت داشته باشد، اما همه باید به مجموعهای مشترک از قواعد پایبند باشند. میتوانید این را به سه سطل تقسیم کنید: چیزهایی که باید بتوانند داخلی مدیریت کنند، مسائلی که باید از آنها آگاه باشید، و در نهایت تصمیمهایی که باید دربارهشان نظر بدهید و تصمیم نهایی بگیرید. 💡 قواعد تصمیمگیری باید مشخص کنند چه چیزی مستقل، اطلاعدادنی یا نیازمند تأیید است.
- مهم است چارچوب درست را به لیدهای تیم خود بدهید و آن تعادل سطح جزئیات موردنیاز را پیدا کنید. 💡 گزارش خوب جزئیات کافی برای تصمیم میدهد، بدون آنکه به ریزمدیریت تبدیل شود.
- همیشه گفتهام باید از هر مشکلی که به نارضایتی مشتری یا رخنهها یا نگرانیهای امنیتی مربوط است آگاه شوم، فارغ از ساعت روز. حتی در آن صورت، مطمئن شدم همه تیمم شماره موبایل من را داشته باشند، چون اگر تأیید نکردم ایمیل یا پیامشان را خواندهام، باید با من تماس بگیرند. هرگز نمیخواستم در موقعیتی باشم که CEO درباره چیزی از من بپرسد که هیچ اطلاعی از آن ندارم. 💡 رخدادهای مشتری و امنیت باید مسیر تشدید فوری و بدون ابهام داشته باشند.
- من این قاعده را بهعنوان قاعده خود پذیرفتهام و بر این روش از سوی گزارشهای مستقیم خود اصرار کردهام. همچنین به کسانی که منتظر من هستند این احترام را میگذارم که آنها را در جریان نگه دارم. هرچقدر هم احمقانه به نظر برسد، میخواهم در آغاز و نیمه هر ساعت بهروز شوم. اینگونه برای افراد آسان است که چشمشان به ساعت باشد و لازم نباشد به یاد بیاورند آخرین بهروزرسانی کی بود. لازم نیست زمانبر یا پرجزئیات باشد؛ فقط یادداشتی کوتاه که بگوید کارها هنوز در حال انجام است. 💡 ریتم ثابت بهروزرسانی در بحران، ابهام و پیگیریهای مزاحم را کاهش میدهد.
- این شاخصها باید معنا داشته باشند و صرفا برای تولید چند نمودار بیمعنا نباشند. شاخص خوب شاخصی است که اجازه دهد پیشرفت را به شکل کلنگر ببینید و وارد گزارش کلی شما شود که برای اطلاعرسانی به تیم مدیریت آماده میکنید. 💡 شاخص فقط زمانی ارزش دارد که به تصمیم و درک پیشرفت کمک کند.
- مزیت داده خام این است که ابهام احساسی را از سنجش موفقیت یک تیم مشخص دور میکند. با این حال، یک هشدار: باید در برابر میل به رقابت دادن تیمها با یکدیگر مقاومت کرد، چون به احتمال زیاد دارید سیب را با پرتقال مقایسه میکنید؛ مقایسهای ناعادلانه. 💡 داده قضاوت را دقیقتر میکند، اما مقایسه تیمهای ناهمگون میتواند گمراهکننده باشد.
- جمعآوری شاخصها برای لیدهای تیم باید نسبتا آسان باشد و هر بار که آنها را برای شما جمع میکنند، خودش به پروژهای جداگانه تبدیل نشود. شاخص خوب به احتمال زیاد از ابزار اصلیای بیرون میآید که تیم استفاده میکند، مثلا JIRA، SonarQube یا Jenkins. 💡 اندازهگیری باید تا حد ممکن از ابزارهای روزمره تیم بهصورت خودکار استخراج شود.
- ماشین خوب روغنکاریشده ماشینی است که همه قطعات آن هماهنگ کار میکنند و جمعا خروجی لازم برای موفقیت موتور را تولید میکنند. تیم هم تفاوتی ندارد؛ باید با پیشبینیپذیری و کارایی عمل کند تا گروه شما بهعنوان یک کل کار کند. برای اینکه این اتفاق بیفتد، لیدهای تیم باید نسبت به خروجی خود پاسخگو باشند و مسئولیت کمبودها یا شکستهای خود را بپذیرند و بردهایشان را با هم جشن بگیرند. 💡 پاسخگویی مشترک، هماهنگی اجزای تیم و پیشبینیپذیری خروجی را تقویت میکند.
- تیمی که هدف ندارد هرگز نمیداند آیا از انتظارات شما عقب است یا فراتر رفته. 💡 بدون هدف و معیار، تشخیص عملکرد ضعیف یا فراتر از انتظار ممکن نیست.
- وقتی آن شاخصها توافق، اندازهگیری و ارزیابی شدند، میتوانید در جلسهها گفتوگوهای معنادار داشته باشید؛ یا درباره بهبود عملکرد یا درباره ایجاد معیارهای مرجع تازه برای سنجش. در همه سطوح گشودگی و صداقت را تشویق کنید. این به آن معنا نیست که دنبال «قربانی» هستید تا وقتی چیزی خراب شد همه تقصیرها به او نسبت داده شود. شما تیمی از تیمها هستید، و برای موفقیت یک تیم، به کانال ارتباطی خوب و محکمی نیاز دارید که بر اعتماد و احترام بنا شده باشد، تا اگر بدترین اتفاق افتاد، هیچکس از آوردن خبر بد نزد شما نترسد یا مرعوب نشود. 💡 شاخصهای توافقشده گفتوگو را از سرزنش به سمت یادگیری و بهبود میبرند.
- پاسخگویی به این معنا نیست که همه خطاها یا مسائل بخشیده میشوند و زندگی ادامه پیدا میکند. پاسخگویی یعنی مسئولیت خطا را پذیرفتن، رسیدن به ریشه مشکل، و گذاشتن رویهها، فرایندها و حتی ابزارهای لازم برای جلوگیری از تکرار آنها. اگر چیزی تغییر نکند یا بارها و بارها تکرار شود، آنگاه پاسخگویی یعنی حذف افراد مسئول از آن جایگاه و گذاشتن کسانی که میتوانند تفاوت ایجاد کنند. این مسئولیت شما بهعنوان رهبر گروهی از تیمهاست. کافی نیست انگشت اتهام را به سوی مدیری ضعیف بگیرید. او مدیر شماست؛ تصمیم شماست که او را در نقش نگه دارید و مسئولیت شماست که منتورینگ و راهنمایی لازم را بدهید تا مطمئن شوید همه فرصتهای موفقیت را دارد. شکست او شکست شماست، و سایهای بر همه خانههای شما میاندازد. CEO شما را زیر نظر خواهد داشت و مدیریت خواهد کرد، و اگر احساس کند دیگر نمیتوانید تیم خود را مدیریت کنید، شما را جایگزین خواهد کرد. 💡 پاسخگویی واقعی یعنی پذیرش خطا، رفع علت ریشهای و جلوگیری از تکرار آن.
- پاسخگو نگه داشتن تیم یعنی آنها را به شاخصها و مسئولیتهایی پایبند نگه دارید که هنگام پذیرش نقش تعهد کردهاند. این یعنی تیمهایتان را برای موفقیت آماده کنید. موفقیت آنها موفقیت شماست. 💡 وظیفه رهبر فراهم کردن شرایط موفقیت و سپس سنجیدن تیم بر اساس تعهدهای روشن است.
- از میان همه جلسههایی که کمکم وارد تقویم شما میشوند، یکی که هرگز نباید عقب بیفتد یا لغو شود جلسه کلاسیک یکبهیک است. 💡 جلسه یکبهیک یکی از مهمترین سرمایهگذاریهای مدیر روی رابطه و رشد افراد است.
- از این جلسههای یکبهیک بهعنوان راهی برای ساختن اعتماد و ارائه منتورینگ و خرد خود استفاده کنید، در قالبی که حامیانه باشد و تحقیرآمیز یا موعظهگرانه به نظر نرسد. 💡 یکبهیک باید فضای اعتماد، شنیدن و منتورینگ باشد، نه سخنرانی مدیر.
- عقب نماندن از روندها، ابزارها و فرایندها خواسته نیست، ضرورت است. بهعنوان رهبر گروه خود، بر عهده شماست که تیم خود را با تازهترین اطلاعات آموزشدیده و آماده نگه دارید تا نه تنها بهرهوری بهتر ارائه دهند و پلتفرم شما را مدرن نگه دارند، بلکه ارزشمندی و عزتنفس نیز به دست آورند. 💡 یادگیری مداوم برای تیم فناوری هزینه جانبی نیست؛ شرط مرتبط ماندن است.
- همیشه خوب است همتایان خود را در منطقه محلی که روی همان فناوریها کار میکنند بشناسید، تا اگر به مشکلی برخوردند یا به مشورتی نیاز داشتند، بتوانند تماس بگیرند و گفتوگو کنند. 💡 شبکه حرفهای محلی امکان تبادل تجربه و حل سریعتر مسئله را فراهم میکند.
- شفافیت یعنی آنقدر محترم و سنجیده باشید که زمان بگذارید و اطلاعات را به شکلی پیشدستانه منتقل کنید. 💡 شفافیت یعنی اطلاعات لازم را پیش از آنکه دیگران مجبور به پیگیری شوند منتقل کنید.
- جاستین مارکوارت، شریک شرکت سرمایهگذاری خصوصی New Harbor Capital، موجز میگوید: «مهمتر از همه، آنها [CTOها] ارتباطگران قویای هستند، که هم برای تیم خود، هم برای رهبران ارشد دیگر و هم برای هیئتمدیره بهطور مؤثر توضیح میدهند آن نقشهراه چگونه با ابتکارهای راهبردی شرکت همراستا است، از جمله توانایی بالا آمدن از جزئیات فناوری زیربنایی برای انتقال اینکه ابتکارهای مختلف چگونه با هدفهای اصلی کسبوکار به هم مربوط میشوند.». 💡 CTO باید بتواند پیام را هم برای تیم فنی و هم برای مدیران کسبوکار روشن بیان کند.
- موضوعات زیر نامزدهای خوبی برای ایمیل سراسری گروه هستند: 💡 ایمیل سراسری برای پیامهایی مناسب است که همه باید نسخهای یکسان از آن بدانند.
- استخدامها/افزودهشدنها به گروه: معرفی سریع فردی که میپیوندد، همراه با خلاصهای کوتاه از دستاوردهایش، نقشی که خواهد داشت و زمانی که خواهد پیوست. همیشه بهتر است این ایمیل پیش از رسیدن فرد ارسال شود تا افراد نسبت به چهره تازه پذیراتر باشند. 💡 معرفی درست عضو تازه، نقش و جایگاه او را از روز اول برای گروه روشن میکند.
- خاتمه همکاری/استعفا: به گروه اطلاع دهید کسی چه زمانی میرود، شامل تاریخ. دیگران را دعوت کنید در آرزوهای خوب شما برای آینده او شریک شوند. حتی در خاتمه همکاری، بهترینها را برایشان بخواهید. جملههایی مانند «ما دوطرفه توافق کردهایم که مسیر مشترکمان به پایان رسیده است» تمام چیزی است که لازم است بگویید، بدون ورود به جزئیاتی که ممکن است حساس باشد. اگر برای نقشی بهتر میروند، این واقعیت را جشن بگیرید که همه شما در گام حرفهای او نقشی داشتهاید. 💡 اطلاعرسانی محترمانه خروج افراد از شایعه و ابهام در تیم جلوگیری میکند.
- اعلانهای شرکت: برای هر اعلان گسترده شرکت که به اشتراک گذاشته شده، گاهی نیاز به ارتباط پیگیری از سوی شماست که کمک کند معنای آن برای گروه شما بهطور مشخص زمینهمند شود. 💡 رهبر باید اثر اعلانهای کلان شرکت را برای تیم خودش ترجمه و روشن کند.
- همچنین هر شکست یا لغزش باید بدون انگشت اتهام برجسته شود، همراه با راهکارهایی که برای جلوگیری از تکرار در آینده اجرا میکنید. 💡 بیان شکست بدون مقصرسازی، زمانی مفید است که اقدام اصلاحی مشخصی همراهش باشد.
- بهترین توصیهای که از منتور فقیدم، Jeremy Geelan، روزنامهنگار، تهیهکننده BBC و ناشر، گرفتم این بود که طوری بنویسم انگار قرار است منتشر شود و برای همیشه بماند. پیش از فشردن Send، پس از بازخوانی، آیا خوشحال میشوید این متن دوباره چاپ شود؟ این آزمون ساده اما مؤثری است، چون هر بار که ایمیلی میفرستم صدای او را میشنوم که این را از من میپرسد؛ و بارها لحن را بازبینی و ویرایش کردهام. 💡 هر پیام کاری را طوری بنویسید که اگر عمومی شد همچنان دقیق و حرفهای باشد.
- از صدای طبیعی خود استفاده کنید؛ تلاش نکنید بیش از حد رسمی باشید. 💡 لحن طبیعی و روشن اعتماد بیشتری از رسمینویسی تصنعی ایجاد میکند.
- این جلسهای است برای اینکه به کل گروه خود بگویید اوضاع چگونه پیش میرود. جلسه مهندسی جلسهای است که یا هفتگی یا دوهفتهیکبار زمانبندی میشود و نباید بیش از ۳۰ دقیقه طول بکشد. موضوعات شامل جشن گرفتن انتشارهای بزرگ، جذب یا از دست دادن مشتری، بهبودهای فرایندی و تغییرات ساختاری است. قالب باید نسبتا ثابت باشد تا افراد به چیزی که باید انتظار داشته باشند عادت کنند. نگه داشتن آن در ۳۰ دقیقه به تیم شما اجازه میدهد خسته نشود و احساس کند هر جلسه ارزش وقتشان را برای گرد آمدن دارد. 💡 جلسه مهندسی باید ریتم ثابت، دستور روشن و گزارشی قابل فهم از وضعیت گروه داشته باشد.
- لپتاپها فقط برای ارائه استفاده میشوند؛ هنگام بررسی ایمیل یا پیامها خیلی آسان است به عامل حواسپرتی تبدیل شوند. 💡 حذف ابزارهای حواسپرتی، کیفیت حضور و تصمیمگیری در جلسه را بالا میبرد.
- صرفا رد کردن کسی یا گوش دادن به او در حالی که هنوز روی صفحهکلید تایپ میکنید بدترین کاری است که میتوانید انجام دهید. 💡 توجه کامل هنگام گفتوگو سادهترین نشانه احترام و در دسترس بودن مدیر است.
- تشویق و ترویج جلسههای فردی یکبهیک به شما فرصت میدهد با افراد روی مهارتهای نرمترشان کار کنید. 💡 یکبهیک منظم فرصتی برای رشد مهارتهای نرم و حل مسائل پیش از بزرگ شدن آنهاست.
این فصل پوشش میدهد
- ساختن تیمهای معنادار
- انواع مختلف ساختارهای تیمی
- آموزشدیده و بهروز نگه داشتن تیم
- کانالهای ارتباطی برای تیمها
- قواعد و ساختار برای انواع سبکهای جلسه
عبارتها و جملههای کوتاه هوشمندانه زیادی درباره تیمها و قدرتشان، همراه با تصویری الهامبخش پشتشان، دیوارهای بسیاری را تزئین کردهاند؛ مانند موارد زیر:
- در تیم، «من» وجود ندارد.
- کار تیمی رؤیا را عملی میکند.
- در اتحاد قدرت است.
- هیچکدام از ما به اندازه همه ما باهوش نیست.
- تیم: با هم، همه بیشتر دستاورد میآورند.
- کار تیمی همان چیزی است که افراد معمولی را قادر به نتایج غیرمعمول میکند.
هرچند بعضی از آنها کلیشهای و سادهلوحانهاند، نباید خیلی سریع از مقدار زیادی حکمت و حقیقت در آنها گذشت. یک تیم خوب میتواند به هر چیزی که برایش هدفگذاری کند برسد، و این وظیفه شماست که بهعنوان CTO تیمهایی بسازید و رهبری کنید تا برای مشتریان و کسبوکار شما موفقیت ایجاد کنند. کتابهای مدیریتی زیادی در طول سالها درباره انتخاب و مدیریت تیم ایدهآل نوشته شدهاند، و باید در ادامه مسیر حرفهای خود آنها را به کتابخانهتان اضافه کنید. با این حال، برای اهداف این کتاب، روی هدفها و دلایلی تمرکز میکنیم که برای موفق بودن باید از منظر تیمها فکر کنید. دلیل بسیار ساده است: نمیتوانید همه کارها را خودتان انجام دهید.
۶.۱ منشور
برای موفقیت یک تیم، باید خواستههای خود، مسئولیتهای تیم و خروجی مورد انتظار را روشن کنید. انتخاب تیم بیشباهت به ارزیابی یک نرمافزار نیست. شما انتظار دارید یک نرمافزار کار یا مجموعهای از کارهای مشخص را انجام دهد، تا آزاد باشید روی خروجی تمرکز کنید و با آن کاری خلاقانه انجام دهید. تصور کنید هر بار که Microsoft Excel را برای مرور بودجه خود باز میکنید، باید پایگاه کد را مدیریت کنید، آن را دستکاری و کامپایل کنید، و تازه بعد بتوانید اعدادتان را ببینید. تیم موجودیتی است که باید خروجی مشخصی تولید کند، با کیفیت و سطحی از قابلیت اتکا که بتوانید به آن وابسته باشید، چون خروجی آن تیم ورودی فرایند یا سیستم دیگری خواهد بود. تیم خوب تیمی است که بتواند برای خودش فکر کند، مسئولیت لازم را بپذیرد و برای تصمیمگیری مستقل در پی تحقق هدف اصلی خود اختیار داشته باشد.
هشدار: نفرین micromanager
micromanager کسی است که باید بر تکتک جنبههای افراد زیر دستش نظارت کند، دقیقا شرح دهد چیزی چگونه باید انجام شود، هر گام را بررسی کند و بهطور کلی مزاحم مسیر شود. بیشتر افراد این ویژگی را در خودشان تشخیص نمیدهند و در عوض آن را شیوه خود برای حفظ کیفیت توجیه میکنند. هنگام مشاوره با شرکتهای سرمایهگذاری خصوصی با بسیاری از این افراد برخورد میکنم، و در نهایت اگر نتوانند از سر راه خودشان کنار بروند، باید رهایشان کنیم، چون گلوگاه مقیاسپذیری هستند و همیشه آسیب بزرگی به روحیه تیم میزنند.
وقتی به هر یک از تیمهای خود نگاه میکنید، فهرستی از انتظارات و الزاماتی بسازید که از آنها دارید؛ این منشور آنهاست. این بیانیه وجود تیم را توجیه میکند و توضیح میدهد چگونه به موفقیت کلی گروه کمک خواهد کرد. سپس رهبر تیم باید برنامهای برای تحقق آن منشور ارائه کند، شامل هر منبع، بودجه و ابزاری که برای رسیدن به هدف نیاز دارد. آن منشور باید روشن و مختصر باشد و لازم نیست بسیار طولانی باشد، حتی اگر لازم شد مجموعهای از نکات فهرستی، و باید در دسترس همه افراد گروه شما باشد. به این ترتیب، همه میدانند در سازمان مهندسی بزرگتر شما چه نقشی دارند. در نهایت، و مهمتر از همه، آن رهبر را رها کنید تا کارش را انجام دهد و اجرای منشور را پیش ببرد. همانطور که بعدا بحث خواهیم کرد، اگرچه پاسخگو خواهد بود، حمایت و راهنمایی لازم را دریافت میکند تا موفق شود.
تصویرسازی کنید
مثل یک ژنرال که راهبردهای نبرد طراحی میکند، من از آدمکهای LEGO روی یک برگه بزرگ کاغذ استفاده میکنم تا ببینم میخواهم تیمهایم چگونه ساخته شوند و خطوط مسئولیت میان آنها چگونه باشد. واقعا بین هرکدام خط میکشم و یادداشت مینویسم. این تکنیک تصویرسازی اجازه میدهد سریع ببینم آیا چیزی را جا انداختهام یا در حوزهای بیش از حد ظرفیت گذاشتهام. اما یک نکته کوچک: اگر از مجموعه LEGO مربوط به Star Wars استفاده میکنید، Darth Vader را کنار بگذارید؛ هیچکس نمیخواهد به آن نقش منصوب شود.
اگر دپارتمانی را به ارث ببرید، به احتمال زیاد تیمهای جاافتادهای خواهید داشت که احتمالا منشور رسمی ندارند. در این وضعیتها باید زمان بگذارید تا یاد بگیرید و کشف کنید هر تیم چه میکند و برای آن منشور بسازید. آخرین کاری که میخواهید انجام دهید این است که پیش از درک واقعی اینکه چرا چیزها اینگونهاند، شروع به تغییر دادن کنید. وقتی این منشور را ساختید و فهمیدید، میتوانید بر اساس تجربه خود از آنچه جواب داده، یا اگر شرکت در حال تغییر جهت است و نیاز به تمرکز دوباره دارد، سراغ تغییر بروید. وقتی عضو تازهای به تیم میپیوندد، باید خیلی زود بداند نقش تیمش بهعنوان یک جمع چیست و خودش چه بخشی از آن را تشکیل خواهد داد. بهعنوان یک آزمون کوچک، اگر همین حالا از همه اعضای یک تیم مشخص بپرسید هدفشان را در یک جمله بگویند، چند پاسخ متفاوت میگیرید؟ اگر همه چیزی کاملا متفاوت بگویند، شما تیم ندارید؛ مجموعهای از افراد دارید که حقوق میگیرند. منشور به تمرکز همه کمک میکند.
۶.۱.۱ دانش
برای موفقیت یک تیم، ابتدا باید هدف داشته باشد. این هدف منشور است. سپس باید منابع لازم برای اجرای آن منشور را داشته باشد. این مسئولیت شما و مدیر تیم است که آن را مشخص و مذاکره کنید. با پیشروی تیم، تجربه کسب میکند و دانش میسازد. این دانش باید بهگونهای ثبت شود که اعضای جدید بتوانند از آن بهره ببرند و در نقش خود بهعنوان مشارکتکننده در گروه مؤثرتر باشند. بیش از حد پیش میآید که تیم حول قدرت یک فرد متمرکز میشود و آن فرد همه اطلاعات را در اختیار دارد، شاید بدون تقصیر خودش. بنابراین اگر آن فرد برود، تیم زیان بزرگی میبیند. یک تیم محکم و قوی باید بتواند از دست دادن هر عضو منفردی را تحمل کند، بیآنکه خروجی تیم بهعنوان یک کل آسیب ببیند. برای اینکه دانش یک تیم ثبت، نگهداری و قابل استفاده باشد، باید ضرورتهای زیر را داشته باشد:
- مواد آنبوردینگ/آموزش: همانند فرایند آنبوردینگ به شرکت، یک تیم باید مواد آنبوردینگ و آموزشی مخصوص خودش را داشته باشد، خاص هدف همان تیم. مثلا اگر این تیم، تیم انتشار باشد، آموزش حول ابزارهای مشخصی خواهد بود که استفاده میکنند، مثلا Jenkins/SonarQube.
- پایگاه دانش: این روزها سخت است شرکتی پیدا کنید که نوعی ویکی یا مخزن سند نداشته باشد، هرچند اینکه چقدر خوب نگهداری یا بهروزرسانی میشوند بحث دیگری است. اما پایگاه دانش لازم نیست فقط سند باشد؛ میتواند ویدئو هم باشد، که بسته به حوزهای که میخواهید ثبت کنید گاهی تولید آن سریعتر است.
- فرایندها/ساختار تعریفشده: برای اینکه تیم کار کند، باید ساختار داشته باشد. ساختار نباید ضمنی یا فرضی باشد، بلکه باید درست مستند و منتقل شود تا همه قواعد را برای رسیدن به نتیجه موفق دنبال کنند. برای تیم توسعه، این میتواند استانداردهای کدنویسی و قالببندی و شیوه استفاده از کنترل نسخه هنگام کار روی تیکتها باشد.
صرفا کنار هم گذاشتن گروهی از افراد و گفتن اینکه آنها تیم هستند هرگز جواب نمیدهد. باید ابزارها و ساختار لازم برای موفقیت را به آنها داد.
۶.۱.۲ نمونه منشور
منشور لازم نیست طولانی، پیچیده یا پرجزئیات باشد. فقط باید در سطح بالا، هدف کامل تیم را منتقل کند. نمونه زیر منشوری برای تیم پشتیبانی یک محصول آنلاین است:
- هدف: ارائه پشتیبانی زنده به کاربران نهایی برای هر چیزی که به تجربه کاربری آنلاین مربوط است، از جمله کمک به
مدیران حساب در مسائل اولیه آنبوردینگ.
- تیم مسئول هر تغییر دادهای است که ممکن است لازم شود، اما برای رفع باگ یا افزودن ویژگی هیچ تغییری در کد انجام نمیدهد. آنها مسئول ثبت تیکتهای باگ/ویژگی برای تیم توسعه هستند.
- مشتری: هر کاربر محصول، شامل کاربران داخلی و خارجی
- منابع
- پایگاه دانش ساختارهای داده داخلی از طریق ویکی داخلی
- دسترسی فقطخواندنی به مخازن داده تولید
- دسترسی ارتقایافته به مخازن داده تولید برای افراد کلیدی
- الزامات مهارتی
- آشنایی با وب، شامل سیستمهای ویدئو/چت آنلاین
- مهارتهای قوی در ارتباطات نوشتاری و شفاهی
- مهارتهای SQL
- شاخصهای کلیدی
- زمان تا بستهشدن موارد حلوفصل
- کل تعاملها در یک دوره مشخص
۶.۲ ساختار تیم
بیایید از همان ابتدا این را روشن کنیم: هیچ ساختار کاملی برای تیم ما وجود ندارد. چیزی که برای یک تیم جواب میدهد لزوما برای تیم دیگر جواب نمیدهد. عوامل زیادی وارد تصمیم ساختاری میشوند، از جمله فرهنگ شرکت، شخصیت اعضا، خلقوخوها، اهمیت کار و اینکه آیا درگیری با مشتری وجود دارد یا نه. شکل سنتیتر مدیریت، برگرفته از دنیای نظامی، ساختار سلسلهمراتبی است؛ جایی که یک رهبر یا مدیر وجود دارد و یک یا چند عضو برای جهتگیری و راهنمایی به او نگاه میکنند. ساختار محبوب دیگر، بهویژه در شرکتهای سنگین از نظر فناوری، ساختاری تختتر است؛ جایی که هر عضو مسئولیت شخصی بیشتری میگیرد و انتظار میرود بدون اینکه به او گفته شود بداند چه باید کرد. اگرچه رایج نیست، بهویژه برای تیمهای مهندسی بزرگتر غیرمعمول نیست که انواع مختلف ساختار برای تیمهای داخلی داشته باشند. مثلا تیم پشتیبانی شاید با یک مدیر واحد که بر همه نظارت میکند بهترین کارکرد را داشته باشد، در حالی که تیم پژوهش میتواند کمی غیررسمیتر باشد. برنامههای محبوب تلویزیون واقعنما، مانند Survivor در ایالات متحده یا The Apprentice در بریتانیا، با پیکربندیها و شخصیتهای مختلف بازی میکنند تا تعارض و درام بسازند، همه به نام سرگرمی. اما اگر به ساختاری که برای گروه شما بهترین کارکرد را خواهد داشت فکر و توجه کافی ندهید، تعارض واقعی است. وقتی شروع به فکر کردن درباره ساختار میکنید، بیایید به دو نقطه داده فکر کنیم که میتوانید آنها را تغییرناپذیر بدانید. اولی که کاملا روشن است: فقط یک CTO وجود دارد، یعنی شما، و آن فرد مسئول هر کاری است که گروه شما انجام میدهد، چه خوب و چه بد. ساختار شما باید به شما دید و شفافیت بدهد تا هرگز غافلگیر نشوید. دومی بیشتر محدودیتی لجستیکی است که از سالها تجربه مدیریت در همه صنایع زاده شده است: بیش از پنج تا هفت گزارش مستقیم عملی نیست. گزارش مستقیم کسی است که برای جهتگیری، راهنمایی، منتورینگ و رهبری کلی به شما نگاه میکند. برای مؤثر بودن و اینکه بیش از حد پراکنده نشوید، اغلب حد هفت ذکر میشود. اگر گروه جوانی هستید و تازه شروع کردهاید، شاید هفت نفر در گروه خود نداشته باشید، پس شاید هنوز این نگرانی را حس نکنید. برای آینده فکر کنید. طوری برنامهریزی کنید که انگار اکنون دو برابر اندازه فعلی هستید.
استثناها: تیمهای بزرگتر
البته عدد هفت بیشتر راهنماست تا قانونی سخت و قطعی. جایی که این قانون اغلب شکسته میشود تیمهای پشتیبانی و تست است. این تیمها میتوانند تعداد زیادی از افراد در سطحی مشابه داشته باشند که همگی وظیفهای مشابه انجام میدهند و واقعا به مدیریت روزمره بسیار کمی نیاز دارند. حتی در آن صورت، مدیری که مسئول تیم بزرگتر میشود باید تجربه لازم برای مدیریت این تیم بزرگتر را داشته باشد و به احتمال زیاد از پیشینه فنی نخواهد بود.
با دانستن اینکه برای مؤثر بودن نمیتوانید تیمهایی بزرگتر از هفت نفر داشته باشید، باید راهی برای تقسیم و غلبه پیدا کنید که برای گروه شما معنا داشته باشد. بیایید به چند شیوه سازماندهی تیمها نگاه کنیم.
۶.۲.۱ محصولمحور
اگر یک یا چند محصول تولید میکنید، چیدن تیمها در خطوط محصول ممکن است منطقی باشد. هر خط محصول مجموعهای از زیردپارتمانهای خود را خواهد داشت، مانند توسعه، تست و پشتیبانی، که هرکدام توسط مدیران جداگانه اداره میشوند و به یک مدیر واحد گزارش میدهند، و او سپس به شما گزارش میدهد. این سناریویی رایج برای شرکتهایی است که یک یا چند محصول جاافتاده دارند، با چرخه عمر و نیازمندیهای محصولی خودشان. برای دانستن اینکه آیا این ساختار گزینهای برای شماست یا نه، از خود بپرسید آیا هر یک از شرایط زیر درست است:
- استکهای فناوری متفاوت
- پایگاههای مشتری بدون همپوشانی
- چرخههای انتشار مستقل
- مسائل پشتیبانی منحصربهفرد و چالشبرانگیز
- اختلافهای درآمدی چشمگیر
این ساختار باید مانند یک مینیاکوسیستم درون گروه بزرگتر کار کند و به هرکدام اجازه دهد مستقل به پایگاه کاربران خود خدمت کند، بدون اینکه بر دیگران اثر بگذارد. این مدل همچنین راهبرد خوبی است اگر هدف بلندمدتتر ادغام یا یکپارچهسازی محصول با خط دیگری باشد، چون اجازه میدهد در حالی که پشت صحنه برای مهاجرت برنامهریزی میکنید، همچنان به پایگاه مشتری خدمت کنید.
۶.۲.۲ چرخهعمرمحور
این احتمالا محبوبترین مدلی است که شرکتهای تولیدکننده نرمافزار داخلی استفاده میکنند؛ جایی که ساختار مانند خط مونتاژ کارخانه چیده میشود و هر دپارتمان مسئول بخشی از چرخه عمر محصول در زمان نگهداری و ساخت آن است. مثلا میتوانید تیم توسعه، تیم تست، تیم انتشار، تیم DevOps/زیرساخت و در نهایت تیم پشتیبانی داشته باشید. هر یک از این تیمها توسط مدیری اداره میشود که سپس مستقیم به شما گزارش میدهد. این مدل زمانی روان کار میکند که SDLC یا چرخه عمر توسعه نرمافزار در سازمان شما خوب تعریف شده و رعایت شود. احتمالا وقتی تازه شروع میکنید، اعضای تیم نقشهای مختلف زیادی را همزمان انجام میدهند. با این حال زمانی خواهد رسید که برای خدمت کامل به هر حوزه به منابع اختصاصی با مهارتهای عمیقتر نیاز خواهید داشت. آن زمان، آنها را به تیمی جداگانه با دامنه مسئولیتهای خودشان تبدیل میکنید.
۶.۲.۳ مشتری/عمودیمحور
صنعت شما ممکن است حول چند مشتری بزرگ یا بازار عمودی متمرکز باشد که هر کدام مجموعه نیازمندیها و رشتههای منحصربهفرد خود را دارند، اما همگی از همان پلتفرم زیربنایی استفاده میکنند. فرض کنید روی پلتفرم Salesforce هستید اما بسته به مشتری یا فضای بازار، پیکربندیهای بسیار متفاوتی دارید. اگر پیشنهاد شما برای بازارهای سلامت، مالی و آموزش کاربرد دارد، شاید منطقی باشد تیمهای خود را در این فضاها بچینید تا بتوانند درباره ویژگیهای منحصربهفرد هر بخش تجربه کسب کنند و تیمهایتان برای شما و کاربر نهایی ارزشمندتر شوند.
۶.۲.۴ رویکرد ترکیبی
در نهایت رویکرد ترکیبی وجود دارد؛ کمی از همه چیز که همزمان کار میکند. این اغلب رخ میدهد، بهویژه در سازمانهای بزرگ که محصولات تاریخی زیادی در جریان دارند. تلاش برای جا دادن همه در یک سلسلهمراتب مشترک، بیش از آنچه حل کند مشکل ایجاد میکند، چون باید آنقدر چابک باشید که با محیطی پیچیده و در حال تغییر سازگار شوید. اگر در حال پروژه بازتصور با محصولات قدیمی/میراثی در حال تکامل هستید، رویکرد ترکیبی راه خوبی برای مدیریت تولید کوتاهمدت است. تیمها انعطاف پیدا میکنند؛ چیزی که یک روز جواب میدهد شاید یک سال بعد همان معنا را نداشته باشد. سازگار باشید و مراقب ساختار خود بمانید. سالی یکبار اغلب کافی است تا از خود بپرسید آیا چیزها به شکلی ساختار یافتهاند که بهینه به کسبوکار خدمت کند یا نه.
۶.۳ عنوانها
یکی از مهمترین چیزهایی که باید به آن مسلط شوید این است که چگونه تیم خود را حول ساختاری طراحی میکنید که به افراد اجازه تکامل، رشد و فهمیدن انتظارات را بدهد. یکی از وجوه آن عنوان ساده است؛ تیم خود را چه خواهید نامید؟ اهمیت عنوان را دستکم نگیرید. هرکس هرچقدر هم ادعا کند عنوان برایش مهم نیست، واقعا اهمیت میدهد، حتی اگر جسارت ظاهریاش نگذارد اعتراف کند. عنوان نشان افتخار، دستاورد و بررسی وضعیت پیشرفت حرفهای فرد است. همچنین راهی است برای ارتباط با دنیای بیرون، شامل خانواده، درباره اینکه او چه نوع فردی است. «او فقط یک ناظر نیست، او یک ابرناظر است.» از Mrs. Brown’s Boys، BBC TV. متأسفانه استاندارد یا مقیاس جهانیای وجود ندارد که بتوانیم توانایی افراد را در شرکتهای مختلف بهطور مؤثر مقایسه کنیم. عنوانهایی مانند «Senior» میتوانند از شرکتی به شرکت دیگر طیف گستردهای از مهارتها و ویژگیها را معنا دهند. Senior در یک شرکت ممکن است در شرکت دیگر Junior یا Associate محسوب شود. بعدتر در این فصل ماتریسی میسازیم که به شما کمک میکند نقشهای مختلف هر عنوان را تعریف کنید. اما فعلا فرض کنیم به آنها نیاز دارید.
۶.۳.۱ در عنوان چه هست؟
عنوان مجموعهای از ویژگیها را در خود دارد که هم استنباط میشوند و هم القا. وقتی کسی خود را با عنوانی توصیف میکند، ما بهطور خودکار پروفایلی فرض میکنیم، چه درست باشد چه غلط. مثلا وقتی کسی با عنوان CEO به شما معرفی میشود، برداشت میکنید رئیس است و ارشدیت دارد.
یک عنوان خوب و درست انتخابشده ویژگیهای زیر را منتقل و مجسم میکند:
- مسئولیتها
- تجربه
- حقوق
- ارشدیت
- شناخت صنعتی
عنوان سطحی از اطمینان را در شنونده ایجاد میکند. به عنوانهایی فکر کنید که بیرون از صنعت خود میشنویم و بیدرنگ به ما احساس آسودگی میدهند. مثلا آیا هنگام بستن کمربند در هواپیما راحتتر هستید وقتی خلبان خود را «Captain» معرفی میکند، نه «Junior Pilot»؟ نمیخواهیم از هیچ «Junior»ی بشنویم، چون این کمبود تجربه، کمبود ارشدیت و کمبود مسئولیت را القا میکند، در حالی که روی باند حرکت میکنیم و آماده پرتاب به هوا هستیم.
حس امنیت
اخیرا مجبور شدم جراحی گردن انجام دهم، و وقتی فهمیدم جراح من «جراح ارشد» بیمارستان است، دانستم در دستان امنی هستم. شاید حس امنیتی غیرمنطقی بود، اما عنوان به من آرامش داد؛ با توجه به اینکه این اولین جراحی عمرم بود، به هر امیدی که میتوانستم چنگ میزدم.
اگرچه اختصاص عنوان درون تیم خودتان شاید مسئله مرگ و زندگی نباشد، برای مشتری بیرونیای که با گروه شما تعامل دارد میتواند اهمیت زیادی داشته باشد. مثلا آن مشتری شاید خوشحال نباشد با یک «Junior» سروکار داشته باشد، چون با توجه به مقدار پولی که خرج میکند شاید احساس کند سزاوار چیز بیشتری است. شرکت شما شاید در انتخاب عنوانها انعطاف زیادی به شما ندهد؛ شاید آنها با بسته جبران خدمات کارمند گره خورده باشند. حتی در این وضعیتها که فکر میکنید دستتان بسته است، هنوز فضای مانور زیادی وجود دارد، و بعدتر در فصل آن را توضیح میدهم.
۶.۳.۲ نردبان پیشرفت
شرکتهای بزرگتر و جاافتادهتر ممکن است از قبل یک مسیر مشخص برای عنوانهای شغلی داشته باشند و تعریف کرده باشند که هر سطح دقیقا چه معنایی دارد. اما در شرکتهای کوچکتر، ممکن است چنین ساختاری هنوز شکل نگرفته باشد. با این حال، حتی اگر این ساختار از قبل وجود داشته باشد، شما بهعنوان رهبر گروه مهندسی باید مشخص کنید که از هر سطح چه انتظاراتی دارید. بیایید در جدول ۶.۱ نگاهی بیندازیم به یک نردبان عنوان شغلی نسبتا رایج و استاندارد در فضای فناوری.
جدول ۶.۱ نردبان عنوان: فناوری
| عنوان | تجربه | یادداشتها |
|---|---|---|
| Junior | ۰ تا ۲ سال | معمولا سطح ورودی؛ جایگاه شروع برای فارغالتحصیل تازه |
| Associate | ۲+ سال | تجربه صنعتی دارد اما هنوز حرفه خود را میآموزد |
| Senior | ۵+ سال | حرفه خود را بسیار خوب و با عمق زیاد میشناسد |
| Lead/Manager | ۵+ سال | آماده پذیرش مسئولیت مدیریت خروجی دیگران است |
| Architect | ۱۰+ سال | در چند رشته در حوزه خود دانش عمیق دارد و گستردهتر فکر میکند |
| Divisional Manager / Vice President | ۱۰+ سال | مسئول بیش از یک تیم در حوزهای تعریفشده است؛ معمولا با بودجهها درگیر است |
| Fellow | ۱۵+ سال | عنوانی ویژه برای شناسایی تلاشهای بلندمدت و مستمر |
هر یک از این عنوانها در حالت ایدهآل باید به نوعی تخصص یا رشته کاری گره بخورد؛ برای مثال «Senior Developer» یا «Support Manager». عنوان، نقش یک نشانگر را در میان رشتههای مختلف گروه شما بازی میکند. البته همیشه استثناهایی برای هر قاعده وجود دارد، و عنوانها نیز همیشه به شرایط و بافت شرکت شما وابستهاند. بعضی سازمانها معمولا الگوی خاص خودشان را دارند. مثلا در IBM، ظاهرا همه «Vice President» چیزی هستند! برخی سازمانهای دیگر از «Director» بهعنوان نشانهای از ارشدیت استفاده میکنند، که میتواند گیجکننده باشد؛ چون در بریتانیا به جای «Chief Executive Officer» از عنوان «Managing Director» استفاده میشود. عنوان «Director» در بریتانیا پیامد حقوقی هم دارد، زیرا چنین فردی در اسناد ثبت شرکت، از نظر قانونی بهعنوان یکی از مسئولان و متولیان شرکت ثبت میشود. تجربه را با عنوان اشتباه نگیرید؛ پنج سال کار کردن در سطح Junior، کسی را Senior نمیکند.
۶.۳.۳ اشتباههای رایج با عنوانها
بعضی شرکتها با عمل ساده ناهماهنگ کردن عنوانها با افراد، برای خود مشکلات جدی ساختهاند. برای اکثریت تصمیمهایی که بهعنوان رهبر میگیریم، راهی برای برگرداندنشان داریم. با این حال، وقتی عنوانی به فردی اختصاص داده شد، حذف یا واگذاری دوباره آن میتواند تنزل تلقی شود، ممکن است HR را درگیر کند و اثرات تضعیفکننده روحیه داشته باشد. برخی اشتباههای رایج در اعطای عنوانها عبارتاند از:
- ترفیع بیش از حد سریع: ترفیعها باید کم و با فاصله باشند و هرگز نباید در نتیجه یک برد یا رویداد منفرد انجام شوند.
- عنوان به جای افزایش حقوق: وقتی باید به کسی پاداش دهید اما بودجه ندارید، تغییر عنوان وسوسهانگیز است. همه کاری که این میکند این است که به او دلیلی میدهد تا دنبال نقشهایی با عنوان مشابه و پولی که باید بگیرد بگردد. نمیتوانید به یک Senior همان حقوقی را بدهید که به یک Junior میدهید.
- پاداش دادن به طول خدمت با عنوان: فقط چون کسی ۲۰ سال با شرکت بوده، اگر معیارها را برآورده نکرده باشد خودبهخود Senior نمیشود. این موضوع ارتباط نزدیکی با افزایش پیوسته حقوق کسی دارد فقط چون بهموقع حاضر شده است. هر دو نتیجه مشکلات بزرگی ایجاد میکنند و یکی از رایجترین مشکلاتی هستند که CTOهای تازهکار به ارث میبرند.
- بیش از حد هوشمندانه بودن با عنوانها: هرچقدر هم وسوسهانگیز باشد، به عنوانهایی بچسبید که در صنعت شناختهشدهاند. این کار نه تنها جذب نیرو را آسانتر میکند، بلکه به تیم فعلی خودتان هم حس تعلق به جامعهای بزرگتر میدهد و برای مشتریان قابل فهم است.
از دل میدان: Chief Knowledge Officer
حدود ۲۰ سال پیش در یک استارتاپ خوب تأمین مالیشده در Silicon Valley این عنوان پرطمطراق را داشتم. این استارتاپ فارغالتحصیلان زیادی از دنیای اولیه Java داشت، و ما به خودمان عنوانهای تند و مد روز میدادیم... جز اینکه برای دنیای بیرون هیچ معنایی نداشتند. در واقعیت، من نقش Evangelist را بازی میکردم، که برای دیگران بسیار معنادارتر از عنوانی بود که فکر میکردیم هوشمندانه است. در پایان، عنوانهای ما بیش از حد خلافآمد بودند؛ مدام نادیده گرفته میشدیم چون مشتریان بالقوه ما هرگز نمیتوانستند بفهمند باید با چه کسی صحبت کنند.
۶.۴ گزارشدهی تیم
اکنون که تیمهایتان شکل گرفتهاند و میدانند نقشهایشان چیست، پرسش بر یافتن راهی برای کار کردن با این تیمها متمرکز میشود. چون قرار نیست micromanager باشید و تیمهایتان استقلال خواهند داشت، باید راهی پیدا کنید تا فعالیت آنها را هماهنگ کنید و از پیشرفت و هر مسئلهای که ممکن است با آن روبهرو باشند باخبر بمانید. اینجاست که باید سازوکاری خوب برای کار با رهبران تیم خود پیدا کنید، تا در هر لحظه تصویر خوبی از وضعیت کلی دپارتمان خود داشته باشید، چه خوب چه بد.
الهام ببخشید: بالا کشیدن دیگران
اگر تیمهای موجود را به ارث میبرید، غیرمعمول نیست که برخی مدیران تیم شما مهارتهای مدیریتی کم داشته باشند یا آموزش رسمی ندیده باشند. آنها در حین کار یاد گرفتهاند و احتمالا تا حد زیادی سبک خود را بر تنها چارچوب مرجع واقعیشان مدل کردهاند: رئیس خودشان. حالا آن رئیس شما هستید. شیوه مدیریت شما، امیدوارانه، بهعنوان راهنمایی برای دیگران دیده خواهد شد. این را در ذهن داشته باشید، بهویژه وقتی روزگار سخت یا پراسترس است، چون هر کاری که میکنید به یاد سپرده و هنگام مدیریت تیمهایشان کپی خواهد شد. من همیشه از خودم میپرسم: آیا از کار کردن برای خودم خوشحال میشدم؟ برای ثبت، زمانهایی در مسیر حرفهایام بوده که باید به آن پاسخ منفی میدادم.
۶.۴.۱ استقلال را تعریف کنید
اگرچه میخواهید تیمهایتان مستقل باشند، در زمانهایی مشخص باید درگیر شوید و درباره تصمیمها نظر بدهید، درست همانطور که باید به CEO پاسخگو باشید. همانطور که CEO برخی موارد را مشخص کرده که برای آنها باید تأیید او، یا حتی هیئتمدیره، را بگیرید، شما هم باید چارچوبی مشابه برای تیمهایتان تنظیم کنید. هر تیم ممکن است بسته به نقش کلی خود در گروه شما و تجربه مدیر، قواعد تعامل کمی متفاوت داشته باشد، اما همه باید به مجموعهای مشترک از قواعد پایبند باشند. میتوانید این را به سه سطل تقسیم کنید: چیزهایی که باید بتوانند داخلی مدیریت کنند، مسائلی که باید از آنها آگاه باشید، و در نهایت تصمیمهایی که باید دربارهشان نظر بدهید و تصمیم نهایی بگیرید. چند نمونه از موضوعاتی که ممکن است در نظر بگیرید در جدول ۶.۲ نشان داده شده است.
جدول ۶.۲ قواعد تعامل
| نیازی به گزارشدهی نیست | شما را در جریان نگه داشتن | نیازمند تصمیم |
|---|---|---|
| مصاحبه با نامزدهای بالقوه | هر مشکل یا مسئله مربوط به یک مشتری | مشورت با HR یا بررسیهای مربوط به خاتمه همکاری |
| فرایندهای داخلی مرتبط با اجرای تیم | هر مشکل تولید | خرید یا مجوزدهی ابزارها |
| جلسههای یکبهیک تیم؛ مدیریت PTO | نگرانیها یا مسائل امنیتی | تغییر فناوری یا ابزارها |
| اجرای پروژه | تغییرات در نحوه تعامل تیم با تیمهای دیگر؛ مشکلات فردی اعضای تیم؛ بهروزرسانیهای زمانبندی | تصمیم نهایی درباره نامزدهای برتر در حال بررسی |
مهم است چارچوب درست را به لیدهای تیم خود بدهید و آن تعادل سطح جزئیات موردنیاز را پیدا کنید.
از دل میدان: دیده شدن مشتری
همیشه گفتهام باید از هر مشکلی که به نارضایتی مشتری یا رخنهها یا نگرانیهای امنیتی مربوط است آگاه شوم، فارغ از ساعت روز. حتی در آن صورت، مطمئن شدم همه تیمم شماره موبایل من را داشته باشند، چون اگر تأیید نکردم ایمیل یا پیامشان را خواندهام، باید با من تماس بگیرند. هرگز نمیخواستم در موقعیتی باشم که CEO درباره چیزی از من بپرسد که هیچ اطلاعی از آن ندارم. همیشه بهتر است شما مشکلات را به مدیریت خود بگویید پیش از آنکه از راهی خارج از کنترل شما باخبر شوند.
هنر «بهروزرسانی بدون نیاز به بهروزرسانی» (Art of the “No-Update Update”)
نکته خوبی که سالها پیش کلی پاول، CEO/نویسنده، به من آموخت، زمانی که رئیس عملیات مشتری در Royall & Co بود، اهمیت «بهروزرسانی بدون نیاز به بهروزرسانی» برای موقعیتهایی بود که دید زیادی داشتند. آیا تا به حال در موقعیتی بودهاید که منتظر بهروزرسانی از کسی هستید و با گذشت زمان و نبود ارتباط، فکر میکنید آیا شما را فراموش کردهاند؟ همه ما آنجا بودهایم؛ هرچه بیشتر ناامید و آزرده میشویم که هیچ اتفاقی نیفتاده است. پاول همیشه بر بهروزرسانی اصرار داشت، حتی اگر این بود که هنوز راهحلی وجود ندارد اما کارها همچنان در حال انجام است. او ترجیح میداد هر ۳۰ یا ۶۰ دقیقه، بسته به شدت مسئله، از طریق ایمیل یا متن بهروز شود.
از دل میدان: بهروزرسانی بدون نیاز به بهروزرسانی (No-Update Update)
من این قاعده را بهعنوان قاعده خود پذیرفتهام و بر این روش از سوی گزارشهای مستقیم خود اصرار کردهام. همچنین به کسانی که منتظر من هستند این احترام را میگذارم که آنها را در جریان نگه دارم. هرچقدر هم احمقانه به نظر برسد، میخواهم در آغاز و نیمه هر ساعت بهروز شوم. اینگونه برای افراد آسان است که چشمشان به ساعت باشد و لازم نباشد به یاد بیاورند آخرین بهروزرسانی کی بود. لازم نیست زمانبر یا پرجزئیات باشد؛ فقط یادداشتی کوتاه که بگوید کارها هنوز در حال انجام است.
۶.۴.۲ شاخصهای گزارشدهی
اگرچه این موضوع تا حد زیادی به نوع تیمهایی که دارید بستگی دارد، بهندرت پیش میآید نتوانید مجموعهای از شاخصها پیدا کنید که لیدهای تیم بتوانند خود را بر اساس آنها اندازهگیری و گزارش کنند. این شاخصها باید معنا داشته باشند و صرفا برای تولید چند نمودار بیمعنا نباشند. شاخص خوب شاخصی است که اجازه دهد پیشرفت را به شکل کلنگر ببینید و وارد گزارش کلی شما شود که برای اطلاعرسانی به تیم مدیریت آماده میکنید. مزیت داده خام این است که ابهام احساسی را از سنجش موفقیت یک تیم مشخص دور میکند. با این حال، یک هشدار: باید در برابر میل به رقابت دادن تیمها با یکدیگر مقاومت کرد، چون به احتمال زیاد دارید سیب را با پرتقال مقایسه میکنید؛ مقایسهای ناعادلانه. هر تیم را در مسیر شاخص خودش نگه دارید و فقط با خود تاریخی یا پیشبینیشدهاش مقایسه کنید. نمونههایی از شاخصهای رایجی که بیشتر تیمها میتوانند دستکم یکی از آنها را استفاده کنند عبارتاند از:
- تیکتهای باز/بسته
- تعاملهای پشتیبانی
- شاخصهای انتشار، شامل تعداد و زمان لازم
- شاخصهای عملکرد/بار
- کاهش بدهی فنی
- پیشرفت هدف/sprint
جمعآوری شاخصها برای لیدهای تیم باید نسبتا آسان باشد و هر بار که آنها را برای شما جمع میکنند، خودش به پروژهای جداگانه تبدیل نشود. شاخص خوب به احتمال زیاد از ابزار اصلیای بیرون میآید که تیم استفاده میکند، مثلا JIRA، SonarQube یا Jenkins. وقتی شاخصها تصمیمگیری شدند، باید تصمیم بگیرید از نظر بسامد دیدن بهروزرسانی چه چیزی برای شما معنا دارد. بهروزرسانی هفتگی غیرمعمول نیست، یا حتی هر دو هفته یکبار. هر چیزی طولانیتر از آن، یعنی ممکن است اتفاقات زیادی بیفتد بدون اینکه دید واقعی داشته باشید تا پیش از بروز مشکلات بالقوه جلویشان را بگیرید.
۶.۴.۳ پاسخگویی
ماشین خوب روغنکاریشده ماشینی است که همه قطعات آن هماهنگ کار میکنند و جمعا خروجی لازم برای موفقیت موتور را تولید میکنند. تیم هم تفاوتی ندارد؛ باید با پیشبینیپذیری و کارایی عمل کند تا گروه شما بهعنوان یک کل کار کند. برای اینکه این اتفاق بیفتد، لیدهای تیم باید نسبت به خروجی خود پاسخگو باشند و مسئولیت کمبودها یا شکستهای خود را بپذیرند و بردهایشان را با هم جشن بگیرند. توافق روی شاخصها و هدفها احساس را از هر گفتوگو حذف میکند و اجازه میدهد بر دادهای تمرکز کنید که موفقیت تیم را توضیح میدهد. تیمی که هدف ندارد هرگز نمیداند آیا از انتظارات شما عقب است یا فراتر رفته. این برای تیم ناعادلانه است و شما را در معرض حکمهای ذهنی و احساسی قرار میدهد. ممکن است چند هفته طول بکشد تا شاخصهای معنادار درست تعیین شوند، بهویژه اگر تازه مسئولیت را بر عهده گرفته باشید. وقتی آن شاخصها توافق، اندازهگیری و ارزیابی شدند، میتوانید در جلسهها گفتوگوهای معنادار داشته باشید؛ یا درباره بهبود عملکرد یا درباره ایجاد معیارهای مرجع تازه برای سنجش. در همه سطوح گشودگی و صداقت را تشویق کنید. این به آن معنا نیست که دنبال «قربانی» هستید تا وقتی چیزی خراب شد همه تقصیرها به او نسبت داده شود. شما تیمی از تیمها هستید، و برای موفقیت یک تیم، به کانال ارتباطی خوب و محکمی نیاز دارید که بر اعتماد و احترام بنا شده باشد، تا اگر بدترین اتفاق افتاد، هیچکس از آوردن خبر بد نزد شما نترسد یا مرعوب نشود.
این خیلی بد است: From the Earth to the Moon
این مجموعه محبوب HBO درباره اینکه ایالات متحده چگونه به ماه رسید، اپیزودی دارد که یکی از بهترین تمثیلها برای اداره یک تیم مهندسی است: «Spider». همه شبانهروزی کار میکنند تا به مهلتهای تهاجمی برسند، و نمیتوانند بفهمند چرا مدام ماژول قمری را دچار خرابی میکنند، تا اینکه یک مهندس با خجالت اعتراف میکند خطای گرد کردن را رها کرده است. او نزد لید میرود و انتظار دارد اخراج شود یا سرزنش بخورد. مهندس ارشد Grumman میگوید: «آیا این را پنهان کردی؟ تلاش کردی آن را لاپوشانی کنی؟ نه. بد است. خیلی بد است. اما برو خانه، کمی بخواب، و بیایید این را حل کنیم.» حالا تصور کنید مسیر دیگری را انتخاب کرده بود: داد و فحش. آیا نفر بعدی اگر خطایی کند احساس اجبار میکند حرف بزند؟ شاید در آن صورت هرگز به ماه نمیرسیدیم. پاسخگویی به این معنا نیست که همه خطاها یا مسائل بخشیده میشوند و زندگی ادامه پیدا میکند. پاسخگویی یعنی مسئولیت خطا را پذیرفتن، رسیدن به ریشه مشکل، و گذاشتن رویهها، فرایندها و حتی ابزارهای لازم برای جلوگیری از تکرار آنها. اگر چیزی تغییر نکند یا بارها و بارها تکرار شود، آنگاه پاسخگویی یعنی حذف افراد مسئول از آن جایگاه و گذاشتن کسانی که میتوانند تفاوت ایجاد کنند. این مسئولیت شما بهعنوان رهبر گروهی از تیمهاست. کافی نیست انگشت اتهام را به سوی مدیری ضعیف بگیرید. او مدیر شماست؛ تصمیم شماست که او را در نقش نگه دارید و مسئولیت شماست که منتورینگ و راهنمایی لازم را بدهید تا مطمئن شوید همه فرصتهای موفقیت را دارد. شکست او شکست شماست، و سایهای بر همه خانههای شما میاندازد. CEO شما را زیر نظر خواهد داشت و مدیریت خواهد کرد، و اگر احساس کند دیگر نمیتوانید تیم خود را مدیریت کنید، شما را جایگزین خواهد کرد. این بهویژه زمانی درست است که شرکت شما بخشی از پرتفوی سرمایهگذاری خصوصی باشد. سرمایهگذاری خصوصی وقت تحمل اشتباههای زیاد را ندارد و فهرست بلندی از مدیران باتجربه، آموزشدیده و محترم دارد تا در چشم بر هم زدنی جایگزینتان کند؛ و هرگز آمدنش را نمیبینید. پاسخگو نگه داشتن تیم یعنی آنها را به شاخصها و مسئولیتهایی پایبند نگه دارید که هنگام پذیرش نقش تعهد کردهاند. این یعنی تیمهایتان را برای موفقیت آماده کنید. موفقیت آنها موفقیت شماست.
۶.۵ جلسه یکبهیک
از میان همه جلسههایی که کمکم وارد تقویم شما میشوند، یکی که هرگز نباید عقب بیفتد یا لغو شود جلسه کلاسیک یکبهیک است. همانطور که نامش میگوید، زمانی است که بهطور منظم با یکی از لیدهای تیم خود بهصورت فردی دیدار میکنید؛ معمولا هفتهای یکبار یا یک هفته در میان. طول ایدهآل این جلسهها باید ۱۵ تا ۳۰ دقیقه باشد و برای بررسی وضعیت درباره حال و وضعیت فرد موردنظر طراحی شدهاند. این جلسهها باید با بیشترین محرمانگی برگزار شوند و برخی حتی آنها را مثل جلسههای mini therapy میبینند. این زمانی است برای گزارش مستقیم شما تا هر حوزهای را که در آن مشکل دارد برجسته کند و برای حل آن از شما کمک بخواهد. نمونه آن میتواند کمک به کسی باشد تا در صحبت با تیم اعتمادبهنفس بیشتری پیدا کند، چون اضطرابش مانع میشود کل گروه را خطاب قرار دهد. این همچنین فرصتی است تا هر نگرانیای را که درباره کار کردن با شما دارد مطرح کند. شاید سبکی دارید که به شکلی منتقل میشود که قصدش را نداشتید، و او باید آنقدر راحت باشد که این را به توجه شما برساند. احتمال دارد دیگران هم همین احساس را داشته باشند. برعکس، این قالب جلسه نباید برای بحث درباره بهروزرسانیهای پروژه، مهلتها یا مسائل استفاده شود. مسیرهای دیگری برای بحث درباره آن موارد دستور جلسه وجود دارد. جدول ۶.۳ را ببینید.
جدول ۶.۳ قالب جلسه
| موضوعات داخل دامنه | موضوعات خارج از دامنه |
|---|---|
| هدفهای شخصی | بهروزرسانیهای پروژه |
| حوزههای قابل بهبود | وظایف تازهای که میخواهید به آنها بپردازد |
| نگرانیها درباره اجرا | گفتوگوهای انضباطی |
| تحلیل یک رویداد اخیر | شایعه درباره اعضای دیگر؛ بهروزرسانیهای شرکت |
انتظار نمیرود همه پاسخها را داشته باشید. انتظار میرود گوش دهید، همدلی کنید و هرجا مناسب است راهنمایی بدهید. این نوع جلسهها برای لیدهای تیمی که خود را در این نقش تازه میبینند و ممکن است چند اشتباه تازهکارانه کنند ارزشمندند؛ چند هشدار آرام در گوششان میتواند سبک مدیریتشان را متحول کند. این فرصتی است برای انجام اصلاحات کوچک در زمانی کوتاه پیش از اینکه چیزی آنقدر بزرگ شود که مجبور شوید بررسی کنید آیا از ابتدا تصمیم درستی گرفتهاید که او را در آن نقش گذاشتهاید یا نه.
از دل میدان: بازتاب دادن خروجی
من این جلسهها را راهی بینهایت ارزشمند یافتهام برای اینکه افراد را ظریف وادار کنم درباره خروجی خود و اینکه میخواهند چگونه شناخته شوند فکر کنند. مثلا اگر شاهد چیزی بودهام که احساس کردهام میتوانست بهتر انجام شود، شاید با پرسیدن اینکه خودشان احساس کردند آن چیز چگونه پیش رفت شروع کنم؛ آیا پیامشان را رساندند؟ آیا احساس کردند اتاق دقیقا فهمید چه میخواهند؟ سپس، به جای اینکه بگویید شما چگونه انجام میدادید، راههای متفاوتی پیشنهاد میکنید که میتوانستند همان کار را انجام دهند و از آنها میپرسید آیا نتایج متفاوتی میداد یا نه.
از این جلسههای یکبهیک بهعنوان راهی برای ساختن اعتماد و ارائه منتورینگ و خرد خود استفاده کنید، در قالبی که حامیانه باشد و تحقیرآمیز یا موعظهگرانه به نظر نرسد.
۶.۶ آموزش و یادگیری
خوششانسیم که در یکی از پیچیدهترین و سریعترین صنایع کار میکنیم؛ صنعتی که هر چند سال یکبار
خود را پیوسته بازآفرینی میکند. عقب نماندن از روندها، ابزارها و فرایندها خواسته نیست، ضرورت است. بهعنوان رهبر
گروه خود، بر عهده شماست که تیم خود را با تازهترین اطلاعات آموزشدیده و آماده نگه دارید تا نه تنها بهرهوری بهتر
ارائه دهند و پلتفرم شما را مدرن نگه دارند، بلکه ارزشمندی و عزتنفس نیز به دست آورند.
خبر خوب این است که اکثریت
بزرگ افرادی که در صنعت ما کار میکنند میدانند باید یادگیری را ادامه دهند و به سوی آن میدوند. اگرچه برخی دنبال
تغییر کامل رشته نیستند، باید از آخرین نسخههای ابزارهایی که استفاده میکنند، بهبودهای زبان و موارد مشابه باخبر
بمانند.
در روزهای قدیم، آموزش را نوعی فرایند رسمی کلاسمحور میدانستید که تیم خود را چند روز در هر نوبت، با هزینه زیاد،
به آن میفرستادید. از مدیریت بودجه آموزشی میخواستید، در حالی که هرگز فایده آموزشدیده نگه داشتن نیروی کار را
نمیدید. خوشبختانه آن روزها گذشته است، با فراوانی منابع آنلاین، از جمله مطالب دانشگاههای برتر، که همگی فقط یک
کلیک دورند. با این حال، نقش شما فقط در دسترس قرار دادن این مواد برای تیم نیست، بلکه باید زمان لازم را هم در کار
بگنجانید تا بتوانند درست از آنها بهره ببرند. چند گزینه پیش روی شما را مرور میکنیم. هر مسیری که انتخاب کنید،
مطمئن شوید از آموزش خود عقب نمیمانید. آموزش و نگهداشت کارکنان موجود بسیار ارزانتر از خاتمه همکاری و در نتیجه
آموزش و آنبوردینگ کارکنان تازه است.
۶.۶.۱ کتابخانهها/منابع آنلاین
منابع آنلاین گوناگون زیادی، هم رایگان و هم پولی، در دسترس هستند. اینها در شکلها و بستههای متفاوتی میآیند. بسیاری از ناشران فنی اشتراکهای ویژهای دارند که به تیم شما دسترسی نامحدود به آرشیو کتابهایشان میدهد. سایتهای تخصصی، مانند Khan Academy و Coursera، دورههای رسمیتر شبیه کلاس آنلاین با تمرین و آزمون ارائه میدهند، همه رایگان. سایتهای دیگر، مانند Udemy، تجربه یادگیری را با چند دلار برای هر دوره ارائه میدهند. مهم است که شما و لید تیمتان این دورهها را ارزیابی کنید تا مطمئن شوید برای تیمتان مرتبط و ارزشمند هستند. این نوع یادگیری برای افرادی ایدهآل است که دوست دارند با سرعت خود و بهتنهایی یاد بگیرند.
۶.۶.۲ گواهینامههای پلتفرم/نرمافزار
بسیاری از بازیگران بزرگ، مانند Amazon، Microsoft، Cisco و Oracle، برای بسیاری از محصولاتشان فرصتهای گواهینامه ارائه میدهند. قیمت اینها در طول سالها بهطور چشمگیری کاهش یافته است و بسیاری از گواهینامهها فقط چندصد دلار هزینه دارند، در مقایسه با هزاران دلار در چند سال قبل. مزیت گواهینامه این است که ثابت میکند فرد آموزش لازم را کامل کرده و آزموده شده تا نشان دهد موضوع موردنظر را میفهمد. این نه تنها برای رزومه شخصی خودش بسیار سودمند است، بلکه برای شما نیز مفید است که بدانید افراد آموزشدیده و دارای گواهی در تیم خود دارید. تقریبا همه برنامههای گواهینامه دورههای آنلاین همراه با آزمون و تمرینهای کوچک در مسیر ارائه میدهند که به آزمون نهایی در پایان منجر میشود.
۶.۶.۳ بوتکمپها
بوتکمپها، بهویژه بوتکمپهای کدنویسی، در سالهای اخیر بسیار محبوب شدهاند، چون فشاری برای آوردن افراد بیشتر به برنامهنویسی وجود داشته است. آنها میتوانند شکلهای متفاوتی بگیرند، از جلسههای فشرده و غوطهورکننده که همه در یک هفته فشرده میشوند تا دورههایی که طی چند هفته پخش میشوند و عصرها یا هنگام ناهار برگزار میشوند. اینها بهصورت حضوری و کلاسمحور برگزار میشوند، پس از معلم یاد میگیرید، شبکهسازی میکنید و از دیگران میآموزید.
۶.۶.۴ گروههای کاربری
هزینه بوتکمپها آنها را دسترسپذیر میکند؛ طراحی شدهاند تا فرد برای بهبود مسیر حرفهای خود هزینهشان را بپردازد، بنابراین نباید مانع بودجهای چشمگیری برای شرکت ایجاد کند تا افراد را به آنها بفرستد. شکل ظریفتری از یادگیری استفاده از گروههای کاربری محلی است. اینها معمولا حول فناوری یا زبان مشخصی متمرکزند و ماهی یکبار، عصرها همراه با پیتزا و آبجو، گرد هم میآیند؛ جایی که سخنران مهمان درباره ویژگی یا فرایندی تازه صحبت میکند یا وارد حوزهای موجود میشود تا دیگران آن را بهتر بفهمند و استفاده کنند.گروه کاربری میتواند رویداد شبکهسازی عالیای باشد و چیزی است که همیشه باید تیمهای خود را تشویق کنید دنبالش بگردند و در آن شرکت کنند. همیشه خوب است همتایان خود را در منطقه محلی که روی همان فناوریها کار میکنند بشناسید، تا اگر به مشکلی برخوردند یا به مشورتی نیاز داشتند، بتوانند تماس بگیرند و گفتوگو کنند.
۶.۶.۵ آموزش داخلی
بیشتر گروههای کاربری تأمین مالی نمیشوند و به حسننیت شرکتهای محلی برای اهدای فضای سخنرانی و حمایت از غذا تکیه دارند. اگر در موقعیتی هستید که فضای دفتر خود را برای سخنران مهمان پیشنهاد دهید، راهی عالی است تا دیگران نه تنها درباره شرکت شما و کاری که انجام میدهید یاد بگیرند، بلکه افراد همفکر در منطقه شما را نیز ملاقات کنند. با توجه به هوش داخلی تیم خودتان، چرا جلسههایی برای اشتراک دانش ساختار نمیدهید؟ میتوانید محیطی بسازید که متخصصان موضوعی مشخص زمانی بگذارند و جلسهای کوچک ایجاد کنند تا حوزه تخصص خود را معرفی کنند یا عمیقتر وارد آن شوند. اگر نمیخواهید خیلی رسمی باشید، میتوانید سراغ چیزی بروید که «ناهارهای دورهمی آموزشی» نام دارد؛ جایی که موضوعی هنگام ناهار مفصل بحث میشود، با این ایده که همه ناهار خود را میآورند و هنگام یادگیری میخورند، هرچند در این وضعیتها همیشه ژستی از حسننیت است که برای همه شرکتکنندگان ناهار بخرید.
۶.۶.۶ کنفرانسها
کنفرانسها پیش از همهگیری COVID-19 بسیار محبوب بودند، و هنوز باید دید آیا هرگز به اندازهای که بودند برمیگردند یا نه؛ به AWS re:Invent فکر کنید، وقتی ۳۰٬۰۰۰ نفر برای یک هفته به Las Vegas میآمدند. با این حال، بسیاری با موفقیت زیادی آنلاین شدهاند و جوهره چیزی را که عالیشان میکرد ثبت کردهاند، هرچند بدون جنبه شبکهسازی. کنفرانسها جلسههای زیادی را در سطوح مختلف فشرده میکنند تا به شرکتکنندگان راهی آسان برای نمونهبرداری همزمان از چیزهای زیاد بدهند. فرستادن یک یا دو عضو به کنفرانس، بهویژه کنفرانسی که سفر و اقامت دارد، میتواند گران باشد و چیزی نیست که بتوانید به همه پیشنهاد دهید؛ کسی باید وقتی رفتهاند مراقب مغازه باشد. راه خوب برای انجام این کار این است که به بهترین عملکردهای خود با این فرصت پاداش دهید و از آنها بخواهید برگردند و یک یا دو جلسه جمعبندی برای بقیه ارائه کنند. همچنین میتوانید افراد را با مأموریتی مشخص بفرستید تا درباره فناوری یا محصولی مشخص یاد بگیرند و برگردند و همه را درباره آنچه آموختهاند آموزش دهند.
۶.۶.۷ دورههای دانشگاهی/کالج
برخی افراد میخواهند جهشی بزرگ در مسیر حرفهای خود بردارند و دنبال گرفتن مدرک در موضوعی مشخص باشند. این تعهدی بزرگ هم از نظر زمان و هم از نظر مالی است و گاهی طی چند سال هزاران دلار هزینه دارد. بسته به نوع مدرک، ممکن است حمایت از همه یا بخشی از آموزش را در نظر بگیرید و اجازه دهید در طول روز کاری زمانی برای رفتن به کلاسها گرفته شود. اگر برای سازمان خود ارزش میبینید، میتوانید توافقی ساختار دهید که شرکت کمک کند، با این فرض که وقتی فرد فارغالتحصیل شد، باید برای تعداد سالهای مشخصی با تیم شما بماند. در غیر این صورت، سرمایهگذاریای را که روی او کردهاید بدهکار خواهد بود. هنگام ایجاد سیاست درباره این پیشنهاد سنجیده باشید تا ناخواسته نارضایتی در کسانی که این مزیت را دریافت نمیکنند ایجاد نکنید. آنها میتوانند ببینند و حمایت کنند که چرا کارمند مشخص در آن شرکت میکند.
۶.۷ ارتباطات
از هر عضو تیم خوشحال بپرسید چه چیزی او را خوشحال میکند، و جایی در آن فهرست واژه شفافیت بیرون میآید: احساس و آرامشِ دانستن اینکه پیرامونشان چه میگذرد و اینکه شامل شدهاند. شفافیت خودبهخود به این معنا نیست که باید همان لحظه که چیزی را میفهمید به همه همه چیز را بگویید. از سایر مدیران ارشد اطلاعات محرمانهای خواهید آموخت که شاید هنوز آماده اشتراکگذاری نیست یا آنقدر اندیشیده نشده که بدون ایجاد استرس و اضطراب بیجا منتقل شود. بهعنوان رهبر گروه خود، شما مجرای آنها به کسبوکار هستید؛ اطلاعات معنادار برایشان را تقطیر و زمینهمند میکنید. جاستین مارکوارت، شریک شرکت سرمایهگذاری خصوصی New Harbor Capital، موجز میگوید: «مهمتر از همه، آنها [CTOها] ارتباطگران قویای هستند، که هم برای تیم خود، هم برای رهبران ارشد دیگر و هم برای هیئتمدیره بهطور مؤثر توضیح میدهند آن نقشهراه چگونه با ابتکارهای راهبردی شرکت همراستا است، از جمله توانایی بالا آمدن از جزئیات فناوری زیربنایی برای انتقال اینکه ابتکارهای مختلف چگونه با هدفهای اصلی کسبوکار به هم مربوط میشوند.». شفافیت یعنی آنقدر محترم و سنجیده باشید که زمان بگذارید و اطلاعات را به شکلی پیشدستانه منتقل کنید. در این بخش، بررسی میکنیم چگونه باید ارتباط برقرار کنید و چه نوع و چه بسامدی از جلسهها را باید در نظر بگیرید.
۶.۷.۱ ایمیل
یکی از محبوبترین راههای توزیع اطلاعات هنوز ایمیل است. اگرچه سیستمهای چت روزبهروز همهجا دیده میشوند، مانند Slack، Mattermost، Cliq، Teams و غیره، باید با آنها مانند ارتباطات بلادرنگ برخورد شود، نه سابقه تاریخیای که انتظار دارید افراد بخوانند و عقبماندگی خود را جبران کنند. این سیستمها گذرا و برای لحظه هستند. از آنها برای پخش اطلاعات حیاتیای که میخواهید همه بخوانند استفاده نکنید. با ایمیل بمانید. باید برای کل گروه خود یک آدرس ایمیلی گروهی بسازید، مانند engineering@xxx.com، که همه افراد فعلی گروه را شامل شود. اینگونه نگران جا انداختن کسی نیستید، و بخشی از فرایند ورود/خروج نیرو بهروز نگه داشتن این فهرست است.
موضوعات زیر نامزدهای خوبی برای ایمیل سراسری گروه هستند:
- استخدامها/افزودهشدنها به گروه: معرفی سریع فردی که میپیوندد، همراه با خلاصهای کوتاه از دستاوردهایش، نقشی که خواهد داشت و زمانی که خواهد پیوست. همیشه بهتر است این ایمیل پیش از رسیدن فرد ارسال شود تا افراد نسبت به چهره تازه پذیراتر باشند.
- خاتمه همکاری/استعفا: به گروه اطلاع دهید کسی چه زمانی میرود، شامل تاریخ. دیگران را دعوت کنید در آرزوهای خوب شما برای آینده او شریک شوند. حتی در خاتمه همکاری، بهترینها را برایشان بخواهید. جملههایی مانند «ما دوطرفه توافق کردهایم که مسیر مشترکمان به پایان رسیده است» تمام چیزی است که لازم است بگویید، بدون ورود به جزئیاتی که ممکن است حساس باشد. اگر برای نقشی بهتر میروند، این واقعیت را جشن بگیرید که همه شما در گام حرفهای او نقشی داشتهاید.
- اعلانهای شرکت: برای هر اعلان گسترده شرکت که به اشتراک گذاشته شده، گاهی نیاز به ارتباط پیگیری از سوی شماست که کمک کند معنای آن برای گروه شما بهطور مشخص زمینهمند شود.
- اعلانهای گروه: نقطههای عطف بزرگ، موفقیتهای بزرگ و شناخت اعضای استثنایی تیم همگی نامزدهای خوبی برای صحبت با گروه هستند. همچنین هر شکست یا لغزش باید بدون انگشت اتهام برجسته شود، همراه با راهکارهایی که برای جلوگیری از تکرار در آینده اجرا میکنید.
- روندهای صنعتی که ممکن است بر شرکت اثر بگذارند: باید با احتیاط استفاده شوند و صرفا برای اشتراک لینک هر بار که چیز جالبی پیدا میکنید نباشند؛ برای آنها از یک کانال عمومی Slack استفاده کنید. اینها تغییرها یا جابهجاییهای بزرگی هستند که اثر نزدیکمدت تا بلندمدت بر شیوه کار گروه شما خواهند داشت.
در برابر میل به استفاده از فهرست توزیع برای موضوعات غیررسمی مقاومت کنید؛ میخواهید سابقهای بسازید که دریافتکنندگان وقتی این ایمیل را میگیرند بدانند نویز نیست، بلکه آنقدر مهم است که به آن توجه کنند.
سبک نوشتن
اگر با خودمان صادق باشیم، همه ما آن ایمیل یا متنی را نوشتهایم که آرزو میکنیم هرگز نفرستاده بودیم. یا لحن برخلاف نیت ما برداشت شده، شوخی نگرفته، یا کسی را آزردهایم، عمدی یا غیرعمدی. چنین ارتباطاتی هیچ جایی ندارند و هیچ کاری برای میراث شما نمیکنند.
سبک خود را پیدا کنید
بهترین توصیهای که از منتور فقیدم، Jeremy Geelan، روزنامهنگار، تهیهکننده BBC و ناشر، گرفتم این بود که طوری بنویسم انگار قرار است منتشر شود و برای همیشه بماند. پیش از فشردن Send، پس از بازخوانی، آیا خوشحال میشوید این متن دوباره چاپ شود؟ این آزمون ساده اما مؤثری است، چون هر بار که ایمیلی میفرستم صدای او را میشنوم که این را از من میپرسد؛ و بارها لحن را بازبینی و ویرایش کردهام.
نکتههایی برای نوشتن ایمیل حرفهای خوب برای توزیع گسترده شامل این موارد است:
- از صدای طبیعی خود استفاده کنید؛ تلاش نکنید بیش از حد رسمی باشید.
- از هیچ ناسزا، کنایه جنسی یا توهین استفاده نکنید.
- حمله شخصی، تحت هیچ شرایطی، نداشته باشید.
- صادق باشید: نه حدسپردازی، نه اغراق.
- حرفهای نگه دارید. متمرکز نگه دارید. صادق نگه دارید.
ارزش دارد به یاد داشته باشید که ایمیل هرگز حذف نمیشود. شرکتها روزبهروز بیشتر نسخههایی از تکتک ایمیلهای ارسال و دریافتشده را در خزانه حسابرسی ویژهای نگه میدارند که هرگز قابل دستکاری نیست. این میتواند به دلایل مقرراتی باشد، یا اگر شرکتی از نظر حقوقی بسیار محتاط است. سرویسهایی مانند G Suite و Office 365 راهاندازی این خزانه را بسیار ساده میکنند. بنابراین حتی اگر فکر میکنید ایمیل را حذف کردهاید، به محض اینکه از صندوق خروجی شما خارج شود، احتمالا برای پس گرفتنش دیر است. برای همیشه حفظ شده است، و چون شرکت مالک آن ایمیل است، ممکن است به نفع یا علیه شما استفاده شود.
۶.۷.۲ جلسهها
جلسهها بخش مهمی از چرخاندن چرخهای صنعت هستند. حتی اگر از ویدئوکنفرانس استفاده میکنید، حیاتی است که آن ارتباط شخصی را نه تنها با لیدهای تیم خود، بلکه با همه اعضای گروهتان داشته باشید. در این بخش، چند نوع رایج جلسه را مرور میکنیم که میخواهید استفاده کنید.
جلسه مهندسی
این جلسهای است برای اینکه به کل گروه خود بگویید اوضاع چگونه پیش میرود. جلسه مهندسی جلسهای است که یا هفتگی یا دوهفتهیکبار زمانبندی میشود و نباید بیش از ۳۰ دقیقه طول بکشد. موضوعات شامل جشن گرفتن انتشارهای بزرگ، جذب یا از دست دادن مشتری، بهبودهای فرایندی و تغییرات ساختاری است. قالب باید نسبتا ثابت باشد تا افراد به چیزی که باید انتظار داشته باشند عادت کنند. نگه داشتن آن در ۳۰ دقیقه به تیم شما اجازه میدهد خسته نشود و احساس کند هر جلسه ارزش وقتشان را برای گرد آمدن دارد.
جلسه Town Hall
جلسه Town Hall جلسهای ویژه است که باید برای موضوعی مشخص کنار گذاشته شود و فقط وقتی نیاز پیش آمد زمانبندی شود. قالب این جلسه شامل فردی است که پیشگام ارائه درباره موضوع موردنظر میشود و سپس پرسشوپاسخ باز با شرکتکنندگان دنبال میشود. این نوع جلسه بهویژه زمانی مفید است که ابتکار تازه، تغییر در جهت محصول یا چیزی از شرکت را پیشنهاد میدهید که باید برای گروه شما تقطیر شود. همچنین اگر میخواهید رهبر دیگری از جای دیگری در شرکت دعوت کنید تا توضیح دهد گروه او چه میکند یا تصمیمی که اخیرا گرفته چه اثری بر گروه شما خواهد داشت، این نوع جلسه خوب است.
جلسههای تیم
جلسههای منظم با رهبران تیم نه تنها شما را در جریان نگه میدارد، بلکه مطمئن میکند رهبران تیم دیگر هم از پیشرفت دیگران باخبرند. این جلسهها باید هفتهای یکبار برگزار شوند و روی مسائل سطح بالایی تمرکز کنند که هر تیم را تحت تأثیر قرار میدهد، بدون اینکه به بحث درباره جزئیات مشخص منحرف شوند. اگر چنین شد، که رایج است، آن را کنار بگذارید و افراد مربوط را دعوت کنید بعد از جلسه بمانند یا جلسه دیگری فقط با طرفهای لازم زمانبندی کنند. اینها را حداکثر ۶۰ دقیقه نگه دارید و به هر لید تیم همان مقدار زمان بدهید تا درباره وضعیت گروه خود گزارش دهد. دستورجلسهای بسازید که ترتیب بازی و زمانی را که به هرکدام میدهید روشن بیان کند، در حالی که در پایان برای هر کار دیگر فضا میگذارد.
جلسههای موردی
افراد زیادی مدت جلسه را بهطور پیشفرض ۶۰ دقیقه میگذارند؛ این اشتباه است و با رشد گروه و شرکت، زمان شما آرامآرام مکیده خواهد شد. در عوض، پیشفرض را ۱۵ یا ۳۰ دقیقه بگذارید و از افراد بخواهید فهرستی مشخص با یک یا دو مورد دستور جلسه تنظیم کنند تا همه بدانند چه انتظاری داشته باشند. جلسه یکی از مختلکنندهترین ابزارهای دنیای شرکتهاست، پس به زمانی که از افراد میخواهید دور میز، مجازی یا نه، جمع شوند احترام بگذارید.
قواعد جلسه تعاملی
اداره جلسه تعاملی چیزی بیش از کنار هم آوردن افراد و حرف زدن آنهاست. این تبادل کسبوکاری است، نه رویداد اجتماعی. قواعد باعث میشوند همه بر کار پیش رو تمرکز کنند تا نتیجه مطلوب بسیار سریعتر به دست آید. برخی پیشنهادها میتواند شامل اینها باشد:
- دستور جلسه باید از قبل توزیع شود، شامل هر ماده خواندنی.
- فقط افرادی را بیاورید که مشارکت خواهند کرد؛ افراد را صرفا برای در جریان نگه داشتن اضافه نکنید.
- وقفه مجاز نیست؛ تلفنهای همراه از روی میز کنار میروند.
- پذیرایی نداشته باشید؛ جلسه نباید آنقدر طولانی باشد که به میانوعده نیاز داشته باشید.
- لپتاپها فقط برای ارائه استفاده میشوند؛ هنگام بررسی ایمیل یا پیامها خیلی آسان است به عامل حواسپرتی تبدیل شوند.
جلسه باید متمرکز، پربازده و مناسب باشد. امروز ضبط جلسههای آنلاین آسان است، اما گاهی زیادهروی است. من معمولا ضبط جلسههایی را نگه میدارم که کاربران چیزی را نشان میدهند که برای مخاطبان گستردهتر مفید خواهد بود. صورتجلسه دستکم باید گرفته شود، یعنی یادداشت کردن هر اقدام پیگیریای که افراد برای انجام آن توافق کردهاند.
مطالعه بیشتر: Meetings Suck، Cameron Herold
خریدن کتاب Herold درباره اینکه چگونه جلسهها را بسیار پربازدهتر کنیم بهشدت توصیه میکنم. او وارد لجستیک اداره جلسهها، بسامد و تنظیم دستورجلسههایی میشود که افراد واقعا به آن پایبند میمانند. من در پادکست Demystifying Technology گروه MacLaurin با او مصاحبه کردم، جایی که مفصل درباره اینکه چگونه جلسهها میتوانند کارآمدتر شوند صحبت کردیم. ISBN-10: 1619614146 https://www.amazon.com/Meetings-Suck-Elements-Business-Valuable/dp/ 1619614146/
۶.۷.۳ بازخورد
مهم است برای پاسخ به هر پرسشی در دسترس هر فردی در گروه خود باشید، بدون اینکه احساس کنند حتما باید سلسلهمراتب را دنبال کنند. اینکه بهترین شیوه تعامل شما چیست کاملا به ترجیح ارتباطی شما بستگی دارد، اما مراقب باشید در کلاسیکترین شکل «در دفتر من همیشه باز است» صرفا در را باز نگذارید؛ افراد از آن استفاده خواهند کرد. در عوض، از همه دعوت کنید تماس بگیرند، و اگر احساس کردید موضوع به زمان بیشتری نیاز دارد، از آنها بخواهید ۱۵ دقیقه در تقویم شما زمان بگذارند تا بتوانید توجه و احترامی را که سزاوارند به آنها بدهید. صرفا رد کردن کسی یا گوش دادن به او در حالی که هنوز روی صفحهکلید تایپ میکنید بدترین کاری است که میتوانید انجام دهید. با این حال، نمیخواهید وقفههای پیوسته داشته باشید. به همین دلیل مهم است انتظارات خود را روشن و از ابتدا بیان کنید.
انتظارات را مدیریت کنید
من همیشه از افراد استقبال میکردم که با من راه بروند و حرف بزنند، یا اگر مهم بود، زمانی در تقویمم بگذارند. هرگز اجازه نمیدادم همان لحظه در گفتوگو کشیده شوم. سریع تشخیص میدادم آیا وضعیت بیش از پاسخی یکجملهای نیاز دارد یا نه، و اگر داشت، از آنها میخواستم زمانی در تقویمم پیدا کنند. اینگونه میدانستم میتوانم زمانی را که سزاوارند به آنها بدهم و هرگز آن کسی نباشم که همیشه وسط صحبت فرار میکند یا پیامها را چک میکند.
میخواهید مطمئن شوید واقعا در دسترس و پذیرنده هستید. این چیزی نیست که فقط چون خوب به نظر میرسد بگویید اما هرگز دنبالش را نگیرید. به کلماتتان عمل بدهید. افراد درک میکنند اگر به آنها بگویید مشغول هستید و موضوع آنقدر مهم است که صبر کند تا بتوانید توجه و تمرکز کامل خود را بدهید. این باعث میشود کارمند بهجای طردشدن، احساس مهم بودن کند.
جمعبندی
- ساختن منشور برای هر تیم که دقیقا مسئولیتش را فهرست کند، همه را آگاه و همراستا نگه میدارد.
- راههای زیادی برای چیدن تیمها وجود دارد، چه مهارتمحور، چه محصولمحور و چه فرایندمحور. هرکدام نقش خود را دارد و باید در برابر نیازهای شما ارزیابی شود.
- شما فقط تیم نمیسازید، بلکه مسیر حرفهایای میسازید تا افراد تکامل یابند و رشد کنند. وقت گذاشتن برای ترسیم این مسیر نشان میدهد برای توسعه تیم خود ارزش قائلید.
- تعریف ساختار برای عنوانها چیزی فراتر از عنوانهای خوشآواست؛ اینها نشانهایی هستند که بیرون از سازمان شما پوشیده میشوند و دیگران ناخودآگاه آنها را رتبهبندی و قضاوت میکنند.
- برقرار کردن فرایندی برای اینکه چگونه میخواهید لیدهای تیم گزارش دهند، همراه با سطح جزئیات و آهنگ مورد انتظار، مطمئن میکند افراد شما را ناامید نمیکنند.
- تشویق و ترویج جلسههای فردی یکبهیک به شما فرصت میدهد با افراد روی مهارتهای نرمترشان کار کنید.
- داشتن برنامه آموزشی پیوسته مهم است، نه فقط برای مرتبط نگه داشتن تیم، بلکه برای اینکه افراد رشتههای تازهای را کاوش کنند که شاید بعدا مفید باشد.
- بهعنوان رهبر، تصمیمگیری درباره سبک ارتباطیتان مهم است، اما گشودگی و شفافیت بیشتر باعث میشود افراد بیشتر به شما اعتماد کنند و نسبت به تصمیمهایتان اطمینان بیشتری داشته باشند.
چکلیست
چند مورد از موارد زیر را میتوانید ادعا کنید که پوشش دادهاید؟
- منشوری ساختهاید که دلیل وجود یک تیم مشخص و شاخصهای موفقیت آن را توضیح میدهد
- بهروشنی تعریف کردهاید هر تیم چگونه ساختار یافته و با کسبوکار همراستا میشود
- درباره هر عنوان در تیم خود و معنای داخلی و بیرونی آن فکر کردهاید
- روشن کردهاید میخواهید لیدهای تیم چگونه بهطور دورهای پیشرفتشان را به شما گزارش دهند
- جلسههای منظم یکبهیک با لیدهای تیم خود زمانبندی کردهاید
- به تیم خود حمایتی را که از یادگیری و بهبود مستمر میکنید بیان کردهاید
- جلسههایی در تقویم خود با هدف و نتیجه روشن زمانبندی کردهاید تا افراد بدانند زمانشان هدر نمیرود
خلاصه هوش مصنوعی
خلاصه فصل
مدیریت تیم مهندسی فراتر از مدیریت پروژه است: ساخت تیمهای معنادار، انتخاب ساختار مناسب (عملکردی، ماتریسی، اسکواد و غیره)، آموزش مداوم، کانالهای ارتباطی و قواعد جلسات. فصل تأکید میکند که تیمهای قوی با انتظارات روشن، بازخورد منظم و روالهای سالم ساخته میشوند.
- ساختار تیم باید با اندازه شرکت، نوع محصول و سرعت تحویل همخوان باشد.
- آموزش و بهروز نگه داشتن مهارتها سرمایهگذاری بلندمدت روی تیم است.
- جلسات با هدف مشخص (ایستاده، برنامهریزی، بازبینی) از اتلاف وقت جلوگیری میکنند.
این خلاصه با کمک هوش مصنوعی بر اساس محتوای فصل تهیه شده و جایگزین مطالعه کامل متن نیست.