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

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

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

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

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

Общие сведения об управлении системой

Управление любой системой предполагает два основных этапа работы:

Настройка, при которой система приводится в некоторое целевое состояние. Этот процесс занял у меня 6 месяцев, но может занять как меньший период, так и больший (до года) в зависимости от текущего уровня беспорядка и степени текущей загруженности в компании.
Мониторинг настроенной системы, которая теперь может работать самостоятельно, и внесение небольших корректирующих воздействий. На данном этапе ПО должно выпускаться с надлежащим качеством даже при отсутствии руководителя (не слишком длительном. Любая система начинает постепенно деградировать при отсутствии контроля).

Первый этап - самый напряжённый как для руководителя, так и для работников. Текущую деятельность никто не отменял, но, помимо неё, в рабочий график необходимо включать ещё и внедрение новых инструментов работы, регламенты и обучение этим инструментам и регламентам.

Производственные метрики

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

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

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

Можно использовать следующие метрики:

среднее количество возвратов задачи в разработку из тестирования;
среднее количество ошибок, выявляемых в ПО при тестировании в некоторую единицу времени;
среднее количество ошибок, обнаруживаемых в готовом продукте пользователями, в некоторую единицу времени;
средняя производительность труда в Story Point'ах в единицу времени;
средняя скорость создания очередной версии продукта (при условии, что все версии сопоставимы между собой по объёму вложенного труда);
доля времени, затрачиваемого на поддержку существующего продукта, от общего времени разработки;
и т.д.

Программное обеспечение

Нормальный процесс разработки невозможно выстроить без использования специализированных средств. Проектирование на листочке и планирование в Excel не помогут вам стать конкурентоспособными разработчиками ПО. Мы использовали линейку продуктов Atlassian, но вы можете использовать и бесплатное ПО. Для работы вам понадобятся:

система контроля версий (Git);
сервер Git (Stash, Bitbucket);
система багтрекинга (JIRA);
система ведения документации (Confluence);
билд-сервер (Bamboo, TeamCity).

Начните свою деятельность с поиска и развёртывания необходимых для вас инструментов. Вы можете пробовать разные варианты; но слишком растягивать этот процесс тоже не стоит.

Элементы управления

Далее я описываю аспекты управления, которые можно внедрять отдельно друг от друга (в уже работающей компании). Я стараюсь придерживаться порядка описания, при котором первые модули можно использовать без последующих за ним. Причём эффект можно будет заметить от внедрения каждого модуля в отдельности.

Порядок описания модулей будет следующим:

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

В то же время, если вы начинаете с нуля и обладаете запасом времени, то эффективным порядком внедрения модулей я считаю другой:

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

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

Далее вы сможете настроить подходящую вам методологию разработки и необходимые для неё инструменты. Следующим шагом вы опишете принципы построения архитектуры вашего ПО, затем настроите систему тестирования перед непосредственно программированием (подход TDD). Затем вы создадите механизм развёртывания (билд-сервер).

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

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

Но сначала - немного о проблемно-ориентированном управлении.

Проблемно-ориентированное управление

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

Таким образом, вашей основной задачей как руководителя станет решение проблем:

реальных;
потенциальных (рисков).

Полностью избежать возникновения проблем не получится, но можно свести риск от их возникновения к минимуму.

Текущие проблемы можно решать по следующему алгоритму.

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

Основные риски руководителя разработки:

уход программиста из компании (увольнение, болезнь, смерть и т.д.);
срыв сроков проекта.

Первый риск решается на этапах:

документирования (знания не должны храниться в чьей-то одной голове);
архитектуры (программист не может создать код, в котором никто не может разобраться, кроме него);
методологии разработки (обязательство писать комментарии в коде и проходить Code Review, обязательное наличие постановок задач, что позволит подхватить работу другому программисту).

Ситуацию со срывом сроков проекта можно описать отдельно.

Срыв сроков проекта

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

перенести срок завершения проекта (если это возможно);
исключить ряд задач из будущей версии проекта. Исключаются задачи с низшим приоритетом;
привлечь дополнительных людей. Этот вариант следует использовать с осторожностью, так как можно потерять время на обучение новых программистов. В связи с этим, такой вариант предпочтителен, если:

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

пожертвовать качеством проекта (наименее предпочтительный вариант)

В любом случае задачей именно руководителя разработки становится отражение давления менеджеров и объяснение причин, по которым проект не может быть закончен в срок.