Разработка программного обеспечения – это сложный и многострадальный процесс, который требует взаимодействия множества участников. Без определения общих целей разработки с заинтересованными сторонами и ЛПРами ничего не выйдет. Что даёт такая вроде бы простая вещь, как синхронизация по целям.

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

📍У всех есть мотивация быть в проекте: Работа на одну цель сплачивает, но хорошо бы, чтобы все понимали, а зачем это лично им. За идею люди не так долго способны шагать вместе. Личные цели тоже нужно прояснять.

📍Все видят риски и работают с ними: Все понимают, что будет, если не сделать проект или сделать плохо. Все согласны со списком рисков и их весами. Тогда с вероятностью 99% команда честно отработает всё, что сможет, для их минимизации.

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

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

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

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

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

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

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

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

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

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

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

Провели вебинар "Облака точек". Обсудили кейсы облаков точек в строительстве и добыче, посмотрели демо. Было много вопросов про то, как работать с облаками без спец ПО и восстанавливать облака точек из фото и видео 360. Запись вебинара по ссылке.
Буду рад продолжить обсуждение!

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

Илья, мы обсудили твоё предложение, не готовы работать, видим много рисков из-за того, что вы работаете с нашими прямыми конкурентами

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

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

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

К слову мне эти аргументы не помогли😁

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

Соблюдение NDA и доверие важны и для подрядчика. Подрядчик тоже строит с вами отношения, если это не залётный гость на тендере. Главное – делать осознанный выбор и уверенно двигаться вперёд, сосредотачиваясь на развитии своего бизнеса.

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

На днях участвовал в круглом столе ИТ директоров – коллеги обсуждали своё место в большом и сложном процессе цифровизации промышленности. В итоге разговор свёлся к тому, как ИТ директору показать ценность своей функции внутри компании. Кажется, что если это порешать, то работать станет несколько проще. Тезисы обсуждали до жути банальные, но тут как посмотреть😁 Бонусом – цитата одного из участников!

Что делать ИТ-директорам, чтобы им давали денег и людей и видели их вклад?

📍Инициируйте инновации
ИТ-директор должен быть не только исполнителем, но и инициатором изменений. Должно быть видение, предложения и аргументы к ним. Следите за трендами, посещайте конференции, спикерам которых вы доверяете. Я люблю инженерные, типа 100Build Tech, но уверен, что в каждой отрасли есть свои классные. Присмотрите для себя пару-тройку технологий и найдите тех, кто или такое уже внедрял, или кому-то делать. Точно будет полезно поговорить часок.

📍Не пытайтесь сразу построить “Байкал” за 200+ млн
Начните с малых инициатив, которые могут продемонстрировать положительный эффект от внедрения технологии. Да, все говорят, что концепция пилотов устарела. Но это работает. Каждый день вижу, что да.

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

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

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

📍Ищите правильных людей в команду. Под себя и под проекты
ИТ-директор “Бытпласт” Александр Громов:

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

В перерывах между докладами родился пост с кодовым названием "3 строчки для расчёта КП” 🙂

Вчера коллеги переслали мне далеко не первый в моей жизни супер лаконичный запрос клиента

Ознакомились с вашим портфолио. У нас 300 проектировщиков, нужна система для контроля эффективности работы. 40% – удалёнщики за пределами РФ. Ждём КП.

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

Что точно нужно знать мне как подрядчику, чтобы выдать корректное КП на задачу. Даже если я сделал уже 30 таких проектов:

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

📍Как выглядит бизнес-процесс в компании: ключевые этапы и участники. Россия – огромная страна и важных нюансов в процессах – десятки. И часть из них точно повлияет на стоимость разработки.

📍С чем и кем нам нужно “подружить” наше решение: интеграции, требования надзорных органов, правила ИБ. Это у всех тоже разное. Кому-то, например, можно опенсорс, а кому-то в эту сторону даже смотреть нельзя.

