Резиновая комната

Важно помнить, что вклад плохих исполнителей в создание кода не только недостаточный. Они не просто работают медленно, а вносят отрицательный вклад. В действительности они забирают время у хороших исполнителей, которые должны отлаживать их код, исправлять ошибки, сделанные плохими исполнителями, отвечать на их вопросы на уровне начинающих и разбираться с последствиями их неудачных решений. Так что плохих исполнителей надо фактически оставлять за бортом команды.
В некоторых организациях очень трудно увольнять балласт. В школьной системе Нью-Йорка настолько трудно справиться с учителем, нанятым на определенный срок, что начальство даже не пытается это делать. "В городских ведомостях на зарплату фигурируют сотни учителей, считающихся некомпетентными, дебоширами или виновными в сексуальных проступках. В школах боятся допускать их к преподаванию, поэтому помещают этих учителей в так называемые "резиновые комнаты", где они читают журналы, играют в карты и болтают за счет налогоплательщиков Нью-Йорка, которым обходятся по 20 млн. долл. ежегодно", - пишет Джон Стоссел в журнале Reason.
Конечная цель лидера команды состоит в том, чтобы улучшить производительность этой команды. Прекрасно, когда плохие исполнители уходят, но если из-за окружающей вас бюрократии, профсоюзных правил или национального законодательства добиться этого вы не можете, тогда используйте систему "резиновых комнат", т.е. что-либо, позволяющее не допускать этих людей к коду.
улучшение производительности
Многие "проблемные" разработчики просто не имеют хоть какой-то способности быть прекрасными разработчиками. По моему глубокому убеждению, имеется класс людей, которые, вероятно, и очень способные, но, тем не менее, никогда не разберутся в указателях и рекурсии. С другой стороны, для многих разработчиков просто нужен специальный подход, чтобы лучше управлять их производительностью. В таком случае руководителю надо устанавливать конкретные, реальные и достижимые цели, чтобы эти разработчики могли понимать, куда им двигаться. Это тренерская часть управления.
В других командах имеются способные разработчики, которые, однако, не могут работать вместе так, чтобы получались хорошие продукты. Эта тема в определенном смысле лежит за пределами данной книги, но ей посвящена другая моя книга, Joel on Software3, в которой говорится обо всем, что может делать команда программистов, чтобы создавать еще лучший код, а также о принципах, применяемых буквально в любой высокотехнологичной команде. В основе той, другой книги лежит тест Джоэла - 12 важных моментов, которые, как мне кажется, все должны выполняться командами разработчиков. Этот тест дается в виде приложения к данной книге.