СИТУАЦИЯ.
Во многих компаниях — разработчиках программного обеспечения сотрудники, ответственные за написание новых программ, влюбляются в свой код. К отзывам клиентов, протестировавших их программы, они зачастую относятся скептически. Например, однажды в Microsoft тестировали очередную новую программную «фишку», и шесть из десяти пользователей не смогли понять, как ею пользоваться. Когда тестовая лаборатория поделилась этими данными с разработчиками, реакция была: «Откуда вы взяли шесть идиотов?»[52] С этой проблемой в той или иной степени сталкиваются многие компании. Возможно ли убедить разработчиков быть отзывчивее на реакцию клиентов?В ЧЕМ ЗАКЛЮЧАЕТСЯ ИЗМЕНЕНИЕ И ЧТО ЕГО СДЕРЖИВАЕТ?
Компаниям надо заставить разработчиков порыться в софте в ответ на отзывы клиентов, иначе программы не будут иметь успеха. Но иногда разработчики сопротивляются и высмеивают отзывы или только символически что-то пересматривают, не пытаясь встать на место клиента и понять его затруднения. Это, вероятно, проблема Слона: разработчики понимают, чего от них хотят, но им не нравится, что их заставляют менять прекрасный код из-за каких-то недоумков. Однако давайте не будем делать поспешных выводов относительно степени вменяемости этих самых разработчиков. Такие оценочные суждения отражают психологическую предвзятость, которую мы рассмотрим в главе 8. Лучше сосредоточимся на том, чтобы больше мотивировать этих яйцеголовых ребят и убрать препятствия с их пути.1. Точка назначения. Мы должны нарисовать картину славы, которую группа получит в результате успешного запуска продукта. Разработчики станут героями-программистами, введут в резюме строчку, которая повергнет в почтительный трепет любого кадровика. Внимательно слушать клиента — просто способ ускорить приближение этой славы.
2. Запланируйте ключевые шаги. Достаточно ли конкретно вы ставите требования разработчикам? Представьте, что мы заявили: простоту пользования их программой оценили как неудовлетворительную. Что с этим сделать? Их Погонщики будут часами крутиться, пытаясь выбрать из десятков возможных улучшений. Наша обязанность — определить ключевые шаги вроде: «Надо сделать так, чтобы можно было быстрее вращать эти объекты».
1. Найдите чувство. В Microsoft разработчиков приглашали посетить лабораторию тестирования юзабилити. Там, стоя за зеркалом одностороннего в
2. Вырастите своих людей. Разработчики могут считать, что код, нуждающийся в пересмотре, бросает тень на их способности (мы поговорим об этом подробнее в главе 7, в разделе о фиксированных установках). Необходимо подчеркнуть, что на самом деле критерий профессионального уровня разработчика — не качество первоначального кода, а то, насколько хорошо он сумеет преодолеть неизбежные препятствия. Мы должны по заслугам отмечать гениальные решения проблем клиентов, требовавшие недюжинных усилий.
1. Сформируйте привычки. Приходят ли отзывы клиентов в самый удобный момент цикла разработки кода? У программистов складывается устоявшийся ритм, который помогает им в работе. Можем ли мы встроить тестирование пользователями в этот цикл?
2. Поработайте с обстановкой. Во многих компаниях программистам выдают лучшие компьютеры. Это отлично повышает производительность труда, но плохо воспитывает сочувствие к клиенту. Один менеджер говорит, что каждый раз, когда его разработчики используют машину, на поколение опережающую оборудование клиентов, у последних возникают проблемы с программным обеспечением. Разработчики не представляют, насколько медленно работают их программы у типичного пользователя. Пересадите их на те же машины, которые используют клиенты! (Это еще одно решение, связанное с Тропой, которое применяет Microsoft.)