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

Why Expectations Can Kill You and What You Can Do About It

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

A new developer quits after two weeks. A three-year veteran leaves the company after receiving a 5% raise at his annual review. A project is delivered according to developer estimates but the project manager is fired. An application is built to approved specifications but the client is unhappy. What do all of these situations have in common?Expectations. We all have expectations: water will come out of the shower in the morning, the car will start, the gas pedal will make the car accelerate, the office will still be there, etc...When they aren't met it can send your life into a tailspin. It's shocking to push the gas pedal and get no response from the car; have you ever experienced this feeling? It feels like reality disconnects for a moment because something you hold as fact becomes false. This has always worked, why doesn't it work now?Daily life involves thousands of expectations; so much so that we get used to having them constantly met. This is one reason that building software is so difficult.Case In PointI developed a web-based a content management system (CMS) back in 2001.I talked in great detail with the client about things the application would and would not do. I wrote a spec, submitted it for approval (I don't think he ever read it), and built the CMS. My boss and co-worker thought it was solid. I showed it to some developer friends of mine and they were thoroughly impressed with the navigation, the usability, and the HTML editing capabilities; this was before things like FreeTextBox, and it took some major JavaScript work to get a usable HTML editor from an HTML text area.When the client saw it he absolutely lost it. This is one of the few times when I actually had to hold the phone away from my ear because he was yelling so loud, like in a cartoon. He kept saying it was too complicated. In fact, at one point I told him to click on a directory to display the pages contained inside, and he asked "What's a directory?" How do you answer a question like that knowing that he needs to understand concepts 10 times more complicated in order to work the application?The problem boiled down to this: he expected it to be like Microsoft Word. He was non-technical and had never used custom web-based software, so his only reference was the Microsoft Office suite. I had a hard time convincing him that custom software is more like a car built by hand than one that rolls off an assembly line - it's expensive, it's going to do exactly what you want, but it's not going to have all the bells and whistles you're used to (in this case things like real-time spell checking, right-click support, and a few others). His expectations were too high for this type of application, and the bottom line is that I hadn't done a good job of correcting them in advance.The happy ending is that after the initial learning curve he had a lot of positive things to say about the CMS, and the project was considered a success (it's still in use today, as far as I know).After this experience I came up with some rules about setting expectations:Rule #1: Put them in writingMemories fade with time and verbal agreements are worth the paper they're printed on. Having something in writing makes it easy to refer back to a year down the line, whether it's a software specification or an evaluation of an employee's performance.Although having my specification in writing didn't ease the initial launch anxiety it allowed us to prove that we had built the applications to an approved design, and ensured that we were paid for our work. It's been said before, but I'll say it again: write it down, even if it's a quick email to confirm something said in a meeting. If you get in the habit of following up phone calls and meetings with "Per our phone conversation..." emails you will be much more successful in the long run.Rule #2: Insist on feedbackYou will often find yourself doing all the talking. Whether this means you're the only one sending emails or creating specs, or the only one speaking during a one on one meeting, open the door for the other person's opinion by asking for it. Someone can listen for hours but never really hear what you're trying to communicate.The application's initial failure had a lot to do with the fact that the client never read the spec. When you submit a spec, include a note that says "Please include feedback with your signature." and mention this verbally, as well. If you receive the spec without feedback ask some specific questions about a piece of the application such as "What do you think about how we're going to handle the directory structuring?" and see what kind of response you receive. It's not about tricking the client, it's about being aware and being prepared for their expectations.Insist, demand, or beg for it...but one way or another get some feedback.Rule #3: Meet face to face55% of communication is non-verbal, which means more than half of communication is tone and body language. Emails and conference calls are great tools, but nothing beats looking someone in the eye. Not only will you have an easier time getting your message across, but people will tend to remember it longer.In retrospect, I got this one half right. I did schedule at least one meeting with the project owner to explain the application in plain English, but he was so busy hat I had about five minutes to explain the application to him and that's not enough time to go into the necessary detail to shape expectations. Since then I've made it a point to put an emphasis on describing an application's limitations - what it won't do. People often spend too much time selling the application during these meetings by saying how great it's going to be, but by this point you already have the contract so step into reality and be forthright about its capabilities. On launch day you'll be glad you did. If you're ultimately responsible for the success of the application be sure you meet early on with those who will determine the success of the application.Rule #4: Don't build in a vacuumThis one is specific to software development, but don't write a specification and then go away for four months to build it. Call it a cyclical development process, agile, xp, or whatever, but plan to release a piece of the app once a month so users can see how the application looks and get some experience playing around with it. Even if you're using the waterfall model where you spec an application up front and then build, give them something they can experience. Most users don't have much contact with custom software so making this extra effort is a huge step towards easing launch-day anxiety.Back to the IntroSo how do expectations tie into the four scenarios from the introduction?The new developer quit after two weeks because he expected the company was building state of the art products, as he was told during his interview. After realizing he would be building basic CRUD (create, read, update, delete) web forms for years to come he opted to move on.The three-year veteran who left the company after receiving a 5% raise had worked hundreds of hours of overtime during the past year, and was the main reason several of the most profitable project succeeded. He expected a nice bonus or a healthy raise, something more than the standard 5%.The project manager who was fired for delivering the project according to developer estimates wasn't able to communicate these estimates to executive management. Instead, someone else was in charge of setting the expectations and from day one the project was due before it could possibly be delivered.And the fourth example was the subject of this article.Setting expectations can be a difficult and time consuming process, but it's one area that you want to be part of. This article is a reminder that you can nail the technical aspect of an application, but missing the human side can just as easily lead to failure.

Новый разработчик увольняется через две недели. Ветеран с трёхлетним стажем уходит из компании, получив 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%.Проект-менеджер, которого уволили за сдачу проекта в соответствии с оценками разработчиков, не сумел донести эти оценки до высшего руководства. Вместо него ожидания устанавливал кто-то другой, и с первого дня проект был обречён на срок, к которому его невозможно было успеть сдать.А четвёртый пример был темой этой статьи.Управление ожиданиями может быть трудным и затратным по времени процессом, но это одна из областей, в которой вы хотите участвовать. Эта статья — напоминание о том, что вы можете безупречно справиться с технической стороной приложения, но упустить человеческую — и этого с такой же лёгкостью достаточно, чтобы привести к провалу.