Дзен ПМа

Всем привет

С мая я работаю на частичной занятости, благодаря тому что ИИ меня уже почти заменил)
Поэтому тема "а что дальше будет с проджектам и деливери?" для меня стоит остро и актуально. Ну и тревожно, так что буду тут рассуждать, присоединяйтесь в комментах, не стесняйтесь.

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

Теперь это никому не надо. Если команда состоит из 2-3х человек (там где было 10+) - зачем им скрам или канбан? Потерями на координацию в такой команде тоже можно пренебречь, они малы.

Мультиагентную "фабрику" производства ПО, где теперь происходит весь процесс, к которому ПМ применял аджайл свой, менеджер не настраивает и не адаптирует, это задача кого то из сеньорных технарей.
Требования ПМ не собирает, репорты ручками не генерит, планы не составляет, что там у нас еще то было?

Тот же треугольник взять:
1) обьем работ напишет ии от начала и до конца, не важно чей ии, ПМа или клиента, останется его согласовать разок
2) сроки - ИИ оценит срок изначальный, дальше на основе реальных данных будет хоть каждый час пересчитывать его на основе скорости прогресса и методов стат моделирования
3) бюджет - тоже самое, ИИ оценит и будет отслеживать потом сам
Причем, когда я говорю что ИИ оценит, абсолютно не важно насколько он будет прав первые разы - на 10й, условно, раз он уже будет оценивать по историческим данным намного точнее, чем кожаные оценивали с своим 10ти+ летним опытом, то есть он будет все лучше это делать с каждым разом.

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

Так и что, получается, как говорил комиссар в фильме "такси" - "мы в жопе!" ?
Вполне возможно что и так, но по другому выражению "даже если вас съели у вас все равно есть один выход", так что вопрос как мы из нее будем вылезать чтобы она не стала символом вечности.
Кстати, если вы сейчас работаете как ПМ или Деливери, то это просто потому что компании достаточно консервативны и изменения в более менее крупных компаниях происходят невероятно медленно в основном, не надейтесь что вас пронесет)

что из вариантов на вскидку:
1) становится Product Engineer, то есть смесь продукт менеджера и немного инженера с помощью ИИ, чтобы генерить продуктовые идеи и быстро проверять их
2) становится GTM Engineer, то есть смесь сейлс, маркетинг + ИИ
3) становится сейлом, но с глубокими знаниями ИИ и желательно тех бекграундом, чтобы поддерживать с клиентом разговор про то, какие инновационные технические и ИИ подходы ваша команда может предложить клиенту и какой солюшен вы видите в его случае
4) похожее на предыдущее, но в роли аккаунт менеджера
5) ваш вариант, делитесь, мне интересно

Первые два стоит погуглить, это первые ласточки, после вот этих FDE (Forward Deployed Engineer), не факт что и эти роли проживут долго, но направление они показывают

Я пока буду размышлять дальше о том, какое место может быть у меня в этом новом дивном мире, слушая очередную лекцию про то, как новая модель изменила все правила, которые мы применяли для старой)
Отличных выходных!

всем привет

Очень много времени сейчас уделяю изучению как работают "фабрики ПО" (software factories) и что такое харнесс (harness) для модели (например Claude Code - это харнесс для моделей от Anthropic)

Если с разработкой все чуть больше вырисовывается, да даже с продуктовым менеджментом тоже, то вот с проектными менеджерами все очень грустно пока выглядит.
Если ПМ был нужен для контроля рисков проекта, то сейчас если команда на 10+ разработчиков а 3 - то тут как бы и риски невысокие.
Технические риски можно и без ПМа контролировать, как и беклог и отченость - автоматизировано.
Что остается? - общение с клиентом. Но тут много ролей, кто может общаться с клиентом, получая статус разработки просто общаясь с ИИ. Да даже клиент может спросить у ИИ чё там происходит у ребят разработчиков.
Те, кто силен в пресейле, имеет доменный опыт и сможет сфокусироваться на бизнес части работы - могут найти свою нишу в этом ИИ шторме.

Я вижу что позиция ПМа если и останется, то будет означать совершенно не то, что она означала еще 1-2 года назад. Понятно что компании будут долго переходить и те, кто сейчас работают ПМами будут либо менять с компанией или попадать под сокращение за ненадобностью. Первыми под удар попадают ПМы в аутсорсе, само собой.
Это не хорошо и не плохо, это просто факт происходящей трансформации.

Если вы без работы, то рекомендую изучать все, что возможно про ИИ разработку, агентные системы и думать, как вы можете это применить и где, делать какие то пет проекты и завести себе тоже гитхаб и начать его использовать)

вот вам пару ссылок полезных в заключение
1) https://github.com/walkinglabs/learn-harness-engineering - про харнесс, есть русский язык
2) https://academy.claude.com/courses/ai-native-sdlc-playbook - ИИ нативный жизненный цикл проектов от антропиков
3) https://www.news.aakashg.com/p/graphs - про графы
4) https://github.com/github/spec-kit/blob/main/spec-driven.md - SDD (spec driven development) то есть разработка по спекам для ИИ

