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

На Хабре в последнее время вышло две статьи про результаты, так сказать, "внедрения" ИИ в практики ИТ-отрасли: про сломанный найм (не очередная порция эмоций, а вполне законченное исследование вопроса), про общее помешательство на самой теме внедрения ИИ с несколькими яркими выводами. Было много и других статей, затрагивающих живые вопросы из этой темы.

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

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

Спойлер: нет, я не про пандемию

Всем привет! На связи Саша Петрушин, я руковожу группой разработки в центре разработки и машинного обучения компании «Инфосистемы Джет».

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

Дисклеймер: в этой статье – теория, как проект мог измениться в 2026 году. ИИ-агенты — это другие требования к информационной безопасности. Используйте их разумно.

В марте, в разгар локдауна, я пришёл в команду пятым разработчиком: Angular 1.4 с Backbone, переписывание на React, виджеты, 2400+ сценариев подачи заявлений. Потом мы расширили команду до двадцати фронтендеров.

В общем, поностальгировал по команде и ощущению «мы же это реально сделали».

А после задался двумя вопросами.

Как бы я решал ту же задачу сейчас?

И что вообще изменилось в реальной экономике поставки продукта за последние пять с лишним лет?

В России мне было легко искать работу - бренды Яндекса и ВШЭ узнавали везде. В Америке эти названия не значили ничего. Рекрутеры не знали эти компании, а некоторые даже не могли их выговорить.

Мы приехали в один из худших периодов рынка труда США за последние десятилетия - время массовых лэйофов, хуже, чем даже в пандемию. И таких, как мы, - мигрантов без локального нетворка и узнаваемого бренда за спиной - здесь оказалось огромное количество.

Help Desk с голосовым ассистентом. Для руководителей ИТ-подразделений, упор делается на потребность, внедрение и принцип работы.

14 августа в Санкт-Петербурге стартует INFOSTART CIO CAMP 2026 - ежегодная встреча ИТ-директоров, руководителей ИТ-подразделений и цифровой трансформации. В этом году деловая программа посвящена экономическому эффекту от внедрения искусственного интеллекта и тому, как этот эффект измерять на практике.

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

Генеральный директор Инфостарта Доржи Цыденов откроет программу темой AI-native Company...

Привет, Хабр! Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.

Руководитель хочет знать одну простую вещь: движется ли работа. Самый очевидный способ проверить это — посмотреть, кто сейчас занят делом. Отсюда растет соблазн поставить трекер экрана или систему учета активности.

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

Я CTO в Арлифте — мы сдаём в аренду и продаём спецтехнику: подъёмники, мини-краны и вакуумные захваты. Наши машины работают на стройках Газпрома, Росатома, Сибура. Меняли стеклопакет на небоскрёбе Лахта весом в 2,1 тонны. Мы остекляли и помогали строить Москва-Сити. 25 городов, 3 страны, оборот 6 млрд в год и основной стек — платформа 1С и Битрикс24.

С 2021 года компания начала развивать новое направление — аренду AWP (самоходных подъёмных платформ для подъёма людей на высоту). Раньше такой техники на рынке почти не было, но она быстро стала востребованной в строительной отрасли. Арлифт начал импортировать AWP из Китая и за 5 лет сформировал собственный арендный парк более чем из 2000 машин. За последние три года оборот компании вырос в 10 раз!

Мы очень сильно и быстро выросли: компания открыла много новых филиалов, количество заказов увеличилось в 3 раза. И у меня, как у руководителя ИТ, возникли сложности:

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

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

— Сроки реализации никто точно не знал. Это приводило к конфликтам с бизнесом: мы не могли ничего обещать и ответить на входе, сколько фича будет делаться. Говорили: «Как будет, так будет».

Чтобы хоть как-то управлять процессом, решили использовать модуль Скрам в нашей тикет-системе Битрикс24. Это позволило начать планирование спринтов, но я не чувствовал, что управляю бизнес-бэклогом. Да и что происходит в разработке, было непонятно.

В тот момент у меня возник синдром самозванца: я чувствовал себя скорее аналитиком и архитектором, чем руководителем отдела разработки.

Что делать? Для начала — то, что раньше держалось на негласных договорённостях, надо было приводить в порядок и делать управляемыми процессами.

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

Сейчас расскажу, как.

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

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

