Изменения

:: '''Сергей Рогачев''' Мы проводили такие мероприятия. К сожалению, на уровне менеджмента такие детали уровня конструктор лего не дают возможности принятия решений. Им нужен ментор, который смог бы объяснить маппинг их проблем на эти отдельные кубики. То есть выходит, что это инструмент Agile-коуча (ментора). И второе, это слабо влияет на реальные изменения в командах: ату "всем завтра внедрить такую-то штуку" сверху не работает - эти кубики надо продавать командам, чтобы решить задачи-проблемы их бизнеса-менеджмента. Итого, выходит, что бизнесу-менеджменту нужно решение проблемы, но решить проблему может только команда, поэтому конструктор решения проблем не нужен бизнесу, но, возможно, нужен команде и их ментору. А это... по сути просто инструмент ретроспективы, не более того. Короче, слишком сложно по мне.

:: '''Максим Цепков''' Сергей Рогачев С OMG Essence - как с диаграммами бизнес-процессов. Сначала ты рисуешь их сам, чтобы понимать, показываешь бизнесу. потом бизнес тоже начинает их понимать, можно на них обсуждать. А дальше - он и сам это дело рисует, а не просто говорит. Но язык Essence - это сильно больше, чем просто бизнес-процесс, в этом ценность. Теперь про проблемы и практики. Это как шаблоны программирования, тоже очень похоже. Есть какая-то проблема, например, нарушена коммуникация, или что-то бросаются разрабатывать раньше, чем убедились в необходимости у стейкхолдеров или что-то еще. У тебя в библиотеке есть практика под нее, например, особая фаза ретроспективы, или отдельный чек-лист по проверке готовности на планировании, Ты ее достаешь и добавляешь к процессу - но не только текстом, а на схемах. Естественно, не сверху "всем внедрить", а в каждой команде отдельно. А дальше каждая команда идет своим отличающимся путем - она же его на ретро корректирует, плюс могут быть отдельные сессии со стейкхолдерами по удовлетворенности работой команды, еще что-то. И тут есть инструмент компактного описания для тех, кто смотрит на ситуацию в целом, сравнивает команды и т.п. - для agile-коучей, руководителей и других. Но применять имеет смысл только если организация - большая, команд - много. Иначе - да слишком сложно, можно и без этого.

:: '''Сергей Рогачев''' Maxim Tsepkov мне показалось, что ты подтвердил мое впечатление. Это инструмент ментора. Но инструментом команды он не станет. Команда пока что-то не переживет на своей шкуре, не верит никаким авторитетам: именно поэтому мы на тренингах даём меньше теории, но больше упражнений и игр - если не верят авторитетам, то как поверят библиотеке? Про общение с бизнесом и менеджментом - да, но опять же инструмент ментора: посмотрел, сделал выводы и... пошел к бизнесу с предложением изменений на обычном языке. :)

:: '''Максим Цепков''' Сергей Рогачев Подтвердил, но отчасти. Начинается все с ментора, так же как рисование процессов через activity diagram начинается с аналитика. А дальше - развилка: ментор, как и аналитик может оставить эти диаграммы себе, разговаривая с остальными на привычным им языках (простыми текстами или вольными картинками), а может - обучить простым диаграммам, и при успехе они начнут пользоваться. Что уместно - зависит от ситуации.

[https://www.facebook.com/mtsepkov/posts/1549015261822089 доклад Pascale Xelot-Dugat] рассказывает про то, как IBM работает со стартапами. И это интересно не только из позиции "заглянуть в опыт большой компании", но и из позиции встраивания в международный рынок стартапов и софта.

{{wl-publish: 2017-10-26 02:56:51 +0300 | MaksTsepkov }}