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

Управление - Личная эффективность

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

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

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

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

  • Это было территориально распределенное производственное предприятие;
  • В эксперименте приняли участие 4 программиста 1С и я, их руководитель (IT-директор);
  • Мы – штатные программисты по поддержке комплекса конфигураций;
  • Нам стало скучно, и мы решили развиваться.

В первую очередь, желание развиваться возникло после того, как нам на глаза попалась книжка Джеффа Сазерленда про Scrum. Про эту методику вы уже наверняка много знаете, поэтому я на ней останавливаться не буду. Основная часть статьи будет не про Scrum.

 

 

Итак, когда мы прочитали эту книгу, то обнаружили, что есть дилемма, которая заключается в неправильном переводе названия книги. Английское название говорит о том, что Scrum ускоряет работу в четыре раза: «Искусство делать вдвое больше работы за половину времени». А в русском переводе утверждается, что Scrum – это некий революционный метод управления проектами. Когда руководителей ИТ-отдела готовят к собеседованиям, им часто говорят – обращайте внимание, на чем концентрируется человек – на процессах или на результатах. Русский перевод концентрируется на процессе.

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

 

Итак, мы прочитали эту книгу и запустили у себя классический Scrum со всеми его основными этапами бизнес-процесса (они приведены на слайде).

Сразу упомяну способ измерения (он будет фигурировать на всем протяжении доклада). Традиционный способ измерения в Scrum – это покер планирования. Он заключается в следующем: по каждой задаче командой (или теми ее участниками, которые что-то в этой задаче понимают), выставляется оценка в баллах – 1, 2, 3, 5, 8 и до 34 (цифры из ряда Фибоначчи). По совокупности оценок берется средняя. Задача считается выполненной, когда ее принял заказчик.

Первые результаты

 

 

Что нам дало внедрение классического Scrum? До него средняя выработка в день на человека была 4,2 балла, а с его внедрением показатель вырос до 7,73 балла. Получилось, что наша продуктивность увеличилась примерно в два раза.

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

Захотелось большего

 

 

Повышение производительности в два раза показалось нам скучным. Поэтому мы стали читать книгу еще раз. На странице 54-55 заметили некие сюхари. В книге было написано, что это принцип из айкидо, который гласил – сначала сделайте все по правилам (сю), потом начните импровизировать (ха), и лишь затем отделяйтесь и творите свою методику сами (ри).

Мы решили так и сделать.

 

 

Базовый алгоритм ускорения, который рекомендуется в книге Джеффа Сазерленда – это цикл Деминга. Простыми словами его можно сформулировать так: смотришь, как работают твои люди, замечаешь, где они тупят (где происходит задержка), придумываешь какое-нибудь изменение, внедряешь и смотришь, что получилось. Если стало лучше, быстрее – оставляешь изменение. Если стало хуже – убираешь изменение. Главное – делать это быстро.

 

 

Важно, что Теория Ограничений Систем говорит примерно о том же, только концентрируется на другом. Она говорит – находите в вашей системе самое узкое звено, расширяйте его или убирайте. Затем повторяйте снова.

Цель, и у того, и у другого – сделать так, чтобы как можно быстрее получать результат на полном производственном цикле. Ту же самую мысль, кстати, высказывал разработчик Toyota Production System – цель производственной системы заключается в том, чтобы деньги клиента поступали как можно быстрее.

 

 

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

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

 

Команда экспериментаторов

 

 

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

 

 

Поэтому вместо двух Стасов, Олега и Игоря в качестве команды будут представлены персонажи, которых все знают, и которые максимально похожи на реальных людей:

  • Кролик – умный, себе на уме, молчаливый.
  • Пятачок – самый молодой, самый прыткий, самый любознательный.
  • Ослик – самый депрессивный, он и в жизни такой.
  • А сова… На самом деле в оригинале книжки была не сова, а филин, мужского рода. Вот и в команде был филин.

 

Следующий этап – импровизация

 

 

В первый же день, когда мы решили все поменять, мы:

  • Выбросили Scrum-доску и стикеры. Scrum-доску заменили информационной системой на базе 1С:Документооборот;
  • Стикеры заменили задачами в этой информационной системе;
  • Оставили покер и измерение скорости;
  • Убрали ежедневные собрания, ретроспективы, проекты (вообще как сущность) – оставили просто некую классификацию задач по темам;
  • Добавили постоянное наблюдение за простоями, потерями;
  • И добавили постоянное изменение процесса.

 

 

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

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

 

 

На всякий случай, упомяну, откуда взялись эти ускорители – это отсылка к предыдущему докладу. Здесь нет ничего нового. Некоторые принципы я придумал сам, некоторые придумали мои ребята, что-то мы прочитали из книжек. Например, когда в книжке рекомендуется для решения такой-то проблемы поступать вот так, надо брать и пробовать. Если получается, то оставляем.

Нулевое изменение

 

 

Итак, первое, с чего началось наше переосмысление процесса – это книга «Кодекс самурая». Я рекомендую всем ее прочитать, приобрести, и держать у себя дома. Потому что она написана 500 лет назад, и уже 500 лет назад люди знали, как управлять, как подчиняться, как саморазвиваться и как совершенствоваться.

Внимание персонажа, которого я называю Пятачком, в «Кодексе самурая» привлекли вот такие две фразы. Он увидел, что:

  • Решение надо принимать очень быстро – за семь вдохов;
  • А если ты не принимаешь решение быстро, то результат будет плачевным.

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

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

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

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

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

Мне такое определение не близко, оно для моих целей не подходит.

Поэтому мы оставили для себя только второе определение и стали воспринимать стратегию только как набор правил для принятия решений.

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

Главный секрет улучшений

 

 

Следующий основополагающий принцип, к которому мы пришли – это «главный секрет улучшений».

Хотите, верьте, хотите – нет, но мы вывели «главный секрет улучшений», в эффективности которого много раз убедились.

Его можно сформулировать так: 75% проблем в изменениях возникает из-за того, что люди не работают так, как им велели.

Почему это происходит? Дело в том, что люди, которые пытаются внедрять изменения (например, Scrum) приходят и говорят своим подчиненным: «Вы теперь работаете по-новому». А потом просто уходят. И когда через неделю или через две возвращаются, то видят – результатов-то нет. И в итоге эти «изменяторы» решают, что Scrum не работает, и навсегда вычеркивают его из своей памяти и из своего набора инструментов. То же самое происходит и со всеми остальными методиками. Я это видел безумное количество раз в своей компании, и меня постоянно пытались убедить в том, что что-то (какое-то изменение) не работает.

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

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

 

Еще одна интересная штука. Вокруг всегда было много крутых управленцев. Я сам когда-то хотел таким стать.

Кто такой крутой управленец? Это тот, кто считает, что нужно ставить задачу, называть срок, и когда срок проходит, а задача не выполнена, наказывать исполнителя.

Но мы для себя решили, что сроки – это зло. Почему?

  • Во-первых, когда у вас пул задач, например, 150, и вы на каждую из них ставите срок, вам надо каждый день эти сроки пересчитывать, потому что они все время «уплывают». Это колоссальное время на администрирование.
  • Во-вторых, из-за того, что сроки все время «уплывают», они всегда неверные.
  • Кроме того, степень попадания человека в сроки вообще ни о чем не говорит. Когда на стратегической сессии в компании люди докладывают, что выполнили все задачи в срок, разве можно сказать, что эти специалисты эффективны? Ведь там могла быть одна задача на квартал. Если она выполнена в срок – человек эффективный? Возможно, с точки зрения компании, да.
  • И еще мы для себя решили, что управление по срокам – это «женский подход» в менеджменте.

Последний пункт надо пояснить отдельно. Сразу прошу женщин не обижаться, тем более что такой подход сейчас даже чаще у мужчин встречается. Эта метафора была придумана для того, чтобы как-то объяснить действия некоторых управленцев.

Аналогия из жизни: представьте, что женщина просит мужчину починить кран и дает ему на это 5 дней. Что будет происходить все эти пять дней? Мужчина будет заниматься какими-то своими делами, а женщина – будет напоминать? Нет, не будет. Она будет каждый день приходить и тихонько смотреть – починил или не починил. И вот наступает пятый день, женщина подходит, смотрит – не починил. Ждет утра, а утром…

 

 

Утром можно наблюдать вот такую картину!

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

 

 

А теперь проведите аналогию с крутыми управленцами, которые ставят задачу так, чтобы человек ее в срок не выполнил, и его потом можно было наказать. Мне кажется, что это – какой-то садизм. Они так развлекаются и считают, что за такую работу им надо платить по 300-500 тысяч рублей в месяц.

Мы – не такие, поэтому мы сформулировали для себя принцип, что срок нужен только тогда, когда после него уже ничего делать не нужно. Например, срок сдачи отчетности. После него можно задачу уже и не делать, потому что штраф за несвоевременную сдачу отчетности, кажется, процентов 20 от выручки?

 

Цели

 

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

 

 

Приходишь на работу – а твой сотрудник сидит вот такой.

 

 

Или вот такой.

 

 

Или даже вот такой.

Что с таким работником делать?

 

 

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

 

 

Человек, на которого постоянно орут, превращается в «засранца». Хотя правильнее сказать, что засранец – это тот, кто его таким сделал.

Чем плохо такое состояние? Если на человека постоянно орут, вы его слез уже не увидите, а значит, вы не узнаете, что он сидит и ничего не делает. Потому что человек в депрессии ничего не делает. Для эффективности это колоссальная потеря. Если человек с утра пришел в депрессии, он весь день будет сидеть в интернете, откроет конфигуратор и будет туда-сюда быстро переключаться. Все же программисты сидят монитором от двери, правильно?

Поэтому на людей лучше не кричать. Надо проанализировать ситуацию, и возможно, окажется, что у человека банально нет мотивации. А мотивации у человека нет потому, что у него нет цели. Он пришел на работу и не знает – зачем. А если он еще и дома какой-то негатив получил, например, за то, что каких-то домашних целей не достиг (жена хочет в отпуск на Мальдивы, а он этого обеспечить не может), он приходит на работу просто посидеть. Потому что как достичь цели, он не знает. А может, у него и цели нет.

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

В результате нам удалось вывести некую «среднюю» цель – одну для всех.

Эта «средняя цель» была вот такая – работать на будущего работодателя. В этой формулировке заложено очень много смыслов.

  • Во-первых, цель программиста не связана с текущей работой на текущую организацию. Потому что люди, которые привязываются к текущей организации, когда ее покидают, получают очень большой удар по своей значимости. Ведь то, что было важно здесь, никому не нужно там.
  • Во-вторых, что значит «работать на будущего работодателя»? Это значит получить максимальный абстрактный опыт, который будет полезен большинству будущих работодателей.

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

 

 

Несколько слов про «кастомизацию на лету» – чисто технический способ ускорения работы.

 

 

С этой темой я выступал на INFOSTART EVENT 2015.

 

 

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

 

 

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

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

 

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

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

 

 

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

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

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

 

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

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

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

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

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

 

 

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

 

 

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

 

 

Или вот так.

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

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

 

 

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

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

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

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

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

 

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

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

 

 

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

 

 

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

 

 

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

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

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

 

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

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

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

73

См. также

Комментарии
Сортировка: Древо
1. best_it_director 09.07.18 08:21 Сейчас в теме
Видосы интереснее статьи :)
2. 1c-intelligence 5213 09.07.18 08:44 Сейчас в теме
4. genayo 09.07.18 09:30 Сейчас в теме
(1) Да, есть у Ивана определенная харизма :))
9. best_it_director 09.07.18 10:25 Сейчас в теме
(4) есть, но странная какая-то. Говорит быстро и сбивчиво, но слушать интересно. Пусть работает над собой.
3. Steelvan 09.07.18 09:27 Сейчас в теме
стикеры =наклейки
кастомизация = настройка
и т.п.

Автор, учи русский !
Jimbo; JohnConnor; Риник; Неопределено; roman77; Mantis; pyrkin_vanya; MOPC; PLAstic; alres; +10 7 Ответить
5. 1c-intelligence 5213 09.07.18 10:11 Сейчас в теме
(3)
стикеры =наклейки

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

слово "настройка" не отражает сущности кастомизации. Кастомизацией может быть, например, программирование. Программирование же не назовешь настройкой?
amon_ra; Mi11er; Yakud3a; Артано; qus-qus; +5 1 Ответить
6. genayo 09.07.18 10:14 Сейчас в теме
(5) Хорошо, что вы не используете слова типа "фасилитировать", бедняга наверное мозг бы сломал в попытке перевести...
vynosmozga; A_Max; PLAstic; +3 Ответить
7. 1c-intelligence 5213 09.07.18 10:18 Сейчас в теме
(6) да я не против замечания коллеги, просто предложенные им синонимы не кажутся подходящими.
103. Steelvan 28.08.18 15:37 Сейчас в теме
(6) Сломать свой твердый мозг можете только вы.
104. genayo 28.08.18 17:33 Сейчас в теме
(103) Вас разбанили? Поздравляю...
97. amon_ra 2 22.08.18 18:51 Сейчас в теме
(3) уважаемый, не первый раз вас встречаю в комментариях где Вы стараетесь приебаться к словам. Зачем? Нынешний русский язык наполнен заимствованными словами и уж если пытаться приебываться, то можно к любому слову, вот кстати, слово "автор" латинское, возможно когда-то кто-то изрекая из уст своих данное слово получал в ответ критику, ибо есть же слово такое как творец, зачем использовать эти всякие заморские словечки?
98. Steelvan 23.08.18 08:10 Сейчас в теме
(97) Это сложно понять человеку, развитие которого остановилось на уровне школоты.
99. 1c-intelligence 5213 23.08.18 08:23 Сейчас в теме
(98) а как ваша фраза относится к Эмилю? Или я чего-то не знаю, и вы знакомы?
101. Steelvan 23.08.18 10:53 Сейчас в теме
(99) Он спрашивает "Зачем". Я отвечаю "Это сложно понять человеку с низким уровнем развития".

Причинно-следственную связь улавливаете ?
102. 1c-intelligence 5213 23.08.18 10:56 Сейчас в теме
(101) неа. Только желание выглядеть умнее, чем есть на самом деле.
8. mifka186 6 09.07.18 10:25 Сейчас в теме
Большинство из них просто запустили у себя процесс Scrum, и когда их спрашиваешь: «Что у вас изменилось?» – они говорят: «У нас стало прозрачно, интересно, весело». Но когда интересуешься, как изменились результаты, увеличилась ли скорость разработки, стали ли вы сдавать проекты быстрее – оказывается, что они этого не знают, потому что результативность не измеряли.


Прям до слёз. Ввели фибоначчи, задачи, доску даже в 1С нарисовали. И всё. Скрам не совсем подходит для нашей организации.
10. AlexZhukov 09.07.18 11:57 Сейчас в теме
не дочитал из-за обилия картинок )
Olenevod; Mantis; PLAstic; +3 Ответить
11. 1c-intelligence 5213 09.07.18 12:00 Сейчас в теме
(10) лучше видео смотрите. Это статья по докладу, ее сложно сделать хорошей, потому что информация изначально рассчитана на устное изложение.
12. Кадош 09.07.18 12:39 Сейчас в теме
Расскажите, как оценивался результат?
Всегда интересно, по каким критериям оценивается эффективность программистов.
Стали писать больше строк кода, выполнять большее количество задач в единицу времени?
13. 1c-intelligence 5213 09.07.18 12:49 Сейчас в теме
(12) стали выполнять больше задач в единицу времени.
Задачи оценивались по трудоемкости в баллах - 1, 2, 3, 5, 8 и т.д.
Сумма баллов выполненных задач в день как раз и увеличилась - с 4.2 балла до 17.3 баллов.
14. ABudnikov 2 09.07.18 14:01 Сейчас в теме
(13) а как была сделана обратная петля связи управления, чтоб эти цифры не улетали вверх. Можно же согласованно начать оценивать средние задачи в большее количество баллов? Может есть какой-то базовый набор действий оцененный в баллах? Чтоб стартовать с чего-то.
tremp; Goleff74; acanta; ladon; +4 Ответить
18. 1c-intelligence 5213 10.07.18 05:20 Сейчас в теме
(14) да, был базовый набор, мы его называли якорь, их было несколько - это типовые задачи, которые периодически встречаются. До этой практики у нас была система мотивации, от которой осталось наследство - нормировка задач.
Ну и я следил за оценками, потому что эксперимент был для себя, а не для демонстрации. Хотелось получить реальное, а не дутое ускорение.
Есть такое понятие - инфляция задач, когда они становятся все дороже и дороже в баллах. У нас было наоборот - дефляция задач, когда мы делаем некий инструмент, из кастомизации на лету, и задачи, которые раньше делали, например, за 5 баллов, мы с использованием инструмента начинаем делать за 2 балла.
15. acsent 1074 09.07.18 16:15 Сейчас в теме
Так задачи стали сложнее или их больше стали выполнять?
16. Ta_Da 09.07.18 20:27 Сейчас в теме
(15) Стали дороже оценивать =)

(0) а что делать если есть отдел с разработчиками, тестировщиками, бизнес-аналитиками, доской со стикерами и при этом у большинства нет никакого желания ускоряться в 4 раза, избавляться от суррогатов и т.п.? бежать?
17. yogaga 09.07.18 21:18 Сейчас в теме
30. Ta_Da 10.07.18 10:06 Сейчас в теме
(17) Есть сильные сомнения в том, что где-то вне 1С все принципиально лучше. Есть опыт работы/общения с разработчиками вне 1С. Там и проект 6-летнего возраста про разработку (аутсорс) "своя альтернатива google documents для автоматизации учета в европейской больнице", без наличия демо, зато с финансированием.
И разработка внутренней (но которую успешно умудряются продавать) учетной системы на asp.net, с отделом разработки человек этак на 100. Кресла-мешки, приставки и печеньки. При этом в учетной системе, которая уже пережила три мажорные версии не позволяет вывести отчет по продажам, если в первую строку отчета попала компания с кириллическим названием (напоминаю, компания работает в СНГ и у них собственные названия кириллические).
Про волшебные внедрения как 1С так и не 1С систем я могу рассказывать часами.
Так что, перефразируя Карлина: "1С в порядке, это люди г*вно". И размазаны они по всей IT-сфере более-менее ровным слоем.
A_Max; hakerxp; Mantis; +3 Ответить
33. yogaga 10.07.18 10:24 Сейчас в теме
(30) Вне 1С банально выбор больше. На 1С по гибким методикам работают (ну, говорят, что работают) некоторые московские франчи, да штук 5 крупных отделов разработки больших компаний.
35. 1c-intelligence 5213 10.07.18 10:26 Сейчас в теме
(33) мне кажется, важно не сколько человек в какой отрасли работают по гибким методикам, а сколько из них какой-то понятный результат от гибких методик получают. Большинство просто "работают по гибким методикам", в смысле это и есть их результат - "мы работаем по гибким методикам", и никакого другого результата нет.
37. yogaga 10.07.18 10:32 Сейчас в теме
(35) Это да. Но тут есть другая причина - крупные клиенты пока на "гибкие методики" клюют неплохо...
38. 1c-intelligence 5213 10.07.18 10:35 Сейчас в теме
(37) да, потому неплохо и живут консультанты, "переводящие работу на гибкие методики". Результат? Ускорение? Не, не слышали.
20. 1c-intelligence 5213 10.07.18 05:22 Сейчас в теме
(16)
и при этом у большинства нет никакого желания ускоряться в 4 раза

