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

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

Самодовольство инженера было поразительным. Гордость за создание такого мощного продукта ослепила его, но хуже того, ослепила и президента, который не видел неспособность инженера спроектировать продукт таким образом, чтобы пользователи остались довольны.

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

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

Наличие инженерных навыков помешало президенту компании. Упростив создание продукта, этот опыт встал на его пути, мешая увидеть заблуждения ведущего программиста. Глубоко укоренившись в программистской среде, он считал подобное положение вещей совершенно нормальным, тогда как наша команда была в изумлении. Этот президент не имел реальной власти. Его ведущий программист управлял делами компании подобно серому кардиналу.

Подготовка катастрофы

Мой коллега Скотт Мак-Грегор (Scott McGregor) поделился изложенной ниже историей, когда я спросил, знает ли он о случаях, когда проекты по разработке выходили из-под контроля из-за отсутствия проектирования взаимодействия. Его история печальна, и особенно тем, что типична для нашей отрасли.

Скотт – человек весьма талантливый, как видно из его хорошо написанной истории. Кроме того, он умелый проектировщик, с отличной родословной – академической и практической – как в разработке программного обеспечения, так и дизайне. Он присоединился к начинающей, с венчурным финансированием, компании в Кремниевой Долине. Основатели компании также имели достойное прошлое, включая несколько лет успешной работы в Apple. Однажды Скотт пригласил меня познакомиться с основателями и рассказать им о моей компании. Президент компании и вице-президент по техническим вопросам показали нашей команде, над чем работает компания, и произвели на нас впечатление. Идея продукта была великолепной. Она основывалась на нестандартном взгляде на производственные процессы. Продукт включал в себя небольшое количество хороших технологий, которые позволяли удовлетворить вполне очевидную потребность рынка. У компании было все для успеха – но отсутствовала практика проектирования взаимодействия. Вот история, рассказанная Скоттом:

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

Чтобы успеть сдать версию 1.2 к 31 декабря, мы просто приняли решение назначить версию 1.2 тому, что будет готово в пять вечера 31 декабря. Разработчики трудились, не имея фиксированной спецификации. Необходимость в значительных изменениях «без объявления войны» обнаружилась 29 декабря.

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