Секрет айсберга

From The Joel on Software Translation Project

Jump to: navigation, search

Автор: Джоэл Спольски
Перевод: Полезные сайты В оригинале статья называлась
The Iceberg Secret, Revealed
и была написана 13 февраля 2002 года

Секрет айсберга

«Я не знаю, что не так с моей командой разработчиков», думает Главный директор. «Всё шло так хорошо, когда мы начинали этот проект. Первые пару недель команда работала, как сумасшедшая, и сделала прекрасный работающий прототип. Но с того времени всё заглохло. Они просто не работают так же усердно.» Он выбирает титановую клюшку от Callaway и посылает кэдди за холодным лимонадом. «Наверное, если я уволю нескольких копуш, то смогу снова зажечь огонь!»

В это время разработчики даже не подозревают, что что-то идёт неправильно. На самом деле, ничего не идёт неправильно. Они идут точно по графику.

Не позволяйте этому случиться с вами! Я собираюсь раскрыть вам секрет, как работать с менеджерами, у которых не технический склад ума, что облегчит вашу жизнь в миллион раз. Это очень просто. Как только вы узнаете мой секрет, у вас больше не будет проблем с такими менеджерами (если вы, кончено, не начнёте спорить с ними о коэффициенте жёсткости их клюшек для гольфа).

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

bunny.jpg

С начала моей работы в разработке программ, почти всё, что я делал, было «массовым». То есть это были не программы для какого-то конкретного клиента – они были сделаны в надежде, что миллионы людей купят его. Но многим недоступна такая роскошь. Они могут быть консультантами, разрабатывающими проект для одного клиента или программистами непрограммистской компании, делающими чего-то там для бухгалтерии (или что вы там программируете на дому - для меня это тайна).

Вы замечали, что в этих проектах на заказ, единственная обычная причина срыва сроков, ошибок и общей убогости обычно сводится к словам: «эти (вставьте сюда прилагательное) клиенты не знают, что именно они хотят».

Вот три популярные версии этой патологии:

  1. «Проклятый клиент изменил своё мнение. Сначала он хотел клиент-серверную архитектуру. Потом он где-то в «XXL» прочитал об XML и решил делать XML. Теперь мы переписываем эту штуку, чтобы она могла использовать тысячи маленьких Лего-роботов.»
  2. «Мы сделали именно то, что они хотели. В контракте было прописано всё до мельчайших деталей. Мы сделали точно то, что было там указано. Но когда мы дали им это, они почему-то были удручены.»
  3. «Наш тупой менеджер по продажам согласился подписать контракт с фиксированной стоимостью на создание того, что не имело даже базовой спецификации, а хитрые юристы клиента не забыли вписать в контракт пункт, где указано, что они не должны платить до ‘принятия продукта клиентом’, поэтому наши 10 программистов работали 2 года над их проектом и мы получили всего $100.»

Если бы можно было всверлить с помощью самой мощной дрели DeWalt только одну мысль каждому начинающему консультанту в голову, то это было бы: клиенты не знают, что они хотят. Перестаньте ждать от клиентов, что они будут знать, чего они хотят. Этого никогда не случится. Смиритесь с этим.

Вместо этого, представьте, что вы всё равно что-то сделаете, и это должно понравиться клиентам, и будет это для них маленьким сюрпризом. ВЫ должны сделать иcследование. ВЫ должны придумать дизайн, который решает проблему клиента удобным для него способом.

Поставьте себя на их место. Представьте, что вы только что продали свою компанию Yahoo! за $100 000 000 и решили, что пора сделать ремонт в кухне. Поэтому вы нанимаете профессионального архитектора и объясняете, что «это должно быть круче, чем у моего друга Васи». Вы не имеете ни малейшего понятия, как это сделать. Вы не знаете, что вы хотите: комплект Bucalossi или плитку от Marazzi – это не входит в ваш словарный запас. Вы хотите, чтобы архитектор сделал что-то хорошее, и именно поэтому вы его наняли.

Адепты Экстремального Программирования говорят, что решение – позвать к себе клиента и включить его в каждый шаг процесса разработки дизайна, сделать его членом команды разработчиков. По-моему, это слишком «экстремально». Это как если бы мой архитектор показывал мне, как они разрабатывают дизайн кухни, и просил ответной реакции по каждой мелочи. Это надоедает: если бы я хотел стать архитектором, то я бы учился на архитектора.

В любом случае, на самом деле вы ведь не хотите, чтобы клиент был частью вашей команды? Ведь вероятнее всего представитель клиента – это какой-то слабак, который работает хуже всех, и никто не заметит его отсутствия. А вам придётся тратить всё время, отведённое на дизайн, для объяснения вещей односложными словами.

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

Теперь, как и пообещал, я открою вам секрет перевода между языком клиентов (или технически недоразвитых менеджеров) и языком программистов.

Вы знаете, что 90% айсберга находится под водой? Ну и с большинством программ то же самое – есть красивенький интерфейс, который занимает 10% работы и потом 90% программистской работы «за кулисами». И если вы примете во внимание, что около половины времени уходит на исправление ошибок, то на пользовательский интерфейс уходит только 5% работы. И если вы ограничиваете себя только визуальной частью интерфейса, картинками, которые показываются в PowerPoint, то мы говорим сейчас менее, чем об 1%.

