Дзен ПМа

Всем привет что я вижу сейчас касательно происходящих изменений: - разработчик не пишет код, он оркестрирует агентов, его работа теперь: проектировать архитектуру, задавать права, границы и цели для каждого агента, проверять результат - код стоит сильно меньше, не бесплатно, конечно, но сравнительно зарплат разработчиков - на порядки дешевле - код и раньше не был самой затратной частью по времени, хороший разработчик в сложном проекте писал код 20-30% времени максимум, поэтому ожидать что проекты будут выполняться в 10 раз быстрее - наивно. - скорость ускорения нелинейна. Условный лендинг ускорился в 100 раз, а сложная система с интеграциями - в 1-2 раза пока максимум. Чем выше цена ошибки - тем меньше ускорение - Можно очень быстро делать херню и узнавать об этом намного позже, когда приходится разгребать говнокод от ИИ. Без долгой и кропотливой подготовки и создания нужного harness обвеса (то есть что может и не может делать агент, куда у него есть доступ и какие права, формулировки измеримых целей и результатов его работы и тд) - высокий риск получить неэффективную кодовую базу, которую потом долго и больно исправлять. Я читал что один разработчик оптимизировал в несколько раз количество кода, который написал ИИ и затраты токенов на работу с этим кодом упали в несколько раз - не стоит забывать, что чисто статистически, чем больше строк кода - тем дороже его обслуживать и тем выше шанс багов. Как говорил один скульптор, скульптура тогда идеальна, когда нечего отнять, а не есть чего добавить. Простота все еще является сложнодостжимой и наиболее эффективной. - Garbage in - garbage out все еще справедливо, если на вход ИИ подаете что то невнятное, то результат будет далек от желаемого. - Ижиниринг контекста перешел от оптимизации промтов в инжиниринг контекста для каждого агента, то есть стал масштабнее и сложнее ну и касательно работы ПМа: - стало легко получить информацию о любой части проекта - стало легко готовиться к разговорам с клиентом или менеджментом - решения все еще ответственность ПМа, как и контроль - теперь можно вести больше проектов одновременно, однако работу с командой ИИ не автоматизировал, а это достаточно большой кусок работы ПМа - ПМы без тех бекграунда сильно проигрывают теперь тем, у кого он есть. Даже Engineering менеджеры, которые какое то время назад перестали писать код - теперь снова его пишут с агентами. Наличие тех бекграунда позволяет намного быстрее быть в теме и не бояться командной строки. Так же сильно помогает знать как выглядит хороший результат с технической точки зрения. - Клиенты ожидают бОльшей подготовки ПМа и более глубоких знаний как работает AI SDLC (жизненный цикл проекта) и что ПМ может внятно обьяснить чем отличаются уровни AI assisted, AI augemented и AI native подходы. Удачи всем нам в это нелегкой время новой реальности) Отличного дня!

всем привет Очень давно мне хотелось сделать поиск по прошлым пресейлам, за последние пару лет, чтобы в клоде спрашиваешь "вот новый пресейл, что похожее у нас уже было, что мы оценивали?" и он тебе выдает что мол такой то пресейл, там было все вот так, вот что общее, вот как это оценивалось, вот что в итоге, выиграли или проиграли. Вроде бы задача то несложная на первый взгляд, тем более что базовые артефакты в пресейлах прошлых часто похожи, их три категории: входные требования + транскрипт звонка с продажниками, экселька с wbs и оценкой, пропоузал (КП) Не буду углубляться в тех детали, скажу сразу что в итоге - нельзя просто взять кучу доков, закинуть их в ИИ и ждать магию) несмотря на то, что ии умеет анализировать, но если дать ему не очень унифицированные данные - то его точность будет хорошо если 50-60%, то есть в остальных случаях на выходе будет разная степень бредовости, что сильно снижает пользу итогового продукта В моем случае мне сначала надо было прогнать кажды прошлый пресейл через определенное количество шагов, чтобы на выходе получить структурированный json и набор токенов (chunks) для векторной базы. Я прогнал штук 10 и понял что прогнать еще 100+ мне надо будет убить часов 20, проще уже сейчас все последующие пресейлы сразу делать с таким итоговым стуктурированным файлом, которые позволит использовать его как исторические данные с минимальным количеством галлюцинаций. Похожий опыт у нас был в проекте для банка где надо было классифицировать входящие документы (инвоис, чек, банковская выписка и тд) и несмотря на наличие примеров таких доков для каждой категории, точность все равно была на уровне 80%, что не сильно совпадало с ожиданиями банка, что будет магия. Оказывается, что для повышения точности нужно намного больше примеров и дополнительное обучение модели) Сейчас экспериментируем вести весь пресейл в репозитории, чтобы там были сразу все письма, прототипы, исследования по этому пресейлу синхронизированно для всех участников команды пресейла. Все равно все используют ИИ в работе над пресейлом, так почему бы не хранить все это в одном месте, а не в личном аккаунте каждого, что теряется по завершению пресейла. Пока такой подход по ощущениям очень даже неплохо, при соблюдении базовых правил работы с репозиторием, обновления статусов, коммитов и тд, чтобы не превращать в мусорку. Поделитесь, что у вас меняется в подходе к работе с клиентами как менеджер с помощью ИИ?

