Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами
Ретроспективные совещания
Ретроспективные совещания
Будем надеяться, что поминки проектов вам проводить не придется. Совещания, тип которых обозначен в заголовке, не должны представлять собой арену для выражения недовольства; на самом деле это лишь формальный способ обучения на собственном опыте. Как писал Норман Кит (Norman Keith):
«Степень эффективности и успеха ретроспективных совещаний обусловливается безопасностью сотрудников. Под безопасностью я имею в виду защищенность сотрудников от критики в рамках их группы. Лишь при таком условии они смогут обсуждать собственные результаты и даже признаваться в том, что поставленных целей можно было достичь по-другому, более оптимальными способами – иначе говоря, учиться анализировать выполненные проекты. Безопасность необходимо культивировать и поддерживать. Несмотря на то, что, по большому счету, безопасность выражает ответственность всех участников ретроспективного совещания, его руководитель призван создавать условия для безопасности, следить за ее поддержанием и контролировать это ощущение. Чтобы сотрудник чувствовал себя в безопасности, он должен быть уверен, что за проявленную честность он не получит по ушам (например, не нарвется на отрицательную оценку во время следующего критического обзора). В ходе ретроспективного совещания не обойтись без постоянного и должным образом поощряемого взаимодоверия»[57].
Проведя ретроспективное совещание в «безопасном» формате, вы получаете хорошие шансы почерпнуть довольно существенные сведения относительно недавно завершенного проекта. Эти знания, в свою очередь, позволят вам усовершенствовать процесс разработки. Необходимость соблюдения на ретроспективных совещаниях ощущения безопасности связана с тем, что иногда сотрудникам на них приходится отвечать на неприятные вопросы.
В ходе ретроспективного совещания, помимо прочего, полезно определиться с ответами на нижеследующие вопросы.
• Насколько четко была сформулирована спецификация продукта? Другой вариант того же вопроса: не случилось ли так, что в силу многократного пересмотра спецификации этап проектирования пришлось отложить на слишком долгий срок?
• Нашлось ли у вас время на макетирование проектного решения или же вы сразу приступили к кодированию?
• Трудно ли было расширять существующую архитектуру новыми функциями?
• Внес ли руководитель проекта весомый вклад в его успешную реализацию? Как можно оценить его организованность, компетентность и готовность к участию в проекте?
• Если бы вам представилась возможность написать тот же код снова, сделали бы вы что-нибудь по-другому?
• Находились ли в вашем распоряжении все программные инструменты, необходимые для решения поставленных задач?
• Как вы думаете, какие составляющие процесса разработки имеет смысл изменить?
Последний вопрос, естественно, открывает возможности для обсуждения широкого круга разнообразных проблем. Такие дискуссии только приветствуются – правда, проводить их следует как можно ближе к предмету обсуждения, то есть к выполненному проекту, и поощрять конструктивные предложения.
Оглавление книги
- Глава 5 Как вести совещания
- Глава 7 Планерки и совещания
- Глава 39 Как проводить совещания
- Ежедневные совещания – настоятельная необходимость
- Статья Екатерины Сехиной «Секреты знаменитых переговоров. Как проводить полезные совещания»
- Эффективные совещания
- Как проводить эффективные совещания и летучки
- 3. Стандарт управления совещаниями
- Рис. 5.1. Вариант шаблона для записей на совещаниях
- Ретроспективные встречи по итерациям и демонстрации
- Непроизводительные совещания
- Регулярные совещания участников проекта