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

Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь организовывать разработку правильно. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно. Наверное.

В глубины!

Во времена стародавние все люди умели делать более-менее всё. Да и уметь там особо много не надо было – разжечь огонь, выследить зверя и метко кинуть копье – вот и весь спектр занятий человека того времени. Команды тогда делились на тех, кто дома с детьми, и на тех, кто на охоте. Нам те времена не сильно интересны, ~~мы же не о равноправии полов тут рассуждаем~~.

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

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

Если перенестись в современность и пойти промышленное производство, мы можем увидеть именно такую структуру – цеха, и изделия, путешествующие из цеха в цех согласно технологической карте. В проектном бюро будут отделы (иногда называемые службами), в it-организации – центры компетенций.

Дальнейшее развитие человеческой мысли в области организации труда привело к созданию кросс-функциональных команд. Впервые подобный формат применила компания Northwestern Mutual Life в 1950-х годах. Кросс-фукциональная команда – это когда мы выдергиваем из артели одного глиномеса (не того, о котором вы подумали, этот реально замешивает глину для горшков), двух гончаров, одного мастера обжига и трех художников, ставим над ними главного и говорим – вы теперь команда. В производстве это называется «производственная линия». Да-да, конвейер – это именно оно.

Что же выбрать? Для так называемого Heliсopter View поднимемся

В небеса!

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

Легко организовать. Проще может быть только толпа.
Значительно упрощено планирование, можно применить Planning Poker, так как в каждом цеху все люди одной специальности и знают специфику.
Проще контролировать загрузку и избегать простоя. Так как руководитель отдела является единой точкой входа и знает загрузку всех специалистов, он эффективно распределяет задачи между ними.
Руководитель отдела – самый крутой спец, делает лучше всех, подает личный пример.
Высокая скорость получения опыта. Люди в отделе всегда общаются и обмениваются опытом.
Высокая взаимозаменяемость специалистов, низкий бас-фактор.
Отсутствует зоопарк решений, так как все решения принимаются в рамках одела.
Легко организовать перекрестный контроль качества работы.
Отдел можно безболезненно горизонтально масштабировать до очень больших размеров, просто выделяя в отделе группы и назначая руководителей. Это никак не меняет саму систему.
Недостатки:

Высокие формальные требования к входящей продукции (иначе говоря, нужен жесткий контракт – что входит, что выходит).
Затруднено общение с другими отделами. Более того, бывает, что отделы начинают враждовать.
Если специалист предыдущего отдела допустил ошибку, её чрезвычайно трудно выявить.

Теперь посмотрим на более позднюю схему производственных линий.

Достоинства:

Слаженность работы команды, так как люди привыкают к стилю работы друг друга.
Чаще всего ошибку предыдущего этапа легко выявить, так как специалист всегда рядом, можно просто спросить.
На каждой линии могут быть установлены свои правила, что может повысить производительность (а может и не повысить).
Более тесные личные отношения, повышающие уровень комфорта.
Эффективное принятие решений, так как присутствуют специалисты от разных областей.
Быстрее передается информация внутри команды, что снижает издержки при проходе задачей всех этапов разработки.
Единая точка ответственности - тимлид.

Недостатки:

Команды трудно организовать, не всегда понятно, сколько и каких специалистов должно там быть. И если в случае отделов можно просто подключить другой отдел (это типовое действие), то в случае команд мы просто не сможем выполнить задачу без танцев с бубном.
Руководитель команды чаще всего является специалистом только в одной из специальностей, не понимая толком, что делают остальные. То есть из самого классного спеца отдела тимлид становится просто менеджером, контролирующим бэклог.
Команды обычно изолированы друг от друга, что вызывает зоопарк технологических практик и решений.
Команды крайне трудно масштабировать, просто добавлять в команду специалистов не получится, ими будет невозможно управлять.
Очень трудно оценить производительность команды, и тем более запланировать загрузку, так как все специалисты разноплановые, а задача часто может быть решена только последовательно.
Очень трудно избегать простоя отдельных специалистов из-за вышеуказанного последовательного решения задач.
Высокий бас-фактор, при выходе из строя одного специалиста другой будет долго вникать в его работу, так как придет по сути в совсем другое окружение, и тимлид не сможет ему помочь, так как не специалист.
Низкая скорость получения опыта специалистами, так как часто специалист вообще единственный в команде, а команды изолированы друг от друга.
Руководителю трудно проверить качество работы, так как специалисты все разные. Приходится контролировать только результат по метрикам.

Теперь спустимся

3. На грешную землю

И постараемся как-то компенсировать недостатки обоих систем организации.

Что можно сделать для компенсации недостатков кроссфункциональных команд? Добавить в структуру центры компетенций (это я их так называю, на практике это могут быть группы, прайды, стримы и так далее). Там, под руководством наиболее опытного из специалистов будут проходить встречи, на которых сотрудники будут делиться опытом. В таком варианте частично уходит изолированность команд, уменьшается зоопарк решений, растет качество кода и скорость набора опыта специалистами. Остальные же родовые черты кроссфункциональных команд остаются с нами.

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

Как мне кажется (и вы наверное это заметили), будущее – за комбинированной структурой, где сотрудник одновременно является и членом кроссфункциональной команды, и сотрудником отдела, вопрос лишь в распределении полномочий управления и между начальником отдела, тимлидом и продакт овнером. Ну и конечно времени, занимаемого встречами в рамках команды и отдела. Пока мне не довелось на практике увидеть идеальное распределение.

Буду очень благодарен, если вы напишете в комментариях, как всё работает в вашей организации, и как по вашему мнению было бы лучше организовать разработку.

Способы организации команд разработки