Тут вопрос в точку, но смешаны два разных трафика. Краулинг для обучения моделей - да, это не даст переходов, тут вы правы. А вот трафик из цитирования в ответах (когда ИИ дает ссылку на источник) - это другое, и он реально измеримый: в кейсе из статьи после работы над авторством переходы из ИИ-ответов выросли на 340% за 4 месяца. Так что часть аудитории таки кликает - не вся, но и не ноль, как вы правильно заметили в ответе выше про товары и услуги.
Согласен, разделение на BPMN и ETL точное. Конкретику по инструментам сознательно не давали - не хотелось превращать статью в рекламу чужих сервисов. Спасибо за наводку, учтём для будущих материалов.
Про войну продакт-программист - метрики из статьи как раз не про “отжать больше”, а про обратное: они защищают человека от произвольных претензий. Если задача стояла три дня на чужом согласовании, а не потому что программист ленился - это видно по истории карточки, а не по тому, сколько минут человек провёл за работой в редакторе кода. То есть нормально устроенная доска работает в обе стороны: руководителю - видимость, где реально затык, сотруднику - защита от “почему не сделано” на пустом месте.
Согласен, что конфликт лучше решать не через противостояние, а через общую выгоду для обеих сторон. Только это не отдельный инструмент вместо метрик, а то, для чего они и нужны при вменяемом использовании. Если метрику приняли как повод для давления - это не метрика виновата, а то, как ее применили.
Качество гипотезы меряется не в моменте, а по критерию, который зафиксировали до старта эксперимента - что именно будет считаться подтверждением. Грубо: если заранее договорились, какой метрикой мерим успех и какой порог считаем значимым, то по итогу просто смотришь, дотянула гипотеза до порога или нет. Без этого любая оценка гипотезы задним числом - уже подгонка под факт.
Согласен по всем пунктам, добавить особо нечего. Разве что по зумерам - выделять их действительно смысла немного, они просто более явно показывают, где в управлении дыры. Остальные грустят молча дольше, вот и вся разница.
По сути согласен - throughput без нормализации по сложности можно легко раздуть, взяв в спринт задачи попроще. Весовая схема на классах размера честнее самоопределенных story points, потому что команда не может подстроить оценку под метрику так же легко. Про продукт - сторипоинты и cycle time есть. Тут еще нужно смотреть специфику работы команды, но думаю, что адаптировать можно.
Справедливо, throughput и cycle time в чистом виде тут не подойдут, потому что неизвестна не скорость, а сам факт результата. Для RnD метрика должна быть другой: не "сколько сделано", а "уложились ли в отведенный таймбокс на исследование" плюс итог по факту: гипотеза подтвердилась, опровергнута или нужно продолжать. По сути закрытие вопроса, а не закрытие задачи. Если гипотезы идут потоком, можно смотреть долю подтвердившихся - но это уже не про скорость, а про качество попаданий.
Так в статье с этим никто и не спорит - в лоб про закон Гудхарта же. Задачу дробят под throughput, тесты режут под cycle time обходят любую метрику, если она одна.
Разница не в том, что придумали какую-то нечитерскую метрику, а в том, что смотреть надо парой с обратным давлением: throughput растет - смотри на возвраты. Если растут оба - читерство видно сразу, а не через квартал, когда релиз уже горит.
Войну это не заканчивает, само собой. Просто обходить одну метрику легко, а две сразу без потерь в другой - запарно
Ну если рассматривать ситуацию, где в каждой задаче нужно кого то тегать - то конечно этот вариант звучит не очень. А если это происходит не часто и сотрудники мотивированы помогать и работать в команде, то проблем не будет.
Согласен, тут есть две стороны и две крайности. Одно дополняет другое.
Согласен, что в основном это смена инструментов. Ведь те же миллениалы со временем будут хотеть работать по-другому. Но все таки в отличие от зумеров или удаленщиков по сравнению с офисными сотрудниками - здесь должны быть разные подходы. Либо быть готовым к тому, что твои задачи/высказывания воспринимаются по-разному.
Тут еще важно смотреть, где именно тегать. Не зря показывал наш сервис, где раз можно тегать в задаче/чате. Такое не пропустить. А если и пропустить, то это вина Пети.
Переписки скорее не только для того, чтобы не общаться совсем. А скорее для того, чтобы фиксировать эти обязательства. Отписался в задаче - значит человек в курсе проблемы.
Привет! Спасибо :) Для оценки используем модель ChatGPT. Итоговый промт получился довольно большой, и касается наших критериев. Поэтому для всех он не подойдет. Лучший вариант - это спросить у ИИ: что нужно, чтобы ты оценивал текст звонка по критериям.
Спасибо за такой вдумчивый комментарий, очень точные наблюдения.
Про «я, как администратор, хочу сбросить пароль, чтобы сбрасывался пароль» — с такими крайними кейсами, к счастью, не сталкивались :) Но в целом вы правы: сам шаблон не гарантирует качества. У нас это скорее микрофреймворк, чтобы задача была написана по-человечески.
Смысл в другом — определить базовую работу пользователя, которую мы закрываем. Это зона ответственности PM. Дальше важно, чтобы этот контекст доходил до всех по цепочке: не просто сделать кнопку, а понять, зачем она нужна. Если этого нет, никакая структура не поможет.
По статусам — да, они не про причину, а про сигнал. Нам важно было сначала увидеть, где именно в процессе начинаются проблемы, а уже потом разбираться, почему это происходит.
Причины каждый раз разные, поэтому универсального ответа нет. Из практики смотрим на cumulative flow diagram: если где-то зона начинает раздуваться, значит туда и идем копать.
По тестированию: из того, что реально прижилось — раннее подключение QA. Когда задача еще не дошла до разработки, QA уже смотрят требования, понимают, какие части продукта затронуты, пишут тест-кейсы.
Это сильно снижает количество сюрпризов в конце и ситуаций, когда вместо тестирования начинается попытка оживить продукт.
Спасибо за вопросы — видно, что вы глубоко в теме 🙂
1. В понедельник, когда завершается текущий спринт, сразу начинается новый, так как его планирование проходит ближе к концу второй недели. За счет этого нет паузы между спринтами.
2. Охват считаем по продуктовой аналитике - по количеству пользователей, вовлеченных в дорабатываемый или связанный функционал. Импакт - по сути субъективная метрика, оцениваем эмпирически.
3. Часть задач действительно удалили. Много дублей и связанных задач объединили. Остальное распределяем по спринтам при регулярной работе с бэклогом.
4. Всегда есть задачи, которые не требуют глубокой проработки: ошибки, техдолг и подобные вещи.
5. Квартальные цели согласуются со стратегией от стейкхолдеров. Планируем примерно на 2-3 квартала вперед, так как рынок и требования аудитории меняются достаточно быстро.
Тут вопрос в точку, но смешаны два разных трафика. Краулинг для обучения моделей - да, это не даст переходов, тут вы правы. А вот трафик из цитирования в ответах (когда ИИ дает ссылку на источник) - это другое, и он реально измеримый: в кейсе из статьи после работы над авторством переходы из ИИ-ответов выросли на 340% за 4 месяца. Так что часть аудитории таки кликает - не вся, но и не ноль, как вы правильно заметили в ответе выше про товары и услуги.
Согласен, разделение на BPMN и ETL точное. Конкретику по инструментам сознательно не давали - не хотелось превращать статью в рекламу чужих сервисов. Спасибо за наводку, учтём для будущих материалов.
Про войну продакт-программист - метрики из статьи как раз не про “отжать больше”, а про обратное: они защищают человека от произвольных претензий. Если задача стояла три дня на чужом согласовании, а не потому что программист ленился - это видно по истории карточки, а не по тому, сколько минут человек провёл за работой в редакторе кода. То есть нормально устроенная доска работает в обе стороны: руководителю - видимость, где реально затык, сотруднику - защита от “почему не сделано” на пустом месте.
Согласен, что конфликт лучше решать не через противостояние, а через общую выгоду для обеих сторон. Только это не отдельный инструмент вместо метрик, а то, для чего они и нужны при вменяемом использовании. Если метрику приняли как повод для давления - это не метрика виновата, а то, как ее применили.
Качество гипотезы меряется не в моменте, а по критерию, который зафиксировали до старта эксперимента - что именно будет считаться подтверждением. Грубо: если заранее договорились, какой метрикой мерим успех и какой порог считаем значимым, то по итогу просто смотришь, дотянула гипотеза до порога или нет. Без этого любая оценка гипотезы задним числом - уже подгонка под факт.
Согласен по всем пунктам, добавить особо нечего. Разве что по зумерам - выделять их действительно смысла немного, они просто более явно показывают, где в управлении дыры. Остальные грустят молча дольше, вот и вся разница.
По сути согласен - throughput без нормализации по сложности можно легко раздуть, взяв в спринт задачи попроще. Весовая схема на классах размера честнее самоопределенных story points, потому что команда не может подстроить оценку под метрику так же легко. Про продукт - сторипоинты и cycle time есть. Тут еще нужно смотреть специфику работы команды, но думаю, что адаптировать можно.
Справедливо, throughput и cycle time в чистом виде тут не подойдут, потому что неизвестна не скорость, а сам факт результата. Для RnD метрика должна быть другой: не "сколько сделано", а "уложились ли в отведенный таймбокс на исследование" плюс итог по факту: гипотеза подтвердилась, опровергнута или нужно продолжать. По сути закрытие вопроса, а не закрытие задачи. Если гипотезы идут потоком, можно смотреть долю подтвердившихся - но это уже не про скорость, а про качество попаданий.
Так в статье с этим никто и не спорит - в лоб про закон Гудхарта же. Задачу дробят под throughput, тесты режут под cycle time обходят любую метрику, если она одна.
Разница не в том, что придумали какую-то нечитерскую метрику, а в том, что смотреть надо парой с обратным давлением: throughput растет - смотри на возвраты. Если растут оба - читерство видно сразу, а не через квартал, когда релиз уже горит.
Войну это не заканчивает, само собой. Просто обходить одну метрику легко, а две сразу без потерь в другой - запарно
Ну если рассматривать ситуацию, где в каждой задаче нужно кого то тегать - то конечно этот вариант звучит не очень. А если это происходит не часто и сотрудники мотивированы помогать и работать в команде, то проблем не будет.
Согласен, тут есть две стороны и две крайности. Одно дополняет другое.
Согласен, что в основном это смена инструментов. Ведь те же миллениалы со временем будут хотеть работать по-другому. Но все таки в отличие от зумеров или удаленщиков по сравнению с офисными сотрудниками - здесь должны быть разные подходы. Либо быть готовым к тому, что твои задачи/высказывания воспринимаются по-разному.
Тут еще важно смотреть, где именно тегать. Не зря показывал наш сервис, где раз можно тегать в задаче/чате. Такое не пропустить. А если и пропустить, то это вина Пети.
Переписки скорее не только для того, чтобы не общаться совсем. А скорее для того, чтобы фиксировать эти обязательства. Отписался в задаче - значит человек в курсе проблемы.
Но согласен, встречи важны.
Спасибо!
Это вы про ИИ?
Привет! Спасибо :)
Для оценки используем модель ChatGPT. Итоговый промт получился довольно большой, и касается наших критериев. Поэтому для всех он не подойдет. Лучший вариант - это спросить у ИИ: что нужно, чтобы ты оценивал текст звонка по критериям.
Спасибо за такой вдумчивый комментарий, очень точные наблюдения.
Про «я, как администратор, хочу сбросить пароль, чтобы сбрасывался пароль» — с такими крайними кейсами, к счастью, не сталкивались :) Но в целом вы правы: сам шаблон не гарантирует качества. У нас это скорее микрофреймворк, чтобы задача была написана по-человечески.
Смысл в другом — определить базовую работу пользователя, которую мы закрываем. Это зона ответственности PM. Дальше важно, чтобы этот контекст доходил до всех по цепочке: не просто сделать кнопку, а понять, зачем она нужна. Если этого нет, никакая структура не поможет.
По статусам — да, они не про причину, а про сигнал. Нам важно было сначала увидеть, где именно в процессе начинаются проблемы, а уже потом разбираться, почему это происходит.
Причины каждый раз разные, поэтому универсального ответа нет. Из практики смотрим на cumulative flow diagram: если где-то зона начинает раздуваться, значит туда и идем копать.
По тестированию: из того, что реально прижилось — раннее подключение QA. Когда задача еще не дошла до разработки, QA уже смотрят требования, понимают, какие части продукта затронуты, пишут тест-кейсы.
Это сильно снижает количество сюрпризов в конце и ситуаций, когда вместо тестирования начинается попытка оживить продукт.
Спасибо за вопросы — видно, что вы глубоко в теме 🙂
Отвечу по пунктам.
1. В понедельник, когда завершается текущий спринт, сразу начинается новый, так как его планирование проходит ближе к концу второй недели. За счет этого нет паузы между спринтами.
2. Охват считаем по продуктовой аналитике - по количеству пользователей, вовлеченных в дорабатываемый или связанный функционал. Импакт - по сути субъективная метрика, оцениваем эмпирически.
3. Часть задач действительно удалили. Много дублей и связанных задач объединили. Остальное распределяем по спринтам при регулярной работе с бэклогом.
4. Всегда есть задачи, которые не требуют глубокой проработки: ошибки, техдолг и подобные вещи.
5. Квартальные цели согласуются со стратегией от стейкхолдеров. Планируем примерно на 2-3 квартала вперед, так как рынок и требования аудитории меняются достаточно быстро.
О, это отличное решение. Спасибо!
Рад, что понравилось!