📍Когда должен быть результат. Сажать одновременно 10 разработчиков на 2 месяца работы и 1 на год – это разные КП.

И у любого цифровизатора эти вопросы будут. Просто у опытного будет готовый опросник с вариантами ответов. А с неопытным придётся поговорить 2-3 часа, чтобы всё собрать.

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

У программистов термин "костыль" почти всегда имеет негативную окраску. Да что там у каких-то программистов, я сам когда активно занимался программированием с задором на ревью кода находил "костыли" и весело стебался над авторами (тайно надеясь, что мои “костыли” никто не найдёт).

Но с течением времени и сменой рода деятельности моё отношение к "костылям" менялось. Кажется, что иногда использование "костылей" действительно может оказаться оптимальным и даже единственным подходом к решению проблемы.

Сегодня про такой "костыль".

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

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

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

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

Запускаем новый формат. Помните пост про ИТ-директоров и цитату Александра Громова из Бытпласта? Мы решили продолжить беседу.

Для контекста:
Бытпласт – один из лидеров в России по производству товаров из пластмасс. В компании около 400 сотрудников и 1500 наименований изделий.

❓Александр, какие технологии считаете самыми перспективными для своей отрасли и почему? 

Ответ будет немного сложный, но правдивый, из личного опыта. Во-первых, это IoT. Он позволяет эффективно управлять оборудованием в реальном времени и повышать качество продукции. Системы диспетчерского управления и сбора данных (SCADA) помогают централизовать управление производственными процессами, дают старт оптимизации. MES, MRP и ERP круто работают вместе – обеспечивают прозрачность, контроль, адекватное планирование. Cистемы управления жизненным циклом продукции (PLM) и управления складом (WMS) помогают наладить чёткую организацию процессов и снизить затраты. 

❓Что из этого уже реализовали или реализуете у себя?

Реализовали в процентном отношении SCADA(30%), MES (60%), ERP (80%), WMS(40%), MRP(50%).

❓Какие проекты делать нравится больше всего?

Нравится развивать проекты WMS, MRP, PLM, ERP, так как данные направления привлекают большое количество внутренних смежных подразделений. Коллектив компании сближается, люди видят общий результат, общее дело. 

❓Какой был самый большой фейл в роли ИТ-директора (если о таком можно говорить)?

Фейлом считается принятие на должность системного аналитика так называемого "протеже"? Представлен данный сотрудник был высшему руководству как перспективный и очень грамотный специалист. Озвучил, что я за него ручаюсь. А он уволился через месяц 😂

❓От чего рассчитывается бюджет цифры в компании – от прибыли или от целевых метрик? 

Бюджет рассчитывается комбинированным способом. Лидирующим всё-таки является прибыль, но как правило есть и целевые показатели, способные скорректировать бюджет.

❓Какой год работы в должности ИТ-директора самый страшный и почему? 

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

❓Что больше всего бесит в общении с ИТ-компаниями? 

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

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

Как и где так быстро брать людей? Да ещё таких, чтобы умели работать на базе российских продуктов. Не гениев-одиночек, а командных.

Задачка со звёздочкой. Именно поэтому в октябре команда Rubius вместе со своим давним партнёром C3D Labs открыла стажировку по направлению САПР.

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

Как это будет на этот раз и какой продукт разрабатываем на базе геометрического ядра С3D – читайте на сайте Rubius!

Весь мой опыт реализации проектов цифровизации показывает, что 80% успеха зависит от менеджера проекта… на стороне Заказчика. Это не самое популярное мнение в ИТ-компаниях по понятным причинам. Но я остаюсь при своём.

Почему Заказчику важно иметь квалифицированного менеджера, и как его отсутствие может привести к масштабным проблемам?

Менеджер проекта со стороны Заказчика — это не просто координатор, который следит за выполнением сроков и управляет бюджетом. Этот человек выполняет критически важную функцию, является связующим звеном между командой разработчиков и бизнесом.

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

