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