Согласен - исключения бывают, и иногда они необходимы. Я скорее говорил про важность системы и правил, без которых хаос становится нормой. Но да, важно доносить, что "исключение" - это именно исключение, а не новая стандартная практика. Иначе фильтр просто теряет силу.
Про участие разработчиков - прям жирный плюсик. Фильтрация задач не должна превращаться в стену. Разработчики не только могут, но и должны участвовать в обсуждении решений, в особенности если это влияет на архитектуру или UX. Коммуникация с заказчиком важна в формате контролируемой, понятной и прозрачной рамке.
Моя задача как Проект Менеджера, не загнать команду в рамки, а наоборот: создать такую среду, где разработчики не тонут в хаосе неопределенности, но при этом остаются вовлечёнными и ценными участниками процесса и прогресса.
Кстати, поделюсь ещё одной деталью. У нас в команде сейчас важную роль фильтра выполняет мой продукт-менеджер. Он тщательно формирует user story, и благодаря этому мы получаем в команду уже более выверенные задачи - понятные, логичные, с ясной бизнес-ценностью.
Это сильно снижает уровень шума и неопределённости на входе. Мы не спорим о том, что делать - мы обсуждаем, как лучше реализовать. То есть фильтрация работает, как выстраивание внятной логики и потока задач.
Спасибо большое за добрые слова - очень рад, что стало лучше
Что касается Trello - он оказался неудобным для планирования спринтов и создания отчётов, которые важны для бизнеса. Также не хватало встроенного контроля времени.
А Google Формы мы использовали как простой способ фиксировать ответы и собирать их в общей таблице. Это нужно не только для текущей работы, но и на будущее - если проект будет передаваться другим людям, чтобы у них была видимость: что делали, какие возникали блокеры и как команда с ними справлялась. Такой своеобразный лог процессов.
Не обижаюсь совсем - наоборот, признателен, что нашли время прочитать и оставить комментарий. Это моя первая попытка рассказать о реальном опыте, без вылизанных формулировок и редакторов. Хотелось передать живую историю, как было - местами сумбурно, местами на эмоциях, как и сам проект.
Про грамотность — согласен, над этим точно стоит поработать. Буду учитывать и обязательно подчищу текст.
Scrum, таск-трекеры, dev — действительно, местами разнобой. Спасибо, что подсветили! Учту это при доработке и в будущих публикациях.
Считаю, что "Лучше написать с ошибками, чем не написать вообще" А дальше — шлифовать и расти
Согласен - исключения бывают, и иногда они необходимы. Я скорее говорил про важность системы и правил, без которых хаос становится нормой. Но да, важно доносить, что "исключение" - это именно исключение, а не новая стандартная практика. Иначе фильтр просто теряет силу.
Про участие разработчиков - прям жирный плюсик.
Фильтрация задач не должна превращаться в стену. Разработчики не только могут, но и должны участвовать в обсуждении решений, в особенности если это влияет на архитектуру или UX. Коммуникация с заказчиком важна в формате контролируемой, понятной и прозрачной рамке.
Моя задача как Проект Менеджера, не загнать команду в рамки, а наоборот: создать такую среду, где разработчики не тонут в хаосе неопределенности, но при этом остаются вовлечёнными и ценными участниками процесса и прогресса.
Кстати, поделюсь ещё одной деталью. У нас в команде сейчас важную роль фильтра выполняет мой продукт-менеджер. Он тщательно формирует user story, и благодаря этому мы получаем в команду уже более выверенные задачи - понятные, логичные, с ясной бизнес-ценностью.
Это сильно снижает уровень шума и неопределённости на входе. Мы не спорим о том, что делать - мы обсуждаем, как лучше реализовать. То есть фильтрация работает, как выстраивание внятной логики и потока задач.
Приветствую, речь шла о Проект менеджере
Тут возникает вопрос, а какие есть риски перехода? И как минимализировать?
Спасибо большое за добрые слова - очень рад, что стало лучше
Что касается Trello - он оказался неудобным для планирования спринтов и создания отчётов, которые важны для бизнеса. Также не хватало встроенного контроля времени.
А Google Формы мы использовали как простой способ фиксировать ответы и собирать их в общей таблице. Это нужно не только для текущей работы, но и на будущее - если проект будет передаваться другим людям, чтобы у них была видимость: что делали, какие возникали блокеры и как команда с ними справлялась. Такой своеобразный лог процессов.
Не обижаюсь совсем - наоборот, признателен, что нашли время прочитать и оставить комментарий. Это моя первая попытка рассказать о реальном опыте, без вылизанных формулировок и редакторов. Хотелось передать живую историю, как было - местами сумбурно, местами на эмоциях, как и сам проект.
Про грамотность — согласен, над этим точно стоит поработать. Буду учитывать и обязательно подчищу текст.
Scrum, таск-трекеры, dev — действительно, местами разнобой. Спасибо, что подсветили! Учту это при доработке и в будущих публикациях.
Считаю, что "Лучше написать с ошибками, чем не написать вообще" А дальше — шлифовать и расти