Я хочу рассказать о своем опыте ускорения автоматизации в команде программистов, и о том, какие приемы мы применили на практике, и что из этого получилось.
Начальные условия
Наш «эксперимент» по ускорению работы программистов мы проводили в следующих условиях:
- Это было территориально распределенное производственное предприятие;
- В эксперименте приняли участие 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 в Москве.
Видосы интереснее статьи 🙂
(1) согласен.
стикеры =наклейки
кастомизация = настройка
и т.п.
Автор, учи русский !
(1) Да, есть у Ивана определенная харизма :))
(3)
если будете называть стикеры наклейками, вас будет сложно понять. Например, фраза «запиши на наклейке» звучит странно.
слово «настройка» не отражает сущности кастомизации. Кастомизацией может быть, например, программирование. Программирование же не назовешь настройкой?
(5) Хорошо, что вы не используете слова типа «фасилитировать», бедняга наверное мозг бы сломал в попытке перевести…
(6) да я не против замечания коллеги, просто предложенные им синонимы не кажутся подходящими.
(4) есть, но странная какая-то. Говорит быстро и сбивчиво, но слушать интересно. Пусть работает над собой.
Прям до слёз. Ввели фибоначчи, задачи, доску даже в 1С нарисовали. И всё. Скрам не совсем подходит для нашей организации.
не дочитал из-за обилия картинок )
(10) лучше видео смотрите. Это статья по докладу, ее сложно сделать хорошей, потому что информация изначально рассчитана на устное изложение.
Расскажите, как оценивался результат?
Всегда интересно, по каким критериям оценивается эффективность программистов.
Стали писать больше строк кода, выполнять большее количество задач в единицу времени?
(12) стали выполнять больше задач в единицу времени.
Задачи оценивались по трудоемкости в баллах — 1, 2, 3, 5, 8 и т.д.
Сумма баллов выполненных задач в день как раз и увеличилась — с 4.2 балла до 17.3 баллов.
(13) а как была сделана обратная петля связи управления, чтоб эти цифры не улетали вверх. Можно же согласованно начать оценивать средние задачи в большее количество баллов? Может есть какой-то базовый набор действий оцененный в баллах? Чтоб стартовать с чего-то.
Так задачи стали сложнее или их больше стали выполнять?
(15) Стали дороже оценивать =)
(0) а что делать если есть отдел с разработчиками, тестировщиками, бизнес-аналитиками, доской со стикерами и при этом у большинства нет никакого желания ускоряться в 4 раза, избавляться от суррогатов и т.п.? бежать?
(16)
Из 1С…
(14) да, был базовый набор, мы его называли якорь, их было несколько — это типовые задачи, которые периодически встречаются. До этой практики у нас была , от которой осталось наследство — нормировка задач.
Ну и я следил за оценками, потому что эксперимент был для себя, а не для демонстрации. Хотелось получить реальное, а не дутое ускорение.
Есть такое понятие — инфляция задач, когда они становятся все дороже и дороже в баллах. У нас было наоборот — дефляция задач, когда мы делаем некий инструмент, из , и задачи, которые раньше делали, например, за 5 баллов, мы с использованием инструмента начинаем делать за 2 балла.
(15) стали больше выполнять, в единицу времени. Т.е. увеличили скорость решения задач.
(16)
ответ на этот вопрос давал во втором видео.
Так же, развернутый ответ есть в этой статье — , и еще в этой —
Иван, а в Окнософте ты внедрял подобную практику? Есть результаты?
(21) да, внедрял и внедряю. Сейчас, если выразить в единицах статьи, скорость 23 балла в день, т.е. на 30% выше, чем самая высокая в статье. Ну или в 5 раз выше, чем на старте статьи.
(22) ты бешеный. Я твои практики для своих бойцов тоже использовал, у меня результат поскромнее — 2.5, за полгода.
(23) ну, у большинства людей коэффициент равен единице 🙂
Так что не я, а ты бешеный — ты ж сам все делаешь. Если хочешь, давай встретимся, расскажешь об успехах, может подскажу что.
(24) да как с тобой встретишься, ты ж из своей дыры не вылезаешь 🙂
Но я тоже хочу коэффициент 4. Я директору показал свою практику и твои статьи. Он наверняка не читал, но моя практика его сильно заинтересовала, хочет попробовать на других отделах.
Вопросов к тебе море, как лучше задать? Лично? По электронной почте?
(25) да как хочешь. В комментах спроси, а то только плюсы ставишь и ничего не спрашиваешь.
(26) о, ладно, щас тогда нафигачу тебе вопросов.
(27) фигачь их сюда, а не в личку, чтобы все ознакомились )
Мне про контроллинг интересно, из второго видео. Расскажешь поподробнее?
(17) Есть сильные сомнения в том, что где-то вне 1С все принципиально лучше. Есть опыт работы/общения с разработчиками вне 1С. Там и проект 6-летнего возраста про разработку (аутсорс) «своя альтернатива google documents для автоматизации учета в европейской больнице», без наличия демо, зато с финансированием.
И разработка внутренней (но которую успешно умудряются продавать) учетной системы на asp.net, с отделом разработки человек этак на 100. Кресла-мешки, приставки и печеньки. При этом в учетной системе, которая уже пережила три мажорные версии не позволяет вывести отчет по продажам, если в первую строку отчета попала компания с кириллическим названием (напоминаю, компания работает в СНГ и у них собственные названия кириллические).
Про волшебные внедрения как 1С так и не 1С систем я могу рассказывать часами.
Так что, перефразируя Карлина: «1С в порядке, это люди г*вно». И размазаны они по всей IT-сфере более-менее ровным слоем.
(20) Ну т.е. не просто «бежать», а «подготовиться и бежать» =)
P.S. свой аналог «кастомизации на лету» как раз внедряю у себя на работе, именно с такими мыслями («зато потом будет опыт и на новой работе смогу это повторить»).
Как я понял, измерение эффективности проводилось с помощью «внутренних» параметров вашей команды. Интересно — для внешней системы как-то проводили измерение изменения эффективности? Т.е. для завода полезность вашего отдела тоже возросла в 4 раза, или это уже сложнее измерить?
(30) Вне 1С банально выбор больше. На 1С по гибким методикам работают (ну, говорят, что работают) некоторые московские франчи, да штук 5 крупных отделов разработки больших компаний.
(32) полезность для завода — немного другая тема. Заводу казалось, что ему полезно наше ускорение.
Но настоящая цепочка длиннее:
1. Надо определить реальные проблемы завода, которые можно решить с помощью автоматизации или бизнес-программирования;
2. Надо выполнить работы по автоматизации или бизнес-программированию;
3. Надо оценить результат;
4. Надо вернуться к п.1.
Наше ускорение работало над эффективностью п.2, поэтому оно безотносительное. Если правильно выполнен п.1, то ускорение п.2 ускоряет п.1, и тогда польза прям очевидна. Если коряво выполнен п.1, то п.2 — просто развлекалово.
У нас был опыт и первого, и второго варианта. Но это, повторю, не особо связанные вещи. Мне кажется, что ускорение п.2 важнее, т.к. п.1 намного легче, к нему просто доступа обычно нет.
(33) мне кажется, важно не сколько человек в какой отрасли работают по гибким методикам, а сколько из них какой-то понятный результат от гибких методик получают. Большинство просто «работают по гибким методикам», в смысле это и есть их результат — «мы работаем по гибким методикам», и никакого другого результата нет.
(31) 🙂 каждый тру 1сник пишет свою кастомизацию
(35) Это да. Но тут есть другая причина — крупные клиенты пока на «гибкие методики» клюют неплохо…
(37) да, потому неплохо и живут консультанты, «переводящие работу на гибкие методики». Результат? Ускорение? Не, не слышали.
Методика подходит если все в команде заинтересованы в результате. Что делать если вы один из кроликов/осликов/пяточков ?
зы: вижу ответили уже в 20ом посте
Подскажите пожалуйста автора книги «Кодекс самурая»)
(40) Ямамото Цунэтомо
(34)
Несогласен. П.1 на самом деле очень сложное действие, а точнее сказать, процесс. Как раз именно таки потому чтобы получить доступ, нужно его заслужить. Ну прям как квест но гораздо сложнее.
(42) это очень просто —
На что это похоже?
Это похоже на стратегию, когда у вас есть правила для принятия решений.
Нет, дорогой автор. Это не стратегия. Это называется прогноз развития ситуации.
(44) а какая разница, как это называется?
(43) неа, не очень. Даже для ит директора. Для рядового программера — еще более сложно.
(46) вы пробовали?
(45) разница в том, что это разные вещи. Стратегия — это в общем цепочка целей для достижения конечной цели(я понимаю что в интернетах дофига всяких умных определений, но приведенное мной — пригодно для практического использования).
Прогноз развития ситуации — это некая сумма ожиданий, как, возможно, будут развиваться события. Быстрота принятия решений осуществляется за счет того что решения приняты заранее, при прогнозировании развития ситуации.
(47)
расскажете, как практически использовали приведенное вами определение? Как я использовал свое — рассказал в статье, и результаты привел.
(46) Так что, и пытаться не стоит? Или просто нет знаний/способностей?
(29) делаешь в своей системе простейший отчет, который показывает, сколько задач выполнено каждым программистом, в баллах и штуках.
Я использовал такие группы:
1. С начала недели;
2. С начала текущего дня;
3. С начала вчерашнего дня;
4. Текущая задача.
Соответственно, раз в 1-2 часа поглядываешь, особенно на п.2. Если там пусто, мельком смотришь на п.3. Если текущая задача большая, то пох — значит, весь день провозится. Если маленькая, значит затупил — спрашиваешь, чо как.
Если текущая задача большая, и в п.2 пусто, и в п.3 пусто — значит, затупил, надо помогать.
(48) да. Итоги, правда, были сильно разные. Но всегда было весело.
(52) сложно было? И кто вы — итдиректор или программист?
(50) С чего бы это? Вовсе нет. Нужно, будет весело. Но — потребуется некоторая работа над собой. Я просто полагаю это в рамках ответа на форуме сложно будет описать,наверняка глупо будет выглядеть и сбивчиво.
(53) программист.
Насчет сложно — мне не очень, но дело в том что до программиста 1с я занимался деятельностью, в основе которой лежал сбор и анализ информации, мне было проще.
(41) Спасибо
(55) вам не сложно, мне не сложно. Кому тогда сложно? Вы кого имели в виду, когда говорили
(57) потому что рядовой программер традиционно слаб в общении с остальными людьми. Программирование здорово капает на мозги, в итоге остальные люди не очень рвутся общаться с программмером и наоборот — программер не очень общается с людьми-неайтишниками.
Программисты тяжки в этой деятельности с новомодным названием софт скиллс.
(57) Сложно для того, кто, как большинство 1С-ников, не обладает знаниями об устройстве бизнеса, и как бизнес можно оптимизировать.
(58) ну это же вы просто обобщили программистов, не зная их?
(60) я программером работаю уже наверно лет 15. Общаюсь как с ними так и с непрограммерами. Такие дела.
(59) читайте статьи про бизнес-программирование, и получите знания об устройстве бизнеса и о том, как его можно оптимизировать.
Предубеждения только уберите, и все получится.
(57)Кстати, у вас в отделе, например, было 5 программистов. Один смог, остальным, тогда, получается надо менять работу, если они тоже захотят?
(61) один смог что? начальником стать?
(62) ну так и я так же, только не 15, а 13 лет.
Но у меня впечатления другие. Может у вас фильтр?
(63) Именно, для этого надо, кроме программирования, расширять свой кругозор в сторону, условно, «менеджмента». Не всем программистам это надо.
(64) Стать бизнес-программистом на этом предприятии.
(67) почему тогда остальным менять работу надо? Бизнес-программист — это не начальник, это тот же самый программист, только объект воздействия другой. Их может быть сколько угодно на одном предприятии.
(68) Это как, в отделе 5 программистов, из них 2 бизнес-программиста, а остальные просто программисты? Или бизнес-программисты перестают быть просто программистами, и получают зарплату больше просто программистов?
(69) бизнес-программист — это дополнительная компетенция. Она не выключает в человеке программиста. Зарплату бизнес-программистам, конечно, надо платить более высокую, чем обычным программистам. Разумеется, когда они результат покажут.
(70) Ну да, с другой стороны скорее всего, если ты один из программистов, и захотел стать бизнес-программистом, то вероятность, что другие тоже хотя-бы только захотят, а не захотят и смогут, не очень высока.
(71) если ты один из программистов, и захотел стать бизнес-программистом, то тебе должно быть насрать, что по этому поводу думают другие, что они собираются делать, что они говорят, что они скажут и т.д.
(72) По большому счету да, максимум что потеряешь — текущее место работы. А то, что приобретешь — навсегда твоим останется.
(65) возможно, конечно что у меня неверное впечатление сложилось, просто людей, которые под него не попадали, было весьма мало.
Спасибо! Будем изучать
Статья получилась любопытная.
Однако фраза на финише статьи
В японских компаниях практикуется метод оценки качества работы руководителя таким способом.
Одновременно отправляли в отпуск руководителей и специалистов одного уровня (например, начальников отделов) и сравнивали результат до и во время отпуска. Меры применяли к тем, у кого показатели падали и к тем, у кого показатели повышались. Мысль моего замечания в том, что «казахский Scrum» фактически держался на одном человеке и его внедрить не удалось. Т.е. в статье не методика, а личный опыт энтузиаста. И не ясно по какой причине автор ушел, и по какой причине программисты остались.
Как-то так….
Это хорошо , что вам стало скучно ))))
У нас отдел 15 человек и не когда скучать ))))
Работал я в компании, где применялся SCRUM и прочая лабуда. Как по мне — данные системы созданы для задр…ния сотрудников.
Ниже по пунктам:
1. Отчет о проделанной работе каждый день — мы люди все взрослые и сознательные, если работаем. Нам установили сроки — мы сами рассчитываем как и что делать и в какой день. Если есть вопросы, а они есть, то они появляются и сразу их нужно решить, а не ждать утра для отчета. Как показала практика, там где я работал, когда не было данных отчетов по утрам, работа велась веселее.
2. Человек приходит работать за деньги! А не ради руководителя или фирмы — ему на нее …. Так вот — мотивировать сотрудников нужно не отчетами и всякого рода штрафами, а ПРЕМИЯМИ, поощрениями различного рода! У многих есть семьи, и человек, всегда заинтересован в ее благополучии. Следовательно, если он будет знать, что если он переработает сегодня-завтра, то это улучшит его материальное положение.
3. Слежение за рабочим временем. Программисты — народ креативный, и голова у нас работает в разное время суток по-разному. Например, я хорошо соображаю утром и в первой половине дня. Другие — вечером и ночью. Следовательно, в нашем случае, учет рабочего времени лишнее. Главное — решить задачу в срок.
4. Анархия — мать порядка. Это я к чему — когда начальство уходило в отпуск, сотрудники продолжали работать слажено, и даже более на эмоциональном подъеме, чем с начальником. В связи с этим, и производительность труда росла. Т.е. при данных системах — начальник — цепной пес, который все время дергает сотрудников и держит их в напряжении. Следовательно, сотрудники либо «ломаются», либо просто уходят.
5. Обезличенный механизм. В угоду скорости, часто страдает отношение к сотрудникам. А каждый человек — личность, и следовательно, нужен свой подход. Но scrum и прочие похожие системы, не учитывают проблем и возможностей сотрудников, что пагубно влияет на производительность труда.
(78) У вас был скрам только по названию, то что вы описываете не имеет с ним ничего общего.
Вообще сразу понятно об амбициях человека 4 кодера и он ИТ директор… у нас отдел ИТ из 30 человек есть два начальника админов и программистов и есть начальник департамента ну вот ну ни как не дотягиваем до ИТ директора)))
А такие вот креативные ИТ директора долго на одном месте не задерживаются.
(78)
Вообще мимо Скрама. Утренние митинги — это не отчет о том что сделано, это способ выяснить возможные проблемы до того как они окажут влияние на работу. Решать вопросы в рабочее время скрам не запрещает, т.е. нет такого, что есть вопрос — дождись митинга. Для решения таких вопросов и нужен скрам мастер.
Люди и их взаимодействия важнее процессов и инструментов — один из принципов. Остальное можно посмотреть в манифесте.
вообще, кстати, фапанье на японские «великие технологии» — оно очень забавно…
(82) вообще, кстати, наблюдение за чужим фапаньем — намного забавнее самого фапанья. Удачи вам в этом нелегком деле.
тк все упало после того как ты оттуда ушел, то получается что единственная методика рабочая — это постоянно проверять не застопорился ли прог, и если что то сразу реагировать.
Ушел помошник-контролер и все вернулось на круги своя
(84) Никто из пользователей (бухгалтеров и операторов) НЕ ПОХВАЛИТ так программиста за оптимально-качественный код запроса или построение алгоритмов, как это может руководитель отдела. Программисты оказались без человека, способного проконтролировать не только факт работы (это может и сторож видеть), не только скорость разработки (это могут пользователи), но и глубину их мыслей. Всегда можно «потом об этом подумать».
(83) да не то слово. Правда я не понял почему оно нелегкое, но вам виднее.
(85) это потому что пользователей очень инетересует решение проблем а не оптимальный, качественный и т.д. код. Будете решать проблемы, будет и благодарность.
(87) Есть некий предел. В том числе и качества данных и архитектуры, при котором возможно (достаточно) быстрое решение проблем. Здесь действует принцип Макдональдсов — выдалась свободная минута — наведи порядок (в конфигураторе). Но если программист не считает что он вправе наводить порядок в метаданных и будет ждать благодарности от пользователей за это (что может быть чревато их недовольством) и тем более если так не считает заказчик (на что он имеет основания ) то работа превращается в болото, где каждое лишнее движение затягивает все глубже в трясину.
Пользователи требуют хлеба и зрелищ. Жест с поднятым большим пальцем кстати означает не похвалу победителю, а всего лишь помилование побежденному.
«Работа на будущего работодателя» как инструмент для мотивации тоже очень узкое место.
Это не является зоной комфорта большинства пользователей. В буквальном смысле ни один работодатель не будет добровольно оплачивать обучение для конкурентов. Снижение скорости работы думаю, в большей степени связано именно с вашим уходом и тем, что оставшиеся «оказались виноваты».
(77) скука не зависит от количества выполняемой работы.
(80)
мне бы вашу прозорливость.
(84) поменялась ключевая идея, цель существования ИТ-отдела. Просто так получилось, что она была в моем лице.
(3) уважаемый, не первый раз вас встречаю в комментариях где Вы стараетесь приебаться к словам. Зачем? Нынешний русский язык наполнен заимствованными словами и уж если пытаться приебываться, то можно к любому слову, вот кстати, слово «автор» латинское, возможно когда-то кто-то изрекая из уст своих данное слово получал в ответ критику, ибо есть же слово такое как творец, зачем использовать эти всякие заморские словечки?
(97) Это сложно понять человеку, развитие которого остановилось на уровне школоты.
(98) а как ваша фраза относится к Эмилю? Или я чего-то не знаю, и вы знакомы?
(99) Он спрашивает «Зачем». Я отвечаю «Это сложно понять человеку с низким уровнем развития».
Причинно-следственную связь улавливаете ?
(101) неа. Только желание выглядеть умнее, чем есть на самом деле.
(6) Сломать свой твердый мозг можете только вы.
(103) Вас разбанили? Поздравляю…