Разработка с нуля: как выстроить команду и оценивать ее КПД

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

Команда: три уровня ответственности

В проектной команде я выделяю три уровня.

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

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

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

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

Три уровня проектной команды: управление проектом, архитектура и исполнение.

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

Для простоты дальше назовем наших архитекторов Тамарой и Федором. Тамара — технический архитектор. Она отвечает за все, что происходит «под капотом» системы, чтобы велосипед, который команда собирает по ходу проекта, в итоге не оказался с квадратными колесами. Федор — функциональный архитектор. Его зона ответственности — то, что видит бизнес: требования, функциональность системы, пользовательские сценарии и целостность решения.

Функциональный архитектор

Функциональный архитектор отвечает прежде всего за управление бизнес-требованиями. Требования по разным участкам проекта не должны существовать независимо друг от друга — они должны складываться в целостную картину.

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

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

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

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

Технический архитектор

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

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

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

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

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

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

Учет задач: что именно считать

Есть простая аналогия — метод трех гвоздей. Представим исполнителя, к которому приходит первая задача. Он «вешает» ее на первый гвоздь и продолжает работать. Затем приходит вторая — второй гвоздь. Потом третья. А дальше появляется четвертая задача. Гвоздей больше нет: приходится либо снимать одну из предыдущих задач, либо забывать новую.

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

Задачи аналитиков и консультантов

Для консультантов я выделяю три базовых типа задач.

• Моделирование. С этого этапа начинается работа: команда собирает бизнес-требования, разбирается в процессе, примеряет его к системе и определяет, какой результат должен получить бизнес-пользователь.

• Проектирование. Требования превращаются в конкретное решение: формируются объекты системы, правила их взаимодействия и проектная документация.

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

Задачи разработчиков

У разработки структура другая. Первый и основной тип — доработки, возникающие из согласованных проектных решений. Проектное решение подготовлено и согласовано — на его основании появляется задача разработки.

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

Третий большой блок — ошибки. Их стоит разделять как минимум на две категории:

• ошибки документации — на этапе проектирования был упущен нюанс или проектное решение оказалось неполным либо некорректным;

• ошибки разработки — проектное решение было сформулировано корректно, но реализовано неправильно или не полностью.

Типов задач в конкретном проекте может быть и больше. Но классификация должна позволять в дальнейшем понять не просто сколько часов было потрачено, а на что именно они были потрачены.

Кто создает задачи

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

Задачи CR — code review — фиксирует технический архитектор. Задачи по обнаруженным ошибкам могут создавать консультанты. То есть в создании и учете задач участвует вся команда.

Плановое и фактическое время

После создания задачи появляется следующий вопрос: сколько времени она должна занять? В разработке практически вся работа в конечном счете переводится в часы. Если мы совсем не умеем прогнозировать трудоемкость, становится сложно управлять сроками и загрузкой.

Представим разработчика Олега. Олег — сильный специалист. Когда ему предлагают оценить задачу, он отвечает: «Я не знаю, сколько это займет. Мне быстрее сделать, чем оценивать». На первый взгляд логично. Но если так происходит постоянно, управлять загрузкой Олега практически невозможно. Мы знаем, что он работает, но не понимаем, когда будет получен результат и сколько еще задач он способен взять.

Как оценивать плановую трудоемкость

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

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

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

Как учитывать фактическое время

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

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

Если через полгода потребуется разобраться, почему определенная задача вышла за план, строка «8 часов — разработка» почти ничего не даст. Описание должно быть коротким, но достаточным, чтобы восстановить смысл выполненной работы.

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

Инструмент учета

В наших проектах для учета задач использовалась Jira. Но сама Jira здесь не принципиальна. Это может быть Trello, 1С:ITIL, Документооборот или другой инструмент. Критично другое: система должна позволять зарегистрировать задачу, определить ее статус, назначить исполнителя, сохранить плановую оценку и учитывать фактическое время.

Например, у нас есть задача по миграции. Технический архитектор оценил ее в 32 часа. Разработчик уже списал часть времени. У нас появляется значительно больше информации для управления, чем просто статус «В работе»: можно смотреть динамику выполнения и обсуждать ожидаемый срок завершения.

Пример задачи в Jira: плановая оценка и фактически списанное время по ролям.

