Автор довольно знакомую картину рассказал, захотелось зарегистрироваться и прокомментировать)
Был один проект, в котором выступал как РП, но ресурсы использовались других команд. Т.е. вроде у тебя есть команда на 0,5 разработчика и 0,5 аналитика + твои ресурсы, но они не твои и так далее.
Основное управлять ожиданиями заказчиков и руководителей.
В какие-то моменты фича не делалась, чтобы архитекторно правильно её реализовать - нужно другое починить, т.к. потом ресурса переделать не будет
Одна из моих проблем была как раз в попытке защитить команды от критики, некоторых заказчиков от суровой правды (релиз их пожалений не принесёт эффекта, т.к. им нужно было сократиться до 1 человека, чтобы хоть как то фичу оправдать)
На следующей работе на позиции простого аналитика я увидел как выстроена правильная работа.
Как управлять хотелками без личного бренда, которые не принесут ценность продукта, при этом руками самих заказчиков. (Это не я вам отказал, а вы сами определили приоритеты исходя из потребностей бизнеса и эффектов. Да задача два года лежит, т.к. видимо эффект от её внедрения для вас и наших коллег не такой большой, как от других задач. Если помните, я предлагал вам обосновать необходимость задачи для топ-менеджмента и увеличить затраты. Как не помните? Вот мемо по нашей встрече в задаче)
Как журить команду, чтобы не переходить на личности, но при этом не вываливать на них все то, что говориться сверху
Почему результаты соседней команды важны и как помощь им, помогает твоей команде.
Почему важно не тушить пожары, а управлять изменениями. (Иногда показывая фильтры для задач руководителям, как у тебя видны влёты в спринте и как ты к ним готовился (около 25% времени заложено на них) - некоторые сразу посмотрят и другие свои команды)
Как разделить зоны ответственности, делегировать задачи/ответственности и их консолидация - почему не нужно отвечать за все самому. Тут как говорят: доверяй, но проверяй.
Автор довольно знакомую картину рассказал, захотелось зарегистрироваться и прокомментировать)
Был один проект, в котором выступал как РП, но ресурсы использовались других команд. Т.е. вроде у тебя есть команда на 0,5 разработчика и 0,5 аналитика + твои ресурсы, но они не твои и так далее.
Основное управлять ожиданиями заказчиков и руководителей.
В какие-то моменты фича не делалась, чтобы архитекторно правильно её реализовать - нужно другое починить, т.к. потом ресурса переделать не будет
Одна из моих проблем была как раз в попытке защитить команды от критики, некоторых заказчиков от суровой правды (релиз их пожалений не принесёт эффекта, т.к. им нужно было сократиться до 1 человека, чтобы хоть как то фичу оправдать)
На следующей работе на позиции простого аналитика я увидел как выстроена правильная работа.
Как управлять хотелками без личного бренда, которые не принесут ценность продукта, при этом руками самих заказчиков. (Это не я вам отказал, а вы сами определили приоритеты исходя из потребностей бизнеса и эффектов. Да задача два года лежит, т.к. видимо эффект от её внедрения для вас и наших коллег не такой большой, как от других задач. Если помните, я предлагал вам обосновать необходимость задачи для топ-менеджмента и увеличить затраты. Как не помните? Вот мемо по нашей встрече в задаче)
Как журить команду, чтобы не переходить на личности, но при этом не вываливать на них все то, что говориться сверху
Почему результаты соседней команды важны и как помощь им, помогает твоей команде.
Почему важно не тушить пожары, а управлять изменениями. (Иногда показывая фильтры для задач руководителям, как у тебя видны влёты в спринте и как ты к ним готовился (около 25% времени заложено на них) - некоторые сразу посмотрят и другие свои команды)
Как разделить зоны ответственности, делегировать задачи/ответственности и их консолидация - почему не нужно отвечать за все самому. Тут как говорят: доверяй, но проверяй.