Архив рубрики: pcweek

Персики, лимоны, рынок вакансий в IT и как все это связано

Эта статья подготовлена для блогов журнала PCWeek.
В 2001 году Джордж Акерлофа получил нобелевскую премию по экономике за анализ рынков с ассиметричной информацией. Ходит байка, что когда он впервые отправил статью про персики и лимоны в экономический журнал, ее отклонили, посоветовав такие статьи отправлять в журналы по садоводству. Что же за понятия персиков и лимонов ввел Акерлофа, и какое отношение они имеют к рынкам с ассиметричной информацией? И вообще, причем здесь вакансии в IT? Вот об этом и предлагаю поговорить.

Одним из очень ярких примеров рынка персиков и лимонов является рынок подержанных автомобилей. Под персиком на нем понимается хороший автомобиль, под лимоном - автомобиль, только выглядящий как хороший, но таковым не являющийся. Покупатель, в отличие от продавца, не владеет информацией о том, какой автомобиль перед ним. Это и есть рынок с ассиметричной информацией. Из-за такой асимметрии продавец персика не может запросить цену выше, чем стоящий рядом продавец лимона. Ведь в этом случае покупатель купит лимон, поскольку при осмотре персик и лимон выглядят одинаково.
Теперь от рынка подержанных автомобилей перейдем к вакансиям в IT. На рынке труда ситуация очень похожа. Кандидатов можно условно разделить  на две группы: лимоны (вроде что-то и умеют, но работать и учиться особо не хотят) и персики (может, не всегда много знают, но много и продуктивно работают, хотят обучаться, расти). Понятно, что кандидаты, как правило, адекватно оценивают себя, а вот рекрутеры не всегда. Отличить лимон от персика, особенно, когда лимон уже прошел несколько собеседований, а персик пришел только на первое-второе, практически невозможно. Ситуация усугубляется еще тем, что рекрутер, возможно, и хочет персик, но, имея «лимит по цене», готов взять и лимон, лишь бы закрыть вакансию. А выбирая лимон, он еще и деньги «сэкономит». Сэкономит в кавычках, так как после покупки лимона компании в достаточно краткосрочной перспективе придется его увольнять, открывать вакансию и снова начинать круг поиска.
Давайте взглянем на эту ситуацию с точки зрения теории игр. Рассмотрим атомарную игру, в которой рекрутер предлагает оффер, а кандидат принимает или отклоняет его. Для простоты, пусть лимон приносит компании 50 единиц прибыли, а персик 200. В случае, когда лимон и персик не знают своей стоимости, выставив цену в 125 единиц, набирая одинаковое количество лимонов и персиков, на каждом лимоне мы будем терять 75 единиц, а на персике получать 75 дополнительных. Глядя на существующий рынок труда, мало кто согласится, что количество лимонов и персиков на нем одинаковое. Получается, что даже в условии симметрии информации ( когда ни рекрутер, ни кандидат не знают, кто он - персик или лимон) мы остаемся на нуле только при одинаковом количестве лимонов и персиков на рынке. Но, если цена всех будет одинакова, то персики с рынка будут вымываться: зачем учиться, если все равно будешь стоить 125?
Ситуация становится еще хуже, когда информация асимметрична. Персик, получив предложение в 125, от него откажется, ведь он знает, что его цена 200. А вот лимон, услышав 125, согласится, ведь он-то знает, что его красная цена 50. К чему же это приводит:
  1.      . Лимоны переоценены
  2.      . Персики недооценивают, становиться ими нет резона и…
  3.      . Рынок персиков исчезает

