Дедлайны близятся, а требований нет

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

Из этой статьи вы узнаете

1. Что делать, если исчерпывающего описания продукта и понимания что в итоге должно получиться нет, а сроки поджимают?
2. Как правильно относится к такой ситуации? (философский вопрос)
3. Что должен делать разработчик в такой ситуации?
4. Как победить, не смотря ни на что? 😊

Предисловие

Прежде чем начать, поговорим немного о вариациях идеального мира с точки зрения отдельно взятого разработчика, а именно меня.

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

Данный подход означает, что разработчик привлекается лишь на этапе разработки и иногда в процессе согласования требований, по причине того что нужна техническая экспертиза для решения какого либо вопроса. Консультации с разработчиком проводит аналитик, прямых контактов с заказчиком разработчик не имеет (да это собственно и не нужно). И как итог, в конце этого процесса у разработчика на руках оказывается аналитика (ТЗ, челобитная, называйте как нравится, суть меняется не сильно).

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

Разработчики, которые так считают, они правы? Бывают ли исключения? Давайте разбираться.

Глава 1. Ничто не предвещало беды

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

Это была задача. На первый взгляд, ни что не отличало её от других. Заголовок, описание, вложения, всё при ней и ничего лишнего.

К задаче были приложены ссылки на документации различных сервисов, с которыми предстояло интегрироваться, swagger файл с описанием API. Я бегло просмотрел их, просто чтобы ознакомиться, ведь я уже заметил его, файл с именем ТЗ.docx.

Вот он, тот самый файл! Именно там лежат ответы на все мои вопросы. И я бросился его читать.

Этот документ оказался весьма внушительным. Множество разделов, таблицы, описания, схемы процессов, чего ещё желать?

Прочитав ТЗ несколько раз, я понял, что оно написано прекрасно и имеет всего один недостаток. Оно написано не для нас...

Глава 2. С чем мы имеем дело?

Так с чем же мы столкнулись и как так вышло?

Перечислим, что мы по факту имели (во всяком случае то, что мы могли видеть с нашей точки обзора):

1. Требование разработать систему, обрабатывающую заявки, отправленные на Госуслугах и интегрировать её с информационной системой (ИС) заказчика
2. Безумно сжатые сроки (не горят, а полыхают 🔥🔥🔥).
3. Как минимум 4 команды разработки, каждая со своим проект-менеджером (3 команды с нашей стороны и команда со стороны заказчика. Это не все участники, но остановимся на этом).
4. Как минимум 3 организации задействованных именно в процессе разработки.

Как вы могли понять из вышесказанного, задача разрабатываемой системы, это транспорт заявки из Госуслуг, до ИС заказчика.

Путь заявки до ИС

Заявка проходит следующие этапы:

1. Форма на Госуслугах (заявитель заполняет форму и отправляет)
2. Заявка попадает в СМЭВ (Система Межведомственного Электронного Взаимодействия)
3. Из СМЭВ данные получает и обрабатывает Агредатор (сервис гарантирующий доставку данных из СМЭВ)
4. Обработанные данные получает интеграционый сервис, задача которого обеспечить интерфейс между Агредатором и ИС заказчика, а так же реализовывать небольшую бизнес-логику
5. Заявка попадает в информационную систему заказчика

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

В чём была задача моей команды и почему ТЗ не помогло?

Наша команда отвечала за разработку интеграционного приложения. Как предполагалось изначально, сервис должен был служить своего рода адаптером между двумя ИС.

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

Множество участников, времени на отладку взаимодействия и согласования ничтожно мало, сроки горят. Нужно что-то делать. Но что?

Глава 3. Разработчик не только разрабатывает и это нормально

Разработчик-детектив

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

Если ты "гребец" на "галере" и из ТЗ проекта не ясно что нужно делать, то ПМ пойдёт выяснять это у заказчика, а ты, разработчик, будешь пока занят чем-то другим.

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

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

Заказчику нужна помощь в решении задачи, а не свободные руки для написания кода.

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

Тут нам и понадобятся детективные способности.

Мы приступили к анализу системы и изучению предметной области.

Разработчик-переговорщик

Можно сказать, что документации описывающей что нам нужно сделать и как не было, поэтому единственный способ выяснить - это общаться со стороной заказчика.

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

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

В результате нам удалось сформировать первую версию требований к нашему сервису.

Разработчик-продавец

Проблема ясна, пора предлагать решение (продать своё видение решения).

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

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

Тот случай, когда немного бюрократии экономит кучу времени и нервов 😊.

Глава 4. Как нас спасли абстракции

Абстракции - это больная тема, наверное, для любого проекта. То их слишком мало, то их слишком много.

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

Создаю абстракции, потому что вынужден

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

После общения с разработчиками заказчика, мы выяснили что и как должен делать наш сервис, но это не всё. Кое-каких знаний нам ещё не хватало:

• не знали в каком виде придут данные заявки
• как обрабатывать вложения (к заявке крепятся файлы, не было ясно как они будут выглядеть)
• каким будет формат данных из формы (блок данных внутри заявки)

и т. д.

Нехватку знаний мы затыкали абстракциями.

Мы не знали что получим на входе, но знали что хотим на выходе, исходя из этого реализовывали интерфейсы классов, оставляя реализацию на потом.

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

Создаю абстракции потому что логично

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

В нашем случае, хорошим примером такой сущности, стли различные виды адресов. Они были разными только по смыслу, но имели одинаковую структуру в API клиента и описывались одной моделью в swagger.json. Можно было бы реализовать только эту модель и обходится ей, но я предпочёл выделить абстракцию для каждого из адресов.

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

Эпилог

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

Долгий путь проделали наши герои, но в конце их ждал успех.

Выводы

Нет требований а сроки поджимают? Начни их выяснять.

Не описано решение? Предлагай его сам.

Это нормально, ничего необычного, это твоя работа. Разработчик решает задачи, а не только пишет код по тебованиям.

Соберись, не раскисай, не жалуйся и тебя ждёт успех!