Процесс оценки IT-проектов — задача комплексная и многослойная, требующая глубокой технической экспертизы и умения предвидеть возможные риски. Если вы представили образ этакой техно-Ванги, сидящей за макбуком, то в целом это недалеко от истины — примерно так и выглядит команда, которая выполняет оценку новых проектов. Чтобы лучше видеть будущее и не упустить ни одной детали, наш Head of Backend Евгений поделился советами, которые помогут избежать недооценки проекта, выявить потенциальные риски и точно определить ресурсы на разработку.
Можно ли сделать точную на 100% оценку заказной разработки?
Если коротко — нет.
В процессе оценки нашей задачей является максимально точный прогноз сроков, ресурсов и стоимости будущего проекта. При этом даже максимально проработанная оценка вряд ли будет стопроцентно точной. Причина этого в важной переменной – самом клиенте и его проекте. Дело в том, что на практике заказчик часто корректирует задачу уже в процессе разработки, например, добавляет или удаляет новые фичи, решает поменять приоритеты, технологию и так далее. Эти изменения кардинально влияют на первоначальные прогнозы, так как в разработке новые требования могут оказаться значительно сложнее. Панацеей для таких случаев является работа по модели Time & Materials (T&M), которая позволяет работать по Agile-методологиям и лучше адаптироваться к изменениям. В отличие от фиксированного Fixed Price T&M позволяет избежать многих проблем, связанных с новыми пожеланиями и изменениями в требованиях, которые неизбежно возникают в процессе разработки. Именно этот формат работы в связке с проработанной первоначальной оценкой дают наилучший результат.
Оценка проекта — это эффективный инструмент... маркетинга
Итак, чем же для нас является оценка проектов? Первое, и самое очевидное, — это часть нашей работы, как IT-компании. Мы оцениваем проекты для участия в пре-сейлах, конкурсах, тендерах, чтобы в конечном счете обеспечить себя интересной работой.
Однако даже те оценки, которые не приводят к заключению контракта, тоже важны. Они позволяют продемонстрировать экспертизу, заявить о себе на рынке и могут привести к будущим заказам. Поэтому качественная, детализированная и проработанная оценка работает на вашу репутацию в любом случае. Даже если изначально заказчик выберет не вас — он может вернуться за «тушением пожара» или за решением других сложных задач.
Оценка проектов — не самая любимая задача для команд
Важно сказать о том, что оценка требует значительных усилий команды, но не всегда приносит ощутимый результат. Это приводит к разочарованию и демотивации команды, так как их труд часто остается незамеченным и непризнанным. Вот почему это происходит.
Недостаток информации
Оценка может выполняться в условиях неполных или нечетких требований, что вынуждает команду тратить много времени на исследование и погружение в различные бизнес-процессы клиента.
Оценка может выполняться в условиях неполных или нечетких требований, что вынуждает команду тратить много времени на исследование и погружение в различные бизнес-процессы клиента.
Сжатые сроки
Клиенты обычно хотят получить оценку быстро, буквально в течение недели. Это накладывает дополнительный стресс на команду.
Клиенты обычно хотят получить оценку быстро, буквально в течение недели. Это накладывает дополнительный стресс на команду.
Субъективность оценки
Оценка субъективна, и невозможно гарантировать, что два разных специалиста дадут одинаковую формализованную оценку одному и тому же проекту.
Оценка субъективна, и невозможно гарантировать, что два разных специалиста дадут одинаковую формализованную оценку одному и тому же проекту.
Работа «в стол»
Часть оценок может оставаться неиспользованной, что демотивирует команду. Когда усилия и время, вложенные в оценку, кажутся напрасными, это снижает мотивацию. Более того, если проект не был подписан, невозможно узнать, насколько точной была оценка.
Часть оценок может оставаться неиспользованной, что демотивирует команду. Когда усилия и время, вложенные в оценку, кажутся напрасными, это снижает мотивацию. Более того, если проект не был подписан, невозможно узнать, насколько точной была оценка.
Тем не менее, даже учитывая эти сложности, важно понимать, что хорошо проведенная оценка — это возможность заявить о себе, продемонстрировать экспертность компании и привлечь новых клиентов.
Что опыт оценки дает команде
Кроме того, что качественная оценка позволяет получить проект и заложить основу для будущего сотрудничества, это действенный инструмент для развития профессиональных навыков команды.
1. Навыки декомпозиции задач
Декомпозиция задач — важный навык, позволяющий разбивать крупные задачи на более мелкие, управляемые части. Этот навык крайне важен для лидов и специалистов уровня MIDDLE и выше.
Декомпозиция задач — важный навык, позволяющий разбивать крупные задачи на более мелкие, управляемые части. Этот навык крайне важен для лидов и специалистов уровня MIDDLE и выше.
2. Навыки проектирования систем
Для оценки проекта необходимо представлять, как будет выглядеть система в целом. Это включает в себя проектирование компонентов, сервисов, механизмов интеграции и хранилищ данных.
Для оценки проекта необходимо представлять, как будет выглядеть система в целом. Это включает в себя проектирование компонентов, сервисов, механизмов интеграции и хранилищ данных.
3. Оценка трудозатрат
Навык точной оценки времени и ресурсов, необходимых для выполнения задач, является важным для любого разработчика. Он помогает избегать недооценки или переоценки трудозатрат, что критично для успешного выполнения проектов в срок.
Навык точной оценки времени и ресурсов, необходимых для выполнения задач, является важным для любого разработчика. Он помогает избегать недооценки или переоценки трудозатрат, что критично для успешного выполнения проектов в срок.
4. Понимание бизнес-процессов
Оценка проектов дает возможность глубже понять бизнес-процессы, которые необходимо автоматизировать. Это позволяет разработчикам не просто выполнять задачи, но и понимать, как их работа влияет на бизнес в целом.
Оценка проектов дает возможность глубже понять бизнес-процессы, которые необходимо автоматизировать. Это позволяет разработчикам не просто выполнять задачи, но и понимать, как их работа влияет на бизнес в целом.
5. Расширение кругозора
Расширение кругозора — ключевой аспект профессионального роста. Участие в оценке проектов способствует этому через приобретение новых знаний в области проектирования систем и использования различных инструментов. Это делает разработчиков более гибкими и подготовленными к разнообразным задачам.
Расширение кругозора — ключевой аспект профессионального роста. Участие в оценке проектов способствует этому через приобретение новых знаний в области проектирования систем и использования различных инструментов. Это делает разработчиков более гибкими и подготовленными к разнообразным задачам.
Что может помочь в оценке проекта
Материалов про оценку проектов существует не так уж и много. Редко можно найти ready-to-go советы, которые позволят сразу сесть и качественно оценить проект. Тем не менее существуют описанные подходы к оценке, например, через декомпозицию задач или по методике PERT.
Декомпозиция задач
Этот метод предполагает разделение проекта на более мелкие, управляемые части, что упрощает оценку их временных и ресурсных затрат. Читайте больше о декомпозиции в нашем тексте про системный и бизнес-анализ.
Этот метод предполагает разделение проекта на более мелкие, управляемые части, что упрощает оценку их временных и ресурсных затрат. Читайте больше о декомпозиции в нашем тексте про системный и бизнес-анализ.
Методика PERT
Метод PERT (Program Evaluation and Review Technique) — еще один полезный инструмент для оценки проектов. PERT предназначен для реализации масштабных и сложных проектов. Метод подразумевает наличие неопределенности, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих.
Метод PERT (Program Evaluation and Review Technique) — еще один полезный инструмент для оценки проектов. PERT предназначен для реализации масштабных и сложных проектов. Метод подразумевает наличие неопределенности, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих.
PERT был разработан главным образом для упрощения планирования на бумаге и составления графиков больших и сложных проектов. Метод в особенности нацелен на анализ времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта.
Книга «Сколько стоит программный проект?»
Одним из ценных источников информации по оценке проектов является книга Стива Макконнелла «Сколько стоит программный проект?». Макконнелл, также известный по своей книге «Совершенный код», предоставляет статистику и факты, а также описания распространенных методов оценки, которые можно применять на практике. Несмотря на то что книга достаточно старая, она остается актуальной и полезной.
В своей книге Макконнелл вводит понятие конуса неопределенности (Cone of Uncertainty) в контексте оценки программных проектов. Этот принцип иллюстрирует, как неопределенность в оценках уменьшается по мере продвижения проекта. На начальных этапах диапазон оценок широк, но по мере получения дополнительной информации и уточнения требований этот диапазон сужается.
Макконнелл рекомендует использовать треугольное распределение для оценки, включающее три значения: оптимистичное (минимальное время), пессимистичное (максимальное время) и наиболее вероятное. Это помогает учитывать неопределенность и предоставляет более реалистичный диапазон выполнения задачи. Макконнелл подчеркивает, что игнорирование неопределенности может привести к чрезмерному оптимизму в оценках, что в свою очередь вызовет задержки и превышение бюджета.
Проработка технических заданий
Мы оцениваем десятки ТЗ в год и можем поделить их на два наиболее встречающихся типа.
1. Оценка после системного анализа
Эти оценки мы чаще проводим перед формированием коммерческих предложений, где требования к качеству оценки максимальные, а результат напрямую влияет на итоговый контракт.
ТЗ здесь содержат подробное описание задач, включая функциональность, юзкейсы, источники данных и даже наброски макетов графического интерфейса. Высокая степень детализации позволяет быстро и качественно выполнить оценку.
2. Экспресс-оценка без предпроектной аналитики
Эти оценки представляют собой предварительные расчеты, которые клиент запрашивает для грубой оценки стоимости проекта. Задача состоит в том, чтобы быстро определить порядок цены, не вдаваясь в подробности.
Здесь ТЗ содержат лишь обобщенные требования, например, «реализовать функционал» или «посчитать данные с помощью алгоритмов», без конкретных деталей. Отсутствие подробного описания, источников данных и их типов делает оценку трудной и неточной. А к этапу готового продукта такие оценки могут выглядеть уже и бессмысленными :)
Промежуточные варианты также часто встречаются. Это ТЗ с умеренной детализацией, с которым в целом тоже комфортно работать, если на встречу идут сами заказчики.
Как читать техническое задание, чтобы ничего не упустить?
Тщательная вычитка помогает избежать упущений и повысить точность оценки.
В моей личной практике этот процесс включает три этапа вычитки, каждый из которых имеет свои цели и задачи. Такой методичный подход помогает не упустить важные детали и значительно повышает качество оценки проекта, обеспечивая его успешную реализацию.
Первый этап — это ознакомление с ТЗ. На этом этапе формируется общее представление о проекте: понимание, что нужно автоматизировать, какие существуют основные функциональности и corner-кейсы. Этот шаг помогает увидеть общую картину и понять предмет оценки.
Второй этап — выделение функциональных требований. ТЗ читается заново, на этот раз с акцентом на конкретные фичи, которые нужно реализовать. Например, если в ТЗ указано, что система должна отказать в регистрации заказа пользователю из черного списка, то это выделяется в отдельную функциональную задачу. Таким образом, формируется первоначальный фич-лист.
Третий этап — детальная декомпозиция. Здесь каждая выделенная фича разбивается на подзадачи. Эта детальная работа позволяет уточнить, какие именно шаги и ресурсы потребуются для реализации каждой фичи. В процессе декомпозиции полезно формировать доменную модель проекта, выписывая все сущности, которые могут быть задействованы.
Проектирование схемы баз данных также является важной частью третьего этапа. Оно позволяет лучше понять взаимосвязи между сущностями и процессами, что существенно повышает точность оценки. Схемы компонентов помогают визуализировать структуру и взаимодействие систем, что также помогает в понимании и оценке проекта.
Процесс оценки проектов в CosySoft
Перейдем к процессу оценки проектов в CosySoft и рассмотрим, как он организован.
1. Валидация проектов
Отдел продаж занимается отбором проектов. Интересные запросы проходят через руководителя проектного офиса, который фильтрует их и принимает решение, можем ли мы брать проект в работу.
Отдел продаж занимается отбором проектов. Интересные запросы проходят через руководителя проектного офиса, который фильтрует их и принимает решение, можем ли мы брать проект в работу.
2. Запуск оценки
На этом этапе команда продаж публикует в специальном чате сообщение о новой оценке с указанием сроков и артефактов. Затем назначается ответственный проектный менеджер, который призывает руководителей направлений определить состав команды для оценки.
На этом этапе команда продаж публикует в специальном чате сообщение о новой оценке с указанием сроков и артефактов. Затем назначается ответственный проектный менеджер, который призывает руководителей направлений определить состав команды для оценки.
3. Формирование команды
После формирования команды проводится вводная встреча, на которой отдел продаж рассказывает о проекте, его требованиях и сроках. Аналитик, если успел ознакомиться с ТЗ, добавляет свои комментарии.
После формирования команды проводится вводная встреча, на которой отдел продаж рассказывает о проекте, его требованиях и сроках. Аналитик, если успел ознакомиться с ТЗ, добавляет свои комментарии.
4. Формирование фич-листа
Включает все фичи, подлежащие реализации. Обычно этим занимается аналитик, но иногда в задачу подключаются участники команды разработки. На этом этапе также готовятся вопросы к заказчику, чтобы уточнить детали. Тут мы ожидаем, что заказчик также активно вовлечен в процесс: участвует во встречах и оперативно отвечает на вопросы. Это существенно повышает точность цифр и в конечном итоге сближает ожидания с реальностью.
После формирования фич-листа команды оценивают трудозатраты и формируют необходимые артефакты.
Включает все фичи, подлежащие реализации. Обычно этим занимается аналитик, но иногда в задачу подключаются участники команды разработки. На этом этапе также готовятся вопросы к заказчику, чтобы уточнить детали. Тут мы ожидаем, что заказчик также активно вовлечен в процесс: участвует во встречах и оперативно отвечает на вопросы. Это существенно повышает точность цифр и в конечном итоге сближает ожидания с реальностью.
После формирования фич-листа команды оценивают трудозатраты и формируют необходимые артефакты.
5. Расчет трудозатрат и стоимости
На оценку накладываются риски, которые возможно предусмотреть. В итоге все данные передаются менеджеру, который формирует коммерческое предложение и отправляет его заказчику.
На оценку накладываются риски, которые возможно предусмотреть. В итоге все данные передаются менеджеру, который формирует коммерческое предложение и отправляет его заказчику.
Подготовка артефактов — ключевой этап оценки
После оценки технического задания наступает стадия подготовки артефактов — важнейший этап оценки проекта. Это не только помогает клиенту лучше понять предлагаемые решения, но и обеспечивает более точное и структурированное планирование работы. Чем больше внимания мы уделяем подготовке артефактов, тем выше качество и точность наших оценок.
Раньше мы предоставляли лишь один артефакт — декомпозицию задач с оценкой. Со временем перечень артефактов расширился, и теперь мы стараемся предоставить более полный набор документов, помогающий IT-службе клиента лучше понять и оценить предлагаемые решения.
Основные артефакты, которые мы готовим в рамках оценки.
1. Декомпозиция задач с оценкой трудозатрат.
Это ключевой документ, включающий разбивку задач по этапам. Здесь подробно описаны задачи и оценено необходимое время для их выполнения.
Это ключевой документ, включающий разбивку задач по этапам. Здесь подробно описаны задачи и оценено необходимое время для их выполнения.
2. Стек технологий.
Указываем, какие технологии и инструменты будем использовать для разработки системы. Это помогает клиенту понять на каких решениях будет базироваться проект и почему именно на них.
Указываем, какие технологии и инструменты будем использовать для разработки системы. Это помогает клиенту понять на каких решениях будет базироваться проект и почему именно на них.
3. Состав команды разработки.
В документе показываем своих специалистов с подробно описанным релевантным опытом, которые будут работать над проектом. Например, для бэкэнда может потребоваться один синьор и два мидла, для фронтэнда — два синьора, а также девопс, два QA, менеджер проекта и аналитик.
В документе показываем своих специалистов с подробно описанным релевантным опытом, которые будут работать над проектом. Например, для бэкэнда может потребоваться один синьор и два мидла, для фронтэнда — два синьора, а также девопс, два QA, менеджер проекта и аналитик.
4. Схемы архитектуры.
Включают высокоуровневое описание компонентов системы: сервисы, кэши, хранилища данных, слои интеграции и взаимосвязи между ними. Архитектурные схемы помогают визуализировать структуру и взаимодействие системы.
Включают высокоуровневое описание компонентов системы: сервисы, кэши, хранилища данных, слои интеграции и взаимосвязи между ними. Архитектурные схемы помогают визуализировать структуру и взаимодействие системы.
5. Пояснительная записка к архитектуре.
Этот документ содержит описание компонентов, их функции и способы взаимодействия. Он помогает клиенту лучше понять, как будет функционировать система.
Этот документ содержит описание компонентов, их функции и способы взаимодействия. Он помогает клиенту лучше понять, как будет функционировать система.
6. Сайзинг-решения (опционально).
При необходимости готовим документ, описывающий требования к оборудованию: объем памяти, место на жестком диске, процессорные мощности, а также планы по горизонтальному масштабированию.
При необходимости готовим документ, описывающий требования к оборудованию: объем памяти, место на жестком диске, процессорные мощности, а также планы по горизонтальному масштабированию.
Заключение
Точная и детализированная оценка позволяет нам не только рационально распределять ресурсы, но и формировать доверие со стороны клиентов, которые рассчитывают на своевременное и качественное выполнение задачи. На практике высокую точность нашей оценки обеспечивают тщательная вычитка технического задания, декомпозиция задач, взаимодействие с заказчиком и создание детализированной архитектуры проекта. Важной частью работы является также подготовка артефактов, которые помогают заказчику понять, что именно будет реализовано, каким образом и в какие сроки. А работа по модели T&M позволяет адаптироваться под реальные потребности, лучше прогнозировать сроки, расходы и финальный результат.
В конечном итоге тщательная оценка помогает команде работать более слаженно и качественно, а клиенту — получить ожидаемый продукт в установленный срок.
