Добрый день! А не подскажете, где-то написано (например, ITSM) что 2ая линия должна воспроизводить дефекты на препроде (например) ? иногда очень сложно бывает выстраивать процессы, когда они "межподразделенческие" в компании и всегда появляется что-то типа "нет, это разработка должна воспроизводить" или наоборот.
Мне нравится как у вас написано: "2-я занимается сбором диагностической информации (логов, метрик мониторинга, конфигов), отвечает на вопросы 3-й линии о случившемся"
Но и у вас эта граница стерта, т.к. далее идет: "отвечает на вопросы 3-й линии о случившемся (когда случилось, что было до инцидента, как его повторить и т. д). " Т.е. повторение оно как бы на 3ей линии у вас.
Я ищу пруфы (уважаемые :) ) чтобы понять что говорят "бест практикс"
Я думаю, что под термин "цифровая трансформация" пихают все, что не могут объяснить своими словами :) когда-то давно (годах в 2000-х), наверное, действительно приходилось трансформировать текущие процессы и переводить их в цифру (я тогда работал программистом и отлично помню как приходилось продавать сотрудникам компаний пользу от цифровизации их процессов). Это я к тому, что термин бы прозвучал, если бы это была какая-то формальная статья для ТОП-менеджеров, а я тут просто как есть попытался изложить.
Надеюсь, я правильно понял основной вопрос. Думаю, что идеи смысла не лишены. Представим себе цепочку: У вас есть продукт, который является стратегическим преимуществом компании, вы должны его развивать максимально быстро (конкурентов куча), вы должны иметь возможность тестировать гипотезы так быстро, как это делают стартапы и т.д. Это значит, что фиксироваться по договорам fix- вы не можете, т.к. они подразумевают наличие согласованного ТЗ и разработанное 1 в 1 должно соответствовать ТЗ. Что-то можно оперативно менять в таких условиях? нееет... (НЕ ПОДХОДИТ!) А если взять подрядчика по t&m? да, в этом случае все похоже на собственную разработку, вы можете давать сотрудникам те задачи, которые считаете нужными, минимизируете свою ответственность за удержание и мотивацию персонала и т.д., но(!) как вы будете выстраивать с ними отношения: прививать корпоративные ценности, мотивировать , обучать и т.д. если это сотрудник другой компании (у него свои работодатели и он находится в той структуре, культуре, финансовой зависимости, организационных правилах) ?
Тут вопрос ,скорее, про культуру взаимодействия. Как известно, культура не внедряется, не навязывается, а прививается. Привить "нужную" культуру сотрудникам, которые получают деньги от кого-то еще и которые работают в рамках культуры своего непосредственного работодателя, очень сложно. Лично я вижу успех в том, что люди с едиными целями и культурой способны на многое. Есть такое выражение "культура следует за структурой", вот, пытаемся ломать все разграничивающие стены (разные KPI, орг.структура и т.д.) и формировать необходимую нам среду для успеха.
Да, я тоже знаю успешные кейсы с подрядом и у нас они тоже есть, однако, там, где вы разрабатываете продукты, которые будут или являются вашим стратегическим или конкурентным преимуществом, таки лучше сделать выбор в пользу in-house.
Вы уверены, что у Вас нет личной обиды на что-то, что когда-то назвали для Вас "Эджайлом"? Через слово сквозит "разводка", "обман" и тд.
Судя по всему, предложенная метрика (измерять как долго сотрудники остаются на работе после официального рабочего времени, как я ее понял) и продиктована тем, что когда-то Вас так, выражаясь обычным языком, кинули.
У нас наоборот. Цель - создать среду для плодотворной работы. Какая еще среда, если люди будут обозлены, подавлены и работают 24/7 ? В этом и дело, что я верю в эффективную работу без переработок!
По метрике отвечаю:
В этом году глобальная цель - "снижать накопленный сотрудниками отпуск". Цифры я называть не могу, но по сравнению с 2019 годом, мы снизили накопленные отпуска процентов на 45 точно и этот тренд продолжается (люди должны отдыхать).
Саму эту метрику я не веду (цели ночевать на работе нет), т.к.
Все планы составляются без учета переработок и работы в выходные.
Если приходится выходить в выходной, то сотрудник получает ДВОЙНУЮ оплату (все по ТК) и , разумеется, мы кросс-функциональны теперь и если кто-то не может выйти, то найдется тот, кто сможет. Сами выходы теперь крайне редки.
У нас в договоре с сотрудниками предусмотрено "чуть больше отпускных дней" нежели стандартные 28 ;)
Ну и я просто вижу людей (кто и когда работает). В данном случае, живое общение и человеческое отношение к сотрудникам имхо заменяет любую метрику.
Думаю, что это вполне отвечает на Ваш вопрос про то как мы "истязаем сотрудников Эджайлом" :)
Начну с последнего вопроса. Мы ведь про ВТБ Лизинг говорим, а не ООО "Ромашка-22" (надеюсь, такого ООО в природе нет :) ). Разумеется мы достаточно серьезно вкладываемся в сотрудников. Один профессиональный Agile-тренинг и тренерское сопровождение команд чего стоили )) Если еще серьезнее, то Вы правы, Agile это про людей, про взаимодействие, про ценности. Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро "сдаются" (мимикрировать долго не получается). По факту, я не вижу смысла переделывать людей, я лишь показываю, что можно работать иначе, а дальше уже выбор человека. "В Agile" мы не загоняем. Очень многие компании несут Agile огнем и мечем, у нас же, те кто прям не могут работать кроме как "каскадно" и обладают иными ценностями, не могут поддерживать должный уровень коммуникаций и т.д. или уходят , или мы находим им место в других направлениях, в которых они могут развиваться дальше.
По поводу метрик производительности труда сложнее. Лично я уверен, что любую метрику можно "читить". Для того, чтобы метрика работала, ее надо реализовывать в компании, культура сотрудников которой позволяет честно показывать что происходит. Например: выработка времени. Списываем честно время и если списали больше, то что? поработали лучше и сделали больше? - нет. Идем дальше, "количество выполненных задач" , оно? тоже нет, т.к. как только люди узнают, что это критерий, то сразу задача начинает декомпозироваться на миллион подзадач и т.д. В статье написано какие метрики мы использовали и ключевыми были лишь 3:
-CSI (отношения с партнерами/клиентами, обратная связь стейкхолдеров)
-LeadTime (за ней смотрели на всех уровнях, т.к. ее можно очень успешно читить)
-Проверяемый экономический эффект (реализуемый эффект. Мы таки деньги зарабатываем)
А Вы о каких метриках говорите? Строчки кода? Переработки? или что? Поделитесь, пожалуйста, я с удовольствием почитаю. Всегда рад узнать что-то новое!
ps
... чуть не забыл. Я предлагаю использовать слово "прививали" (например). Agile это не методика, это культура. Внедрение культуры не работает, культуру прививают или , например, "выращивают" (да, странно звучит :) ). Если относиться как к ВНЕДРЕНИЮ, то это просто про процессы и карго-культ. Такого нам не надо. Agile только через ценности (понимаю, со стороны звучит как дикость и "радуга с единорогами")
Все вот в этой Вашей фразе: "При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. "
КОНЕЧНО! Почему-то историю с Agile часто воспринимают лишь как игрушка ИТ-шников. У меня ушло не мало сил на объяснение внутри компании, что Agile это про всю компанию! Разумеется, Agile как культура и ценности не может существовать в отдельно взятом подразделении.
Сложно конечно в комментариях дискутировать на такие глобальные темы. Попробую сформулировать свои мысли на этот счет:
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 клеток, а больше). Там, действительно, можно все заранее продумать, а вот в чем-то более сложном.. я еще таких всесторонних "продумщиков" не встречал. Если Вы такой, то снимаю шляпу! мне бы такие сотрудники очень пригодились, правда.
Agile больше подходит для легси-проектов , в которых доработки - мелочь, а на стартапах Agile-зло, т.к. может быть много изменений.
Постараюсь ответить (соответственно):
Есть такой термин DoD (Definitionof Done) , т.е. уровень вашего тяп-ляпа вы способны определить самостоятельно. Например, в последние 1,5 года мы очень активно развиваем автотесты. Не скажу, что достигли потрясающих успехов, но наш функционал покрыт автотестами > 70%. Учитывая, что 100% и не нужно, то ИМХО мы в состоянии проверять состояние регрессионного функционала. Так вот, прежде чем что-то выпустить, системы проходят полный цикл тестирования (скоро еще DevOps историей займемся и будет ваще здорово :) ). Таким образом, как написано в статье, с появлением Agile истории в командах, они даже снизили уровень багов и это тенденция сохраняется вот уже более года (с момента старта пилота).
Тут мне сложно комментировать, т.к. например, Scrum, лучше работает именно на стартапах, где надо быстро проверить идею и оперативно подстраиваться под изменения среды. Приведу Ваш пример чуть иначе чем Вы: "Для стартапов, которые не знают чего им надо, Waterfall настоящее зло, т.к. о том, что программисту надо все переписать, компания узнает не через неделю, а через месяцев 6 или даже больше, т.к. первым этапом пойдет аналитика, в результате которой будет БТ , слова в котором будут звучать правильно, а вот как их реализует программист.. уж все мы видели этот мем с качелями и деревом". Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно. Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Эх.. написал развернутый ответ , но не нажал "отправить" перед F5.. вечереет..
Попробую еще раз)
Вы верно подметили про "хату с краю", однако, я несколько о другом пишу. Думаю, что не будете спорить, большие компании дадут фору любому стартапу по части бюрократии. Иногда это все доходит до того, что внедрение элементарного улучшения/изменения процесса выглядит для сотрудника как прохождение миллиона итераций обсуждений, согласований, комитетов, собора подписей и т.д. Возникают "окольные тропы" в обход корпоративных процессов. Конечно, такое охладит пыл любого и потихоньку все приходит к той самой "хате".
Имея лидирующие места на рынке лизинга, разумеется, компания "ВТБ Лизинг" имеет возможность инвестировать в своих сотрудников большие ресурсы, при этом, странно помещать людей в условия, в которых они не смогут реализовать свой потенциал. Учитывая планы по предстоящим изменениям, мне хотелось создать такую среду, в которой было бы минимум преград на пути новых Agile-команд. Никаких "хат", только генерация идей и их реализация. Да, знаю, звучит пафосно, но идея была именно такая и таковой остается. Я уверен, что если люди занимаются любимым делом, человек не чувствует себя каким-то бесполезным винтиком в гигантской системе, у них есть реальная обратная связь от клиентов и возможность реализовывать свои идеи, то "хаты с краю" пропадают сами собой. Я искал людей, которые ГОРЯТ и на их примере старался показать остальным, что все возможно.
В том, что получится уверенности не может быть вообще. Была идея основанная на:
Личный опыт. Я уже проходил подобную историю в другой крупной финансовой компании (наверное, не этично писать в какой). Ситуация была аналогичной. Когда попадаешь в схожую среду, начинаешь видеть необходимость определенных изменений более четко.
Люди. Я начал с поиска сторонников и пытался вдохновить опытных сотрудников компании на изменения. Мы анализировали текущие процессы и продукты компании, попытались сформулировать видение развития продуктов вместе со стейкхолдерами, составляли звездные карты, собирали обратную связь от стейкхолдеров и ИТ-шников по части удобства текущих процессов и т.д. В итоге, коллективно сошлись во мнении, что все должно получиться.
Пилот. да, это более поздний этап, но любая гипотеза должна быть проверена. Пилот окончательно показал, что идея верная и при правильном масштабировании, мы получим отличный результат. После его успешного прохождения, на высшем уровне компании дали добро на масштабирование.
Еще немного про "хату с краю". Тут важно понять простую вещь. Вас окружают люди, а не какие-то злодеи, которые принципиально загоняют вас и себя в сложные условия. Я всегда придерживаюсь мнения, что если людям показать ситуацию, сделать предложение, которое подкрепляется реальным практическим результатом, то они будут меняться и менять окружение. Главное показать им их выгоду :) Когда у вас есть возможность напрямую влиять на тот продукт, который вы делаете, вы видите реальный результат своей работы в бою, благодарность пользователей и даже клиентов компании, вы точно не будете оставаться в стороне. Это не могло не сработать ;)
Интересный вопрос :) сейчас, скорее, мы проходим стадию "опрозрачнивания", т.е. за счет большого вовлечения стейкхолдеров в процессы: совместной с ИТ генерации идей, формулирования UserStory, регулярных демонстраций результатов работы спринта и т.д. мы показываем друг другу, что какие-то элементарные изменения могут влиять на результат. Это дает свои плоды, т.е. стейкхолдеры начали понимать, что каждое изменение должно приносить ценность, а не просто "хочу". Особенно дело сдвинулось, когда начали появляться "Владельцы продуктов". У нас они все от бизнеса, а не из ИТ. Вот эти ребята быстро смекнули, что ценные заявки должны быть в верхних строчках бэклогов, а то команда будет обходиться компании дороже чем эффект от ее работы :)
Да и вообще, Вы серьезно думаете, что так легко найти идеальных стейкхолдеров, которые к тому и не рядовые сотрудники (у нас и директора генерят идеи постоянно в погоне за изменениями рынка), да еще и они не должны хотеть всего и сразу? + предлагаете оценивать компетенции людей только по тому, сколько они генерят изменений? Мне за 20 лет работы в ИТ такие пока не попадались :) Думаю, что единственный способ победить "поток сознания" и отфильтровать ценные гипотезы - это оценивать эффект от каждой из них , приоритезировать и максимально быстро проверять идею. ВАЖНО потом проверять попадаем ли в ожидания, т.е. сколько в реале пришло денег от реализации.
По поводу SAFE или Nexus.
Это наше будущее. Вспомните свое первое знакомство со Scrum (например). Сама идея того, что можно делать продукты иначе была удивительна и чужда (ну, у меня так точно было :) ). Не думаю, что Вы сразу пошли сертифицироваться на PST (например). В школе мы тратим 11 лет для получения среднего образования, в институте 5 лет для высшего образования и т.д. Это я все к тому, что у всех разный уровень зрелости и трансформация начинается с разных уровней. У меня , на момент начала пилота, да и зарождения идеи трансформации, не было людей, которые понимали даже какие-то базовые вещи и могли отличить "Владельца продукта" от "Руководителя проекта", Scrum от Kanban и т.д. Масштабируемый Scrum (в тот момент) казался чем-то таким непостижимым и мы решили, что в пилоте это не нужно (не те масштабы). А вот сейчас..
У Вас есть практический опыт масштабирования Agile? Хорошо знакомы с SAFE? "тогда мы идем к Вам" за советами :)
Согласен. Именно поэтому в статью я вставлял фразы типа "...а потом суметь правильно привить им эту культуру. "
Суть трансформации в том, что мы ее проводим не только и не столько как изменение процессов, а именно изменение культуры и ценностей в компании. Ценно партнерство на всех этапах (люди не винтики и не ресурсы, мнение каждого важно). Я стараюсь двигать Agile именно как ценности и мышление, а не карго-культ (бездумно делай так и будет успех). Уплощение структуры у нас тоже происходит (это помогает убирать "испорченный телефон" и вовлекать каждого в процесс "креатива", т.к. все участвуют в генерации идей, а не только начальники). Крайне важно слышать тех, кто непосредственно пишет код или работает с твоим продуктом в полях. Scrum с его Retro и Demo отлично помогают в этом. Сейчас мы растем (существенно), наше руководство поверило в in-house разработку и мне нужно больше людей, которым есть, что сказать ))
Добрый день! А не подскажете, где-то написано (например, ITSM) что 2ая линия должна воспроизводить дефекты на препроде (например) ? иногда очень сложно бывает выстраивать процессы, когда они "межподразделенческие" в компании и всегда появляется что-то типа "нет, это разработка должна воспроизводить" или наоборот.
Мне нравится как у вас написано:
"2-я занимается сбором диагностической информации (логов, метрик мониторинга, конфигов), отвечает на вопросы 3-й линии о случившемся"
Но и у вас эта граница стерта, т.к. далее идет: "отвечает на вопросы 3-й линии о случившемся (когда случилось, что было до инцидента, как его повторить и т. д). " Т.е. повторение оно как бы на 3ей линии у вас.
Я ищу пруфы (уважаемые :) ) чтобы понять что говорят "бест практикс"
Я думаю, что под термин "цифровая трансформация" пихают все, что не могут объяснить своими словами :) когда-то давно (годах в 2000-х), наверное, действительно приходилось трансформировать текущие процессы и переводить их в цифру (я тогда работал программистом и отлично помню как приходилось продавать сотрудникам компаний пользу от цифровизации их процессов). Это я к тому, что термин бы прозвучал, если бы это была какая-то формальная статья для ТОП-менеджеров, а я тут просто как есть попытался изложить.
Надеюсь, я правильно понял основной вопрос. Думаю, что идеи смысла не лишены. Представим себе цепочку: У вас есть продукт, который является стратегическим преимуществом компании, вы должны его развивать максимально быстро (конкурентов куча), вы должны иметь возможность тестировать гипотезы так быстро, как это делают стартапы и т.д.
Это значит, что фиксироваться по договорам fix- вы не можете, т.к. они подразумевают наличие согласованного ТЗ и разработанное 1 в 1 должно соответствовать ТЗ. Что-то можно оперативно менять в таких условиях? нееет... (НЕ ПОДХОДИТ!)
А если взять подрядчика по t&m? да, в этом случае все похоже на собственную разработку, вы можете давать сотрудникам те задачи, которые считаете нужными, минимизируете свою ответственность за удержание и мотивацию персонала и т.д., но(!) как вы будете выстраивать с ними отношения: прививать корпоративные ценности, мотивировать , обучать и т.д. если это сотрудник другой компании (у него свои работодатели и он находится в той структуре, культуре, финансовой зависимости, организационных правилах) ?
Ответил?
Тут вопрос ,скорее, про культуру взаимодействия. Как известно, культура не внедряется, не навязывается, а прививается. Привить "нужную" культуру сотрудникам, которые получают деньги от кого-то еще и которые работают в рамках культуры своего непосредственного работодателя, очень сложно. Лично я вижу успех в том, что люди с едиными целями и культурой способны на многое.
Есть такое выражение "культура следует за структурой", вот, пытаемся ломать все разграничивающие стены (разные KPI, орг.структура и т.д.) и формировать необходимую нам среду для успеха.
Да, я тоже знаю успешные кейсы с подрядом и у нас они тоже есть, однако, там, где вы разрабатываете продукты, которые будут или являются вашим стратегическим или конкурентным преимуществом, таки лучше сделать выбор в пользу in-house.
)))
О! привет!
Рад встрече!)) успехов в трансформации! Держитесь, будет увлекательно )) и чуток тяжело ))
Вы уверены, что у Вас нет личной обиды на что-то, что когда-то назвали для Вас "Эджайлом"? Через слово сквозит "разводка", "обман" и тд.
Судя по всему, предложенная метрика (измерять как долго сотрудники остаются на работе после официального рабочего времени, как я ее понял) и продиктована тем, что когда-то Вас так, выражаясь обычным языком, кинули.
У нас наоборот. Цель - создать среду для плодотворной работы. Какая еще среда, если люди будут обозлены, подавлены и работают 24/7 ? В этом и дело, что я верю в эффективную работу без переработок!
По метрике отвечаю:
В этом году глобальная цель - "снижать накопленный сотрудниками отпуск". Цифры я называть не могу, но по сравнению с 2019 годом, мы снизили накопленные отпуска процентов на 45 точно и этот тренд продолжается (люди должны отдыхать).
Саму эту метрику я не веду (цели ночевать на работе нет), т.к.
Все планы составляются без учета переработок и работы в выходные.
Если приходится выходить в выходной, то сотрудник получает ДВОЙНУЮ оплату (все по ТК) и , разумеется, мы кросс-функциональны теперь и если кто-то не может выйти, то найдется тот, кто сможет. Сами выходы теперь крайне редки.
У нас в договоре с сотрудниками предусмотрено "чуть больше отпускных дней" нежели стандартные 28 ;)
Ну и я просто вижу людей (кто и когда работает). В данном случае, живое общение и человеческое отношение к сотрудникам имхо заменяет любую метрику.
Думаю, что это вполне отвечает на Ваш вопрос про то как мы "истязаем сотрудников Эджайлом" :)
Спасибо за интересный вопрос.
Начну с последнего вопроса. Мы ведь про ВТБ Лизинг говорим, а не ООО "Ромашка-22" (надеюсь, такого ООО в природе нет :) ). Разумеется мы достаточно серьезно вкладываемся в сотрудников. Один профессиональный Agile-тренинг и тренерское сопровождение команд чего стоили )) Если еще серьезнее, то Вы правы, Agile это про людей, про взаимодействие, про ценности. Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро "сдаются" (мимикрировать долго не получается). По факту, я не вижу смысла переделывать людей, я лишь показываю, что можно работать иначе, а дальше уже выбор человека. "В Agile" мы не загоняем. Очень многие компании несут Agile огнем и мечем, у нас же, те кто прям не могут работать кроме как "каскадно" и обладают иными ценностями, не могут поддерживать должный уровень коммуникаций и т.д. или уходят , или мы находим им место в других направлениях, в которых они могут развиваться дальше.
По поводу метрик производительности труда сложнее. Лично я уверен, что любую метрику можно "читить". Для того, чтобы метрика работала, ее надо реализовывать в компании, культура сотрудников которой позволяет честно показывать что происходит. Например: выработка времени. Списываем честно время и если списали больше, то что? поработали лучше и сделали больше? - нет. Идем дальше, "количество выполненных задач" , оно? тоже нет, т.к. как только люди узнают, что это критерий, то сразу задача начинает декомпозироваться на миллион подзадач и т.д. В статье написано какие метрики мы использовали и ключевыми были лишь 3:
-CSI (отношения с партнерами/клиентами, обратная связь стейкхолдеров)
-LeadTime (за ней смотрели на всех уровнях, т.к. ее можно очень успешно читить)
-Проверяемый экономический эффект (реализуемый эффект. Мы таки деньги зарабатываем)
А Вы о каких метриках говорите? Строчки кода? Переработки? или что? Поделитесь, пожалуйста, я с удовольствием почитаю. Всегда рад узнать что-то новое!
ps
... чуть не забыл. Я предлагаю использовать слово "прививали" (например). Agile это не методика, это культура. Внедрение культуры не работает, культуру прививают или , например, "выращивают" (да, странно звучит :) ). Если относиться как к ВНЕДРЕНИЮ, то это просто про процессы и карго-культ. Такого нам не надо. Agile только через ценности (понимаю, со стороны звучит как дикость и "радуга с единорогами")
Спасибо! рад, что понравилось
Спасибо за развернутый комментарий. Теперь понял.
Все вот в этой Вашей фразе: "При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. "
КОНЕЧНО! Почему-то историю с Agile часто воспринимают лишь как игрушка ИТ-шников. У меня ушло не мало сил на объяснение внутри компании, что Agile это про всю компанию! Разумеется, Agile как культура и ценности не может существовать в отдельно взятом подразделении.
куда? :)
Класс! теперь я Ваш подписчик :)
написал в личку
Сложно конечно в комментариях дискутировать на такие глобальные темы. Попробую сформулировать свои мысли на этот счет:
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 клеток, а больше). Там, действительно, можно все заранее продумать, а вот в чем-то более сложном.. я еще таких всесторонних "продумщиков" не встречал. Если Вы такой, то снимаю шляпу! мне бы такие сотрудники очень пригодились, правда.
Давайте разберем Ваши тезисы. У увидел:
Agile это тяп-ляп
Agile больше подходит для легси-проектов , в которых доработки - мелочь, а на стартапах Agile-зло, т.к. может быть много изменений.
Постараюсь ответить (соответственно):
Есть такой термин DoD (Definition of Done) , т.е. уровень вашего тяп-ляпа вы способны определить самостоятельно. Например, в последние 1,5 года мы очень активно развиваем автотесты. Не скажу, что достигли потрясающих успехов, но наш функционал покрыт автотестами > 70%. Учитывая, что 100% и не нужно, то ИМХО мы в состоянии проверять состояние регрессионного функционала. Так вот, прежде чем что-то выпустить, системы проходят полный цикл тестирования (скоро еще DevOps историей займемся и будет ваще здорово :) ). Таким образом, как написано в статье, с появлением Agile истории в командах, они даже снизили уровень багов и это тенденция сохраняется вот уже более года (с момента старта пилота).
Тут мне сложно комментировать, т.к. например, Scrum, лучше работает именно на стартапах, где надо быстро проверить идею и оперативно подстраиваться под изменения среды. Приведу Ваш пример чуть иначе чем Вы: "Для стартапов, которые не знают чего им надо, Waterfall настоящее зло, т.к. о том, что программисту надо все переписать, компания узнает не через неделю, а через месяцев 6 или даже больше, т.к. первым этапом пойдет аналитика, в результате которой будет БТ , слова в котором будут звучать правильно, а вот как их реализует программист.. уж все мы видели этот мем с качелями и деревом". Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно. Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Эх.. написал развернутый ответ , но не нажал "отправить" перед F5.. вечереет..
Попробую еще раз)
Вы верно подметили про "хату с краю", однако, я несколько о другом пишу. Думаю, что не будете спорить, большие компании дадут фору любому стартапу по части бюрократии. Иногда это все доходит до того, что внедрение элементарного улучшения/изменения процесса выглядит для сотрудника как прохождение миллиона итераций обсуждений, согласований, комитетов, собора подписей и т.д. Возникают "окольные тропы" в обход корпоративных процессов. Конечно, такое охладит пыл любого и потихоньку все приходит к той самой "хате".
Имея лидирующие места на рынке лизинга, разумеется, компания "ВТБ Лизинг" имеет возможность инвестировать в своих сотрудников большие ресурсы, при этом, странно помещать людей в условия, в которых они не смогут реализовать свой потенциал. Учитывая планы по предстоящим изменениям, мне хотелось создать такую среду, в которой было бы минимум преград на пути новых Agile-команд. Никаких "хат", только генерация идей и их реализация. Да, знаю, звучит пафосно, но идея была именно такая и таковой остается. Я уверен, что если люди занимаются любимым делом, человек не чувствует себя каким-то бесполезным винтиком в гигантской системе, у них есть реальная обратная связь от клиентов и возможность реализовывать свои идеи, то "хаты с краю" пропадают сами собой. Я искал людей, которые ГОРЯТ и на их примере старался показать остальным, что все возможно.
В том, что получится уверенности не может быть вообще. Была идея основанная на:
Личный опыт. Я уже проходил подобную историю в другой крупной финансовой компании (наверное, не этично писать в какой). Ситуация была аналогичной. Когда попадаешь в схожую среду, начинаешь видеть необходимость определенных изменений более четко.
Люди. Я начал с поиска сторонников и пытался вдохновить опытных сотрудников компании на изменения. Мы анализировали текущие процессы и продукты компании, попытались сформулировать видение развития продуктов вместе со стейкхолдерами, составляли звездные карты, собирали обратную связь от стейкхолдеров и ИТ-шников по части удобства текущих процессов и т.д. В итоге, коллективно сошлись во мнении, что все должно получиться.
Пилот. да, это более поздний этап, но любая гипотеза должна быть проверена. Пилот окончательно показал, что идея верная и при правильном масштабировании, мы получим отличный результат. После его успешного прохождения, на высшем уровне компании дали добро на масштабирование.
Еще немного про "хату с краю". Тут важно понять простую вещь. Вас окружают люди, а не какие-то злодеи, которые принципиально загоняют вас и себя в сложные условия. Я всегда придерживаюсь мнения, что если людям показать ситуацию, сделать предложение, которое подкрепляется реальным практическим результатом, то они будут меняться и менять окружение. Главное показать им их выгоду :) Когда у вас есть возможность напрямую влиять на тот продукт, который вы делаете, вы видите реальный результат своей работы в бою, благодарность пользователей и даже клиентов компании, вы точно не будете оставаться в стороне. Это не могло не сработать ;)
Интересный вопрос :) сейчас, скорее, мы проходим стадию "опрозрачнивания", т.е. за счет большого вовлечения стейкхолдеров в процессы: совместной с ИТ генерации идей, формулирования UserStory, регулярных демонстраций результатов работы спринта и т.д. мы показываем друг другу, что какие-то элементарные изменения могут влиять на результат. Это дает свои плоды, т.е. стейкхолдеры начали понимать, что каждое изменение должно приносить ценность, а не просто "хочу". Особенно дело сдвинулось, когда начали появляться "Владельцы продуктов". У нас они все от бизнеса, а не из ИТ. Вот эти ребята быстро смекнули, что ценные заявки должны быть в верхних строчках бэклогов, а то команда будет обходиться компании дороже чем эффект от ее работы :)
Да и вообще, Вы серьезно думаете, что так легко найти идеальных стейкхолдеров, которые к тому и не рядовые сотрудники (у нас и директора генерят идеи постоянно в погоне за изменениями рынка), да еще и они не должны хотеть всего и сразу? + предлагаете оценивать компетенции людей только по тому, сколько они генерят изменений? Мне за 20 лет работы в ИТ такие пока не попадались :) Думаю, что единственный способ победить "поток сознания" и отфильтровать ценные гипотезы - это оценивать эффект от каждой из них , приоритезировать и максимально быстро проверять идею. ВАЖНО потом проверять попадаем ли в ожидания, т.е. сколько в реале пришло денег от реализации.
По поводу SAFE или Nexus.
Это наше будущее. Вспомните свое первое знакомство со Scrum (например). Сама идея того, что можно делать продукты иначе была удивительна и чужда (ну, у меня так точно было :) ). Не думаю, что Вы сразу пошли сертифицироваться на PST (например). В школе мы тратим 11 лет для получения среднего образования, в институте 5 лет для высшего образования и т.д. Это я все к тому, что у всех разный уровень зрелости и трансформация начинается с разных уровней. У меня , на момент начала пилота, да и зарождения идеи трансформации, не было людей, которые понимали даже какие-то базовые вещи и могли отличить "Владельца продукта" от "Руководителя проекта", Scrum от Kanban и т.д. Масштабируемый Scrum (в тот момент) казался чем-то таким непостижимым и мы решили, что в пилоте это не нужно (не те масштабы). А вот сейчас..
У Вас есть практический опыт масштабирования Agile? Хорошо знакомы с SAFE? "тогда мы идем к Вам" за советами :)
Согласен. Именно поэтому в статью я вставлял фразы типа "...а потом суметь правильно привить им эту культуру. "
Суть трансформации в том, что мы ее проводим не только и не столько как изменение процессов, а именно изменение культуры и ценностей в компании. Ценно партнерство на всех этапах (люди не винтики и не ресурсы, мнение каждого важно). Я стараюсь двигать Agile именно как ценности и мышление, а не карго-культ (бездумно делай так и будет успех). Уплощение структуры у нас тоже происходит (это помогает убирать "испорченный телефон" и вовлекать каждого в процесс "креатива", т.к. все участвуют в генерации идей, а не только начальники). Крайне важно слышать тех, кто непосредственно пишет код или работает с твоим продуктом в полях. Scrum с его Retro и Demo отлично помогают в этом. Сейчас мы растем (существенно), наше руководство поверило в in-house разработку и мне нужно больше людей, которым есть, что сказать ))