Выбор разработчика корпоративного ПО: какие факторы наиболее важны

Сотрудничество через центр компетенции

Сегодня стандартной организационной практикой, обеспечивающей движение корпоративного заказчика в сторону цифровизации, является формирование центров компетенции

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

• Происходит очередная смена парадигмы в построении ИТ-архитектуры и организации взаимосвязи ее компонентов. Решения, в которые активно инвестировали 10 – 15 лет назад, сегодня морально устарели и требуют замены.
• Идет тотальная цифровизация бизнеса, диктующая необходимость оперативно создавать адекватные новым бизнес-задачам качественные ИТ-системы.
• На отечественном рынке дополнительным катализатором процесса особенно для предприятий с госучастием являются законодательные инициативы и программа «Цифровая экономика России».

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

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

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

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

Если брать крупнейшие организации российской экономики из разных отраслей, то для них затраты на построение центров компетенции на базе исключительно собственных ресурсов вполне могут и окупиться, но таких организаций не так много. Для остальных компаний это совсем непростая задача. Построение полного производственного цикла по разработке ПО внутри – это процесс не на один год, требующий привлечения существенных ресурсов как экономических, так и людских. На мной взгляд, ИТ-руководителям таких компаний правильнее организовать стык команды профессионального подрядчика, занимающегося разработкой ПО, со своим бизнесом. Контролировать постановку и реализацию задач на уровне превращения бизнес-идеи в ИТ-архитектуру, держать руку на пульсе продакт-менеджемента, проектирования решения и хода разработки, - считает Евгений Минеев, исполнительный директор компании «Рексофт».

Структура предложения на рынке разработки

При существовании большого количества потенциально возможных схем сотрудничества «заказчик – разработчик ПО» можно выделить две принципиально отличающиеся друг от друга.

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

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

Мы строим свою работу таким образом, что готовы предложить клиенту функции верхнего уровня, среди которых, например, технологическая поддержка продакт-менеджмент заказчика, а если нужно, то и помощь в создании этой функции с обучением сотрудников заказчика. Многим из своих клиентов мы помогаем совместно продумать идею бизнес-изменений и затем ее реализовать. Заказчик формулирует задачу, а мы предлагаем возможные, а главное отработанные технологические и процессные варианты реализации, так как «Рексофт» много лет погружен в технологию разработки новых ИТ-решений для разных индустрий. Такой опыт позволяет заранее оценить варианты оптимальных действий в конкретной ситуации. Это может оказаться не только разработка, но и приобретение какой-то части функционала решения в виде готового продукта и последующая его интеграция. Например, без профессионального подрядчика многим компаниям трудно сориентироваться, как правильно «раскатывать» высоконагруженное приложение на клиентов, понять, как управлять релизами, как приоретезировать задачи, что брать в релиз, а что нет, какие нужны артефакты и т.д., - поясняет Евгений Минеев

Критерии оценки

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

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

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

При выборе партнера я рекомендую обращать внимание на уже имеющийся у многих опыт запуска новых цифровых продуктов в интересах заказчика. Очень хорошо, если этот запуск осуществлялся с нуля. Цифровой проект имеет типовые сложности, которые надо уметь обходить. Размер компании-партнера также имеет значение, но прежде всего потому, что ряд подрядчиков работают строго в определенной нише и не ориентированы на решение широкого круга задач. Ну и культурное соприкосновение коллективов, степень комфортности работы друг с другом сейчас тоже выходит на первый план. Это в большей части становится понятно еще на этапе постановки задачи - отмечает Евгений Минеев.

Экспертиза в отраслевых вопросах

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

Мы проходили этот путь и точно знаем, что сотрудник ИТ-компании никогда не будет разбираться в бизнесе заказчика лучше, чем его сотрудники. А если отраслевой эксперт появляется внутри подрядчика, то его навыки быстро теряют качество, так как он оторван от текущей ситуации, да и каждая компания даже в одном сегменте уникальна. «Рексофт» много лет работает с заказчиками из очень разных индустрий и понимает, как быстро нарастить нашу экспертизу до того уровня, чтобы разговаривать с заказчиком на его языке и вести полноценный диалог в его бизнес-терминах и реалиях. Мы, например, формируем чек-листы, опросники, проводим и модерируем совместные с бизнес-заказчиками клиента мероприятия. В результате бизнес-видение с нашей стороны по мере продвижения проекта быстро «доращивается» до нужного уровня. Численные показатели успешности выполнения проекта (в том числе промежуточные) в виде небезызвестных SLA тоже в большей мере формируются в бизнес-терминах. Скажем, речь идет не о надежности работы инфраструктуры на уровне 99.99, а о гарантированном исполнении заказа или иной бизнес-транзакции, - считает Евгений Минеев.

Зарубежный опыт как критерий

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

