Главные мифы заказной разработки

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

Миф: Заказчики отдают подрядчику самые неинтересные для себя задачи

Юрий Чвыров

Руководитель службы архитектуры компании "Синимекс"

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

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

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

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

Бывает, что у заказчика свой стек, или он выбирает технологии сам, в таком случае у нас выбор несколько ограничен. Однако, многие клиенты используют современный техстек с точки зрения разработки, например, платформы оркестрации контейнеров Kubernetes или Openshift, брокеры на базе Apache Kafka, S3 хранилища и другие решения.

Поэтому интересных проектов хватает на всех — и на собственные команды, и на привлечение интеграторов.

Миф: Заказная разработка — это разработка строго по ТЗ заказчика, а проекты не имеют продолжения

Евгений Ковальцов

Руководитель центра сопровождения и поддержки компании "Синимекс"

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

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

Например, продукт вышел на рынок, но появилась потребность в новых фичах и функциях. Это проекты с продолжением. Разве можно сдать заказной продукт, который постоянно развивается?

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

В этом смысле итерационный подход дает возможность специалистам для саморазвития и проявления инициативы.

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

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

Миф: Тестировщики и разработчики — соперники

Александр Буйко

Руководитель отдела обеспечения качества компании "Синимекс"

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

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

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

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

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

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

Миф: Подрядчик не имеет права голоса

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

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

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

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