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

Опубликовано в выпуске авторского блога
Елены Маркушиной на сайте Harvard Business Review

– так называется книга 1999 года Алана Купера, создателя Visual Basic и признанного авторитета в мире информационных технологий. Вряд ли можно было ожидать, что кто-то из именитых программистов вдруг вывернет напоказ изнанку айтишного подхода к реальному бизнесу. Но это произошло! Оказалось, что руководитель 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-отрасли и, в конце концов, для естественного отбора. Ведь уважать партнера – это так естественно! Или нет?