Дзен ПМа

всем привет

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

Итак, дано: в 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/

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

Отличных выходных!

всем привет
кстати, на основе моей матрицы скиллов для деливери/проджект менеджеров я сделал страницу для самостоятельного определения уровня по разным скиллам. С помощью клод кода конечно же)
Выложил вот сюда, пользуйтесь, потом русскую версию прикручу
https://alxbelkavets.github.io/delivery_manager_assessment/dm-self-assessment.html

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

из свежего дока, начинается:
"Developer Build Brief — Honest Edition
What to build, what to skip, and how to ship without fake promises"
и заканчивается
"Build something useful first. Make it intelligent second. Make it exceptional with real data.
Build smart. Ship real. Earn trust."
лозунги какие то одни
в середине фразы "The website says a lot. Some of it is real today. Some of it is a future vision. Your job as a developer is to
know the difference — and never ship a feature that is fake."

ну хоть высокоуровневый список фич есть и на том спасибо.
если всю воду слить, можно было из 10 страниц сделать ровно одну или две максимум)

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

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

Spec driven development, когда сначала пишем спеку, потом уже подключаем агентов - сейчас набирает обороты, то есть наш любимый каскад (waterfall) снова живее всех живых)
Сам сижу разбираюсь с клодом, смотрю часы видосов, делаю лендинги рабочие, чтобы самому понимать что да как - и это далеко не так просто, как показывают в рилсах и твиттерах, ощущение что я снова учу программирование заново, но в моем случае есть бекграунд в разработке, а у кого нет - тем явно в разы тяжелее сделать что-то рабочее.
Реальность что без знаний как происходит разработка с ИИ дальше в IT все больше нечего будет делать, так что рекомендую преодолеть внутреннее сопротивление и начать хотя бы по чуть чуть, пока стоимость токенов не полетела в космос, а то тогда еще сначала придется разбираться как поставить локальную модель)
Всем отличной недели!

всем привет
тема про БА залетела, давайте продолжим
Сравним два подхода, "как всегда было" и AI-first

Разработка требований:
было: БА/ПМ собирают требования, передают команде в виде юзер-стори, сценарии использования (use case) и прочие полотна в конфлюенсе
стало: Требования становятся многоуровневыми: intent, domain rules, constraints, examples, contracts, acceptance logic

Спецификации:
было: Спецификация нужна, чтобы все в команде одинаково поняли задачу
стало: Спецификация становится primary artifact: из нее рождаются agent tasks, тесты, policy checks, контракты и часть реализации
Здесь спецификация становится источником исполнения и верификации.

Тестирование (докину, хоть и не касается БА)
было: Test pyramid + отдельная QA-фаза
стало: Verification mesh: unit + contract + property + scenario evals + regression sets + canary + runtime assertions

Планирование:
было: Планируются задачи и делаются оценки
стало: Планируют не микрозадачи, а цели, контекст, границы, риск, evals, критерии эскалации и ownership

Документация:
было: Отдельные документы, часто устаревают, надо создавать и поддерживать
стало: Docs живут рядом с кодом и спецификациями; решение, контекст и критерии проверки версионируются

SDLC
было: roadmap → PRD → backlog → sprint → implementation → QA → release → bugfixing
стало: Два контура
1. Контур продукта / бизнеса цели, приоритеты, риски, KPI, domain constraints.
2. Контур delivery context pack → spec → evals → agent execution → verification → human decision → release.

Работа с требованиям:
Было: Требования обычно проходят цепочку:
- бизнес-цель,
- PRD / BRD,
- user stories,
- acceptance criteria,
- уточнения по ходу реализации.
Стало:
Требования превращаются в структурированный контекст, а не просто в описание задачи.
Обычно они раскладываются на слои:
- Business intent — зачем это изменение нужно.
- Domain rules — какие правила домена нельзя нарушать.
- Constraints — security, compliance, latency, cost, UX, data constraints.
- Interfaces/contracts — API, schema, events, state transitions.
- Examples / counterexamples — позитивные и негативные случаи.
- Acceptance logic — как именно будет определено, что решение годится.
- Risk tier — насколько опасно изменение.
- Escalation path — где AI останавливается и нужен человек.

