У меня есть scrum-команда, состоящая из разработчиков-клиентов и разработчиков моей компании, чтобы сформировать команду из 8 человек. Я заметил много разногласий/споров между членами команды по поводу того, как лучше всего решить проблему.
Как бы вы подошли к решению таких проблем и убедились, что обе стороны удовлетворены и что был использован лучший метод?
Делайте «архитектурные шипы» из обоих. Это означает: установить разумные временные рамки для работы (обычно день), убедиться, что работа полностью практическая (создать как можно больше из каждого конкурирующего решения), выбросить работу с пиками, когда она будет выполнена, и только затем проведите обсуждение, чтобы принять решение. Один из способов сделать это более эффективным — заставить каждую подгруппу продвигать предложение другой подгруппы. Это гарантирует, что вы не столкнетесь с проблемой «ошибки необратимых затрат» после того, как пики будут завершены. Любой теоретический аргумент будет иметь тенденцию к «аналитическому параличу». Практическая работа намного эффективнее для поиска наилучшего решения.
В планировании спринта это распределение возможностей для обучения , а не для реализации. Пока это не занимает весь ваш спринт, а команда все еще работает над потенциально готовым к выпуску инкрементом продукта (в дополнение к обучению на пиках), вы должны быть в состоянии оставаться на правильном пути.
Другими словами, споры занимают больше времени, чем простое опробование альтернатив.
Интересно, что принятие произвольного решения также лучше, чем попытка обосновать «правильное» решение, поскольку это дает вашей команде возможность быстрее проверить и адаптироваться. Спор почти всегда бесполезен.
Как говорит Кен Швабер, основатель Scrum, «используйте Scrum, чтобы за месяц создать что-то не то» (перефразируя), а затем «проверить и адаптировать».
Конфликт и разногласия хороши, потому что они означают, что ваша команда вовлечена, они думают о вещах, они вложены, они ищут успешное решение, и так далее. Если у вас не было никакого конфликта, несмотря на то, что он кажется замечательным, у вас может быть сильно разобщенная команда с низким моральным духом, серьезный случай группового мышления или подобное явление.
Вам нужно работать над разногласиями. Создайте путь для двух или более сегментов команды, чтобы аргументировать свою позицию, обсудить плюсы и минусы различных альтернатив. Вам нужно способствовать этому, чтобы вещи оставались бесстрастными и основанными на фактах / источниках. Вы можете играть роль лица, принимающего решения, или создать какую-либо структуру голосования для решения проблемы или их комбинацию. Может показаться, что работы много, и может показаться, что дела не продвигаются, но гораздо лучше получить максимальную отдачу от вашей команды, чем продвигаться вперед с худшим решением, а затем переделывать проблему позже.
С моими небольшими познаниями в управлении проектами, я бы сказал, что считаю, что каждый хочет, чтобы его/ее мнение транслировалось и претворялось в жизнь. Одним из качеств PM является умение слушать и общаться с людьми, участвующими в проекте, чтобы сделать работу продуктивной и уложиться в срок.
Однако важно отметить, что как PM вы должны сбалансировать конкурирующие цели проекта, где каждая команда спорит о наилучшем способе решения проблемы. Ваше суждение/решение по определенным проблемам должно быть подкреплено фактами и уверенностью в том, что, выслушав их, вы, без сомнения, принимаете правильное решение как PM.
Тодд А. Джейкобс