Why Expectations Can Kill You and What You Can Do About It | Rob Walling

Почему ожидания могут вас погубить и что с этим делать

Новый разработчик увольняется через две недели. Ветеран с трёхлетним стажем уходит из компании, получив 5% прибавки на ежегодном пересмотре. Проект сдан в соответствии с оценками разработчиков, но проект-менеджера увольняют. Приложение построено по утверждённым спецификациям, но клиент недоволен. Что общего у всех этих ситуаций?Ожидания. У всех нас есть ожидания: утром из душа польётся вода, машина заведётся, педаль газа заставит машину ускориться, офис будет на месте и т.д.Когда они не оправдываются, это может пустить вашу жизнь под откос. Это шокирует — нажать на газ и не получить никакой реакции от машины; вы когда-нибудь испытывали это чувство? Кажется, будто реальность на мгновение даёт сбой, потому что нечто, что вы считали фактом, оказывается ложью. Это всегда работало, почему же не работает сейчас?Повседневная жизнь состоит из тысяч ожиданий — настолько, что мы привыкаем к их постоянному исполнению. Это одна из причин, почему создавать ПО так трудно.Показательный примерВ 2001 году я разрабатывал веб-систему управления контентом (CMS).Я подробно обсудил с клиентом, что приложение будет и чего не будет делать. Я написал спецификацию, отправил её на утверждение (не думаю, что он её вообще читал) и построил CMS. Мой начальник и коллега сочли её основательной. Я показал её нескольким друзьям-разработчикам, и они были по-настоящему впечатлены навигацией, удобством использования и возможностями редактирования HTML; это было ещё до появления таких вещей, как FreeTextBox, и потребовалась серьёзная работа с JavaScript, чтобы сделать пригодный HTML-редактор из обычного текстового поля.Когда клиент это увидел, он совершенно вышел из себя. Это один из немногих случаев, когда мне действительно пришлось держать телефон подальше от уха, потому что он орал так громко, прямо как в мультфильме. Он всё повторял, что это слишком сложно. В какой-то момент я попросил его кликнуть по каталогу, чтобы отобразить содержащиеся внутри страницы, а он спросил: «Что такое каталог?» Как отвечать на такой вопрос, понимая, что для работы с приложением ему нужно усвоить понятия в 10 раз сложнее?Проблема сводилась к следующему: он ожидал, что это будет как Microsoft Word. Он был нетехническим человеком и никогда не пользовался кастомным веб-софтом, поэтому его единственным ориентиром был пакет Microsoft Office. Мне было трудно убедить его, что кастомное ПО больше похоже на машину, собранную вручную, чем на ту, что сходит с конвейера, — оно дорогое, оно будет делать именно то, что вам нужно, но в нём не будет всех тех наворотов, к которым вы привыкли (в данном случае таких вещей, как проверка орфографии в реальном времени, поддержка правого клика и ещё нескольких). Его ожидания были слишком завышены для приложения такого типа, и суть в том, что я плохо справился с задачей скорректировать их заранее.Счастливый конец в том, что после первоначального периода обучения он отзывался о CMS очень положительно, и проект сочли успешным (насколько мне известно, он используется до сих пор).После этого опыта я вывел несколько правил по управлению ожиданиями:Правило №1: Фиксируйте их письменноВоспоминания со временем стираются, а устные договорённости стоят ровно столько, сколько бумага, на которой они напечатаны. Наличие чего-либо в письменном виде позволяет легко обратиться к этому год спустя — будь то спецификация ПО или оценка работы сотрудника.Хотя письменная спецификация не уменьшила первоначальную тревогу перед запуском, она позволила нам доказать, что мы построили приложения по утверждённому проекту, и обеспечила оплату нашей работы. Это уже говорилось, но я повторю: записывайте, даже если это просто короткое письмо для подтверждения сказанного на встрече. Если вы возьмёте в привычку дополнять телефонные звонки и встречи письмами вида «Согласно нашему телефонному разговору...», вы будете гораздо успешнее в долгосрочной перспективе.Правило №2: Настаивайте на обратной связиВы часто будете обнаруживать, что говорите только вы. Будь то ситуация, когда только вы отправляете письма или создаёте спецификации, или когда только вы говорите во время встречи один на один, — откройте дверь для мнения другого человека, попросив его высказаться. Человек может слушать часами, но так и не услышать по-настоящему то, что вы пытаетесь донести.Первоначальный провал приложения во многом был связан с тем, что клиент так и не прочитал спецификацию. Когда вы отправляете спецификацию, добавьте примечание: «Пожалуйста, приложите комментарии вместе с вашей подписью» — и упомяните это устно тоже. Если вы получаете спецификацию без комментариев, задайте несколько конкретных вопросов о какой-нибудь части приложения, например: «Что вы думаете о том, как мы собираемся организовать структуру каталогов?» — и посмотрите, какую реакцию получите. Дело не в том, чтобы обмануть клиента, а в том, чтобы быть осведомлённым и готовым к его ожиданиям.Настаивайте, требуйте или умоляйте... но так или иначе получите обратную связь.Правило №3: Встречайтесь лицом к лицу55% общения невербально, а значит, больше половины коммуникации — это тон и язык тела. Письма и конференц-звонки — отличные инструменты, но ничто не сравнится с тем, чтобы посмотреть человеку в глаза. Вам не только будет легче донести своё сообщение, но и люди будут дольше его помнить.Оглядываясь назад, это правило я выполнил наполовину. Я действительно назначил по меньшей мере одну встречу с владельцем проекта, чтобы объяснить приложение простым языком, но он был так занят, что у меня было около пяти минут, чтобы объяснить ему приложение, а этого недостаточно, чтобы вдаться в необходимые детали и сформировать ожидания. С тех пор я взял за правило делать акцент на описании ограничений приложения — на том, чего оно не будет делать. Люди часто тратят слишком много времени на этих встречах, продавая приложение и рассказывая, каким замечательным оно будет, но к этому моменту контракт у вас уже есть, так что вернитесь к реальности и будьте честны относительно его возможностей. В день запуска вы будете рады, что сделали это. Если в конечном счёте именно вы отвечаете за успех приложения, обязательно встретьтесь заранее с теми, кто будет определять этот успех.Правило №4: Не разрабатывайте в вакуумеЭто правило специфично для разработки ПО: не пишите спецификацию, чтобы затем уйти на четыре месяца и строить по ней. Называйте это цикличным процессом разработки, agile, xp или как угодно, но планируйте выпускать часть приложения раз в месяц, чтобы пользователи могли увидеть, как оно выглядит, и получить некоторый опыт работы с ним. Даже если вы используете каскадную модель (waterfall), где приложение сначала специфицируется целиком, а затем строится, дайте им что-то, что они смогут пощупать. У большинства пользователей мало контакта с кастомным ПО, поэтому это дополнительное усилие — огромный шаг к снижению тревоги в день запуска.Возвращаясь ко вступлениюИтак, как ожидания связаны с четырьмя сценариями из вступления?Новый разработчик уволился через две недели, потому что ожидал, что компания создаёт продукты по последнему слову техники, как ему сказали на собеседовании. Осознав, что ближайшие годы он будет строить базовые CRUD-формы (create, read, update, delete) для веба, он решил двигаться дальше.Ветеран с трёхлетним стажем, ушедший из компании после 5% прибавки, за прошедший год отработал сотни часов сверхурочно и был главной причиной успеха нескольких самых прибыльных проектов. Он ожидал хорошего бонуса или солидной прибавки — чего-то большего, чем стандартные 5%.Проект-менеджер, которого уволили за сдачу проекта в соответствии с оценками разработчиков, не сумел донести эти оценки до высшего руководства. Вместо него ожидания устанавливал кто-то другой, и с первого дня проект был обречён на срок, к которому его невозможно было успеть сдать.А четвёртый пример был темой этой статьи.Управление ожиданиями может быть трудным и затратным по времени процессом, но это одна из областей, в которой вы хотите участвовать. Эта статья — напоминание о том, что вы можете безупречно справиться с технической стороной приложения, но упустить человеческую — и этого с такой же лёгкостью достаточно, чтобы привести к провалу.