Евгений Пригаров
Руководитель программы проектов в ГК Юзтех
Введение
Здравствуйте. Меня зовут Евгений Пригаров, я руководитель программы проектов в ГК Юзтех. С 2006 года я занимаюсь оценкой проектов, работал на пресейлах в 4-х компаниях разного масштаба. В совокупности за эти годы я отработал 1000+ пресейлов.
В этой статье я хочу поделиться своим личным опытом, подходом и рекомендациями к оценке проектов и созданию технико-коммерческих предложений (ТКП). Эти рекомендации довольно простые и, возможно, покажутся банальными, но на мой взгляд, они хорошо работают. Они позволяют разумно и эффективно использовать время и возможности.
Из статьи вы узнаете:
Как качественно оценить проект?
Как создать качественное ТКП?
Как качественно подать результаты оценки?
Дисклеймер:
— Качественная оценка и ТКП не гарантируют победы в пресейле;
— Качественная оценка и ТКП не гарантируют успешного выполнения проекта. Чтобы проект был выполнен успешно, нужно и на всех последующих этапах проекта отрабатывать возникающие задачи на пределе своих возможностей.
Зачем стараться?
Зачем тогда стараться оценивать и писать ТКП, если нет никаких гарантий?
Стараться всё-таки стоит и вот почему:
В ходе декомпозиции оценки и написания (формулирования) ТКП происходит лучшее понимание проекта, возникают правильные вопросы, появляется более чистое видение проекта. Более чистое видение приводит к выявлению рисков, формулированию правильных выводов и допущений. Это, в свою очередь, ведёт к более продуманной оценке проекта, более осмысленному предложению.
Оформление этого видения в качестве полноценного ТКП приводит к получению следующего результата:
— Конкурентоспособность. Формирование более конкурентноспособного предложения при прочих равных (цена, «заходы», экспертность и т.п.).
— Защита. Возможность защитить оценку перед Заказчиком на базе уже продуманных в ходе оценки идей, вопросов.
— Снижение рисков проекта. Формирование защиты от рисков (в том числе и рисков недобросовестности Заказчика) для последующего более безболезненного выполнения проекта. За счёт чёткого формирования шестиугольника компромиссов.
Как следствие:
— Возможность выиграть проект при прочих равных;
— Даёт больше шансов не расплескать его по дороге.
Условия, в которых происходит оценка проекта
1. Неопределённость – информации для оценки всегда недостаточно.
2. Срочность – всегда есть спешка с принятием решения или есть очень ограниченное время на уточнение вопросов.
3. Дефицит рабочего времени – мало того, что Заказчик давит, так еще и груз собственных задач тоже не даёт много времени на оценку.
В результате мы получаем рискованность. Исполняющая организация всегда идёт на риск, когда даёт оценку Заказчику. Но его не надо бояться: его надо стараться сократить, а что сократить нельзя – то осмысленно принять.
Вообще я не боюсь недооценить проект. Я боюсь его недопонять. Когда я его недопонимаю, то сильно переоцениваю. Что тоже плохо и возможно даже хуже недооценки.
Цель создания оценки
Итоговая цель — это чёткое формирование шестиугольника компромиссов (Содержание, Время, Бюджет, Риски, Ресурсы, Качество).
Принципы создания оценки
В своей работе я стараюсь следовать следующим принципам:
1. Минимизация усилий. Оценка должна быть сделана с применением усилий несоизмеримо малых по сравнению с усилиями, требующимися на реализацию проекта. Причина этому узкая воронка.
2. Целостность. Учёт всех функциональных требований, нефункциональных требований, поддерживающих работ и процессов. Включая те, которые в явном виде не указаны во входящей документации Заказчика. Это все затраты времени, денег и т.д.
3. Обоснованность. У каждой цифры в оценке должно быть обоснование. Тот, кто цифру поставил, должен понимать, почему она именно такая, и уметь свою оценку в случае необходимости объяснить.
Она может получиться из параметров модели, нормативов компании, аналогичных проектов, количественных характеристик проекта (форм, отчётов).
В этом может помочь описание оцениваемого требования, его количественный состав и отсылка к предыдущему опыту.
4. Реалистичность. Реализуемость проекта, который будет создаваться по данной оценке. Команда, которая делала оценку, должна быть готова к такому: «Всё, завтра старт. Поехали. Вы в проекте». После этих слов она не должна отказываться от оценки, а должна быть готова сделать проект по той оценке, которую подготовила.
Подводя итог: качественная оценка — это оценка сделанная минимальными усилиями, всесторонняя, обоснованная (защищаемая) и реализуемая.
Рекомендации по оценке проекта
Теперь хочу дать несколько советов по оценке проекта.
1. Минимальная достаточность. Формулирование и оценка только объема работы, минимально необходимого для выполнения бизнес-требований. Маленькую систему оценить проще чем большую. Её проще сделать, проще сдать, проще получить деньги. До больших размеров система разрастётся и без нашей помощи.
2. Сокращение неопределённостей. Любую найденную в оцениваемом проекте неопределённость нужно убирать. Фразу «разберёмся позднее» я допускаю только для технологий разработки уровня «библиотека» (при условии взаимозаменяемости и приближенности усилий). Неопределённости, как правило, создаёт «квантор всеобщности», употребляемый во входящей информации.
Самый лучший способ ухода от неопределённости — замена слов «все», «любые», «и т.п.» на конкретное перечисление или конкретное число.
3. Учёт неявных требований, прямо не указанных в исходящей от Заказчика документации, без которых бизнес-требования не выполняются. Здесь есть тонкая грань в том, чтобы не выдумывать требования без необходимости. В этом случае стоит опираться на свой опыт и знания.
4. Учёт нефункциональных требований. Я указал этот пункт отдельно, так как часто видел, как нефункциональные требования забывались, и из-за этого бывали проблемы. Даже если их нет в исходящей от Заказчика документации, они всё равно в проекте присутствуют.
Есть три варианта как с ними поступить:
— не упоминать, игнорировать;
— упомянуть с атрибутом «требование не предъявлено»;
— написать априори выполнимое нами требование и оттолкнуться от него.
Мне больше нравится третий вариант. Он позволяет при обсуждении с Заказчиком оценки получить какой-то новый пласт информации и уточнить ожидания.
5. Помнить о технологиях разработки. Не все технологии ведут к одинаковому результату, не у всех технологий к нему одинаковый путь. Особенно это касается реализации нефункциональных требований.
6. Альтернативные оценки. Лучше иметь по возможности 2-3 альтернативные оценки одной и той же оцениваемой базы. Это лучше помогает понять пробелы и неоднозначности в требованиях, сформулировать правильные вопросы и допущения.
7. Не все риски можно закрыть деньгами. Поэтому не стоит раздувать бюджет рискованного проекта. Но далеко не все разделяют это мнение.
8. Вопросы Заказчику. Желательно задавать такие вопросы, ответы на которые: уточняют бизнес смысл и прямым образом влияют на оценку проекта
9. Не мельчить в описании требований. Желательно оставаться на одном достаточно высоком уровне описания требований. Оценка из 10 пунктов, на мой взгляд лучше, чем оценка из 100 пунктов.
Теперь перейдём к следующему разделу – оформлению ТКП. И начну я с принципов его оформления.
Принципы оформления ТКП
Перед нами стоит цель в оформлении оценки для подачи ТКП Заказчику с целью продажи. По сути, ТКП является инструментом продажи. Итак, принципы:
Конкурентоспособность. Кроме, собственно, оценки должно являться свидетельством и подтверждением наших конкурентных преимуществ.
Прозрачность формирования цены. Соблюдение этого принципа даёт возможность осуществлению разумного торга по структуре проекта.
Полнота (завершённость). ТКП должно иметь завершённый вид (все аспекты проведённой оценки должны быть отражены в ТКП). Должен быть раскрыт шестиугольник компромиссов, заложенный в оценку, о котором я писал чуть выше.
Читабельность. Для меня читабельность заключается в:
— Аккуратности и продуманности шрифтов;
— Грамотной русской речи, орфографии, пунктуации;
— Наличии табличных и графических форм представления информации;
—Лаконичности и структурированности текстуальных описаний.
Шаблонность. По возможности ТКП должно создаваться по шаблону, собираться из готовых модулей, сокращая время на подготовку и позволяя концентрироваться на сутевой части предложения, а не на его оформлении.
Главное основание для работы по проекту. Это главный документ, к которому предстоит обращаться в случае спорных ситуаций. Оно должно устранять необходимость обращения к предшествующим документам Заказчика. То есть, это своеобразная «конституция» проекта. Если нам дают возможность написать конституцию, то не стоит от такой возможности отказываться. Я прикладывал ТКП к договорам.
Оценку мы сформировали, а теперь её нужно донести до Заказчика. Для этого мы пишем сопроводительное письмо. Как это сделать? Опишу в следующем разделе.
Принципы создания сопроводительного письма
Как должно выглядеть описание оценки или сопроводительное письмо? По сути, это краткая выжимка ТКП, размером в 1 страницу формата А4.
Что в неё стоит добавить?
1. Легкое введение, восстанавливающее контекст (напоминание договоренностей, на чём остановились в прошлый раз);
2. Ссылку или вложения с более подробными результатами (Оценка, ТКП и т.п.)
3. Краткую оценку срока, стоимости, [опционально] ресурсов проекта;
4. Что будет результатом проекта (что за система, рамки, объём);
5. Что организационно входит в эту стоимость: какие процессы, гарантия, работы помимо собственно разработки;
6. Ключевые допущения, лежащие в основе оценки (риски): технологии, количество характер интеграций, состав и характер отчётности, параметры нагрузки, если уместно. Можно приводить погрешность оценки и необходимость переоценки на определённых этапах;
7. Призыв к действию (предложение созвониться, встретиться, что-то сделать с этой оценкой).
Итак, мы рассмотрели принципы создания ТКП и оценки проектов. Я надеюсь, что мой опыт поможет вам в этом. Оставляйте обратную связь в комментариях и поделитесь своим опытом.