Собственно за эти выводы Джордж Акерлофа и получил нобелевскую премию по экономике.
Как же можно предотвратить исчезновение рынка персиков? Самое главное - это не соглашаться на лимон, если вам нужен персик. Очень показательный пример описан в одном из номеров  Harvard Business Review Россия в заметке "Во что обойдутся низкие зарплаты", где сравнивается стратегия Wal-Mart, проявляющаяся, в частности, в жестком ограничении зарплат сотрудников, и его прямого конкурента Costco, у которого относительные затраты на персонал существенно выше, а число сотрудников во столько же раз меньше. Показано, что в долгосрочной перспективе Costco получает надежный и эффективный персонал, а также низкую текучесть кадров. Ведь наличие талантов в организации в конечном итоге намного важнее размеров их оплаты труда.
Внимательный читатель задаст вопрос: «А как же отличить персик, ведь у нас рынок с ассиметричной информацией?» А вот это второй шаг. Должен быть изменен подход к рекрутингу IT-персонала. Сейчас на первом собеседовании соискателя на вакансию встречает, как правило, молодая девочка без существенного опыта за плечами. Она задает типовые вопросы и предлагает типовую ставку. Как на это реагируют лимоны и персики, можно посмотреть в описании игры выше. Да, это дорого - проводить первичные собеседования высококвалифицированным, опытным сотрудником. Но здесь возникает вопрос: «А не дорого ли нам обходится регулярный найм лимонов, и что мы будем делать, когда рынок персиков окончательно схлопнется?»

О KPI и мотивации

Эта статья подготовлена для блогов журнала PCWeek.

«Наиболее важные факторы, необходимые для управления любой организацией, как правило, неизвестны и количественно неопределимы»
Э. Деминг, "Выход из кризиса"
Открывая новый проект, запуская изменения в существующем процессе, мы придумываем метрики и задаем KPI. И, как правило, за достижение этих KPI назначаются ответственные, которые получат бонусы или будут наказаны за несоответствие реальности целевым индикаторам. Предполагается, что наличие таких показателей должно стимулировать исполнителей. Но как на самом деле все это работает? В большинстве случаев – странно.

Если бизнесом организации не является разработка программного обеспечения или аутсорсинг IT-услуг, то практически невозможно привязать показатели подразделений IT к ее экономическим результатам. Например, бизнес запускает новый вид услуг, IT внедряет соответствующую инфраструктуру, но прибыль запущенная услуга не приносит. Кто виноват? IT или экономическая ситуация на рынке? Или другой пример: IT повысило надежность предоставляемых бизнесу сервисов с 95% до 98%. Бизнес получил прибыль на 10% больше по сравнению с предыдущим годом. Это достижение IT или особенность все той же экономической ситуации? В результате, появляются KPI, не имеющие никакого отношения к полезности IT для бизнеса. Сотрудники не понимают, зачем требуются такие показатели. А все то, что люди не понимают, или вообще не делается, или делается спустя рукава. А раз делается плохо, то вводится материальная мотивация. И тут возникает вторая проблема – локальные экстремумы.
В IT, в связи с производственными особенностями, работают умные люди. Поэтому, когда необходимость KPI не понятна, а за несоответствие показателю будут наказывать рублем (да, неполучение премии - это наказание), сотрудники начинают искать локальный экстремум. В нем KPI должен быть выполнен, а вот работы на это должно быть затрачено по минимуму. Как это проявляется? Допустим, мы ставим KPI программистам по количеству багов. В этом случае обнаружение каждой ошибки в тестировании будет выливаться в целое представление. «Нет, это не ошибка! Нет, это не моя ошибка, а ошибка внешней библиотеки!» А через какое-то время может выясниться, что разработчик договорился с тестировщиком, и тот сообщает об обнаруженных ошибках неофициально. В итоге в багтрекере багов нет, а в продукте есть. Конечно, такие KPI дают эффект на первом этапе, но потом дела будут идти все хуже и хуже, так как все будут стремиться обмануть систему, чтобы соответствовать именно требуемому показателю, пусть даже в ущерб компании. Хуже всего то, что менеджеры, в надежде избежать такой ситуации, добавляют третью проблему – избыточную сложность.
«Ах, вы научились обманывать KPI? Давайте добавим еще вот эту, а потом вот эту метрики». И тогда мало того, что начинается «гонка щита и меча» между метриками и теми, кто пытается их обмануть, так еще и на поддержание этой системы тратятся огромные ресурсы. Бывает, что это заканчивается коллапсом системы, так как через достаточно небольшое время уже никто не понимает, что считается, как считается, как проверяется.
Что же делать? Во-первых, не применять KPI, не понятные команде. Необходимо создавать систему, в которой люди могут делать свою работу. Ведь мы их приглашали на работу именно потому, что они могут и, самое главное, хотят работать, развиваться, расти. Во-вторых, не нужно придумывать метрику под KPI. Должна быть поставлена некая цель и подобраны практики, позволяющие ее достичь. Должна быть выбрана максимально простая и прозрачная метрика, позволяющая измерить эффективность применения практики. Должны быть назначены понятные и достижимые целевые значения метрики. И только тогда все это соберется в KPI. В-третьих, KPI должен быть принят исполнителями, они должны понимать, как его выполнение улучшит именно их работу.
Если эти пункты кажутся слишком сложными, то есть путь проще: открываем http://kpilibrary.com, вводим ключевое слово и берем верхний KPI из результатов поиска. На сайте десятки тысяч KPI, почему бы и не взять из них первый попавшийся?

