В современном мире логистики управление IT-проектами требует не только технических знаний, но и умения работать с людьми и ресурсами. Мы пригласили в наш подкаст Джонатана Воложчика, IT-директора крупного оператора складской логистики, чтобы он поделился своими знаниями и опытом в управлении IT-проектами в сфере логистики. В этой статье мы представляем вам текстовый пересказ его выступления.
Джонатан рассказал о вызовах и решениях, с которыми сталкиваются IT-специалисты в крупных масштабных проектах, а также поделился секретами успешной работы с подрядчиками и командой.
Начало карьеры и ключевые достижения
Расскажи немного про себя?
Джонатан: Я IT-директор в компании FM Logistic. Компания FM Logistic — это международная логистическая компания, основанная во Франции.
Во-первых, я не русский, я приехал сюда 12 лет назад и у меня нет формального IT-образования. Всё, что я рассказываю, базируется исключительно на моём личном опыте, а также на том, что я узнал через эксперименты и практику. Поэтому не стоит ожидать академической точности в моих рассказах.
В институте я учился менеджменту. Почти сразу после этого я попал в компанию FM Logistic и тогда увлёкся IT, сначала как хобби. Это было ещё во Франции. Тогда было модно делать свои сайты, и я развлекался, создавая их на таких CMS, как Joomla и WordPress. Еще я с детства я увлекался играми и создавал форумы для своей команды, что также было весьма популярно.
Начав работать в FM Logistic, я сначала занимался небольшими IT-проектами, работал стажёром-разработчиком. За 15 лет я прошёл путь до IT-директора. Мне повезло встретить руководителей, которые верили в меня. Я достаточно любознательный человек, люблю искать и пробовать что-то новое. Сейчас применяю все эти знания в своей работе.
Какие три самых значимых достижения в твоей карьере?
Джонатан: Первое достижение связано с внедрением единого инструмента в разных странах. Процесс заключался в том, чтобы по прибытию в каждую страну, идентифицировать ключевых пользователей, общаясь с ними несколько дней, объясняя их роль и миссию. Затем мы вместе внедряете продукт в этой стране, проходя неделю стабилизации и затем переходя к следующей стране. Это заняло несколько месяцев, но мы успешно запустили этот масштабный проект, его успешное завершение стало для меня важным этапом в жизни.
Второе достижение — внедрение нового core-продукта. Мы заменили самописный legacy софт новым логистическим решением. Ситуация была такой: компания много лет работала на одном кастомном софте, и задача заключалась в том, чтобы внедрить готовое коробочное решение. Это потребовало изменений в культуре компании.
В отличие от старого софта, новый продукт сложнее кастомизировать, нужно соблюдать стандарты, и у нас нет полного доступа к исходному коду. Реактивность, то есть скорость отклика на запросы пользователей, снизилась. Люди привыкли, что их запросы быстро выполняются, а с новым продуктом нужно было искать компромиссы и учитывать развитие самого продукта. Несмотря на сложности, мы успешно внедрили это решение. После первой итерации продуктом пользовались около 80 человек, а сейчас — несколько тысяч.
Третье достижение — реализация моей давней мечты. За годы работы у меня сложилось представление о том, каким должен быть идеальный логистический продукт. Ситуация на рынке, включая импортозамещение и уход иностранных вендоров, заставила нас переосмыслить свои подходы. Мы решили создать масштабный логистический продукт, который соответствует новым требованиям рынка и новым клиентам. Это позволило нам стать гибче, быстрее и дешевле. Сейчас этим продуктом пользуются около 250 человек, и это значительное достижение, учитывая все сложности и изменения на рынке.
Подготовка и реализация проекта
Как собрать команду проекта?
Джонатан: Сбор команды для IT-проекта — это не просто выбор специалистов с нужными навыками, это более сложный процесс, требующий учёта интересов сотрудников. Я выбираю тех, кто действительно заинтересован в проекте и готов развивать свои навыки. При этом я никогда не основываюсь исключительно на знании технологии, которая будет использоваться в проекте. Технологию можно выучить, а вот страсть и мотивацию — нет.
Если для проекта необходимы подрядчики, я выбираю их так же, как и внутренних специалистов, исходя из того, с кем мне будет комфортно работать. Важен не столько опыт компании, сколько опыт и мотивация конкретного человека.
Outsourcing или in-house?
Джонатан:
Нет однозначного победителя, всё зависит от контекста. Есть задачи, которые лучше выполнять самостоятельно, и задачи, которые целесообразнее отдать на аутсорсинг. Когда перед тобой стоит задача выполнения бизнес-требований, важно чётко понимать, почему ты выбираешь тот или иной подход.
In-house подходит, если ты считаешь, что можешь добавить ценность, которую рынок не может. Это может быть связано с финансовыми причинами или скоростью реакции. Но если ты не видишь особой ценности в выполнении задачи своими силами, стоит задать вопрос: почему бы не отдать это на аутсорс? У всех много задач, и иногда легче и эффективнее передать часть работы внешней команде.
Outsourcing приносит много плюсов в ситуациях, когда у компании есть технологические преимущества. Если у меня в компании есть специалисты, которые могут мониторить тренды и рекомендовать лучшие решения, я предпочитаю оставить эти компетенции внутри. Однако, если задача требует специфических навыков, которых у нас нет, лучше передать её внешней команде.
При разработке важно решить, нужно ли нанимать разработчиков в штат или воспользоваться аутсорсом. Если продукт будет использоваться много лет, возможно, лучше разработать его внутри. Но иногда подрядчики могут выполнить задачу так же эффективно, как и собственная команда, при условии правильного управления и контроля.
Риски in-house:
- Компетенции могут уйти вместе с людьми, и новые сотрудники могут предлагать другие решения, что может повлиять на продукт.
- Невозможность быстро масштабировать ресурсы для выполнения задачи.
- Неправильные архитектурные решения из-за ограниченности внутреннего контекста.
Риски outsourcing:
- Стать заложником партнёра, который может не оправдать ожидания.
- Необходимость постоянного контроля и управления процессом.
- Потеря времени при смене подрядчиков и перезапуске проекта.
Важно помнить, что outsource и in-house не исключают друг друга. Важно уметь правильно сочетать оба подхода, учитывая специфику задачи и возможности компании.
Как избежать рисков при работе с аутсорсером?
Джонатан: Чтобы избежать риска стать заложником аутсорсера, нужно быть активно вовлечённым в процесс разработки и контролировать, что именно делает подрядчик. Важно понимать не только что они делают, но и как они это делают. Вот несколько ключевых шагов:
- Понимание процесса разработки: Тебе нужно понимать, как исполнитель разрабатывает продукт. Например, если разработка идёт в Bitrix, важно знать, как они изменяют модули, как организован код, где он хранится (в гите или другом репозитории).
- Контроль логики: Ты можешь не читать код, но нужно задавать разработчикам конкретные вопросы. Например: «Объясни мне простыми словами, какую фичу ты разработал и какую логику закладывал». Если разработчик объясняет сложно и непонятно, это сигнал о проблеме. Если ответ чёткий и ясный, это хороший знак.
- Тестирование и проверка: Убедись, что кто-то тестирует каждую фичу и подтверждает, что она работает как нужно. Это важно для поддержки и для того, чтобы не стать заложником уникальных решений, понятных только одному подрядчику.
- Обучение и вовлечение: Важно обучить подрядчика, объяснить контекст и специфику вашего бизнеса. Я готов тратить время на обучение их людей, чтобы они поняли то, что я хочу, какую логику и идеологию закладываю в продукт. Это создаёт общую базу знаний и уменьшает риск недопонимания.
- Постоянное общение: Регулярное общение с разработчиками и контроль статуса проекта. Каждый день или неделю нужно проверять, как идут дела, какие проблемы возникают, и при необходимости помогать их решать. Это предотвращает ситуацию, когда внешняя команда работает в изоляции и возникают проблемы на поздних этапах.
- Долгосрочное партнёрство: Если ты рассчитываешь на долгосрочное партнёрство, обучение и вовлечение подрядчика — это не потеря времени. Это инвестиция в надёжное сотрудничество.
Как происходит внедрение продукта в компанию?
Джонатан: Главная ошибка, которую часто допускают, — это внедрение изменений сверху вниз, когда решения принимаются в узком кругу руководителей, проект-менеджеров и консультантов. Затем эти решения просто объявляют сотрудникам: "С этого дня мы будем работать по-новому, следуйте этим инструкциям". Однако люди, которых эти изменения касаются, часто не вовлечены в процесс и могут воспринимать нововведения без энтузиазма.
Один из ключевых факторов успешного внедрения изменений — это насколько близко ты будешь к тем людям, которых эти изменения затронут. Ты должен их понять, а они должны тебе доверять. Чтобы заработать этот кредит доверия, нужно быть с ними, понимать их потребности и искренне хотеть помочь.
Это не просто чек-лист, который можно пройти, это должен быть ваш личный интерес и желание улучшить ситуацию.
Просто объявить изменения недостаточно. Важно выстроить взаимопонимание и выяснять их реальные проблемы. Я всегда стараюсь быть рядом с пользователями, изучать их текущие процессы и помогать им адаптироваться к новым системам.
Искренность и вовлеченность — ключевые элементы. Нужно получать удовольствие от процесса, активно искать пути улучшения работы других людей и не просто выполнять проект, а действительно улучшать жизнь тех, с кем работаешь. Если ты начинаешь с правильных причин и погружаешься в процесс, успех практически гарантирован.
Продажа продукта
Как продать продукт? На что ты в первую очередь обращаешь внимание?
Джонатан: Во-первых, я заинтересован в тех, кто действительно может предложить что-то ценное и интересное. Что мне не нравится, так это компании или люди, которые пытаются доказать свою силу тем, что у них много других клиентов, и они все довольны. Популярность продукта среди многих людей — это хорошо, но это не убеждает меня, что они решат именно мою проблему.
Пример из практики: У нас был тендер, в котором участвовали две компании, и они очень отличались друг от друга. Первая компания пришла на встречу, которая длилась час. Первые 20 минут они показывали портфолио своих клиентов, затем 10-15 минут объясняли свои навыки и достижения, и оставшиеся 10-15 минут мы обменивались мнениями и вопросами. Они задали вопрос: «У вас есть вопросы?» На что я ответил, что нет, у меня нет особо вопросов. Они ушли.
Вторая компания начала встречу с короткой презентации о себе, которая длилась около 5 минут. Затем они сразу перешли к обсуждению нашего проекта. Они задали очень релевантные вопросы по существу, углубляясь в детали, которые обычно всплывают через полгода работы над проектом. В течение 30 минут они задавали вопросы, а затем предложили конкретные решения и сроки. Спустя 2 дня я выбрал вторую компанию, и проекты были очень успешны.
Подходите к каждому проекту индивидуально, показывайте своё понимание и готовность решать конкретные задачи клиента. Это ключ к успешной продаже продукта.
Советы по работе с командой
Какие инструменты ты можешь посоветовать при работе с командой, что используешь в своей работе?
Джонатан: Я разработал небольшой скрипт, который каждый день отправляет людям простую форму для заполнения. Они описывают, что делали сегодня и что планируют делать завтра. Каждый заполняет эти два поля — это всего 10 слов.
Как это работает: Люди фиксируют цель на день вперёд. Когда они приходят утром, они могут увидеть, что они писали вчера, и сравнить, что планировали сделать и что в итоге сделали.
Преимущества:
- Фокусировка на задачах: Это заставляет людей фиксировать цель на день и следовать ей.
- Прозрачность: Список того, что каждый заполнил, рассылается всей команде, включая меня. Все видят, кто чем занимается, что добавляет открытости в работу.
- История изменений: Я иногда возвращаюсь к этим записям и вижу, как люди меняются, как они ставят цели и на что тратят время. Это помогает отслеживать прогресс и эффективность.
- Практическое применение: Этот инструмент помогает снизить количество отвлечений, убирает лишний шум и позволяет лучше управлять своим временем.
- Простота и гибкость: Это небольшая Google форма, которую каждый заполняет. Затем информация собирается в общую базу и рассылается всем. Понимание, чем занимаются другие, помогает новичкам в компании быстрее включиться в работу.
Попробуй внедрить такой инструмент. Это не панацея, но это простой способ повысить прозрачность и эффективность. Людям полезно знать, что они будут делать завтра.
ESB
Что такое ESB, как ты с этим познакомился и как используешь?
Принцип слaбосвязанной системооритентированной архитектуры
Джонатан: Под этим термином можно подавать разные вещи. Для меня ESB — это платформа, которая позволяет управлять множеством различных интеграций между системами в быстром виде, не затрачивая время впустую на управление и обработку ошибок, которые могут возникать.
Требования по интеграции у нас не ограничены только нашими системами. Каждый раз, когда мы встречаем нового клиента, нового партнёра, мы строим с ними автоматизацию. Благодаря чему наши отрасли становятся технологичными со временем. Никто больше не работает на больших масштабах вручную – по почте с экселями, хотя это и присутствует во многих местах, тем не менее все хотят интегрироваться в автоматизацию. Все привыкли к описанной API-документации.
Современное поколение сотрудников, которое работает сейчас в различных компаниях адаптировалось к новым темпам интеграции, поскольку они родились уже в технологическом мире и им привычен такой темп.
Возвращаясь к ESB, если прописывать вручную каждую интеграцию, то можно наткнуться на множество проблем: во-первых это разное качество кода – если разработчик Вася пишет одну интеграцию, то он будет её делать по своей методологии, несмотря на правила компании, он будет решать, предусматривая различные кейсы и ошибки, что вероятно не будет охватывать всё, а потом появятся новые бизнес-кейсы, и эта интеграция становится практически как продукт, как инструмент, который требует глубокой поддержки, долгой разработки и проектирования.
ESB платформа позволяет это делать гораздо быстрее. Конкретно это low-code платформа, в которой можно кодить, указывая только то, что несёт ценность для интеграции.
То есть ты говоришь: «Мне нужны данные из базы данных». Окей, забираю там необходимые данные из базы, а весь код, который заключается в заборе этих данных, что делать с проблемой при подключении, при чрезмерном объеме данных, как вести себя с тем или иным типом данных, которые вернутся, как я должен прописать строку подключения – ты об этом не думаешь. Ты просто нарисовал кусок, который говорит: «Бери данные из базы данных» – всё. Дальше ты идёшь на следующий шаг и говоришь: «Бери вот эти данные и преврати их в инструкцию для определенного бота или залей их куда-то».
То есть ты по сути описываешь бизнес-логику твоего потока интеграции. Ты уже не пишешь код, ты разрабатываешь в том смысле, что к тебе попадает проблематика: «Вот мы вам отправляем эти данные, вам нужно сделать действие А, действие Б, В». И всё. Ты прямо так и строишь свою логику.
Что также называется ETL — Extract, Transform, Load. Платформа поддерживает и ESB и ETL – простые операции на большом объеме данных: например конвертация или заливка в Data Warehouse данных по расписанию или триггерам.
ESB — это Enterprise Service Bus, шина, которая отвечает за коммуникации. Это шина обмена данными и инструкциями между системами. Часто эти понятия сливаются, часто они вместе строятся и вместе продаются.
Подключение напрямую к базе данных может быть спорным решением с точки зрения безопасности, но если это помогает выполнять задачи быстрее, то это будет оправдано.
ESB помогает избежать необходимости передавать множество задач подрядчикам, позволяя решать их внутри компании.
Мы используем ESB платформу для управления двумя тысячами интеграций. Мы знаем, какие интеграции за что отвечают, кто их использует. Поддержка также осуществляется без особого обучения, что большой плюс.
В итоге получается, это такой конструктор, который позволяет собрать интеграцию с помощью мыши и небольшого количества правил с небольшим использованием кода, что скорее исключение из правил, в основном всё собирается на готовых компонентах.
И ты научил этому процессу своих логистических аналитиков?
Специально подчёркиваю, что это аналитики, а не разработчики которые курс молодого бойца по использованию этой шины и смогли поддерживать свои участки интеграции самостоятельно, не сливая всё на разработчиков.
Логисты занимаются аналитикой, могут написать документ по потокам, сказать, где какие данные надо передавать, какие должны быть поля, их типы и прочее. С этим знанием они приходят, изучают шину данных, конструктор, и дальше на этом конструкторе могут либо собирать и поддерживать существующее решение.
Джонатан: В этом деле участвуют люди, которые не были продвинутыми айтишниками, которых мы научили бизнесу. Также есть направления, где люди из бизнеса люди с небольшими, но всё-таки склонностями или пониманием технологий могут быть полезными. Если у человека есть базовое понимание, что такое база данных, что такое FTP, то этого уже достаточно. Он может стать разработчиком или аналитиком, который производит интеграции для тебя. Это очень ценно, это входная дверь в IT. Не у всех есть навыки программирования, но через эту дверь они могут их развить. Они начинают понимать, как организован код, как решать задачи.
Low-code
Сейчас всё больше решений презентуют именно с low-code составляющей. Как ты видишь это развитие?
Пример структуры джобы low-code платформы
Джонатан: Да, их действительно становится больше. Моё мнение на этот счёт такое: есть несколько причин для этого. Во-первых, это технологические достижения. Сейчас платформа лучше, чем была раньше.
Второй фактор — нишевый эффект. Всё больше компаний специализируются в одном деле, создают специализированные low-code платформы. Есть платформы для начинающих, есть для разработчиков, есть по отраслям, по типам интеграции, по типам технологий. Это как с компаниями: меньше гигантов, больше стартапов с узкой специализацией. Google, Amazon, Apple и Facebook перекупают эти инициативы, потому что по скорости, технологии и пониманию нишевой области они не смогут дотянуться до уровня этих специализированных компаний. Эти люди, движимые страстью к продукту, делают его самым качественным. В low-code платформах появляется такой же эффект. Нет одного, который лучше других, они просто разные.
Если завтра у меня появляются новые требования, которые платформа не выполняет, я буду ориентироваться на другой продукт. Сейчас можно рассматривать IT как расходник. Ты производишь что-то в контексте здесь и сейчас, надо думать о последствиях и устойчивости решения, но не надо думать, что то, что ты внедряешь сейчас, будет жить через 20 лет.
