Когда я рассказывал о «беспощадной автоматизации» на конференции Инфостарт в 2017 году, то, как обычно, не сумел уложиться в отведенные 30 минут, и остаток доклада читал в малом зале.
Потом, через год, когда из доклада делали публикацию, об этом торжественно забыли. А я что-то поленился сидеть и стенографировать свою болтовню, и с тех пор каждый день об этом переживал.
Но вот, собрал волю в кулак и доделал потерянный кусок. Перед прочтением этой статьи рекомендую, конечно, прочитать предыдущую – там рассказан контекст, условия эксперимента и чем он закончился.
Меня частенько обвиняют в том, что я превращаю разработку в конвейер, не давая людям развивать свои компетенции вширь. Команда тоже не была исключением – этот вопрос мне задавал Ослик – плакал, ныл и просил задачи посложнее, т.к. он был самым неопытным, низкооплачиваемым и несертифицированным.
Я говорю – пф, почему бы и нет? Только давайте сбалансируем. Я не могу платить вам от имени работодателя стипендию за то, что вы будете заниматься изучением платформы, но, с другой стороны, конвейер из невзаимозаменяемых сотрудников мне тоже не нужен.
Взяли и сбалансировали. В среднем получалось выделять на решение новых для человека задач 30 % времени. Принципы были такими:
- Развиваемся минимум в две стороны – скорость и кругозор;
- Развивать только кругозор нельзя – мы не университет (с такой-то стипендией, бу-га-га);
- Развивать только скорость нельзя – мы не конвейер;
- Поэтому – соблюдаем баланс.
Кстати, раз уж упомянул Ослика… Он, в итоге, оказался самым эффективным сотрудником. Баллов он выдавал меньше всех, но, если посчитать стоимость балла, то она оказалась самой низкой. Грубо говоря, результаты его работы обходились компании дешевле всего. Ослик очень этим гордился.
Этот пункт стоит немного в стороне от работы программистов – здесь речь об ускорении автоматизации через преодоление сопротивления других руководителей.
Большинство руководителей, которые сидели вокруг в той компании, мне задач не ставили. Задачи им ставил я. Ну, пытался ставить - напрямую, или через директора. Приходил, например, к Васе и говорил – Вася, у тебя все плохо. У Васи естественная реакция – сопротивление. Нет, у меня все хорошо. Ну, даже если все откровенно плохо. И так – до бесконечности. Все плохо, но ничего не меняется, потому что Вася говорит, что у него все хорошо.
Чтобы Вася изменился, он должен признать, что у него все плохо.
Вася должен искупаться в… Ну, в собственном «все хорошо». И порадоваться этому.
Как сделать, чтобы Вася искупался? Это очень тонкая материя. Принципы примерно такие:
- Знать заранее, что предложить человеку для решения его проблем;
- Окунать очень, очень, ОЧЕНЬ аккуратно;
- Заранее убедиться, что дерьмо – настоящее;
- Никому об этом не рассказывать.
Если вы приходите и рассказываете человеку, что у него все плохо, но ничего предложить не можете, то он с вами больше разговаривать не будет. Потому что бесплатно, без какого-либо выхлопа для себя, в дерьмо головой никто лезть не хочет.
Разумеется, делать это нужно очень аккуратно, т.к. речь о прямых интересах человека, а зачастую – и о его личности. Если у менеджера кризис – например, его собираются увольнять за неэффективность, то он согласится на любые меры, лишь бы сохранить место. А если как бы «все хорошо», то придется постараться.
Например, тот же Вася. Мы с ним разговаривали три дня. Наедине, разумеется – нельзя, чтобы кто-то знал о таких разговорах или почитывал их стенограмму. Когда, на третий день, Вася согласился, что у него все плохо, я ему говорю – все, теперь молчи, никому ничего не рассказывай, давай просто исправим, там недолго – немного перекроим бизнес-процесс, быстренько автоматизируем и станет хорошо.
Но Вася так вдохновился после окунания в дерьмо, что пошел всем налево и направо рассказывать, как у него все плохо и как, вскоре, станет хорошо. Его речи дошли до руководства, и на следующий же день к нам приехала Комиссия и сказала – так, давайте, устав проекта, план-график, ресурсы, люди, риски. А работы было дня на три, напоминаю. В результате изменения заглохли, а Вася уволился.
Пришел новый начальник на его место. Вася, естественно, не рассказал ему, что у него в отделе все плохо. Пришлось начинать все с нуля, но я столкнулся с трудностями. Новым начальником была серьезная, очень уверенная в себе девушка. Она не хотела ничего признавать, никуда окунаться, и вообще со мной разговаривать. Пришлось искать обходной путь.
Высадил к ним, в отдел закупа, Пятачка. Говорю – давно же ноете, что автоматизации вам не хватает? Вот вам Пятачок в полное распоряжение. Высадка была со злым умыслом, т.к. Пятачок – веселый, обаятельный парень, и очень нравится девушкам (коих в отделе закупок - большинство).
Неделю он с ними просто сидел – таково было задание из центра, сидеть и наблюдать. Понаблюдал, пришел и говорит – они работают 3% времени. Работают – в смысле закупают, ищут поставщиков, заказы оформляют, т.е. исполняют свою основную функцию. Все остальное время какой-то процессной, бюрократической и прочей ерундой занимаются.
Закупщикам мы, естественно, об этом не сказали, чтобы не обиделись. Пятачок получил новое задание и вернулся в закупки. Стал задавать начальнице неудобные вопросы, или попросту троллить. Хватило нескольких дней – начальница сама пришла к нам в ИТ-отдел и говорит – аааа, как быть с этим зоопарком?
Ну а у меня-то план еще со времен Васи сохранился – вот, говорю, давай так сделаем. И все, пошло дело.
Теперь немного о Кролике. Он очень долго работал один, на заводах.
Что происходит с человеком, когда он долго работает один на заводе программистом 1С? Он начинает сопротивляться задачам. Делает он это очень качественно – напомню, Кролик очень умный, хорошо учился в школе и университете. Приносят ему задачу, говорят – давай сделаем, а Кролик отвечает – не, это делать не надо, и приводит массу, казалось бы, объективных причин, почему задачу действительно не надо решать.
Все бы ничего, но он начал так же поступать и со мной. Например, ставлю я ему задачу. Он ничего не говорит, садится за компьютер.
Я занимаюсь своими делами и искренне думаю, что он сидит и решает задачу. А он, собака, сидит и придумывает, почему ее делать не надо. Результатом его работы за день, или даже за два, является качественный список причин, по которым задачу делать не надо!
А если этот этап все-таки удавалось преодолеть, он откидывался на спинку стула, поднимал взор к потолку и начинал рассказывать, какие он встретит сложности на пути решения этой задачи. Я говорю – э, стопэ! Ты же знаешь, как все это сделать? Ну да, говорит. Так чего ты мне тут тогда рассказываешь про свои сложности! Ну, так я… - говорит Кролик.
В итоге сформулировали простейший принцип: задачу надо решить. Неважно, что ты о ней думаешь, если я, как руководитель, взял эту задачу в работу, то тебе придется ее решить – без вариантов. Не ищи никаких путей увильнуть от этой задачи. Ну и все, больше таких ситуаций не возникало.
Это очень простой принцип. Задачи бывают большими и маленькими. Scrum говорит – надо разбивать задачи на куски, чтобы выполнение каждой занимало не больше одного дня.
Но иногда получается так. Сидит человек, делает задачу, и заканчивает, например, в 15-00, за два часа до конца рабочего дня. Новую задачу начинать неохота. Аналогично утром – пока кофе, почта, соц.сети, то-сё, а только потом – задачи.
Чтобы эффективно использовать эти обрезки времени, мы выделили особый пул задач, которые назвали «коротышками». Они не подчинялись матрице Эйзенхауэра, лежали в отдельном списке, и предназначались именно для «затыкания дыр». Остался час до конца рабочего дня – сделай пару коротышек. Простые, без погружения в контекст, но приносящие пользу задачи. Если их не игнорировать, то можно получить прирост эффективности процентов в тридцать.
Назойливая муха – это я.
Классический Scrum говорит – надо делать ежедневные собрания, по утрам. А я вспоминаю свой любимый контроллинг и смотрю через его призму. Что такое ежедневные собрания по утрам? Это акт управления один раз в течение дня. Т.е. в классическом Scrum к рулю можно подойти один раз в день.
Мне этого мало, потому что если на собрании человек сказал, что у него все получается, а через пять минут перестало получаться, то я об этом узнаю только на следующий день, потеряв 20 % эффективности.
Поэтому я заменил ежедневные собрания контроллингом.
- Спрашиваешь раз в день – управляешь раз в день;
- Спрашиваешь раз в неделю – управляешь раз в неделю;
- Спрашиваешь раз в месяц – управляешь раз в месяц;
- Спрашиваешь 5 раз в день – управляешь 5 раз в день;
- Управление – это изменение в нужную сторону.
Для такого управления, естественно, не годилась скрам-доска. Она дает ответ на вопрос «что сделано в течение спринта», но ничего не знает о том, что сделано с утра, или вчера. Пробовали приспособить – например, писать на стикере дату и время выполнения, но считывать эту информацию неудобно.
Поэтому скрам-доска меня, как руководителя, жутко бесила – не давала информации для управления. Ну я ее и выкинул, заменив простой автоматизаций в информационной системе. Закрытая задача сразу попадала в отчет, который я разбил на два раздела – с начала недели и с утра. Контролируя эти два показателя, я в любой момент времени видел, что пошел какой-то провал.
Принципы простые:
- Смотреть на объем выполнения задач несколько раз в день;
- Сознательно и настоятельно спрашивать о трудностях и препятствиях;
- Сразу разбираться;
- Спасибо 1С:ДО, до свидания scrum-доска.
P.S.
Я продолжаю развивать и обогащать тему ускорения. Сейчас, глядя на опыт двухлетней давности, я, с одной стороны, умиляюсь – уж больно простые были условия, можно сказать – лабораторные. С другой – радуюсь, ведь именно тот опыт помог понять, насколько высок может быть потенциал человека, если им предметно заняться.
Сейчас вся вот эта тема с ускорением давно вышла за пределы виртуальных баллов, и превратилась в ускорение выхода продуктов и релизов, реализации проектов и поступления денег. С другими законами, критериями успеха, коммерческой составляющей. Проще говоря, тема стала серьезной.
Но базовые принципы и практики остались теми же – веселыми, интересными, глупыми и наивными.
Знаю, что вы по этому пути не пошли и не пойдете. Отказались, потому что простые методы ведь не могут какую-то реальную пользу приносить? Ну как можно быстрее закрывать задачи, если измерять их в каких-то баллах? Бред сивой кобылы, чушь колхозная и пыль в глаза.
Ну да и ладно, я не настаиваю. Тем более, что из этой детской глупости сейчас растет конкурентное преимущество некоторых компаний. Они, правда, в этом вряд ли признаются сейчас – сами еще не верят, что поднялись на десятки процентов в первые месяцы. Не в баллах, а в деньгах.
Так что, друзья, считайте, что это очередная сказка про мифических челябинских программистов, Сергеев, Ламанчских, Винни Пухов, графоманов и прочую нечисть.
