Оценка трудозатрат на проект и подготовка коммерческих предложений

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

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

Как правило, чаще всего называют следующие причины:

  1. Потому что появились новые требования от заказчика;
  2. Потому что в оценке не учли часть требований от заказчика;
  3. Потому что встретили непредвиденные технические сложности.

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

Но на практике так происходит очень редко. Почему?

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


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

Думаю, что я не раскрыл чего-то нового для тех, кто делает это ежедневно. Проблема так и остается для многих команд нерешенной.

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

Что мы придумали, чтобы улучшить ситуацию?

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

Мы решили написать внутреннее приложение для оценки проекта и подготовки сразу коммерческого предложения. Решено было заставить технического аналитика в обязательном порядке проходить по конкретным страницам и заполнять требуемый поля. А саму оценку проекта вывести на отдельную страницу в виде таблички аналогичной excel (возможность пользоваться почти теми же горячими клавишами и водить данные с клавиатуры). При этом технический аналитик должен был любой проект разделить на стадии выполнения, модули (крупные части требований), а также задачи и подзадачи вплоть до самых маленьких. Таким образом, любая оценка стала осуществляться с заполнением конкретных полей и, главное, весь объем работы системно разделялся на огромное количество мелких задач разбитых по модулям и стадиям. В результате точность оценки повысилась и уже на этапе первоначальной подготовки предложения возникало масса очень конкретных и мелких вопросов, ответы на которые позволяли дать еще более точную оценку. Менеджер продаж при этом должен был заполнить только несколько страниц и определить бюджет (на основе стоимости за час или дать общую цену), условия оплаты и добавить различные маркетинговые данные.

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

Со временем, встретив частые похожие проекты, мы ввели шаблоны (возможность делать оценку / предложение на основе созданного ранее предложения), а также CRM модуль для хранения информации по клиентам и трекинга процесса переговоров.

Таким образом, мы добились резкого улучшения точности оценки проектов. А вся работа, начиная с первоначального получения требования и заканчивая началом работы по проекту, стала существенно более системной. Серьезные ошибки в оценке проектов были исключены.

Позднее мы встретил похожие продукты и перешли на один из них для ежедневной работы. На рынке сейчас существуют несколько похожих приложений, которые могут сильно облегчить процесс анализа и оценки проектов. Их можно найти по таким запросам как «Software project proposal creation». Но важно подчеркнуть, что выбор того или иного программного обеспечения не является абсолютным решением сам по себе. Гораздо важнее построить работу коллектива, вовлеченного в анализ и оценку проектов по четко сформулированным шагам с конкретным промежуточным и окончательным результатом, а также разграничить ответственность сотрудников разной квалификации (продавцов и технических специалистов), требуя от каждого свойственные его ответственности результаты.

