Беспощадная автоматизация: ускоряемся в 4 раза

Статья посвящена способам ускорения автоматизации в команде программистов.

Я хочу рассказать о своем опыте ускорения автоматизации в команде программистов, и о том, какие приемы мы применили на практике, и что из этого получилось.

Начальные условия

Наш «эксперимент» по ускорению работы программистов мы проводили в следующих условиях:

  • Это было территориально распределенное производственное предприятие;
  • В эксперименте приняли участие 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 2024.

 

 

На слайде показан неполный перечень таких ускорителей. Это – абстрактные решения, которые очень быстро решают определенные классы задач. Самый типичный пример – это проверка данных. Вместо того чтобы каждый раз, когда пользователь хочет что-то при проведении документа запретить, 30 минут писать код, мы делаем проверку за три минуты, не запуская конфигуратор. Все.

 

 

Сложив «Среднюю цель» и «Кастомизацию на лету», получаем «Комплект увольнения». Что это такое? Это как раз тот набор знаний, опыта, идей, который человек, уходя из компании, выносит с собой.

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

 

Приоритеты – это безумно важная вещь.

Я в жизни перепробовал множество разных вариантов назначения приоритетов выполнения задач – вплоть до того, что использовал модель инновационно-векторного развития предприятия из докторской диссертации по экономике.

 

 

Но практика показала, что эффективность – в простоте. Поэтому в итоге для расстановки приоритетов я выбрал обычную матрицу Эйзенхауэра. Все знают об этом инструменте – когда все задачи делятся на четыре квадрата.

В принципах команды это отразилось так:

  • Срочность и важность ставит руководитель;
  • А программист просто берет и делает – сначала левый верхний квадрат, потом левой нижний квадрат, и так далее;
  • Почему у сотрудника нет выбора порядка выполнения? Потому что возможность выбора задачи для программиста – это потрясающее зло для эффективности. Он может выбирать задачу целый день. А что такое день? Это – 20% от недели. Все, день прошел. Он ведь не просто выбирает задачу, он может зайти в конфигуратор, посмотреть, как она решается, какие там подводные камни, и потом испугается и передумает ее делать. И так проходит целый день, а может и больше.

 

А два самых больших зла для эффективности – это когда человеку страшно и когда ему непонятно.

Страшно – это когда человек сидит и ему:

  • Страшно спросить;
  • Страшно ошибиться;
  • Страшно отвлекать коллег, чтобы что-то спрашивать;
  • Страшно сделать не оптимально, потому что его будут ругать.

А страх парализует, как и возможность выбора. Человек начал делать, ему спросить страшно – и он сидит парализованный, пока к нему не придешь и не спросишь – что там?

Когда у нас проводился весь этот эксперимент, я не отдавал себе отчета в том, насколько это важно. Я это понял только тогда, когда перешёл в другую компанию.

 

 

Теперь мой страх выглядит вот так. Знаете этого человека?

 

 

Или вот еще, если кто не узнал.

 

 

Или вот так.

Я боюсь этого человека, потому что он обладает знаниями, раз в 20 превышающими мои. И мне страшно его спрашивать, потому что я привык, что я – самый лучший, а тут я – идиот. И я боюсь.

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

 

 

Когда страшно, можно выйти из ситуации с помощью юмора. Мы этот способ нашли интуитивно. Потому что, когда человек ошибается, над ним можно посмеяться, а так как смеются все и над всеми, то уже никому не обидно.

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

Надо силой заставлять людей вставать из-за компьютеров, чтобы помочь товарищу, и объяснить ему, что не понятно. Почему надо заставлять? Можно же просто сказать: «Помогайте друг другу, ребята». Но ребята не будут помогать, потому что программисты любят смотреть в свой монитор. Для них встать из-за монитора – это проблема. Бывает, говоришь: «Ребята, слушайте меня, я вам сейчас классную штуку расскажу». Но они сидят, смотрят в мониторы, говорят, что слушают, а в реальности заняты своими делами. В итоге, иногда даже приходится кнопочки на мониторах нажимать, чтобы они туда не пялились.

