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