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

Почему одни идеи превращаются в востребованные продукты, а другие так и остаются красивыми презентациями — или мемами про очередной B2B AI SaaS? Часто проблема не в технологии и не в качестве реализации. Команда может отлично сделать то, что пользователю на самом деле не нужно.

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

Меня зовут Лера, я технический писатель в Авито. Я продолжаю разбирать книги, идеи из которых помогают по-новому посмотреть на работу, команды и создание продуктов. Сегодня поговорим о книге Тима Брауна «Дизайн-мышление в бизнесе».

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

Вы уже брали когнитивный долг

Представьте, что вы руководите проектом. Аналитик Вася присылает двадцать слайдов, которые сегодня (а на самом деле вчера) надо показать клиенту. Общая логика вроде ОК, ключевые цифры разумные. На 17-м слайде есть результаты расчета, на проверку которого, по-хорошему, уйдет день. Вася говорит, что все проверил.
Можно попытаться перенести встречу. А можно решить: достаточно, Вася выглядит адекватным, риск небольшой, идем к клиенту.
Если вы были в похожей ситуации – вы уже брали когнитивный долг.
И никакого искусственного интеллекта для этого не требовалось.

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

Начальник не повторяет все вычисления сотрудника. Архитектор не читает каждую строчку каждого сервиса. Главный редактор не перепроверяет каждый факт так, как это делал автор. Партнер консалтинговой фирмы не строит своими руками каждую модель, которую показывает клиенту.
Более того, если заставить его все это делать, организация перестанет иметь экономический смысл.
Поэтому вопрос — не «есть ли у нас когнитивный долг?»
А два других: сколько его у нас и достаточно ли мы контролируем риск? 

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

Илон Маск как одержимый выпускает на рынок все новые модели своей нейронной сети Grok, и 12 августа уже стала доступной версия 4.6, но, хотя он постоянно подчеркивает, что его детище является максимально правдивым ИИ, правдивость ответов Grok в некоторых случаях не обеспечивает. Это не случайно – в модели содержится принципиальный дефект – она не владеет научными правилами отличия правды от лжи и заблуждений. Чтобы исправить этот дефект, к алгоритмам обучения SFT и RL следует добавить новый – НРД.

Несколько лет назад Илон Маск захотел создать альтернативу ChatGPT – нейросеть TruthGPT, в которой упор был бы сделан на поиск правды, однако что-то пошло не так, и у него получилась в 2023 году нейросеть Grok, у которой из-за минимальной цензуры существует значительный риск воспроизведения непроверенных данных, поэтому ее пользователям рекомендуют обязательно проверять факты.

Тем не менее, сам Илон Маск постоянно подчеркивает, что его детище является максимально правдивым ИИ, даже если эта истина иногда противоречит общепринятой точке зрения или политкорректности. Да и название нейросети, которое взято из романа Роберта Хайнлайна «Чужак в чужой стране», там использовалось в смысле интуитивного, глубинное понимание чего-либо. То есть претензии на правду остались, несмотря на другое название.

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

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

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

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

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

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

Недавно я нашёл старый черновик статьи, которую так и не опубликовал с 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 года я пересобрал принципы работы, и получилось обещать и чётко выполнять сроки внутренним заказчикам, реалистично оценивать важность фичей, не пропускать стратегические вещи, контролировать, кто над чем и насколько эффективно работает, прямо реально видеть каждый статус каждой задачи. И бизнес, и я, и команда почувствовали, что стало понятнее и лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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