Как изменить поведение сотрудников

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

Человеческий мозг принято делить на творческое (правое) и рациональное (левое) полушария. Но кроме творческого и рационального начала, правое полушарие отвечает за потребности, а левое -за стратегии по их удовлетворению. То есть, именно правое полушарие получает сигнал от желудка и вырабатывает потребность : «Хочу есть». Причем потребности эти могут быть как физиологические, так и расположенные выше по пирамиде Маслоу. Именно это полушарие сообщает нам о потребности в безопасности, быть признанным и т.д. Все эти потребности распределяются правым полушарием по приоритетам, после чего в процесс вступает левое полушарие. За работу со стратегиями отвечают лобные и теменные доли. Лобные - это то, что принято называть разумом. Мы прибегаем к нему, когда, попадая в новую ситуацию, придумываем новые стратегии. Но в большинстве случаев лобные доли ленятся, и работу на себя берет теменная часть мозга. А она отвечает за использование уже имеющихся стратегий. И, так же, как правое полушарие расставляет приоритеты потребностям, левое полушарие приоритезирует стратегии: «В прошлый раз я опоздал на работу и сказал, что попал в пробку. Меня не ругали, значит, эту стратегию с придумыванием отговорок можно применить и в следующий раз».
Исходя из всего выше сказанного, для того, чтобы изменить поведение, обусловленное стратегиями, достаточно понизить приоритет стратегий контрпродуктивных и повысить приоритет стратегий продуктивных. Воспользуемся любимым инструментом многих менеджеров - матрицей два на два - и проведем с ее помощью группировку всех методов, позволяющих влиять на приоритет стратегий:
Зеленым цветом выделены так называемые «добрые методы воздействия», они нацелены на то, чтобы осуществление полезного деяния человеком получало подкрепление в виде положительных эмоций. «Злые методы», выделенные на рисунке красным, заключаются в намеренном применении страданий с целью изменить нежелательное поведение.  По большому счету, «злые методы» - это менеджерские методы. Добрые – лидерские. Видимо, благодаря работам Беррес Фредерик Скиннера и предложенной им теории оперантного научения, и закрепилась слава именно лидерских подходов. Беррес одним из первых выдвинул тезис, что стабильные изменения поведения достигаются только с помощью положительных стимулов. Но нужно понимать, что лидерские методы работают не всегда. Бывают ситуации, когда необходимо избавиться от нежелательного поведения, в которых приходится применять злые-менеджерские методы. Например, сотрудник постоянно опаздывает на работу, не сообщает вовремя о проблемах, критикует всю команду, обесценивает чужую работу и т.д. Во всех этих случаях нет полезного поведения, которое необходимо подкреплять. А есть деструктивное, которое необходимо искоренять.
К злым методам относят:
  1. Угасание
  2. Отрицательное подкрепление
  3. Ограничение
  4. Наказание