ответ на этот вопрос давал во втором видео.
Так же, развернутый ответ есть в этой статье - https://infostart.ru/public/707406/, и еще в этой - https://infostart.ru/public/852933/
31. Ta_Da 10.07.18 10:09 Сейчас в теме
(20) Ну т.е. не просто "бежать", а "подготовиться и бежать" =)

P.S. свой аналог "кастомизации на лету" как раз внедряю у себя на работе, именно с такими мыслями ("зато потом будет опыт и на новой работе смогу это повторить").
36. pm74 126 10.07.18 10:31 Сейчас в теме
(31) :) каждый тру 1сник пишет свою кастомизацию
19. 1c-intelligence 5213 10.07.18 05:20 Сейчас в теме
(15) стали больше выполнять, в единицу времени. Т.е. увеличили скорость решения задач.
21. best_it_director 10.07.18 05:23 Сейчас в теме
Иван, а в Окнософте ты внедрял подобную практику? Есть результаты?
22. 1c-intelligence 5213 10.07.18 05:42 Сейчас в теме
(21) да, внедрял и внедряю. Сейчас, если выразить в единицах статьи, скорость 23 балла в день, т.е. на 30% выше, чем самая высокая в статье. Ну или в 5 раз выше, чем на старте статьи.
23. best_it_director 10.07.18 05:43 Сейчас в теме
(22) ты бешеный. Я твои практики для своих бойцов тоже использовал, у меня результат поскромнее - 2.5, за полгода.
24. 1c-intelligence 5213 10.07.18 05:47 Сейчас в теме
(23) ну, у большинства людей коэффициент равен единице :)
Так что не я, а ты бешеный - ты ж сам все делаешь. Если хочешь, давай встретимся, расскажешь об успехах, может подскажу что.
25. best_it_director 10.07.18 05:53 Сейчас в теме
(24) да как с тобой встретишься, ты ж из своей дыры не вылезаешь :)
Но я тоже хочу коэффициент 4. Я директору показал свою практику и твои статьи. Он наверняка не читал, но моя практика его сильно заинтересовала, хочет попробовать на других отделах.
Вопросов к тебе море, как лучше задать? Лично? По электронной почте?
26. 1c-intelligence 5213 10.07.18 05:55 Сейчас в теме
(25) да как хочешь. В комментах спроси, а то только плюсы ставишь и ничего не спрашиваешь.
27. best_it_director 10.07.18 05:57 Сейчас в теме
(26) о, ладно, щас тогда нафигачу тебе вопросов.
28. BelikJan 1 10.07.18 06:26 Сейчас в теме
(27) фигачь их сюда, а не в личку, чтобы все ознакомились )
29. best_it_director 10.07.18 08:53 Сейчас в теме
Мне про контроллинг интересно, из второго видео. Расскажешь поподробнее?
51. 1c-intelligence 5213 10.07.18 13:14 Сейчас в теме
(29) делаешь в своей системе простейший отчет, который показывает, сколько задач выполнено каждым программистом, в баллах и штуках.

Я использовал такие группы:
1. С начала недели;
2. С начала текущего дня;
3. С начала вчерашнего дня;
4. Текущая задача.

Соответственно, раз в 1-2 часа поглядываешь, особенно на п.2. Если там пусто, мельком смотришь на п.3. Если текущая задача большая, то пох - значит, весь день провозится. Если маленькая, значит затупил - спрашиваешь, чо как.
Если текущая задача большая, и в п.2 пусто, и в п.3 пусто - значит, затупил, надо помогать.
32. Kutuzov 418 10.07.18 10:15 Сейчас в теме
Как я понял, измерение эффективности проводилось с помощью "внутренних" параметров вашей команды. Интересно - для внешней системы как-то проводили измерение изменения эффективности? Т.е. для завода полезность вашего отдела тоже возросла в 4 раза, или это уже сложнее измерить?
34. 1c-intelligence 5213 10.07.18 10:24 Сейчас в теме
(32) полезность для завода - немного другая тема. Заводу казалось, что ему полезно наше ускорение.
Но настоящая цепочка длиннее:
1. Надо определить реальные проблемы завода, которые можно решить с помощью автоматизации или бизнес-программирования;
2. Надо выполнить работы по автоматизации или бизнес-программированию;
3. Надо оценить результат;
4. Надо вернуться к п.1.

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

