Я хочу рассказать о своем опыте ускорения автоматизации в команде программистов, и о том, какие приемы мы применили на практике, и что из этого получилось.
Начальные условия
Наш эксперимент по ускорению работы программистов мы проводили в следующих условиях:
- это было территориально распределенное производственное предприятие;
- в эксперименте приняли участие 4 программиста 1С и я, их руководитель;
- мы – штатные программисты по поддержке комплекса конфигураций;
- нам стало скучно, и мы решили развиваться.
В первую очередь, желание развиваться возникло после того, как нам на глаза попалась книжка Джеффа Сазерленда про Scrum. Про эту методику вы уже наверняка много знаете, поэтому я на ней останавливаться не буду. Основная часть статьи будет не про Scrum.
Итак, когда мы прочитали эту книгу, то обнаружили, что есть дилемма, которая заключается в неправильном переводе названия книги. Английское название говорит о том, что Scrum ускоряет работу в четыре раза: «Искусство делать вдвое больше работы за половину времени».
А в русском переводе утверждается, что Scrum – это некий революционный метод управления проектами. Когда руководителей ИТ-отдела готовят к собеседованиям, им часто говорят – обращайте внимание, на чем концентрируется человек – на процессах или на результатах. Русский перевод концентрируется на процессе.
Почему я столь уверенно об этом говорю? Я вживую видел несколько десятков людей, которые применяли Scrum. Большинство из них просто запустили у себя процесс Scrum, и когда их спрашиваешь: «Что у вас изменилось?» – они говорят: «У нас стало прозрачно, интересно, весело». Но когда интересуешься, как изменились результаты, увеличилась ли скорость разработки, стали ли вы сдавать проекты быстрее – оказывается, что они этого не знают, потому что результативность не измеряли.
Итак, мы прочитали эту книгу и запустили у себя классический Scrum со всеми его основными этапами бизнес-процесса (они приведены на картинке).
Сразу упомяну способ измерения (он будет фигурировать на всем протяжении доклада). Традиционный способ измерения в Scrum – это покер планирования. Он заключается в следующем: по каждой задаче командой (или теми ее участниками, которые что-то в этой задаче понимают), выставляется оценка в баллах – 1, 2, 3, 5, 8 и до 34 (цифры из ряда Фибоначчи). По совокупности оценок берется средняя. Задача считается выполненной, когда ее принял заказчик.
Первые результаты
Что нам дало внедрение классического Scrum? До него средняя выработка в день на человека была 4,2 балла, а с его внедрением показатель вырос до 7,73 балла. Получилось, что наша продуктивность увеличилась примерно в два раза.
Всем понравилось, мы рассказали об этом коллегам из других отделов, вся компания заинтересовалась, все стали внедрять у себя Scrum.
Но ничего не получилось, потому что все увлеклись фетишем – накупили себе пробковых досок, приклеили на них стикеры и этим ограничились. Даже собственник, который тоже заинтересовался Scrum’ом, троллил сотрудников: подходил к пробковой доске, фотографировал ее, потом приходил через неделю и снова фотографировал – доска не менялась.
Захотелось большего
Повышение производительности в два раза показалось нам скучным. Поэтому я стал читать книгу еще раз. На странице 54-55 заметил некие сюхари. В книге было написано, что это принцип из айкидо, который гласил – сначала сделайте все по правилам (сю), потом начните импровизировать (ха), и лишь затем отделяйтесь и творите свою методику сами (ри).
Что интересно – в широко известном Scrum Guide этот принцип выкинули, и от «сюхари» осталось только «сю».
А мы решили пройти весь путь.
Базовый алгоритм ускорения, который рекомендуется в книге Джеффа Сазерленда – это цикл Деминга. Простыми словами его можно сформулировать так: смотришь, как работают твои люди, замечаешь, где они тупят, где происходит задержка, придумываешь какое-нибудь изменение, внедряешь и смотришь, что получилось. Если стало лучше, быстрее – оставляешь изменение. Если стало хуже – убираешь изменение. Главное – делать это быстро.
Кстати, Теория Ограничений Систем Голдратта говорит примерно о том же, только концентрируется на другом. Она говорит – находите в вашей системе самое узкое звено, расширяйте его или убирайте. Затем повторяйте снова.
Цель, и у того, и у другого – сделать так, чтобы как можно быстрее получать результат на полном производственном цикле. Ту же самую мысль, кстати, высказывал разработчик Toyota Production System – цель производственной системы заключается в том, чтобы деньги клиента поступали как можно быстрее.
Роль наблюдателя за рабочим процессом исполняет Scrum-мастер. Можно сказать, что это тренер. Когда читаешь опыт коллег по Scrum, они воспринимают Scrum-мастера как защитника и говорят, что Scrum-мастер должен устранять препятствия, отгонять каких-то людей, помогать в чем-то.
Однако я уверен, что Scrum-мастер – это наблюдатель и тренер, который учит своих людей работать быстрее, смотрит, где они тупят, помогает, подсказывает, ищет что-то новое, пробует разные комбинации. Как тренер в футболе.
Команда эксперимента.
Чтобы максимально понять контекст, в котором происходил наш эксперимент, нужно представить команду. Если я вам скажу, что в ней были два Стаса, Олег и Игорь – это вам ни о чем не скажет, потому что никто этих людей не знает. Вы, плюс-минус, знаете только меня.
Поэтому вместо двух Стасов, Олега и Игоря в качестве команды будут представлены персонажи, которых все знают, и которые максимально похожи на реальных людей:
- Кролик – умный, себе на уме, молчаливый.
- Пятачок – самый молодой, самый прыткий, самый любознательный.
- Ослик – самый депрессивный, он и в жизни такой.
- А сова… На самом деле в оригинале книжки была не сова, а филин, мужского рода. Вот и в команде был филин.
Следующий этап – импровизация
В первый же день, когда мы решили все поменять, мы:
- Выбросили Scrum-доску и стикеры. Scrum-доску заменили информационной системой на базе 1С: Документооборот;
- Стикеры заменили задачами в этой информационной системе;
- Оставили покер и измерение скорости;
- Убрали ежедневные собрания, ретроспективы, проекты (вообще, как сущность) – оставили просто некую классификацию задач по темам;
- Добавили постоянное наблюдение за простоями, потерями;
- И добавили постоянное изменение процесса.
Всего в течение этого эксперимента, который продолжался у нас примерно год, мы нашли примерно 40 ускорителей. Эти 40 ускорителей я постарался сгруппировать и сейчас вам быстро расскажу, как каждый из них повлиял на рабочий процесс.
На всякий случай, упомяну, откуда взялись эти ускорители. Здесь нет ничего нового. Некоторые принципы я придумал сам, некоторые придумали мои ребята, что-то мы прочитали из книжек. Например, когда в книжке рекомендуется для решения такой-то проблемы поступать вот так, надо брать и пробовать. Если получается, то оставляем. Если толку нет – выкидываем.
Нулевое изменение
Итак, первое, с чего началось наше переосмысление процесса – это книга «Кодекс самурая». Я рекомендую всем ее прочитать, приобрести, и держать у себя дома. Потому что она написана 500 лет назад, и уже 500 лет назад люди знали, как управлять, как подчиняться, как развиваться и как совершенствоваться.
Внимание персонажа, которого я называю Пятачком, в «Кодексе самурая» привлекли вот такие две фразы. Он увидел, что:
- Решение надо принимать очень быстро – за семь вдохов;
- А если ты не принимаешь решение быстро, то результат будет плачевным.
Пятачок так увлекся этой идеей, что, если не мог принять решение за семь вдохов – отказывался. Однажды даже веселую пьянку пропустил.
Мне стало интересно, я перечитал эту книгу еще раз и обратил внимание, что примерно на каждой 10-ой странице написано: для того, чтобы быстро принимать решения, надо заранее подумать, как ты будешь действовать в той или иной ситуации.
На что это похоже?
Это похоже на стратегию, когда у вас есть правила для принятия решений.
Как у нас в стране чаще всего представляют себе стратегию? Когда спрашиваешь кого-нибудь: «Какая стратегия у вашей компании?», они тебе показывают длинную «портянку», где написано, что они будут делать в этом году – какие у компании планы, бюджеты, задачи, как они прирастут в продажах и т.д.
Мне такое определение не близко, оно для моих целей не подходит.
Поэтому мы оставили для себя только второе определение и стали воспринимать стратегию только как набор правил для принятия решений.
Соответственно, нулевое изменение, которое мы ввели в наш процесс Scrum, заключалось в том, что, пробуя в своем коллективе новые ускоряющие техники, мы формируем для них принципы, даем им названия (чтобы легче запоминать и обсуждать), и используем дальше в своей работе. Эти принципы – носители всего остального.
Главный секрет улучшений
Следующий основополагающий принцип, к которому мы пришли – это «главный секрет улучшений».
Хотите, верьте, хотите – нет, но мы вывели «главный секрет улучшений», в эффективности которого много раз убедились.
Его можно сформулировать так: 75% проблем в изменениях возникает из-за того, что люди не работают так, как им велели.
Почему это происходит? Дело в том, что люди, которые пытаются внедрять изменения (например, Scrum) приходят и говорят своим подчиненным: «Вы теперь работаете по-новому». А потом просто уходят. И когда через неделю или через две возвращаются, то видят – результатов-то нет. И в итоге эти «изменяторы» решают, что Scrum не работает, и навсегда вычеркивают его из своей памяти и из своего набора инструментов. То же самое происходит и со всеми остальными методиками. Я это видел безумное количество раз в своей компании, и меня постоянно пытались убедить в том, что что-то (какое-то изменение) не работает.
Поэтому мы сформировали базовые принципы изменений – чтобы изменения происходили, их необходимо применять. Если мы решили, что у нас сегодня техподдержки нет – просто хочется посмотреть, что будет без техподдержки – то техподдержки нет, и никак иначе.
Это, наверное, самое главное, на чем был основан наш успех, – на том, что ребята, которые со мной работали, приняли эти правила. Они не просили от меня приказов, распоряжений, изменений штатного расписания, перестановок. Мы просто договаривались и вместе делали. В итоге мы за один день могли проверить действие каких-то методик, практик и т.д.
Вокруг всегда было много крутых управленцев. Я сам когда-то хотел таким стать.
Кто такой крутой управленец? Это тот, кто считает, что нужно ставить задачу, называть срок, и когда срок проходит, а задача не выполнена, дрючить исполнителя. Это не мое, а их выражение. Они так говорят: Scrum – это все хрень, ты должен ставить задачи и дрючить, когда не исполняют в срок.
Но мы для себя решили, что сроки – это зло. Почему?
- Во-первых, когда у вас пул задач, например, 150, и вы на каждую из них ставите срок, вам надо каждый день эти сроки пересчитывать, потому что они все время «уплывают». В итоге тратится колоссальное время на администрирование;
- Во-вторых, из-за того, что сроки все время «уплывают», они всегда неверные;
- Кроме того, степень попадания человека в сроки вообще ни о чем не говорит. Просто у человека, за период, могла быть одна задача;
- И нафига они тогда нужны? Если возни много, а по факту сроки всегда не верны? Сроки – просто фетиш;
- Мы для себя решили, что управление по срокам – это «женский подход» в менеджменте.
Последний пункт надо пояснить отдельно. Сразу прошу женщин не обижаться, тем более что такой подход сейчас даже чаще у мужчин встречается. Эта метафора была придумана для того, чтобы как-то объяснить действия некоторых управленцев.
Аналогия из жизни: представьте, что женщина просит мужчину починить кран и дает ему на это 5 дней. Что будет происходить все эти пять дней? Мужчина будет заниматься какими-то своими делами, а женщина – будет напоминать? Нет, не будет. Она будет каждый день приходить и тихонько смотреть – починил или не починил. И вот наступает пятый день, женщина подходит, смотрит – не починил. Ждет утра, а утром…
И самое главное, что для женщины это – позитивный результат. Почему? Потому что после этого можно сделать вот так:
А теперь проведите аналогию с крутыми управленцами, которые ставят задачу так, чтобы человек ее в срок не выполнил, и его потом можно было вздрючить. Мне кажется, что это – какой-то садизм. Они так развлекаются и считают, что это – работа, и за нее надо платить по 300-500 тысяч рублей в месяц.
Мы – не такие, поэтому мы сформулировали для себя принцип, что срок нужен только тогда, когда после него уже ничего делать не нужно. Например, срок сдачи отчетности. После него можно задачу уже и не делать, потому что штраф за несвоевременную сдачу отчетности, кажется, процентов 20 от выручки?
Цели
Наверняка всем случалось видеть своих подчиненных вот в таком состоянии.
Приходишь на работу – а твой сотрудник сидит вот такой.
Или вот такой.
Что с ним делать? Раньше я поступал так:
В итоге, несколько раз был откровенно послан, однажды довел человека до обморока, и это не считая пролитых слез – и мужских, и женских. Отвратительно, до сих пор стыдно.
Человек, на которого постоянно орут, превращается в засранца. Хотя правильнее сказать, что засранец – это тот, кто его таким сделал.
Чем плохо такое состояние? Если на человека постоянно орут, вы его слез уже не увидите, а значит, вы не узнаете, что он сидит и ничего не делает. Потому что человек в депрессии ничего не делает. Для эффективности это колоссальная потеря. Если человек с утра пришел в депрессии, он весь день будет сидеть в интернете, откроет конфигуратор и будет туда-сюда быстро переключаться. Все же программисты сидят монитором от двери, правильно?
Поэтому на людей лучше не орать. Надо проанализировать ситуацию, и возможно, окажется, что у человека банально нет мотивации. А мотивации у человека нет потому, что у него нет цели. Он пришел на работу и не знает – зачем. А если он еще и дома какой-то негатив получил, например, за то, что каких-то домашних целей не достиг (жена хочет в отпуск на Мальдивы, а он этого обеспечить не может), он приходит на работу просто посидеть. Потому что как достичь цели, он не знает. А может, у него и цели нет.
Поэтому мы сформулировали для себя принцип, что нам надо разговаривать о целях. Сначала по одному с каждым посидели, поговорили, потом вместе собрались, обсудили.
В результате нам удалось вывести некую «среднюю» цель – одну для всех.
Эта «средняя цель» была вот такая – работать на будущего работодателя. В этой формулировке заложено очень много смыслов (ну, мне так кажется). Упомяну только два:
- Во-первых, цель программиста не связана с текущей работой на текущую организацию. Потому что люди, которые привязываются к текущей организации, когда ее покидают, получают очень большой удар по своей значимости. Ведь то, что было важно здесь, никому не нужно там.
- Во-вторых, что значит «работать на будущего работодателя»? Это значит получить максимальный абстрактный опыт, который будет полезен большинству будущих работодателей.
Вот такую цель мы сформулировали для ребят, и это на них очень позитивно сказалось.
Несколько слов про «кастомизацию на лету» – чисто технический способ ускорения работы.
На картинке показан неполный перечень таких ускорителей. Это – абстрактные решения, которые очень быстро решают определенные классы задач. Самый типичный пример – это проверка данных. Вместо того чтобы каждый раз, когда пользователь хочет что-то при проведении документа запретить, 30 минут писать код, мы делаем проверку за три минуты, не запуская конфигуратор. Всё.
Сложив «Среднюю цель» и «Кастомизацию на лету», получаем «Комплект увольнения». Что это такое? Это как раз тот набор знаний, опыта, идей, который человек, уходя из компании, выносит с собой.
Мы для каждого участника команды составили довольно большой перечень того, что надо изучить, что надо попробовать, в чем надо разобраться, чтобы, выйдя из компании, это можно было применить на новой работе.
Приоритеты – это безумно важная вещь.
Я в жизни перепробовал множество разных вариантов назначения приоритетов выполнения задач – вплоть до того, что использовал модель инновационно-векторного развития предприятия из докторской диссертации по экономике.
Но практика показала, что эффективность – в простоте. Поэтому в итоге для расстановки приоритетов я выбрал обычную матрицу Эйзенхауэра. Все знают об этом инструменте – когда все задачи делятся на четыре квадрата.
В принципах команды это отразилось так:
- Срочность/Важность ставит руководитель (я);
- У сотрудника нет выбора порядка выполнения;
- Ибо Нефиг.
Почему у сотрудника нет выбора порядка выполнения? Потому что возможность выбора задачи для программиста – это потрясающее зло для эффективности. Он может выбирать задачу целый день. А что такое день? Это – 20% от недели. Все, день прошел. Он ведь не просто выбирает задачу, он может зайти в конфигуратор, посмотреть, как она решается, какие там подводные камни, и потом испугается и передумает ее делать. И так проходит целый день, а может и больше.
А два самых больших зла для эффективности – это когда человеку страшно и когда ему непонятно.
Страшно – это когда человек сидит и ему:
- Страшно спросить;
- Страшно ошибиться;
- Страшно отвлекать коллег, чтобы что-то спрашивать;
- Страшно сделать не оптимально, потому что его будут ругать.
А страх парализует, как и возможность выбора. Человек начал делать, ему спросить страшно – и он сидит парализованный, пока к нему не придешь и не спросишь – что там?
Когда у нас проводился весь этот эксперимент, я не отдавал себе отчета в том, насколько это важно. Я это понял только тогда, когда перешёл в другую компанию. Теперь мой страх выглядит вот так. Знаете этого человека?
Или вот еще, если кто не узнал.
Это Евгений Маляров, автор платформы metadata.js.
Я боюсь этого человека, потому что он обладает знаниями, раз в 20 превышающими мои. И мне страшно его спрашивать, потому что я привык, что я – самый лучший, а тут я – идиот. И я боюсь.
Я уже говорил, что человек может весь день протупить. Сейчас и я могу весь день протупить, просто чтобы дождаться конца дня и убежать.
Когда страшно, можно выйти из ситуации с помощью юмора. Мы этот способ нашли интуитивно. Когда человек ошибается, мы над ним ржем. А так как ржут все и над всеми, в том числе надо мной, то никому не обидно.
А что делать, когда непонятно? Представьте, сел программист, получил задачу и не понимает, как ее делать.
Надо силой заставлять людей вставать из-за компьютеров, чтобы помочь дружбану, и объяснить ему, что не понятно. Почему надо заставлять? Можно же просто сказать: «Помогайте друг другу, ребята». Но ребята не будут помогать, потому что программисты любят смотреть в свой монитор. Для них встать из-за монитора – это проблема. Бывает, говоришь: «Ребята, слушайте меня, я вам сейчас классную штуку расскажу». Но они сидят, смотрят в мониторы, говорят, что слушают, а в реальности заняты своими делами. В итоге, иногда даже приходится мониторы выключать, чтобы они туда не пялились.
А что делать, когда никому не понятно и никто друг другу помочь не может? Пять человек сидят – никто не знает, как это делать. В этом случае нужно устраивать:
- Мозговой штурм.
- Или воспользоваться методом под названием «Адвокат дьявола». Это когда один программист предлагает одно решение, а другой – другое. И в результате их надо поменять местами, чтобы первый защищал идею второго, а второй – первого. Это безумно интересно – если подойти к вопросу искренне, и захотеть защитить идею другого так, будто ты и сам в нее поверишь.
- Люди-катализаторы – это еще один из способов придумать что-то хорошее. Например, если ты решил придумать какое-то классное архитектурное решение, не думай молча – думай вслух. Собери вокруг себя ребят, скажи: «Ребята, слушайте, что я скажу, и поддакивайте, или наоборот, не соглашайтесь». В результате решения приходят значительно быстрее, вместо двух дней – за 30 минут.
- Чингисхан – еще один интересный способ решения задач. Чингисхан любил брать города так: он подходил к городу, начинал его штурмовать, а потом делал вид, что сдается и отступал. Люди выбегали из города, и попадали в засаду. Аналогичный способ тоже можно применять: когда человек придумал решение, он за него держится и не хочет придумывать другое. Но если ему руководитель скажет: «забудь, это решение не годится, оно в корне неверно» – человек начинает вынуждено придумывать другое. И в результате где-то на пятую-шестую итерацию рождается классное решение.
Меня частенько обвиняют в том, что я превращаю разработку в конвейер, не давая людям развивать свои компетенции вширь. Команда тоже не была исключением – этот вопрос мне задавал Ослик – плакал, ныл и просил задачи посложнее, т.к. он был самым неопытным, низкооплачиваемым и несертифицированным.
Я говорю – пф, почему бы и нет? Только давайте сбалансируем. Я не могу платить вам от имени работодателя стипендию за то, что вы будете заниматься изучением платформы, но, с другой стороны, конвейер из невзаимозаменяемых сотрудников мне тоже не нужен.
Взяли и сбалансировали. В среднем получалось выделять на решение новых для человека задач 30 % времени. Принципы были такими:
- Развиваемся минимум в две стороны – скорость и кругозор;
- Развивать только кругозор нельзя – мы не университет (с такой-то стипендией, бу-га-га);
- Развивать только скорость нельзя – мы не конвейер;
- Поэтому – соблюдаем баланс.
Кстати, раз уж упомянул Ослика… Он, в итоге, оказался самым эффективным сотрудником. Баллов он выдавал меньше всех, но, если посчитать стоимость балла, то она оказалась самой низкой. Грубо говоря, результаты его работы обходились компании дешевле всего. Ослик очень этим гордился.
Этот пункт стоит немного в стороне от работы программистов – здесь речь об ускорении автоматизации через преодоление сопротивления других руководителей.
Большинство руководителей, которые сидели вокруг в той компании, мне задач не ставили. Задачи им ставил я. Ну, пытался ставить — напрямую, или через директора. Приходил, например, к Васе и говорил – Вася, у тебя все плохо. У Васи естественная реакция – сопротивление. Нет, у меня все хорошо. Ну, даже если все откровенно плохо. И так – до бесконечности. Все плохо, но ничего не меняется, потому что Вася говорит, что у него все хорошо.
Чтобы Вася изменился, он должен признать, что у него все плохо.
Вася должен искупаться в… Ну, в собственном «все хорошо». И порадоваться этому.
Как сделать, чтобы Вася искупался? Это очень тонкая материя. Принципы примерно такие:
- Знать заранее, что предложить человеку для решения его проблем;
- Окунать очень, очень, ОЧЕНЬ аккуратно;
- Заранее убедиться, что дерьмо – настоящее;
- Никому об этом не рассказывать.
Если вы приходите и рассказываете человеку, что у него все плохо, но ничего предложить не можете, то он с вами больше разговаривать не будет. Потому что бесплатно, без какого-либо выхлопа для себя, в дерьмо головой никто лезть не хочет.
Разумеется, делать это нужно очень аккуратно, т.к. речь о прямых интересах человека, а зачастую – и о его личности. Если у менеджера кризис – например, его собираются увольнять за неэффективность, то он согласится на любые меры, лишь бы сохранить место. А если как бы «все хорошо», то придется постараться.
Например, тот же Вася. Мы с ним разговаривали три дня. Наедине, разумеется – нельзя, чтобы кто-то знал о таких разговорах или почитывал их стенограмму. Когда, на третий день, Вася согласился, что у него все плохо, я ему говорю – все, теперь молчи, никому ничего не рассказывай, давай просто исправим, там недолго – немного перекроим бизнес-процесс, быстренько автоматизируем и станет хорошо.
Но Вася так вдохновился после окунания в дерьмо, что пошел всем налево и направо рассказывать, как у него все плохо и как, вскоре, станет хорошо. Его речи дошли до руководства, и на следующий же день к нам приехала Комиссия и сказала – так, давайте, устав проекта, план-график, ресурсы, люди, риски. А работы было дня на три, напоминаю. В результате изменения заглохли, а Вася уволился.
Пришел новый начальник на его место. Вася, естественно, не рассказал ему, что у него в отделе все плохо. Пришлось начинать все с нуля, но я столкнулся с трудностями. Новым начальником была серьезная, очень уверенная в себе девушка. Она не хотела ничего признавать, никуда окунаться, и вообще со мной разговаривать. Пришлось искать обходной путь.
Высадил к ним, в отдел закупа, Пятачка. Говорю – давно же ноете, что автоматизации вам не хватает? Вот вам Пятачок в полное распоряжение. Высадка была со злым умыслом, т.к. Пятачок – веселый, обаятельный парень, и очень нравится девушкам (коих в отделе закупок — большинство).
Неделю он с ними просто сидел – таково было задание из центра, сидеть и наблюдать. Понаблюдал, пришел и говорит – они работают 3% времени. Работают – в смысле закупают, ищут поставщиков, заказы оформляют, т.е. исполняют свою основную функцию. Все остальное время какой-то процессной, бюрократической и прочей ерундой занимаются.
Закупщикам мы, естественно, об этом не сказали, чтобы не обиделись. Пятачок получил новое задание и вернулся в закупки. Стал задавать начальнице неудобные вопросы, или попросту троллить. Хватило нескольких дней – начальница сама пришла к нам в ИТ-отдел и говорит – аааа, как быть с этим зоопарком?
Ну а у меня-то план еще со времен Васи сохранился – вот, говорю, давай так сделаем. И все, пошло дело.
Теперь немного о Кролике. Он очень долго работал один, на заводах.
Что происходит с человеком, когда он долго работает один на заводе программистом 1С? Он начинает сопротивляться задачам. Делает он это очень качественно – напомню, Кролик очень умный, хорошо учился в школе и университете. Приносят ему задачу, говорят – давай сделаем, а Кролик отвечает – не, это делать не надо, и приводит массу, казалось бы, объективных причин, почему задачу действительно не надо решать.
Все бы ничего, но он начал так же поступать и со мной. Например, ставлю я ему задачу. Он ничего не говорит, садится за компьютер.
Я занимаюсь своими делами и искренне думаю, что он сидит и решает задачу. А он, собака, сидит и придумывает, почему ее делать не надо. Результатом его работы за день, или даже за два, является качественный список причин, по которым задачу делать не надо!
А если этот этап все-таки удавалось преодолеть, он откидывался на спинку стула, поднимал взор к потолку и начинал рассказывать, какие он встретит сложности на пути решения этой задачи. Я говорю – э, стопэ! Ты же знаешь, как все это сделать? Ну да, говорит. Так чего ты мне тут тогда рассказываешь про свои сложности! Ну, так я… — говорит Кролик.
В итоге сформулировали простейший принцип: задачу надо решить. Неважно, что ты о ней думаешь, если я, как руководитель, взял эту задачу в работу, то тебе придется ее решить – без вариантов. Не ищи никаких путей увильнуть от этой задачи. Ну и все, больше таких ситуаций не возникало.
Это очень простой принцип. Задачи бывают большими и маленькими. Scrum говорит – надо разивать задачи на куски, чтобы выполнение каждой занимало не больше одного дня.
Но иногда получается так. Сидит человек, делает задачу, и заканчивает, например, в 15-00, за два часа до конца рабочего дня. Новую задачу начинать неохота. Аналогично утром – пока кофе, почта, соц.сети, то-сё, а только потом – задачи.
Чтобы эффективно использовать эти обрезки времени, мы выделили особый пул задач, которые назвали «коротышками». Они не подчинялись матрице Эйзенхауэра, лежали в отдельном списке, и предназначались именно для «затыкания дыр». Остался час до конца рабочего дня – сделай пару коротышек. Простые, без погружения в контекст, но приносящие пользу задачи. Если их не игнорировать, то можно получить прирост эффективности процентов в тридцать.
Назойливая муха – это я.
Классический Scrum говорит – надо делать ежедневные собрания, по утрам. А я вспоминаю свой любимый контроллинг и смотрю через его призму. Что такое ежедневные собрания по утрам? Это акт управления один раз в течение дня. Т.е. в классическом Scrum к рулю можно подойти один раз в день.
Мне этого мало, потому что если на собрании человек сказал, что у него все получается, а через пять минут перестало получаться, то я об этом узнаю только на следующий день, потеряв 20 % эффективности.
Поэтому я заменил ежедневные собрания контроллингом.
- Спрашиваешь раз в день – управляешь раз в день;
- Спрашиваешь раз в неделю – управляешь раз в неделю;
- Спрашиваешь раз в месяц – управляешь раз в месяц;
- Спрашиваешь 5 раз в день – управляешь 5 раз в день;
- Управление – это изменение в нужную сторону.
Для такого управления, естественно, не годилась скрам-доска. Она дает ответ на вопрос «что сделано в течение спринта», но ничего не знает о том, что сделано с утра, или вчера. Пробовали приспособить – например, писать на стикере дату и время выполнения, но считывать эту информацию неудобно.
Поэтому скрам-доска меня, как руководителя, жутко бесила – не давала информации для управления. Ну я ее и выкинул, заменив простой автоматизаций в информационной системе. Закрытая задача сразу попадала в отчет, который я разбил на два раздела – с начала недели и с утра. Контролируя эти два показателя, я в любой момент времени видел, что пошел какой-то провал.
Принципы простые:
- Смотреть на объем выполнения задач несколько раз в день;
- Сознательно и настоятельно спрашивать о трудностях и препятствиях;
- Сразу разбираться;
- Спасибо 1С: ДО, до свидания scrum-доска.
Итоговые результаты
В итоге у нас получилась некая методика с принципами и контрольными точками. Поскольку принципы мы уже придумали, нам надо было придумать название, потому что иначе это неудобно обсуждать. Поиск названия занял ровно одну минуту!
Сначала вот так.
А потом вот так.
Эксперимент, который мы проводили по «казахской» методике, длился у нас около года.
- Напомню, до внедрения классического Scrum у нас эффективность была на уровне 4,2 балла.
- Книжный Scrum повысил показатель до 7,73 балла.
- А на «казахском» Scrum мы стали выдавать уже 17 баллов.
И после всего этого я ушел из этой компании, и на мое место пришел «крутой управленец». Настоящий крутой управленец, который Scrum называет «скрумом» и говорит, что это новомодная методика. Поскольку мои ребята в компании остались, они продолжили замерять свою эффективность, и дали мне свои показатели, как они работают сейчас. Сейчас их эффективность упала до 2,5 баллов.
Если подсчитать частное от итогового и самого первого измерений, то получается, что все примененные методы и принципы дали нам повышение эффективности в 4 раза.
