Психбольница в руках пациентов

ОглавлениеДобавить в закладки К обложке

Как можно было предположить, к концу февраля совет директоров принял меры, и президент с вице-президентом по разработке были вынуждены оставить свои посты.

Конечно, это всего лишь один эпизод. И он мог бы показаться частным случаем, если бы не повторялся многократно в компаниях, где мне приходилось работать за последние двадцать с лишним лет.

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

Скотт подчеркивает фундаментальную истину: «Что посеешь, то и пожнешь». Если все время смотреть на календарь, то проект будет сдан вовремя, а если вам все равно, будет ли пользователь удовлетворен продуктом, то о пользователя просто вытрут ноги. Скотт продолжает рассказ:

Инвесторы не устают повторять: «У нас не так много денег, чтобы тратить их на продукт, который мы не сможем продать, поэтому мы должны изучить покупателей, прежде чем начнем проект». И при этом руководители разработки, похоже, неизменно верят в то, что у нас не так много времени и денег, чтобы тратить их на проектирование взаимодействия. Мы можем проектировать до бесконечности, и деньги закончатся прежде, чем мы успеем сделать продукт». Поэтому в конечном итоге они создают новые и новые продукты, вместо того чтобы совершенствовать уже имеющиеся – пока не закончатся деньги…

Если посмотреть со стороны, последние несколько месяцев были похожи на старую эксцентричную комедию или мыльную оперу, только без всякой романтики. Тоже по-своему ценный опыт. Конечно, смотря на дело только так, история не стоила бы столь подробного рассказа. Но во мне говорит сильное чувство. Думаю, долг чести требует прекратить впустую тратить жизнь людей на столь бесполезные предприятия.

В книге «About Face» ты писал о том, как важно перестать тратить время пользователя. От всего сердца соглашаюсь. Но это лишь вершина айсберга. Время пользователя можно потратить только тогда, когда продукт, достигший рынка, начинают покупать. Многие проекты закрываются прежде, чем разработчики успеют создать продукт, а результатом многих становятся продукты, не находящие покупателей. Инженерам из числа знакомых мне далеко не безразлична судьба их продуктов. Однако когда проект закрывают или продукт получается неудачным из-за отсутствия проектирования, то это означает пустую трату их энергии. А в мире не так уж много квалифицированных кадров, чтобы впустую тратить их время. Долг чести, о котором я говорю, призывает не просто «перестать впустую, тратить время пользователей, но перестать впустую тратить время и жизни всех людей, включая программистов.

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

Хочу подчеркнуть, что опыт Скотта вполне типичен. Вот история другого коллеги из нашей области, Джона Ривлина (John Rivlin). Джон управляет небольшой, но очень успешной компанией в Пало-Альто, специализирующейся на проектировании и разработке программного обеспечения. Он прислал мне свою историю:

Мы всегда тщательно проектировали продукты, прежде чем начинать разработку, и данный конкретный случай – не исключение. Мы начали проект с создания пятнадцатистраничной спецификации, описывающей взаимодействие пользователя с программой, которую мы предлагали написать. Спецификация включала и общие проектные положения, что дало нам возможность выйти за пределы начального описания «в одно предложение». Это важно, поскольку мы работаем исходя из фиксированной стоимости разработки и идем на определенный риск.
-= 90 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня