ИТ-Стайер

Как создать и развивать свой продукт?

Если лучший автомобиль – это служебный с водителем, то лучшая система – это та, которую создал ты сам.

Это совершенно не означает, что все необходимо делать самостоятельно с самого-самого начала. Я говорю про здоровую долю кастомизации или доработки системы под нужды конкретной компании. Нужно понимать, что когда вам говорят, что компания “сидит” на том или ином продукте, например 1С или SAP, то это совсем не означает, что они используют одинаковый типовой функционал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь поговорим об управлении внедрением изменений в ИТ-системы.

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

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

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

– Ни одно тестирование не гарантирует, что на “боевых данных” все будет гладко.

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

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

– Никогда не нужно проводить обновления в пятницу или перед праздниками.

– Даже изменение цвета или местоположения кнопки – это обновление.

– О любых изменениях нужно оповещать пользователей.

– Большинство пользователей не читают “Что нового?”

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

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

– Обо всех странностях после обновления служба поддержки должна немедленно информировать владельца продукта.

Ну и чтобы текст не был таким сухим приведу два реальных случая, которые имели место во время моей работы в торговой сети Магнит.

Случай первый. Сеть уже насчитывала порядка 1500 магазинов. Каждый магазин имел свою независимую базу данных и система была построена так, что большинство обновлений требовало запуска ряда скриптов, который обеспечивала специальная программа “робот”. Эта программа была сама по себе достаточно уникальна для того времени, поскольку по сети этих “роботов” обеспечивалась передача данных между объектами и они же могли запускать автоматически достаточно большой набор сервисных процедур. Это было прогрессивно: запущенное по сети обновление автоматом устанавливалось практически на все объекты в течении пары дней (связь тогда была еще той), ну а там где возникали ошибки уже подключались люди. Такой подход позволял существенно экономить на обслуживании.

В один теплый пятничный вечер раздается телефонный звонок от руководителя службы технической поддержки и он докладывает, что у него шквал звонков из магазинов по поводу неработающих касс. Потом подсчитали, что за полчаса в поддержку поступило порядка 600 звонков. Кто знает, что для продуктового ритейла в магазинах у дома пятничный вечер – тот поймет.

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

Первое что сделали, это прервали обмен, чтобы те “роботы”, которые не успели получить обновление не повлияли на работу магазинов.

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

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

Случай неприятный, но очень поучительный. Из него было сделано очень много выводов и больше на моей памяти подобного не происходило.

Еще одна история связана с распределительными центрами. Мы как раз только начали заниматься разработкой собственной WMS-системы и много времени проводили на складе в Кропоткине.

Меня зовет руководитель РЦ и в панике говорит, что у них поменялась форма отборочного листа, отборщики отбирают неправильно и товар вместо штук неконтролируемо уходит блочками.

Штучной отборки в то время на РЦ было не много, но товар там был дорогой. И если у тебя вместо единицы уходит шесть при цене в 400 рублей – это точно не хорошо, особенно, если учесть, что на снабжении было магазинов под триста.

Начинаем разборки. Вопрос разработчику, который занимался печатью отборочных листов: “Что меняли?”. Сегодня ничего в листах не меняли. Но лист другой. В общем чудеса.