Проверяем разработчика на профпригодность в XXI веке

Поговорили с Вячеславом Резниченко, техническим директором компании <Бета>, о том, что делать с прогнозируемой непрогнозируемостью и чем должен быть озабочен разработчик ПО до подписания контракта с клиентом.

Поговорим о непредсказуемости заказной разработки. Можно ли ее избежать?

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

Что может сделать команда разработки, чтобы всем было спокойно?

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

Есть другой вариант – формировать дорожную карту продукта итерациями. Тот самый agile, который прекрасно работает, если финальный результат пока не понятен. Быстро создать MVP (минимальную базовую версию продукта), протестировать ее на реальных пользователях, и наращивать разработку и функциональность на основе полученной обратной связи.

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

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

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

Если он задает вопросы, может сформулировать ТЗ и «дорожную карту» проекта до подписания договора – это третий положительный маркер.

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

То есть, начиная разработку продукта, стоит идти с конца? Как в таком случае быть с проектами, где итоговый продукт не сформулирован, и клиент идет итерационным путем?

Тут есть два нюанса. Во-первых, гибкие методологии разработки – не про отсутствие границ в принципе. Они про ситуации, когда и разработчик, и заказчик понимают, что на каком-то этапе это процесс не прогнозируем. И они оба с этим прогнозируемо согласны. Непрогнозируемость строго очерчена. Поэтому результат все же может быть сформулирован в том или ином виде.

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

Какие компетенции в итоге являются ключевыми для команды разработки?

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

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

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

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

#интервью #разработка #управление_проектами