Развитие «Башни из слоновой кости» (Ivory Tower Development) Перевод

Ещё один интересный материал (перевел) для ознакомления. Перевод статьи Jeff Atwood от 2005 года — Ivory Tower Development.

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

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

Я выступил с презентацией на собрании всех участников для подразделения Sun и попросил группу поднять руки, если они встречались с живым клиентом за последние 30 дней. Поднялась пара рук. «Последние 90 дней?» Ещё один. — «В прошлом году?» Еще два. В этой комнате было более 100 человек, непосредственно ответственных за результаты, которые шли прямо к пользователям… в данном случае это учебные курсы Java.

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

Приложите усилия, чтобы предоставить разработчикам доступ к пользователям на протяжении всего жизненного цикла проекта. Приводите одного разработчика из своей команды на каждую встречу с пользователями. Вовлеките разработчиков в ваше юзабилити и приемочное тестирование. Ничто не снимает шоры Homo Logicus разработчика быстрее, чем видеть, как типичный пользователь борется с базовыми компьютерными приложениями. Разработчики просто не могут понять, что обычный пользователь даже не знает, что делает ALT+TAB, не говоря уже о том, как его использовать. Они должны увидеть это, чтобы поверить в это.

Большинство проектов, над которыми я работаю в эти дни, являются внутренними. Я определяю внутренние проекты как проекты, в которых пользователи вынуждены использовать ваше приложение, хотят они этого или нет. Вот тебе и свобода воли. И, слишком часто, так много для беспокойства о качестве программного обеспечения. Как говорит Джоэл: к сожалению, многие внутренние программы довольно плохо работают. Это правда. И это печально. Это еще одна форма разработки «Башни из слоновой кости»: какой у меня стимул заботиться о проблемах нашего «клиента», когда их работа требует, чтобы они использовали мое приложение?

Я бы предпочел работать над проектами с платежеспособными клиентами или, по крайней мере, относиться к внутренним проектам так, как если бы пользователи платили реальные деньги за ваш продукт. Это порождает то, что Эрик Синк называет отношениями взаимного доверия:

Когда люди покупают у вас программное обеспечение, они ожидают многого, как сейчас, так и в будущем:

• Они верят, что ваш продукт будет работать на их машинах.
• Они верят, что вы поможете им, если у них возникнут проблемы.
• Они верят, что вы будете продолжать совершенствовать продукт.
• Они верят, что вы предоставите им разумный и по справедливой цене способ получения этих улучшенных версий.
• Они верят, что вы не выйдете из бизнеса в ближайшее время.

Таким образом, прося пользователей заплатить за ваше программное обеспечение, вы просите их доверять вам. Но насколько вы им доверяете?

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

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

Jeff Atwood, 7 февраля 2005 г. Ivory Tower Development