Управление проектами *

«Если ты не измеряешь, значит, ты не управляешь» — кто‑то из великих менеджеров

На одном совещании мне понравилась фраза руководителя: «Если вы пришли на совещание без цифр, то что мы тут собираемся обсуждать?». Принятие решений на основании фактов даже легло в основу подхода Data Driven, когда система принятия решений, основывается на анализе данных, а не на интуиции или опыте руководства, при этом бизнес‑решение подкрепляется не только показателями, но и результатами анализа их в динамике, а также прогнозами. В данной статье обсудим, какие показатели могут быть интересны руководителю операционного уровня.

Обязательная маркировка моторных масел и автомобильных жидкостей стала не просто новым этапом регулирования рынка, но и драйвером автоматизации для всего автомобильного сектора. Без DataMatrix-кода перемещение и реализация товаров этой категории становятся невозможными: код нужен производителям, импортёрам, дистрибьюторам, рознице и автобизнесу — для каждого экземпляра продукции и для каждого этапа оборота.

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

Привет, меня зовут Михаил Горбуля, product owner Polymatica BI. За два года работы над данным продуктом я смог из набора разрозненных договоренностей выстроить устойчивую систему работы, состоящую из пяти практик. Они позволяют одновременно справляться с потоком поддержки, который требует гибкости и мгновенной реакции, и сохранять предсказуемость разработки, без которой не бывает релизов и довольных заказчиков.

Если на один из пунктов ниже вы ответите да — статья будет вам полезна.

1. Вы — заказчик или внедренец: вы не можете чётко сказать клиенту, в какой версии будет выпущенная нужная ему фича или исправление, и вынуждены отвечать «скоро».

2. Вы — разработчик: вас постоянно дёргают срочными задачами, которые рушат все планы и убивают фокус.

3. Вы — поддержка: живёте в режиме тушения пожаров, а действительно важные баги тонут в очереди.

4. Вы — руководитель: у вас есть иллюзия «забитого спринта», которая разрушается в первый же день.

Контент в базе знаний не может существовать сам по себе — его нужно организовать и им нужно управлять. Именно этому я посвятила серию статей.

Привет, Хабр! Меня зовут Анастасия Граф, я руковожу отделом разработки технической документации в Maxim Technology. За плечами — 16 лет преподавания математического моделирования в вузе и восемь в управлении и реинжиниринге базы знаний службы поддержки большой государственной информационной системы, разработке и внедрении методологии наполнения, актуализации, верификации базы знаний разработки, юротдела и нескольких торговых предприятий.

В этой части разберёмся с универсальными требованиями к базе знаний на примере Confluence и с чего начать  «уборку»: как сортировать содержания накопленных знаний, что учесть и как это может в итоге выглядеть. Статья подготовлена по мотивам доклада на Saint TeamLead Conf.

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

Именно эту задачу решает YMS (Yard Management System) — система управления двором (yard management) и территорией складского комплекса. В статье разберём, что такое YMS, какие функции действительно важны, как обычно выглядит контур внедрения и чем интересен подход INTEKEY YARD.

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

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

Всем привет! Меня зовут Яна Чеканова, я проджект-менеджер в red_mad_robot уже два года — и да, я не технарь, а филолог по образованию. Парадоксально, но именно это образование помогло мне в одном из самых технологичных проектов — создании AI-поиска для сервиса книги билайн.

Идея родилась у команды билайна: они провели исследование и поняли, что большинство читателей не ищут конкретного автора или название, а ориентируются на настроение и ощущение от книги — «что-то атмосферное», «что-то как любимый роман». Так появилась гипотеза: сделать поиск, который понимает смысл запроса, а не только ключевые слова.

Мы подключились, чтобы превратить эту идею в технологию: векторизовали метаданные полумиллиона книг, обучили LLM и собрали гибридную систему, которая подбирает литературу по смыслу и контексту — даже если запрос звучит просто как «что-нибудь про путешествия во времени».

Рассказываю, как это было.

Пока IT-мир спорит о лицензиях на Open Source, в мире «больших финансов» пытаются провернуть эксплойт столетней давности. Американский инвестфонд Noble Capital подал иск в Федеральный суд округа Колумбия, требуя от Российской Федерации выплаты $225,8 млрд.

«План ничто, планирование всё...» — Дуайт Эйзенхауэр, 34-й президент США

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

В этой статье рассматриваются особенности работы с трехмерными объектами в nanoCAD Механика PRO. При создании и редактировании моделей пользователю приходится работать с 3D-телами и деталями, визуальное представление которых играет важную роль при анализе конструкции.

Когда-то давно я столкнулся с почти совершенной корпоративной методологией внедрения ИТ-проектов. Она была полной, удобной, масштабируемой и понятной даже джуну (которым я тогда был).

С тех пор, за почти 20 лет внедрений(!) в куче российских компаний, я не встретил равного ей аналога в России. И до массового увлечения Agile, и после него, и даже сейчас, после того, как рынок проголосовал за гибриды WF и Agile.

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

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

Этот текст - для начинающих РПО и РП, которые хотят вырасти в РПО.

Я расскажу про то, что такое для меня "идеальная методология", чем она отличается от PMBoK, P3.express и всего остального, почему ГОСТ34 не так уж и плох, и почему волшебная таблетка не используется повсеместно, если рецепт был известен уже 20 лет тому назад.

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление в ИТ.

