Возможности по инструкции
Автор
Андрей Кузьменко
Любой стандарт и регламент должен быть понятен и прозрачен для тех, кто будет его выполнять.
Есть мнение, что правила придуманы для того, чтобы их нарушать. Кажется, вся история человечества служит тому доказательством. Лорд Кельвин утверждал, что летающие машины весом тяжелее воздуха невозможны, а Билл Гейтс говорил о том, что 640 килобайт памяти более чем достаточно.
И вот мы летаем самолетами, а в кармане у нас лежит мобильный телефон, объему памяти которого позавидовал бы любой компьютер десятилетней давности. Давно ли все мы выходили в Интернет через коммутируемое модемное соединение, а теперь вот Wi-Fi да 4G. Возможности поистине потрясающие! Однако мы совершенно справедливо рассчитываем на то, что шаги процедуры по получению денег в банкомате будут неизменно приводить нас к наличным, а не к сообщению о блокировке карты.
Юриспруденция — это царство формальных правил. Мода и дизайн — это постоянное творчество. А что происходит в мире информационных технологий? Как его видят люди, чья работа каждый день приводит к изменению этого самого мира? На что следует обращать внимание и как понимать происходящее? Для того чтобы во всем этом разобраться и с пользой применить полученные знания на практике, мы обратимся к инструменту нейролингвистического программирования под названием «метапрограммы». Сегодня у нас в гостях «Процедуры — Возможности».
Позвольте представиться
Что же являет собой данная метапрограмма? Когда нужно выполнить какое-либо действие (инструкцию, задание), человек может придерживаться одной из двух стратегий: ориентации на процедуры или на возможности.
Для определения полюса данной метапрограммы следует задать вопрос «почему?». Если ваш собеседник говорит о нахождении новых вариантов и осуществлении выбора, он ориентирован на возможности. В его речи обязательно будут такие слова, как «альтернативы», «выбор», «способы», «пробовать», «варианты», «новый». Когда на вопрос «почему?» отвечают так, как если бы был задан вопрос «как?», — это верный признак того, что человек ориентирован на процедуры. Вы услышите словосочетания «проверенный способ», «зарекомендовавшая себя методика», «гарантированный результат», «последовательность шагов». Простой пример:
— Почему в качестве среды разработки вы используете NetBeans?
— Почитав тематические обзоры, я установил NetBeans, написал маленький тестовый пример, нажал Build и в результате получил проект, где в отдельной папке лежал готовый к использованию jar-файл. Процесс работы аналогичен таковому в Visual Studio: очевидная последовательность шагов приводит к гарантированному результату. Мне нравится.
Или так:
— NetBeans позволяет выбрать то, что тебе нужно: хочешь работать под Linux — нет проблем, хочешь под Windows — пожалуйста, программируешь на C++ или PHP — милости просим. Программа постоянно обновляется, появляются новые возможности. Я, кстати, много IDE перепробовал, но среди всех вариантов NetBeans лучший.
Мифы и рифы
С метапрограммой «Процедуры — Возможности» связано одно заблуждение, уходящее своими корнями в привычку навешивать ярлыки. Бытует мнение, что люди, у которых доминирует полюс «Процедуры», — это такие роботы, которые могут лишь «читать по бумажке». Отсутствие «фонтана» неожиданных идей совершенно непонятным образом отождествляется с бесталанностью и ограниченностью: дескать, не знает человек ответа на вопрос, почему люки круглые, значит он «не поэт». Применительно к ИТ-реалиям делается вывод о том, что Настоящий Программист должен быть «альтернативщиком», а «процедурщик», так, «на подхвате». Это весьма популярная «тема» среди работников кадровых агентств, занимающихся подбором персонала: мол, программист — профессия творческая, отрасль динамично развивается, соответственно, сотрудник должен мыслить в терминах возможностей. Однако программист — это не дизайнер и не стилист: хэш-таблица и алгоритм Кока — Янгера — Кассами не требуют индивидуального подхода и нового видения, для них вполне достаточно понимания и умения применять, когда есть в том необходимость. Кроме того, упускается из виду, что «альтернативщик» может находиться в сильной зависимости от своего настроения, состояния, вдохновения, в то время как «процедурщик» будет спокоен, собран и дотошен. И у кого производительность труда в данном случае выше?
Оно тебе зачем
Рассматривая метапрограмму «Процедуры — Возможности» применительно к мотивации человека, можно сказать, что с «альтернативщиком» нужно говорить о перспективах и новшествах, а с «процедурщиком» — о достоинствах конкретных способов и составляющих их шагов. Если сильно упростить, то «альтернативщик» считает, что всегда есть возможность выбрать нечто лучшее, а «процедурщик» считает, что всегда следует делать правильно.
Допустим, стоит задача обосновать перед руководителем введение практики парного программирования:
— Парное программирование — это отличный способ вывести процесс создания программного обеспечения на качественно новый уровень, получив в результате возможность сократить количество концептуальных ошибок в коде, снизить стоимость его поддержки в течение всего жизненного цикла, повысить производительность труда программистов.
А можно и так:
— Парное программирование — это хорошо зарекомендовавшая себя методика, позволяющая создавать качественное программное обеспечение за счет набора простых действий, применяемых в рамках одной процедуры: анализ задачи и методики решения с разных точек зрения, совместный контроль кода, появление элемента соревнования (кто первый предложит лучшее решение).
Шаг влево
Человек, находящийся вблизи полюса «Процедуры», очень часто убежден в том, что существует некий правильный алгоритм, выполняя который, можно обеспечить достижение необходимого результата. Та самая «серебряная пуля». Из этого непосредственно следует, что если алгоритм будет нарушен, то желаемый результат никоим образом не гарантирован. Для таких людей наличие плана или структуры жизненно необходимо. Эту особенность очень легко соотнести с организацией рабочего процесса: отдавая на откуп решение некоторой задачи «процедурщику», не следует ожидать от него инноваций. Он выполнит работу ровно так, как делал это раньше и в рамках тех средств, которыми пользовался в прошлом.
Для «процедурщика» любая незавершенная ситуация является сильным стрессогенным фактором. Если по какой-либо причине привычная последовательность действий или событий обрывается, то человек не может увязать новую ситуацию со старым опытом. Проверенные наработки оказываются бесполезны. Для иллюстрации здесь можно вспомнить старую байку о том, что, дескать, американцы потратили уйму денег на разработку ручки, способной писать в невесомости, в то время как советские космонавты пользовались простым карандашом. В состоянии стресса «процедурщик» может либо поддаться депрессивным настроениям, что обязательно скажется на мотивации и продуктивности работы всех, кто с ним взаимодействует, либо перейти к ворчанию и негативной критике, которая точно так же будет иметь неприятные последствия для совместной работы группы. Если у вас в команде есть такой «ворчун», то построение его эффективного взаимодействия с остальными членами группы будет выглядеть следующим образом: группа продуцирует некоторую новую идею, после чего «процедурщику» предлагается ее покритиковать, причем в самом прямом смысле этого слова. В зависимости от ситуации человек выскажет либо то, что конкретно помешает реализовать эту идею, либо то, какими скрытыми проблемами эта идея может обернуться в самый неожиданный момент.
Пример:
— Давайте в новом проекте будем использовать MongoDB!
— А как вы хотите это делать, когда у нас нет никого, кто бы представлял себе полную последовательность шагов по проектированию и реализации NoSQL-решения для промышленных проектов?
Или так:
— Работа с большими, часто денормализованными объектами связана с многочисленными проблемами при попытках произвольных запросов к данным, а как следствие, сильным падением производительности.
Вывод простой: надо дать возможность «процедурщику» сказать свое слово до того, как «заварилась каша». Он будет благодарен за то, что реально вовлечен в командную работу, а группа получит максимально полное представление о возможных проблемах.
А как быть в том случае, если нечто плохое уже случилось, и действовать приходится, так сказать, постфактум? Во-первых, не нужно «процедурщика» убеждать в том, что на самом деле все не так плохо, а могло бы быть еще хуже. Столь воспеваемая техника «во всем видеть позитив» в данном случае будет работать с точностью до наоборот! «Процедурщик» наглядно убедится в том, что вы, мягко говоря, не слишком адекватно представляете себе суть происходящего. Он прекрасно понимает, что нарушение технологии привело именно к тем проблемам, которые сейчас есть. Какой смысл радоваться отсутствию более серьезных проблем, если их все равно решать не нужно? Во-вторых, последовательно переводите разговор от обсуждения проблемы к поиску способов ее решения.
Шаг вправо
Теперь поговорим об «альтернативщиках». В их «избушке» тоже хватает «погремушек». Начнем с того, что «альтернативщики», являющиеся руководителями высокого уровня, могут в прямом смысле слова раздергать фирму на куски. Это, кстати, является одной из причин того, что многие интересные и перспективные стартапы разваливаются в самом начале своего существования: не успели сделать одно, как поступает команда делать другое. «Альтернативщики» никак не соотносят свои идеи с первым шагом их реализации, с точкой входа в процедуру по претворению мысли в жизнь. Нужны деньги? Ну, достанем где-нибудь. Например, возьмем кредит. Как будем кредит отдавать? Ну, как-нибудь отдадим, главное начать работу! А если не сможем отдать? Ну, придумаем что-нибудь! В том случае, если два человека находятся на противоположных полюсах обсуждаемой метапрограммы, «процедурщик» может на полном серьезе полагать, что «альтернативщик» скрывает от него важную информацию: говорит что, но не говорит как. И это может быть причиной очень серьезного конфликта, хотя возможностный человек совершенно искренне не будет понимать, в чем он виноват и как до такого вообще можно было додуматься!
Другой проблемой «альтернативщика» является его зараженность какой-либо идеей. Постоянно, к месту и не к месту он будет выдавать разнообразные варианты осуществления своей «мечты». Хорошим способом «приструнить» такого фантазера будет следующая фраза: «Ты так здорово все придумал! Приступай к делу». Понятно, что придумать и до конца реализовать — это вещи абсолютно не тождественные.
Следующая беда «альтернативщика» — неспособность следовать процедуре там, где это необходимо и обязательно. Например, есть внутрифирменный стандарт на оформление исходного кода: именование переменных и классов, размер отступов, способ расстановки скобок и т. д. Однако вместо того, чтобы делать как все, «альтернативщик» делает так, как считает нужным в данный момент. Минусы очевидны. Что можно сделать? Прежде всего, любой стандарт и регламент должен быть понятен и прозрачен для тех, кто будет его выполнять. Если у человека нет внутреннего согласия с правилами, он не будет им следовать. Поэтому составителям различного рода инструкций следует это учитывать. Любая формализация должна помогать людям в их повседневной работе, а не усложнять ее. Если руководитель не может содержательно объяснить суть формальной процедуры и ее преимущества (при наличии таковых), то это ставит под сомнение целесообразность данной процедуры.
Оглянись вокруг
Сравнивая систему высшего профессионального образования в России (СССР) и в западных странах, например США, можно заметить, что у нас подход возможностный, а у них — процедурный. Это не хорошо и не плохо. Это факт, который необходимо обязательно учитывать, если вы планируете сотрудничество с зарубежными партнерами. Если взглянуть на ассортимент профессиональной литературы в каком-либо американском книжном магазине, то окажется, что огромное количество книг, написанных высококлассными специалистами в самых разных областях деятельности, имеет в своем названии словосочетание «best practices», что в переводе означает «лучшие методы». Заметьте, не «best ideas», а именно «best practices»!
Кстати, отличие в образовательных подходах можно проследить и в такой области, как корпоративные тренинги. Я думаю, что любому читателю этой статьи случалось при покупке товара или заказе услуги сталкиваться с таким феноменом, как принудительное объяснение того, как товар или услуга работает, вместо собственно продажи. Допустим, вам нужна соковыжималка. Продавец подробно рассказывает, какие соки можно приготовить, что для этого нужно сделать, как будет выглядеть результат ее работы, какие кнопки нужно нажимать и т. д. В определенный момент у вас создается ощущение, что тут какой-то подвох... А тут нет никакого подвоха, просто продавец прошел тренинг по продажам, разработанный где-нибудь на просторах штата Мэриленд.
А теперь спроецируем данный пример на наши информационно-технологические нужды. Допустим, есть желание построить процесс разработки программного обеспечения в соответствии с технологиями и практиками Agile. Находим тренинговый центр, заказываем семинар, проводим его, щедро оплатив, а ожидаемого результата, увы, нет. Почему? Исключив такие причины, как профнепригодность одной стороны и некомпетентность другой, оставим несовпадение «их» подходов и «нашего» менталитета. И в масштабах страны это очень серьезная проблема, поскольку специалистов, способных оценить пригодность западных образовательных продуктов отечественным реалиям, ничтожно малый процент. А образовательные центры, которые сознательно адаптируют информационные продукты, вообще единичны.
Последнее слово
Несмотря на то, что обсуждаемая выше метапрограмма имеет ярко выраженную дихотомию, она является шкальной. Это значит, что помимо явных «процедурщиков» и «альтернативщиков» есть люди, находящиеся на разном расстоянии от обозначенных полюсов. Задача эффективной коммуникации — понять мотивации своего собеседника, а вовсе не приклеивать ярлыки к его личности. Удачи, мой читатель!
Опубликовано 24.12.2012