Проблема часто не в самой модели, а в слабом управлении разработкой. Если в обычном проекте неясно, что именно строят, для кого и как будут проверять результат, AI этого не исправит. Он лишь позволит ошибаться быстрее.

У меня был другой путь. Я не «внедрял AI в компанию» и не измерял эффективность числом сгенерированных строк. Я начал использовать AI-агента как постоянного участника разработки.

Или как один лотерейный билет превратился в несколько сотен требований, десятки интеграций и пять месяцев Discovery.

Когда мне предложили заняться разработкой с нуля цифрового сервиса Альфа‑Мании, я была уверена, что понимаю задачу. Что может быть проще? Клиент открывает мобильное приложение банка, выбирает лотерейный билет, оплачивает его, ждет розыгрыш и, если цифры в лотерейном билете совпали — получает выигрыш. На первый взгляд всё выглядело как вполне стандартный цифровой продукт: несколько экранов мобильного приложения, интеграция с партнером, немного аналитики, немного CRM‑коммуникаций и привычная продуктовая работа.

Я никогда так не ошибалась.

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

При этом ТЗ всё ещё не было.

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

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

Привет, Хабр! Меня зовут Екатерина Горшкова я старший аналитик Битрикс24 в ZeBrains. Девять лет в продажах, шесть в IT, ещё год в образовании. Звучит как разные вселенные, но если честно, это одна и та же профессия под разными вывесками. Потому что везде нужно было понять человека напротив и договориться так, чтобы результат устроил обе стороны. 

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

Low-code, BPM и ESM-платформы — взаимозаменяемы или нет? Решают ли они одну задачу? Как формировать стратегию автоматизации, если отличия не понятны? Если запутаться в терминах, есть риск выбрать не то, что нужно для вашей задачи. Разберёмся, что может каждое из трёх решений.

Я люблю метафоры. Они работают как алгоритм архивации знаний: имя становится ключом, а распаковка происходит почти мгновенно.

Для разных устойчивых управленческих подходов я подобрал геометрические объекты. Так их удобнее держать в голове и применять в работе. Я выделяю четыре основных формы…

Может ли машина программировать — или она лишь продолжает намерение человека? Споры о вайбкодинге часто застревают между восторгом от скорости и страхом потерять контроль. Но практический вопрос точнее: при каких условиях созданной с участием ИИ программе можно доверять?

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

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

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

Меня зовут Татьяна Егорова, я руковожу департаментом бизнес-анализа в Лукоморье. У нас несколько продуктов и столько же команд, у каждой свои пользователи, дорожная карта и сроки, так что вопрос «как сделать, чтобы они не разъехались в разные стороны» встал перед нами давно. Ответ, к которому мы в итоге пришли, звучит так: аналитик делает свою задачу и тратит ещё десять процентов внимания на то, чтобы не сломать задачу соседа.

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

В начале 1960-ых годов Республика Корея все еще сильно отставала от своего северного коммунистического соседа в экономическом плане. Большинство промышленных предприятий, построенных в колониальный период, находились именно на территории КНДР. 

Южнокорейское руководство во главе с тогдашним президентом Пак Чон Хи пришло к выводу, что страна должна стать самодостаточной в производстве стали. Встал вопрос о строительстве металлургического комбината полного цикла. С этого и началась история компании POSCO. 

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

На тестовой эксплуатации менеджер создал обычную заявку на закупку. Основной объём составляли канцтовары, плюс в той же заявке было несколько мониторов. Система проанализировала состав, определила преобладающую категорию и автоматически направила всё категориальному менеджеру по канцтоварам. Маршрут сработал, заявка не потерялась, права доступа были корректны, алгоритм выполнился ровно так, как его запрограммировали.

Проблему обнаружил один вопрос: а мониторы он теперь тоже должен закупать?

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

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

15 уроков охватят все: от настройки интерфейса и трассировки трубопроводов до гидравлических расчётов, выпуска документации и работы с базами данных. По окончании – сертификат от разработчика и доступ к материалам на три месяца.

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

Меня зовут Дмитрий Неверов, я технический консультант в Бастионе. Занимаюсь пентестами инфраструктур на базе Active Directory. Сегодня хочу поговорить о постпроектной работе — том этапе, который начинается уже после завершения пентеста. Хотя примеры будут связаны с AD, тему можно переложить на любую другую область наступательной безопасности. 

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

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

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