Добрый день. Всё дерево целиком, посмотреть не получится, там всё-таки есть наша специфика. Но я могу попробовать ответить на какие-то конкретные вопросы по нему.
Перед нами было две задачи: уйти от использования Gitlab и упростить процесс. Поэтому подходы по поиску проблем в текущем решении нам не подходили, а вариации на тему user story также приводят нас сразу к "пользователю" системы. Мы хотели подняться выше текущих решений и вот исследование графа работ хорошо в этом помогает.
Спасибо, за интересный опыт. А как вы поступаете, если задача по RICE набрала мало баллов, но её "надо" сделать? Просто делаете не взирая на баллы или поднимаете ей I и C, чтобы поднять ей баллы?
О да, мессенджеры, это интересно. Думаю развивать их - это сложная задача. Разрабатывать продукт, который постоянно используется и должен работать очень быстро - это круто. И плюс, есть явные конкуренты и референсы для сравнения.
это скорее может быть аргументом для решения идти вообще в разработку продукта или нет. А вот как отслеживать успешность или развитие продукта - вот это вопрос.
Я бы тут скорее пошёл в сторону оценки процессов планирования задач или ведения бэклогов, приоритизации и чего-то такого. т.е. из логики, что вести спринты - это необходимость для команд, а вот если сервис используют и для других задач - значит, он действительно удобный
Спасибо за комментарий, крутой поинт про "не факт что нет аналогов" это действительно может оказывать значительное влияние на продукт. А иногда мы и сами переносим свой опыт из одного сервиса в другой или одной компании в другую )
Круто, значит не зря писал :)
Ты не одинока :) Хорошая статья для старта на пути продакта.
Написал в личку )
Добрый день. Всё дерево целиком, посмотреть не получится, там всё-таки есть наша специфика. Но я могу попробовать ответить на какие-то конкретные вопросы по нему.
Спасибо, мало статей про внутренние продукты :) Приходится самому писать )
Успеха вам в этом, инструмент крутой, но и со своими нюансами :)
Перед нами было две задачи: уйти от использования Gitlab и упростить процесс.
Поэтому подходы по поиску проблем в текущем решении нам не подходили, а вариации на тему user story также приводят нас сразу к "пользователю" системы. Мы хотели подняться выше текущих решений и вот исследование графа работ хорошо в этом помогает.
Спасибо ?
Спасибо, надеюсь пригодится )
Пустой акаунт палит пустые акаунты... Ну это конечно мооощно!
Спасибо, за интересный опыт. А как вы поступаете, если задача по RICE набрала мало баллов, но её "надо" сделать? Просто делаете не взирая на баллы или поднимаете ей I и C, чтобы поднять ей баллы?
О да, мессенджеры, это интересно. Думаю развивать их - это сложная задача. Разрабатывать продукт, который постоянно используется и должен работать очень быстро - это круто. И плюс, есть явные конкуренты и референсы для сравнения.
это скорее может быть аргументом для решения идти вообще в разработку продукта или нет. А вот как отслеживать успешность или развитие продукта - вот это вопрос.
Я бы тут скорее пошёл в сторону оценки процессов планирования задач или ведения бэклогов, приоритизации и чего-то такого. т.е. из логики, что вести спринты - это необходимость для команд, а вот если сервис используют и для других задач - значит, он действительно удобный
Спасибо за комментарий, крутой поинт про "не факт что нет аналогов" это действительно может оказывать значительное влияние на продукт. А иногда мы и сами переносим свой опыт из одного сервиса в другой или одной компании в другую )
Спасибо, да, я так и решил, мне интересно заниматься такими продуктами. Иногда даже они могут быть совсем не маленькими )