Это не секрет. Секрет в том, что люди, которые не являются программистами, не понимают этого.

Есть несколько очень важных следствий из этого секрета.

Важное следствие №1. Если вы покажете непрограммисту картинку, на которой интерфейс на 90% хуже, они будут думать, что программа на 90% хуже.

Я понял это, когда был консультантом и показывал веб-проект команде клиента. Код был написан почти на 100%. Мы всё ещё ждали, пока графический дизайнер выберет шрифты, цвета и нарисует прикольные трёхмерные вкладки. В это время мы использовали стандартные шрифты, всё было чёрно-белым, и в целом смотрелось не супер. Но 100% функциональности уже было и делало прекрасные вещи.
Что случилось в процессе демонстрации? Представители клиента потратили всё совещание ругаясь по поводу оформления экрана. Они даже не говорили по поводу интерфейса. Просто графическое оформление. «Это как-то не очень выглядит», жаловался их менеджер проекта. Это было всё, о чём они могли думать. Мы не могли заставить их задуматься о настоящей функциональности. На самом деле добавление графического дизайна заняло около одного дня. Такое впечатление, будто они думали, что наняли художников.

Важное следствие №2. Если вы покажете непрограммисту картинку, на которой интерфейс красив на 100%, они будут думать, что программа почти сделана.

Люди, которые не являются программистами, смотрят на экран и видят какие-то пиксели. И если кажется, что эти пиксели могут собраться в программу, которая что-то делает, они думают «да ну, сколько там ещё осталось, чтобы она просто начала действительно работать
Тут есть большой риск, если вы быстро рисуете интерфейс, например, чтобы получить какую-то обратную связь от клиентов, то они будут думать, что вы почти закончили. А потом вы проводите следующий год, работая «за кулисами», и, так как никто не видит, что вы делаете, то они думают, что вы ничего не делаете.

Важное следствие №3. «Дотком» у которого прикольный, вылизанный сайт из четырёх страниц, будет стоить дороже, чем «Дотком» с высокофункциональным сайтом, с архивом за 3700 лет и серым фоном страниц по умолчанию.

Ой, подождите, «Доткомы» уже не стоят ничего. Не обращайте внимания.

Важное следствие №4. Когда клиент или нетехнический менеджер очень хочет принять участие в проекте, дайте ему несколько версий графического дизайна, чтобы они могли выбрать.

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

Важное следствие №5. Когда вы делаете презентацию клиенту, единственная важная вещь – это скриншот. Сделайте его на максимально красивым.

Даже не думайте, что вы сможете попросить хоть кого-то представить как круто это будет. Не думайте, что они смотрят на функциональность. Они не смотрят. Они хотят видеть красивые пиксели.
Стив Джобс это понимает. О да, он это понимает. Инженеры в Apple научились, как делать вещи, из которых выходят супер-скриншоты, как например эффектные 1024х1024 иконки в системной панели, даже не смотря на то, что они тратят зря рабочее пространство на экране. И Linux-поклонники сходят с ума по поводу полупрозрачных терминалов xterms, которые отлично выглядит на скриншотах, но абсолютно невыносимы в использовании. Каждый раз, когда Gnome или KDE объявляет о новом релизе, я сразу смотрю на скриншоты и говорю: «Ого, они поменяли планету с Юпитера на Сатурн. Круто.» Не важно, что они действительно сделали.

Помните Главного директора в начале статьи? Он был недоволен, потому что его команда показала ему красивые PowerPoint'ы в начале – на скорую руку сделанные в Photoshop'е, даже не в Visual Basic. А теперь, когда они на самом деле работают "за кулисами", то кажется, что они ничего не делают.

Что вы можете с этим всем сделать? Как только вы узнали «секрет айсберга», легко понять, как это побороть. Поймите, что на презентации, которую вы делаете с проектором, речь будет идти только о пикселях. Если вы можете, создайте интерфейс так, чтобы незаконченные вещи выглядели незаконченными. Например, используйте только контуры значков в панели инструментов, пока для них действительно не будет сделана функциональность. Если вы делаете веб-сервис, то может быть нужно убрать с главной страницы функции, для которых пока не написан код. Тогда люди могут видеть, как страница с 3 командами вырастает в страницу с 20 командами.

Более важно, чтобы вы держали под контролем то, что люди думают о графике. Предоставьте детальный график в виде Excel'евского файла. Каждую неделю шлите самовосхволяющие e-mail'ы, в которых говорится, что вы продвинулись с 32% работы до 35% и вы точно соблюдаете график, чтобы завершить 25 декабря. Удостоверьтесь, что реальные факты доминируют над вымыслами по поводу того, с правильной ли скоростью реализуется проект. Да, и не разрешайте вашим начальникам использовать титановые клюшки от Callaway, независимо от того, насколько сильно вы хотите, чтобы они выиграли, федерация USGA запретила их.


---

Personal tools