Техника внедрения изменений
Дятел-board
Сибирикс

Дятел-board

Техника внедрения изменений
«Принимай, только если это АХУЕННО и ты ДОВОЛЕН» — записал Антон на желтый стикер и повесил на специальную доску. Стикер провисит на ней четыре недели — примерно столько, по мнению британских ученых, нужно для формирования устойчивой привычки (ха-ха). И каждый день коллеги напомнят тебе, что где-то ты смалодушничал, попробовал скруглить углы, принял работу, которая не нравилась даже тебе и пошел сдавать ее заказчику. Фу, так делать.

Эта доска со стикерами у нас завелась лет 8 назад. Мы называем ее «Дятел-board» или «Дятел», поскольку техника мозгоклюйская: «Мэ-мэ-мэ-мэ-мэ, Мэ-мэ-мэ-мэ-мэ… Тьфу, блин!». Кто-то утром зачитывает вслух все стикеры. Ставит палочку для учета дней. Убирает отработанные стикеры.

Тут работает несколько техник:

1) Лишение права на незнание

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

2) Напоминашки

Менеджер — он как настоящий мужик — все время что-то ДОЛЖЕН. Даже если это хрупкая девушка (хотя сейчас некоторые хрупкие девушки по характеру большие мужики, чем некоторые нехрупкие с виду мужики, но это так, лирика). Дел, нюансов, техник, подходов, которые лучше бы знать и применять — ну очень много. Даже если они формализованы в регламентах и чек-листах, даже если вспоминаются на внутристудийных обучениях. То, что применяется не каждый день — все равно забывается.

3) Хитрожопые скруглятели углов

Ну, есть такое явление. Хочется тебе сделать побыстрее и попроще. Сэкономить силы, так сказать. Например, не проводить демонстрацию спринта клиенту, а сделать все изменения за две недели прямо на боевом сервере. Желательно во время самой важной для клиента акции в году. Чик-чик — и в продакшн. Кровь, ошметки… Нет, понятно, что за такие выходки чаем с козинаками не напоят. Как минимум, поговорят о добре и зле. И дальше по справедливости — в зависимости от регулярности профанаций, степени тяжести и тенденции к исправлению. Может, например, именной стикер про тебя появится. Слава богу, явление довольно редкое.

4) Ретроспективные советы, которые непонятно куда зацепить

Есть менеджеры, есть команды. Регулярно заканчиваются спринты и проходят ретроспективы. И там бывают какие-то интересные нюансы, техники, советы или факапы, про которые хорошо бы всем рассказать.

Например, «Делаешь редизайн проекта — проведи Code Review» — ну что это, правило что ли? Понадобится в следующий раз через полгода может. Делать из этого отдельные регламенты — утонем в бумаге. А вот обсудить такую штуку, почитать по утрам — глядишь, кто-то и вспомнит, что перед тем, как запланировать этап программирования, программисту нужно дать пощупать сайт, познакомиться с ним — сделать Code Review.
Решили завести «дятла» себе? Смотрите, как надо: рисуете «дятлу» рабочую область, разделив ее на четыре части. Одна часть — одна рабочая неделя. Всего 20 рабочих дней. Каждый день на тикете делается отметка о прочтении, как зарубка.

Тикет с новой привычкой крепится на неделю в первый раздел, затем на неделю во второй, потом в третий, а на последнюю неделю кочует в четвертый и затем остается в архиве на веки-вечные.

Сделали? Отойдите на пару шагов, дабы взглянуть на результат работы со стороны. Ахуенно? Вы довольны? Берите в работу ;)