Всім привіт! Мене звуть Людмила Макарова, я менеджер розробки в УБРіР та третина моєї команди – «універсали».
Визнайте: кожен Tech Lead мріє про крос-функціональність усередині своєї команди. Адже це так круто, коли одна людина здатна замінити трьох, та ще й зробити це якісно, не зсуваючи термінів. І, що важливо, це забезпечує економію ресурсів!
Звучить дуже привабливо, але чи це так насправді? Спробуймо розібратися.
Хто він, наш передбачник очікувань?
Під поняттям «універсал» зазвичай розуміють членів команди, які поєднують у собі більше однієї ролі, наприклад, розробник-аналітик.
Взаємодія команди та результат її роботи залежать від професійних та особистісних якостей учасників.
По hard skills все ясно, а ось soft skills заслуговують на особливу увагу. Вони допомагають знайти підхід до співробітника та направити його саме на те завдання, на якому він буде максимально корисним.
Існує багато статей про різні типи особистостей представників IT-індустрії. Маючи свій досвід, я б поділила IT-універсалів на чотири категорії:
1. «Універсал – всемогутній»
Такі є скрізь. Вони завжди виявляють велику активність, хочуть бути в центрі уваги, постійно цікавляться у колег, чи потрібна їхня допомога, іноді навіть можуть дратувати. Їх цікавлять лише значущі завдання, участь у яких дасть простір для творчості та зможе потішити самолюбство.
У чому сильні:
- здатні розв'язувати складні завдання;
- глибоко поринають у проблему, «копають» і досягають результату;
- мають допитливий розум.
але:
- емоційно лабільні;
- слабо керовані;
- мають свою непохитну точку зору, яку дуже складно змінити;
- складно змусити зробити просту справу. Легкі завдання зачіпають самолюбство всемогутніх.
2. "Універсал - розберуся і зроблю"
Таким людям достатньо мануалу і небагато часу – і вони вирішать питання. Зазвичай вони мають за спиною великий бекграунд як DevOps. Такі універсали не турбують себе проектуванням і вважають за краще використовувати метод розробки тільки на основі виключно свого досвіду. Можуть запросто закуситися з техлідом щодо обраного варіанта реалізації завдання.
У чому сильні:
- самостійні;
- стресостійкі;
- компетентні у багатьох питаннях;
- ерудовані - з ними завжди є про що поговорити.
але:
- часто порушують зобов'язання;
- схильні все ускладнювати: вирішують таблицю множення інтегруванням частинами;
- якість роботи низька, все виходить із 2-3 рази;
- постійно зсувають терміни, тому що насправді все виявляється не так просто.
3. «Універсал – гаразд, давайте я, раз більше нема кому»
Співробітник непогано розуміється на кількох областях і має відповідний досвід. Але йому не вдається стати професіоналом у жодній з них, тому що його часто використовують як рятувальний круг, затикаючи дірки за поточними завданнями. Податливий, виконавчий вважає себе затребуваним, проте таким не є.
Практичний ідеальний співробітник. Швидше за все, він має напрям, який йому більше подобається, але через розмиття компетенцій розвитку не відбувається. У результаті людина ризикує стати незатребуваною та емоційно вигорілою.
У чому сильні:
- відповідальні;
- орієнтовані на результат;
- спокійні;
- повністю контрольовані.
але:
- показують середній результат через низький рівень компетенцій;
- не можуть вирішувати складні та абстрактні завдання.
4. «Універсал – майстер своєї справи»
Людина з серйозним бекграундом розробника має системне мислення. Педантичний, вимогливий до себе та команди. Будь-яке завдання з його участю може розростутися до нескінченності, якщо не позначити межі.
Добре знайомий із архітектурою, вибирає метод технічної реалізації, ретельно аналізуючи вплив обраного рішення на поточну архітектуру. Скромен, не амбітний.
У чому сильні:
- показують високу якість роботи;
- здатні вирішити будь-яке завдання;
- дуже працездатні.
але:
- нетерпимі до думки інших;
- максималісти. Намагаються все зробити правильно, а це збільшує термін розробки.
Що маємо на практиці?
Подивимося, як найчастіше поєднуються ролі та компетенції. За відправну точку візьмемо стандартну команду розробки: PO, менеджер з розробки (техлід), аналітики, програмісти, тестувальники. Власника продукту і техлід вважати не будемо. Першого – через відсутність технічних компетенцій. Другий, якщо в команді проблеми, якраз має вміти робити все.
Найбільш поширений варіант об'єднання/злиття/суміщення компетенцій – розробник-аналітик. Також дуже часто зустрічаються аналітик-тестувальник і "три в одному".
На прикладі своєї команди покажу, у чому плюси та мінуси колег-універсалів. У моїй команді їхня третина, і я їх дуже люблю.
Від PO надійшло термінове завдання щодо впровадження нових тарифів у існуючий продукт. У моїй команді 4 аналітики. На той момент один перебував у відпустці, інший захворів, а решта займалася реалізацією стратегічних завдань. Якби я висмикнула їх, це неминуче зірвало б термін реалізації. Залишився єдиний вихід: використовувати «секретну зброю» – універсал розробника-аналітика, який володів потрібною предметною областю. Назвемо його Анатолієм.
Його тип особистості – «універсал - розберуся і зроблю». Звичайно, він довго намагався пояснити, що у нього «повний беклог своїх завдань», але моїм вольовим рішенням було відправлено на вирішення термінового завдання. І Анатолій упорався! Він провів постановку та виконав реалізацію вчасно, а замовники залишилися задоволеними.
На перший погляд, все вдалося. Але через кілька тижнів щодо цього продукту знову виникли вимоги щодо доопрацювання. Тепер постановкою із цього завдання займався «чистий» аналітик. На етапі тестування нової розробки ми довго не могли зрозуміти, чому у нас виникають помилки щодо прив'язки нових тарифів і лише потім, розмотавши весь клубок, докопалися до істини. Ми витратили купу часу та зірвали терміни.
Проблема полягала в тому, що багато прихованих моментів і підводних каменів залишилися тільки в голові нашого універсала і не були перенесені на папір. Як пізніше пояснив Анатолій, він надто поспішав. Але найімовірніший варіант, що він натрапив на проблеми вже при розробці і просто їх обійшов, ніде це не відобразивши.
Була й інша ситуація. Зараз у нас лише один тестувальник, тому деякі завдання доводиться тестувати аналітикам, у тому числі універсалам. Тому один таск я віддала умовному Федору – «універсалу – гаразд, давайте я, раз більше нема кому».
Федір – «три в одному», але з цього завдання вже було виділено розробника. Отже, Феді треба було поєднати у собі лише аналітика та тестувальника.
Вимоги зібрані, специфікацію передано в розробку, настав час тестувати. Федір знає систему «як свої п'ять пальців», що допрацьовується, і досконально опрацьовував поточні вимоги. Тому він не став турбувати себе написанням тестових сценаріїв, а провів тестування на те, «як система має працювати», потім – передав користувачам.
Тест завершився, доопрацювання пішло на пром. Пізніше з'ясувалося, що система не тільки призупиняє проведення платежів на певні балансові рахунки, а й блокує проведення платежів із дуже рідкісних внутрішніх рахунків, які не повинні були брати участь у цьому.
Це сталося через те, що Федір не провів перевірку на те, як «не мусить працювати система», не склав тест-план, чек-листи. Він вирішив заощадити на термінах і поклався на власне чуття.
Як працюємо з проблемами?
Подібні ситуації впливають на ефективність роботи команди, якість релізів, що випускаються, і задоволеність замовників. Тому їх не можна залишати без уваги та аналізу причин.
1. За кожним завданням, що викликало складності, я прошу заповнити уніфіковану форму: карту помилок, яка дозволяє виявити етап, на якому відбулася «просідання»:
2. Після виявлення вузьких місць з кожним співробітником, який вплинув на проблему, проводиться мозковий штурм «Що змінити?» (приватні випадки ми розглядаємо на ретро), за підсумками якого народжуються конкретні дії (кожного типу особистості свої) з термінами.
3. Ми запровадили правила взаємодії всередині команди. Наприклад, домовилися обов'язково фіксувати всю інформацію про перебіг завдання у системі управління проектів. При зміні/виявленні артефактів у процесі розробки необхідно відображати це на основі знань і підсумкової версії ТЗ.
4. Контроль став проводитися кожному етапі (особлива увага приділяється проблемним етапам у минулому) і автоматично за результатами виконання наступного завдання.
5. Якщо результат з наступного завдання не змінився, то універсала, що розглядається, не ставлю в ту роль, з якою він погано справляється. Намагаюся оцінити його здатність та бажання до розвитку компетенцій у цій ролі. Якщо не знаходжу відгуку, залишаю його в тій ролі, яка йому ближча.
Що зрештою вийшло?
Процес розробки став прозорішим. Зменшився BUS-фактор. Члени команди, працюючи над помилками, стають мотивованими, покращують свою карму. Ми поступово підвищуємо якість наших релізів.
Висновки
У співробітників-універсалів є свої плюси та мінуси.
Переваги:
- можна в будь-який момент закрити завдання, що провисає, або дозволити терміновий баг в короткі терміни;
- комплексний підхід під час вирішення завдання: виконавець дивиться неї з боку всіх ролей;
- універсали можуть практично все робити однаково добре.
Недоліки:
- зростає BUS-фактор;
- розмиваються основні компетенції, властиві ролі. Через це знижується якість роботи;
- підвищується можливість зсуву термінів, т.к. відсутній контроль за кожним етапом. Також виникають ризики вирощування «зірки»: співробітник упевнений, що він краще знає, що він – профі;
- збільшується ризик професійного вигоряння;
- багато важливої інформації про проект може залишитися лише у голові у співробітника.
Як бачите, недоліків більше. Тому універсалами я користуюся лише в тому випадку, якщо не вистачає ресурсів, а завдання досить термінове. Або людина має компетенції, яких недостатньо в інших, а на кону стоїть якість.
Якщо спільної роботи над завданням дотримується правило розподілу ролей, то якість роботи зростає. На проблеми ми дивимося з різних боків, погляд не замилюється, завжди з'являються свіжі думки. При цьому кожен учасник команди має всі можливості для професійного зростання та розширення своїх компетенцій.
Я вважаю, що найважливіше – відчувати свою причетність до процесу, займатися своєю роботою, поступово збільшуючи широту своїх компетенцій. Тим не менш, універсали в команді приносять користь: головне зробити так, щоб вони ефективно поєднували різні ролі.
Бажаю всім команди «універсалів-майстрів своєї справи», що самоорганізується!
Джерело: habr.com