Всем привет Раньше в разработке как было: требования написали, тасочки нарезали, закодили, протестировали, собрали вместе в релиз, потестили вместе - и в люди. Сейчас как вырисовывается? Два крайних варианта и много оттенков среднего между ними. Первый - полностью автоматизированный процесс производства ПО. Человеки загрузили требования в беклог, а там дальше чудо агенты сами разобрали, закодили, потестили и задеплоили, все это по кругу (loop). Аналогия с "тёмной" фабрикой, где нет света, потому что роботам он и не нужен, они и так все видят. Понятно что тут надо построить обвязку всю сначала, как и на такой фабрике, то есть установить ограничения для агентов, права, правила, тесты, стат анализаторы кода, и так далее. Но потом оно все крутится и производит ПО. Но есть проблемка - не умеют модели в архитектуру, особенно если речь про сложное ПО в сотни тысяч строк кода, а если легаси - то вообще ж..а В итоге тесты все зеленые, а спустя какое то время - приходится платить долги, в данном случае речь про тех долг, и переделывать огромный кусок. Второй подход - темная фабрика та же, но в некоторых местах на линии все же включаем свет и смотрим, а не херню ли мы тут производим. Как минимум в 2х местах мы свет включаем: сначала в начале где кожаный должен завалидировать дизайн системы и архитектуру, проверить что план от ИИ подходит для решения, а затем разработчик смотрит PR'ы от ИИ перед тем как это пойдет в деплой, валидируя что получилось норм. Но тут тоже проблема - кожаный становится узким местом из-за ограниченного количества когнитивной нагрузки, которую он способен вывезти. Само собой это его ограничение очень сильно меньше объема кода, который может выдавать машина. В итоге это наше очень узкое место, ограничивающее производительность всей системы целиком. Зато тех долг не копится и можно быть уверенным что кожаный понимает как работает это ПО и где там что, чтобы в случае каких то экстренных проблем можно было оперативно по старинке знать куда ударить молотком, чтобы заработало опять. Ну и само собой между этими двумя есть бесконечность вариантов. Что-то мелкое и с низким риском можно оставить в темноте, что-то крупное с высоким риском смотреть со светом. Вопрос кто как определяет риск, насколько хорош весь обвес (harness) вокруг агентов, насколько сложный и старый код, насколько критерии приемки задачи можно описать в точных величинах которые хорошо проверяются машиной и так далее. Именно вариации ответов на такие вопросы создают все оттенки серого, про которые я говорил. Можно нырнуть глубже в эту кроличью нору и обсудить графы, состояния и флоу чарты, но я пожалуй не буду пока, оставим это разработчикам. Признавайтесь, все еще работаете с добавлением ИИ как копилота в классическом цикле разработки или все же уже ступили на острие прогресса в компании где вы работаете?

