Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

• Делайте различие между профессиональными умениями и дисциплиной.В предыдущей главе мы обсуждали два критерия зрелости: профессиональные умения и дисциплину. Возможно, при оценке людей и команд вам стоит пользоваться этими критериями по отдельности. Это поможет наиболее квалифицированным сотрудникам (которые порой думают, что застрахованы от ошибок) не забывать о дисциплине. А людям, у которых с дисциплиной все хорошо, это поможет избежать самоуверенности («я прекрасно работаю, потому что выполняю все процедуры»). Несколько примеров показателей, позволяющих оценить состояние дисциплины: доска задач поддерживается в актуальном состоянии, совещания начинаются вовремя, покрытие кода тестами всегда превышает 95 %. И показатели, связанные с профессиональными умениями: отсутствие ошибок при сборке, в коде мало ошибок, демо всегда принимаются клиентом.

• Не составляйте рейтингов знаний или опыта.В моем представлении знания и опыт – необходимые условия профессионализма и дисциплины, но измерять их было бы странно. Знания и опыт описывают состояние человека. Профессионализм и дисциплина напрямую связаны с результатами . Писатель попадает в рейтинги не потому, что он писатель . В рейтинги он попадает благодаря изданным книгам . В вашей компании никто не должен получать высокие рейтинги за знания и опыт, ведь такой человек вполне может проводить свое рабочее время за компьютерными играми.

• Выставляйте одновременно рейтинги по нескольким видам деятельности.У каждого из нас есть дела, с которыми ему удается справляться лучше, чем с другими. Гораздо легче пережить унижение, получив низкий рейтинг по одному виду деятельности, если одновременно получен высокий рейтинг по другому. Точно так же сотрудники легче воспринимают критику, если ее компенсировать похвалой за какие-либо достижения в другой области. Одновременные рейтинги по нескольким видам деятельности дают возможность быть более справедливым к людям. Должны быть рейтинги, отражающие качество релиза и его своевременность, степень удовлетворенности клиента и экономию затрат при реализации проекта, соблюдение принятых в компании стандартов и проявленную командой гибкость.

• Оценивайте несколько попыток.Один из моих учителей в средней школе практиковал систему, при которой он ставил ученику не менее десяти оценок в год. Но выводя итоговую, не принимал во внимание самые низкие из них, потому что «у всех нас бывают неудачные дни». Люди в целом предпочитают иметь возможность быть оцененными за какой-либо вид деятельности несколько раз. Нужно давать им шанс в следующий раз сделать лучше. Поэтому должны быть рейтинги за каждый завершенный проект и за каждый релиз продукта.

• По возможности всегда используйте относительные рейтинги.Сравнивайте актуальные результаты команды с предыдущими («в этот раз на 15 % лучше, чем было»); с результатами других команд в вашей организации («на 20 % хуже, чем у коллег, которые занимаются проектом X») либо с другими компаниями («наши дела обстоят на 32 % лучше, чем в компании B»). Относительные показатели стимулируют команды от раза к разу повышать свою производительность, вместо того чтобы однократно достичь цели и застыть в этой точке [Highsmith 2009: 353].

• Цикл обратной связи должен быть предельно быстрым.Не должно быть большого разрыва во времени между действием и получением обратной связи в виде рейтинга или другого показателя. Это одна из причин, почему я стал вести блог до того, как начал писать эту книгу. Мне нужна была моментальная обратная связь от читателей, чтобы научиться писать лучше. Только через полтора года я почувствовал достаточную уверенность, чтобы начать писать книгу – как известно, у книг цикл обратной связи занимает гораздо больше времени.

• Используйте как опережающие, так и запаздывающие параметры.Изменения в опережающих параметрах позволяют понять, какова вероятность , что вы достигнете поставленной цели. (Пример: увеличение покрытия кода тестами может свидетельствовать о более высоком качестве продукта.) Запаздывающие параметры показывают (уже после завершения проекта), удалось ли вам достичь своих целей. (Пример: низкое количество жалоб от клиентов на ошибки уже после релиза подтверждает качество продукта.) В целом рекомендуется пользоваться обоими типами параметров [Cohn 2009: 440].