Кто должен анализировать все эти данные? Здесь мы снова возвращаемся ко второму уровню команды — архитекторам. Смысл учета не в том, чтобы накопить максимально большое количество данных. Их нужно регулярно просматривать и искать отклонения.

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

План-факт и КПД: как читать цифры

«Можно быть очень занятым человеком и при этом не очень эффективным», — заметил в свое время Стивен Кови. Вернемся к Олегу. Он сильный специалист, его постоянно отвлекают, коллеги стоят к нему в очереди за помощью, он практически всегда занят. Но высокая загрузка сама по себе еще ничего не говорит об эффективности.

План-фактный анализ

Первый инструмент, который мы используем, — план-фактный анализ завершенных задач.

Например, задача была оценена в 20 часов, а фактически на нее потрачено 37 часов. Что нам говорит эта цифра? Сама по себе — почти ничего. Она говорит лишь одно: здесь есть отклонение, которое нужно разобрать.

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

Пример план-фактного анализа по завершенным задачам разработчиков.

Экономия тоже стоит разбора, хоть и по другой причине. У разработчика №5 план составлял 123 часа, факт — 107, то есть минус 13%. Разбор показал: в оценку заложили резерв на интеграцию со смежной системой, которая в итоге не понадобилась — часть работы уже была закрыта на другом участке проекта. Сигнал здесь не про исполнителя, а про то, что саму оценку стоит уточнить в следующий раз.

КПД разработчиков

Вторая часть анализа — оценка КПД. В используемой модели для разработчиков применяется следующая формула:

Зачем разделять эти категории? Чтобы не записать любой перерасход на счет разработчика. Новое требование — это изменение объема работ. Ошибка аналитика на этапе проектирования — ошибка документации. И только отдельная категория показывает собственно переделку, связанную с ошибкой разработки.

Например, мы видим, что на исправление ошибок разработчика было потрачено 11 часов. Дальше начинается разбор. В рассматриваемом случае разработчик вовремя не проконсультировался с консультантом, неверно понял проектное решение и реализовал его не в том направлении. На приемке потребовалась существенная переработка.

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

Пример расчета КПД разработчиков с разделением причин повторной работы.

Второй показательный случай в этой же таблице — разработчик №6: 176 часов работы, из них 47,5 часа — ошибки разработки, КПД 73%. Картина здесь другая: не один провал на сложной задаче, а системная невнимательность на нескольких мелких доработках. С разработчиком разбирали не конкретную задачу, а привычку — сдавать работу, не перечитав техническое задание.

КПД консультантов

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

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

Пример расчета КПД консультантов: низкий показатель требует анализа причин, а не автоматической оценки сотрудника.

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

Рассмотрим два примера. Консультант №6 показывает КПД 31% - кажется результат выглядит плохо. Но при анализе выясняется, что специалист был специально подключен функциональным архитектором для помощи другому консультанту, который не успевал завершить свой блок: на подзадачи ушло около 90 часов. Человек действительно большую часть времени занимался переделкой, но это было сознательное управленческое решение.

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

У консультанта №7 ситуация внешне похожа. Первоначально моделирование было оценено примерно в 5 часов, но на связанные подзадачи в итоге ушло 124 часа. По ходу работы появилось большое количество дополнительных требований, возникли проблемы коммуникации с бизнес-пользователем, стороны не смогли своевременно договориться о границах решения.

Формально мы снова видим большое количество переделок. Но причина уже совершенно другая. Поэтому одинаковые или близкие показатели КПД еще не означают одинаковые управленческие решения.

Похожая логика — с консультантами №3 и №5, чьи 73% и 62% выглядят тревожно, но до уровня «критично» не дотягивают. В обоих случаях подзадачи сосредоточены на этапе моделирования — то есть на стыке с бизнес-пользователем, а не на этапе проектирования, за который отвечает уже сам консультант. Для команды это сигнал присмотреться к конкретному бизнес-блоку, а не к работе специалиста.

Когда система оценки действительно работает

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

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

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

3. Команда умеет прогнозировать или готова этому учиться. Оценка трудоемкости — навык, который развивается со временем. Но если команда принципиально работает по модели «начнем делать, а там посмотрим», оценивать эффективность становится практически невозможно.

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

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

Именно поэтому план-факт и КПД имеют смысл смотреть вместе с содержанием задач и историей проекта. Без контекста цифра практически ничего не значит. С контекстом она превращается в инструмент управления.

Вместо заключения

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

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.