отличного дня!

всем привет

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

Еще пару мыслей о ближайшем будущем, что я наблюдаю и с чем согласен
- Не будет ни код ревью, ни юнит тестов, просто за ненадобностью
- Умение писать код ручками станет прикольным хобби, примерно как шить одежду дома самому или делать себе обувь.
- слопа будет много, но все что никому не нужно быстро отомрёт, а то что нужно будет очень быстро меняться
- токены - новая нефть, топливо и вообще повсеместный ресурс типа электричества: хочешь сам крути динамо машину на локальной модели, хочешь - получай по проводам от станции (датацентра)
- логичное продолжение этого - у кого хватит денег на токены то и молодец и вообще, у кого не хватит - будет работать на заводе, условно
- хороший код будет как итальянская обувь ручной работы - красиво, уникально и 99,9% людей нафиг не надо. И чем дешевле токены тем меньше будут об этом думать.
- умение выделять главное, быстро адаптироваться и понимать что нужно бизнесу растет в ценности огромными темпами (отчасти потому что остальные скиллы обесцениваются так же быстро)
- залетные люди в айти, которые там не по зову души и не готовы посвящать этому каждый день уйдут или просто не смогут найти работу после сокращения

Сидел сегодня смотрел по каким запросам в ИИ наша компания появляется в ответах ИИ и где бы надо написать еще контента, много интересных стартапов на самом деле
вот этот тестирую сейчас на эту тему:
https://lightsage.com/

Я это делал пока ждал чтобы оркестр агентов сделает оценку проекта и подготовит мне драфт proposal (КП). А еще буквально недавно я часами сидел собирал слайды из темплейта в какой нибудь фигме, мда.

Хорошей недели!

Всем привет

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

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

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

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

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

Удачи нам всем в этом прекрасном новом мире)

всем привет

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

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

Проблема усугубится с ростом стоимости токенов - от СТО все больше будут требовать гарантий или подтверждения того, что эти траты положительно повлияют на прибыль, а СТО таких гарантий дать не может. Лучшее что он может - это пообещать что тасок начнут выполнять в разы больше, а остальное не в его зоне ответственности.

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

Много ИИ кода приводит к накоплению проблем в перспективе - перегруженные интерфейсы, тех долг, проблемы с архитектурой, рост стоимости токенов и тд.

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

Всем привет

почитал я тут на досуге подход к AI native жизненному циклу проекта от Антропик.
Что я вам могу сказать?
взяли каждый классический этап и предложили делать его в их продукте - Клоде
требования - поговорите с клодом
дизайн - закиньте требования от клода с предыдущего этапа в клод дизайн, он вам нарисует
разработка - возьмите требования от клода и попросите клод код сделать план, затем запустите агентов от клода выполнить план
тестирование - запустите агента проверить результат
и тд.

ну и между строк там - сделайте CLAUDE.md с правилами и не забудьте все это хранить в гите.

Если ничего особо не знать про ИИ разработку - то для старта норм, но лучше все же посмотреть в сторону SDD (Spec Driven Development), например от Gihub - это следующий, продвинутый уровень

кто еще не видел и сам хочет почитать AI native SDLC от антропиков, то вот
https://academy.claude.com/courses/ai-native-sdlc-playbook

Всем отличной недели!

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

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

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

В частности, вы узнаете:
- как быстро понять где узкое место процесса
- как быстро посчитать какой у вас сейчас lead и cycle time
- сколько задач/часов из оценок/стори поинтов вы сейчас закрываете в неделю
- какой сейчас у вас график план vs факт и какие задачи заняли больше всего времени относительно оценки
- сколько задач в каждом статусе
- какая сейчас эффективность потока
- какой разброс возраста тасок
- количество открытых тасок - растет или уменьшается
- дата завершения текущего скоупа на основе метода стат моделирования Монте-Карло (10,000 симуляций)

Все это совершенно бесплатно, без подписок и смс, что называется.
Учитывая лето и выходные на природе - предлагаю вечер четверга.

⏰ Дата: Четверг 2е июля 20:00 (по Минску)
место: зум
https://us05web.zoom.us/j/83191623207?pwd=k7BwlfPY0RKQ82sYyfgwp6GYuLim8i.1
Passcode: 6fQuUJ

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

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

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

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

Например: изменился планируемый бюджет и надо подтверждение клиента? ПМ должен рассказать причины, описать план по коррекции причин (если она не разовая), описать текущие риски бюджета, как они изменились. Клиент должен понимать, насколько увеличился бюджет, какой риск того, что он продолжит увеличиваться дальше, есть ли план коррекции и тд, чтобы принять обоснованное бизнес решение.

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

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

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

всем привет

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

https://forecasting-delivery.vercel.app/

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

Чтобы сделать свой - идете в jira в поиск по issues, выгружаете все таски со всеми статусами за последние 3 месяца и загружаете.
Увидите баги или если с вашим экспортом что то не будет работать как надо - пишите мне обязательно, буду очень признателен.

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

Жду ваш фидбек)
Чуть позже запишу видео что там вообще отображается и что значит

Переключалка языка EN/RU внизу