Всем привет перехожу к следующей метрике. Кстати, в эпоху ИИ метрики уже есть новые, как разберусь в них получше, тоже опишу, а пока продолжаем по известным и хорошо опробованным Lead time и Lead time distribution Время от создания тикета до его завершения. От cycle time отличается тем, что включает время ожидания в беклоге. График распределения показывает категории сколько тикетов в какой отрезок попадает (см скриншот) Что мы видим на скрине: - половина тикетов делается за 20 дней, - 85% тикетов делается за 43 дня - 95% тикетов делается аж за 67 дней Как это интерпретировать, то есть что это может значить. Опять предостерегу от быстрых выводов по одной метрике - это слишком мало информации чтобы делать выводы, это всего лишь указатель куда посмотреть поглубже Само по себе такое время - это очень долго, а в текущих реалиях непростительно долго. Это признак нестабильного деливери процесса. Здесь прямо сильно обязательно разбираться глубже в чем может быть проблема. Потенциальные проблемы исходя из такого графика (одна или несколько сразу): - команда не успевает брать задачи в работу, не хватает капасити - новых тикетов появляется больше, чем выполняется, некоторые тикеты ждут своей очереди очень долго (системная проблема) - нет SLA (то есть какого то лимита на ожидание) - есть маленькие тикеты, закрываются быстрее, в первую неделю и есть тикеты побольше, которые ждут дольше, чтобы их взяли в работу - Тикеты закрываются пачками к концу спринта или релиза независимо от того, когда реально закончена работа — отсюда пик около 12-18 дней и провалы между корзинами. - Смешение разных типов задач в одной метрике (баги vs фичи vs технический долг). У них разная естественная длительность, и сложенные вместе они дают бимодальное распределение. - Хвост — это тикеты, заблокированные внешними зависимостями (ответ клиента, доступ, стороннее API), низкоприоритетные задачи, которые постоянно отодвигают, или тикеты с расползающимся скоупом без переоценки. - Отсутствие WIP-лимитов — если в работе одновременно слишком много тикетов, они физически не могут двигаться быстро, отсюда растянутый хвост. Что делать дальше: - Разбить lead time по типу тикета (баг/фича/техдолг) — вероятно, увидите два четких распределения вместо одного смешанного - Разбить lead time на wait time (до старта) и cycle time (от старта до завершения) - Посмотреть отдельно на тикеты из хвоста (48+ дней) — обычно там небольшая группа с общей причиной (один блокер, одна команда, один клиент) Отдельно стоит упомянуть что если новых тикетов появляется больше, чем завершается, то график распределения не будет отражать реальность, получится что тикеты стоят в очереди почти столько же времени, сколько работаются. Тут стоит посмотреть график возраста тасок в беклоге и кумулятивную диаграмму потока. ну и график в динамике - он будет растягиваться все больше со временем. Растягивающийся хвост как на графике в скрине - как раз симптом такой проблемы. По закону Литтла: Lead Time = WIP / Throughput. Если входящий поток (arrival rate) стабильно превышает throughput команды, WIP растёт без остановки. А раз WIP растёт, растёт и lead time — причём не линейно, а ускоряясь, потому что каждый новый тикет попадает в очередь, которая уже длиннее, чем была у предыдущего. В заключение - lead time метрика не является основой для каких либо выводов, но помогает как дополнительная информация в наборе метрик, чтобы сделать верные выводы. Всем отличной недели!

всем привет давайте про метрики поговорим опять, возьмем первую из тула, что я шарил - Производительность по неделям например, пускай у вас есть вот такие показатели Закрытие vs поступление в неделю (из демо сценария на основе экспорта из разработки реального продукта) Неделя Закрыто 05/18 54 05/25 21 06/01 13 06/08 12 06/15 45 06/22 26 06/29 34 что мы имеем? в среднем получается примерно 26 тикетов закрывается в неделю. По идее мы можем использовать эту цифру, чтобы сказать что следующие 100 тикетов мы закроем за следующий месяц? Но есть нюанс. Наша волатильность, то есть разброс в каждую неделю - 70%, это значит что в конкретную неделю мы можем быть плюс или минус 70% от этих 26 средних и это делает утверждение про 1 месяц сильно сомнительным. Я бы не стал обещать 100 тикетов в месяц при таких условиях руководству или клиенту, сначала пошел бы разбираться что в процессе деливери приводит к такому сильному разбросу. Для того чтобы делать такие обещания волатильность должна быть не выше 20-40% иначе погрешность может быть высокая и вы сделаете в итоге 70-80 вместо 100 за месяц и будете выглядеть не очень хорошо перед лицом тех, кому вы это пообещали. При волатильность 20% вы сделаете больше 90 тикетов минимум (с большим шансом что и 100 и выше) и это будет хорошим результатом В данном случае примера проблема в длинном cycle time и узких местах, когда тикеты застревают в тестировании на много дней и долго ждут релиза. Прежде чем обещать что-то - стоит разобраться с этими проблемами и снизить cycle time в идеале до недели и меньше и/или уровень волатильности ниже 40% В вашем случае это может быть что-то другое, но такой разброс явно указывает, что вам стоит посмотреть глубже, в том числе посмотреть на другие метрики, делать выводы на основании одной единственной метрики - это почти всегда делать неверные выводы. Всем отличной недели!

