Поговорили с Вячеславом Резниченко, техническим директором, о том, что делать с прогнозируемой непрогнозируемостью и чем должен быть озабочен разработчик ПО до подписания контракта с клиентом.
Поговорим о непредсказуемости заказной разработки. Можно ли ее избежать?
Непредсказуемость связывают с мнимым отсутствием ограничений при разработке с нуля. Для разработчика это, с одной стороны, плюс – можно реализовать самые смелые мечты –, с другой стороны, риск – риск уйти не туда или поддаться соблазну создать продукт на все случаи жизни. Соблазн заразен, и финансовая свобода заказчика в этом случае – негативный фактор. Поэтому обеспечение предсказуемости разработки – это не только головная боль заказчика, но и первичная организационная задача команды разработки.
Что может сделать команда разработки, чтобы всем было спокойно?
Иметь теоретические и практические рамки в голове и уметь переложить их на процесс разработки. Это позволяет вовремя останавливаться и удерживать изначальные цели, которые стоят перед итоговым продуктом.
Есть другой вариант – формировать дорожную карту продукта итерациями. Тот самый agile, который прекрасно работает, если финальный результат пока не понятен. Быстро создать MVP (минимальную базовую версию продукта), протестировать ее на реальных пользователях, и наращивать разработку и функциональность на основе полученной обратной связи.
Как проверить, есть ли у разработчика эти самые рамки до того, как подпишешь контракт?
Я, как технический директор, могу оценить это со стороны разработки. Нужно общаться. Если разработчик – а с ними нужно обязательно общаться на этапе выбора – может понятно объяснить, как он будет решать поставленные задачи, какие варианты есть, то это положительный маркер.
Если он владеет широким стеком технологий, которые можно использовать, и может обосновать выбор тех или иных технологий, то это второй положительный маркер.
Если он задает вопросы, может сформулировать ТЗ и «дорожную карту» проекта до подписания договора – это третий положительный маркер.
Если он озаботился интеграцией решения на старте, это четвертый маркер. Потому что сама разработка — только часть работы (не всегда бОльшая). Основная задача – состыковать получившееся решение с имеющейся у заказчика инфраструктурой. А зачастую, не только с подсистемами заказчика. И вот здесь заказная разработка однозначно выгоднее во всех смыслах. Понимая, что и с чем предстоит интегрировать, это закладывается в продукт на старте. Тогда как используя готовое решение, приходится изощряться, так как возможности коробочного продукта ограничены. В таких случаях интеграционная часть работ выходит легче и дешевле, чем при кастомизации.
То есть, начиная разработку продукта, стоит идти с конца? Как в таком случае быть с проектами, где итоговый продукт не сформулирован, и клиент идет итерационным путем?
Тут есть два нюанса. Во-первых, гибкие методологии разработки – не про отсутствие границ в принципе. Они про ситуации, когда и разработчик, и заказчик понимают, что на каком-то этапе это процесс не прогнозируем. И они оба с этим прогнозируемо согласны. Непрогнозируемость строго очерчена. Поэтому результат все же может быть сформулирован в том или ином виде.
Во-вторых, в случае разработки MVP определяющим фактором становится скорость разработки. Поэтому требования к интеграции просто тоже формируются итерационно.
Какие компетенции в итоге являются ключевыми для команды разработки?
Безусловно, от профильных IT-компетенций разработчиков зависит качество и скорость создания требуемого решения, качество кода, возможности интеграции и масштабирования итогового продукта. С другой стороны, разработка – это длительный процесс, и его организация, по нашему опыту, важна ничуть не меньше.
Приведу пример. У нас был проект по автоматизации управления платными автомобильными трассами. Мы, как разработчики программной части, должны были обеспечить управление дорожными устройствами – светофорами, шлагбаумами и др. – с помощью нашего ПО. Но на момент финального этапа разработки строительство самой дороги было не закончено, и дорожных устройств у заказчика, а значит, и у нас, не оказалось. Было два пути. Ждать окончания строительства, и тогда ввод трассы в эксплуатацию был бы сдвинут в том числе потому, что заказчику после получения оборудования нужно было бы ждать, когда мы интегрируем свой софт с устройствами. Или же решить вопрос оперативно.
Мы пошли по второму пути. Договорились с поставщиком дорожного оборудования, и он предоставил нам программное обеспечение, которое установлено на этом оборудовании. Без самих устройств. И под этот реальный действующий софт, его протоколы, форматы данных и интерфейсы, мы написали сервис и создали эмуляторы, которые впоследствии успешно состыковали.
Вот такой пример организационного решения, которое сократило время разработки и ускорило заказчику ввод трассы в эксплуатацию.