Ни для кого не секрет, что большинство команд разработчиков регулярно или периодически встречаются с ситуациями проваленных сроков выполнения и превышения планируемого бюджета проектов. В англоязычном интернете можно найти очень много информации по этому поводу. Более того, каждый более или менее опытный разработчик, как правило, имеет собственное мнение на этот счет.
Задача правильной оценки трудозатрат проекта и сроков его выполнения является жизненно важной для любой команды разработчиков. И главное, что все это понимают очень хорошо! Так в чем же дело? Почему проекты регулярно делаются дольше и существенно дороже, чем планировалось?
Как правило, чаще всего называют следующие причины:
Таким образом, чтобы сдать проект в срок и в утвержденный бюджет требуется внимательно и детально прояснить требования с заказчиком и утвердить их. Стандартный и, на мой взгляд, правильный порядок подготовительных работ сводится к написанию тех задания, подготовки и утверждения мокапов с заказчиком и, в конечном счете, к созданию интерфейсного прототипа. После выполнения этих нескольких пунктов квалифицированному аналитику достаточно просто корректно оценить трудозатраты по проекту и спланировать сроки выполнение.
Но на практике так происходит очень редко. Почему?
Для решения данной задачи компании часто делают предварительную оценку и только в случае, если видят серьезную заинтересованность клиента, начинают глубокий и системный анализ. А часто бывает, что у менеджера по продажам нет возможности несколько раз менять бюджет с клиентом и продажа проходит по цене озвученной в ходе поверхностной оценки проекта. И тогда компания на свой страх и риск берет на себя ответственность выполнения подобного проекта.
Думаю, что я не раскрыл чего-то нового для тех, кто делает это ежедневно. Проблема так и остается для многих команд нерешенной.
Для того чтобы разрешить эту проблему очевидно нужно выстраивать системный процесс работы с новыми запросами на проекты и соответственно с клиентами. Очевидно, менеджер по продажам и технический аналитик должны обладать необходимыми знаниями и опытом для работы с клиентами и оценки проектов. Но под систематизацией я подразумевают формализацию процесса с разбиением его на конкретные этапы и назначения для каждого этапа.
Что мы придумали, чтобы улучшить ситуацию?
Еще в 2011 году мы поняли, что большая доля ошибок возникает на этапе первоначальной оценки проекта. При этом еще было очевидно, что использование excel табличек для оценки трудозатрат и встраивание их в word шаблон коммерческого предложения занимает время, да еще и порождает мелкие ошибки, которые часто сотрудники пропускают. А еще стало понятно, что сотрудники даже не всегда знают, что требуется сделать, написать, продумать при формировании оценки проекта и создании коммерческого предложения.
Мы решили написать внутреннее приложение для оценки проекта и подготовки сразу коммерческого предложения. Решено было заставить технического аналитика в обязательном порядке проходить по конкретным страницам и заполнять требуемый поля. А саму оценку проекта вывести на отдельную страницу в виде таблички аналогичной excel (возможность пользоваться почти теми же горячими клавишами и водить данные с клавиатуры). При этом технический аналитик должен был любой проект разделить на стадии выполнения, модули (крупные части требований), а также задачи и подзадачи вплоть до самых маленьких. Таким образом, любая оценка стала осуществляться с заполнением конкретных полей и, главное, весь объем работы системно разделялся на огромное количество мелких задач разбитых по модулям и стадиям. В результате точность оценки повысилась и уже на этапе первоначальной подготовки предложения возникало масса очень конкретных и мелких вопросов, ответы на которые позволяли дать еще более точную оценку. Менеджер продаж при этом должен был заполнить только несколько страниц и определить бюджет (на основе стоимости за час или дать общую цену), условия оплаты и добавить различные маркетинговые данные.
Далее мы разграничили ответственности менеджера продаж и технического аналитика. Часть страниц мог заполнять только технический аналитик, а часть страниц только сотрудник, ответственный за продажи и формирование стоимости проекта. Таким образом, технический аналитик видел только техническую часть, а менеджер продаж не мог менять что-либо в технической части предложения.
Со временем, встретив частые похожие проекты, мы ввели шаблоны (возможность делать оценку / предложение на основе созданного ранее предложения), а также CRM модуль для хранения информации по клиентам и трекинга процесса переговоров.
Таким образом, мы добились резкого улучшения точности оценки проектов. А вся работа, начиная с первоначального получения требования и заканчивая началом работы по проекту, стала существенно более системной. Серьезные ошибки в оценке проектов были исключены.
Позднее мы встретил похожие продукты и перешли на один из них для ежедневной работы. На рынке сейчас существуют несколько похожих приложений, которые могут сильно облегчить процесс анализа и оценки проектов. Их можно найти по таким запросам как «Software project proposal creation». Но важно подчеркнуть, что выбор того или иного программного обеспечения не является абсолютным решением сам по себе. Гораздо важнее построить работу коллектива, вовлеченного в анализ и оценку проектов по четко сформулированным шагам с конкретным промежуточным и окончательным результатом, а также разграничить ответственность сотрудников разной квалификации (продавцов и технических специалистов), требуя от каждого свойственные его ответственности результаты.
Правильная оценка проекта залог успешного его окончания.
Задача правильной оценки трудозатрат проекта и сроков его выполнения является жизненно важной для любой команды разработчиков. И главное, что все это понимают очень хорошо! Так в чем же дело? Почему проекты регулярно делаются дольше и существенно дороже, чем планировалось?
Как правило, чаще всего называют следующие причины:
- Потому что появились новые требования от заказчика;
- Потому что в оценке не учли часть требований от заказчика;
- Потому что встретили непредвиденные технические сложности.
Таким образом, чтобы сдать проект в срок и в утвержденный бюджет требуется внимательно и детально прояснить требования с заказчиком и утвердить их. Стандартный и, на мой взгляд, правильный порядок подготовительных работ сводится к написанию тех задания, подготовки и утверждения мокапов с заказчиком и, в конечном счете, к созданию интерфейсного прототипа. После выполнения этих нескольких пунктов квалифицированному аналитику достаточно просто корректно оценить трудозатраты по проекту и спланировать сроки выполнение.
Но на практике так происходит очень редко. Почему?
- Потому что заказчик хочет получить цену раньше, чем требования будут согласованы детально
- Потому что выполнять упомянутые работы для каждого нового запроса бесплатно очень накладно
- Очень часто техническому аналитику морально тяжело ежедневно вникать в каждый новые запросы на проекты и делать тщательный анализ и соответственно правильную оценку
- И главная проблема: очень часто человек, оценивающий проект, не знает точно, как системно подойти к его оценке. А менеджер по продажам часто не знает, как правильно составить коммерческое предложение на базе полученной оценки. И достаточно часто, особенно в маленьких фирмах, это делает один и тот же человек, либо с техническим, либо с экономическим образованием. Что также плюсов к правильности оценке трудозатрат и бюджета не добавляет.
Для решения данной задачи компании часто делают предварительную оценку и только в случае, если видят серьезную заинтересованность клиента, начинают глубокий и системный анализ. А часто бывает, что у менеджера по продажам нет возможности несколько раз менять бюджет с клиентом и продажа проходит по цене озвученной в ходе поверхностной оценки проекта. И тогда компания на свой страх и риск берет на себя ответственность выполнения подобного проекта.
Думаю, что я не раскрыл чего-то нового для тех, кто делает это ежедневно. Проблема так и остается для многих команд нерешенной.
Для того чтобы разрешить эту проблему очевидно нужно выстраивать системный процесс работы с новыми запросами на проекты и соответственно с клиентами. Очевидно, менеджер по продажам и технический аналитик должны обладать необходимыми знаниями и опытом для работы с клиентами и оценки проектов. Но под систематизацией я подразумевают формализацию процесса с разбиением его на конкретные этапы и назначения для каждого этапа.
Что мы придумали, чтобы улучшить ситуацию?
Еще в 2011 году мы поняли, что большая доля ошибок возникает на этапе первоначальной оценки проекта. При этом еще было очевидно, что использование excel табличек для оценки трудозатрат и встраивание их в word шаблон коммерческого предложения занимает время, да еще и порождает мелкие ошибки, которые часто сотрудники пропускают. А еще стало понятно, что сотрудники даже не всегда знают, что требуется сделать, написать, продумать при формировании оценки проекта и создании коммерческого предложения.
Мы решили написать внутреннее приложение для оценки проекта и подготовки сразу коммерческого предложения. Решено было заставить технического аналитика в обязательном порядке проходить по конкретным страницам и заполнять требуемый поля. А саму оценку проекта вывести на отдельную страницу в виде таблички аналогичной excel (возможность пользоваться почти теми же горячими клавишами и водить данные с клавиатуры). При этом технический аналитик должен был любой проект разделить на стадии выполнения, модули (крупные части требований), а также задачи и подзадачи вплоть до самых маленьких. Таким образом, любая оценка стала осуществляться с заполнением конкретных полей и, главное, весь объем работы системно разделялся на огромное количество мелких задач разбитых по модулям и стадиям. В результате точность оценки повысилась и уже на этапе первоначальной подготовки предложения возникало масса очень конкретных и мелких вопросов, ответы на которые позволяли дать еще более точную оценку. Менеджер продаж при этом должен был заполнить только несколько страниц и определить бюджет (на основе стоимости за час или дать общую цену), условия оплаты и добавить различные маркетинговые данные.
Далее мы разграничили ответственности менеджера продаж и технического аналитика. Часть страниц мог заполнять только технический аналитик, а часть страниц только сотрудник, ответственный за продажи и формирование стоимости проекта. Таким образом, технический аналитик видел только техническую часть, а менеджер продаж не мог менять что-либо в технической части предложения.
Со временем, встретив частые похожие проекты, мы ввели шаблоны (возможность делать оценку / предложение на основе созданного ранее предложения), а также CRM модуль для хранения информации по клиентам и трекинга процесса переговоров.
Таким образом, мы добились резкого улучшения точности оценки проектов. А вся работа, начиная с первоначального получения требования и заканчивая началом работы по проекту, стала существенно более системной. Серьезные ошибки в оценке проектов были исключены.
Позднее мы встретил похожие продукты и перешли на один из них для ежедневной работы. На рынке сейчас существуют несколько похожих приложений, которые могут сильно облегчить процесс анализа и оценки проектов. Их можно найти по таким запросам как «Software project proposal creation». Но важно подчеркнуть, что выбор того или иного программного обеспечения не является абсолютным решением сам по себе. Гораздо важнее построить работу коллектива, вовлеченного в анализ и оценку проектов по четко сформулированным шагам с конкретным промежуточным и окончательным результатом, а также разграничить ответственность сотрудников разной квалификации (продавцов и технических специалистов), требуя от каждого свойственные его ответственности результаты.
Правильная оценка проекта залог успешного его окончания.
