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

Опубликовано на сайте журнала Harvard Business Review 25.05.2008 (блог №14 на тогдашнем hbr-russia.ru). Затем на сайте Альянса Разработчиков Программного Обеспечения Silicon Taiga (Silicontaiga.ru) первого президента Ассоциации РУССОФТ Булата Накиевича Гайфуллина.
Елена Маркушина

25 МАЯ / 2008

Вы находитесь на сайте автора статьи. Блог по темам менеджмента роста и управления изменениями размещён на Дзен. Читать эту статью на блоге >>

«Психбольница в руках пациентов» – так называется книга 1999 года создателя Visual Basic* и признанного авторитета в мире информационных технологий Алана Купера. Вряд ли можно было ожидать, что кто-то из именитых программистов вдруг вывернет напоказ изнанку айтишного подхода к реальному бизнесу. Но это произошло! Оказалось, что руководитель IT-отдела нашей компании тоже читал эту книгу. Мы оба вспомнили о ней на рабочей встрече, посвящённой текущим проектам автоматизации. Те заметные перемены, которые происходили в отношениях «Заказчик – Разработчик» («бизнесмен – программист»), не могли не вызвать бурного обсуждения.
Алан Купер и его книга "Психбольница в руках пациентов"
Мы (профсообщество Kinsmark.com) впервые написали о книге в 2005 году. Тогда на сайте «Управление изменениями в компании» была размещена одностраничная цитата. В ней был такой эпизод:
На собрании присутствовал президент, весьма сведущий деловой человек, основавший компанию, а также ведущий программист, ответственный за создание продукта. Президент показал нам продукт и продемонстрировал его мощь, которая была для нас очевидна, как и то, что этой мощью сложно управлять – интерфейс продукта был чрезмерно сложен. Наша команда проектировщиков быстро поняла, что программисты «проектировали» этот продукт по ходу написания кода, – примерно как бобер «проектирует» свою плотину во время её строительства.

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

Ведущий разработчик потряс нас просьбой не вносить изменения во взаимодействия продукта с пользователем. Он считал, что в этой области проблем нет. Ему казалось, что в положении продукта на рынке виноваты недостаточно сведущие в его применении маркетологи компании. Он хотел, чтобы мы подготовили внутренние рекламные материалы, позволяющие маркетологам работать эффективнее. Он полностью отрицал наличие недостатков в продукте, несмотря на их неопровержимые свидетельства – в виде наступающего «более слабого» конкурента.
То есть для тех, для кого любая автоматизация – серьёзный повод для изменений в компании, эта книга стала своей. Теперь на совещаниях с участием CEO, начальника IT-отдела и сторонних программистов мы были вооружены авторитетным мнением из стана оппонентов.

Трудности перевода и ответственность

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

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

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

За всю многолетнюю практику в тесном взаимодействии с IT-подрядчиками (как с разработчиками своего, так и внедренцами чужого ПО) я не припомню случая, чтобы клиент-Заказчик уговаривал IT-компанию «взять его деньги». Но вот Спрос вырос и… «испортил» Предложение.
Елена Маркушина. IT-проект как повод для организационных изменений
Руководитель фирмы, у которой мы заказали семинар о возможностях одного из продуктов «1С» (и обсуждали план семинара не одну неделю), отменил мероприятие за два часа до его начала. Основание – «деньги не дошли». Их представитель не знал, как извиняться, уговаривал наших топов «собрать кворум» в другой раз. Его босс как-то не принял во внимание, что правильный счёт (без ошибок) они нам выставили под Первое мая. Там признавали, что презентовать потенциальному клиенту ПО за его же деньги – странно, но продолжали инвестировать в отношения полное наплевательтво... К сожалению, это не стало для меня новостью.

В начале 2000-х я работала директором по маркетингу в одной консалтинговой компании, продвигающей свой IT-продукт и методологию описания организации. И тогда, и позднее мне довелось прочувствовать то, о чем писал Купер. Бес интеллектуального превосходства нашёл в IT благоприятную среду для обитания, развлечений и экспериментов. Менеджеры всех уровней на заводах и фабриках якобы слишком глупы, чтобы понять сложность и оценить красоту простыней машинного кода. Проектировщик взаимодействия? А кто это? Тот, который интерфейс проектирует? Нет? Тогда не знаем таких… Это был бесценный опыт, благодаря которому я воспринимаю нынешние тенденции конца нулевых не как трагичные, а как забавные. Рыночная конъюнктура лишь сделала явным отношение программистов к заказчикам. Таким оно было всегда, просто лучше скрывалось.