Начнем с идеала...

Привет, Хабр! Импортозамещение в ИТ — это не просто смена вендоров или технологий. Это сложнейшая хирургическая операция на живом организме бизнес-процессов компании. Привет, Хабр! Я Станислав Тульчинский, руководитель блока кредитного корпоративного бизнеса РСХБ.Цифра. В этой статье расскажу про наш проект по замене информационной системы управления жизненным циклом залогов и договоров залога (и это не одно и тоже) по кредитам юридических лиц в банке.

Вы написали безупречное техническое задание. Провели двадцать интервью. Заполнили сто страниц в Confluence. Проект запущен, а через месяц ключевой стейкхолдер говорит: «Нет, это не то, что мы хотели». Знакомо?

Классический бизнес-анализ даёт нам инструменты для работы с озвученными потребностями. Но настоящая магия (и главные риски проекта) скрыта в зоне неозвученных мотивов, страхов и психологических игр. Сегодня поговорим о том, как применять методы, условно называемые «психоанализом стейкхолдеров», не будучи психологом.

Всем привет! На связи практика Business Intelligence GlowByte. Открываем год полезной информацией. 

В 2022 году мы опубликовали на Habr статью про выбор BI-платформы, публикация набрала более 24 000 просмотров. Тогда наш подход был простым: составили большую таблицу сравнения по множеству критериев, поставили баллы — и вуаля, выбирайте лидера.

Четыре года спустя понимаем: такой подход работал для своего времени, но сегодня устарел. В условиях большой неопределенности компании действительно искали универсальные решения "на все случаи жизни". Логика была понятной: выбираем один инструмент, который закроет максимум потребностей на годы вперед.

Но рынок BI созрел. Заказчики стали подходить к выбору осознаннее, исходя не из абстрактного функционала, а из конкретных бизнес-сценариев. И оказалось, что попытка найти "универсальную пилюлю" часто приводит к разочарованию.

Расскажу, как мы в GlowByte пересмотрели методику выбора BI и почему сценарный подход работает эффективнее.

Стандарты автоматизации корпоративных информационных систем развиваются эволюционно: от автоматизации небольшой предметной области, обеспечиваемую незначительным программным функционалом, до покрытия хозяйственных операций предприятий и даже холдингов, требующего масштабных программно-технических разработок. Это наглядно демонстрирует стандарт ERP, включавший в себя изначально класс систем MRP2, далее трансформировавшийся в ERP2 и ERP3, объединив множество прочих классов систем (SRM, CRM, PLM, SCM, FI и др.). Таким образом полнота охватов бизнес-процессов демонстрирует степень развития как предприятия, так и программного решения. Не стал исключением и класс автоматизации CRM: технологическое развитие и инновации в области управления взаимоотношениями с клиентами, их опытом и знаниями, позволил расширить данных стандарт и предложить новый – Customer Experience или CX.

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

У нас есть цех, где жидкая сталь превращается в слиток. Это происходит в УНРС — установке непрерывной разливки стали. На УНРС жидкая сталь проходит через кристаллизатор, где формируется «корочка» (оболочка) будущего непрерывнолитого слитка, и поддерживающую систему, состоящую из роликовых сегментов, где происходит окончательное затвердевание слитка за счёт охлаждения в зоне вторичного охлаждения (ЗВО) водо-воздушной смесью.

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

Сегменты постоянно осматривают рабочие.

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

Получилась критичная ИТ-система, которая не делает ничего космического или нагруженного, но предельно важна всем в цеху.

Вот про развитие этой системы я сейчас и расскажу.

Коллизии между архитектурой и инженерными системами в модульных зданиях часто обнаруживаются слишком поздно – на производстве или стройплощадке. Задача, стоящая перед предприятием «СПЕЦ Прожект групп» (Бронезавод «АПИТ») заключалась в выявлении и устранении подобных явлений на ранних этапах реализации проектов. В кейсе представлен детальный разбор, как средствами nanoCAD BIM Строительство создавалась единая BIM-модель, где каркас, панели и проемы становятся основой для бесшовной интеграции всех смежных разделов. Представлена трансформация типового чертежа формата DWG в «живую» параметрическую модель, где корректировка одного свойства автоматически обновляет все планы, разрезы и ведомости.

По просьбе подписчика моего ТГ-канала публикую список источников для самоподготовки. Легендарные вещи, полностью изменившие мои взгляды на индустрию.

Начнем данную статью с казалось бы простого вопроса: "Кто такие клиенты и зачем их считать?". Ответ на данный вопрос не такой простой и вообще философский! Каждая компания и человек в отдельности ответят на него по-своему.

В телеком компании вам скажут: "Клиент = абонент. Мы считаем их прирост, а также дни, в течение которых они платят нам абонентскую плату.". В небольшой парикмахерской вам, возможно ответят так: "Ну вот кто пришел стричься, тот и клиент. Считаем количество тех, кто постригся за отрезок времени.". Подсчет клиентов может даже пригодиться для оценки компании третьими лицами, здесь также используются свои методологии. И так далее... Думаю, мораль ясна, каждый определяет для себя сам, кто является клиентом и как их считать.

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