Всем привет!
Сегодня я хочу рассказать о нескольких практиках оценок задач, которые сложились в нашей команде за годы совместной работы. Я надеюсь, что статья будет полезна тем, кто только начинает свой путь в менеджменте, и особенно тем, кто работает по ватерфелу в "кровавом enterprise".
Эффективное планирование зависит от множества разных факторов: от качества оценки, проработки деталей решения, использованной методики планирования, правильной оценки рисков.
Для начала я расскажу о подготовительной части планирования – оценке задачи разработчиками. В нашей команде нам удалось, балансируя между бюрократией и жизненной необходимостью, разработать ряд практик, которые позволяют без лишних промедлений и размышлений превращать оценки в план работ.
Итак, начнем с правил оценки.
Оцениваем задачи по единым правилам
Правила оценки появились у нас после того, как выяснилось, что один из разработчиков в оценке под 1 человеко-днем работы подразумевает 8 часов непрерывной работы без перерывов на планерки, чай/кофе и даже санитарно-гигиенические нужды. Поэтому мы в команде составили очень простое соглашение:
- оценка проводится в человеко-днях (в документах пишем просто «дни»);
- задача на 1 человеко-день решается за 1 рабочий день. 0,5 человеко-дня – это начать утром и завершить к обеду. В этот человеко-день включена планерка, помощь коллегам, чай с печеньками и так далее;
- (для менеджера) в 1 человеко-дне около 6 часов эффективной разработки.
Не обязательно ваши правила должны быть такими же, главное, чтобы вы работали в одной системе координат.
Декомпозируем задачу
Зачастую разработчику гораздо проще сказать: «да там на пару недель работы». А менеджеру добавить в план задачу на 80 часов. Однако из-за такого подхода к планированию потом и возникают вопросы вида: «скажи, сколько процентов работы тебе осталось сделать» и другие способы понять, какой у разработчика прогресс по выполнению задаче.
Мы установили следующие ограничения: любая задача декомпозируется на подзадачи длительностью 0,5-3 дней. Каждая подзадача представляет собой законченную часть функционала.
Опять-таки в вашей команде ограничения могут быть другими. Здесь необходимо соблюдать баланс.
Но по нашему опыту подзадачи более 3 дней:
- вызывают эффект выпрямления сроков;
- демотивируют разработчика долгим отсутствием результата;
- осложняют контроль и снижают скорость реакции на проблемы.
Менее 0,5 дня тоже имеют недостатки:
- чем меньше задачи, тем больше зависимостей между ними;
- чем меньше задачи, тем больше времени и внимания требуется для их отслеживания.
При этом мы сразу нумеруем пункты декомпозиции (подзадачи) – так гораздо удобнее работать с ними в сетевой диаграмме (об этом ниже) и в плане.
Унифицируем подход к декомпозиции
Однажды мы столкнулись с такой ситуацией: оценка трудоемкости разработки другой команды оказалась на 25% меньше, чем наша. Эта ситуация очень заинтересовала руководство – расследование показало, что наши коллеги не включили в оценку проверку разработчиками результатов своей разработки (внутреннее дымовое тестирование).
Чтобы таких ситуаций не было, мы добавили в правила оценки еще пару пунктов:
- модульное тестирование включается в оценку разработки;
- дымовое тестирование мы оцениваем отдельно.
Этот пункт еще раз напоминает, что все члены команды и заинтересованные стороны должны работать в одной системе координат.
Оцениваем зависимости задач
Планирование без учета зависимостей похоже на игру в рулетку. Если все пойдет хорошо, то ваш план вполне может быть успешно реализован. Но если вы столкнетесь с жесткой взаимозависимостью нескольких элементов работ, то план «поедет».
Поэтому для качественного планирования, кроме декомпозиции необходима информация о связях подзадач между собой. Например, вы сначала разрабатываете бэкэнд, а потом фронтэнд. Или сначала делаете заглушки на стороне бэкенда, а потом пилите бэкэнд и фронтэнд параллельно. И в том, и в другом случае между работами есть зависимость. Она окажет влияние на старт работ фронтэнда.
Наиболее простой и понятный способ отображения зависимостей – сетевая диаграмма. Например, такая, где элементами являются подзадачи, а стрелки показывают зависимости между ними.
Учитываем ограничения
Часто в задаче заложены еще какие-то ограничения: например, необходимо применить технологию, которой владеют не все члены команды. В нашей команде все владеют стеком бэкенда, но лишь несколько разработчиков могут разрабатывать фронтэнд. Поэтому в каждом элементе декомпозиции мы указываем, к какой технологии относится тот или иной пункт. Эта информация о делении работ на фронтэнд и бэкенд используется при планировании при построении критической цепи.
Оцениваем риски
Есть анекдот про менеджеров, которые умножают оценки разработчиков на некоторое эмпирическое число. Максим Дорофеев объясняет, почему не надо так делать.
Вместо того, чтобы играть в угадайку, мы оцениваем риски следующим образом: на каждый пункт декомпозиции разработчик пишет, какие есть риски, каковая их вероятность и какое влияние они окажут на трудоемкость. Мы называем этот рисками разработки.
При планировании менеджер решает, как обработать риски. А кроме рисков разработки он оценивает и добавляет на этапе планирования менеджерские риски. Например, основываясь на статистике предыдущих проектов.
На практике
На практике в нашей команде при выполнении оценки разработчик заполняет вот такую простую таблицу:
| Номер подзадачи | Подзадача | Пункт ТЗ | Технология | Оценка, дней | Риски, дней |
|---|---|---|---|---|---|
| 1 | Разработать заглушки | бэкэнд | 1 | ||
| 2 | Реализовать фичу | 1 | бэкэнд | 3 | 1 (возможно придется перенастраивать макет) |
| 3 | Реализовать форму | 2 | фронтенд | 2 |
А также рисует сетевую диаграмму примерно такого вида:
Заключение
На этом оценка со стороны разработчика завершается. И к работе приступает менеджер, в задачу которого входит превратить два данных артефакта в готовый план работ по задаче. Как происходит такое превращение я расскажу в следующей части.
Спасибо за внимание!
third112
Со времен книги Брукса про миф человеко-месяца было предложено много подходов, т.к. тема действительно очень актуальная. Хотелось бы посмотреть, как работает Ваш метод на реальном, хотя бы небольшом проекте — думаю, это будет интересно многим читателям. Могу для этого предложить примеры своих уже сделанных мини-проектов:
2 игровых бота: 1 и 2
и маленькая игровая задачка
Прикиньте по своей методике, сколько человеко-дней на какие этапы нужно, риски и т.д. А я скажу, как оказалось в реальности.
Kluge Автор
Наверное, я вас разочарую, но описанные практики не совсем методика, а скорее некоторые практические дополнения к той методике, которая применяется в проекте.
Важно отметить, что эти практики больше ориентированны на командую разработку в «кровавом enterprise» с средним/низким уровнем неопределенности. Как правило доработка банковской системы/системы управления складом или чего-то подобного представляет собой развитие функционала, а не революцию в нем. Отсюда поход с унификацией, стандартизацией и так далее. Оценка и планирование в таких проектах — воспроизводимый процесс.
Но мы можем потренироваться и на ваших проектах. Только оценивать будете вы, потому что опыт и экспертиза на вашей стороне. Для начала договоримся, в чем будем оценивать (человеко-дни, чистые часы, а может быть «попугаи»). Затем определимся с конечной целью и будем разбивать работы на подзадачи. С учетом уровня неопределенности можно не пытаться съесть слона целиком, а начать с прототипирования. Оценим ограничения и риски. В общем, я думаю во многих проектах можно применить эти практики.
third112
Ok. Предлагаю «человеко-дни» по Вашему определению:
Kluge Автор
Договорились.
Теперь выберем, что будем оценивать. У вас есть какой-нибудь новый проект?
Потому что по старым проектам правильные ответы вы уже знаете. Оценивать придется вам, так как исполнителем в итоге будете тоже вы. А это очень хорошо, когда оценивает тот, кто будет реализовывать. Да и отсутствие у меня опыта работы с ИИ и указанными инструментами не позволит мне корректно оценивать ваши задачи.
third112
>У вас есть какой-нибудь новый проект?
Думаю, что для демонстрации возможностей Вашего подхода имеет смысл сравнение только с уже сделанным. Допустим, новый проект получит суммарную оценку в 1 человеко-год. При одном исполнителе будем ждать год, пока я сделаю этот проект? За это время Вы успеете усовершенствовать Ваш подход, и устаревшая оценка будет никому не интересна. Кроме того, было бы неправильным разглашать основные детали еще несделанного проекта.
> по старым проектам правильные ответы вы уже знаете.
Строго говоря, правильных ответов я не знаю, а знаю, как получилось у меня (или у нас, т.к. один из проектов исполнялся вдвоем). И было бы интересно сравнить со сторонней оценкой. Понятно, что у каждого исполнителя разная производительность, но, насколько я понимаю, для оценки берется средняя: столько-то строк кода написать за 1 человеко-день, столько-то отладить и т.д. Более того: из того, что мне удалось удачно выполнить какой-то проект, совсем не следует, что я его правильно выполнял – оптимальным образом провел декомпозицию, правильно оценил риски и т.д. Может, мне просто повезло. А может, тот же результат я мог бы получить гораздо быстрее.
Что касается отсутствия опыта работы с ИИ, в моих проектах, конечно, есть своя специфика, но не столь большая, как, нпр., в случае нейронных сетей. При том, что «маленькая игровая задачка» по сути не является задачей ИИ, и в моем решении ИИ не используется, что и отмечено в публикации. Очень часто производитель ПО – будь это отдельный программист или целая фирма – сталкивается с необходимостью решить задачу, для которой у него отсутствует опыт. Как же оценивать и планировать в этом случае? Неужели Ваш подход не поможет?
> А это очень хорошо, когда оценивает тот, кто будет реализовывать.
Давайте поставим задачу иначе. Предположим, что некой фирме Х так понравились три моих вышеуказанных программных продукта, что она хочет получить на них права (не будем при этом обсуждать юридическую сторону вопроса о правах на открытое ПО). Так же фирме Х понравился Ваш подход, и она обратилась к Вам с просьбой быть независимым экспертом для приблизительной оценки трудоемкости создания подобного ПО. Используя эту оценку, как некий средний объективный критерий, фирма Х определит примерный размер компенсации, которую она считает разумным мне предложить. Конечно, в подобной модельной ситуации я могу не соглашаться с какими-либо оценками, возражая, что на подзадачу, оцененную в 2 человеко-дня, потратил 20. Но и мне резонно возразят, что это мои проблемы организации работ и если у меня плохая организация, то все равно никто не будет платить мне за элементарную подзадачу в 10 раз выше среднего. Если я продолжу упорствовать и заломлю слишком высокую, по мнению Х, цену, то фирма Х, опять же учитывая Вашу оценку, может решить ничего мне не компенсировать, и что для нее будет выгоднее написать свой собственный код с похожей функциональностью (юридическую сторону такого решения тоже обсуждать не будем).