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