• Зарубежный рынок часто весьма конкурентен, и компания, работающая на международных заказчиков, как минимум должна соответствовать всем стандартам разработки и умело определять нишу для собственной деятельности.
• Заказчики на таких рынках часто методически более подкованы, чем российские и лучше понимают нюансы ИТ-решений, которые хотят внедрять. Это дисциплинирует и команду разработчика.
• Данный рынок всегда предлагает новейшие ИТ-разработки, многие из которых в отечественном ИТ-ланшафте считаются перспективными, но практического распространения пока не получили. В условиях цифровой трансформации такие «зазоры» могут быть особенно полезны российским заказчикам.

Имея опыт работы на зарубежном рынке компания как минимум способна опираться на современные процессы производства программного обеспечения и быть в курсе новейших разработок в сфере ИТ. Но не смотря на наличие у «Рексофт» такого опыта, я бы не определял бы этот фактор как решающий для клиента. Скорее готов утверждать, что наличие в нашем арсенале помимо зарубежных проектов, наработанной практики в разных отечественных отраслях, опыта взаимодействия с государственными заказчиками и профессиональными ассоциациями, действительно формирует очень важный для практических внедрений симбиоз, - полагает исполнительный директор «Рексофт».

Параметр Time-to-Market и его значение

Сегодня в среде массового появления новых бизнес-сервисов (и ИТ-сервисов в том числе) показатель, связанный с возможностью оперативно выводить их на рынок новые продукты и услуги (Time-to-Market), становится все более востребованным. Естественно, его пытаются применять и при оценке решений и подходов, предлагаемых разработчиками. Здесь полезно отметить некоторые нюансы.

• Погоня за показателями Time-to-Market и абсолютизация этого параметра объективно связаны с рисками потери качества продукта, и даже некоренного выбора ИТ-стека разработки.
• Говоря о Time-to-Market, часто приводят в пример взрывной рост новых компаний или стартапов, по сути полностью базирующихся на ИТ-сервисах. Но потенциально достижимые темпы роста и повышение конкурентоспособности большинства взрослых бизнесов куда чаще связаны с формированием тех или иных активов, к сфере ИТ вовсе не относящихся. Чтобы сформировать услугу чаще всего надо подготовить инфраструктуру и бизнес-процесс, и только потом обрамить его в ИТ-приложение. Без подготовленной бизнес-базы делать излишнюю ставку на Time-to-Market выпуска ИТ-решения, не всегда целесообразно. Конечно, можно оперативно запустить интернет-доставку на сайте, но если у компании нет договоренности с логистическими компаниями, и еще не построен процесс сборки заказов, то быстрый запуск ИТ-части процесса ничего кроме репутационных рисков не даст.
• Time-to-Market в отрыве от иных бизнес-показателей предполагает скорее кратковременное сотрудничество с внешними партнерами и не стимулирует к долговременному партнерству. А в ряде ситуаций это необходимо.

Интерес к показателю Time-to-Market и связывание этого показателя с новыми динамичными подходами к ИТ-поддержке резко оживился в связи с тем, что существующие ИТ-системы и принципы их создания перестали удовлетворять заказчика как по уровню, так и по темпу кастомизации. С другой стороны абсолютизация важности Time-to-Market может вести к снижению качества, надежности, а, возможно, и других параметров решения. Не надо путать две разные истории, когда стартап пытается проверить свою бизнес-модель, имея лишь некий прототип ИТ-решения, и когда изменения идут в крупной организации с серьезной клиентской базой. Ни банк, ни телеком-оператор, ни большинство других компаний не могут позволить себе ошибки уже в первой версии нового решения или сервиса, даже если уверены, что во второй все будет исправлено. И тут крайне важна роль внешнего партнера по разработке. Он должен знать все типовые ошибки подобных проектов. Знать, как наиболее оперативно и без потери качества поэтапно развивать решение, плавно и безболезненно осуществляя цифровую трансформацию, - говорит Евгений Минеев

Сотрудничество разработчика и консультанта

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

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

Мы часто работаем со стратегиями, написанными представителями консалтинговых компаний, в некоторых проектах работаем с консультантами в связке или берем на себя их задачи. Этот опыт позволяет нам говорить о повышении роли технологического консалтинга, в котором силен «Рексофт». Мы часто работаем в проектах связующим звеном, когда можем рекомендации бизнес-консультантов, описанные в стратегиях, приземлить на ИТ-ландшафт, бизнес-процессы и существующие технологии заказчика, - считает Евгений Минеев.

Сохранить лучшее из накопленного

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

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

Agile – это модно и удобно. Клиент может корректировать бизнес-требования по ходу проекта. Но для любого бизнеса важно качество, сроки и бюджеты. Эти параметры не всегда коррелируют. Agile подход парой уводит от них, так как всегда есть возможность что-то поменять, улучшить, что затягивает проект и приводит к росту бюджета. Прежде, чем слепо работать в методологии Agile, стоит совместно с ИТ-подрядчиком взвесить сроки и ресурсы, и выбрать верное сочетание методологии разработки и KPI. ИТ-партнер, сделавший большое число проектов от крупных федеральных систем до интернет-магазинов, скорее сориентирует по целесообразности того или иного выбора и объяснит возможные риски. Мы за взвешенный выбор и дискуссию в подходах, - резюмирует Евгений Минеев.