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

Эта статья о том что у организационного провала ИТ-функции существует типовой сценарий. Эта статья о том когда, где, что и как ломается

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

В этой статье мы не будем рассматривать то как лечить перечисленные проблемы или как стать cycle breaker. Эти вопросы нужно рассматривать отдельно.
Поэтому в этой статье — описываем симптоматику и пытаемся поставить диагноз. И плачем вместе.

Знакомая ситуация: вашей команде нужна фича в чужом сервисе, вы ставите задачу — и ждёте. Неделю, месяц, квартал. Потому что у того сервиса свои приоритеты и свой ограниченный ресурс. А ваш продукт стоит.

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

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

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

В ходе исследований наткнулся на проект "Университет 2035". В рамках поиска кейсов по технологиям RAG наткнулся на их раздел проектов.

Сайт выглядит как полноценная экосистема. Например, есть проект по разработке когнитивного ассистента для диспетчерского управления электроэнергетическими объектами на основе RAG-модуля (мне лично очень близко).

Механика работы самого университета описана красиво: есть «Банк задач», куда компании могут размещать реальные кейсы, а студенческие команды под руководством наставников берут их в работу в рамках 2,5-3-месячных интенсивов. В теории это мост между образованием и индустрией. Есть даже возможность стать ментором, партнером или просто участником команды.

Смотрю дальше…И тут начинаются вопросы.

За последний год на пресейлах я всё чаще слышу одни и те же фразы: «Дорого!», «За что такие деньги?», «С такой автоматизацией мы без штанов останемся». И это не торг за бюджет. За этими фразами стоит жесткий вопрос: какой экономический эффект покупает заказчик?

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

Есть такой тип владельцев и руководителй бизнеса, которые искренне считают, что долги — это проблема компании, а не их личная. Компания накопила долгов? Не беда. Переведём на другого человека, перестанем сдавать отчётность, обнулим счета и забудем, а кредиторы пусть дальше сами разбираются.

Спойлер: архитектура AIналитика полностью переписана, теперь Платформу можно запускать практически под любым харнесом (OpenCode, Kodik, Codex, Claude Code), а также подключать любые LLM, включая локальные. Добавлено/в разработке много новых фич: многоагентная система, доска навигации и дашборд для тимлидов.

Пару месяцев назад я опубликовал на Хабре статью «Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось». Коротко: я разработал AI Платформу AIналитик - ai-ассистента, который работает рядом с бизнес-аналитиком, как опытный коллега. Он знает методологию BABOK v3 и ведёт BA по проекту, может: спланировать, подготовить интервью, собрать требования, провести трассировку, приоритизировать, оценить риски и изменения. Покрыты все задачи пяти областей знаний, главы с 3 по 7, за исключением 8-ой.

Исходный код AIналитика v1 на Github. Канал с новостями проекта AI Платформа AIналитик.

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

Когда я говорю, что перешёл с React на Angular, на меня смотрят примерно так же, как если бы я сказал, что добровольно переехал из Амстердама куда-нибудь в Челябинск. С непониманием и вопросом «а зачем».

Если открыть типичный канал про разработку, там будет React, Next.js, React Native, снова React. Джуны учат его как первый фреймворк, мидлы обычно выносят в резюме жирным шрифтом. Angular воспринимается как что-то невероятно сложное, для мега-приложений масштаба «строим город на Луне» и бэкендеров, которым не повезло. Я тоже так думал. У меня за плечами был React, я понимал компонентный подход, умел работать с хуками, знал экосистему. И тут Angular.

Готовых инструкций, как перейти с React на Angular, в сети практически нет. Зато есть тысячи статей про обратный путь. Пришлось разбираться самому, и вот что из этого вышло.

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

В IT эту метрику считают регулярно. На складах — почти никогда. При том что текучесть персонала в складской отрасли составляет около 49% в год. Склад, который не знает своего bus-factor, не знает, насколько каждый такой уход приближает его к операционному сбою.

Важная оговорка до расчёта: bus-factor — не оценка компетентности. Высокий bus-factor у конкретного человека означает, что склад правильно спроектирован вокруг этой роли. Низкий — что знание об операции сосредоточено в одном месте и нигде больше не зафиксировано.

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

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

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

Количество итераций проверки одного документа — от 2 до 5. Серьёзно. Формулировки бывают настолько запутанными, что приходится писать кучу уточняющих вопросов.

