Короткая ссылка: MultySpecTeam

Специализация в IT все возрастает, и все они нужны в разработке. Раньше достаточно было разработчика широкого профиля вместе с аналитиком, потом появилась специализация на front-end и back-end. А сейчас есть специализации на каждую мобильную платформу, и в целом количество специализаций превышает ограничение численности эффективной команды 7±2. В посте была описана именно такая ситуация, и сейчас я пишу по мотивам обсуждения. Там был дан пример команды.

Аналитик
BackEnd разработчик
Разработчик АБС (Банковская система)
Веб-разработчик
iOs разработчик
Android разработчик
Тестировщик

Мы имеем уже семь узких специализаций. И многие практики перестают работать: непонятно, как делать оценку, потому что каждый компетентен в своей области. Непонятно, как обеспечить взаимозаменяемость специалистов, чтобы снять критичность при болезни одного, как избежать пробок в потоке работы из-за перегрузки одного специалиста и что делать с неполной загрузкой.

Универсальных рецептов тут, естественно, нет, однако, это не означает, что все надо придумывать самому. Есть достаточно много практик, из которых можно выбирать подходящие для ваших условий, и которые я выношу в пост. И хотя все написано на IT-примерах, это достаточно легко обобщается и на бизнес-команды, в которых вопрос специализаций стоит еще острее.

Содержание

1 Много специализаций в команде
- 1.1 Взаимозаменяемость в команде
- 1.2 Оценка при многих специализациях
2 Альтернативные способы организации
- 2.1 Инфраструктурные команды
- 2.2 Конвейер разработки

Много специализаций в команде

Взаимозаменяемость в команде

Для начала примем, что в команде действительно необходимо так много специализаций. Приведенный выше состав команды вырастает из требования, чтобы в команде был полный набор компетентных специалистов, чтобы выпускать конечную ценность, то есть делать пользовательские user story. И в принципе 7 специализаций - еще допустимое число. Но если специализацией обладает только один человек, то каждый становится критичным ресурсом и, потенциально, узким горлом, если вдруг в потоке пошли задачи со сложностью в конкретной специализации. Способ ухода от этого - накапливать взаимозаменяемость. Например, простые операции с базой данных (добавить таблицу или поле) обычно вполне доступны разработчикам backend с одной стороны или аналитикам с другой. И так далее. Каждый из специалистов может выделить такие простые задачи, кратко описать как делаем и передавать их другим, чтобы не быть узким местом при разработке.

Оценка при многих специализациях

Теперь надо сконструировать способ оценки работ и планирования. Именно сконструировать, потому что обычные подходы рассчитаны на базовое предположение о кроссфункциональности команды, а оно выполняется плохо. И начнем, естественно, от использования оценки, она же нужна не просто "чтобы было". Есть два назначения. Product Owner должен понять стоимость user story, и принять решение, что эта стоимость его устраивает, то есть ценность превышает стоимость, не надо что-то упрощать. И второе - команда должна ориентироваться на оценку, выбирая истории в sprint, чтобы все выполнить. И вот если говорить про второе, то в условиях такой специализации любой из членов команды может стать узким местом, ограничением.

Теория ограничений Голдратта говорит, что, как правило, ограничение - единственное. Если так, то его надо выявить и именно эта оценка для задачи будет основной. А остальные можно добавлять пропорционально составу команды. Многие, кстати, так делают, оценивая аналитику и тестирвоание как добавки к основной разработке. И это разумно, потому что если каждый делает свою часть, и люди не могут друг друга заменить, то время, затраченное командой на задачу будет равно времени самой долгой работой, остальные специалисты просто будут простаивать или плодить незавершенные работы, что еще хуже. При этом те истории, которые не задействуют основного специалиста, если они есть, оказываются практически бесплатны. Однако, если поток user story не является однородным, то тогда надо, чтобы каждый оценивает свою часть, а дальше можно принимать оценку по самой трудоемкой, добавляя остальное в процентах.

Какие при этом есть недостатки? Главное - если каждый из специалистов оценивает свою часть, то мы становимся заложниками их понимания каждой истории, на планировании не происходит общения и синхронизации понимания - что есть отдельная ценность Agile. Трактовки user story по сложности могут сильно отличаться и люди могут увидеть необходимость сложного алгоритма там, где предполагалась простая проверка и наоборот. Если у нас именно такая ситуация, то необходимо коллективное обсуждение в процессе оценки, а это означает, что оценивать должны все, чтобы выработать общее понимание. Но тогда нельзя оценивать в story point, надо использовать размер истории, например, простые, средние, сложные, очень сложные. При этом члены команды соотносят новую историю с ранее выполнявшимися и выносят вердикт. А PO пересчитывает размеры историй в трудоемкость, опираясь на прошлый опыт. В целом это и для PO может оказаться проще - объяснить новую задачу через старые. Однако, практика работает только если команда уже работает некоторое время и эта история решения задач - есть.

Если опыт достаточно большой, то можно калибровать размеры историй через примеры и примерную трудоемкость, например: "к средним историям у нас относится два типа задач: (1) сделать форму для ввода, обычно у нас занимают столько-то времени у таких-то специализаций; и (2) сделать отчет обычно у нас занимают столько-то времени у таких-то специализаций". Такая калибровка особенно полезна, когда в команде меняется состав и новым участникам надо освоить шкалы оценки. Список каждая команда может формировать и накапливать сама, но при этом списки разных всех команд должны быть в общем доступе для обмена опытом и взаимного сравнения.

