Практикум PM

Продолжаем нашу благодатную тему о ретроспективе проекта. Ранее мы детально рассмотрели, что нужно для ретроспективы и в каких случаях ее стоит проводить, а когда ретро станет пустой тратой времени, и определили, как получать обратную связь от команды. Сегодня давайте соберем все в микро-методичку по ретро. Шаг 1 Определяем, нужна ли нам ретро. Выделяем на ретро два часа времени. Желательно - провести ретро через день после релиза, когда хотфиксы уже накачены, команду отпустило и еще не накрыло новыми задачами с головой...

Итак, мы с вами стали матерыми ребятами, которые делают все по красоте. И у нас грядет ретро. Что это такое и как подготовиться к такой полезной встрече с командой мы начали рассматривать в предыдущем посте, узнали о необходимых для ретро составляющих и остановились на таблице обратной связи...

Я не хочу начинать с тем, на которые написано уже куча статей на Хабре, проведены сотни выступлений на ocherednaya_CONF и прекрасно описано в классике из менеджерской библиотеки.  Диаграммы Ганта, Roadmap, Burndown chart и иже с ними прекрасно работают тогда, когда у вас уже есть опыт. Я расскажу о них позже. Они важны, когда вы уже поели дерьма с командой, поняли, что и когда уместно и не пытаетесь вбить кувалдой любой проект в рамки всех этих инструментов. В противном (и неизбежном для обучения) случае вас ждет классический крах с хорошим началом и всем известным концом...

Представления про IT у многих начинаются и заканчиваются «Кремниевой долиной», историями про светлую сторону менежмента о dream team, мотивации, продуктивности и Голдратте , случайно оброненным каким-нибудь блоггером «мы пишем сайт», и на мысли, что «Битрикс- это плохо».  А еще у нас всегда есть гидроскутеры в офисе и печеньки, и половина офиса - веганы с собачками. Программисты - это гениальные люди, неспособные к социализации, менеджеры - немного глуповатые ненужные звенья, работаем мы, лениво...