ИТ-Стайер

Большой бизнес не может быть типовым и тут возникает потребность создания своего продукта. И появляются программисты, постановщики, консультанты, как свои, так и привлеченные извне. У ведущих торговых сетей РФ количество людей задействованных в изменениях ИТ-системы исчисляется сотнями. Эти сотни людей обрабатывают тысячи заявок и хотелок, которые достаточно хаотично сыпятся от подразделений – система получает уникальность.

Особый случай – это когда компания развивает свое совсем уникальное решение на базе полностью внутренней разработки, а не платформы, представленной на рынке каким-либо производителем. Характерным примером могут являться Ашан или Магнит. Такие системы иногда называют “самописными”.

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

Тема “промышленная система” против “собственной разработки” – это поле для еще одной “священной войны”. Оба подхода имеют свои преимущества и свои недостатки.

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

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

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

Итак, развивая ИТ-систему нужно озаботиться, как минимум, двумя вещами:

– наличием адекватного владельца продукта

– управлением внедрением изменений

Это именно то, что отличает серьезный системный подход от хаотичного шатания и является определяющим порог, за которым остается понятие “самописного”.

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

В последнее время термин “владелец продукта” или “product owner” приобрел определенную популярность. Это связано с тем, что гибкие методологии управления проектами на базе Agile предусматривают такую роль. Владелец продукта определяет и транслирует общее видение развития продукта, агрегирует функциональные требования, планирует порядок их реализации, формируя его ценность.

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

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

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

Хочется акцентировать, что владельцем продукта не стоит делать бизнес-подразделение. Практически не бывает такого, что какая-то система работает только в интересах одного направления. Это как ТСЖ. Система должна учитывать интересы всех жителей, а для этого нужно знать потребности каждого и искать компромиссы. Заказчик и владелец продукта – это разные роли и не стоит их смешивать.