ИТ-Стайер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А за дверью триста мужиков, которые простаивают, а это хуже чем триста спартанцев. У тех хоть все понятно, а у этих горит заработок.

Поиски ничего не дают, все штатно. Ситуация накаляется.

В какой-то мере повезло, потому что в это же время в Кропоткине был руководитель РЦ из Энгельса. Поинтересовавшись в чем проблема и глянув на “новый” отборочный лист он сказал, что уже месяц по такому работает. На вопрос “как так? и как справился с проблемой?” он сказал, что ему админы передали, что вот такую новость прислали из Краснодара и теперь будет так. Он собрал народ, благо у него склад поменьше и народу тоже, проинструктировал по новому и все прошло гладко.

Оказалось, что “новый отборочный лист” был включен в тест, который проходил на РЦ Энгельс и поскольку никаких отзывов не последовало, то сопровождение посчитало, что все прошло отлично и включило его в плановую установку, которую робот и выполнил, когда смог. Когда причину нашли, то проблему устранили в несколько минут.

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

Минут через пятнадцать на вопрос “как обстановка?” руководитель отдела сопровождения отстучался в аську: “Все нормально. Заходил СН. С …. перешел на имена”.

И уж если вспомнился Сергей Николаевич Галицкий, то в контексте разговора о “владельцах продукта”, мне думается, успех Магнита связан именно с тем, что его собственник и руководитель отлично соответствовал этой роли применительно к торговой сети.

Глава 10
Как бороться с хроническим недостатком ресурсов

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

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

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

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

Казалось бы самый простой путь решения такой задачи – это набрать программистов. Если у бизнеса есть потребность и он “готов за это платить”, то почему бы и нет. Ну или не набрать, а привлечь на аутсорсинг. Давайте быстро наберем или привлечем и решим проблему за день-два.

К сожалению, в разработке так не работает. Это сложно воспринимается, поэтому я обычно привожу два примера. Нужно ли два человека, если требуется забить гвоздь? И если бетону для застывания требуется 28 дней, то как повлияет на это наличие 5 или 10 рабочих.

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

Однажды, работая в Магните, мы решали одну достаточно несложную задачку в интересах транспортников. Вопрос касался регистрации прибытия/убытия автомобилей на торговую точку. Времена были древние, GPS было еще не в моде и мы делали отметки с использованием электронного ключа. Эта система была отработана на супервайзерах магазинов, сотрудниках безопасности, но у транспортников возникла проблема, поскольку в отличии от остальных, водители иногда попадали в интервал, когда система магазина была на обслуживании и база данных была недоступна для записи информации. И вроде бы чего там делать: давайте запишем куда-нибудь, а потом проверим доступность базы и перенесем данные. Только вот специалисты знают, что если делать по уму, то почему-то вылезет куча деталей: записать нужно туда, где просто так не достанешь, где точно никто не подменит; нужно обеспечить, чтобы информация не потерялась и не задублировалась – короче есть тысяча мелочей, с которыми нужно просто повозиться.

Задачу взяли в работу вчера и срок в три недели я обозначил руководителю Департамента транспорта в 3 недели. Расчет прост: неделя на разработку, неделя на тестирование и неделя на гарантированную раскатку обновления по всем торговым точкам. В районе обеда раздался шум в коридоре и ко мне в возбужденном состоянии залетел Галицкий вместе с Директором по транспорту.

– Как три недели? Там же нечего делать!

– А вот так. Разработка, тестирование, раскатка..

– Да я на свободном рынке сейчас найду команду, которая это за 3 дня сделает!

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

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

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

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

Так сколько же программистов нужно держать? Это очень сложный вопрос. В моем понимании, ровно столько сколько вы сможете озадачить и еще немножко. А хороший ИТ-директор, поверьте может озадачить очень много.

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

По-моему опыту программисту для адаптации требуется от месяца до полугода.

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

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

Насколько я знаю, Магнит потом расширил практику взаимодействия с университетом. Я тоже потом, работая и в Донецке и Хабаровске, успешно сотрудничал с местными ВУЗами. Мы проводили совместные мероприятия и на мой взгляд это было взаимовыгодно.

Про аутсорсинг мы уже говорили в главе 7. В части наращивания ресурсов программистов, мой опыт говорит, что это далеко не лучший вариант.

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

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

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

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

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

Полезно когда кто-то перед тем как задача попадет непосредственно к программисту:

– рассортирует реальные доработки от инцидентов

– определит имеет ли место реальная ошибка в коде или проблема кроется в каких-то настройках или в данных

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

– проработает задание с пользователем и переведет его на язык более понятный программистам

– согласует приоритеты выполнения

Это все точно может сделать человек с менее дефицитной квалификацией, чем программист-разработчик.

Тестирование, написание инструкций – это из той же области. Единственное с тестированием нужно не перегибать. Программист обязан первичное тестирование проводить сам, иначе начинается никому не нужный футбол с тестировщиками.

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

Если говорить про доработки, то есть тоже одна хитрость, которая поможет сократить их количество. Не секрет, что работа “на корзину” может составлять от 30 до 70% от всего того, что делают программисты. За этим стоят не только потери связанные с оплатой оказавшегося бесполезным труда, но и очень серьезный демотивирующий фактор. Борьба с этим ведется по разному. Кто-то даже вводит штрафы за неиспользуемые отчеты и программные модули, но это ни к чему хорошему не приводит. Потратили бестолково время на программирование и продолжаем тратить время на бестолковое формирование, “чтобы меня не оштрафовали”. Гораздо более действенной является организация возможности попробовать с помощью Экселя. Оказалось, что наличие даже одного кудесника Экселя, который хорошо владеет всеми тонкостями его использования, включая макросы и VBA, позволяет существенно облегчить труд программистов и сделать счастливыми многих пользователей.

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

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

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

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

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