В коллективной работе часто встречается (но не становится от этого нормальной!) ситуация, когда один разработчик часами бьется над задачей, решение которой уже знает другой. Как правило, выясняется это, когда время уже потрачено, и в совершенно демотивирующем духе: «Ну ты и дурак, всем [то есть только мне] известно, что это делается так-то и так-то». В итоге – двойной ущерб проекту.
Чтобы уменьшить число подобных ситуаций, ПМ должен обеспечить в проекте среду, способствующую быстрой передаче компетенций (компетенция – это знание, как что-то сделать). Как правило, консультация человека, знающего решение, приводит к более быстрому результату, чем самостоятельный поиск. Поэтому такие консультации в проекте должны поощряться.
1. Создается доска компетенций. ПМ создает общедоступное хранилище информации и поощряет аффилянтов (личной беседой с наводящими вопросами, похвалой в адрес разработчиков и т. д.) внести в него сведения о своих компетенциях (что умеем делать, знакомые технологии и т. д.). Ссылка на доску компетенций рассылается всем аффилянтам (включая субподрядчиков).
2. Стимулируется трансфер компетенций. На первом собрании ПМ объясняет, что трансфер компетенций (то есть передача знаний, как сделать ХХХ) является высшим приоритетом в деятельности разработчиков. На последующих ПМ отмечает похвалой каждый случай трансфера компетенций, в том числе и те из них, которые привели к срыву сроков собственных заданий со стороны делившихся знаниями.
Результат. Столкнувшись с проблемами, разработчики привыкают сначала спрашивать решение друг у друга, а только потом искать его самостоятельно.
Трансфер компетенций особенно важен именно в проектной деятельности, поскольку в ней часто требуется поиск принципиально новых решений, что настраивает разработчиков именно на поиск и может привести к «изобретениям велосипедов». Хорошо налаженный трансфер гарантирует, что изобретать в команде будут только то, что действительно нужно изобретать.