«Универсал» в команде разработки: польза или вред?

Всем привет! Меня зовут Людмила Макарова, я менеджер разработки в УБРиР и треть моей команды – «универсалы».

Признайте: каждый 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