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

Илья, расскажите, пожалуйста, как вы пришли на место директора по ИТ в вашу компанию.

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

Далее была английская компания, где из тим-лидера команды автоматизации вырос до руководителя отдела веб-разработок. Следующий шаг развития - это директор информационных технологий в крупной сети платёжных терминалов в Петербурге и Ленинградской области.

Какие первоочередные задачи сейчас стоят перед вашим ИТ-департаментом?

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

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

От кого в вашей компании исходят инициативы по введению различных инноваций? Какова роль ИТ-директора в их воплощении в жизнь?

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

Наши внутренние и внешние заказчики часто не понимают, как им лучше оптимизировать работу. Многие работают в 1С и мыслят категориями этого программного средства. Многие работают в своих АРМ и могут предложить какие-либо улучшения только в рамках текущего функционала или своего опыта на предыдущих местах работ, а на уровне всех информационных систем и информационных потоков - не могут. Если понимать это, то становится ясно: мнение, что заказчик должен предоставлять ТЗ на доработку и изменения ПО, особенно это касается внутренних заказчиков, ошибочно. Часто им нужна хорошая и работающая вещь, которая сделана правильно и под них. Проблема заключается в том, что описать эту вещь в соответствующих терминах они не могут.

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

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

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

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

Каковы на ваш взгляд наиболее острые (трудные) моменты в работе ИТ-директора?

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

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

Помогает ли участие в профессиональных сообществах в решении каких-то рабочих вопросов?

 - Знания - залог успеха любого руководителя, особенно, если он может их применить на практике. А практика, особенно операционная, зачастую отнимает внушительное количество времени. Это приводит к тому, что много полезной информации приходится раскапывать у знакомых в профессиональных сообществах. Всё как в Datamining: если у самого нет времени на добычу информации, то на помощь приходит интеллектуальный анализ экспертов, в качестве которых выступают коллеги, например, по SPb CIO Club. Зачем наступать на грабли, на которые уже наступил твой боевой товарищ. Если сам начинаешь что-то делать, не исследовав вопрос, то часто возникает ситуация, когда в рамках архитектуры какой-то блок системы оказывается ограниченным со всех сторон, и его развитие и расширение становятся неоправданно тяжёлыми.

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

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

Как организован (структурирован) ваш ИТ-отдел?

 - В моем отделе несколько команд – backend- и frontend-программисты, тест-инженеры, аналитики, поддержка. Взаимодействие происходит на уровне поставленных процессов и регламентов.

Если говорить о командах разработки и тест-инженеров, то здесь всё просто. Вся работа структурирована по принципам Agile-методологи разработки и проектного управления, ориентирована на динамически изменяющиеся требования и самоорганизующиеся команды проектов. Мы используем XP, Scrum, Kanban, Lean.

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

Какие ИТ-проекты вы сейчас реализуете? Что в них наиболее интересно? Какие перспективы?

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

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

Как эффективная организация ИТ повышает эффективность работы вашей компании?

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

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

Вы сторонник применения методологии Agile в разработке ПО. Что сейчас интересного происходит в этой области? Каким вы видите будущее этой методологии разработки?

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

Сами гибкие методологии довольно быстро развиваются. В своей работе я использую и Scrum, и Kanban, и XP, и Lean. По сути, это конструктор, который можно сложить удобным для себя образом. А цель одна - качественно управлять проектами, разработкой и получать уверенность в том, что гибкие методологии могут пересекаться и складываться в качественный продукт.

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

На самом деле в этом направлении ничего нового нет. Всё сводится к классической схеме непрерывного совершенствования на базе постоянного применения цикла Шухарта - Деминга: планируй - делай - проверяй - внедряй. Scrum – это разработка короткими итерациями, в которых присутствуют эти четыре шага: планирование, разработка, тестирование и внедрение. Всё по Демингу, но при этом циклы коротки, и это обеспечивает практически непрерывное улучшение не только продукта, но и процесса разработки. По процессу разработки цикл Деминга состоит из шагов: измеряй - анализируй – улучшай – управляй. Результатом выступает управляемое и контролируемое изменение процесса.

Что касается разрабатываемого продукта, то и здесь ничего нового нет, всё когда-то кто-то изобрёл. Другое дело, что в направлении разработки ПО это не имеет повсеместного использования. Взять, например, концепцию бережливого производства Lean, которая перетекает в концепцию бережливой разработки ПО - Lean Software development. Цель подхода - уменьшить количество лишних действий, которые не привносят добавленной ценности продукту, клиенту или уменьшают её. Концепция пришла из Японской философии Кайдзен, рассчитана на производство без потерь. Основная задача подхода – это устранять потери, возникающие во время разработки. Например, излишнюю функциональность, лишние шаги в разработке, пропуск багов при тестировании, задержки из-за ожидания каких-либо решений, ожидания ответов от клиентов, потери при развёртывании системы и т.д.

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

На текущий момент наиболее острой проблемой является непрерывная поставка продукта. В рамках быстрых итераций или при применении методологии Kanban встаёт проблема гибкой интеграции разработчиков ПО и админов, тех, кто эксплуатирует ПО. Для решения этой задачи появилась новая методология разработки ПО – Devops (development и operations), суть которой в тесном взаимодействии программистов и админов. Задача методологии – быстро, безопасно и с малыми затратами производить и устанавливать продукты и сервисы, а также сопровождать продукты, при этом не терять время на стыке между программистами, которые являются источниками изменений, и поддержкой, которая хочет стабильности.

Подробности

Илья Семенов

В 1999 закончил ЛЭТИ, кафедру радиоэлектронных средств. В 2004 получил PhD на факультете вычислительной техники университета фундаментального обучения. В 2013 закончил в Политехническом университете Президентскую программу по подготовке управленческих кадров. В 2014 получил сертификат немецкой Академии экономики и управления AFW по направлению управление проектами.

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

О компании

«Смарт Процессинг» - быстрорастущий процессинговый проект. Компания использует передовые средства разработки и специализируемся на решениях по управлению информацией. Проекты компании - высокопроизводительные процессинговые системы для приёма и обработки транзакций в разных предметных областях.