У нас был опыт и первого, и второго варианта. Но это, повторю, не особо связанные вещи. Мне кажется, что ускорение п.2 важнее, т.к. п.1 намного легче, к нему просто доступа обычно нет.
42. Vovan1975 14 10.07.18 12:28 Сейчас в теме
(34)
Мне кажется, что ускорение п.2 важнее, т.к. п.1 намного легче, к нему просто доступа обычно нет.


Несогласен. П.1 на самом деле очень сложное действие, а точнее сказать, процесс. Как раз именно таки потому чтобы получить доступ, нужно его заслужить. Ну прям как квест но гораздо сложнее.
43. 1c-intelligence 5213 10.07.18 12:33 Сейчас в теме
46. Vovan1975 14 10.07.18 12:52 Сейчас в теме
(43) неа, не очень. Даже для ит директора. Для рядового программера - еще более сложно.
48. 1c-intelligence 5213 10.07.18 12:58 Сейчас в теме
52. Vovan1975 14 10.07.18 13:25 Сейчас в теме
(48) да. Итоги, правда, были сильно разные. Но всегда было весело.
53. 1c-intelligence 5213 10.07.18 13:30 Сейчас в теме
(52) сложно было? И кто вы - итдиректор или программист?
55. Vovan1975 14 10.07.18 13:35 Сейчас в теме
(53) программист.
Насчет сложно - мне не очень, но дело в том что до программиста 1с я занимался деятельностью, в основе которой лежал сбор и анализ информации, мне было проще.
57. 1c-intelligence 5213 10.07.18 13:38 Сейчас в теме
(55) вам не сложно, мне не сложно. Кому тогда сложно? Вы кого имели в виду, когда говорили
Даже для ит директора. Для рядового программера - еще более сложно.
58. Vovan1975 14 10.07.18 13:43 Сейчас в теме
(57) потому что рядовой программер традиционно слаб в общении с остальными людьми. Программирование здорово капает на мозги, в итоге остальные люди не очень рвутся общаться с программмером и наоборот - программер не очень общается с людьми-неайтишниками.
Программисты тяжки в этой деятельности с новомодным названием софт скиллс.
60. 1c-intelligence 5213 10.07.18 13:46 Сейчас в теме
(58) ну это же вы просто обобщили программистов, не зная их?
62. Vovan1975 14 10.07.18 13:47 Сейчас в теме
(60) я программером работаю уже наверно лет 15. Общаюсь как с ними так и с непрограммерами. Такие дела.
65. 1c-intelligence 5213 10.07.18 13:48 Сейчас в теме
(62) ну так и я так же, только не 15, а 13 лет.
Но у меня впечатления другие. Может у вас фильтр?
74. Vovan1975 14 10.07.18 15:11 Сейчас в теме
(65) возможно, конечно что у меня неверное впечатление сложилось, просто людей, которые под него не попадали, было весьма мало.
59. yogaga 10.07.18 13:43 Сейчас в теме
(57) Сложно для того, кто, как большинство 1С-ников, не обладает знаниями об устройстве бизнеса, и как бизнес можно оптимизировать.
63. 1c-intelligence 5213 10.07.18 13:47 Сейчас в теме
(59) читайте статьи про бизнес-программирование, и получите знания об устройстве бизнеса и о том, как его можно оптимизировать.
Предубеждения только уберите, и все получится.
66. yogaga 10.07.18 13:48 Сейчас в теме
(63) Именно, для этого надо, кроме программирования, расширять свой кругозор в сторону, условно, "менеджмента". Не всем программистам это надо.
61. yogaga 10.07.18 13:47 Сейчас в теме
(57)Кстати, у вас в отделе, например, было 5 программистов. Один смог, остальным, тогда, получается надо менять работу, если они тоже захотят?
64. 1c-intelligence 5213 10.07.18 13:47 Сейчас в теме
(61) один смог что? начальником стать?
67. yogaga 10.07.18 13:49 Сейчас в теме
(64) Стать бизнес-программистом на этом предприятии.
68. 1c-intelligence 5213 10.07.18 13:50 Сейчас в теме
(67) почему тогда остальным менять работу надо? Бизнес-программист - это не начальник, это тот же самый программист, только объект воздействия другой. Их может быть сколько угодно на одном предприятии.
69. yogaga 10.07.18 13:56 Сейчас в теме
(68) Это как, в отделе 5 программистов, из них 2 бизнес-программиста, а остальные просто программисты? Или бизнес-программисты перестают быть просто программистами, и получают зарплату больше просто программистов?
70. 1c-intelligence 5213 10.07.18 14:08 Сейчас в теме
(69) бизнес-программист - это дополнительная компетенция. Она не выключает в человеке программиста. Зарплату бизнес-программистам, конечно, надо платить более высокую, чем обычным программистам. Разумеется, когда они результат покажут.
71. yogaga 10.07.18 14:20 Сейчас в теме
(70) Ну да, с другой стороны скорее всего, если ты один из программистов, и захотел стать бизнес-программистом, то вероятность, что другие тоже хотя-бы только захотят, а не захотят и смогут, не очень высока.
72. 1c-intelligence 5213 10.07.18 14:25 Сейчас в теме
(71) если ты один из программистов, и захотел стать бизнес-программистом, то тебе должно быть насрать, что по этому поводу думают другие, что они собираются делать, что они говорят, что они скажут и т.д.
73. yogaga 10.07.18 14:35 Сейчас в теме
(72) По большому счету да, максимум что потеряешь - текущее место работы. А то, что приобретешь - навсегда твоим останется.
50. yogaga 10.07.18 13:03 Сейчас в теме
(46) Так что, и пытаться не стоит? Или просто нет знаний/способностей?
54. Vovan1975 14 10.07.18 13:33 Сейчас в теме
(50) С чего бы это? Вовсе нет. Нужно, будет весело. Но - потребуется некоторая работа над собой. Я просто полагаю это в рамках ответа на форуме сложно будет описать,наверняка глупо будет выглядеть и сбивчиво.
39. BackinSoda 10.07.18 11:11 Сейчас в теме
Методика подходит если все в команде заинтересованы в результате. Что делать если вы один из кроликов/осликов/пяточков ?
зы: вижу ответили уже в 20ом посте
40. YanovM 10.07.18 11:43 Сейчас в теме
Подскажите пожалуйста автора книги "Кодекс самурая")
41. 1c-intelligence 5213 10.07.18 11:51 Сейчас в теме
56. YanovM 10.07.18 13:35 Сейчас в теме
44. Vovan1975 14 10.07.18 12:45 Сейчас в теме
Мне стало интересно, я перечитал эту книгу еще раз и обратил внимание, что примерно на каждой 10-ой странице написано: для того, чтобы быстро принимать решения, надо заранее подумать, как ты будешь действовать в такой-то ситуации.

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

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