Угасаниебазируется на отказе человеку в реакции. Поведение, не получающее ни положительного, ни отрицательного подкрепления, со временем угаснет. Особенно этот метод хорошо работает с поведением, имеющим словесное выражение. К примеру, если на постоянную критику команды одним из ее членов никто не будет реагировать, то, не получая подкрепления, эта стратегия сойдет на нет. Ведь человек критикует не просто так, а потому, что у него есть потребность, например, в получении статуса. И он эту потребность пытался удовлетворить, «опуская» всех остальных. Нет реакции - нет удовлетворения потребности, стратегия откладывается, как не приносящая результата.
Отрицательное подкрепление заключается в любом неприятном событии или стимуле, пусть даже весьма слабом, который следует немедленно после действия или во время действия. В отличие от наказания, его нельзя применить через час, день, неделю. Достаточно часто отрицательное подкрепление может быть минимальным. Опоздал сотрудник на работу? В большинстве случаев, чтобы поведение изменилось, может быть достаточно хмурого взгляда или раздраженного приветствия от человека, которого опаздывающий уважает. Не нужно забывать, что у того же опоздания могут быть и объективные причины, например, заболел член семьи, отводящий ребенка в детский сад, и сейчас у сотрудника нет возможности прийти вовремя. Как только внешний фактор исчезнет, без всяких воздействий со стороны руководителя прекратится и неконструктивное поведение. Нужно просто разобраться в мотивах. Кстати, если опоздание обусловлено желанием вечером подольше почитать фейсбучек, то отрицательное подкрепление не сработает по той простой причине, что фейсбучек был вчера, а отрицательное подкрепление -сегодня.
Ограничение – один из основных менеджерских инструментов. Он заключается в невозможности осуществить нежелательную стратегию. Сотрудник пытается сидеть во время ежедневного стендапа? Проводите митинг в комнате, где сидеть вообще не на чем. Сотрудник постоянно критикует применяемые в команде процессы? Введите ограничение, что критиковать процессы можно только на ретроспективе. Увольнение сотрудника - это ведь тоже ограничение. У него больше нет возможности вести себя неправильно, по крайней мере, в рамках данной компании.
Наказание. Если предыдущий метод был основным, то этот является излюбленным методом очень многих руководителей. Когда поведение сотрудника неправильное, мы в первую очередь думаем о наказании: ругаем, снижаем зарплату, налагаем штрафы. К сожалению, этот метод работает очень плохо. Вроде и наказали за неконструктивное поведение, а оно возникает снова. Большинство руководителей просто пытается увеличить наказание. Чтобы наказание было действенным, должно сойтись много факторов:
  • Поведение должно находиться под контролем получающего наказание. Если человек вынужден отводить ребенка в детский сад за заболевшего члена семьи, то, даже наказывая его штрафом, мы не изменим поведение: сад от нашего штрафа раньше не откроется, да и заболевший быстрее не выздоровеет.
  • Сотруднику должно быть понятно, за какое поведение он не получит санкций. Если он не понимает, на что менять поведение, то он его и не изменит. Всегда нужно объяснять, что это наказание, например, не за несданный вовремя отчет. Наказание за то, что руководитель узнал о проблеме в момент, когда отчет понадобился, а не заранее, когда можно было поручить эту работу другому или помочь в работе над отчетом другим способом.
  • Наказания применяются намного реже, чем поощрения. Да, это опять отсылка к работам Скиннера: в долгосрочной перспективе работают только положительные методы.
  • Наказание воспринимается как справедливое. Это один из самых тонких моментов, но и один из самых важных. Если наказание воспринимается неадекватно легким, то на изменение поведения оно не повлияет. Если неадекватно тяжелым, то может и повлияет, но вызовет озлобленность, желание отомстить, приведет к конфликту и т.д.
  • Страх перед будущим наказанием намного больше немедленных выгод от негативного поведения. Очень часто руководители грешат тем, что сразу после нежелательного поведения на волне эмоций наказывают строго, но если денек «пошифроваться», то наказания не будет или оно будет незначительным. Это провоцирует сотрудника скрываться, отключать телефон и вообще вести себя как маленький ребенок, закрывающий глаза, чтобы не видеть буку, вместо того, чтобы решать проблему прямо сейчас. Чем позже руководитель применяет наказание сотрудника , тем оно должно быть сильнее, чтобы у наказываемого не было стимула скрывать возникающие проблемы с целью смягчения наказания.
Подводя итоги, остается только пожелать, чтобы нам всем приходилось как можно реже применять все то, что описывается в этой статье, и как можно чаще то, что на схеме находится в зеленых четвертях. Но об этом в другой раз.

Оценка требований по Кано

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