Ещё есть ТЗ на разметку, там вообще становится понятно, почему Скайнет восстал. Например, надо обвести все надписи на вагоне. А если там мелом написано ХУZ, это должно попасть в распознавание? И вот инженеры сидят и принимают такие решения по каждой мелочи. 

Заставлять инженера, который может писать сложнейшие алгоритмы, по три дня вычитывать по шаблону один и тот же документ — это жестокая история. Правда, очень важная. Просто ничего не делать — не получится.

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

Всем привет! Меня зовут Олег Джулаев, я автор Projecto.

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

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

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

Навыки есть? А если найду?

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

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

Как-то к нам пришел очень крутой разработчик физики, очень... его переманивали год на разные проекты и под разными предлогами, а физику на том проекте настраивали через таблицы в текстовых файлах и lua-скрипты, а не через движковые параметры (ну вот так исторически сложилось), и первые недели он все время пытался что-то переписать, исправить, доработать, и 90% его изменений заворачивали на ревью, что конечно не добавляло настроение ни ему, ни команде. И визуально он работал заметно медленнее джуна, который пришёл месяцам раньше и просто принял такое положение вещей как данность, но смог пофиксить пару сложных багов, которые висели в беклоге пару лет.

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

Разбираемся, какие виды тестирования нужно проводить при внедрении заказных бизнес-приложений. Что такое воронка «бесконечного тестирования». Чем синдром «сапера» отличается от синдрома «лудомана». А также можно ли полюбить тестирование.

Изменение всего одной технической характеристики при проектировании опасного нефтеперерабатывающего объекта приводит к многочасовой ручной переделке десятков схем и спецификаций. Инжиниринговая компания КНГК-Групп, возводящая сложнейшие промышленные объекты, решила эту проблему, внедрив программное решение nanoCAD BIM Электро. Теперь модели, схемы и документы обновляются автоматически, а инженеры вместо кропотливых правок сосредоточены на проектировании и знают, что система сама проследит за точностью и согласованностью данных.

18 лет работы, 100 объектов «под ключ»: от нефтяных установок до водородных. И десятки правок из-за одной ошибки

Когда инженеры проектируют промышленные объекты, любые изменения в исходных данных приводят к десяткам корректировок. Над проектами одновременно работают специалисты смежных направлений. Они постоянно обмениваются информацией, параметры оборудования и схемы регулярно меняются. В итоге инженеры часто тратят время не на проектирование, а на перепроверку и исправление документации.

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

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

По данным команды UserJot, продакт-менеджеры тратят от 40% до 60% рабочего времени на создание презентаций, документов и отчётов, которые практически не влияют на реальное развитие продукта. В пересчёте на пятидневку — это около 20 потерянных часов в неделю на составление и обновление документации, форматирование слайдов и синхронизацию версий вместо общения с пользователями, анализа продуктовых метрик и работы с командой. При этом, согласно ежегодному исследованию Pragmatic Institute, 91% продакт-менеджеров называют работу с дорожной картой одной из ключевых составляющих своей роли, опережая описание требований (88%) и сценариев использования (85%).

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

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

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

Компания «Профсталь», производитель домов из легких стальных тонкостенных конструкций (ЛСТК), одновременно решает задачи строительства и машиностроения, создавая в одной системе и 3D-модели зданий, и детали для ремонта производственного оборудования. При этом учитываются бизнес-процессы, связанные со снабжением предприятия. Пилотный проект «Современный энергоэффективный дом из ЛСТК» показал, что решение отлично вписывается в цифровую экосистему полного цикла.

Знакомьтесь с пошаговым разбором пяти этапов тестирования программы nanoCAD Механика PRO и полученными результатами. Мы проследим, как на базе одной платформы были объединены создание 3D-моделей для аддитивного производства, проектирование строительных конструкций (ЛСТК), автоматическое формирование спецификаций, а также – и в этом ключевое преимущество программы – автоматизирован документооборот путем интеграции с системой 1С:ERP.

Оператор склада писал напрямую программисту. Директор по логистике ставил задачу руководителю разработки - разработчик откладывал то, над чем работал. Прилетала задача от CEO - все бросали всё.

ИТ не работало медленно. Просто работало одновременно над всем.

Когда я попробовал собрать картину - что ИТ сделало за последний месяц и как это повлияло на бизнес - не получилось. Задачи приходили из почты, мессенджеров, нескольких параллельных Excel-файлов. У разных людей были разные версии одного и того же списка. Формального приоритета не было ни у одной задачи: всё было одинаково срочным, потому что каждый заказчик считал своё важнейшим.

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