Одно из приложений закона Мерфи гласит: «Если вас могут понять неправильно — вас обязательно поймут неправильно!» Это действует не только в межличностном общении, но и при разработке IT-продуктов. Клиент желал второй «Shazam», а ему выдали совершенно другое. Разработчик не понял хотелку Заказчика и потратил время зря.
Чтобы избежать подобного исхода, перед тем, как начать разработку программного обеспечения, мы синхронизируемся с Заказчиком — проводим предпроектную подготовку и готовим техническое задание на разработку программы.
Этап подготовки сравним с работой архитектора, который проектирует здание с нуля, разрабатывает генеральный план, считает расходы материалов. Прежде чем запустить процесс разработки, нужно четко понимать, что мы желаем получить в итоге, какое «здание» будет построено. А также сколько времени это займет и сколько денег нужно вложить.
Распространенная ситуация, когда Заказчик приходит к разработчику с конкретной проблемой или запросом, но у него пока нет понимания, как именно ее решить. Задача разработчика — изучить проблему и предложить решение с четким описанием, что и как будет выполнено, сколько времени и ресурсов на это понадобится.
Рассмотрим пример. Приходит запрос от клиента на автоматизацию работы фирмы по производству мебели. Сейчас новые заявки загружаются в Excel, менеджеры путаются в них или забывают перезвонить клиентам; составление стандартных документов (КП, договор, счет) занимает много времени. Нужно, чтобы эту заявку потом можно было передать в отдел производства, а по окончанию работ — отследить и проанализировать весь ее жизненный цикл.
Есть проблема и запрос на определенный функционал программы. Нужно оценить по срокам и стоимости. Пусть задача и ясна, она недостаточно конкретна. Чтобы понять масштаб и стоимость работ, нужно продумать количество и функционал страниц, взаимосвязь данных и расчетов. При этом важно учесть особенности сферы мебельного производства, а для этого погрузиться в бизнес-процессы и изучить опыт конкурентов.
Возможно, особенность в том, что специалисты в отделе производства практически не сидят перед компьютером, и передавать заявку нужно не в веб-приложении, а на мобильное устройство. Или цена на заявку зависит от десятка различных факторов, что порождает такое же количество возможных вариантов КП. Не исключено, что сложный функционал в CRM достаточно заменить напоминалками для менеджеров, заявками на почту отдела производства и одним отчетом для директора в конце месяца — и это решит поставленные задачи.
Предпроектная подготовка позволяет предусмотреть все нюансы задуманного продукта, сократить время разработки и сэкономить на ошибках. Нашей командой проводится объемная работа:
- Вместе с вами определяем цели и задачи, которые должно решать приложение;
- Маркетолог изучает конкурентов и особенности вашей сферы;
- Аналитик находит оптимальный вариант решения поставленной задачи;
- Адаптируем идею к программным требованиям, прорабатываем алгоритмы работы программы;
- Разрабатываем архитектуру проекта;
- Дизайнер продумывает внешний вид и готовит макеты;
- Выявляем слабые места и пути их решения.
По итогам подготовки вы получаете продуманное техническое задание на разработку программы, более точную оценку стоимости и сроков проекта, варианты разделения работы и оплат на этапы. Документ выступает гарантом, что конечный результат будет соответствовать ожиданиям.
Вы с ТЗ на руках:
- Понимаете, за что платите деньги, видите структуру будущего продукта и можете скорректировать ещё до начала разработки.
- Оцениваете компетентность подрядчика. То, как составлен документ, отражает понимание исполнителем сути задачи и его логику решения.
- Получаете тот самый продукт, ведь он сверяется с ТЗ. Если что-то не соответствует, исполнитель обязан исправить.
- Можете планировать бюджет на разработку, знаете, сколько времени понадобится.
- Экономите деньги за счет снижения вероятности ошибок.
- Можете просто поменять исполнителя, если в период предпроектной подготовки что-то не устроит в команде. А готовое ТЗ можно передать другим разработчикам – это позволит им быстрее включиться в работу.
Исполнитель с ТЗ на руках:
- Понимает, чего хотите вы. Он уже задал вам десятки вопросов, обсудил все возможные варианты реализации проекта и согласовал все по пунктам.
Нужно ли платить за ТЗ?
Хорошее ТЗ на разработку программы — результат комплексной работы всей команды и фундамент будущего продукта. Его составление занимает недели работы специалистов, которая должна оплачиваться. Стоимость предпроектной подготовки рассчитывается индивидуально и составляет до 10% прогнозируемой стоимости проекта.
Что, если не платить за ТЗ? Исполнители не смогут потратить достаточное количество рабочего времени на аналитику и документ будет сырым. Когда команда берется за разработку, в ее же интересах заложить прочный фундамент в основу своего продукта. Если хотите сэкономить на разработке, есть более гуманные способы. Например, можете почитать статью про экономию при разработке мобильного приложения.