При первом приближении взятие в работу должно идти в следующем порядке: правая-верхняя четверть, левая верхняя четверть, правая нижняя. На левую нижнюю никогда не хватает времени. Про оценку сложности можно говорить очень много, и об этом в другой раз. Сегодня предлагаю обсудить оценку полезности, предложенную Нориаки Канов начале 80-х годов прошлого века. В рамках этой модели все требования (функции будущего продукта) разбиваются на 5 групп:
1.       Привлекательные характеристики. При наличии этих параметров пользователи будут испытывать удовлетворение. Однако, если этих функций в продукте не будет, к негативным эффектам это не приведет. Именно об этих характеристиках продукта будет рассказывать «сарафанное радио».
2.       Одномерные характеристики.  Эти характеристики вызывают удовлетворенность, если они есть, и неудовлетворенность, если их нет. К таким параметрам может относиться скорость работы приложения. При низкой скорости откликов – негатив, при высокой – удовлетворение.
3.       Обязательные характеристики. Их наличие считается обязательным, поэтому отсутствие вызывает негатив. К примеру, если ваш текстовый редактор не позволяет набирать текст, то вы его не продадите.
4.       Неважные характеристики. Пользователь к ним нейтрален. Например, для большинства пользователей того-же текстового редактора функция подсчета символов в тексте – нейтральная.
5.       Нежелательные характеристики. Это все то, что будет вызывать у пользователя раздражение. Как правило, эти характеристики возникают потому, что так было проще разрабатывать.
Для того, чтобы отнести требование к одной из этих групп, необходимо провести анкетирование пользователей. По каждому требованию задаются два вопроса:
1.       Насколько вам понравится наличие … в продукте?
2.       Как вы отнесетесь к отсутствию … в продукте?
На каждый вопрос  пользователь может выбрать один из пяти вариантов ответа:
1.       Мне это нравится
2.       Я ожидаю именно этого
3.       Мне все равно
4.       Я могу это терпеть
5.       Мне это не нравится
Для обработки полученных в опросе результатов применяется оценочная таблица следующего вида:

В нее заносится, сколько человек ответило именно так на положительный и отрицательный вопрос о требовании. Допустим, если вы анализируете требование «наличие двухфакторной авторизации», и  на положительный вопрос (наличие двухфакторной авторизации) пользователь ответил «Ожидаю», а на отрицательный (отсутствие двухфакторной авторизации) – «Могу терпеть», то его голос будет добавлен вот в эту ячейку:

В результате получим некоторые значения в зонах нашей таблицы. Если основная масса ответов о требовании пришлась на зону «Привлекательно», то, значит, эта функция может стать фишкой приложения. Когда основная масса находится в зоне «Обязательно», выбора нет, этот функционал должен быть реализован. Если лидирует зона «Нежелательно», будьте уверены, этот  функционал пользователи не оценят. Зона «Не важно» оставляет простор для выбора. И самая интересная зона - «Непонятно». Если в этой зоне много голосов, от опрашиваемые не поняли функцию, поскольку не может одновременно нравится и наличие этой функции, и ее отсутствие.
Пользуясь моделью Кано, необходимо понимать, что она не всегда применима. Например, она не может решить проблему, изложенную в теореме Эрроу. Да и Генри Форд говорил: «Если бы я слушал своих клиентов, мне бы пришлось дать им более быструю лошадь». Но если вас это не останавливает, то предложенная методика позволяет неплохо  ранжировать ценность требований в списке.
Для тех, кто захочет попробовать методику, но не готов в ручном режиме обрабатывать результаты, есть бесплатный сайт: http://www.kanosurvey.com/

Драйверы и разработка программного обеспечения


Эта статья подготовлена для блогов журнала PCWeek.

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.