всем привет Рынок аутсорса сейчас переживает кризис, каких я не видел за последние лет 15. Все потенциальные клиенты ждут обещанного ИИ волшебства, делают х..ню демо и прототипы на коленке, уверены что большое приложение должно стоить 10% от того, что раньше и делаться в 5 раз быстрее как минимум. Найм поменялся, теперь нельзя просто в линкедине выставить статус и смотреть там же вакансии - надо использовать сервис, который запустит ИИ агентов (платно) или построить такой самому (тоже не совсем бесплатно). Пока присматриваюсь к рынку и параллельно ищу клиентов на консультации и деливери аудит. Если кто забыл, я делаю менторские 1:1 встречи тоже, сейчас на это есть время. Внедрение ИИ в разработку, по моим наблюдениям, идет очень туго. Да, все уже используют ИИ для написания простых частей приложения, код стал дешевле и быстрее, но все что было до кода и после - все так же как и было раньше, все равно надо писать спеки, все равно надо понимать, что же в результате должно получиться. Да и код от ИИ нужно либо проверять либо выстроить такую обвязку вокруг (harness) чтобы не получился ..овнокод и количество прод багов не стало расти экспоненциально. Малым и средним компаниям такие изменения дорого и долго внедрять, как никак надо перестроить весь процесс производства, а это вам не шутки. Большие компании инвестируют в это активнее, само собой. Пока приходится наблюдать за перестройкой всего процесса производства софта и ждать пока эта перестройка как то устаканится и какие то подходы и лучшие практики выйдут на свет и будут приняты большинством, в том числе с точки зрение изменения управления всем этим добром. Буду сообщать вам о том, как проходит поиск клиентов и как проходит поиск работы. Всем отличного дня!

Запись вебинара готова, для удобства сделал 2 варианта: 🔗 ссылка на запись на ютубе - https://youtu.be/mjppQumYfls 🔗 ссылка на запись файлом на гугл драйве - https://drive.google.com/file/d/1-9jDMeNMVEz77NomT-WSfC1fAzTdTwSW/view?usp=sharing

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

UrbanBite-demo.csv

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

всем привет ну что же, демо приложения которое показывает деливери метрики и прогноз завершения на основе симуляции Монте-карло готов. https://forecasting-delivery.vercel.app/ создаете проект с любым названием и загружаете .csv файл, который я приложил, он сделан на основе анонимизированной выгрузки одного из моих проектов. Чтобы сделать свой - идете в jira в поиск по issues, выгружаете все таски со всеми статусами за последние 3 месяца и загружаете. Увидите баги или если с вашим экспортом что то не будет работать как надо - пишите мне обязательно, буду очень признателен. Важно - данные не уходят на сервер и вообще куда либо из вашего браузера. Бекенда нет вообще, все в браузере, все данные в полной безопасности только у вас. Даже аналитику не подключал, чтобы была максимальная безопасность данных. Жду ваш фидбек) Чуть позже запишу видео что там вообще отображается и что значит Переключалка языка EN/RU внизу

всем привет Отличная иллюстрация в вчерашнему посту. Продолжая работать над своим приложением для аудита деливери я нашел весьма интересный баг, допущенный ИИ. Итак, дано: в csv экспорте из JIRA есть колонка Log Work, куда записывается информация о времени, которое залогано в задаче. Нюанс в том, что время туда записывается в секундах, то есть 10 минут будет записано как 600. Но Клод сделал ход конём, он решил, что туда могут быть записаны как секунды, так и часы. Поэтому, рассудил он, если значение в этой колонке меньше 1000 - то это явно часы)) Почему? - патамушта для него это, видимо, логично В аттаче я заскринил его ответ и чистосердечное признание. Да, мне стоило начать с более глубокой и обстоятельной подготовке требований, описать каждую колонку из экспорта, ее ограничения и возможные значения, но я решил что это был бы перебор) В итоге я методично сам тестировал каждую итоговую секцию, правда не всегда есть возможность иметь эталонное значение, чтобы понять, где ИИ выдумало свою формулу с условными правилами. А теперь представьте, что вы пишете финансовое приложение, которое будет что то делать с реальными деньгами? Думаете будет просто и надежно? А если вы не эксперт в финансах - сможете ли вы доверять результату работы ИИ? Готовы чтобы такой софт использовал ваши деньги? Попросить ИИ сделать себе бота для торговли на бирже и дать ему свой реальный депозит? Ну вот и большинство серьезных клиентов пока не готовы вайбкодить серьезные приложения, но как минимум удешевления все же ожидают. Только попробовав сделать что то своими руками начинаешь лучше понимать, что есть на самом деле и что нет.

