На проекте остался основной разработчик, а для второго как раз был подготовлен к старту следующий проект.
Вы правы, закон Брукса никто не отменял. Второй разработчик был добавлен не с целью ускорить работу в два раза, а как превентивная мера потенциальному затягиванию разработки из-за усталости и перегруженности основного. После прохождения пикового момента нагрузки на проекте вернулись к схеме с одним разработчиком.
Eduard, спасибо!
Alex, смысл проекта мы обсуждали еще в самом начале, до перехода в фазу поддержки и мелких доработок. В указанном примере описан момент, когда команда устала и понадобились пересмотр цели и работа с мотивацией.
Дмитрий, спасибо за вопрос. В указанном случае для клиента сроки были важнее бюджета. В обсуждениях основной упор с моей стороны был на качество (чем больше человек перегружен, тем выше вероятность ошибок) и сроки, которые бы пострадали не добавь мы подмогу.
Продуктивные взаимоотношения действительно двигатель всего, но возможны они только при обоюдном желании сторон. Работа в команде подразумевает, что все участники способствуют их налаживанию и открыты к диалогу. Задача ПМа — помогать, если у коллег есть с этим сложности.
В первом примере доверительные отношения как раз и выстраивались с помощью митингов 1:1, т.к. для меня это самый эффективный способ (даже если вся команда в одном офисе). Я старалась узнать о сотрудниках как можно больше, выяснить какие есть проблемы и при этом показать кто я, как работаю.
Да, всегда есть вероятность, что коллега не расскажет всю правду. Но если показать человеку, что он разговаривает с потенциальным помощником, то общение приобретает более открытый характер. Особенно, если это не первый митинг 1:1 и удалось выполнить хотя бы часть из проговоренного ранее.
В описанной ситуации результатом добавления второго разработчика стала нормализация нагрузки, что было заметно даже без дополнительных митингов. Возможно, было и другое решение, но принятых мер оказалось достаточно.