Предлагаю поговорить об одном из взглядов на проблему, озвученную в эпиграфе. Почему, сколько бы времени мы не закладывали на задачу, она решается точно в срок или позже? Тайби Кэлер, дорабатывая теорию транзитивного анализа, ввел понятие микросценариев (микроскриптов) поведения, которые могут длиться от нескольких секунд до нескольких минут. Контрпродуктивные сценарии Т. Кэлер выделил в отдельную группу и назвал драйверами. При дословном переводе мы получаем этаких кучеров, которые заставляют нас бежать по однажды проторенному маршруту, не давая свернуть.
Известны пять драйверов :
1.Будь лучшим
2.Радуй других
3.Старайся
4.Будь сильным
5.Спеши
Кстати, относительно проявления драйверов в профессиональной деятельности чаще употребляют выражение «личностный стиль» или «рабочий стиль». Давайте рассмотрим эти драйверы и то, как они влияют на нашу работу.
Будь лучшим
Как и остальные драйверы, этот получил свое название от благих намерений, которыми родители потчивали всех нас в детстве. На первый взгляд, он выглядит вполне безобидным и даже полезным. Действительно, человек запрограммированный этим драйвером, как правило, эрудирован, проявляет интерес к новым знаниям и дискуссиям. Но, с другой стороны быть лучшим - это огромная ответственность, надо все знать и уметь, никогда нельзя ошибиться. Не зная ответа на вопрос, можно сослаться на громкую фамилию, особенно если книги этого автора никто не читал (Кнут, Страустрап у всех на слуху, но немногие осилили ту же «Теорию алгоритмов»). Начиная разбираться в уже существующем проекте, «лучший», обычно начинает с фразы: «А почему у вас все так плохо? Ведь лучше будет вот так!». А это «вот так» возвращает нас к затратам времени на решение задачи. Ведь ошибиться нельзя! Ага, задача на 5 часов? Хорошо! Построим план работ, выверим его до последней детали. Что, здесь «некрасивая» связка с другой системой? Ничего страшного, перепишем ее. Написали? Ого, остался еще один час на задачу, можно еще улучшить вот здесь и здесь, а также поправить вон в том модуле. Нет, он мне не нужен, но кто же так пишет? И вот, прошло уже не пять и даже не шесть часов, а улучшения продолжаются и продолжаются. Причем, даже остановиться не получается, так как ничего не работает, пока не доделаешь здесь и чуть-чуть вон там.
Для борьбы с этим драйвером необходимо понять, что ошибки — это несмертельно, снижение планки и установление реальных целей – это не конец света, а чуть меньше критики окружающих не ухудшит их мнение о вас, а, наоборот, улучшит.
Радуй других
Человек с этим драйвером вынес из детства волшебное решение: «если я буду всем нравиться, то все у меня будет хорошо». И вот у нас появляется безотказный коллега. С какой просьбой к нему не обратишься - он всегда рад помочь. Доотладить скрипт, доделать модуль, задержаться после работы. Да, такие люди всегда на хорошем счету у начальства, к ним хорошо относятся в коллективе. Но рано или поздно, особенно, если наш «душка» стал руководителем, объем просьб превышает разумные пределы, и человек, не умеющий сказать нет, начинает решать сто задач одновременно. У него на задачу целых пять часов, но ведь надо помочь Степану, да и Маша просила сходить с ней на обед. И даже если есть подчиненные, передать часть своих работ им не позволяет драйвер. Ведь они начнут относиться ко мне хуже, а этого нельзя допустить. И вот, сроки задачи сорваны, появляются невыполненные обещания, проваленные проекты. Похоже, что из-за желания нравиться другим сгорело больше руководителей проектов, чем по всем остальным причинам.
Для борьбы с этим драйвером нужно не только себя ставить на место других, но и других на место себя. Не надо «читать мысли», задавать больше вопросов и выяснять реальные потребности окружающих. И да, немного здорового эгоизма не помешает.
Старайся
Человек с этим драйвером верит в процесс. Если он будет стараться, то кто-то поможет ему: может быть, коллега, а, может, вселенная, и все будет хорошо. Не важен результат, ведь есть процесс, к которому прикладываются все силы. Ну, не получится сразу, попробую еще раз, а потом еще и еще… Вы уже узнали Сизифа. Зачем он тащит камень на гору? Почему он каждый раз скатывается? Все это не важно, главное - стараться. Начиная любое дело, носитель этого драйвера сначала продумывает пути отступления, ведь важнее сохранить статус-кво, чем идти вперед. Ах, на задачу пять часов? И я ее не решил? Но я ведь старался, я искал три часа в гугле, потом спрашивал у Пети. Я вон какую стратегию проработал для решения задачи, у меня только разветвлений на ней больше двух десятков. А результат? Ну да, нет результата. Но я ведь старался!
Чтобы победить этот драйвер, надо перестать гордиться процессом. Взялся за дело - доводи его до конца. Ориентация на результат - вот главный метод борьбы.
Будь сильным
Помните из детства: "Не плачь, ты же мальчик"? В результате образуется драйвер, заставляющий казаться сильным. Ведь если показать, что ты сильный, то проблема испугается и убежит. Обратиться за помощью к коллеге? Однозначное нет! Я ведь сильный! Посчитать риски, которые могут возникнуть в процессе работ? Зачем, ведь все пройдет идеально. А там, где будет неидеально - я сильный, я справлюсь. И вот, перед нами список задач, который можно решить только в идеальных условиях. Проблемы, возникающие в процессе решения задачи, будут до последнего преодолеваться в одиночку. А ведь можно еще пойти не по простому пути, а по сложному, а то вдруг кто-то усомнится в моей силе. Поэтому за пять минут до запланированного срока задачи проекта от человека с таким драйвером можно будет услышать: «Я думал, я все успею исправить».
Итак, если вы углядели в своем поведении этот драйвер, то расслабьтесь. Нет, не в смысле «Расслабьтесь, все у вас хорошо», а в смысле «Научитесь расслабляться, иногда быть слабым, и не стесняйтесь просить коллег о помощи».
Спеши
Этот драйвер редко бывает главной движущей силой. Как правило, он идет в комплекте с другим, более сильным драйвером, например, «Старайся». Человек начинает спешить не чтобы успеть, а чтобы не опоздать. В отличие от остальных драйверов, которые обещают волшебный результат, этот запугивает: «Если ты не будешь торопиться, то все пропало». Такие люди очень сильно подвержены манипуляциям на дефиците: «Еще чуть-чуть, и ты опоздаешь», «Осталось всего два часа до окончания оплаты» и т.д. Они всегда спешат, все время взгляд на часы, быстрая пулеметная речь. Получив задачу на пять часов, программист с этим драйвером бросится в работу, ведь надо успеть. Но у него очень быстро возникнут еще более срочные дела, которые надо успеть. Пришло новое письмо? Спеши, надо успеть прочитать! Возникла новая задача? Спеши, надо успеть забрать ее себе!
Для борьбы с этим драйвером нужно сложные задачи разбивать на более мелкие и в единицу времени решать только одну. И, самое главное, не стараться успеть все.
Если верить Тайби Кэлеру, то у всех нас, в той или иной мере, выражены эти драйверы. Какие-то более ярко, какие-то менее. Чем чаще мы даем драйверу власть над своим поведением, тем более естественен и привычен он будет для нас. Поэтому, узнав у себя описанные выше сценарии поведения, надо остановиться и подумать: «Может, пора отнять управление своей жизнью у драйвера и передать его себе?»

