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

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

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

📍Все видят риски и работают с ними: Все понимают, что будет, если не сделать проект или сделать плохо. Все согласны со списком рисков и их весами. Тогда с вероятностью 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!