Управление проектами с почасовой оплатой

    Расскажу о том, как превратить почасовую оплату в отличный способ управления проектом. А также о том, как заказчику (менеджеру проекта) не волноваться о завышении сроков разработчиком, а разработчику не беспокоиться, что заказчик будет его двигать по срокам.


    Цели участников проекта



    Цель заказчика — выполнить проект в рамках выделенных ресурсов (временных, финансовых и человеческих). При почасовой оплате количество контролируемых ресурсов сужается до одного — человеко-часа, а чем меньше параметров для контроля — тем лучше контроль.

    Цель разработчика — больше заработать и повысить профессионализм (отдачу от затраченного времени и как следствие больше зарабатывать). У разработчика есть два способа больше заработать — больше работать (больше часов) и работать лучше (эффективнее и иметь более высокую оплату за час труда). Увеличивать время до бесконечности нельзя, а вот уменьшить время, затрачиваемое впустую, можно. И самый простой способ это делать — изучать на что нужно тратить время в первую очередь, научившись экономить ресурсы заказчика.

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

    Метод «как ты будешь это делать?»



    Ключевые моменты метода:

    • Исполнитель сам описывает свои действия по решению задачи и сам их оценивает;
    • Заказчик соглашается с этой оценкой или предлагает свой способ реализации;


    1. Постановка задачи.



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

    2. Разработчик разбивает задачу на этапы по функционалу.



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

    Некоторые разработчики боятся этого шага, ожидая что от них требуется что-то наподобие ТЗ (которое писать никто не любит) — не надо никакого ТЗ, формализма, графиков, UML-ов и прочих улетных технологий ухода от реальности, просто описать реализацию как есть, как она видится разработчику. Например:

    1. Посмотрю на сайте таком-то как эту задачу делали другие.
    2. Произведу изменения в БД
    3. Создам в БД таблицу «messages» с полями: id, from_id, to_id, message, time, is_readed.
    4. Добавлю в таблицу «users» поле «new_messages»
    5. Дополню модель
    6. Добавлю в модель пользователя методы: send_message(user_id, message), read_message(id), get_all_messages()
    7. Метод send_message сохраняет сообщение в таблицу messages и инкрементирует поле new_messages у отправляющего пользователя
    8. Оповещения
    9. Скачиваю и подключаю библиотеку jquery
    10. Пишу функционал ввода окна нотификации
    11. Вставляю в шаблон код вызывающий нотификацию
    12. Тестирую и отлаживаю


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

    Важно — если человек не может внятно описать как он собирается что-то делать, он не сможет это сделать в разумные сроки вообще.

    3. Разработчик определяет сроки



    Зная, теперь, как и что он будет делать, разработчик подсчитывает сколько времени займет реализация каждого этапа. Важно сначала описать весь функционал (этап 2), не задумываясь о сроках, а затем оценить его.

    Например:
    1. Поиски решений на сайтах — 20 минут.
    2. Изменения в БД — 15 минут.
    3. Дополнение модели — 30 минут.
    4. Оповещения — 90 минут
    5. Тестирую и отлаживаю — 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) или пойти погулять. В любом случае его работа оплачивается в размере планового срока (стоимость часа * премиальный коэффициент * плановый срок), то есть фактически он заработал себе и премию, и часы-отгулы.

    Резьюм



    Таким образом с помощью описанной методики:

    • Устанавливается действительно рабочий регламент, разработчик заинтересован сделать быстрее, а заказчик получает возможность экономить ресурсы правильнее описывая свою задачу.
    • Мы имеем задачу, с четко выраженным планом: этапами, способами и сроками их выполнения. Не навязанные, а рожденные совместно с разработчиком (по большей части им самим).
    • Разработчик не углубляется в мифический «нужный когда-нибудь функционал», а делает только то, что нужно, таким образом экономит и свое и чужое время.
    • Укладываемся в срок приоретизируя функционал.


    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 19
    • 0
      Не слишком ли много времени будет уходить на обсуждение?
      • 0
        Смотря какая задача. Я предпочитаю долго обсуждать и быстро делать.

        А если разработчик всегда без обсуждения и планов точно выдает срок с которым ты согласен и в этот срок укладывается — то им с таким разработчиком и методик управления никаких не нужно.
        • 0
          Долго обсуждать это правильно, главное чтобы мне за это время тоже заплатили :)
    • 0
      знаете, в Советском Союзе, в котором экономическая составляющая, хотя и не игнорировалась, но стояла не на первом месте, очень быстро (буквально за два года) отказались от сдельной оплаты труда, которую вы собственно и описали
      проблема в том, что подобный подход будет иметь позитивный эффект только среди самомотивированных личностей, в противном случае вы разоритесь на контролерах, контролерах контролеров и т.д.
      и второе, вы по-сути, превращаете каждого программиста в ИП (или как нынче модно называть — фрилансера) — соответственно, многократно возрастают затраты на менеджмент
      • 0
        В Советском Союзе с системами мотивации и управления было все в порядке.

        До сих пор встречаю среди современных консультантов по управлению «новоявленные методики», описанные еще в 70-х года отечественными социологами. Слишком многое мы выкинули, как «само собой разумеется неправильное», только потому что это применялось в СССР, даже не углубляясь в детали.
        • 0
          Мотивация тут не причем. Главное чтобы человек мог объяснить как он это будет делать. Когда он будет знать как он сделает, он будет знать и точный срок.

          Чаще же всего сроки называют просто от балды, на глаз определяя сложность/легкость.
          • 0
            а вы не когда не беретесь за задачи, которые не знаете как решить?
            у вас скучная жизнь :) — это конечно же только имхо, хорошо что все люди разные
            • +1
              В таком случае берется задача «Поиск способа решить», по окончании которой известен способ и сроки.
              • 0
                Берусь, но я все равно знаю как ее решу :)

                А заказывать разработчику задачу, которую он не знает как решить, это уже венчур :)
          • –1
            Во-первых, как сказали выше, куча времени будет уходить та тупую болтовню. Причем «куча времени» — это еще слабо сказано! Если заявляется, что такой подход поможет заказчику лучше контролировать стоимость (через количество часов) — то резонно предположить, что он таки будет это делать. Соответственно получаем испорченный телефон «заказчик-менеджер-прогер», в котором прогеру постоянно надо объяснять заказчику (дубу) через менеджера (тоже дуб) почему ХХХ делать именно 90 минут а не 15.

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

            Далее — момент, что всю ответственность (в плане оплаты за работу) несет программист, который если вылез за оговоренное время — то ничего сверху не получает. Это, с одно стороны, правильно — будет его мобилизовать. А с другой — такой подход 100% приведет к сильному завышению сроков, особенно на задачах, которые вот прям так сразу и непонятно как делать (вариант: как лучше делать). А завышение приведет к новой волне споров типа «а че так долго??».

            Итого метод — от реальности оторвано ну очень сильно! Работать если и будет — то только на очень-очень простых задачах, которые можно сходу точно оценить.
            • 0
              «Далее — момент, что всю ответственность (в плане оплаты за работу) несет программист, который если вылез за оговоренное время — то ничего сверху не получает.»

              перечитайте:
              «Если разработчик не уложился в установленные им же самим сроки, он получает сумму в обговоренном размере стоимости часа за! фактически! потраченное время.»

              он получает за каждый просроченный час
              • 0
                Хм, прошу прощения, как-то не бросилось в глаза слово «фактически». Кроме того, оно немного противоречит общему смыслу методы. Ну какой же тогда смысл в предварительной оценке времени если оплата все равно будет идти «по факту»?
                Вариант «а если сделает быстрее — то премия» — ту не пройдет. Точнее пройдет не более одного раза. Как только прогер сделает кусок быстрее, чем обещал — в следующий раз ему время просто порежут. В пропорции к предыдущему разу. «А че, может же и быстрее?» :)
              • 0
                Реально метод работает уже не первый год в различных предметных областях. Сожалею что вам не повезло с менеджерами :)
              • +5
                Мне кажется, эта методика оценки и согласования времени крайне подвержена одной очень неприятной проблеме, присущей любым «переговорным играм». Если вы читали книгу «Смертельный марш. Путь камикадзе» Йордона, вы должны меня понять — болезнь называется «угадай число».

                Вкратце это выглядит так.
                «Угадай число, которое я задумал» – такую игру я уяснил на одном из моих первых проектов, когда был ещё молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются чётко её сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много – попробуй угадать ещё раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придётся отвечать за неё.
                Если программист (исполнитель) не чувствует себя уверенным настолько, чтобы продвигать свои оценки и пре необходимости даже давить на заказчика в оценке сроков, настаивая на правильности, то вскоре он падет жертвой подобных игр. Это неприятно.

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

                • +1
                  Дельное замечание, спасибо! Особенно за книгу, которую не могу теперь нигде найти в продаже :)

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

                  Я недавно закончил ремонт в квартире, и не раз с работниками возникал вопрос об оплате и сроках. Когда исполнители заявляют цену они обосновывают это некой сложностью работы. Если попросить рассказать как он собирается выполнять эту работу, очень часто для самого исполнителя она начинает выглядеть не такой сложной. А иногда выясняется что исполнитель банально не компетентен и реально не знает как он будет ее выполнять.

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

                  У меня даже тест есть такой для отбора претендентов на должность монтажников — обьяснить как они будут вешать ящик.

                  Варианты ответов:

                  Вася:
                  — Ну, это, возьму и повешу.
                  — А что вы сделаете сначала?
                  — Ну сначала я это, прикручу ящик.
                  — А отверстия для анкеров когда будете делать?
                  — А, да, сначала отверстия просверлю.
                  и т.д.

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

                  Как вы думаете кто выполнит задачу четко и в срок и кого возьмут на работу?
                  • 0
                    >>15 августа 2009, 00:00
                    Это вин! :)

                    Теряюсь в догадке, кто выполнит первым — из того, что человек не может объяснить вам, совсем необязательно следует то, что он сам будет «потерянным».

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

                    P.S. Книга есть в сети. Поищите по словосочетанию «двойной плевок пустышкой» :)
                    • +1
                      надо брать обоих, второго назначаем главным монтажником — пусть, раз так складно глаголет, руководит первым :)
                  • 0
                    Все правильно в методике работы. Именно так я и получаю «правильных» заказчиков.

                    Но вот оплата по часам…

                    Стандартная для меня ситуация когда работа сделана немного раньше срока или вообще вне плана — сильно заранее. Я вроде как получаю свободное время на отдых, самообраование, другие проекты. Но в реальности, если поставить работу в половину срока, то через 2-3 проекта возникает вопрос с оценкой работ.

                    Менее часто встречающая ситуация, когда работы затянулись. Как правило причины две — либо другой проект повлиял на общий план, либо ожидания были нарушены внешним фактором — обнаружен баг в библиотеке или глюк в ПО. Первое оплачивать заказчику вроде как не с руки, а второе некий форс-мажор, и вменяемые заказчики адекватно оценивают доп работы отдельно.

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

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