всем привет Пришла мне в голову идея сделать веб приложение, куда я могу загрузить экспорт из джиры и увидеть текущие метрики деливери, а также прогноз по завершению скоупа с помощью моделирования монте-карло. По результатам последнего деливери аудита я понял что такой инструмент сэкономил бы мне некоторое количество часов ручной сборки прогноза в эксель темплейте сижу я, значит, третий день с клодом и кодексом и понял одну вещь. Я когда то был разработчиком, посредственным, но тем не менее начинал еще в школе на basic и pascal, потом сам учил, потом работал разработчиком лет 5. То есть база мне хорошо понятна, даже несмотря на то, что разработчиком я был, честно говоря, посредственным. Однако поскольку я любил брать на себя ответственность и делать, то так в менеджеры и попал - никто больше не желал брать на себя бОльшую ответственность, а я не держался за написание кода) Но к чему я это всё. Кодить с ИИ прикольно и здорово, но по мере нарастания вещей, которые надо в приложение добавить и учесть - я снова ощущаю себя так себе программистом, потому что я знаю, сколько всего надо сделать и понимаю что это нифига не чуть-чуть повайбкодить и что с pro двадцатибаксовым аккаунтом я буду делать это еще очень долго. Никак не х..к, х..к и в продакшн, как обещает реклама и гуру в соцсетях. Мне кажется даже с 200 баксовым я бы сжёг еще очень много токенов пока получилось бы что-то, что не стыдно показывать) Возможно, мне надо еще поучиться как все правильно организовать и структурировать, но обещали же что теперь каждая домохозяйка может навайбкодить SaaS в два счет?) Человеку без такого бекграунда проще - он не знает о многих важных вещах и считает рабочий интерфейс законченным приложением. Пока не приходит в точку когда очередной промпт ломает что-то, что уже работало, он фрустрирует, откатывает на пару промптов назад и пробует снова (это реальный опыт из рассказа одного из клиентов, который потом пришел ко мне в пресейл сделать наконец нормально) В общем, не верьте всему тому, что говорит вам реклама и хайп. ИИ крутой тул, но его надо освоить. Причем не день, не два и даже не неделю. Замануха что пара промптов и вы на коне - сказки, максимум сможете демку дырявую навайбкодить с ходу. Опять таки, может это просто мое мнение основанное на моем долгом опыте работы в IT и я видел как надо, а другим "и так сойдет" и не важно. Однако если мы говорим про "один человек с командой агентов может сделать свой продукт приносящий миллионы", то тут, как говорится, есть нюансы. В теории может, но это не будет обычный человек, а скорее выдающийся во многих смыслах. Кстати, если когда я закончу (надеюсь за недельку будет внятная бета, которую мне будет не стыдно показать) вы бы хотели потестить мой инструмент со своими джира данными, то отпишите в комментариях, мне бы еще пару тестеров с другим джира воркфлоу не помешали бы. Всем отличной недели!

