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

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

Тогда, стоит напомнить, что магия вне Хогвардса запрещена 🙃

Я регулярно вижу одно и то же: в компанию вливаются бюджеты, заходят дорогие и не очень консультанты, рисуются красивые схемы (но, чаще некрасивые). Процессы переписываются. Люди — нет.

Процессы делают те же люди. С тем же уровнем мышления. С теми же ограничениями. Менять процессы, не меняясь самим — любимый корпоративный фетиш. Результат предсказуем: те же паттерны, те же решения, тот же «лебедь, рак и щука», только с новыми названиями.

Раньше можно было приписать «Agile», и добавить x100 к стоимости, сейчас лучше выбрать «AI». Хе‑хе.

Штат раздувается. Роли множатся. Ответственность размывается. Это как поменять море на океан, но продолжать плыть с дыркой в лодке.

Самое неприятное: вы ещё и платите за это 🙂

В публикации предлагается формальная математическая модель, связывающая накопленный Cost of Delay C(t) и остаточный Expected Monetary Value EMV(t) как взаимно обратные (комплементарные) функции относительно исходной ценности V₀. Показано, что для всех пяти канонических профилей CoD по Д. Райнертсену (Urgency, Fixed Date, Intangible, Expedite, S-curve) точка пересечения кривых CoD и EMV всегда лежит на уровне V₀/2, а отличается только скорость её достижения. Этот результат даёт руководителю проекта универсальный индикатор break-even задержки и основу для количественной приоритизации портфеля задач по WSJF/CD3.

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

За две статьи меня успели оклеветать: копирайтером, который вылез из тени своего спеца и ИИшкой:

Я руководитель проектов и у меня есть команда разработки продуктов. Аналитики исследуют и анализирует новые фичи, пишут спецификации. Есть разработчики и тестировщики. Есть DevOps, который чинит CI и выкатывает релизы. И даже есть технический писатель анализирует изменения и обновляет документацию.

Обычная продуктовая команда разработки.

Только людей в этой команде нет.

Все исполнители - AI-агенты…

Я формулирую проблему, описываю ожидаемый результат, задаю ограничения, выбираю приоритеты, принимаю или отклоняю результаты, разбираю спорные ситуации. А мои AI-агенты делают то, что обычно делают участники полноценной команды разработки.

Современные AI-агенты способны выполнять работу разных инженерных ролей, так почему бы не управлять ими как полноценной командой? А для управления использовать те же подходы, которыми мы давно управляем человеческими командами: Kanban, Scrum, Agile, Definition of Done, декомпозиция, pipeline, review, escalation.

Эта статья — про мой практический опыт такого подхода. Не про «AI заменит программистов». Не про «теперь можно не думать». И не про «вот магическая кнопка, которая делает продукт». Скорее наоборот: чем больше AI пишет кода, тем важнее становятся процесс, постановка задачи, спецификации, тесты, CI, документация и контроль состояния.

Моя рабочая практика сложилась таким образом, что почти всю жизнь я проработал в стартапах самых разных отраслей, и моей задачей было вывести компанию на приемлемый зрелый уровень. Здесь следует сразу обозначить, что именно я подразумеваю под стартапом, поскольку различных определений много. Итак, стартап - это организация, которая не понимает, что именно она делает, на чём она зарабатывает. Стартап - не обязательно молодой бизнес. Бывают компании, которые не выходят из состояния стартапа и 5 лет, и 10 лет.

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

Таблица 1. Стадии развития организации

Меня просто нечеловечески бесит, когда разработчики оправдывают собственную некомпетентность мантрой «бизнесу надо». Если программист любой степени квалификации, от стажёра — до принципала — использует в качестве аргумента в любой дискуссии фразу «бизнесу надо» — знайте, перед вами тупой самозванец, гоните его в шею. Звучит претенциозно?

Если погуглить «payment hierarchy», найдёте десяток исследований TransUnion за 15 лет. Они отслеживают одну вещь: в какой последовательности заёмщик с несколькими долгами уходит в просрочку, когда денег на всё не хватает.

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

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

У нас всё ровно наоборот.

От руководителя, точнее от его решений зависит в бизнесе слишком много.
Nokia, Motorola, Volkswagen, Tesla и другие больше компаний были или уничтожены, или потеряли репутация из-за действия именно руководителя.
Именно поэтому в MBA и EMBA так важно провести аудит тараканов мышления у руководства бизнеса.
Для этого я разработал простой тест из трёх вопросов.

1. Как правильно Молдавия или Молдова/ Алматы или Алма-Ата.

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

2. Почему большой внешний долг США - это не проблема для экономии США.

(госдолг США - это лакмусовая бумажка для понимания насколько руководитель понимает как работает экономика.
Вероятно, он даже не понимает, что кредит дают тому у кого есть деньги или в кого верят.
Ну или он пересмотрел телевизор, и тогда это вообще тяжёлый случай)

3. Почему атомная энергетика самая неэффективная и дорогая из всех видов.

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

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

Как сделать так, чтобы продукт или фича работала для пользователя? Ответ в этой статье.

