Comments 14
Спасибо за детали, именно их читать интересно. Есть несколько вопросов. Как я понял у вас работает agile методология. Как с таким подходом удается решать стратегические цели? Например из головы, «к декабрю подсистема API сервисов должна поддерживать частное облако» (это всего лишь пример большой цели). При этом бэклог состоит из частных запросов заказчиков. То есть должна быть и «водопадная» часть: план с проектом.
Заказчики видят приоритет своих запросов. Вы их разбиваете / объединяете при обработке конкретных требований к продукту? Если да, то как это видит заказчик?
Заказчики видят приоритет своих запросов. Вы их разбиваете / объединяете при обработке конкретных требований к продукту? Если да, то как это видит заказчик?
Как я понял у вас работает agile методология. Как с таким подходом удается решать стратегические цели?
Must-have задачи — это как раз задачи для решения стратегических целей. Процесс работы со ними выглядит примерно так: с какой-то обговоренной периодичностью (раз в 3-4 месяца сейчас) у нас проходят интенсивы, где определяются список задач на это время. После производится верхнеуровневая оценка, декомпозиция — мы всегда разбиваем крупные задачи на подзадачи (не больше 3-5 дней), — и составление примерного плана на эти 3-4 месяца. В дальнейшем они просто попадают в бэклог для must-have задач и тянутся оттуда по мере появления слотов на доске.
При этом бэклог состоит из частных запросов заказчиков.
Бэклог у нас общий для всех типов задач. За стратегическими целями стоят те же заказчики, только задачи больше.
Заказчики видят приоритет своих запросов. Вы их разбиваете / объединяете при обработке конкретных требований к продукту? Если да, то как это видит заказчик?
Как правило, крупные задачи приходят в категории must-have. Как я писала выше, мы их разбиваем на более мелкие исходя из объема работ или нюансов реализации. Заказчик видит это как царь-задачу и подзадачи.
Ответила на все вопросы?
Читать очень сложно — не надо после почти каждого абзаца вставлять гифки.
Не принимайте близко к сердцу, но:
- По заголовку можно было подумать, что у вас прямо российский Valve получился с его (почти) плоской структурой. Но нет, см. п. 2
- По тексту оказалось, что вы разгребли бэклог и доску в порядок привели :) и с приоритетами немного разобрались.
И соглашусь с mikhailzakharov — Вы судя по истории и правда менеджер команды.
Да, история не масштабов Valve, но я в самом начале обозначила, что речь про команду, то есть в среднем про 10 человек. Статья лишь про опыт решения некоторых проблем, которые не чужды многим IT-компаниям.
Если у вас сложилось впечатление, что я — менеджер команды, то я не могу с вами целиком согласиться. Мы — лид тестирования в моём лице и лид разработки — придумали и реализовали описанные решения, но роль "план-мастера" по-прежнему передается внутри команды, и каждый занимается планированием.
Украл котов. У вас тимлид писавший статью выполняет роль менеджера. Коты бесподобны. На чем сделан бэклог? Это тот же Google Sheet?
С бэклогом работаем через jira и её стандартные возможности. Сама карусель в гуглодоке — там просто фиксируем порядок заказчиков.
Мы с лидом разработки придумывали и внедряли эти решения, но всё же я не выполняю роль менеджера, она распределена по команде — каждый следующий дежурный берёт на себя дополнительные задачи по планированию.
За котов спасибо! :)
Мы с лидом разработки придумывали и внедряли эти решения, но всё же я не выполняю роль менеджера, она распределена по команде — каждый следующий дежурный берёт на себя дополнительные задачи по планированию.
За котов спасибо! :)
Все эти плюшки реализовывали на каких-то готовых инструментах (про гуглдок понятно) или все пекли сами?
Sign up to leave a comment.
Планирование с удовольствием. Как мы настроили процессы без менеджеров