Об учёте времени в проектах разработки ПО

в 23:10, , рубрики: agile, разработка, управление проектами, учет времени, учёт рабочего времени, метки: , ,

В своей работе мне довольно часто приходится обсуждать вопросы подходов к учету времени, потраченного на разработку программного обеспечения. Нужно ли учитывать время по каждой задаче? Нужно ли отчитываться каждый день? Полезны ли «таймшиты» и как они должны выглядеть? Кто должен заполнять отчёты и когда? И т.д. Иногда разговор уходит к противостоянию Agile-методологий и более строгих методов управления.
Бывает, такие обсуждения переходят в спор, противостояние точек зрения, а заканчиваются примиряющей фразой: «конечно же, каждая компания имеет свою специфику и особенности, свою модель бизнеса, а значит и свои подходы к учету ресурсов». И это правильно, потому что, по большому счету, принципы учета ресурсов зависят от модели бизнеса, но я всё же хочу собрать в одном месте накопленные аргументы разных сторон и подходов, а главное — попробовать сделать «открытую статью», статью в виде диалога, в виде противостояния аргументов и точек зрения, на которую повлияют комментарии и голоса читателей.
На мой взгляд, различные варианты сводятся к трем базовым подходам:

  1. Учёт потраченных человеко-часов с разбивкой по задачам
  2. Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
  3. Творческая работа без списка функционала и контроля ресурсов

Давайте рассмотрим различия и аргументы в выборе подходов для следующих аспектов:

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

Обсуждать и противопоставлять мы будем первые два подхода, потому что про третий я рассуждать не могу. Мне приходилось работать в разных компаниях и в разных проектах, на разных технологиях и в разных управленческих схемах…
И самые интересные, технологически сложные и продвинутые, самые необычные проекты делались именно по третьему подходу. Именно про эти проекты я рассказывал на собеседованиях, именно в них создавались принципиально новые продукты, а не всякая надоевшая обыденность типа база данных→бизнес-логика→бизнес-процессы→клиентские представления→отчёты. Работой в этих проектах я горжусь, вспоминаю с ностальгией, не стесняюсь сказать «вот эти архитектурные решения принял я», и именно про эти проекты обычно слушают с большим интересом. Но с другой стороны, именно эти проекты были очень дорогими и экономически сомнительными. Сейчас никакие аргументы за или против таких проектов я приводить не готов, поэтому рассмотрим только два подхода:

Timesheets
Учёт времени по каждой задаче
Backlog
Учёт совокупного времени, потраченного на итерацию и функции
Существует отдельная или интегрированная система учета рабочего времени (Timesheeting), обязывающая сотрудников вводить информацию о том, на что были потрачены его 8 рабочих часов в день. Крайним случаем детализации
можно назвать фиксацию времени, потраченного на каждый этап работы над задачей или даже обязательную разбивку затрат по конкретным датам, если задача длилась более 1 дня.

Если система Timesheeting отделена от проектного управления, то учёт может вырождаться до второго случая, когда часы «списываются» на проект или крупную высокоуровневую задачу.

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

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

Учёт «текучки», мелких задач
Может выделяться специальная задача «прочие работы», занимающая небольшой процент рабочего времени, на которую списываются мелкие работы.
Если работа больше определённого порога, её заводят отдельной задачей в рамках конкретного проекта.

Минус: для случая нескольких проектов у исполнителя создается одна задача «прочие работы», что несколько снижает точность распределения работ.

Мелкие задачи учтены в общих затратах на проект.

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

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

Точность вычисления стоимости сильно зависит от наличия и качества методики суммирования трудозатрат.

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

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

Плюс: позволяет точно постфактум оценить стоимость реализации отдельных функций.

Минус: высокие дополнительные расходы на учёт.

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

Точность вычисления стоимости достаточно высокая за счёт естественного включения всех фактических работ и потерь.

Достоверность оценок высокая, так как команде не требуется как-либо детализировать и вносить выдуманную информацию в структуру затрат.

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

Плюс: низкие дополнительные расходы на учёт.

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

Плюс: собрана детальная информация по всем работам.

Минус: так как непредвиденные работы должны вводиться в систему для учета, они не всегда могут быть достоверно отнесены для учета к правильным функциям, что искажает оценки.

В системе имеются уровни сложности функций и фактические суммарные затраты на их реализацию.

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

Замечание: для проектов T&M задача накопления оценок может быть не актуальна вовсе.

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

Плюс: возможно использовать инструментальный мониторинг процесса разработки.

Минус: достоверность данных может существенно искажаться из-за необходимости маскировать потери, а также из-за нежелания ежедневно и детально фиксировать трудозатраты.

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

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

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

Минус: потребность исполнителя распределить 8 рабочих часов по своим задачам ограничивает его желание участвовать в помощи другим членам команды в их задачах.

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

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

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

Плюс: отсутствие сложностей в системе учета при совместной работе над задачей или при передаче задачи между исполнителями.

Индивидуальная производительность, мотивация
Существует возможность формального оценивания производительности труда и занятости работника. Возможна схема денежной мотивации, пропорциональной трудозатратам.

Минус: наличие стимула для искажения данных о производительности.

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

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

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

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

Плюс: сложность фальсификации производительности.

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

Минус: появляется стимул для искажения и спекулятивного использования данных о производительности.

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

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

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

Минус: влияние межличностных отношений.

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

Эмоциональное состояние сотрудников
Минус: появляется недовольство необходимостью вести постоянный учет затрат времени

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

Плюс: атмосфера доверия и творческой свободы

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

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

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

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

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

Автор: ayakovlev

Поделиться

* - обязательные к заполнению поля