Привет, меня зовут Дмитрий Галатов. Я работаю старшим программистом в компании ЦВТ. Веб-разработкой занимаюсь 4 года.
Недавно с командой мы завершили проект для одного из уральских банков: разработали сервис для подачи онлайн-заявки на ипотеку. Изначально проект казался простым и понятным, но у заказчика постоянно возникали новые требования. В итоге работа значительно затянулась.
Я расскажу, как в таких случаях не подвести клиента и создать сервис, который будет решать задачи бизнеса. А также каким образом выстроить работу по проекту, чтобы не пришлось ничего переделывать.
Что хотел заказчик/ Задача заказчика и исходные данные проекта
Банк обратился к нам с задачей: разработать сервис по оформлению онлайн-заявок на ипотеку. Он включает в себя следующие компоненты:
Посадочная страница с калькулятором ипотечной ставки. Будущий заемщик может самостоятельно посчитать процент по кредиту на сайте банка. При этом учитывается множество условий: сумма первоначального взноса, сроки, участие в зарплатном проекте.
Онлайн-анкета с возможностью прикрепить документы. Клиент указывает сведения об образовании, имуществе, доходах и расходах. В общей сложности более 100 пунктов, которые содержат персональные данные. Далее к анкете прикрепляются скан-копии документов.
Интерфейс для сотрудников банка. В нем работники проверяют корректность заполнения поступивших заявок. Если все верно, то клиента приглашают в офис для заключения договора. Если нужна корректировка, банк уведомляет, какие данные следует уточнить.
Проект пришел к нам в виде концепции и небольшого прототипа с несколькими полями анкеты. Казалось, что все понятно, поэтому мы сразу приступили к разработке. Рассчитывали закончить за 2 месяца, но не тут-то было. У заказчика постоянно возникали новые требования, так как с его стороны не было одного утвержденного ответственного лица. Департаменты банка перекидывали решение о согласовании друг на друга. Мы ждали ответа по несколько месяцев или не получали его вообще. Из-за этого процесс затягивался на неопределенный срок, но в итоге мы справились.
По окончании этого проекта мы с командой сделали выводы, как оптимизировать работу с подобным заказчиком-банком.
О чем стоит договориться с заказчиком до старта проекта
Перед стартом работы важно обговорить с заказчиком как можно больше деталей, чтобы все шло по плану и без сюрпризов.
Итак, нужно выяснить:
Есть ли необходимая для разработки документация. Запрашивайте сразу, если чего-то не хватает. Иначе придется писать все с нуля, а это точно займет много времени.
Кто и когда готовит ТЗ. Сначала утвердите ТЗ, а потом приступайте к разработке сервиса. Не стоит параллельно выполнять проектные задачи. Это не ускорит процесс разработки, а, скорее, наоборот. Например, при реализации проекта команда может понять, что не учла требования службы информационной безопасности к хранению персональных данных. В таком случае архитектору придется вернуться к началу работы.
Кто делает интеграцию. Важно понимать, что если этим займется ваша команда, время на разработку увеличится. Если интеграции будет делать банк, то в договоре нужно четко прописать SLA.
Как будет согласовываться результат. Важно утвердить ответственное лицо со стороны заказчика. Это облегчит и ускорит процесс согласования.
Если не учесть эти пункты, работа над простым проектом изрядно потреплет нервы команде и в разы затянется.
Как наладить рабочий процесс с заказчиком
Обратите внимание на эти пункты сразу, как только к вам приходит задача.
Тип заказчика и перспектива развития проекта
В каждой компании — своя внутренняя структура, длительность согласований и подход к поддержке. Можно сразу проанализировать заказчика, чтобы понять, насколько критичны для него дедлайны, какие фичи он может себе позволить. Возможно, с самого начала получится отговорить клиента от одного решения и предложить ему другое, более подходящее. У заказчика-банка, скорее всего, будет долгая система согласований с разными департаментами. Вероятно, понадобится сложная архитектура, и сам проект займет точно больше 2 месяцев.
Архитектура
Если все требования сразу понять не получается, попробуйте немного завысить ожидания. Например, предложите заказчику-банку вариант с более сложной и, соответственно, более дорогой архитектурой. Скорее всего, это решение сразу отправят на согласование к руководителю разработки, а это значит, что не придется долго ждать ответа.
Для больших структур и сложных проектов лучше выбрать событийную архитектуру и потоковую обработку информации — например, Kafka. Дополнительно можно создать универсальное удобное хранилище вроде Hadoop. Также, вероятно, стоит сразу использовать методику DDD или паттерны CQRS и Event Sourcing.
Логирование
Обдумайте и покажите заказчику изначальный список логов. Еще при оценке закладывайте больше логирования: предложите логировать техническую информацию и бизнес-процессы.
Например, в проекте есть ипотечная анкета. Можно предугадать, что при ее заполнении у заявки меняется статус, а клиенту приходит об этом оповещение. Все это можно предложить залогировать. Такое решение сразу отправят на согласование к архитектору, руководителям отдела безопасности или департамента разработки. В итоге у вас изначально будет утвержденный список логов, сократятся новые требования в дальнейшем.
Эти решения помогут вам скоординировать действия в самом начале проекта, снизить количество новых требований и в результате — работать спокойнее.
Резюме: как сберечь нервы себе и команде
Помимо технических моментов, считаю важными еще несколько пунктов. Вот несколько основных советов для работы с заказчиком-банком, чтобы не выгореть на проекте.
Предугадывайте ход развития проекта и требований
С опытом станет легче это делать. Вы начнете анализировать заказчика и предполагать, какие инструменты ему могут понадобиться, какую логичнее выбрать архитектуру.
Договаривайтесь о потенциальных рисках на берегу
Разработчику важно не только решить задачу клиента, но и показать ему последствия тех или иных решений. При этом нужно сохранить нервы своей команды. Для этого обговорите основные моменты с заказчиком до старта проекта.
Задавайте вопросы сразу и уточняйте непонятные моменты
Это сильно сэкономит время в дальнейшем. Если вы будете фиксировать вопросы в таблице, совсем не факт, что заказчик до них доберется. Проще будет задавать их на ежедневной синхронизации. Если не ответили — спрашивайте еще раз на следующей.
Будьте готовы к изменениям
При работе со сложным заказчиком этого не избежать. Просто потому, что согласование проходит с несколькими департаментами и разными ответственными лицами. Выше я рассказал, как можно облегчить этот процесс. Но, в любом случае, новые требования не должны выбивать вас из колеи. Просто примите, что они часть рабочего процесса.
Опирайтесь на команду
Они — ваша опора и поддержка. Вместе более реально разобраться с новыми требованиями и не выгореть. Поэтому важно выстроить доверительные отношения внутри команды.
Проведите ретроспективу после окончания проекта
Обсудите с командой ошибки, чтобы в будущих аналогичных ситуациях не повторять их.
Будьте готовы к сражению и не дайте сложностям уничтожить ваши нервы и проект!