Правильная оценка проекта залог успешного его окончания.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 20

    +1
    Зуб даю, что после всей формализации у вас оценка на единицу функциональности выросла в два и более раза. Так как задачи чаще всего не делаются сильно раньше срока и сильно дешевле бюджета, то вы даже не можете оценить точность попадания, ибо любое превышение оценки над реальной потребностью незаметно съедается.
      0
      Оценка стала реальней. Основная суть в том, на мой взгляд, что чтобы дать оценку более менее верно нужно раздробить задачу на массу взаимосвязанных подзадач. Как правило это позволяет не пропустить чего-то важного. При этом оценка точно получается точнее когда разделяешь все на мелкие части. Но да — это трудозатратно.
      Там еще дополнительный вопрос. Делить все на элементы или на архитектурные части. Скажем часть разработчиков пытается делить всю работу на работы по БД, сервисы, клиентская часть. Другой подход делить все на элементы. Например, для интернет магазина это будут Home, каталог товаров, контакты и вплоть до мелких элементов таких как отдельные кнопки, контролы и т.п.
        0
        Если пытаться декомпозировать задачу сверх вашего понимания её решения, то вы неизбежно чтонить упустите. Например вы всегда занимались СЭД, которые работали на 100 пользователей, а внезапно вам надо сделать чтобы работало на 100000. Вы уверены, что при оценке такой задачи вы ничего не упустите? Я уверен в обратном.

        Чтобы реально ничего не упустить нужно собственно выполнить проектирование, и, скорее всего, сделать прототип. Но если заказчик эти работы не оплачивает, то это крайне большой риск. Увы. Я предпочитают продавить проекты с поэтапной оплатой, чтобы сделать прототип за счет заказчика. Тем более что прототип заказчику нужен также, как и мне, так что это win-win.

        Если же вы знаете как реализовать проект, то детальная декомпозиция вовсе необязательна, достаточно экспертной оценки и поправочных коэффициентов от уровня рисков.
          0
          Не буду спорить. Если предметная область новая и требуется оценить работы из этой области, всегда велик риск ошибки. При этом системный подход с разбиением всего объема задач на конкретные такси все равно является правильным и позволяет сократить ошибки в оценках. При этом мы в этом случае во время оценки делаем дополнительное исследование проблемы. Человек, ответственный за оценку, советуется с другими разработчиками на тему правильности оценки. Но да — ошибиться можно всегда. Я лишь говорю, как можно уменьшить ошибки.
          Касательно прототипа я тоже об этом писал. Любой крупный проект стоит делать поэтапно. При этом первый этап — прототип. И оценивать тогда уже каждый последующий этап. Вот так мы об этом говорим заказчикам: www.yumapos.com/#/services/custom
          Мы делаем следующим образом: оцениваем весь проект (обычно 5000-30000 человеко часов). Первый этап прототип 500-5000 часов. При этом мы заранее говорим заказчику что мы хотим иметь возможность сократить или увеличить время и бюджет проекта после завершения прототипа. Но не более 25% от первоначального бюджета. Обычно заказчики соглашаются. Если же объем новых выявленных задач во время выполнения прототипа превышает 25%, то либо начинаем подрезать где-то, либо объясняем необходимость полного пересмотра бюджета. Иногда соглашаемся на 25% увеличения и все, если маржа и так достаточно большая.
          Но все равно я абсолютно уверен, что системность подхода к оценке проекта или отдельного этапа увеличивает правильность оценки. Проверено на 1000+ случаях))
      0
      Я обычно продаю итерационную разработку и внедрение с малой длиной итерации. Это уменьшает риски заказчика — он может выйти раньше, если поймет что результат его категорически не устраивает. Это уменьшает мои риски, так как я получаю деньги раньше, у меня нету больших гэпов в cashflow. Это увеличивает удовлетворение заказчика, так как он видит работающую систему. Удовлетворение заказчика способствует продаже следующих этапов работ.

      При этом не нужна точная оценка на большой промежуток времени, достаточно примерной с разбросом в 20%-30% и то можно скорректировать, так как заказчик сразу всю сумму не платит. А для оценки работ на пару недель-месяц можно просто и программиста спросить.

      Вообще не понимаю откуда появилось такое стремление продавать большие проекты с огромной неопределённостью.
        0
        Не во всех отраслях это применимо. Увы.
          0
          В каких например? Ну кроме госов.
            0
            Бывают крупные внедрения/миграции enterprise-продуктов. Обычно такие проекты бьются на этапы, но этап может длиться несколько месяцев и стоить несколько миллионов.
              0
              Я делал крупные миграции и внедрения enterprise продуктов. Если за пару месяцев нечего показать, то зря заказчик связался с подрядчиком.

              Сколько конкретно стоит — относительный вопрос. Если внедрение на 10 человек, то несколько миллионов это дорого, если на 10000, то несколько миллионов — ошибка округления в общих затратах.
              0
              Медицина, банки да и госы бывают разные.
                0
                Медицина — госы, в основном, а в частных клиниках легко продать agile и поэтапную сдачу. Банки совсем разные бывают, я работал и госбанками с закупками по 93фз и с небольшими частными банками и не видел особых проблем с поэтапной оплатой и корректировкой scope, чтобы уложиться в фиксированную сумму.
          0
          Поддерживаю идею автоматизации процессов пресейла. Главное, в результате получить нечто большее, нежели красивую обертку над все теми же случайными цифрами.

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

          Кстати, буду рад, если отрекомендуете приложение, нацеленное на российский рынок.
            0
            Согласен. Мы пользуемся swproposal.com. Но есть еще evenflowpro.com, quoteroller.com. И еще несколько точно можно найти. Они все развиваются и полируются в плане функционала и требования заказчиков. Мы работаем для иностранного рынка, поэтому прекрасно подходит английский. Наверное со временем они локализуются. По крайней мере у нас в настройках есть выбор языка, но пока он там только один — английский.
            0
            А вам случаем не на мегамозг? Тематика статьи вроде не «хабравская». Или с песочницей еще непонятки…
              +1
              Ход рассуждений понятный, но полезной информации в статье практически нет.
              «Выстраивайте системную работу» (мышки, станьте ежиками.)

              На какие именно этапы вы разбиваете процесс оценки?

              Какие виды проектов вы ведёте в пределах «внедрения CRM»?

              Каковы были хотя бы группы категорий, по которым велась оценка проекта?

              Какой точности удалось добиться?

              Для того, чтобы провести точную оценку, нужна коммуникация с заказчиком. Насколько выросло время на общение с ним?
                +1
                Спасибо за комментарий.
                Мы занимаемся разработкой POS систем (www.yumapos.com). Каждая система, хоть и имеет общий функционал, уникальна и требует отдельного осмысления и последующей оценки трудозатрат. Средний разброс, как я писал выше, 5000-30000 часов. Последний раз я оценил систему в 27000 часов. И вот при оценке подобной системы мы не можем начать объяснять, что для того чтобы оценить нам нужно сделать прототип. Заказчик хочет сказать что ему надо и через несколько дней получить сроки и бюджет. Мы в этом случае, конечно, каждый раз работаем с более менее понятной для нас областью. Но размер проекта все равно требует усилий по детальной оценке. Скажем в последнем проекте, который я оценивал, было 29 модулей и еще 4 отдельным мобильных приложения с поддержкой четырех платформ (web, desktop, iOS, Android). Изначально показалось (как часто бывает), что проект максимум на 10000 часов. Но когда стал считать и прояснять мелочи получилось 27000.
                Вот с чем я работаю. Я рассказал, чтобы Вы понимали мою ситуацию. У каждого она все таки индивидуальная.

                Теперь отвечу на Ваши вопросы:

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

                2. Если Вы имеете в виду внедрение CRM типа MS Dinamix для заказчиков, то мы этим не занимаемся. Мы делаем проекты разработки с нуля, а также проекты когда мы разрабатываем часть Point of sale системы, а часть продаем готовые модули. Но чаще всего разработки с нуля не менее 50%. Если вопрос в том, какую CRM мы используем, то это тот функционал, что есть в swproposal.com. Она там не супер функциональная. Скорее простая. В основном мы храним информацию о клиенте и трекаем статус отношений с ним. Подгружаем файлы. На каждого клиента создаем проект и предложение или несколько предложений и также отслеживаем процесс переговоров по ним. Сразу извиняюсь, если я не совсем о том. До конца вопрос Ваш не понял.

                3. Обычно мы разделяем объем работы на модули (например раздел Customers, Inventory, Orders liss). Далее делим на крупные задачи в рамках модуля (Customers groups management, customer form, и т.п.) и далее уже делим на мелкие задачи и подзадачи, чтобы каждая задача была 1-10 человеко часов. Если проект подразумевает этапы, то мы распределяем полученный лист задач на разные этапы.

                4. Первоначально мы занимались разработкой всего, что могли найти. Были веб социальные проекты, мессенджеры, веб приложения для автоматизации бизнес процессов, CRM и много чего еще. Тогда мы начали работу по организации процесса оценки. Ранее оценивал просто программист на основании собственного опыта и собственной тщательности. Разные программисты давали сильно разные оценки и разную детализацию проекта. Однажды мы продали проект за 3 человеко-месяца, а делали около года. Сейчас ошибки бывают, но это не катастрофические ошибки и не выходят за пределы 20%. То, что мы сделали — заставили всех, кто участвует в продажах и оценке проектов действовать по утвержденным шагам с детализированной оценкой проекта. Так чтобы все большие задачи разбивались на логично взаимосвязанные маленькие с их последующей оценкой. Это сокращает вероятность ошибки.

                5. Коммуникация, конечно, возросла. Но и возрос процент полученных проектов из тех, что мы оценивали подробно.
                  0
                  Спасибо за развёрнутый ответ.

                  1. Я спрашивал про этапы ОЦЕНКИ, которые вы упоминали в посте, а не этапы ПРОЕКТА. Принципы разбиения проекта отличные.

                  2. Мне не на что было ориентироваться, кроме названий блогов, куда вы запостили. Теперь я знаю вашу специализацию, а у меня как раз проект на эту тему начинается :)

                  3. Как делается оценка функциональности — понятно. А как вы работаете с требованиями к качеству — скорости, надёжности и т.д.? Как именно они влияют на оценку трудоёмкости у вас?

                  4. Супер, мой опыт тоже показывает, что при плохой оценке ошибка достигает 300%.
                0
                Если говорить про POS то там ключевая задача состоит в обеспечении правильности расчетов чека. Там одновременно накладываются масса условий связанных с выбранным товаром, клиентом, существующими маркетинговыми компаниями и т.п. Для того чтобы этого добиться мы все подобные расчеты покрываем тестами (и клиентскую и серверную часть) и соответственно закладываем 50-100% времени на разработку тестов от времени разработки функциональности. В местах не критичных тестов пишем меньше или вообще не пишем. Но при оценке так и пишем скажем:

                Task 1 — 50 man-hours
                Sub task 1 — 10 man-hours
                Sub task 2 — 10 man-hours
                Sub task 3 — 10 man-hours
                Unit tests — 15 man-hours
                QA work — 5 man-hours

                Раньше мы делали все это просто в excel но потом из-за частых ошибок перешли на приложение. Но принцип тот же самый.
                  0
                  Николай, ответьте пожалуйста на мои вопросы 1 и 3 выше.
                  0
                  Мы подстроили процесс под функционал приложения. Получается так:
                  1. Продавец создает карточку проекта (связанную с его клиентом или не связанную) и загружает всю имеющуюся информацию. В последствии, если появляется что-то новое, то тоже добавляет туда в виде подгруженных файлов или комментариев.
                  2. Технический аналитик просматривает карточку проекта, анализирует всю имеющуюся информацию и либо формирует список вопросов, либо начинает работу над технической частью проекта. При этом иногда технический аналитик проясняет все напрямую с клиентом, а иногда через менеджера продаж.
                  (Сразу оговорюсь, что тут я говорю про предварительную максимально точную оценку. Оценку окончательную мы даем после прототипирования, как я и писал выше.)
                  3. В целом, когда информации достаточно, технический аналитик создает техническую часть предложения. Имеется в виду, что он фактически последовательно заполняет поле за полем от технической части с заголовками: «в чем цель проекта», «какие основные требования», «какие возможны риски», «какие основные модули можно выделить», «подгрузите картинку с архитектурой и опишите ее» (одну или много), «выберете технологии из списка», «укажите какие виды тестирования будут применяться», «как будет осуществляться коммуникация», «укажите документацию, которая будет предоставлена с проектом» и далее непосредственно необходимо заполнить таблицу «breakdown» где указать стадии, модули, такси и саб-таски с оценкой трудозатрат и необходимую категорию специалиста (software developer, senior software developer, project manager, QA engineer и т.п.). Далее технический аналитик планирует необходимое количество людей на стадию и сроки выполнения. Переносит отдельные задачи с одной стадии на другую. Описывает конкретный результаты после сдачи каждой стадии (если их больше одной). Когда техническая часть проекта завершена, технический аналитик ставит ее в статус «complete». Фактически количество трудозатрат и сроки проекта после этого уже определены.
                  4. Далее начинается ответственность менеджера продаж или человека ответственного за окончательную стоимость проекта. Менеджер продаж может просматривать техническую часть, но не может ее редактировать. Он же редактирует финансовую часть. Указывает стоимость за час, скидки, налоги (если надо) и получает общий бюджет проекта. Если продаются уже созданные части, которые имеют фиксированную цену, то добавляет их. Добавляет доп. услуги в духе обучения персонала, написание обучающей документации и т.п. Получив общую стоимость, он указывает условия оплаты включая расписание оплаты и способы перечисления денег. Плюс иногда добавляет 2-3 образца портфолио и референсов клиента, и генерит предложение. Соответственно, менеджер продаж тоже указывает статус финансовой части «complete» и после этого технический аналитик уже не может ничего менять в своей оценке.
                  5. Ну и часто этот процесс происходит в несколько циклов. Так как в процессе переговоров клиенту приходят в голову новые идеи или он что-то сокращает, удивив цену выше возможностей. Поступают новые требования и если они существенные мы создаем новое предложения на основе созданного, а если изменения не большие, то просто корректируем созданное предложение.

                  На вопрос 3 я все таки уже пытался ответить. В оценке каждой задачи у нас идет отдельная задача (или несколько) на написание текстов и работу QA инженера. То есть суммарные трудозатраты по задаче включают различные виды автоматического тестирования (для разных случаев применяются разные виды) и времени тестера. Само собой когда все оценивается техническим аналитиком он держит в уме требования к надежности и скорости системы. Исходя из этого и оценивает.

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

                  Самое читаемое