Comments 29
Современные управляющие, менеджеры незаслуженно избегают применять такой испытанный и проверенный метод, как "демократический централизм".
Ракету построили, бомбу сделали, человека в космос, "кузькину мать", да Наполеона отбуцкали, Гитлера зарыли всё с помощью демократического централизма.
Вспомните "совет в Филях", когда младший штабной офицер первым излагает свою точку зрения и не боится никого. Это традиция русских штабов. Ну и после совета жесточайшая дисциплина со всеми прилагающимися.
Гораздо важнее достигнуть свободы обсуждения, вовлеченность и ответственность всех и плюшки, тем кто заслужил, а не выпросил.
Обсуждение считаю нужным начать с обоснованности выбора agile.
Согласен. Именно поэтому в статью я вставлял фразы типа "...а потом суметь правильно привить им эту культуру. "
Суть трансформации в том, что мы ее проводим не только и не столько как изменение процессов, а именно изменение культуры и ценностей в компании. Ценно партнерство на всех этапах (люди не винтики и не ресурсы, мнение каждого важно). Я стараюсь двигать Agile именно как ценности и мышление, а не карго-культ (бездумно делай так и будет успех). Уплощение структуры у нас тоже происходит (это помогает убирать "испорченный телефон" и вовлекать каждого в процесс "креатива", т.к. все участвуют в генерации идей, а не только начальники). Крайне важно слышать тех, кто непосредственно пишет код или работает с твоим продуктом в полях. Scrum с его Retro и Demo отлично помогают в этом. Сейчас мы растем (существенно), наше руководство поверило в in-house разработку и мне нужно больше людей, которым есть, что сказать ))
Так ведь в статье досствостаточно четко описываются предусловия. Диаграмма Ганта, в которой от базового плана двигались зависимые задачи. Изменен срок одной задачи, подвинулись еще 20 и более, выполняемые теми же ресурсами. Все просто waterfall стал сдишком планово незапланированно предсказуем. Иными словами, базовые сроки неисполнимы из-за зависимости ресурсов, человеков. А кроссфункциональные скрам команды пофиксили данный баг.
Современные управляющие, менеджеры незаслуженно избегают применять такой испытанный и проверенный метод, как «демократический централизм».Интересно, где это его испытали и проверили — этот метод?
Если вы думаете что в СССР, в КПСС (где он был записан в Уставе как основа функционирования партийной организции), то вы вы заблуждаетесь.
Потому что в СССР реальность и ее отражение в документах — это были две большие разницы.
В частности, «демократический централизм» в КПСС функционировал следующим образом: при рассмотрении вопроса на каком либо уровне на общем собрании или собрании партийного комитета представитель вышестоящего партийного комитета, или начальник организации сообщал, что «есть мнение», и все послушно за это мнение голосовали (послушание было выработано практикой 1921-1938 годов). И только если у вышестоящей организации и у партийного секретаря почему-либо мнения не было, начинался тот самый теоретический демократический централизм (для тех, кто от советских реалий в силу возраста далек, поясню: секретарь-официальное название должности партийного начальника, почему — так исторически сложилось).
Я успел пожить в СССР ( совет в Филях лично не застал ) и видел в действии при решении технических вопросов этот централизм. Очень он эффективно работал и я лично загубил парочку безумных проектов выступая на НТС первым, младшим.
Как Вы себе представляете "приходит секретарь партийный на заседание технического совета к Королеву и говорит, Вы, мол, тут не круглый иллюминатор делайте, а квадратный". Вы, @mvv-rus сами хоть верите в такой секретарский заход?
Решения совета главных конструкторов были обязательны для девятки министерств. Это в корне отличается от системы эффективного нынешнего менеджера.
Которая с легкостью могла одобрить любую глупость, пришедшую сверху, типа «рязанского чуда» (показательный случай, кстати).
В СССР я тоже успел пожить и поработать (и даже из комсомольского возраста выйти), но — в обычных условиях, со всей полнотой проявления руководящей и направляющей роли партии. Плюс, родственники, в таких же условиях жившие и работавшие, кое что про жизнь рассказывали.
А вот про такие особенные, исключенные по факту из системы партийного руководства явления, как это ваше КБ Королева (или, там, НИИЧАВО) я сказать ничего не могу) — не встречался с ними по жизни.
Молодцы конечно, но выглядит как микроскопом по гвоздями. Ключевая проблема - заказчик постоянно меняет требования. Я понимаю,когда речь в рынке и необхомисти перехода с ДВА на электромотор. Но когда так поступает внутренний заказчик, это прямой вопрос к его компетенции в коммуникации. Зачем терпеть кучу не компетентные людей в компании и исключительно в угоду им устраивать дорогую смену процессов? Смена 20 десятков людей на более компетентные и умеющих думать наперед даст ещё больший эффект,за гораздо более скромные вложения.
И ещё вопрос если нужен был Enterprise Agile + Scrum, почему не SAFE или Nexus SCRUM?
Интересный вопрос :) сейчас, скорее, мы проходим стадию "опрозрачнивания", т.е. за счет большого вовлечения стейкхолдеров в процессы: совместной с ИТ генерации идей, формулирования UserStory, регулярных демонстраций результатов работы спринта и т.д. мы показываем друг другу, что какие-то элементарные изменения могут влиять на результат. Это дает свои плоды, т.е. стейкхолдеры начали понимать, что каждое изменение должно приносить ценность, а не просто "хочу". Особенно дело сдвинулось, когда начали появляться "Владельцы продуктов". У нас они все от бизнеса, а не из ИТ. Вот эти ребята быстро смекнули, что ценные заявки должны быть в верхних строчках бэклогов, а то команда будет обходиться компании дороже чем эффект от ее работы :)
Да и вообще, Вы серьезно думаете, что так легко найти идеальных стейкхолдеров, которые к тому и не рядовые сотрудники (у нас и директора генерят идеи постоянно в погоне за изменениями рынка), да еще и они не должны хотеть всего и сразу? + предлагаете оценивать компетенции людей только по тому, сколько они генерят изменений? Мне за 20 лет работы в ИТ такие пока не попадались :) Думаю, что единственный способ победить "поток сознания" и отфильтровать ценные гипотезы - это оценивать эффект от каждой из них , приоритезировать и максимально быстро проверять идею. ВАЖНО потом проверять попадаем ли в ожидания, т.е. сколько в реале пришло денег от реализации.
По поводу SAFE или Nexus.
Это наше будущее. Вспомните свое первое знакомство со Scrum (например). Сама идея того, что можно делать продукты иначе была удивительна и чужда (ну, у меня так точно было :) ). Не думаю, что Вы сразу пошли сертифицироваться на PST (например). В школе мы тратим 11 лет для получения среднего образования, в институте 5 лет для высшего образования и т.д. Это я все к тому, что у всех разный уровень зрелости и трансформация начинается с разных уровней. У меня , на момент начала пилота, да и зарождения идеи трансформации, не было людей, которые понимали даже какие-то базовые вещи и могли отличить "Владельца продукта" от "Руководителя проекта", Scrum от Kanban и т.д. Масштабируемый Scrum (в тот момент) казался чем-то таким непостижимым и мы решили, что в пилоте это не нужно (не те масштабы). А вот сейчас..
У Вас есть практический опыт масштабирования Agile? Хорошо знакомы с SAFE? "тогда мы идем к Вам" за советами :)
В начале Вы постулируете, что в крупных компаниях подход про «хату с краю» сам собой возникает. И далее говорите, что, когда пришли на это место, решили все изменить.
И вот тут связка лично мне непонятная: а откуда взялась эта уверенность, что получится, и откуда коллеги вдруг решили не в «хату с краю» поиграть? Размер компании, не говоря, что это ВТБ, как бы намекает на обратное.
Эх.. написал развернутый ответ , но не нажал "отправить" перед F5.. вечереет..
Попробую еще раз)
Вы верно подметили про "хату с краю", однако, я несколько о другом пишу. Думаю, что не будете спорить, большие компании дадут фору любому стартапу по части бюрократии. Иногда это все доходит до того, что внедрение элементарного улучшения/изменения процесса выглядит для сотрудника как прохождение миллиона итераций обсуждений, согласований, комитетов, собора подписей и т.д. Возникают "окольные тропы" в обход корпоративных процессов. Конечно, такое охладит пыл любого и потихоньку все приходит к той самой "хате".
Имея лидирующие места на рынке лизинга, разумеется, компания "ВТБ Лизинг" имеет возможность инвестировать в своих сотрудников большие ресурсы, при этом, странно помещать людей в условия, в которых они не смогут реализовать свой потенциал. Учитывая планы по предстоящим изменениям, мне хотелось создать такую среду, в которой было бы минимум преград на пути новых Agile-команд. Никаких "хат", только генерация идей и их реализация. Да, знаю, звучит пафосно, но идея была именно такая и таковой остается. Я уверен, что если люди занимаются любимым делом, человек не чувствует себя каким-то бесполезным винтиком в гигантской системе, у них есть реальная обратная связь от клиентов и возможность реализовывать свои идеи, то "хаты с краю" пропадают сами собой. Я искал людей, которые ГОРЯТ и на их примере старался показать остальным, что все возможно.
В том, что получится уверенности не может быть вообще. Была идея основанная на:
Личный опыт. Я уже проходил подобную историю в другой крупной финансовой компании (наверное, не этично писать в какой). Ситуация была аналогичной. Когда попадаешь в схожую среду, начинаешь видеть необходимость определенных изменений более четко.
Люди. Я начал с поиска сторонников и пытался вдохновить опытных сотрудников компании на изменения. Мы анализировали текущие процессы и продукты компании, попытались сформулировать видение развития продуктов вместе со стейкхолдерами, составляли звездные карты, собирали обратную связь от стейкхолдеров и ИТ-шников по части удобства текущих процессов и т.д. В итоге, коллективно сошлись во мнении, что все должно получиться.
Пилот. да, это более поздний этап, но любая гипотеза должна быть проверена. Пилот окончательно показал, что идея верная и при правильном масштабировании, мы получим отличный результат. После его успешного прохождения, на высшем уровне компании дали добро на масштабирование.
Еще немного про "хату с краю". Тут важно понять простую вещь. Вас окружают люди, а не какие-то злодеи, которые принципиально загоняют вас и себя в сложные условия. Я всегда придерживаюсь мнения, что если людям показать ситуацию, сделать предложение, которое подкрепляется реальным практическим результатом, то они будут меняться и менять окружение. Главное показать им их выгоду :) Когда у вас есть возможность напрямую влиять на тот продукт, который вы делаете, вы видите реальный результат своей работы в бою, благодарность пользователей и даже клиентов компании, вы точно не будете оставаться в стороне. Это не могло не сработать ;)
С аджаилом есть одна проблема. Называется тяп-ляп и в продакшен. Так как никто не анализирует множество требований в совокупности и на противоречия до начала разработки - есть высокий риск на очередном требовании "добавьте кнопку" все переписать с нуля и не раз.
На легаси проектах, которые первично были реализованы по ватерфоллу - этой проблем никто не заметит, потому что на текущем проекте в основном текучка и устоявшиеся бизнес-процессы. А вот для стартапов, которые не знают, какой учет им потребуется партийный или серийный - аджаил вселенское зло. Даже если программист перепишет все за неделю, то наклейки придется печатать и переклеивать на коробках месяц-другой сутками на пролет и всей толпой.
Давайте разберем Ваши тезисы. У увидел:
Agile это тяп-ляп
Agile больше подходит для легси-проектов , в которых доработки - мелочь, а на стартапах Agile-зло, т.к. может быть много изменений.
Постараюсь ответить (соответственно):
Есть такой термин DoD (Definition of Done) , т.е. уровень вашего тяп-ляпа вы способны определить самостоятельно. Например, в последние 1,5 года мы очень активно развиваем автотесты. Не скажу, что достигли потрясающих успехов, но наш функционал покрыт автотестами > 70%. Учитывая, что 100% и не нужно, то ИМХО мы в состоянии проверять состояние регрессионного функционала. Так вот, прежде чем что-то выпустить, системы проходят полный цикл тестирования (скоро еще DevOps историей займемся и будет ваще здорово :) ). Таким образом, как написано в статье, с появлением Agile истории в командах, они даже снизили уровень багов и это тенденция сохраняется вот уже более года (с момента старта пилота).
Тут мне сложно комментировать, т.к. например, Scrum, лучше работает именно на стартапах, где надо быстро проверить идею и оперативно подстраиваться под изменения среды. Приведу Ваш пример чуть иначе чем Вы: "Для стартапов, которые не знают чего им надо, Waterfall настоящее зло, т.к. о том, что программисту надо все переписать, компания узнает не через неделю, а через месяцев 6 или даже больше, т.к. первым этапом пойдет аналитика, в результате которой будет БТ , слова в котором будут звучать правильно, а вот как их реализует программист.. уж все мы видели этот мем с качелями и деревом". Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно. Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Если выделять тезисы, то он один - применять аджаил к месту.
Дело не в DoD и тем более не в тестах. Дело в отсутствии общей картины и достаточного анализа. Другими словами в отсутствии более-менее продуманного ТЗ на первое время. Что приводит к факапам, но не с точки зрения аджаила (у него как раз все хорошо), а с точки зрения бизнеса, людей, времени и денег. Область видимости аджаила ограничена, чтобы видеть всю картину и все проблемы, которые он создает.
Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно.
Например это. Изначально аджаил оперировал только таким артефактом как программное обеспечение. Если же заглянуть в ГОСТы 19/34, то там можно обнаружить другие виды обеспечения (организационное, методологическое и так далее). Переписывание программного обеспечения - это лишь малая часть.
Я в своем комментарии привел пример из своего опыта. Это обычный бизнес по продаже некоторого физического товара, который захотел новомодные ИТ-штучки и франшизу. Вместо аджаила лучше было бы сесть, подумать, описать бизнес-процессы и обкатать их хотя бы в голове, а лучше на складе, убрать противоречия, увидеть более полную картину. Другими словами составить ТЗ. А вот уже потом включать аджаил, заполнять бэклог, запускать спринты и болтать на митингах часами рабочего времени каждый день. В итоге это займет допустим неделю. А еще пойти на склад, расставить товар по полкам, наклеить свои штрихкоды и ценники, и это займет месяц-два.
Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Нет, клиенту на самом деле важно увеличение прибыли, уменьшение расходов, поток клиентов, благоприятная атмосфера в рабочем коллективе. И где-то потом уже продукт. Только аджаил этого не замечает.
Сложно конечно в комментариях дискутировать на такие глобальные темы. Попробую сформулировать свои мысли на этот счет:
Agile это культура. Культура не применяется. Судя по всему, вы говорите не про сам Agile (c его ценностями и принципами), а про Scrum, как фреймворк, который предписывает выполнять определенные мероприятия. Кто мешает не использовать Scrum, если он, по определенным причинам, не подходит?
"Agile" это адаптивная история. Зародилось это все в ИТ, но уже давно покинуло рамки лишь ИТ. Agile позволяет бизнесу максимально быстро получить MVP для проверки принятых решений и , вообще, тот продукт, который ему нужен, т.е. позволяет оперативно давать обратную связь разработчикам и корректировать свои потребности. Какая ее модель позволяет получать такую гибкость и за счет чего?
Про Ваш пример из личного опыта могу сказать, что тут вина не Agile. На начальной стадии не был сделан User Story Mapping, т.е. сразу ломанулись что-то делать не видя процесса (не отрисовав его). "Agile Scrum" не говорит , что надо так делать. Обычно это результат неграмотного трактования принципов Agile. Например, похожая история была в ВТБЛ до меня. От такого "внедрения" мне пришлось имя "Agile" еще отмывать несколько месяцев (на это слово было наложено проклятье :) ). Вы все верно говорите, но в том, что так не сделали, как Вы пишите, вина не подхода, а людей, которые сразу начали что-то делать без формирования видения продукта.
Последний тезис я не понял. Если мы говорим про внешнего клиента, то Ваш коллектив и атмосфера в нем его не сильно беспокоят. Ему надо то, чем он будет пользоваться. И чем лучший продукт предложит компания (соотношение цена /качество или уникальность, или еще по какому параметру), тем у нее , потенциально, будет больше выручка. По поводу уменьшения расходов (тут я понял, что Вы про внутреннего клиента, а не про того, о котором я) могу сказать, что по ТЗ может быть все здорово, только после реализации заказчик понимает, что написано "сделай экранную форму такую", а на деле какого-то функционала в ней нет и удивляется "ой, я думал, что он будет по умолчанию". все прописать в ТЗ просто нереально. Такой подход был развенчан самим Уинстон Ройс (считающимся создателем каскадной модели waterfall). В своей статье “Managing the Development of Large Software Systems” он утверждал, что только простые проекты можно делать таким образом и от итераций не уйти.
Вы говорите о каких-то маленьких масштабах (подумать неделю, например). Я же говорю о том, что утопия "сесть и обо всем подумать". Конечно, думать можно, но даже умы Гугла, Яндекса и т.д. постоянно развивают свои сервисы, а если бы можно было бы все сразу придумать, то они выпускали бы одну версию навсегда, где было бы все, но.. так не получается. В начале MVP, смотрим "оно/не оно", потом определяем дальнейший шаг и т.д. Часто бывает так, что мы создаем совсем не тот продукт, что хотели изначально и это нормально. Так происходит потому, что как раз НЕЛЬЗЯ все придумать изначально.
PS
Все, что я написал выше не относится к простым процессам типа игры в "крестики-нолики", где нового не придумаешь (хотя, и там выдумывают не 9 клеток, а больше). Там, действительно, можно все заранее продумать, а вот в чем-то более сложном.. я еще таких всесторонних "продумщиков" не встречал. Если Вы такой, то снимаю шляпу! мне бы такие сотрудники очень пригодились, правда.
Аджаил, который я упоминаю - это совокупность всего, в том числе конкретных методик типа scrum/kanban/lean.
Вы по-прежнему остаетесь в рамках программного обеспечения. Абстрагируйтесь от него, ведь оно стало массовым только в последние лет 30-40, когда появились первые персональные компьютеры. Если подняться выше - увидите всю картину.
Элементы аджаила зародились не в ИТ, а как минимум в Японии после второй мировой войны в сфере производства. Просто бравые, по большей части, американские парни подумали "а чем мы хуже" и решили адаптировать это дело под производство программного обеспечения. Но я все же надеюсь они не забывали, что компьютер - это всего лишь инструмент, а программное обеспечение - всего лишь маленькая часть больших бизнес-процессов где бы то ни было (на складах, на заводах, в банках).
На начальной стадии не был сделан User Story Mapping, т.е. сразу ломанулись что-то делать не видя процесса
Погодите, откуда тут взялось описание процесса? По аджаилу к нам приходит заказчик и говорит "сделай то не знаю что", выдавая неопределенные требования на словах в час по чайной ложке. Если уж мы взялись за аналитику и описание бизнес-процессов - разве вся эта писанина не первый этап по ватерфоллу? И как же так вышло?
Короче, суть в чем.
Чистый аджаил хорошо покрывает конкретно разработку программного обеспечения по требованиям, по которым уже была проведена глубокая аналитика. Т.е. управление требованиями остается на совести заказчика/владельца продукта. Но чаще всего заказчик не айтишник и не имеет опыта построения ИТ систем, даже если ему знакома предметная область.
Если каждый набросок в бэклог должен проходить еще и этап аналитики внутри команды разработки, то для начала придется добавить в спринт задачу "описать бизнес-процесс" (= написать ТЗ). А это по факту уже натягивание ватерфолла на спринты.
Мало того, если поторопиться, то придется все кардинально переписывать и не раз. Аджаил говорит "лучше об этом узнать раньше, чем поздно". В принципе логично и правильно. А что нам говорит бизнес? "Почему, чтобы добавить кнопку вам надо месяц и все переписать" или "Какого ... я должен оплачивать переработки складских работников, которые вынуждены по ночам переставлять товар и переклеивать штрихкоды. Вы что не можете сразу по-нормальному сделать???!!!".
Нет, не могут. Потому что по аджаилу в бэклог набрасывают заженные спички, а команда разработки занимается тушением пожаров.
Если вернутся к вашим банковским системам, то для дальнейшего развития и устранения багов аджаил подходит довольно хорошо, о чем вы и написали в своей статье. Почему? Потому что вы пришли на устоявшуюся систему, которая 146% была реализована по ватерфоллу 20 лет назад. А что будет если вам дадут задачу написать АБС с нуля по аджаилу? Не узнаешь пока не попробуешь. Но никто этого делать не будет.
При этом использование аджаила в гораздо более простых системах (как мой пример со складом) уже обнажает проблемы. Нельзя начинать писать код без предварительного анализа бизнес-процессов (=написание ТЗ =ватерфолл). Потому что по итогу приходится не только переписывать программное обеспечение, но и заново расставлять 20 тыс позиций на складе по новым правилам. В аджаиле об этом ни слова.
При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. Но хорошо бы выбрать какое-то иное средство прототипирования. Непосредственно кодинг конечно быстрее, чем строить дом, но порой не достаточно быстро. Например, как в фильме про братьев Макдональдс. Они на асфальте рисовали мелом расстановку кухонных блоков и тестировали процесс быстрого приготовления пищи. Т.е. спринт у них был ну 1 час. Тут кстати в целом интересный момент. Макдональдс существует со своими бизнес-процессами с 1940, а персональные компьютеры появились только спустя 40 лет. Что как раз и доказывает, что компьютеры это инструмент, а программное обеспечение - лишь малая часть бизнес-процесса.
Аналогичная проблема при использовании TDD. Нельзя сначала писать тесты, а потом реализацию. Потому что в процессе описания бизнес-процессов, уточнения требований, раз за разом придется с нуля переписывать все эти тесты. Тесты нужно писать на уже более-менее стабильный функционал.
Спасибо за развернутый комментарий. Теперь понял.
Все вот в этой Вашей фразе: "При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. "
КОНЕЧНО! Почему-то историю с Agile часто воспринимают лишь как игрушка ИТ-шников. У меня ушло не мало сил на объяснение внутри компании, что Agile это про всю компанию! Разумеется, Agile как культура и ценности не может существовать в отдельно взятом подразделении.
Д давно понятно куда все это движется. Но пока мне нравится
Затем набирали людей в команду. Критериев отбора было всего два:
1. Должны гореть глаза.
...
Такие критерии настораживают. Мы ведь тут живем не в Самой Прекрасной Советской Стране, а вовсе в Царстве Бездушного Чистогана, то есть работаем не ради процветания Родно Страны и любимого предприятия, а чисто ради получаемых нами лично денег.
А потому требование видимого энтузиазма от работников выглядит подозрительным — как попытка владельцев бизнеса поиметь с них больше за те же деньги.
В связи с этим у меня к вам вопрос: не обнаружили ли вы в результате внедрения этих прогрессивных методик увеличение интенсивности труда программистов? Я понимаю, что нужные для ответа метрики, скорее всего, не собирались (ибо методикой гибкой разработки они не предусмотрены, сами по себе менеджерам они не нужны, а профсоюза у вас там нет), но, тем не менее, вопрос такой задам.
И совсем на всякий случай — еще вопрос: если увеличение интенсивности труда разработчиков имело место, то компенсировалось ли оно как-либо?
Спасибо за интересный вопрос.
Начну с последнего вопроса. Мы ведь про ВТБ Лизинг говорим, а не ООО "Ромашка-22" (надеюсь, такого ООО в природе нет :) ). Разумеется мы достаточно серьезно вкладываемся в сотрудников. Один профессиональный Agile-тренинг и тренерское сопровождение команд чего стоили )) Если еще серьезнее, то Вы правы, Agile это про людей, про взаимодействие, про ценности. Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро "сдаются" (мимикрировать долго не получается). По факту, я не вижу смысла переделывать людей, я лишь показываю, что можно работать иначе, а дальше уже выбор человека. "В Agile" мы не загоняем. Очень многие компании несут Agile огнем и мечем, у нас же, те кто прям не могут работать кроме как "каскадно" и обладают иными ценностями, не могут поддерживать должный уровень коммуникаций и т.д. или уходят , или мы находим им место в других направлениях, в которых они могут развиваться дальше.
По поводу метрик производительности труда сложнее. Лично я уверен, что любую метрику можно "читить". Для того, чтобы метрика работала, ее надо реализовывать в компании, культура сотрудников которой позволяет честно показывать что происходит. Например: выработка времени. Списываем честно время и если списали больше, то что? поработали лучше и сделали больше? - нет. Идем дальше, "количество выполненных задач" , оно? тоже нет, т.к. как только люди узнают, что это критерий, то сразу задача начинает декомпозироваться на миллион подзадач и т.д. В статье написано какие метрики мы использовали и ключевыми были лишь 3:
-CSI (отношения с партнерами/клиентами, обратная связь стейкхолдеров)
-LeadTime (за ней смотрели на всех уровнях, т.к. ее можно очень успешно читить)
-Проверяемый экономический эффект (реализуемый эффект. Мы таки деньги зарабатываем)
А Вы о каких метриках говорите? Строчки кода? Переработки? или что? Поделитесь, пожалуйста, я с удовольствием почитаю. Всегда рад узнать что-то новое!
ps
... чуть не забыл. Я предлагаю использовать слово "прививали" (например). Agile это не методика, это культура. Внедрение культуры не работает, культуру прививают или , например, "выращивают" (да, странно звучит :) ). Если относиться как к ВНЕДРЕНИЮ, то это просто про процессы и карго-культ. Такого нам не надо. Agile только через ценности (понимаю, со стороны звучит как дикость и "радуга с единорогами")
Спасибо за интересный вопрос.Я вас понимаю.Я бы на вашем месте тоже обругал бы такого оппонента последними словами.
Начну с последнего вопроса.Зря. Он имеет смысл только в контексте положительного ответа на предпоследний вопрос — об интенсивности труда программистов.
А сам по себе ответ на последний вопрос заставляет предположить, что это увеличение интенсивности труда действительно имела место и ничем материальным скомпенсирована не было. Я правильно вас понял?
Потому что слова
Разумеется мы достаточно серьезно вкладываемся в сотрудников...по факту содержат неявное дополнение: "..., чтобы переделать их под свои нужды". Все эти Agile-тренинги — они ни материально сотрудникам ничего не приносят, ни ценность их на рынке труда не повышают. Эти вложения нужны исключительно вашей компании. Вы имеете полное право их делать, конечно, но неправильно представлять это как форму компенсации сотрудникам.
Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро «сдаются» (мимикрировать долго не получается).
Немного в сторону. Вы просто плохо знаете людей. Я вот пожил и поработал в СССР — и знаю, что мимикрировать можно очень долго: приходилось, потому что там доступной альтернативы марсистко-ленинской идеологии с ее «трудовым энтузазизмом» не было. И, как мы знаем по опыту распада СССР, у многих мимикрировать получилось достаточно хорошо, чтобы занять весьма высокое положение в иерархии.
По поводу метрик производительности труда сложнее.
Вы то ли меня действительно не поняли, то ли пытаетесь подменить понятия. Так вот, возвращаю контекст: я вел речь не о производительности труда — его результатах для фирмы, а о его интенсивности — то есть расходовании рабочей силы работниками, той самой, за продажу которой наемные работники поулчают зарплату. Отсутствие соответствующих метрик в вашем распоряжении — это для меня как раз ожидаемо (я сразу писал). Но, минимум, одна, хоть и приближенная, метрика есть: реальное суммарное время переработки за период. Вы можете сообщить как изменилось время переработки? И, если да — как в нем учтено было именно реальное время — в которое входят добровольные задержки, внеурочная работа из дома, состояние «на телефоне» и т.п.
С уважением.
PS
Agile это не методика, это культура.
Когда я слышу слово «культура» мне чисто автоматически хочется продолжить фразу крылатыми словами, вложенными в уста отрицательного героя своей драмы «Шлагеттер» немецким драматургом Гансом Йостом ("… я взвожу свой браунинг"). Потому что 90+% случаев это слово сопровождает ту или иную разводку (на бабки, на поработать нахаляву и т.д.). И обсуждаемый вопрос, по моей оценке — он ничуть из этих 90+% не выбивается.
понимаю, со стороны звучит как дикость и «радуга с единорогами»
Или как «классовое сотрудничество» — формой проявления которого по факту и является.
Вы уверены, что у Вас нет личной обиды на что-то, что когда-то назвали для Вас "Эджайлом"? Через слово сквозит "разводка", "обман" и тд.
Судя по всему, предложенная метрика (измерять как долго сотрудники остаются на работе после официального рабочего времени, как я ее понял) и продиктована тем, что когда-то Вас так, выражаясь обычным языком, кинули.
У нас наоборот. Цель - создать среду для плодотворной работы. Какая еще среда, если люди будут обозлены, подавлены и работают 24/7 ? В этом и дело, что я верю в эффективную работу без переработок!
По метрике отвечаю:
В этом году глобальная цель - "снижать накопленный сотрудниками отпуск". Цифры я называть не могу, но по сравнению с 2019 годом, мы снизили накопленные отпуска процентов на 45 точно и этот тренд продолжается (люди должны отдыхать).
Саму эту метрику я не веду (цели ночевать на работе нет), т.к.
Все планы составляются без учета переработок и работы в выходные.
Если приходится выходить в выходной, то сотрудник получает ДВОЙНУЮ оплату (все по ТК) и , разумеется, мы кросс-функциональны теперь и если кто-то не может выйти, то найдется тот, кто сможет. Сами выходы теперь крайне редки.
У нас в договоре с сотрудниками предусмотрено "чуть больше отпускных дней" нежели стандартные 28 ;)
Ну и я просто вижу людей (кто и когда работает). В данном случае, живое общение и человеческое отношение к сотрудникам имхо заменяет любую метрику.
Думаю, что это вполне отвечает на Ваш вопрос про то как мы "истязаем сотрудников Эджайлом" :)
Костя, привет! )
Делаем аналогичное дело в «РБ ЛИЗИНГ». Нам, явно, проще. Видимо, возраст стейкхолдеров сказывается )
На связи.
Повесть о двух департаментах, или как в ВТБ Лизинге Agile прививали