Парадигма Кеневина и разработка программного обеспечения

Эта статья подготовлена для блогов журнала PCWeek.
Теория запутанности (сложности), предложенная Дейвом Сноудоном в начале двадцать первого века, несмотря на свою молодость, уже нашла применение в кибернетике, менеджменте и биологии. Сегодня я предлагаю обсудить парадигму Кеневина в применении к разработке программного обеспечения.

Владеющие английским могут посмотреть вот это видео (ссылка http://www.youtube.com/watch?v=N7oz366X0-8), в котором сам автор описывает парадигму. Для остальных кратко изложу ее суть на русском.
Итак, в теории запутанности понятие «система» немного отличается от привычного многим, поэтому начну с нескольких определений:
Артефакт - материальный ресурс, имеющий определенное положение и реагирующий на действия агентов.
Агент - коллекция свойств, стратегий и возможностей для взаимодействия с артефактами и другими агентами.
Агентами могут быть как отдельные люди, так и группы людей, правила, идеи и т.д.
Система – некая сеть, включающая одну или несколько групп агентов, и, возможно, артефакты.
Обратите внимание, что в отличие от классического понимания систем, в данном определении отсутствует понятие цели.
В рамках парадигмы Кеневина все окружающие нас системы делятся на три большие группы. На одном конце оси координат находятся упорядоченные системы с жестко ограниченными агентами, характеризующиеся детерминированностью и независимостью от наблюдателя. К таким системам можно отнести конвейер, армию, разработку медицинского оборудования. На другом - хаотические системы, в которых агенты не зависимы от системы и друг от друга. Примером такой системы может быть попытка сплавиться по Ниагарскому водопаду в бочке и предсказать, как эту бочку с находящимся в ней человеком будет крутить и куда выбросит. Ну, а между ними находятся запутанные системы. Такие системы, с одной стороны, ограничивают своих агентов, а с другой - агенты оказывают влияние на систему и друг на друга, в результате чего все это коэволюционирует, и процесс этот является необратимым. Примером может послужить большинство коммерческих организаций, живые организмы и даже кружки по интересам.

Для упорядоченных систем характерно наличие экспертов. В простых системах мнения экспертов сходятся, и есть понятие лучших практик (Best practice). Достаточно действовать в соответствии с этими практиками, и результат будет гарантирован. Все, кто не придерживаются Best practice, начинают проигрывать. В упорядоченных сложных системах разные эксперты могут предлагать разные пути решения, получая одинаково хорошие результаты. Для примера можно взять двух хороших программистов и попросить их выполнить некую задачу. Решения будут отличаться, а вот результаты будет практически идентичными. В данном случае идеального пути нет, но можно выделить несколько достаточно правильных.
В запутанных системах экспертов нет. Да оно и понятно, ведь такие системы имеют множество агентов, взаимосвязи между которыми разнообразны и запутанны. Очень часто в таких системах можно найти факты, противоречащие друг другу. Даже небольшое воздействие на систему может привести к сильным изменениям. В таких системах приходится идти методом проб и ошибок: Попробовали? Дало положительный результат? Продолжаем, а если нет, то давайте сделаем что-то другое.
Хаотичные системы не поддаются анализу. В них нет вообще никакой структуры. Поэтому главное в такой ситуации - начать действовать. Правильно или неправильно - понять не возможно, но так как  состояние хаоса заканчивается очень быстро, то по его завершении мы и узнаем, правильной ли дорогой мы шли. Как правило, те, кто идут, оказываются в более выигрышной позиции по сравнению с теми, кто во время хаоса ничего не делал.
Теперь давайте посмотрим на разработку ПО через призму изложенной теории. Если у нас проекты простые и без изменения требований (правый нижний угол), то можно применять водопадные методики «и в ус не дуть». Если система упорядоченная, но сложная, то можно воспользоваться любой устоявшейся инженерной практикой, будь то PMI или PRINCE2. В зоне же запутанности хорошо себя покажут итеративные подходы к разработке - Scrum или Kanban. Ну а в хаосе можно пробовать все. Если придет жесткий диктатор - появится шанс перейти из хаоса в жестко упорядоченный правый нижний угол, поведет за собой открытый для внешнего мира лидер - попадете в правый верхний квадрат. Даже если вы ничего делать не будете, то хаос вас выкинет хотя бы в зону запутанности.
Главное - не забывать, что все эти зоны субъективны. Вспомните свой первый день на первом месте работы. Все вокруг непонятно, куда-то движется, кто-то с кем-то обсуждает вещи, даже названия которых вы не слышали. Но для окружающих это все могло быть упорядоченной системой с детерминизмом в основе. Да и для вас через несколько дней или недель это был уже не хаос, а система.
Тоже самое происходит и в разработке. Когда вы запускаете новый проект, все запутанно. Гибкие методологии позволят в параллельном или последовательном эксперименте проверить гипотезы, оценить трудоемкость тех или иных задач, определить производительность команды и т.д. Но в дальнейшем может иметь смысл перейти на более формальные подходы к управлению проектом, построить диаграмму Ганта, запланировать буферы, составить реестр рисков. Само собой, многие практики из PMI можно применить и в запутанных системах. Никак не лишним будет список заинтересованных лиц или устав проекта. Но использовать многие другие практики окажется нецелесообразным. Тем не менее, важно о них знать и пробовать применять, чтобы в максимально короткие сроки перейти к упорядоченному состоянию системы.