Нет, дорогой автор. Это не стратегия. Это называется прогноз развития ситуации.
45. 1c-intelligence 5213 10.07.18 12:51 Сейчас в теме
(44) а какая разница, как это называется?
47. Vovan1975 14 10.07.18 12:58 Сейчас в теме
(45) разница в том, что это разные вещи. Стратегия - это в общем цепочка целей для достижения конечной цели(я понимаю что в интернетах дофига всяких умных определений, но приведенное мной - пригодно для практического использования).

Прогноз развития ситуации - это некая сумма ожиданий, как, возможно, будут развиваться события. Быстрота принятия решений осуществляется за счет того что решения приняты заранее, при прогнозировании развития ситуации.
49. 1c-intelligence 5213 10.07.18 12:59 Сейчас в теме
(47)
я понимаю что в интернетах дофига всяких умных определений, но приведенное мной - пригодно для практического использования


расскажете, как практически использовали приведенное вами определение? Как я использовал свое - рассказал в статье, и результаты привел.
75. user1012597 11.07.18 01:00 Сейчас в теме
76. МимохожийОднако 120 11.07.18 07:57 Сейчас в теме
Статья получилась любопытная.
Однако фраза на финише статьи
я ушел из этой компании,...мои ребята в компании остались, они продолжили замерять свою эффективность, и дали мне свои показатели, как они работают сейчас. Сейчас их эффективность упала до 2,5 балла.

В японских компаниях практикуется метод оценки качества работы руководителя таким способом.
Одновременно отправляли в отпуск руководителей и специалистов одного уровня (например, начальников отделов) и сравнивали результат до и во время отпуска. Меры применяли к тем, у кого показатели падали и к тем, у кого показатели повышались. Мысль моего замечания в том, что "казахский Scrum" фактически держался на одном человеке и его внедрить не удалось. Т.е. в статье не методика, а личный опыт энтузиаста. И не ясно по какой причине автор ушел, и по какой причине программисты остались.
Как-то так....
Waanneek; zqzq; Mantis; +3 Ответить
77. Mantis 136 11.07.18 08:41 Сейчас в теме
Это хорошо , что вам стало скучно ))))
У нас отдел 15 человек и не когда скучать ))))
92. 1c-intelligence 5213 30.07.18 05:53 Сейчас в теме
(77) скука не зависит от количества выполняемой работы.
78. hakerxp 1599 11.07.18 09:33 Сейчас в теме
Работал я в компании, где применялся SCRUM и прочая лабуда. Как по мне - данные системы созданы для задр...ния сотрудников.
Ниже по пунктам:

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

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

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

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

