«Не обезвредишь вовремя ошибки в ТЗ — заказчик сольет бюджет»

Сооснователи web-студии «Ананас» из Екатеринбурга Евгений Гавриляк и Егор Таланцев в беседе с DK.RU рассказали, как правильно поставить ТЗ стороннему разработчику и избежать больших дополнительных затрат.

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

Е.Г.: Web или мобильное приложение (и вообще любая программа) пишутся на основе технического задания заказчика. Именно в этом документе скрывается большинство ошибок, которые срабатывают как мина замедленного действия — проявляются в процессе разработки или даже после его окончания и требуют дополнительного бюджета на устранение. Чем серьезнее ошибка, тем больше времени нужно на внесение изменений в проект, а работа программистов студии обычно оплачивается по часам. Отсюда увеличение срока разработки и лишние затраты. И хорошо еще, когда ошибки поддаются исправлению. Они могут быть настолько глобальными, что проект приходится переделывать с нуля и с новым бюджетом. В таком случае заказчик может вообще отказаться от приложения.

То есть ответственность за слив бюджета в этом случае полностью лежит на заказчике?

Е.Г.: Если у студии чисто формальный подход к работе, она действительно переложит ответственность на клиента. Ведь в чем суть формального подхода?

Разработчик просто берет техническое задание, как есть, и делает ровно то, что в нем указано. Он, конечно, доведет проект до конца (мы здесь не говорим о мошенниках), однако приложение может работать или выглядеть совсем не так, как представлял себе заказчик. На претензии студия ответит, что работа выполнена согласно техзаданию и возьмет плату сверху за доведение приложения до ума. Либо клиенту придется искать другого подрядчика, но все равно это будут дополнительные затраты.

У нас противоположный подход. Мы анализируем полученное ТЗ и отслеживаем большинство проблемных моментов, обращая на них внимание клиента. Обычно после этого, уже с нашей помощью, создается новый, рабочий вариант технического задания.

А как выглядит недостаточно проработанное ТЗ?

Е.Г.: Чаще всего это либо слишком общее, либо излишне подробное описание будущего приложения. И то, и другое одинаково плохо.

В первом случае задание не будет учитывать критически важные моменты, которые обязательно напомнят о себе впоследствии. Например, одному из наших заказчиков нужен был сервис онлайн-заказа большегрузного транспорта, аналогичный Uber или «Яндекс.Такси». В ТЗ компания описала, какой функционал должен быть для клиентов и для водителей, то есть основных пользователей приложения. Но ведь есть еще несколько групп пользователей: администраторы, специалисты технической поддержки и другой персонал, но о них заказчик просто не подумал.

Если бы мы этого не увидели и просто сделали работу по ТЗ, получился бы неработающий сервис, требующий глобального исправления.

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

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

Как правильно написать техзадание, если нужно сложное программное решение для автоматизации одного или нескольких внутренних бизнес-процессов в компании?

Е.Т.: Это ситуация, когда заказчику вообще не стоит самому готовить первичный вариант ТЗ. Конечно, он отлично разбирается в каждом своем бизнес-процессе, но как их оцифровать, не представляет.

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

Более того, у нас в штате есть специалист, который является одновременно разработчиком и бизнес-аналитиком. Он может приехать к клиенту, изучить процесс, требующий автоматизации, сформулировать задачи и правильно донести их до программистов.

Разработка приложения — длительный процесс. А если за это время у заказчика что-то изменится и он захочет поменять изначальную концепцию или задачи программы?

Е.Т.: Срок разработки сложного приложения может составлять год и даже более, а бизнес очень динамичен, особенно в сегменте b2c. Он развивается, какие-то процессы меняются, открываются новые ниши на рынке, трансформируются потребности аудитории. Этот момент заказчику нужно просто учитывать и, опять же, ограничиться разработкой самой простой версии приложения, а затем просто обеспечивать его развитие и поддержку, в том числе с помощью разработчика. В предыдущем интервью мы много рассказывали про созданный нами голосовой помощник TWIN, который наша студия сейчас поддерживает на аутсорсинге — улучшает, обучает, приспосабливает под разные задачи и специфику конкретного бизнеса.  

Может ли заказчик как-то отслеживать работу над приложением?

Е.Г.: Да. У нас есть практика предоставления клиенту промежуточных отчетов и постоянно обновляемых версий приложения. Это позволяет вовремя заметить, что разработка движется не в ту сторону, и скорректировать процесс до того, как мы потратим десятки оплачиваемых заказчиком нормо-часов на то, что делать было не нужно, или на исправление недостатков.

Если техническое задание было составлено правильно и процесс разработки контролировался заказчиком, то на выходе получается на 100% качественный продукт? 

Е.Т.: Конечно, учет всех вышеописанных ошибок позволяет получить достаточно качественное приложение без превышения бюджета на разработку. При условии, что внутри самой web-студии грамотно выстроены бизнес-процессы и все сделано в срок. Однако финальную версию продукта заказчик все равно должен тщательно проверить. Убедиться, что все элементы UI/UX– интерфейса работают, пользовательские сценарии нормально выполняются, приложение одинаково хорошо запускается на всех платформах и во всех браузерах, не тормозит и не зависает. 

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

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