А еще в описании задачи обязательно фиксировать аналогию истории, и когда ее будут реализовывать - то смотреть за ее соблюдением. Если вскрываются какие-то особенности задачи, которые делают решение по аналогии непригодным, то необходимо в момент возникновения проинформировать и PO и других заинтересованных лиц. Daily Scrum Meenting подойдет, но при условии что к его моменту не уйдешь далеко по альтернативной ветви, и психологически будешь готов отказаться. Переписка в таск-трекере тоже, но только в таком варианте, когда получатели сообщений будут понимать: идет не рабочее уточнение задачи, а нештатная ситуация, требующая внимания.

Итого, для оценки есть два способа: каждый оценивает свое, и тут можно выдавать трудоемкость, или коллективная оценка по размеру историй.

Альтернативные способы организации

Инфраструктурные команды

Простой вариант - когда часть специализаций можно вынести за пределы команды. Это подходит в случае, когда основная масса задач с точки зрения специализации является типовой и может быть выполнена широким кругом разработчиков, как, например, добавление полей и таблиц в базу данных. Тогда специалисты по базе данных высокого уровня собираются в отдельную команду поддержки производства, у которой есть две задачи:

организовывать выполнение типовых задач по базе данных силами обычных разработчиков внутри команды
выполнять по запросу нетривиальные задачи по базе данных, такие как оптимизация запросов или обеспечение эффективного хранения не типовыми способами

Первая задача подразумевает определение набора типовых задач и поддержание инструкций по их выполнению. Но - не только это. Важно, во-первых, наблюдать за практическим выполнением этих типовых задач силами команд. имея доступ к кодам и базе данных для того, чтобы во-время скорректировать неверные действия. В том числе возникающие из-за несовершенства самих инструкций, которые тоже надо совершенствовать. А, во-вторых, желателен предварительный аудит задач до планирования, потому что не-специалисты могут ошибаться в квалификации задачи. Оба этих аспекта не слишком обремен6ительны, это по сути практики code review и review требований, которые можно сделать технологично и не слишком затратно. Но их необходимо отдельно ставить, сами собой они не появляются - об этом часто забывают.

А вторая задача подразумевает, что у команда специалистов по базе данных работа организована таким образом, что время обработки нетривиального запроса сопоставимо с его трудоемкостью. То есть запрос не попадает в хвост очереди на следующий квартал, а обрабатывается в темпе появления с ограниченной средней задержкой. Это может быть несколько непонятным, поэтому я поясню. В идеале, естественно, есть желание гарантировать время выполнения любого запроса, но это сделать нельзя - именно потому, что нетривиальные запросы имеют переменную трудоемкость. Однако, должно быть гарантировано, что запрос будет рассмотрен и попадет в очередь на обработку, это во-первых. А во-вторых, мощность команды достаточна для обработки средней очереди, существенных задержек не происходит. Грубо говоря, каждый день команда завершает какие-то задачи, и берет новые задачи из очереди, и очередь - короткая, а выборка из нее очередных задач - штука прогнозируемая.

Для практической организации таких работ хорошо подходит Kanban. При этом необходима организация обработки, как минимум, трех типов задач

Задачи на оценку новых работ, которые должны проходить с большим приоритетом и по которым как раз должен быть SLA по срокам завершения задачи. При этом завершение может быть в варианте: задача - супер-сложная и требует такого-то времени даже на проработку первого этапа - то есть перемещается во вторую очередь.
Задачи обработки нетривиальных задач по работам с базой данных
Задачи по улучшению правил решения типовых задач - добавление задач новых типов, улучшение инструкций и тому подобное.

Третий поток очень важен, так как такой функциональный отдел будет работать эффективно только в том случае, если 70-90% задач по работе в базой данных являются типовыми, то есть качественно выполняются силами самих команд. Иначе он превратиться в узкое место.

Все это вместе означает, что команда базы данных является инфраструктурой, которая поддерживает работу основных команд по требованию и для в нее заложен резерв мощности, который как раз и тратится на третий поток задач. Аналогичные решения можно применять, например, для взаимодействия с АБС, если оно касается преимущественно интеграции, а не доработок внутри.

С точки зрения оценки и планирования работ при такой организации есть дополнительный этап подготовки backlog, на котором идентифицируются нетривиальные задачи и запрашивается их оценка у специализированных команд. Далее, в зависимости от характера задач и трудоемкости, может быть включение задачи в очередь с фиксацией ожиданий, а могут быть и более нетривиальные решения, например, временное включение специалиста в команду разработки на время спринта, в котором выполняются такие не типовые задачи.

Конвейер разработки

Можно поделить команды на несколько, зацепив в конвейер через Kanban по фазам прохождения user story. Например, есть компании, где в одной команде находятся аналитики и web-дизайнеры, а от них задача уходит front и back-разработчикам, а те передают тестировщикам и delivery. Такой способ хорошо подходит, если есть поток задач и каждая имеет отдельную ценность, а если есть спринты и выпуск релизов, то это сильно сложнее, хотя можно делать сдвинутые спринты команд относительно друг друга. Кроме того, такой подход несет проблемы классического подхода со слабой коммуникацией и перекидыванием проблем.

Оцениваться при этом может каждый этап отдельно, а может быть оценка только по этапу основных затрат. служащих ограничением - в соответствии с TOC Голдратта.