А что делать, когда никому не понятно и никто друг другу помочь не может? Пять человек сидят – никто не знает, как это делать. В этом случае нужно устраивать:

  • Мозговой штурм.
  • Или воспользоваться методом под названием «Адвокат дьявола». Это когда один программист предлагает одно решение, а другой – другое. И в результате их надо поменять местами, чтобы первый защищал идею второго, а второй – первого. Это безумно интересно – если подойти к вопросу искренне, и захотеть защитить идею другого так, будто ты и сам в нее поверишь.
  • Люди-катализаторы – это еще один из способов придумать что-то хорошее. Например, если ты решил придумать какое-то классное архитектурное решение, не думай молча – думай вслух. Собери вокруг себя ребят, скажи: «Ребята, слушайте, что я скажу, и поддакивайте, или наоборот, не соглашайтесь». В результате решения приходят значительно быстрее, вместо двух дней – за 30 минут.
  • Чингисхан – еще один интересный способ решения задач. Чингисхан любил брать города так: он подходил к городу, начинал его штурмовать, а потом делал вид, что сдается и отступал. Люди выбегали из замка, и попадали в засаду. Аналогичный способ тоже можно применять: когда человек придумал решение, он за него держится и не хочет придумывать другое. Но если ему руководитель скажет: «забудь, это решение не годится, оно в корне неверно» – человек начинает вынуждено придумывать другое. И в результате где-то на пятую-шестую итерацию рождается классное решение.

 

Итоговые результаты

В итоге у нас получилась некая методика с принципами и контрольными точками. Поскольку принципы мы уже придумали, нам надо было придумать название, потому что иначе это неудобно обсуждать. Поиск названия занял ровно одну минуту!

 

 

Сначала вот так.

 

 

А потом вот так.

 

 

Эксперимент, который мы проводили по «казахской» методике, длился у нас около года.

  • Напомню, до внедрения классического Scrum у нас эффективность была на уровне 4,2 балла.
  • Книжный Scrum повысил показатель до 7,73 балла.
  • А на «казахском» Scrum мы стали выдавать уже 17 баллов.
  • И после всего этого я ушел из этой компании, и на мое место пришел «крутой управленец». Настоящий крутой управленец, который Scrum называет «скрумом» и говорит что это новомодная методика. Поскольку мои ребята в компании остались, они продолжили замерять свою эффективность, и дали мне свои показатели, как они работают сейчас. Сейчас их эффективность упала до 2,5 балла.

Если подсчитать частное от итогового и самого первого измерений, то получается, что все примененные методы и принципы дали нам повышение эффективности в 4 раза (17 поделить на 4 будет (примерно) 4).

 

****************

Данная статья написана по итогам доклада (продолжение), прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.

