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

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

— так называется книга Алана Купера, создателя Visual Basic2 и признанного авторитета в мире информационных технологий. Вряд ли можно было ожидать, что кто-нибудь из именитых айтишников вдруг захочет вывернуть напоказ изнанку программистского подхода к реальному бизнесу. Но это произошло! Оказалось, что и руководитель отдела IT нашей компании тоже читал эту книжку раньше [она вышла в 2005-м]. Мы оба вспомнили о ней на рабочей встрече, посвященной текущим проектам автоматизации. Те заметные перемены, которые произошли в отношениях «заказчик — исполнитель» («бизнесмен — программист»), не могли не стать темой нашего пристрастного обсуждения.

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

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

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

Но это не всё. За всю многолетнюю практику работы в тесном взаимодействии с внешними программистами (как и с IT-внедренцами) я не припомню случая, чтобы клиент уговаривал IT-партнёра «взять его деньги». Но вот Спрос вырос и… «испортил» Предложение. 

Руководитель внедренческой компании, у которой мы заказали семинар о возможностях одного из продуктов «1С» (и обсуждали план семинара не одну неделю), отменил мероприятие за два часа до его начала. Основание — «деньги не дошли». Связной менеджер той стороны не знал, как извиняться, уговаривал наших топов «собрать кворум» в другой раз. Его босс как-то не принял во внимание, что правильный счёт (без ошибок) нам был выставлен под Первое мая. Даже признавая, что презентовать потенциальному клиенту продукт за его же деньги — странно, там продолжали инвестировать в отношения полное наплевательтво.

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

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

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

Проектировщик взаимодействия — очень важная роль в IT-команде. Понять, как потенциальный пользователь будет на самом деле взаимодействовать с продуктом, залог создания удобного юзабилити. Но есть и другая роль — проектировщика взаимодействия команды программистов с Заказчиком. Я бы не стала упрощать, мол, всё сводится к овладению двумя разными русскими языками и более высокой коммуникабельности, а призываю обе стороны овладеть приёмами социально-ролевого анализа. Умея читать биологические "установки по умолчанию" своих партнёров, вы сможете понимать их язык, логику и прогнозировать поведение. Программисты зачастую люди не только умные, но и чувствительные, поэтому фальшь и всякие психологические приёмчики они распознают издалека. Вам придётся не просто больше трудиться над отношениями, но знать то, что неизвестно большинству программистов — социогеномику.

Могут ли компании тонко организованных умников обходиться без такого помощника? Могут ли не обижаться на глупые вопросы пользователей и смешки конкурентов? Безусловно. Но такое по плечу лишь выдающимся компаниям.

«В 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-компании:

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

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

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

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

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