всем привет Когда мне приходилось делать аудит деливери процесса, обычно это происходило потому что руководство считает, что разработка проходит недостаточно быстро или не по плану. В процессе анализа чаще всего выясняется, что проблема не в самой разработке непосредтсвенно, а во всем, что просиходит до или после Для примера, что я видел: - cycle time (среднее время от взятия в работу и до завершения) только части процесса по подготовке требований занимает 2 недели, прежде чем задача будет готова к планированию в спринт - код ревью занимает 2-3 дня, деплой на стейдж - еще 2-3 в итоге задача от ее создания и до деплоя занимает в среднем около месяца. Это при том, что разработка занимает в среднем 2-3 дня Это среднее, само собой при все этом вариабельность (разброс времени) тоже достаточно широкий. К этому можно добавить влетающие срочные задачи, потери на переключения и псевдо скрам. Все это создает слабо предсказуемый пайплайн поставки задач и выполнение каких то планов на несколько месяцев можно считать случайной величиной) Такое положение дел вызывает логичное беспокойство руководства. Руководство не погружено в детали SDLC (жизненного цикла) разработки и не может самостоятельно решить вопрос. Получается ситуация когда верхи не могут, а низы тоже не могут. Тут как раз и полезна роль Деливери менеджера, который может проанализировать текущий флоу работы, узкие места и сделать поставку более предсказуемой, выстроить каденцию и обеспечить более эффективный поток. Процесс анализа: - интервью с ключевыми участниками разработки - ПМ, техлид, СТО, продакт/аналитик и тд - анализ таск трекера, например JIRA - выгрузка данных по задачам за последние пару месяцев, анализ приблизительных метрик потока, если есть достаточно информации и вокрфлоу более менее понятный, без откровенных костылей, с последовательным переходом между статусами до done - анализ встроенных отчетов трекера. В JIRA это - CFD (кумулятивная диаграмма потока) и Control Chart. Оба этих репорта должен обязательно уметь читать и анализировать каждый ПМ выше уровня джуниора (ну или понимать что спрашивать у ИИ по отчету) - анализ зон ответственности и точек передачи (RACI матрица если есть, если нет, то опрос участников) - анализ самих задач: полнота описание, наличие DoR и DoD - анализ процессе деплоя, покрытия тестами, процесса тестирования Это позволяет сформировать набор гипотез об узких местах процесса и их влиянии на поток работу. Далее валидируем каждую гипотезу погружаясь на уровень глубже, обычно с помощью интервью и получения дополнительных данных из других источников (например планы в google sheets и другие заметки вне трекера задач) В итоге получаем более менее понятную картину текущего состояния деливери процесса, с которой можно прийти к руководству и наглядно показать, что надо делать и как можно улучшить предсказуемость и прозрачность происходящего. Делается такой аудит в течении двух недель если не тратить на это все время, а по пару часов в день. В аудите хорошо помогает ИИ, особенно когда надо проанализировать выгрузку из JIRA или подготовить список вопросов для интервью из собственных заметок. В компаниях схожего размера обычно паттерны очень похожи, часто просто не хватает нужного человека или инициативы сверху, чтобы начать это улучшать. Всем отличного дня и наступающей недели!

всем привет как обещал, пишу чаще) неделю отдыхал и дорабатывал свой сайт с клодом, добавил кейсы, другую разбивку на страницы и переключалку на русский Клод за 20$ выедает 5ти часовой лимит за 15-30 минут, а покупать за 200 пока рано) Теперь об интересном: ИИ ускоряет. Причем если вы делали херню, то будете делать больше херни, теперь можно сделать быстрее беклог из никому ненужных фич и считать это успехом) То есть вопрос output vs outcomes снова становится важнейшим различием Раньше, когда код стоил дороже, приходилось думать и выбирать, на что потратить выделенное время и бюджет. Всякие техники приоритизации, оценка ценности и сравнение по этой оценке фич было важным занятием. Итерационная работа над фичами позволяла делать только то, что действительно нужно клиентам и пользователям. Сейчас можно делать весь беклог по цене его трети, и не важно что только треть действительно нужна. Проблема появляется потом, когда весь этот код надо поддерживать, даже тот, что не приносит никакой прибыли или пользы - а это значит больше расходов на токены и на регрессию. Логика что чем больше мы создаем, тем больше ценности это дает - неверна. Чаще всего мы создаем больше лишнего и ненужного, если продолжаем работать в старой парадигме. Все круто для простых продуктов и прототипов, но когда речь про сложные комплексные системы, усложнение путем добавления много нового только ухудшает показатели. Доказано, что увеличение выбора товара на полке больше определенного уровня делает людей несчастнее. Я думаю что это справедливо и для софтверных продуктов - еще больше функционала больше определенного уровня ухудшает пользовательский опыт

