В своей работе мне довольно часто приходится обсуждать вопросы подходов к учету времени, потраченного на разработку программного обеспечения. Нужно ли учитывать время по каждой задаче? Нужно ли отчитываться каждый день? Полезны ли «таймшиты» и как они должны выглядеть? Кто должен заполнять отчёты и когда? И т.д. Иногда разговор уходит к противостоянию Agile-методологий и более строгих методов управления.
Бывает, такие обсуждения переходят в спор, противостояние точек зрения, а заканчиваются примиряющей фразой: «конечно же, каждая компания имеет свою специфику и особенности, свою модель бизнеса, а значит и свои подходы к учету ресурсов». И это правильно, потому что, по большому счету, принципы учета ресурсов зависят от модели бизнеса, но я всё же хочу собрать в одном месте накопленные аргументы разных сторон и подходов, а главное — попробовать сделать «открытую статью», статью в виде диалога, в виде противостояния аргументов и точек зрения, на которую повлияют комментарии и голоса читателей.
На мой взгляд, различные варианты сводятся к трем базовым подходам:
- Учёт потраченных человеко-часов с разбивкой по задачам
- Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
- Творческая работа без списка функционала и контроля ресурсов
Давайте рассмотрим различия и аргументы в выборе подходов для следующих аспектов:
- оценка фактических затрат
- метрики для оценки предстоящих проектов
- мониторинг текущих проектов
- влияние на командное взаимодействие
- индивидуальная производительность, мотивация
- избавление от неэффективных сотрудников
- эмоциональное состояние сотрудников
- реализация рутинных проектов
- реализация сложных, нестандартных проектов
Обсуждать и противопоставлять мы будем первые два подхода, потому что про третий я рассуждать не могу. Мне приходилось работать в разных компаниях и в разных проектах, на разных технологиях и в разных управленческих схемах…
И самые интересные, технологически сложные и продвинутые, самые необычные проекты делались именно по третьему подходу. Именно про эти проекты я рассказывал на собеседованиях, именно в них создавались принципиально новые продукты, а не всякая надоевшая обыденность типа база данных→бизнес-логика→бизнес-процессы→клиентские представления→отчёты. Работой в этих проектах я горжусь, вспоминаю с ностальгией, не стесняюсь сказать «вот эти архитектурные решения принял я», и именно про эти проекты обычно слушают с большим интересом. Но с другой стороны, именно эти проекты были очень дорогими и экономически сомнительными. Сейчас никакие аргументы за или против таких проектов я приводить не готов, поэтому рассмотрим только два подхода:
| Timesheets Учёт времени по каждой задаче |
Backlog Учёт совокупного времени, потраченного на итерацию и функции |
| Существует отдельная или интегрированная система учета рабочего времени (Timesheeting), обязывающая сотрудников вводить информацию о том, на что были потрачены его 8 рабочих часов в день. Крайним случаем детализации можно назвать фиксацию времени, потраченного на каждый этап работы над задачей или даже обязательную разбивку затрат по конкретным датам, если задача длилась более 1 дня. Если система Timesheeting отделена от проектного управления, то учёт может вырождаться до второго случая, когда часы «списываются» на проект или крупную высокоуровневую задачу. |
Команда имеет систему управления требованиями и методологию выбора некоторого количества требований для реализации в итерацию. Это может быть backlog, список требований, запросов на изменения и дефектов, доска задач SCRUM или Kanban и т.п. Учитываются совокупные затраты всей команды на итерацию, при этом может также производиться условная оценка трудоёмкости требований в storypoints или баллах сложности. |
| Учёт «текучки», мелких задач | |
| Может выделяться специальная задача «прочие работы», занимающая небольшой процент рабочего времени, на которую списываются мелкие работы. Если работа больше определённого порога, её заводят отдельной задачей в рамках конкретного проекта. Минус: для случая нескольких проектов у исполнителя создается одна задача «прочие работы», что несколько снижает точность распределения работ. |
Мелкие задачи учтены в общих затратах на проект.
Сомнения: отсутствие учета мелких работ упрощает работу, но появляется опасность «погрязнуть» в мелкой работе в ущерб основным задачам. |
| Оценка трудозатрат постфактум | |
| Для каждой задачи известны реальные затраты. Доступно большое количество детальных данных о затратах по выполненным работам.
Точность вычисления стоимости сильно зависит от наличия и качества методики суммирования трудозатрат. Достоверность оценок может быть снижена, так как исполнители должны маскировать естественные трудопотери в проектные задачи, и появляется много возможностей для косвенного искажения оценок. Плюс: позволяет выявлять наиболее трудоёмкие задачи, причины трудопотерь, анализировать структуру трудоёмкости. Плюс: позволяет точно постфактум оценить стоимость реализации отдельных функций. Минус: высокие дополнительные расходы на учёт. |
Известны суммарные трудозатраты на всю итерацию. Вычисляется агрегированная стоимость функций без детализации по подзадачам.
Точность вычисления стоимости достаточно высокая за счёт естественного включения всех фактических работ и потерь. Достоверность оценок высокая, так как команде не требуется как-либо детализировать и вносить выдуманную информацию в структуру затрат. Сомнение: анализ причин трудопотерь носит качественный, но не количественный, не формализованный характер. Плюс: низкие дополнительные расходы на учёт. |
| Накопление данных для оценок будущих проектов | |
| Накапливается статистика соответствия исходной оценки сложности задач и конечных трудозатрат на реализацию высокоуровневых функций/сценариев использования. Например, в упрощенном виде это будет таблица, в которой для каждого уровня сложности указана средняя агрегированная стоимость реализации в предыдущих проектах. |
|
| Суммируются затраты на все задачи на основании данных о привязке задач к реализуемым функциям.
Плюс: собрана детальная информация по всем работам. Минус: так как непредвиденные работы должны вводиться в систему для учета, они не всегда могут быть достоверно отнесены для учета к правильным функциям, что искажает оценки. |
В системе имеются уровни сложности функций и фактические суммарные затраты на их реализацию.
Плюс: агрегированная оценка включает фактический уровень затрат вместе со всеми потерями, что позволяет оценивать будущие затраты также с учётом уровня неизбежных потерь. Замечание: для проектов T&M задача накопления оценок может быть не актуальна вовсе. |
| Мониторинг выполнения проекта | |
| Существует возможность обязать сотрудников ежедневно отчитываться о потраченных на работы часах, что позволяет получить детальную картину о ходе работ.
Плюс: возможно использовать инструментальный мониторинг процесса разработки. Минус: достоверность данных может существенно искажаться из-за необходимости маскировать потери, а также из-за нежелания ежедневно и детально фиксировать трудозатраты. |
Формальный мониторинг хода проекта доступен только на уровне прогресса по реализации функций. Детальный ход работ и информация о проблемах доступна только руководителям конкретных проектов, участвующим в ежедневных «статусах».
Плюс: высокая достоверность информации о прогрессе реализации требований. Проблемы в проекте проще афишируются за счёт акцента на конечной цели реализации функционала, а не выявления и фиксации в timetracker-е причины и виновных проблемы. |
| Командное взаимодействие | |
| Система учета трудозатрат индивидуальна и требует выделения затрат на задачу по каждому из разработчиков. В случае коллективной работы над требованием необходимо отдельно учитывать работу каждого в виде отдельных задач.
Минус: потребность исполнителя распределить 8 рабочих часов по своим задачам ограничивает его желание участвовать в помощи другим членам команды в их задачах. Минус: дополнительная административная нагрузка по созданию отдельных задач при необходимости существенного отвлечения на помощь в решении задач других людей. |
В системе учета нет нужды создавать отдельные задачи при коллективной работе над ними.
Плюс: между членами команды нет препятствий для перераспределения усилий и оказания помощи при необходимости, так как итоговое оценивание зависит от реализованных требований всей командой, а не индивидуальных показателей трудозатрат. Плюс: отсутствие сложностей в системе учета при совместной работе над задачей или при передаче задачи между исполнителями. |
| Индивидуальная производительность, мотивация | |
| Существует возможность формального оценивания производительности труда и занятости работника. Возможна схема денежной мотивации, пропорциональной трудозатратам.
Минус: наличие стимула для искажения данных о производительности. Минус: возможность фальсификации производительности. Плюс: возможность применения формальных методов оценки, включая способы выявления фальсификации. |
Рекомендуется оценка эффективности всей команды, без выделения индивидуальных оценок. Денежная мотивация строится на пропорциональном делении награды между членами команды в случае успешной реализации этапов.
Индивидуальная оценка каждого члена команды может быть сформирована внутри команды неформальными способами. Однако, существует возможность оценки эффективности по количеству реализованных требований и их сложности. Плюс: сложность фальсификации производительности. |
| Избавление от неэффективных сотрудников | |
| Плюс: существует возможность избавиться от неэффективного сотрудника по формальным критериям на уровне срабатывания правил системы, что существенно уменьшает эмоциональную нагрузку на остальных членов команды.
Минус: появляется стимул для искажения и спекулятивного использования данных о производительности. Плюс: эффективный сотрудник может защитить свою репутацию вне зависимости от личностных отношений и эмоциональной неприязни. |
Команда практически всегда видит неэффективных сотрудников, однако возникают сложности личностного характера. Решение о вытеснении из команды принимается лично участниками.
Минус: высокая эмоциональная нагрузка в случае необходимости исключения. Минус: влияние межличностных отношений. Однако, следует заметить, что данный подход позволяет сформировать эмоционально устойчивые, здоровые команды, которые не сталкиваются с заявленными минусами. |
| Эмоциональное состояние сотрудников | |
| Минус: появляется недовольство необходимостью вести постоянный учет затрат времени
Минус: накапливается недовольство ощущением излишнего контроля и необходимостью оправдывать или скрывать каждый случай потери рабочего времени. |
Плюс: атмосфера доверия и творческой свободы
Плюс: ощущение командной работы и взаимопомощи |
| Реализация рутинных проектов | |
| Плюс: жесткий контроль и давление формирует пассивную позицию и позволяет принуждать сотрудников работать на рутинных, неинтересных проектах с приемлемой производительностью. | Минус: эффективные, производительные команды, имеющие адекватную самооценку, предпочитают работать на интересных проектах. Могут избегать рутинных проектов вплоть до покидания компании. |
| Реализация сложных, нестандартных проектов | |
| Минус: жесткий контроль подавляет творческое , вытесняет из коллектива ярких и неординарных людей, формируя посредственные команды, неспособные к решению нестандартных, амбициозных задач. | Плюс: отсутствие фиксации на затратах, возможность вести поиск и пробовать новые решения, творческая свобода в команде и её ориентация на результат, позволяет команде успешно реализовывать сложные, нестандартные, неординарные проекты. |
Далее в первых 10 комментариях я хочу построить обсуждение темы по перечисленным аспектам с возможностью голосования за конкретные подходы. Давайте договоримся в ветках с голосованием за аргументы ставить только плюсы, иначе я рискую нахватать минусов в рейтинг на очевидно негативных аспектах выбранных подходов.
Впрочем, для чего ещё рисковать рейтингом, как не для интересующего исследования. =)
Автор: ayakovlev