Как видно, роль БА (и не только эта роль, само собой) должна измениться кардинально, чтобы продолжать приносить ценность. Старые документы а-ля Vision&Scope или SRS/FRS уходят в прошлое в том, виде, в котором они есть сейчас

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

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

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

Всем привет
поговорим снова про пресейл
типичная Дискавери фаза, которую продаем:
- сбор требований для MVP
- кликабельный прототип
- высокоуровневая архитектура
- питчдек для инвесторов (опционально)
- какой нибудь Vision & Scope документ
- оценка сроков, стоимости и обьема работ для MVP (обычно от 3 месяцев и больше)

чем дальше, тем больше это ощущается архаично и устаревше.
Я планирую попробовать новые предложения, например
1) 72 часа до результата
- работающее ИИ демо/PoC
- ключевое УТП и цель продукта
- ключевые риски и допущения
- рекомендованый путь дальнейшей разработки
- примерная стоимость и длительность первой версии (MVP)

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

2) Стартовый спринт (1-2 недели)
- продуктовая гипотеза, цель и метрики
- анализ продуктовой идеи (lean product concept)
- ии прототип/демо
- высокоуровневая архитектура полной первой версии
- план разработки на первые месяцы
- примерная стоимость и длительность первой версии (MVP)

по сути, Дискавери, но переупакованная на более современный лад

3) Пакет для инвестора (1-2 недели)
- красивый рабочий ИИ прототип
- проработанный главный/основной путь пользователя
- архитектурный план
- питчдек для инвесторов
- примерная стоимость и длительность первой версии (MVP)

для тех, у кого в приоритете пойти к инвесторам в самый короткий срок со своей идеей

4) Быстрый запуск (1-2 месяца)
- небольшая, но уже полностью рабочая первая версия, с самым минимальным обьемом фич (желательно один основной путь пользователя), которую можно выкатывать в прод
- план на следующую версию, со стоимостью и сроками
- беклог на следующую версию
- метрики успешности продукта и встроенная аналитика использования
- архитектура заложена с учетом будущих фич
- минимальная документация

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

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

всем привет
у меня оформилось наблюдение, которым хочу поделиться.

итак, немного кликбейта: Команда умерла - да здравствует команда!)

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

берем классическую команду на аутсорс проекте: ПМ, БА, разработчики, диз и девопс
Пм админит, БА собирает требования и оформляет их таски, разработчики пишут код, потом с помощью девопса это идет в какое то нужное окружение.
четкое разделение ролей, все вроде понятно и знакомо

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

Решает ли он реальные задачи клиента? примерно с таким же успехом, как и без ИИ.

Фокус смещается с вопроса "как это сделать", на вопрос "что именно делать и нафига?"
Output vs Outcome, не новая история, просто раньше что то проверять, тестировать было долго и дорого - и это было главной отмазкой, поэтому дальше PoC (Proof of Concept) прототипов дело редко доходило и все делали большой релиз от 3х месяцев до 9 месяцев и потом бета тестировали результат.
Сейчас это уже выглядит архаично и неэффективно

На сцену потихоньку выходит команда нового типа - Builder team, то есть команда строителей, так сказать
Это небольшая команда, которая полностью владеет процессом от идеи до реализации и проверки результата в реальном мире, с помощью кардинально другого подхода к организации работы.
Вместо большой ставки и большого релиза - маленькие релизы, которые быстро проверяют гипотезы, быстро итерируют и измеряют непосредственный бизнес результат, а не количество поставленных фич. Все как проповедовали последователи Аджайла все эти года)
Да, такой команде нужно больше автономии, поэтому их создание очень сильно тормозится существующей организационной структурой. ИИ история, она не про инструменты, а про культуру и инерционность принятия изменений людьми.
Требует изменения фокуса ответственности с количества строк кода на бизнес результат.
Перехода от "что хочет заказчик" на "что хочет клиент заказчика", больше ответственности, которую мало кто хочет на себя брать.
К сожалению без этого есть риск все сильнее отставать от тех, кто готов.

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

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

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

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

