"جهانی" در تیم توسعه: سود یا ضرر؟

سلام به همه! نام من لیودمیلا ماکاروا است، من یک مدیر توسعه در UBRD هستم و یک سوم تیم من "عمومی" هستند.

اعتراف کنید: هر رهبر فنی رویای عملکرد متقابل در تیم خود را دارد. خیلی جالب است که یک نفر بتواند سه نفر را جایگزین کند، و حتی این کار را بدون تاخیر در ضرب الاجل انجام دهد. و مهمتر از همه، باعث صرفه جویی در منابع می شود!
بسیار وسوسه انگیز به نظر می رسد، اما آیا واقعا اینطور است؟ بیایید سعی کنیم آن را بفهمیم.

او پیشرو انتظارات ما کیست؟

اصطلاح "عمومی" معمولاً به اعضای تیمی اطلاق می شود که بیش از یک نقش را ترکیب می کنند، به عنوان مثال، توسعه دهنده-تحلیلگر.

تعامل تیم و نتیجه کار آن به ویژگی های حرفه ای و شخصی شرکت کنندگان بستگی دارد.

همه چیز در مورد مهارت های سخت روشن است، اما مهارت های نرم سزاوار توجه ویژه هستند. آنها به یافتن رویکردی برای یک کارمند کمک می کنند و او را به سمت کاری هدایت می کنند که در آن بیشترین استفاده را داشته باشد.

مقالات زیادی در مورد انواع تیپ های شخصیتی در صنعت IT وجود دارد. بر اساس تجربه‌ام، من متخصصان فناوری اطلاعات را به چهار دسته تقسیم می‌کنم:

1. "جهانی - قادر مطلق"

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

در چه مواردی قوی هستند:

• قادر به حل مسائل پیچیده هستند؛
• عمیقاً در مشکل فرو بروید، "کاوش کنید" و به نتایج برسید.
• ذهن کنجکاو داشته باشید

اما:

• از نظر احساسی ناپایدار؛
• مدیریت ضعیف؛
• دیدگاه تزلزل ناپذیر خود را دارند که تغییر آن بسیار دشوار است.
• سخت است کسی را وادار به انجام یک کار ساده کنید. کارهای آسان به نفس قادر متعال صدمه می زند.

2. "Universal - من آن را کشف خواهم کرد و آن را انجام خواهم داد"

چنین افرادی فقط به یک کتابچه راهنمای کاربر و کمی زمان نیاز دارند - و آنها مشکل را حل خواهند کرد. آنها معمولا پیشینه قوی در DevOps دارند. چنین کلی گراها خودشان را با طراحی خسته نمی کنند و ترجیح می دهند از یک روش توسعه تنها بر اساس تجربه خود استفاده کنند. آنها به راحتی می توانند با مسئول فنی در مورد گزینه انتخاب شده برای اجرای کار بحث کنند.

در چه مواردی قوی هستند:

• مستقل؛
• مقاوم در برابر استرس؛
• شایستگی در بسیاری از مسائل؛
• دانشمند - همیشه چیزی برای صحبت با آنها وجود دارد.

اما:

• اغلب تعهدات را نقض می کنند.
• مایل به پیچیده کردن همه چیز هستند: جدول ضرب را با ادغام کردن با قطعات حل کنید.
• کیفیت کار پایین است، همه چیز 2-3 بار کار می کند.
• آنها دائماً ضرب الاجل ها را تغییر می دهند، زیرا در واقعیت همه چیز به این سادگی نیست.

3. "یونیورسال - باشه، بگذار این کار را بکنم، چون هیچ کس دیگری وجود ندارد"

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

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

در چه مواردی قوی هستند:

• مسئول
• نتیجه گرا؛
• آرام؛
• کاملا کنترل شده

اما:

• نشان دادن نتایج متوسط ​​به دلیل سطح پایین شایستگی ها؛
• نمی تواند مسائل پیچیده و انتزاعی را حل کند.

