Настоящий CTO: думай как технический директор - Алан Уильямсон

6.1.1. Знания

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

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

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

• Вводные/учебные материалы. Как и в компании в целом, в каждой команде должны быть материалы для адаптации и обучения, соответствующие ее задачам. Например, в команде, ответственной за релизы, можно изучать используемые для этого инструменты (Jenkins/SonarQube и т. п.).

• База знаний. В наши дни едва ли найдется компания, в которой нет своей вики или хранилища документов, хотя то, насколько они обновляются и поддерживаются в актуальном состоянии, – это отдельный вопрос. Но база знаний не обязательно должна состоять из документов; в ней могут быть и видеоролики, а их, в зависимости от вашей темы, может быть даже проще сделать.

• Описанные процессы/правила. Чтобы команда могла функционировать, она должна иметь правила. Правила не должны быть неявными или само собой разумеющимися, их необходимо описать и донести до всех, чтобы все следовали им для достижения общей цели. Например, для команды разработчиков можно зафиксировать стандарты написания и форматирования кода, а также использование системы контроля версий при выполнении тех или иных задач.

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

6.1.2. Образец устава

Устав не должен быть ни длинным, ни сложным или заумным. Достаточно описать в нем в общих чертах цели команды. Вот пример устава группы поддержки онлайн-сервиса:

• Цель – обеспечивать оперативную поддержку конечных пользователей по всем вопросам взаимодействия с сервисом, включая помощь менеджерам из отдела по работе с клиентами в решении любых проблем, связанных с созданием новых пользователей.

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

• Клиент – любой пользователь продукта, как внутренний, так и внешний.

• Ресурсы

• База знаний о структуре внутренних данных в виде внутренней вики.

• Доступ к данным продакшена только для чтения.

• Полный доступ к данным продакшена для отдельных сотрудников.

• Требуемые навыки

• Знание веб-технологий, включая системы видеоконференций/чаты.

• Грамотная письменная и устная речь.

• Знание SQL.

• Ключевые показатели

• Время до закрытия инцидента.

• Общее количество обращений за определенный период.

6.2. Структура команды

Сразу оговоримся: не существует идеальной структуры, подходящей для всех. То, что работает для одной команды, не обязательно будет работать для другой. На то, какая структура сложится у вас, влияют многие факторы, в том числе корпоративная культура, личные качества и темперамент сотрудников, важность их работы и необходимость взаимодействовать с клиентами.

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

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

В популярных реалити-шоу, таких как Survivor в США или The Apprentice в Великобритании, создают команды с самым разношерстным составом участников и разной структурой, все это для создания конфликтов и драм с целью развлечения. Но эти конфликты вполне реальны, поэтому стоит позаботиться о подборе структуры, которая лучше всего подойдет для вашей команды.

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

Если ваша команда создана недавно и только начинает работу, в ней еще может не быть семи человек, в этом случае сейчас вам беспокоиться не о чем. Но думайте о будущем. При составлении планов считайте, что ваша команда увеличится вдвое.

Исключения

Большие команды

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

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

6.2.1. Вокруг продукта

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

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

• разные стеки технологий;

• непересекающиеся клиентские базы;

• независимые релизные циклы;

• уникальные для разных продуктов и трудоемкие проблемы поддержки;

• значительная разница в прибыли, которую генерируют разные продукты.

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

6.2.2. Вокруг жизненного цикла

Это, вероятно, самая популярная модель из используемых компаниями, разрабатывающими собственное программное обеспечение. Такая структура подобна заводскому конвейеру, где каждый отдел отвечает за определенную часть процесса создания и эксплуатации продукта. Например, у вас может быть команда разработчиков, команда тестирования, команда, ответственная за релизы, команда DevOps/инфраструктуры и, наконец, служба поддержки. Каждую из этих команд возглавляет отдельный руководитель, который будет находиться в вашем непосредственном подчинении.

Эта модель хорошо работает, если в организации существует четко определенный и работающий SDLC (Software Development Life Cycle, жизненный цикл разработки программного обеспечения). Скорее всего, на начальном этапе создания проекта каждый из ваших сотрудников будет выполнять сразу несколько ролей. Однако придет время, и вам потребуются специалисты с более глубокими знаниями в каждой области. Тогда вы