всем привет

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

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

Итак, пришел клиент с запросом, нам надо для него придумать решение (solution), для этого мы уточняем требования, собираем тех команду, описываем обьем работ (scope) и оцениваем его. Потом накидываем риски и оформляем в коммерческое предложение (proposal)
Пока все просто и логично, НО качество солюшена зависит от: экспертизы тех команды, достаточного уровня информации для его формирования и нашего "аппетита к риску", то есть насколько мы уверены в своих силах, имеем релевантный опыт и умеем выполнять такие задачи - в виде списка рисков, который мы как то оцениваем и добавляем к голой оценке тех команды.
Это значит что нам надо
- повышать экспертизу команды оценки
- упаковывать предыдущий опыт в виде кейс стади для добавления в КП
- не жадничать с рисками за счет улучшения процесса деливери и работы с клиентом

Вот уже все сложнее. Дальше - больше.
- Нельзя просто взять хорошего разработчика для оценки, надо брать solution architect, то есть человека, который сможет придумать наиболее подходящее техническое решение, обосновать его, предложить альтернативы (например, разработка с нуля VS взять готовое опенсорс решение и кастомизировать), написать валидные допущения (asssumptions). В крупной компании это отдельная роль в пресейле для специального опытного человека, роль может называться solution acrhitect, presale engineer и тд. В компаниях поменьше для такого привлекают техлида, с наиболее близкими нужными скиллами. Поскольку такой человек должен иметь обширный и глубокий технический опыт, а также отличные коммуникативные навыки - найти его не так то просто.
- с кейсами все обычно проще, маркетинг и дизайнеры это могут достаточно хорошо, по крайней мере у меня проблем с этим не было ни в одной компании
- с буфером на риски сложнее. Производство хочет заложить комфортный для них уровень буфера, который часто делает финальный бюджет не очень конкурентноспособным там, где есть конкуренция или мы пытаемся выиграть проект, где у нас мало или вообще нет релевантного опыта.
Тут в ход идут подходы такие как: уменьшить буфер, но обложиться допущениями; дать низкую цену на первую фазу в надежде добрать на следующих фазах; привлечь стороннего эксперта (SME) с релевантным опытом для ревью и пересмотра решения и тд

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

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

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

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

ИИ все больше меняет ландшафт и это ощущается. Невозможно больше делать вид, что это просто игрушка.
Например, в работе со стартапами, классическая дискавери фаза, когда мы создаем большие документы требований, такие как Business Requirements или Vision & Scope, перестает быть ценной.
Вместо этого мы делаем намного более простые документы, а в остальное время создаем ИИ прототипы, которые хоть и сырые, но все же дают возможность намного быстрее получить обратную связь от рынка. Не кликабельные фигма дизайны, а непосредственно приложения, которые можно отправить в google play или appstore, разместить на сайте и запустить целевых бета тестеров.
Да, вопросы с регуляциями, комплайенсом и даже безопасностью иногда, остаются не до конца покрытыми, но для стартапа скорость проверки продуктовой гипотезы намного ценнее чем идеальный результат.
В текущей компании мы уже предлагаем такую услугу нашим потенциальным клиентам, кто приходит к нам с идеей. Часто это просто эксперты в своей области, далекие от технологий и IT продуктов.
Инвесторы тоже в тренде и ожидают не просто картинки и описание, а что-то, что можно пощупать и быстро проверить.

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

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

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

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

Как говорил один персонаж Алисы в стране Чудес - "надо очень быстро бежать чтобы просто оставаться на месте".
Всем отличного дня

всем привет
немного наблюдений и рассуждений о работе в аутсорс проектах и продуктах