4. "همه کاره در کار خود استاد است"

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

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

در چه مواردی قوی هستند:

• نشان دادن کیفیت بالای کار؛
• قادر به حل هر مشکلی است؛
• بسیار کارآمد

اما:

• عدم تحمل عقاید دیگران؛
• حداکثر گرایان آنها سعی می کنند همه چیز را درست انجام دهند و این باعث افزایش زمان توسعه می شود.

در عمل چه داریم؟

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

رایج ترین گزینه برای ترکیب/ادغام/ترکیب شایستگی ها توسعه دهنده-تحلیلگر است. تحلیلگر تست و "سه در یک" نیز بسیار رایج هستند.

با استفاده از تیم خود به عنوان مثال، من به شما مزایا و معایب همکاران عمومی خود را نشان خواهم داد. یک سوم آنها در تیم من هستند و من آنها را بسیار دوست دارم.

PO یک وظیفه فوری برای معرفی تعرفه های جدید در یک محصول موجود دریافت کرد. تیم من 4 تحلیلگر دارد. در آن زمان یکی در تعطیلات بود، دیگری مریض بود و بقیه مشغول اجرای وظایف استراتژیک بودند. اگر آنها را بیرون می کشیدم، به ناچار مهلت اجرا را مختل می کرد. تنها یک راه وجود داشت: استفاده از "سلاح مخفی" - یک توسعه دهنده-تحلیلگر همه کاره که بر حوزه موضوع مورد نیاز تسلط داشت. بیایید او را آناتولی صدا کنیم.

تیپ شخصیتی او است "جهانی - من آن را کشف خواهم کرد و آن را انجام خواهم داد". البته، او مدتها سعی کرد توضیح دهد که "کارهایش را به طور کامل پشت سر گذاشته است"، اما با تصمیم قوی من او را برای حل یک مشکل فوری فرستادند. و آناتولی این کار را کرد! صحنه سازی را انجام داد و به موقع اجرا را به پایان رساند و مشتریان راضی بودند.

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

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

وضعیت دیگری وجود داشت. اکنون ما فقط یک آزمایشگر داریم، بنابراین برخی از وظایف باید توسط تحلیلگران، از جمله متخصصان عمومی، آزمایش شوند. بنابراین، من یک وظیفه به فدور مشروط دادم - "جهانی - باشه، اجازه بده این کار را بکنم، چون هیچ کس دیگری نیست".
Fedor یک "سه در یک" است، اما یک توسعه دهنده قبلاً برای این کار اختصاص داده شده است. این بدان معناست که فدیا مجبور بود فقط یک تحلیلگر و یک آزمایشگر را ترکیب کند.

الزامات جمع آوری شده است، مشخصات به توسعه ارائه شده است، زمان آزمایش فرا رسیده است. فدور می‌داند که سیستم در حال اصلاح «مثل پشت دست او» است و الزامات فعلی را کاملاً بررسی کرده است. بنابراین، او خود را با نوشتن اسکریپت های آزمایشی خسته نکرد، بلکه آزمایش هایی را در مورد "نحوه عملکرد سیستم" انجام داد، سپس آن را به کاربران منتقل کرد.
آزمایش کامل شد، تجدید نظر به تولید رفت. بعداً مشخص شد که این سیستم نه تنها پرداخت به حساب‌های موجودی خاصی را به حالت تعلیق درآورده است، بلکه پرداخت‌های حساب‌های داخلی بسیار کمیاب را که قرار نبود در این امر مشارکت داشته باشند، مسدود کرده است.

این به این دلیل اتفاق افتاد که فدور بررسی نکرد که چگونه "سیستم نباید کار کند" ، یک برنامه آزمایشی یا چک لیست تهیه نکرد. او تصمیم گرفت در زمان صرفه جویی کند و به غرایز خود تکیه کند.

چگونه با مشکلات کنار بیاییم؟

