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

Мозг всегда экономит энергию, и ассоциативные цепочки для «действий на автомате» используются не только в профессиональной деятельности, но и в повседневной жизни. Согласно спорным, но страшноватым результатам исследований до 90% наших действий происходит «на автомате», благодаря сформированным за жизнь ассоциативным цепочкам. Такие действия получаются у нас легко и просто, тогда как отход от наработанных схем встречает внутреннее сопротивление: мозг не хочет «включаться» и начинать тратить сахар в промышленных масштабах. Многим моим читателям знакома ситуация, когда, сев за компьютер поработать мы неожиданно обнаруживаем себя лайкающим уже десятую фотку в фейсбуке. А попытка переключиться в среду разработки встречает просто физическое сопротивление нашей сущности. Это она — автоматика мозга, призванная экономить ресурсы и повторно использовать удачные стратегии.

Обмануть мозг

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

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

Построение коридоров

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

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

И это история не о штрафах

Но я затеял это все писать не для того, чтобы сказать «угрожайте разработчику штрафами — и он начнет хорошо работать». Потому что это неправда — не начнет он хорошо работать. Хотя бы потому, что для мозга будет гораздо эффективнее придумать способ обмануть штраф, формально выполняя работу, нежели делать саму работу. Или вообще расценивать штраф как официальную плату за возможность работу не делать. Многие из вас это видели: введение KPI часто приводит к тому, что разработчики мастерски овладевают техникой формального удовлетворения этих KPI, забивая при этом на саму работу.

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

Как строить коридоры

Вначале приведу пример из реальной жизни, который мне очень нравится. Перед Макдоналдсом стояла задача: сделать так, чтобы люди пользовались электронными терминалами для заказа. А люди не хотели пользоваться — потому, что это новое, думать надо. Что сделали в Макдоналдс? Построили «коридор»: оставили одну кассу и разместили вокруг нее 10 электронных терминалов. Подходит человек к Макдоналдсу, видит очередь в кассу из 20 человек, пару человек у терминалов — и тут ему открывается истина. Что в очереди он будет стоять полчаса, а на терминале сделает заказ за минуту. Он не хочет пользоваться терминалом — но стоять полчаса в очереди к единственной кассе он не хочет намного, намного больше. И человек идет по «коридору», делая то, что нам нужно. Идет безо всякого принуждения, формируя нужные ассоциативные цепочки. Потому что так проще.

Но как сделать коридор, чтобы Team Lead каждое утро делал Code Review? Это немного сложнее, чем подтолкнуть клиентов к использованию терминалов. И тут на помощь приходит неизбежность.

Использование неизбежности для строительства коридоров

Сотрудник должен знать, что проверка выполненной работы неизбежна

— Менеджер

Стенки коридора создаются автоматикой. Хотим, чтобы каждое утро был code review? Добавляем правило в систему контроля версий: нельзя сделать merge, пока не сделан code review. Неожиданно получаем штатный механизм «pre-commit code review».

Идем дальше. Хотим, чтобы у команды каждое утро был стендап? Команда этого не хочет. Мозг не хочет напрягаться, мозг хочет кусочек сахара. Делаем автоматику: текстовый стендап под контролем бота, не отвечающего ждут все остальные. Через три дня коллектив объяснит самым нестойким, что так делать нельзя.

Хотим, чтобы разработчики оценивали сроки для каждой задачи? Разработчики этого не хотят. Потому что мозг не хочет напрягаться, он хочет кусочек сахара. Делаем автоматику: задачу нельзя ни на кого назначить, пока все не отписались по срокам. Мозг неожиданно понимает, что не делать работу вообще — это как-то неправильно. И вот магия — мозг уже хочет проставлять сроки для задачи. Потому что если не проставить — случится что-то страшное.

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

Техника безопасности при строительстве коридоров

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

Во-первых, неизбежность должна быть неизбежной. Мозг очень тонко чувствует фальшь, и если есть хоть один способ «вот сейчас не сделать, потому что очень-очень надо» — начинание будет «спущено на тормозах». Не потому, что ребята плохие — а потому, что этого требует человеческая природа. Мозг не хочет напрягаться и делать тесты — мозг хочет делать что-то привычное. И кусочек сахара.

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

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

Заключение

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

Оригинал: http://apptractor.ru/develop/grigoriy-petrov-priruchenie-neizbezhnosti.html

Владимир Завертайлов
Генеральный директор в Сибирикс

Очень понравилось про неизбежность.

К сожалению, строить такие системы в коммуникационных процессах, с живыми людьми, на много сложнее, чем навесить хуки на коммиты или автобилды.

Работающие примеры:

• У нас опоздавший менеджер останется без ресурсов на техническую поддержку своих проектов.
• Менеджер с кривыми постановками задач будет на утренней планерке читать дятла http://blog.sibirix.ru/2013/10/10/kak-dobitsya-otdachi/
• Менеджер с недобрыми мыслями почти наверняка получит красную булавку в свою фотографию в нико-нико http://blog.sibirix.ru/2013/02/08/niko-niko-calendar/

Пример с автоматическим текстовым ботом для стендапов вообще утопичен: текстовые стендапы ничем не отличаются от обычных отчетов и на пару порядков менее продуктивны, чем физические, у доски. А уж скормить боту строчку с мусором — сам программистский бог велел. Все, коридор сломан.
А значит нужен человек, который проконтролирует, что в «текстовом стендапе» никто не пишет мусор. И нужен workflow, как наказывать провинившихся и workflow, что будет, если контролирующий человек продолбает контроль :)

Технически коридоры неизбежности действительно строить интересно и относительно легко.

Из весёлостей последних дней — можете попробовать сделать с себя подобное:
Дано — список репозиториев, списк комитов за день и список рабочих копий (обновлявшихся с течении дня через систему автобилдов).
Пишем бота, который тестирует рабочие копии:
 

1. удалить кеши;
2. пройти про обновленным страницам;
3. дернуть их;
4. отследить скорость генерации;
5. количество sql-запросов;
6. количество медленных запросов;
7. ну и разломанные рабочие копии заодно.

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

Приятно смотреть, как люди сами начинают внимательно смотреть за производительностью своего кода.