В аутсорсе ценность - это сколько задач из wbs закрыто за итерацию/спринт. Цель - сделать весь обьем работы (скоуп) в заданные сроки, чтобы клиент был доволен. Фокус на предсказуемой поставке (деливери) какого то обьема фич. Ценность для конечного клиента фигурирует в разговоре, но обычно выбор как эту ценность дать клиенту принадлежит кому то на стороне клиента (или самому клиенту), с которого бизнес аналитик собирает видение решения и оформляет в таски для команд разработки.
ПМы оптимизируют процесс доставки (поток, спринты) и отчитываются о скорости команды и проценте выполнения запланированного объема работ. Решают узкие места, определяют фазы выполнения задач на доске, критерии завершение и обьем релизов.
В итоге результат работы нужен кому то или нет - это всегда проблема и забота клиента, он несет ответственность за то, как он это будет потом продавать и использовать,

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

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

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

Еще выше разговор начинается не с фич, а с пользовательского пути (customer journey map), баланса краткосрочных и долгосрочных целей, выстраивания понятного плана от высокоуровневой стратегии всего продукта к отдельным его частям. Повышается согласованность действий разных бизнес юнитов и отделов относительно общей стратегии.

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

Всем привет!

Всех с наступившим, надеюсь отлично провели новый год и готовы что то почитать интересное

Сегодня я расскажу вам про важный концепт из области управления проектам - матрица Cynefin (также это фреймворк)

Как ее только не произносят: киневин, синефин, цинефин и так далее, слово уэльское, разговорное, обычные правила английского тут бессильны, официально произносится как "kuh-NEV-in”, означает “место обитания или принадлежности” (habitat). Придумал матрицу профессор Дейв Сноуден, крутой старый чувак, у него очень интересные интервью на ютубе, советую посмотреть какое нибудь хотя бы одно.

Итак, матрица описывает 5 доменов, проект может находится в одном из них и, соответственно, фреймворк описывает разную последовательность действий, в зависимости от того, в каком домене находится проект

1) Очевидный (или Явный, или Простой) — Clear / Obvious

Это область, где всё понятно: есть чёткие причинно-следственные связи, и можно использовать лучшие практики.

2) Сложный — Complicated

Здесь есть причинно-следственные связи, но они требуют анализа или экспертных знаний. Подход — хорошие практики, не единственно верные.

3) Сложнокомплексный (или Комплексный) — Complex

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

4) Хаотичный — Chaotic

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

5) Неопределённый (или Беспорядочный) — *(Disorder)*

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

Как это использовать?

Пример 1: Клиент требует новый модуль в продукте
Ситуация: Клиент хочет новый отчёт по аналитике. Думает, что «это просто».

Разбор:
- Сначала кажется Очевидным — просто вывести данные.
- Но при анализе выясняется, что источники данных разрозненные, API нестабильны.
- Это уже Сложный домен — нужен аналитик + архитектор, чтобы проработать логику и интеграции.

Решение:
- Опиши возможные варианты отчёта.
- Проведи оценку усилий для каждого.
- Согласуй с клиентом, какой из вариантов покрывает ключевые цели.

Пример 2: Запуск нового финтех‑продукта на рынке MENA
Ситуация: Непонятна реакция пользователей. Регуляторные риски. Разная зрелость у стран.

Разбор:
- Это типично Комплексный домен: неизвестные переменные, нужна гибкость.

Решение:
- Запустить MVP в одной стране.
- Собрать данные о поведении пользователей.
- Постепенно расширяться, меняя фичи и UX под поведение реальных пользователей.

Пример 3: Уволился главный DevOps, все пайплайны лежат
Ситуация: Нет доступа к ключевым системам, прод упал.

Разбор:
- Это Хаос — надо действовать немедленно, не разбираясь в причинах.

Решение:
- Восстановить сервис любой ценой: откат, резерв, внешние ресурсы.
- Только после стабилизации — анализ, построение нового CI/CD.

Пример 4: Заказчик сам не знает, что хочет
Ситуация: Вроде «простой сайт», но требования постоянно плавают, фидбек противоречивый.

Разбор:
- Это Неопределённость (Disorder). Пока непонятно, с чем ты имеешь дело.

Решение:
- Разбей требования по частям.
- Где можно — применяй стандарты (Очевидное).
- Где нужна интеграция — оцени (Сложное).
- Где реакция пользователей важна — планируй A/B тесты (Комплексное).
- Если что-то резко ломается — переход в Хаос.

