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

Если погуглить «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 — это дедлайн, к которому привыкли пользователи банков, погашающих свой же кредит со своего же счёта в этом же банке. Когда клиент платит по кредиту Сбера со счёта в Сбере, внешнего клиринга нет — это внутрибанковская проводка, она проходит мгновенно.

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

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

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

Всем привет от Петра Третьяка, который за 10 лет в управлении проектами ни разу не видел, чтобы крупный релиз вышел ровно в ту дату, которую назвали на старте. Ни разу. При этом все на старте в эту дату верили: и заказчик, и команда, и я сам.

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

Но с каждым днём кубики становятся мельче, а модели — сложнее и реалистичнее. Работа требует всё больше концентрации и времени.

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

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

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

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.

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

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

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

Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.

И это не исключение. Это нормальное состояние большинства организаций.

Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».

В IT разработке результат дает не один человек, а команда. А в любой команде (даже если она работает на полной удаленке) будут отношения. А где есть отношения, там есть манипуляшки.

Мир неидеален, на солнце есть пятна, не все проекты делаются в срок, начальники орут, исполнители молча соглашаются с невыполнимым и доблестно выгорают - короче, все неидеально.

Но если все так, то как сохранить себя в этом бардаке, как работать максимально эффективно с совершенно разными людьми?

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

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

Итак, поехали!

Этот текст о применении ИИ-агентов для задач управления проектами.

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

Иными словами, ИИ-агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.