Что может изменить у себя Заказчик ПО

Мы изменили свою партнерскую политику. Теперь громкое имя IT-компании и опыт её внедрений «где-то там, где нас нет» не считаются преимуществом. Мы усовершенствовали тендерные процессы и стали оценивать в деньгах варианты долгосрочного сотрудничества. Можно сказать, что мы с порога стали сообщать потенциальным партнёрам, что именно для нас важно в отношениях с программистами. Теперь мы делаем предложение «в одно окно» один раз, сразу сообщая, на какие компромиссы готовы идти и чем можем быть интересны для подрядчика как в рамках проекта, так и после него.

Купер рассказывает в книге о том, как разработчику ПО создавать профили пользователей. Это очень непростая работа проектировщика взаимодействия пользователя с программой. Качество этой работы – залог создания удобного юзабилити. Чтобы быть готовыми к возможным вопросам сильного разработчика, мы с нашим IT отделом объединили усилия и насколько смогли описали укрупнённые портреты наших пользователей. И мы с нетерпением ждали случая, когда сможем наконец рассмотреть воочию работу человека, которому Купер отвёл в своей книге главную роль. Однако раньше того, как мы подписали договор с внешними программистами, мы успели убедиться в важности этой роли в работе с нашими собственными гениями.

Проектировщик взаимодействия

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

«Проектировщик взаимодействия» – это по сути одна из функций директора по развитию организации. Того самого, который владеет Управлением Изменениями, но не HR-овским (холическим), а системным (орг. импрувментом). Могут ли компании тонко организованных умников обходиться без такого напарника? Могут ли не обижаться на глупые вопросы пользователей и смешки конкурентов? Безусловно. Но такое по плечу лишь выдающимся компаниям.

«В 1986 году компания Мiсrоsоft поторопилась на рынок с первой версией Windows, которая была столь смехотворна, что заслуженно стала предметом шуток. Шесть месяцев спустя Мiсrоsоft выпустила версию 1.03 и исправила некоторые дефекты. Годом позже Microsoft выпустила версию 1.1, а затем версию 2.01. На каждом этапе развития продукта разработчики пытались разрешить проблемы, созданные в предыдущей версии. Наконец, четыре года спустя после выпуска первой версии, Мiсrоsоft представила Windows 3.0, и все перестали смеяться. Мало какие компании в этой индустрии имеют такое упорство и финансовые возможности, позволяющие выдержать четыре года публичного унижения и добиться, наконец, приемлемого результата. При этом все наблюдают, как лидер де-факто слепо спотыкается практически до победного конца, после чего делают очевидный вывод о том, что именно так и нужно действовать».
Говоря о роли внутренних проектировщиков взаимодействия, Купер по сути говорит об изменениях, которые должны произойти в IT-компании:
«Руководство должно взять на себя ответственность и включать проектирование в процесс до того, как начато программирование. Если проводить аналогии, проектирование взаимодействия – это архитектура, а не дизайн интерьеров. Оно определяет, куда будет залит бетон фундамента здания, а не какой будет самый подходящий материал для портьер на окна в его помещениях.

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

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

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

Компания, сорвавшая семинар и потерявшая потенциальный бюджет в 680 тыс. (не «у.е.», но все же), получила претензионное письмо с запросом о возврате наших смешных 23 200 рублей за семинар и свою законную строчку в черном списке. Правда, последнее было важно скорее для нас, чем для этой компании: будучи одним из крупнейших франчайзи «1С» в Питере, она не останется без клиентов. А мы уже на третий день заключили соглашение с новым партнёром, которым пока вполне довольны. Так оправдал себя наш подход: иметь минимум два запасных варианта по каждому из текущих проектов.

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

Программисты, которые пошли работать и пропали, вдруг забеспокоились, – что это мы не звоним. И, заглянув в гости, оторопели от новости, что работы идут полным ходом, но… с другими программистами.

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

Ещё по теме: Вход в ИИ для директора по развитию. ИИ для бизнеса

Оставить комментарий можно под этой статьёй на Дзен.