Всем привет
всех с наступающими праздниками, само собой!

Частая ситуация на пресейле или уже на старте проекта. Клиент хочет “как у больших”, но бюджет и сроки у него как на пилот.

Пример из жизни. Приходит клиент с новым стартапом - финтех продуктом. Хочет web, iOS, Android, админку, роли, отчёты, интеграции со Stripe, CRM, аналитикой. И всё это за 3-4 месяца желательно. Ну и бюджет у него на это меньше сотки зелени.

Есть два пути.

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

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

Второй путь скучнее, труднее, но он рабочий и в долгосроке сэкономит всем нервы, силы и настроение, а также позволит выстроить долгосрочные взаимовыгодные отношение. Это разговор про выбор, а не про “всё или ничего”.

Как я обычно веду такую беседу:
1. Сначала цель релиза 1.0, а не список фич, желательно цель достижимая и не такая амбициозная с которой клиент пришел. Его видение мы не оспариваем и не говорим что оно невозможно, скорее сводим это к “перовму шагу”
- Что должно случиться после запуска: первые N оплат, первые N активных пользователей в день, сокращение ручной работы, проверка гипотезы что это кому то нужно

2. Затем ограничения: Бюджет, срок, объём. Одновременно фиксировать все три пункта это почти всегда путь в никуда. Выбираем один, максимум два, третий становится переменным.

2. Дальше 2-3 варианта на стол:
- Вариант A: укладываемся в бюджет и срок, режем объём
- Вариант B: сохраняем объём, двигаем срок
- Вариант C: сохраняем срок, добавляем бюджет

3. Нарезаем ингридиенты MVP правильно: Не “по чуть-чуть отовсюду”, а один самый ценный пользовательский путь end-to-end. Один сценарий, который даёт ценность и проверяет гипотезу.

4. Убираем автоматизацию, которую можно пережить
- Отчёты в первой версии часто можно выгрузить из БД и собрать в Excel
- Ролей можно сделать 1-2 вместо полноценного RBAC
- Какие то операции по сборным платежам можно делать вручную, если платежи уже работают и тд

5. Пересматриваем интеграции и платформы:
- Каждая интеграция это риск и деньги. В MVP оставляем только критичное
- По платформам то же самое. На старт предлагаем 1-2, а не все три
- Один язык, один регион, очень желательно

6. Ищем готовое: дизайн-система, типовые админ-модули, стандартные провайдеры. Кастом только там, где это даёт преимущество с первого дня. Вообще желательно ВСЕГДА с этого начинать любой пресейл и тренировать технарей думать об этом, а не сразу оценивать разработку с нуля

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

Главный эффект. Клиент не покупает “обещание”. Он покупает короткий, понятный шаг с контролируемым риском.

Дополнительный совет: можно добавить какую то гарантию, например “если вы не получите рабочую систему через 3-4 месяца, то на каждый час сверху мы даем один бесплатно/мы даем месяц бесплатной поддержки после запуска/все баги фиксим бесплатно и тому подобное.

Всем отличных выходных!

Всем привет
поступил вопрос про использование ИИ в работе, вот свежий пример:
клиент пришел с запросом на оценку финтех проекта. Входящие документы от клиента по функционалу команда оценила в 250-300к$, клиенту презентовали и это явно оказалось для него дорого, судя по реакции. Что делать дальше?
Берем ИИ, в моем случае это perplexity, даем ему входящие доки и нашу WBS и просим предложить вариант укороченного релиза (MVP), который можно сделать дешевле, в нашем случае я выбрал 100к и 3-4 месяца.
Указываем что клиент не технический, нет смысла ему предлагать техники проиритизации (тип MoSCoW и тд).
ИИ выдал полную стратегию разговора с клиентом, описание укороченного функционала, даже картинку нарисовал.
ИИ выделил самое ценное действие клиента в приложении, описал почему именно оно и что оно даст клиенту.
Даже метрики успешности MVP написал.
Теперь осталось это скомпоновать в email клиенту или завернуть в красивую презентацию для клиента.
Все это быстро и без аналитика, самостоятельно
Все отличного дня!

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

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