موقعیت هایی مانند این ها بر عملکرد تیم، کیفیت انتشار و رضایت مشتری تأثیر می گذارد. بنابراین نمی توان آنها را بدون توجه و تحلیل دلایل رها کرد.

1. برای هر کاری که باعث ایجاد مشکل شده است، از شما می خواهم یک فرم یکپارچه را پر کنید: یک نقشه خطا، که به شما امکان می دهد مرحله ای را که در آن "کاهش" رخ داده است شناسایی کنید:

2. پس از شناسایی تنگناها، یک جلسه طوفان فکری با هر یک از کارمندانی که بر مشکل تأثیر گذاشته اند برگزار می شود: "چه چیزی را باید تغییر داد؟" (ما موارد خاصی را به گذشته در نظر نمی گیریم) که در نتیجه اعمال خاصی (مشخص برای هر تیپ شخصیتی) با ضرب الاجل متولد می شود.

3. ما قوانینی را برای تعامل در تیم معرفی کرده ایم. به عنوان مثال، ما موافقت کردیم که لزوماً تمام اطلاعات مربوط به پیشرفت یک کار را در سیستم مدیریت پروژه ثبت کنیم. هنگامی که مصنوعات در طول فرآیند توسعه تغییر/شناسایی می‌شوند، این باید در پایگاه دانش و نسخه نهایی مشخصات فنی منعکس شود.

4. کنترل در هر مرحله شروع شد (توجه ویژه ای به مراحل مشکل ساز در گذشته شده است) و به طور خودکار بر اساس نتایج کار بعدی انجام می شود.

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

آنچه در پایان اتفاق افتاد؟

روند توسعه شفاف تر شده است. فاکتور BUS کاهش یافته است. اعضای تیم که روی اشتباهات کار می کنند، انگیزه بیشتری پیدا می کنند و کارمای خود را بهبود می بخشند. ما به تدریج در حال بهبود کیفیت انتشارات خود هستیم.

یافته ها

کارمندان جنرالیست مزایا و معایب خود را دارند.

مزایا:

• شما می توانید هر زمان که بخواهید یک کار ضعیف را ببندید یا یک اشکال فوری را در مدت زمان کوتاهی حل کنید.
• یک رویکرد یکپارچه برای حل یک مشکل: مجری از منظر همه نقش ها به آن نگاه می کند.
• ژنرال ها تقریباً همه چیز را به همان اندازه خوب می توانند انجام دهند.

معایب:

• ضریب اتوبوس افزایش می یابد.
• شایستگی های اصلی ذاتی نقش فرسایش می یابد. به همین دلیل، کیفیت کار کاهش می یابد.
• احتمال تغییر در ضرب الاجل افزایش می یابد، زیرا هیچ کنترلی در هر مرحله وجود ندارد. همچنین خطرات رشد یک "ستاره" وجود دارد: کارمند مطمئن است که بهتر می داند که یک حرفه ای است.
• خطر فرسودگی شغلی افزایش می یابد.
• بسیاری از اطلاعات مهم در مورد پروژه می تواند فقط "در سر" کارمند باقی بماند.

همانطور که می بینید، کمبودهای بیشتری وجود دارد. بنابراین، من فقط در صورتی که منابع کافی وجود نداشته باشد و کار کاملاً فوری باشد، از کلیات استفاده می کنم. یا فردی شایستگی هایی دارد که دیگران فاقد آن هستند، اما کیفیت در خطر است.

اگر قاعده توزیع نقش ها در کار مشترک روی یک کار رعایت شود، کیفیت کار افزایش می یابد. ما از زوایای مختلف به مشکلات نگاه می کنیم، دید ما تار نیست، افکار تازه همیشه ظاهر می شوند. در عین حال، هر یک از اعضای تیم هر فرصتی برای رشد حرفه ای و گسترش شایستگی های خود دارند.

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

برای همه آرزو می کنم یک تیم خودسازمانده از "استادان جهانی صنعت خود" داشته باشند!

منبع: www.habr.com