99 Comments

  1. best_it_director

    Видосы интереснее статьи 🙂

    Reply
  2. 1c-intelligence

    (1) согласен.

    Reply
  3. Steelvan

    стикеры =наклейки

    кастомизация = настройка

    и т.п.

    Автор, учи русский !

    Reply
  4. genayo

    (1) Да, есть у Ивана определенная харизма :))

    Reply
  5. 1c-intelligence

    (3)

    стикеры =наклейки

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

    кастомизация = настройка

    слово «настройка» не отражает сущности кастомизации. Кастомизацией может быть, например, программирование. Программирование же не назовешь настройкой?

    Reply
  6. genayo

    (5) Хорошо, что вы не используете слова типа «фасилитировать», бедняга наверное мозг бы сломал в попытке перевести…

    Reply
  7. 1c-intelligence

    (6) да я не против замечания коллеги, просто предложенные им синонимы не кажутся подходящими.

    Reply
  8. best_it_director

    (4) есть, но странная какая-то. Говорит быстро и сбивчиво, но слушать интересно. Пусть работает над собой.

    Reply
  9. mifka186
    Большинство из них просто запустили у себя процесс Scrum, и когда их спрашиваешь: «Что у вас изменилось?» – они говорят: «У нас стало прозрачно, интересно, весело». Но когда интересуешься, как изменились результаты, увеличилась ли скорость разработки, стали ли вы сдавать проекты быстрее – оказывается, что они этого не знают, потому что результативность не измеряли.

    Прям до слёз. Ввели фибоначчи, задачи, доску даже в 1С нарисовали. И всё. Скрам не совсем подходит для нашей организации.

    Reply
  10. AlexZhukov

    не дочитал из-за обилия картинок )

    Reply
  11. 1c-intelligence

    (10) лучше видео смотрите. Это статья по докладу, ее сложно сделать хорошей, потому что информация изначально рассчитана на устное изложение.

    Reply
  12. Кадош

    Расскажите, как оценивался результат?

    Всегда интересно, по каким критериям оценивается эффективность программистов.

    Стали писать больше строк кода, выполнять большее количество задач в единицу времени?

    Reply
  13. 1c-intelligence

    (12) стали выполнять больше задач в единицу времени.

    Задачи оценивались по трудоемкости в баллах — 1, 2, 3, 5, 8 и т.д.

    Сумма баллов выполненных задач в день как раз и увеличилась — с 4.2 балла до 17.3 баллов.

    Reply
  14. ABudnikov

    (13) а как была сделана обратная петля связи управления, чтоб эти цифры не улетали вверх. Можно же согласованно начать оценивать средние задачи в большее количество баллов? Может есть какой-то базовый набор действий оцененный в баллах? Чтоб стартовать с чего-то.

    Reply
  15. acsent

    Так задачи стали сложнее или их больше стали выполнять?

    Reply
  16. Ta_Da

    (15) Стали дороже оценивать =)

    (0) а что делать если есть отдел с разработчиками, тестировщиками, бизнес-аналитиками, доской со стикерами и при этом у большинства нет никакого желания ускоряться в 4 раза, избавляться от суррогатов и т.п.? бежать?

    Reply
  17. yogaga

    (16)

    бежать?

    Из 1С…

    Reply
  18. 1c-intelligence

    (14) да, был базовый набор, мы его называли якорь, их было несколько — это типовые задачи, которые периодически встречаются. До этой практики у нас была система мотивации, от которой осталось наследство — нормировка задач.

    Ну и я следил за оценками, потому что эксперимент был для себя, а не для демонстрации. Хотелось получить реальное, а не дутое ускорение.

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

    Reply
  19. 1c-intelligence

    (15) стали больше выполнять, в единицу времени. Т.е. увеличили скорость решения задач.

    Reply
  20. 1c-intelligence

    (16)

    и при этом у большинства нет никакого желания ускоряться в 4 раза

    ответ на этот вопрос давал во втором видео.

    Так же, развернутый ответ есть в этой статье — https://infostart.ru/public/707406/, и еще в этой — https://infostart.ru/public/852933/

    Reply
  21. best_it_director

    Иван, а в Окнософте ты внедрял подобную практику? Есть результаты?

    Reply
  22. 1c-intelligence

    (21) да, внедрял и внедряю. Сейчас, если выразить в единицах статьи, скорость 23 балла в день, т.е. на 30% выше, чем самая высокая в статье. Ну или в 5 раз выше, чем на старте статьи.

    Reply
  23. best_it_director

    (22) ты бешеный. Я твои практики для своих бойцов тоже использовал, у меня результат поскромнее — 2.5, за полгода.

    Reply
  24. 1c-intelligence

    (23) ну, у большинства людей коэффициент равен единице 🙂

    Так что не я, а ты бешеный — ты ж сам все делаешь. Если хочешь, давай встретимся, расскажешь об успехах, может подскажу что.

    Reply
  25. best_it_director

    (24) да как с тобой встретишься, ты ж из своей дыры не вылезаешь 🙂

    Но я тоже хочу коэффициент 4. Я директору показал свою практику и твои статьи. Он наверняка не читал, но моя практика его сильно заинтересовала, хочет попробовать на других отделах.

    Вопросов к тебе море, как лучше задать? Лично? По электронной почте?

    Reply
  26. 1c-intelligence

    (25) да как хочешь. В комментах спроси, а то только плюсы ставишь и ничего не спрашиваешь.

    Reply
  27. best_it_director

    (26) о, ладно, щас тогда нафигачу тебе вопросов.

    Reply
  28. BelikJan

    (27) фигачь их сюда, а не в личку, чтобы все ознакомились )

    Reply
  29. best_it_director

    Мне про контроллинг интересно, из второго видео. Расскажешь поподробнее?

    Reply
  30. Ta_Da

    (17) Есть сильные сомнения в том, что где-то вне 1С все принципиально лучше. Есть опыт работы/общения с разработчиками вне 1С. Там и проект 6-летнего возраста про разработку (аутсорс) «своя альтернатива google documents для автоматизации учета в европейской больнице», без наличия демо, зато с финансированием.

    И разработка внутренней (но которую успешно умудряются продавать) учетной системы на asp.net, с отделом разработки человек этак на 100. Кресла-мешки, приставки и печеньки. При этом в учетной системе, которая уже пережила три мажорные версии не позволяет вывести отчет по продажам, если в первую строку отчета попала компания с кириллическим названием (напоминаю, компания работает в СНГ и у них собственные названия кириллические).

    Про волшебные внедрения как 1С так и не 1С систем я могу рассказывать часами.

    Так что, перефразируя Карлина: «1С в порядке, это люди г*вно». И размазаны они по всей IT-сфере более-менее ровным слоем.

    Reply
  31. Ta_Da

    (20) Ну т.е. не просто «бежать», а «подготовиться и бежать» =)

    P.S. свой аналог «кастомизации на лету» как раз внедряю у себя на работе, именно с такими мыслями («зато потом будет опыт и на новой работе смогу это повторить»).

    Reply
  32. Kutuzov

    Как я понял, измерение эффективности проводилось с помощью «внутренних» параметров вашей команды. Интересно — для внешней системы как-то проводили измерение изменения эффективности? Т.е. для завода полезность вашего отдела тоже возросла в 4 раза, или это уже сложнее измерить?

    Reply
  33. yogaga

    (30) Вне 1С банально выбор больше. На 1С по гибким методикам работают (ну, говорят, что работают) некоторые московские франчи, да штук 5 крупных отделов разработки больших компаний.

    Reply
  34. 1c-intelligence

    (32) полезность для завода — немного другая тема. Заводу казалось, что ему полезно наше ускорение.

    Но настоящая цепочка длиннее:

    1. Надо определить реальные проблемы завода, которые можно решить с помощью автоматизации или бизнес-программирования;

    2. Надо выполнить работы по автоматизации или бизнес-программированию;

    3. Надо оценить результат;

    4. Надо вернуться к п.1.

    Наше ускорение работало над эффективностью п.2, поэтому оно безотносительное. Если правильно выполнен п.1, то ускорение п.2 ускоряет п.1, и тогда польза прям очевидна. Если коряво выполнен п.1, то п.2 — просто развлекалово.

    У нас был опыт и первого, и второго варианта. Но это, повторю, не особо связанные вещи. Мне кажется, что ускорение п.2 важнее, т.к. п.1 намного легче, к нему просто доступа обычно нет.

    Reply
  35. 1c-intelligence

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

    Reply
  36. pm74

    (31) 🙂 каждый тру 1сник пишет свою кастомизацию

    Reply
  37. yogaga

    (35) Это да. Но тут есть другая причина — крупные клиенты пока на «гибкие методики» клюют неплохо…

    Reply
  38. 1c-intelligence

    (37) да, потому неплохо и живут консультанты, «переводящие работу на гибкие методики». Результат? Ускорение? Не, не слышали.

    Reply
  39. BackinSoda

    Методика подходит если все в команде заинтересованы в результате. Что делать если вы один из кроликов/осликов/пяточков ?

    зы: вижу ответили уже в 20ом посте

    Reply
  40. YanovM

    Подскажите пожалуйста автора книги «Кодекс самурая»)

    Reply
  41. 1c-intelligence

    (40) Ямамото Цунэтомо

    Reply
  42. Vovan1975

    (34)

    Мне кажется, что ускорение п.2 важнее, т.к. п.1 намного легче, к нему просто доступа обычно нет.

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

    Reply
  43. 1c-intelligence

    (42) это очень просто — https://infostart.ru/public/622937/

    Reply
  44. Vovan1975
    Мне стало интересно, я перечитал эту книгу еще раз и обратил внимание, что примерно на каждой 10-ой странице написано: для того, чтобы быстро принимать решения, надо заранее подумать, как ты будешь действовать в такой-то ситуации.

    На что это похоже?

    Это похоже на стратегию, когда у вас есть правила для принятия решений.

    Нет, дорогой автор. Это не стратегия. Это называется прогноз развития ситуации.

    Reply
  45. 1c-intelligence

    (44) а какая разница, как это называется?

    Reply
  46. Vovan1975

    (43) неа, не очень. Даже для ит директора. Для рядового программера — еще более сложно.

    Reply
  47. 1c-intelligence

    (46) вы пробовали?

    Reply
  48. Vovan1975

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

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

    Reply
  49. 1c-intelligence

    (47)

    я понимаю что в интернетах дофига всяких умных определений, но приведенное мной — пригодно для практического использования

    расскажете, как практически использовали приведенное вами определение? Как я использовал свое — рассказал в статье, и результаты привел.

    Reply
  50. yogaga

    (46) Так что, и пытаться не стоит? Или просто нет знаний/способностей?

    Reply
  51. 1c-intelligence

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

    Я использовал такие группы:

    1. С начала недели;

    2. С начала текущего дня;

    3. С начала вчерашнего дня;

    4. Текущая задача.

    Соответственно, раз в 1-2 часа поглядываешь, особенно на п.2. Если там пусто, мельком смотришь на п.3. Если текущая задача большая, то пох — значит, весь день провозится. Если маленькая, значит затупил — спрашиваешь, чо как.

    Если текущая задача большая, и в п.2 пусто, и в п.3 пусто — значит, затупил, надо помогать.

    Reply
  52. Vovan1975

    (48) да. Итоги, правда, были сильно разные. Но всегда было весело.

    Reply
  53. 1c-intelligence

    (52) сложно было? И кто вы — итдиректор или программист?

    Reply
  54. Vovan1975

    (50) С чего бы это? Вовсе нет. Нужно, будет весело. Но — потребуется некоторая работа над собой. Я просто полагаю это в рамках ответа на форуме сложно будет описать,наверняка глупо будет выглядеть и сбивчиво.

    Reply
  55. Vovan1975

    (53) программист.

    Насчет сложно — мне не очень, но дело в том что до программиста 1с я занимался деятельностью, в основе которой лежал сбор и анализ информации, мне было проще.

    Reply
  56. YanovM

    (41) Спасибо

    Reply
  57. 1c-intelligence

    (55) вам не сложно, мне не сложно. Кому тогда сложно? Вы кого имели в виду, когда говорили

    Даже для ит директора. Для рядового программера — еще более сложно.
    Reply
  58. Vovan1975

    (57) потому что рядовой программер традиционно слаб в общении с остальными людьми. Программирование здорово капает на мозги, в итоге остальные люди не очень рвутся общаться с программмером и наоборот — программер не очень общается с людьми-неайтишниками.

    Программисты тяжки в этой деятельности с новомодным названием софт скиллс.

    Reply
  59. yogaga

    (57) Сложно для того, кто, как большинство 1С-ников, не обладает знаниями об устройстве бизнеса, и как бизнес можно оптимизировать.

    Reply
  60. 1c-intelligence

    (58) ну это же вы просто обобщили программистов, не зная их?

    Reply
  61. Vovan1975

    (60) я программером работаю уже наверно лет 15. Общаюсь как с ними так и с непрограммерами. Такие дела.

    Reply
  62. 1c-intelligence

    (59) читайте статьи про бизнес-программирование, и получите знания об устройстве бизнеса и о том, как его можно оптимизировать.

    Предубеждения только уберите, и все получится.

    Reply
  63. yogaga

    (57)Кстати, у вас в отделе, например, было 5 программистов. Один смог, остальным, тогда, получается надо менять работу, если они тоже захотят?

    Reply
  64. 1c-intelligence

    (61) один смог что? начальником стать?

    Reply
  65. 1c-intelligence

    (62) ну так и я так же, только не 15, а 13 лет.

    Но у меня впечатления другие. Может у вас фильтр?

    Reply
  66. yogaga

    (63) Именно, для этого надо, кроме программирования, расширять свой кругозор в сторону, условно, «менеджмента». Не всем программистам это надо.

    Reply
  67. yogaga

    (64) Стать бизнес-программистом на этом предприятии.

    Reply
  68. 1c-intelligence

    (67) почему тогда остальным менять работу надо? Бизнес-программист — это не начальник, это тот же самый программист, только объект воздействия другой. Их может быть сколько угодно на одном предприятии.

    Reply
  69. yogaga

    (68) Это как, в отделе 5 программистов, из них 2 бизнес-программиста, а остальные просто программисты? Или бизнес-программисты перестают быть просто программистами, и получают зарплату больше просто программистов?

    Reply
  70. 1c-intelligence

    (69) бизнес-программист — это дополнительная компетенция. Она не выключает в человеке программиста. Зарплату бизнес-программистам, конечно, надо платить более высокую, чем обычным программистам. Разумеется, когда они результат покажут.

    Reply
  71. yogaga

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

    Reply
  72. 1c-intelligence

    (71) если ты один из программистов, и захотел стать бизнес-программистом, то тебе должно быть насрать, что по этому поводу думают другие, что они собираются делать, что они говорят, что они скажут и т.д.

    Reply
  73. yogaga

    (72) По большому счету да, максимум что потеряешь — текущее место работы. А то, что приобретешь — навсегда твоим останется.

    Reply
  74. Vovan1975

    (65) возможно, конечно что у меня неверное впечатление сложилось, просто людей, которые под него не попадали, было весьма мало.

    Reply
  75. user1012597

    Спасибо! Будем изучать

    Reply
  76. МимохожийОднако

    Статья получилась любопытная.

    Однако фраза на финише статьи

    я ушел из этой компании,…мои ребята в компании остались, они продолжили замерять свою эффективность, и дали мне свои показатели, как они работают сейчас. Сейчас их эффективность упала до 2,5 балла.

    В японских компаниях практикуется метод оценки качества работы руководителя таким способом.

    Одновременно отправляли в отпуск руководителей и специалистов одного уровня (например, начальников отделов) и сравнивали результат до и во время отпуска. Меры применяли к тем, у кого показатели падали и к тем, у кого показатели повышались. Мысль моего замечания в том, что «казахский Scrum» фактически держался на одном человеке и его внедрить не удалось. Т.е. в статье не методика, а личный опыт энтузиаста. И не ясно по какой причине автор ушел, и по какой причине программисты остались.

    Как-то так….

    Reply
  77. Mantis

    Это хорошо , что вам стало скучно ))))

    У нас отдел 15 человек и не когда скучать ))))

    Reply
  78. hakerxp

    Работал я в компании, где применялся SCRUM и прочая лабуда. Как по мне — данные системы созданы для задр…ния сотрудников.

    Ниже по пунктам:

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

    2. Человек приходит работать за деньги! А не ради руководителя или фирмы — ему на нее …. Так вот — мотивировать сотрудников нужно не отчетами и всякого рода штрафами, а ПРЕМИЯМИ, поощрениями различного рода! У многих есть семьи, и человек, всегда заинтересован в ее благополучии. Следовательно, если он будет знать, что если он переработает сегодня-завтра, то это улучшит его материальное положение.

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

    4. Анархия — мать порядка. Это я к чему — когда начальство уходило в отпуск, сотрудники продолжали работать слажено, и даже более на эмоциональном подъеме, чем с начальником. В связи с этим, и производительность труда росла. Т.е. при данных системах — начальник — цепной пес, который все время дергает сотрудников и держит их в напряжении. Следовательно, сотрудники либо «ломаются», либо просто уходят.

    5. Обезличенный механизм. В угоду скорости, часто страдает отношение к сотрудникам. А каждый человек — личность, и следовательно, нужен свой подход. Но scrum и прочие похожие системы, не учитывают проблем и возможностей сотрудников, что пагубно влияет на производительность труда.

    Reply
  79. yogaga

    (78) У вас был скрам только по названию, то что вы описываете не имеет с ним ничего общего.

    Reply
  80. Mantis

    Вообще сразу понятно об амбициях человека 4 кодера и он ИТ директор… у нас отдел ИТ из 30 человек есть два начальника админов и программистов и есть начальник департамента ну вот ну ни как не дотягиваем до ИТ директора)))

    А такие вот креативные ИТ директора долго на одном месте не задерживаются.

    Reply
  81. mifka186

    (78)

    Отчет о проделанной работе каждый день

    Вообще мимо Скрама. Утренние митинги — это не отчет о том что сделано, это способ выяснить возможные проблемы до того как они окажут влияние на работу. Решать вопросы в рабочее время скрам не запрещает, т.е. нет такого, что есть вопрос — дождись митинга. Для решения таких вопросов и нужен скрам мастер.

    Люди и их взаимодействия важнее процессов и инструментов — один из принципов. Остальное можно посмотреть в манифесте.

    Reply
  82. Vovan1975

    вообще, кстати, фапанье на японские «великие технологии» — оно очень забавно…

    Reply
  83. 1c-intelligence

    (82) вообще, кстати, наблюдение за чужим фапаньем — намного забавнее самого фапанья. Удачи вам в этом нелегком деле.

    Reply
  84. acsent

    тк все упало после того как ты оттуда ушел, то получается что единственная методика рабочая — это постоянно проверять не застопорился ли прог, и если что то сразу реагировать.

    Ушел помошник-контролер и все вернулось на круги своя

    Reply
  85. acanta

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

    Reply
  86. Vovan1975

    (83) да не то слово. Правда я не понял почему оно нелегкое, но вам виднее.

    Reply
  87. Vovan1975

    (85) это потому что пользователей очень инетересует решение проблем а не оптимальный, качественный и т.д. код. Будете решать проблемы, будет и благодарность.

    Reply
  88. acanta

    (87) Есть некий предел. В том числе и качества данных и архитектуры, при котором возможно (достаточно) быстрое решение проблем. Здесь действует принцип Макдональдсов — выдалась свободная минута — наведи порядок (в конфигураторе). Но если программист не считает что он вправе наводить порядок в метаданных и будет ждать благодарности от пользователей за это (что может быть чревато их недовольством) и тем более если так не считает заказчик (на что он имеет основания ) то работа превращается в болото, где каждое лишнее движение затягивает все глубже в трясину.

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

    Reply
  89. acanta

    «Работа на будущего работодателя» как инструмент для мотивации тоже очень узкое место.

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

    Reply
  90. 1c-intelligence

    (77) скука не зависит от количества выполняемой работы.

    Reply
  91. 1c-intelligence

    (80)

    Вообще сразу понятно об амбициях человека 4 кодера и он ИТ директор

    мне бы вашу прозорливость.

    Reply
  92. 1c-intelligence

    (84) поменялась ключевая идея, цель существования ИТ-отдела. Просто так получилось, что она была в моем лице.

    Reply
  93. amon_ra

    (3) уважаемый, не первый раз вас встречаю в комментариях где Вы стараетесь приебаться к словам. Зачем? Нынешний русский язык наполнен заимствованными словами и уж если пытаться приебываться, то можно к любому слову, вот кстати, слово «автор» латинское, возможно когда-то кто-то изрекая из уст своих данное слово получал в ответ критику, ибо есть же слово такое как творец, зачем использовать эти всякие заморские словечки?

    Reply
  94. Steelvan

    (97) Это сложно понять человеку, развитие которого остановилось на уровне школоты.

    Reply
  95. 1c-intelligence

    (98) а как ваша фраза относится к Эмилю? Или я чего-то не знаю, и вы знакомы?

    Reply
  96. Steelvan

    (99) Он спрашивает «Зачем». Я отвечаю «Это сложно понять человеку с низким уровнем развития».

    Причинно-следственную связь улавливаете ?

    Reply
  97. 1c-intelligence

    (101) неа. Только желание выглядеть умнее, чем есть на самом деле.

    Reply
  98. Steelvan

    (6) Сломать свой твердый мозг можете только вы.

    Reply
  99. genayo

    (103) Вас разбанили? Поздравляю…

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *