Привет, меня зовут Дмитрий Галатов. Я работаю старшим программистом в компании ЦВТ. Веб-разработкой занимаюсь 4 года.

Недавно с командой мы завершили проект для одного из уральских банков: разработали сервис для подачи онлайн-заявки на ипотеку. Изначально проект казался простым и понятным, но у заказчика постоянно возникали новые требования. В итоге работа значительно затянулась.

Я расскажу, как в таких случаях не подвести клиента и создать сервис, который будет решать задачи бизнеса. А также каким образом выстроить работу по проекту, чтобы не пришлось ничего переделывать.

Что хотел заказчик/ Задача заказчика и исходные данные проекта

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

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

• Онлайн-анкета с возможностью прикрепить документы. Клиент указывает сведения об образовании, имуществе, доходах и расходах. В общей сложности более 100 пунктов, которые содержат персональные данные. Далее к анкете прикрепляются скан-копии документов.

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

Проект пришел к нам в виде концепции и небольшого прототипа с несколькими полями анкеты. Казалось, что все понятно, поэтому мы сразу приступили к разработке. Рассчитывали закончить за 2 месяца, но не тут-то было. У заказчика постоянно возникали новые требования, так как с его стороны не было одного утвержденного ответственного лица. Департаменты банка перекидывали решение о согласовании друг на друга. Мы ждали ответа по несколько месяцев или не получали его вообще. Из-за этого процесс затягивался на неопределенный срок, но в итоге мы справились.

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

О чем стоит договориться с заказчиком до старта проекта

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

Итак, нужно выяснить:

• Есть ли необходимая для разработки документация. Запрашивайте сразу, если чего-то не хватает. Иначе придется писать все с нуля, а это точно займет много времени.

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

• Кто делает интеграцию. Важно понимать, что если этим займется ваша команда, время на разработку увеличится. Если интеграции будет делать банк, то в договоре нужно четко прописать SLA.

• Как будет согласовываться результат. Важно утвердить ответственное лицо со стороны заказчика. Это облегчит и ускорит процесс согласования.

Если не учесть эти пункты, работа над простым проектом изрядно потреплет нервы команде и в разы затянется.

Как наладить рабочий процесс с заказчиком

Обратите внимание на эти пункты сразу, как только к вам приходит задача.

Тип заказчика и перспектива развития проекта

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

Архитектура

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

Для больших структур и сложных проектов лучше выбрать событийную архитектуру и потоковую обработку информации — например, Kafka. Дополнительно можно создать универсальное удобное хранилище вроде Hadoop. Также, вероятно, стоит сразу использовать методику DDD или паттерны CQRS и Event Sourcing.

Логирование

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

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

Эти решения помогут вам скоординировать действия в самом начале проекта, снизить количество новых требований и в результате — работать спокойнее.

Резюме: как сберечь нервы себе и команде

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

Предугадывайте ход развития проекта и требований

С опытом станет легче это делать. Вы начнете анализировать заказчика и предполагать, какие инструменты ему могут понадобиться, какую логичнее выбрать архитектуру.

Договаривайтесь о потенциальных рисках на берегу

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

Задавайте вопросы сразу и уточняйте непонятные моменты

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

Будьте готовы к изменениям

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

Опирайтесь на команду

Они — ваша опора и поддержка. Вместе более реально разобраться с новыми требованиями и не выгореть. Поэтому важно выстроить доверительные отношения внутри команды.

Проведите ретроспективу после окончания проекта

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

Будьте готовы к сражению и не дайте сложностям уничтожить ваши нервы и проект!