Всем привет Работа ПМа в этом году уже изменилась существенно, я ожидаю что она изменится еще сильнее в течении этого года. Администраторская работа ПМа по сбору статуса и отчетов уже не стоит ничего и легко автоматизируется. Что же остается? Глобально вопрос, на мой взгляд, звучит так: "В чем ценность того, что ПМ есть на проекте? Что это дает клиенту, команде, менеджменту?" ну или "как присутствие ПМа позволит заработать или не потерять больше денег, чем затраченные на него деньги?" Если вы знаете ответ на этот вопрос - то вы сможете позиционировать себя на рынке и продавать свои навыки управления проектами. Что ПМ может дать и должен давать/делать сейчас? 1) работа с людьми - это работа с командой и ресурсами в общем, управление ожиданиями стейкхолдеров, коммуникация с ними всеми. 2) работа с рисками - да, работа ПМа всегда была работа с рисками проекта, в самом широком смысле. Сейчас изменился список и приоритет рисков, но тем не менее, они есть и их все так же много. Сейчас бОльший приоритет в управлении неопределенностью через управление рисками. ИИ может показать риски, но человек решает, что с ними делать, какую стратегию выбрать, какие действия предпринять. Ценность PM здесь: не обнаружить проблему, а превратить ее в решение. 3) Решения по проекту, которые влияют на бизнес ПМ должен выходить за рамки delivery и понимать бизнес-контекст, ценность, ограничения и последствия решений. То есть даже собрав все статусы и информацию с помощью ИИ - такой отчет надо интерпретировать и подтвердить как это влияет на ограничения проекта (бюджет, сроки и тд) “Мы не успеваем к 15 мая. Есть три варианта: сократить scope, добавить людей, или сдвинуть release. Я рекомендую сократить scope на X, потому что это сохраняет основную бизнес-ценность релиза.” 4) PM должен понимать не только “что делаем”, но и “зачем”. Сильный PM задает вопросы: -какая фича реально нужна для запуска -что можно отложить -где клиент тратит бюджет без эффекта -какой scope несет максимальную ценность -где команда делает technical work без понятного business reason 5) Не управлять задачами, а принимать решения Хороший PM ведет decision log и двигает проект через решения: -какой payment provider выбираем -что входит в MVP -какие edge cases закрываем сейчас -какие compliance items обязательны -какой release scope фиксируем -какие дефекты блокируют acceptance AI может помочь собрать контекст. PM должен добиться решения. Само собой использование ИИ - это уже обязательный навык, типа как "уверенный пользователь ПК" было раньше) PM нужен там, где есть неопределенность, конфликт интересов, зависимость от людей, нехватка информации и необходимость принимать решения. AI крут в обработке информации. PM ценен в принятии решений и ответственности за них. Я бы сформулировал ценность PM теперь так: PM превращает хаотичную работу команды, клиента, требований, рисков и ограничений в управляемый процесс, где бизнес понимает, что происходит, какие есть риски, какие решения нужны и чего ожидать дальше. PM = delivery operator + business translator + risk manager + decision driver + AI-enabled coordinator. В итоге, можно использовать следующее позиционирование: Реальная ценность PM — в том, чтобы проект оставался управляемым: риски были видны заранее, прогнозы строились на данных, клиент понимал последствия решений, команда не работала в хаосе, а delivery был связан с бизнес-результатом. Всем отличной недели)

всем привет ну что ж, как обычно (не в первый раз такое в моем долгом опыте), моя позиция, как не биллабл оказалась слишком дорогой в условиях очень слабых продаж в этом году (1 лид в месяц по сравнению с 10-15 в месяц в прошлом, а я как раз отвечал за пресейл) и мне сказали что не могут меня больше позволить, потому что компания уходит в режим выживания и экономии. Во всем виноват, само собой, ИИ, который полностью развалил рынок Как раньше разработку никто не покупает, а как сейчас - никто пока не знает толком - слишком много хайп шума и офигительных историй про то теперь все просто и легко в клоде) Для вас это, несомненно, плюс, потому что теперь у меня будет время чаще писать сюда интересные (как я думаю) истории и опыт. Сидеть на диване просто - не мой подход, поэтому я занырну глубоко в дивный новый мир ИИ разработки и возможностей. Начал я с создания лендинга для своего оффера услуг частичного Деливери менеджера для компаний, которые не готовы к ПМО и к тому чтобы нанять себе фуллтайм хеда деливери или пмо, но хотели бы навести порядок в своих проектах где все ведется сейчас "как выросло" и не очень стабильно, поэтому готовы к внешней парт тайм помощи или аудиту. Лендинг я буду еще итерировать и улучшать, пока эта версия не видится мне оптимальной, но для начала сойдет. https://alexbelkavets.pro/ Так что если у кого есть такая необходимость - смело пишите мне) А я обещаю вас радовать новыми интересными постами и, возможно каким нибудь воркшопом в ближайшее время) Отличных выходных!