Привет, на связи Саша Солдатов, CEO REB8T! Сегодня расскажу про четыре инструмента, которые наша команда использует в работе на каждом проекте: JTBD, ICE-приоритизацию, User Flow и UX-гипотезы.

Огромное спасибо нашему Lead UX/UI Вере Ксенофонтовой, которая собрала этот материал и разложила всё по полочкам для вас и нашей команды!

А теперь, начнём!

Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.

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

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

На связи Ольга, бизнес-аналитик в Outlines Tech. Расскажу, как я погружаюсь в новую задачу, чтобы составить техническое задание за 30 минут. По моей методике 80% работы над ТЗ — понять и договориться, 20% — зафиксировать всё в документ. Так не придётся торопиться и придумывать текст с нуля или вносить правки на ходу.

В программировании (как и в написании HDL кода и подобных профессиях) есть две школы мысли: чистолисты (строят свою архитектуру с чистого листа и пишут так чтобы поменьше отлаживать) и кодокопатели (отлаживают что есть, дополняя мусором из интернета, чтобы поменьше писать). На это накладывается менеджмент, который пытается комбинировать чистолистов и кодокопателей, иногда неправильным образом, то есть ставит чистолистов править то, что налабали кодокопатели. Это происходит потому, что кодокопатели постоянно выглядят занятыми отладкой, а чистолист часто смотрит в потолок обдумывая дизайн, поэтому менеджмент думает что первые работают быстрее чем вторые, и пытаются соптимизировать “быстроту-качество” вот таким образом. Реально кодокопательские проекты обычно увязают в отладке и прогресс становится черепашьим.

В издательстве Бомбора впервые на русском языке вышла книга о методе управления проектами P3.express. Как один из авторов публикую главу из книги в открытом доступе.

Привет, Хабр! Меня зовут Надя Скребец, я DevRel СВОЙ Тех.

Обычно здесь рассказывают про архитектурные победы, эпичные факапы или магию Kubernetes. Это круто, но за каждой строчкой кода и каждым релизом стоит человек. Сегодня я хочу показать вам CTO «Свой Банк» — Максима Гречихо.

Для многих позиция технического директора — это вершина карьеры, «финальный босс» в мире ИТ. Но какой вид открывается с этой вершины? Чтобы это выяснить, я буквально зажала Максима в углу между кофемашиной и переговоркой. Бежать ему было некуда, так что я воспользовалась случаем и заставила его поговорить со мной не о графиках и дедлайнах, а о том, почему современный СТО — это больше про смыслы, чем про синтаксис.

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

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

— В данный момент я занимаю позицию технического директора (CTO) в одном из ключевых проектов финтех-группы СВОЙ. Я узнал о группе от коллег и был поражен амбициозными целями банка, культурой компании и ролью ИТ в бизнесе. Желание стать частью такой команды возникло практически мгновенно.

Сейчас в мои обязанности входят управление всей ИТ-командой Банка, взаимодействие и активное участие в развитии бизнеса через наши кроссфункциональные команды, работа с ИТ-бюджетом, ФОТом и КПЭ. Планы у нас достаточно большие: Банк одновременно занят серьезной трансформацией ИТ-ландшафта, внедряя новую АБС и активно реализуя новые бизнес-сервисы. Это накладывает особую ответственность и необходимость очень профессионального подхода к управлению ресурсами, командами и проектами. Так что главный пункт — осуществить задуманное и реализовать все в сроки с нужным качеством. В дальнейшем, конечно, это развитие команды и ИТ-процессов.

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

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

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

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

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

В контексте Битрикс24 BI не отдельный внешний инструмент, а логичное продолжение CRM и бизнес‑процессов.

В ленте увидел пост о продукте «Супер Сплит» от Яндекс Банка: автор оплатил рассрочку в 21:15, через 15 минут после прописанного в договоре дедлайна 21:00, — и получил аннулирование льготного периода, пересчёт графика на 24 месяца и ставку 58,223% годовых, итого около 15 000 ₽ переплаты. И сделал вывод, что это сознательно спроектированный dark pattern, и банк закладывает невнимательных пользователей в unit-экономику продукта. 

Теперь разберем, что там под капотом на самом деле

Что происходит в 21:00

Утверждение «в 99% банков операционный день заканчивается в 23:59» неверно. 

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

Между ними стоит клиринг — банк-эквайер консолидирует платежи за последний час и зачисляем их одним платежом на счёт получателя. У крупных эквайеров последний клиринг проходит вечером — где-то в 21:00, где-то в 22:00. Всё, что списано с карты после этого времени, зачисляется на расчётный счёт уже следующими сутками.

Для бухгалтерского учёта датой платежа считается дата зачисления на р/с, а не дата списания с карты клиента. Это требование 402-ФЗ и базовая логика учёта по кассовому методу, а не намеренное изменение правил со стороны продукта.

Почему 21:00, а не 23:59

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

Завершаю рассказ о том, как и почему мы строили — Личный кабинет покупателя (ЛКП) и Корзину. С первой и второй частью можно ознакомиться по ссылкам, а мы переходим к заключительной серии.

Привет! Сегодня продолжу рассказ о том, как мы создавали Личный кабинет покупателя (ЛКП) и Корзину — инструменты, которых нет ни у одного агрегатора недвижимости.

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