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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Далее в первых 10 комментариях я хочу построить обсуждение темы по перечисленным аспектам с возможностью голосования за конкретные подходы. Давайте договоримся в ветках с голосованием за аргументы ставить только плюсы, иначе я рискую нахватать минусов в рейтинг на очевидно негативных аспектах выбранных подходов.
    Впрочем, для чего ещё рисковать рейтингом, как не для интересующего исследования. =)
    P.S. Ещё раз обращаю внимание на структуру первых 10 комментов: это эксперимент по созданию открытой статьи с рейтингованием отдельных её утверждений и сбором новых агументов для дополнения статьи.
    Естественно, никто не мешает вести свободную дискуссию и вне этих 10-ти комментариев.
    В идеале, я вижу в итоге статью с голосами по пунктам и дополненную наиболее заплюсованными аргументами.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 48
    • –5
      Общее отношение к подходам учета рабочего времени
      • –4
        Предпочтительно детальное заполнение Timesheet
        • 0
          Я по всем пунктам — за второй вариант, за менее формальный, за более коллективный, за более творческий, не убивающий инициативу…
          Программирование ведь командная игра(ну как и в принципе сама жизнь), верно?) Так давайте поощрять «командность»=)
        • –3
          Достаточно управления списком функций Backlog
          • +4
            Отредактировать пост совсем никак? Зачем комменты штамповать?
            • 0
              комменты для голосования и для того, чтобы в них добавлять новые соображения и обсуждать имеющиеся
          • –1
            Оценка фактических затрат. Ипользуется для вычисления премий, выставления счетов, получения метрик эффективности, формирования KPI
            • –1
              Только детальное заполнение Timesheet позволит точно вычислить требуемые метрики
              • 0
                Точности распределения фактических затрат на список реализуемых функций Backlog вполне достаточно для решения всех экономических задач
              • 0
                Накопление статистики для оценки предстоящих проектов
                • 0
                  Точные оценки могут быть получены только из детальных данных Timesheet
                  • 0
                    Усреднённые оценки полученные делением фактических затрат на функции из Backlog достоверно отражают фактические средние затраты команды
                  • 0
                    Точные оценки могут быть получены только из детальных данных Timesheet
                    • 0
                      А тут я ошибся, здесь можно о чём-нибудь пошутить =)
                      • +5
                        Знаете, мне кажется вы убиваете желание вести диалог с помощью комментариев к статье, таким вот формальным подходом…
                        • +5
                          Такая структура этих «10-ти комментариев» (я имею ввиду что каждый делится на две ветки), зачем?) чтобы собрать в каждой под-ветке тех кто за нее?) так в таком случае обсуждения не выйдет, вроде как) а если отписываться и в той ветке, и в той, то на выходе, по идее, получится много перекрестных ссылок)
                          • 0
                            Такая структура чтобы:
                            1. Была возможность проголосовать за подход по конкретному критерию
                            2. Была возможность добавить аргумент к конкретному критерию
                            Ну и потом — у нас нет стандартной структуры такого обсуждения. Возможно, есть вариант организовать иначе.
                            Я придумал такой вариант и решил поэкспериментировать с ним.
                            • 0
                              Давайте не забывать, что форма общения на этом ресурсе не формализирована) Мне кажется структура тут не нужна), структуру можно было бы получить потом, просуммировав уже комментарий каждого, составив некий отчет)
                              И не стоит забывать) кто ваша целевая аудитория, это люди которые не согласны мириться с чем-то, просто потому, что «есть правило, и нужно ему следовать», если есть правило, оно должно быть рациональным, оно должно что-то упрощать, оно должно помогать решать задачу)
                              Ваших аргументов в пользу этой структуры явно не достаточно.
                              Что у такой структуры комментариев есть такого, чего нет у всех других статей?)Чего мы не видим?)
                              • 0
                                такая структура и не нужна другим статьям. Речь идет об этой конкретной статье. я хотел получить для неё голосование по пунктам.
                        • –3
                          Аспект 3: Мониторинг текущего проекта
                          • –3
                            Для своевременного и адекватного оценивания состояния проекта требуется детальная отчётность по всем работам
                            • –1
                              Состояния реализации запланированных функций и ежедневных «статус-митингов» вполне достаточно и для тактического и для стратегического мониторинга хода проектов
                            • 0
                              Аспект 4: Командное взаимодействие
                              • 0
                                Детальный учет работ позволяет поддерживать дисциплину и не мешает командному взаимодействию
                                • 0
                                  Акцент на реализации функций и отсутствие бюрократического учета облегчает командное взаимодействие
                                • 0
                                  Аспект 5: Индивидуальная производительность, мотивация
                                  • 0
                                    Данные из Timesheet позволяют стимулировать производительность и строить модель мотивации
                                    • 0
                                      Акцент на общей результативности работ повышает и производительность и мотивацию
                                    • 0
                                      Аспект 6: Избавление от неэффективных сотрудников
                                      • 0
                                        Система заполнения timesheet позволяет точно и объективно оценивать эффективность сотрудников и защищает от бездельников
                                        • 0
                                          Хорошая команда профессионалов должна иметь возможность саморегуляции
                                        • 0
                                          Аспект 7: Эмоциональное состояние сотрудников
                                          • 0
                                            Нормальному дисциплинированному сотруднику не сложно потратить 5 минут в день на заполнение timesheet
                                            • 0
                                              Команда чувствует себя намного лучше, когда не тратит усилия на излишние бюрократические процедуры
                                            • 0
                                              Аспект 8: Реализация рутинных проектов
                                              • 0
                                                Система детального учета рабочего времени позволяет поддерживать дисциплину и эффективность на любых типах проектов
                                                • 0
                                                  Успешные команды найдут способ реализовать рутинный проект так, чтобы все стороны остались довольны
                                                • 0
                                                  Аспект 9: Реализация сложных, нестандартных проектов
                                                  • 0
                                                    Хороший учёт затрат позволяет адекватно распределять усилия и оценивать творческие идеи, что необходимо в сложных, нестандартных проектах.
                                                    • 0
                                                      Команда должна концентрироваться на решении прикладных задач, вместо учёта часов, потраченных на необходимые обсуждения
                                                    • +8
                                                      у меня такое ощущение, что обсуждения с такой структурой вы не получите. единственный шанс получить нормальный фидбэк по интересующим вас вопросам — удалить пост (так как комментарии удалять нельзя). написать новый пост с таким же текстом, но без десятка излишних совершенно комментариев.
                                                      • –2
                                                        А как тогда голосовать по пунктам?
                                                        Я не утверждаю, что этот подход единственно верный. Я пробую.
                                                        И потом — что мешает вести свободную дискуссию здесь, ниже?
                                                        • +2
                                                          Мешает тем, что вы наспамили коментов, которые по сути не коменты, а темы для обсуждения.
                                                          • –1
                                                            Негатив я уже вижу. Предложите альтернативную структуру с возможностью выделения пунктов для голосования.
                                                            • +2
                                                              Сделайте отдельное голосование от топика
                                                              • 0
                                                                да, никакого негатива не было. предложили вам просто убрать эти комментарии.
                                                                как видите, с вашим подходом обсуждения/голосования вы не получили. хотя, думаю, многим тема интересна.
                                                        • 0
                                                          Мне кажется, что учет рабочего времени нужен, но команда не должна отвлекаться на него. Заполнять какие-то бумажки, отчеты.… Лучше автоматизировать процесс с помощью специальной программы учета и все.
                                                          • 0
                                                            Мне кажется, что метод Timesheeting на западе чаще называют Time Tracking. Мы на работе используем Time Tracker primaERP. Когда я запускаю по конкретной задаче таймер это мобилизует. Это в какой то степени «заставляет» лучше концентрироваться на конкретной задаче, если не хочешь увидеть в результатах нецелевое использование часов. Важно собирать статистику по использованному времени, чтобы понимать в каких пропорциях и на что оно тратится.

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