5. Обезличенный механизм. В угоду скорости, часто страдает отношение к сотрудникам. А каждый человек - личность, и следовательно, нужен свой подход. Но scrum и прочие похожие системы, не учитывают проблем и возможностей сотрудников, что пагубно влияет на производительность труда.
Art1387; docerman; pm74; Mantis; bsturtle; +5 Ответить
79. yogaga 11.07.18 10:30 Сейчас в теме
(78) У вас был скрам только по названию, то что вы описываете не имеет с ним ничего общего.
A_Max; mifka186; Mantis; +3 Ответить
81. mifka186 6 11.07.18 19:07 Сейчас в теме
(78)
Отчет о проделанной работе каждый день

Вообще мимо Скрама. Утренние митинги - это не отчет о том что сделано, это способ выяснить возможные проблемы до того как они окажут влияние на работу. Решать вопросы в рабочее время скрам не запрещает, т.е. нет такого, что есть вопрос - дождись митинга. Для решения таких вопросов и нужен скрам мастер.
Люди и их взаимодействия важнее процессов и инструментов - один из принципов. Остальное можно посмотреть в манифесте.
80. Mantis 136 11.07.18 10:41 Сейчас в теме
Вообще сразу понятно об амбициях человека 4 кодера и он ИТ директор... у нас отдел ИТ из 30 человек есть два начальника админов и программистов и есть начальник департамента ну вот ну ни как не дотягиваем до ИТ директора)))
А такие вот креативные ИТ директора долго на одном месте не задерживаются.
93. 1c-intelligence 5213 30.07.18 05:54 Сейчас в теме
(80)
Вообще сразу понятно об амбициях человека 4 кодера и он ИТ директор

мне бы вашу прозорливость.
82. Vovan1975 14 12.07.18 11:38 Сейчас в теме
вообще, кстати, фапанье на японские "великие технологии" - оно очень забавно...
83. 1c-intelligence 5213 12.07.18 13:20 Сейчас в теме
(82) вообще, кстати, наблюдение за чужим фапаньем - намного забавнее самого фапанья. Удачи вам в этом нелегком деле.
86. Vovan1975 14 13.07.18 11:32 Сейчас в теме
(83) да не то слово. Правда я не понял почему оно нелегкое, но вам виднее.
84. acsent 1074 12.07.18 18:08 Сейчас в теме
тк все упало после того как ты оттуда ушел, то получается что единственная методика рабочая - это постоянно проверять не застопорился ли прог, и если что то сразу реагировать.
Ушел помошник-контролер и все вернулось на круги своя
85. acanta 44 12.07.18 18:21 Сейчас в теме
(84) Никто из пользователей (бухгалтеров и операторов) НЕ ПОХВАЛИТ так программиста за оптимально-качественный код запроса или построение алгоритмов, как это может руководитель отдела. Программисты оказались без человека, способного проконтролировать не только факт работы (это может и сторож видеть), не только скорость разработки (это могут пользователи), но и глубину их мыслей. Всегда можно "потом об этом подумать".
87. Vovan1975 14 13.07.18 11:34 Сейчас в теме
(85) это потому что пользователей очень инетересует решение проблем а не оптимальный, качественный и т.д. код. Будете решать проблемы, будет и благодарность.
88. acanta 44 13.07.18 12:20 Сейчас в теме
(87) Есть некий предел. В том числе и качества данных и архитектуры, при котором возможно (достаточно) быстрое решение проблем. Здесь действует принцип Макдональдсов - выдалась свободная минута - наведи порядок (в конфигураторе). Но если программист не считает что он вправе наводить порядок в метаданных и будет ждать благодарности от пользователей за это (что может быть чревато их недовольством) и тем более если так не считает заказчик (на что он имеет основания ) то работа превращается в болото, где каждое лишнее движение затягивает все глубже в трясину.
Пользователи требуют хлеба и зрелищ. Жест с поднятым большим пальцем кстати означает не похвалу победителю, а всего лишь помилование побежденному.
pavlov_dv; A_Max; +2 Ответить
94. 1c-intelligence 5213 30.07.18 05:55 Сейчас в теме
(84) поменялась ключевая идея, цель существования ИТ-отдела. Просто так получилось, что она была в моем лице.
89. acanta 44 13.07.18 14:48 Сейчас в теме
"Работа на будущего работодателя" как инструмент для мотивации тоже очень узкое место.
Это не является зоной комфорта большинства пользователей. В буквальном смысле ни один работодатель не будет добровольно оплачивать обучение для конкурентов. Снижение скорости работы думаю, в большей степени связано именно с вашим уходом и тем, что оставшиеся "оказались виноваты".
Оставьте свое сообщение