Как составить смету в IT-проекте, чтобы потом не объяснять заказчику, откуда взялись дополнительные работы

Небольшое отступление. За годы работы в IT я видел очень много коммерческих предложений коллег: красивых, пестрых, прекрасных и ужасных. Максимально крутые — это сочетание контента, персонализации и дизайна.

Хотелось отдельно рассказать о структуре КП, которую мы используем, но в целом мы придерживаемся вечной классики — написанная давным-давно Андреем Тереховым, текст можно найти на Хабре. В целом мы придерживаемся этой структуры, пытаемся отказаться от PDF и перейти на цифровые носители. Туда можно и видео прикрутить и интерактив, но пока королями здесь остаются PDF и Эксель. 

Но сегодня не об этом. 

Элементом любого КП является смета. В целом они есть практически везде, без разницы, работает вы в продукте, агентстве, веб-студии и т.д.

У кого-то смета занимает одну страницу, у кого-то Excel растягивается на несколько десятков вкладок. Где-то заказчику показывают только итоговую сумму, а где-то можно найти часы аналитика, ставку программиста, загрузку дизайнера и чуть ли не количество созвонов.

У каждого подхода есть свои причины.

Но важнее всего то, что смета должна помочь заказчику сравнить предложения подрядчиков. По ней заказчик пытается понять сразу несколько вещей: что именно он покупает, из чего складывается бюджет, насколько предложение сопоставимо с другими подрядчиками и где могут появиться дополнительные расходы.

Допустим, у одного подрядчика проект стоит 7 млн, у другого — 10 млн. Кажется, что выбор очевиден. Но если в первой смете нет части интеграций и тестирования, то сравнивать 7 и 10 млн бессмысленно. Поэтому я бы смотрел сначала на состав работ.

Для агентства здесь есть еще одна задача — самим понимать границы проекта. Чем раньше они зафиксированы, тем меньше неприятных разговоров появляется после начала работ.

Классическая смета

или неумирающая классика) 

Классическая смета довольно простая: работа → стоимость → часы → специалист → ставка. Для небольшого проекта этого вполне хватает. Заказчик видит объём, ставку и итоговую стоимость.

Расширенная смета

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

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

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

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

Матричная смета

По сути это некая адаптация горизонтальной сметы, которая была ранее.

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

Функциональная смета

Совмещение вариантов.

Это некая вариация предыдущей сметы, но более компактная. Если ранее мы работали с отдельными блоками (например, дизайн главной страницы и т.д.), то здесь мы уже работает с бэклогами, эпиками, стори. Например, этап “Авторизация” - и смотрим ее со всех сторон ( интерфейс, валидации, права доступа, уведомления, тестирование и т.п.).

Такой уровень детализации позволяет понять состав функциональности и одновременно оставить команде пространство для нормальной работы.

Если обобщить, у сметы есть две крайности.

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

• Слишком общие блоки — потеря значительной части функциональности.

Вообще подходов довольно много, сметы есть в каждой отрасли, где-то обложены нормативами https://www.consultant.ru/document/cons_doc_LAW_48827/ea4c47ee5a4bcd78c37301ff9065ebd1ef1f5a84/

Самая богатая в этом плане смета в сфере строительства:

В любом случае: чем доступнее и понятнее доносится информация, тем лучше.

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

Рекомендации по формированию сметы IT-проекта

1. Декомпозируй — это снижает шанс что-то пропустить, но не переборщи. 

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

3. Смету всегда лучше разбивать на этапы — так будет проще защищать. 

4. Диаграмма Ганта — лучше использовать, чем не использовать.

5. Срок в КП нужно воспринимать как план, учитывая влияние согласований и загрузки команды.

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