Главные мифы заказной разработки
Мифы сопровождали человека с древних времен и продолжают существовать сейчас – уже в мире высоких технологий. Специально для издания Tproger мы поговорили с руководителями дирекции производства компании «Синимекс» и узнали, какие мифы они встречали в сфере заказной разработки, почему такие стереотипы появляются, и главное – что на самом деле представляет из себя работа в компании-интеграторе.
МИФ: Заказчики отдают подрядчику самые неинтересные для себя задачи
Юрий Чвыров, руководитель службы архитектуры компании «Синимекс»
Появление мифа связано с развитием инсорсинга, то есть появлением у заказчика собственных команд разработки. Для мотивации собственного штата интересные задачи заказчик может оставить себе. С другой стороны, у крупных клиентов проектов и задач намного больше, чем собственных специалистов. Есть примеры, когда компании изначально ориентируются на ИТ-интеграторов, а в собственные команды набирают преимущественно менеджеров. Есть задачи, которые полностью отдают подрядчикам, и в нашем портфеле есть такие проекты по реализации бизнес-процессов предприятия под ключ.
Что касается интересных и современных технологий, то иногда заказчик предоставляет их выбор интегратору. В таком случае все в наших руках, и мы стараемся использовать самые новые подходы, технологии, фреймворки, продукты. Одна из наших задач – понимать наличие компетенций у заказчика и подбирать такие решения, которые он сможет поддерживать и развивать. В работе мы стараемся искать золотую середину – новые технологии и наличие компетенций у заказчика.
Бывает, что у заказчика свой стек, или он выбирает технологии сам, в таком случае у нас выбор несколько ограничен. Однако, многие наши клиенты используют современный техстек с точки зрения разработки, например платформы оркестрации контейнеров Kubernetes или Openshift, брокеры на базе Apache Kafka, S3 хранилища и другие решения.
Поэтому интересных проектов хватает на всех – и на собственные команды, и на привлечение интеграторов.
МИФ: Заказная разработка – это разработка строго по ТЗ заказчика, а проекты не имеют продолжения
Евгений Ковальцов, руководитель центра сопровождения и поддержки компании «Синимекс»
За последнее десятилетие заказная разработка трансформировалась в заказную продуктовую разработку с использованием соответствующих принципов и подходов, например методологии DevOps. Преимущество заказной продуктовой разработки в том, что заказчику не нужно держать продуктовую команду и брать на себя управление и экспертизу – это берет на себя интегратор.
В старом виде заказная разработка не работает, и мы перешли на итерационный подход ведения проектов. Такой подход построен не на конкретном ТЗ заказчика, а на видении, которое может меняться в зависимости от конъюнктуры рынка. Например, мы достигли результата, но появилась потребность в новых фичах и функциях. Это проекты с продолжением. Разве можно сдать заказной продукт, который постоянно развивается?
Также если в процессе эксплуатации появились проблемы, то участник команды может инициировать автоматизацию исправления или предложить решение, которое позволит избежать выявленных проблем. Каждый может внести свою инновацию. В этом смысле итерационный подход дает возможность специалистам для саморазвития и проявления инициативы.
Юрий Чвыров, руководитель службы архитектуры компании «Синимекс»
Существует мнение, что заказная разработка, в отличие от продуктовой, не имеет продолжения, а команда не знает, как ведет себя продукт в промышленной эксплуатации. Давайте посмотрим на другие сценарии, когда после реализации жизнь продукта не заканчивается, и дальше происходит его поддержка. Иногда заказчик поддерживает решение собственными силами, но чаще поддержкой продолжает заниматься подрядчик. Когда мы реализовали решение, мы даем на него гарантию. Если что-то случилось – подключаются наши сотрудники. Мне, как специалисту, всегда интересно знать, как наше решение ведет себя в промышленной эксплуатации – в бою. Это полезный опыт.
МИФ: Тестировщики и разработчики – соперники
Александр Буйко, руководитель отдела обеспечения качества компании «Синимекс»
Стереотип, что тестировщики и разработчики – соперники, популярен прежде всего в ИТ-сообществах в интернете, где можно найти различные мемы на эту тему. В реальной жизни ситуация другая.
Многие слышали об эффекте Даннинга-Крюгера и о кривой уверенности в своих силах. Гипотеза гласит, что менее компетентные люди в целом имеют более высокое мнение о собственных способностях, чем это свойственно людям компетентным. Такой эффект можно встретить в ИТ-сфере. Младшие специалисты могут считать свой код идеальным, а тестировщики могут разрушить их представление о проделанной работе. Специалисты уровня middle, наоборот, пишут хороший код, но считают, что там есть изъян. В этой ситуации тестировщики подтверждают отсутствие дефектов и укрепляют самооценку разработчика.
Когда я пришел в компанию «Синимекс» младшим специалистом по тестированию, я ошибочно думал, что если нашел дефект, то надо обвинять разработчика в написании некачественного кода. Но мне быстро объяснили, что в компании мы придерживаемся Agile-манифеста. В манифесте есть пункт – ответственность за услугу или продукт несет вся команда. Разработчики и тестировщики должны максимально конкретно рассказывать, где и какие слабые места у продукта, кода, софта. Взаимовыручка команды особо чувствуется на крупных проектах, где работают большие команды разработки, тестирования и аналитики, а руководители проектов транслируют ценности Agile. С таким подходом качество становится ответственностью всей команды проекта, а тестировщики и разработчики – союзники, и уж точно не соперники.
МИФ: Подрядчик не имеет права голоса
Юрий Чвыров, руководитель службы архитектуры компании «Синимекс»
Считается, что заказчик – это владелец задач, он должен принимать решения, а подрядная организация может только выполнять работы. На практике – у меня другой опыт. На некоторых проектах заказчик просит команду подрядчика подключаться как можно больше к решению глобальных и стратегических задач, высказывать свое профессиональное мнение. Конечно, все решения необходимо согласовывать в банке. Но это не отличается от процессов, когда архитектор из внутренней команды банка предлагает решение – все те же согласования.
Если смотреть на задачи интегратора классически, то кажется, что мы реализуем только бизнес-приложения. Но у нас есть и активности по платформенным сервисам, наши сотрудники писали правила разработки для заказчика. Мы писали концепт, согласовывали его с коллегами в банке. Это уже уровень Enterprise-архитектуры, когда наши сотрудники вместе с корпоративными архитекторами разрабатывают глобальную стратегию. В целом, работа в компании интеграторе дает сотруднику возможность быть услышанным, попробовать себя как архитектор бизнес-приложений, так и в роли enterprise-архитектора.