📍Управление коммуникацией и обратной связью: потеряться во мнениях ЛПРов на стороне Заказчика – легко и очень больно, может привести к провалу проекта.

📍Реакция на изменения: скорость интернета растёт, а вот информация по этажам больших корпораций спускается медленно, круто, когда кто-то следит, куда ветер дует.

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

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

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

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

Помните рекламу "Сколько вешать в граммах?" про то, что точность никогда не бывает лишней? Согласитесь, фраза не зря стала крылатой🙂 Но если колбасу можно измерить до граммов, то с кучей угля или железной руды на складе ГОКа всё не так просто – на весы не положишь.

Тахеометры дают погрешность в 5-10%. В итоге реальные запасы неминуемо оказываются меньше учётных. Как здесь планировать работу и оптимизировать ресурсы? Больше геодезистов на площадке проблему не решат: люди среди бульдозеров и экскаваторов – это лишние риски травматизма.

Тогда как организовать контроль за запасами и получать стабильный результат измерений независимо от погоды, людей и формы той самой кучи?

Об этом и поговорим на онлайн-встрече об инвентаризации открытых складов ГОКов 28 ноября в 11.00 (МСК). Приглашаем главных инженеров, маркшейдеров, геодезистов и специалистов по охране труда.

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

P.S. Кстати, реклама была совсем не про колбасу🙂

Ссылка на вебинар тут

Совместный проект компании Rubius и федерального застройщика Эталон вошёл в шорт-лист премии "Компания будущего".

Эксперты премии при поддержке Минэкономразвития выбирают проекты и компании, которые задают тренды – как будут развиваться целые отрасли в России. Так, например, Эталон меняет подходы к проектированию зданий.

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

Уже завтра, 4 декабря, эксперты объявят победителей. А пока ещё есть время – голосуйте за наш сервис "Цифровое техническое задание" на сайте премии. Сдвинув бегунок на отметку 10, приблизим светлое цифровое будущее.

https://special.ko.ru/digital-transformation-2024

Друзья, всем привет!

В приближении Нового года захотелось оглянуться на почти прошедший год и оценить, запрос на какие технологии превалировал в 2024 в проектах Rubius. С чем Заказчики обращались чаще всего?

📍Большие языковые модели (LLM)
Глобальный тренд, начавшийся с ChatGPT, не обошёл и меня стороной. Самое большое количество запросов было по ИИ: анализ строительной документации, корпоративный поиск по базе данных, генерация шаблонов документов и многое другое.

Всё больше и больше компаний задумываются об ИИ. Подстегивает их интерес, как мне кажется, то что пионеры этих технологий уже переходят от стадии проработки концепций (PoC) к подсчёту экономических выгод от первого года использования решений. Для многих это важный сигнал к началу внедрения технологий в собственный производственный процесс.

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

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

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

Очень разного масштаба проекты (от аналитики процесса возведения одного строительного объекта до контроля показателей эффективности деятельности в 89 регионах страны) показывают на сколько ценной становится информация для бизнеса.

Это были тренды, с которыми наша команда столкнулась в этом году. С нетерпением жду года следующего, чтобы узнать, что нового он готовит в плане технологий. А вам всем хочу пожелать полезных инноваций, эффективного использования современных технологий и, конечно же, успеха во всех начинаниях. С Новым годом!🎉🎄🎅

Про это как будто бы никто не знает, но мы работаем с логистикой уже около 8 лет. Никогда не ставили себе такой цели, но привыкли честно работать с разными запросами клиентов. В итоге научились управлять заказами и отгрузками, создавать внутренние биржи грузоперевозчиков и даже немного контролировать склады. Чтобы как-то систематизировать свой опыт, последние месяцы много говорим с рынком логистики – DPD, Байкал Сервис, Boxberry и ещё с десяток разных компаний. Для себя и для коллег завели канал, где делимся тем, что узнаём или подтверждаем через интервью. Подписывайтесь - https://news.1rj.ru/str/digital_logistics_pro