Расскажу о том, как превратить почасовую оплату в отличный способ управления проектом. А также о том, как заказчику (менеджеру проекта) не волноваться о завышении сроков разработчиком, а разработчику не беспокоиться, что заказчик будет его двигать по срокам.
Цель заказчика — выполнить проект в рамках выделенных ресурсов (временных, финансовых и человеческих). При почасовой оплате количество контролируемых ресурсов сужается до одного — человеко-часа, а чем меньше параметров для контроля — тем лучше контроль.
Цель разработчика — больше заработать и повысить профессионализм (отдачу от затраченного времени и как следствие больше зарабатывать). У разработчика есть два способа больше заработать — больше работать (больше часов) и работать лучше (эффективнее и иметь более высокую оплату за час труда). Увеличивать время до бесконечности нельзя, а вот уменьшить время, затрачиваемое впустую, можно. И самый простой способ это делать — изучать на что нужно тратить время в первую очередь, научившись экономить ресурсы заказчика.
Эти цели легко удовлетворить, если следовать алгоритму, к которому мы пришли в процессе исполнения проектов в различных предметных областях (от софта, до строительства). Единственное условие для отличного результата в этом алгоритме — менеджер проекта (в нашем случае он же заказчик) должен разбирается в предметной области не хуже разработчика.
Ключевые моменты метода:
Менеджер ставит задачу описывая результат, который хочет получить от требуемого функционала.
Походу выясняя у менеджера нюансы, разработчик описывает, человеческим языком, как он собирается реализовывать эту задачу: какой алгоритм, какой функционал для этого создается, какие файлы трогаются/меняются, какие модули используются. Задачу стараемся разбить на этапы-фичи.
Некоторые разработчики боятся этого шага, ожидая что от них требуется что-то наподобие ТЗ (которое писать никто не любит) — не надо никакого ТЗ, формализма, графиков, UML-ов и прочих улетных технологий ухода от реальности, просто описать реализацию как есть, как она видится разработчику. Например:
Это достаточно важная изыскательная работа и очень хорошее упражнение, для того чтобы разработчик сам понял, а как же он самом деле будет реализовывать этот функционал. Тогда он сможет и более точно распланировать свои действия и точнее определить сроки их свершения.
Важно — если человек не может внятно описать как он собирается что-то делать, он не сможет это сделать в разумные сроки вообще.
Зная, теперь, как и что он будет делать, разработчик подсчитывает сколько времени займет реализация каждого этапа. Важно сначала описать весь функционал (этап 2), не задумываясь о сроках, а затем оценить его.
Например:
Итого: 3 часа 05 минут.
Редко получается сразу правильно оценить сроки. Но через 2-3-4-5 итераций появляется навык и умение планировать и оценивать достаточно точно.
Глядя на описание функционала и установленные разработчиком сроки, менеджер решает принимать ему их как есть или нет.
Если менеджер считает, что какой-то этап можно выполнить быстрее — он объясняет разработчику как это нужно сделать (фактически они возвращаются на 2-й этап) до тех пор пока оба не сойдутся в сроках и способах реализации. Например:
Если испытываются сложности с планированием какого-то этапа, его можно разбить на несколько более мелких, описать и оценить сначала их.
После того как менеджер с разработчиком сошлись по всем срокам он приоретизирует функционал в зависимости от срока его выполнения. Смотрит сколько отведено времени на выполнение каждого пункта вообще и насколько оправдано тратить такие ресурсы (время + оплата) на данном этапе проекта. Если в этом смысла нет, то такой функционал удаляется из текущей задачи и переносится в backlog, до лучших времен.
Например на выполнение задачи «оповещения» в проекте отводилось 90 минут. На данном этапе это расточительно, поэтому сделаем простой вывод значка почтового ящика в профайле, что займет не 90, а 5 минут.
Теперь имеется четкий, рожденный самим разработчиком функционал, план и срок выполнения задачи. После того как менеджер отсеил не нужный функционал и дал отмашку, разработчик приступает к реализации.
Если разработчик видит, что он, все таки, выбивается из графика, что случается и в этом нет ничего страшного, значит что-то он что-то не предусмотрел в первоначальном плане (недоработал изыскательную часть) и немедленно сообщает об этом менеджеру. Менеджер с разработчиком снова начинают обсуждать способ выполнения этого этапа (пункт 2) и выясняют что нужно изменить чтобы он был выполнен в срок.
Если сроки меняются, то менеджер повторно оценивает приоретизацию (пункт 5) и возможно исключает этот этап из задачи, разбивает его н аболее мелкие или принимает новые сроки.
Если разработчик не уложился в установленные им же самим сроки, он получает сумму в обговоренном размере стоимости часа за фактически потраченное время. Если так происходит часто, то есть разработчик не может научиться оценивать время (выполнять пункт 2), вы уделяете этому моменту особенное внимание и обучаете его, если и в этом случае нет результата, про придется с таким сотрудником растаться.
Если разработчик укладывается в срок и даже успевает выполнить задачу быстрее — он уже сам решает, сдать ее раньше и приступить к другой или наполнить ее фичами от которых отказались (см backlog) или пойти погулять. В любом случае его работа оплачивается в размере планового срока (стоимость часа * премиальный коэффициент * плановый срок), то есть фактически он заработал себе и премию, и часы-отгулы.
Таким образом с помощью описанной методики:
Цели участников проекта
Цель заказчика — выполнить проект в рамках выделенных ресурсов (временных, финансовых и человеческих). При почасовой оплате количество контролируемых ресурсов сужается до одного — человеко-часа, а чем меньше параметров для контроля — тем лучше контроль.
Цель разработчика — больше заработать и повысить профессионализм (отдачу от затраченного времени и как следствие больше зарабатывать). У разработчика есть два способа больше заработать — больше работать (больше часов) и работать лучше (эффективнее и иметь более высокую оплату за час труда). Увеличивать время до бесконечности нельзя, а вот уменьшить время, затрачиваемое впустую, можно. И самый простой способ это делать — изучать на что нужно тратить время в первую очередь, научившись экономить ресурсы заказчика.
Эти цели легко удовлетворить, если следовать алгоритму, к которому мы пришли в процессе исполнения проектов в различных предметных областях (от софта, до строительства). Единственное условие для отличного результата в этом алгоритме — менеджер проекта (в нашем случае он же заказчик) должен разбирается в предметной области не хуже разработчика.
Метод «как ты будешь это делать?»
Ключевые моменты метода:
- Исполнитель сам описывает свои действия по решению задачи и сам их оценивает;
- Заказчик соглашается с этой оценкой или предлагает свой способ реализации;
1. Постановка задачи.
Менеджер ставит задачу описывая результат, который хочет получить от требуемого функционала.
2. Разработчик разбивает задачу на этапы по функционалу.
Походу выясняя у менеджера нюансы, разработчик описывает, человеческим языком, как он собирается реализовывать эту задачу: какой алгоритм, какой функционал для этого создается, какие файлы трогаются/меняются, какие модули используются. Задачу стараемся разбить на этапы-фичи.
Некоторые разработчики боятся этого шага, ожидая что от них требуется что-то наподобие ТЗ (которое писать никто не любит) — не надо никакого ТЗ, формализма, графиков, UML-ов и прочих улетных технологий ухода от реальности, просто описать реализацию как есть, как она видится разработчику. Например:
- Посмотрю на сайте таком-то как эту задачу делали другие.
- Произведу изменения в БД
- Создам в БД таблицу «messages» с полями: id, from_id, to_id, message, time, is_readed.
- Добавлю в таблицу «users» поле «new_messages»
- Дополню модель
- Добавлю в модель пользователя методы: send_message(user_id, message), read_message(id), get_all_messages()
- Метод send_message сохраняет сообщение в таблицу messages и инкрементирует поле new_messages у отправляющего пользователя
- Оповещения
- Скачиваю и подключаю библиотеку jquery
- Пишу функционал ввода окна нотификации
- Вставляю в шаблон код вызывающий нотификацию
- Тестирую и отлаживаю
Это достаточно важная изыскательная работа и очень хорошее упражнение, для того чтобы разработчик сам понял, а как же он самом деле будет реализовывать этот функционал. Тогда он сможет и более точно распланировать свои действия и точнее определить сроки их свершения.
Важно — если человек не может внятно описать как он собирается что-то делать, он не сможет это сделать в разумные сроки вообще.
3. Разработчик определяет сроки
Зная, теперь, как и что он будет делать, разработчик подсчитывает сколько времени займет реализация каждого этапа. Важно сначала описать весь функционал (этап 2), не задумываясь о сроках, а затем оценить его.
Например:
- Поиски решений на сайтах — 20 минут.
- Изменения в БД — 15 минут.
- Дополнение модели — 30 минут.
- Оповещения — 90 минут
- Тестирую и отлаживаю — 30 минут
Итого: 3 часа 05 минут.
Редко получается сразу правильно оценить сроки. Но через 2-3-4-5 итераций появляется навык и умение планировать и оценивать достаточно точно.
4. Менеджер оценивает способы и сроки реализации.
Глядя на описание функционала и установленные разработчиком сроки, менеджер решает принимать ему их как есть или нет.
Если менеджер считает, что какой-то этап можно выполнить быстрее — он объясняет разработчику как это нужно сделать (фактически они возвращаются на 2-й этап) до тех пор пока оба не сойдутся в сроках и способах реализации. Например:
Менеджер: я считаю оповещение можно сделать за 15 минут, если применить плагин NotifyBar.
Разработчик: 15 минут мало, уйдет около 30 минут, так как плагин еще нужно подстраивать под свои нужды (он использует другую JS библиотеку)
Менеджер: ok, 30 минут на оповещение.
Если испытываются сложности с планированием какого-то этапа, его можно разбить на несколько более мелких, описать и оценить сначала их.
5. Менеджер приоретизирует функционал.
После того как менеджер с разработчиком сошлись по всем срокам он приоретизирует функционал в зависимости от срока его выполнения. Смотрит сколько отведено времени на выполнение каждого пункта вообще и насколько оправдано тратить такие ресурсы (время + оплата) на данном этапе проекта. Если в этом смысла нет, то такой функционал удаляется из текущей задачи и переносится в backlog, до лучших времен.
Например на выполнение задачи «оповещения» в проекте отводилось 90 минут. На данном этапе это расточительно, поэтому сделаем простой вывод значка почтового ящика в профайле, что займет не 90, а 5 минут.
6. Реализация.
Теперь имеется четкий, рожденный самим разработчиком функционал, план и срок выполнения задачи. После того как менеджер отсеил не нужный функционал и дал отмашку, разработчик приступает к реализации.
Неожиданная задержка
Если разработчик видит, что он, все таки, выбивается из графика, что случается и в этом нет ничего страшного, значит что-то он что-то не предусмотрел в первоначальном плане (недоработал изыскательную часть) и немедленно сообщает об этом менеджеру. Менеджер с разработчиком снова начинают обсуждать способ выполнения этого этапа (пункт 2) и выясняют что нужно изменить чтобы он был выполнен в срок.
Если сроки меняются, то менеджер повторно оценивает приоретизацию (пункт 5) и возможно исключает этот этап из задачи, разбивает его н аболее мелкие или принимает новые сроки.
7. Все готово, оплата.
Просрочка
Если разработчик не уложился в установленные им же самим сроки, он получает сумму в обговоренном размере стоимости часа за фактически потраченное время. Если так происходит часто, то есть разработчик не может научиться оценивать время (выполнять пункт 2), вы уделяете этому моменту особенное внимание и обучаете его, если и в этом случае нет результата, про придется с таким сотрудником растаться.
Выполнили раньше срока
Если разработчик укладывается в срок и даже успевает выполнить задачу быстрее — он уже сам решает, сдать ее раньше и приступить к другой или наполнить ее фичами от которых отказались (см backlog) или пойти погулять. В любом случае его работа оплачивается в размере планового срока (стоимость часа * премиальный коэффициент * плановый срок), то есть фактически он заработал себе и премию, и часы-отгулы.
Резьюм
Таким образом с помощью описанной методики:
- Устанавливается действительно рабочий регламент, разработчик заинтересован сделать быстрее, а заказчик получает возможность экономить ресурсы правильнее описывая свою задачу.
- Мы имеем задачу, с четко выраженным планом: этапами, способами и сроками их выполнения. Не навязанные, а рожденные совместно с разработчиком (по большей части им самим).
- Разработчик не углубляется в мифический «нужный когда-нибудь функционал», а делает только то, что нужно, таким образом экономит и свое и чужое время.
- Укладываемся в срок приоретизируя функционал.
