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