Вдогонку к предыдущему посту: у многих аналитиков техника Event Storming вызывает... ну, почти что отторжение, а между тем это же всё очень похоже на юскейсы.
Вот смотрите:
🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать.
Когда мы изучаем юскейсы, я всем советую составлять отдельный перечень всех событий, собирая их из предусловий/постусловий. Кто хоть раз составлял такой перечень и отслеживал его актуальность? А в штурме событий он занимает центральное место!
🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время?
Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована")
Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает").
А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев.
Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события).
Акторы, они везде акторы (хотя в ES — и 🟥 системы тоже).
Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит.
Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов.
Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.
Вот смотрите:
🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать.
Когда мы изучаем юскейсы, я всем советую составлять отдельный перечень всех событий, собирая их из предусловий/постусловий. Кто хоть раз составлял такой перечень и отслеживал его актуальность? А в штурме событий он занимает центральное место!
🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время?
Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована")
Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает").
А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев.
Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события).
Акторы, они везде акторы (хотя в ES — и 🟥 системы тоже).
Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит.
Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов.
Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.
👌6❤5😢1
Извините, будет пост про бизнес-анализ, а не системный. Причем бизнес-анализ именно в смысле организационного консультирования, а не сбора требований к информационной системе. Ну, какими проектами занимаюсь, про то и пишу. Сейчас вот так.
И что хочу сказать: очень большое упущение в образовании бизнес-аналитиков — практически полное игнорирование теорий менеджмента! Если мы посмотрим на BABoK, он не основан ни на какой теории, это просто сборник некоторых практик "из полей".
Взять, хотя бы, модель организации. Есть такая книга, аж 1986 года, "Образы организаций" канадского профессора Гэрета Моргана. Он говорит, что любая модель организации следует какой-то метафоре, и приводит их 8:
1. Машина, механизм, состоящий из соединенных деталей.
2. Организм, пытающийся выживать и адаптироваться к меняющейся окружающей среде.
3. Мозг, постоянно получающий и обрабатывающий информацию, принимающий решения.
4. Культура, общество в миниатюре. Со своими суб-культурами, ценностями, нормами, верованиями, ритуалами.
5. Политическая система. Организация — это игра, борьба разных акторов за влияние и власть.
6. Психическая тюрьма. Организация — это набор мифов и историй, ограничивающих мысли, идеи и действия людей.
7. Инструмент доминирования. Организации нужны, чтобы подавлять и эксплуатировать людей.
8. Непрерывный поток трансформаций. Организация постоянно должна находиться в поиске и постоянно меняться в ответ на вызовы.
А теперь думаем: как аналитики, мы с какой метафорой работаем?
Важно, что это не типология организаций, а метафоры — как мы смотрим. Это значит, что на каждую организацию можно посмотреть через любую оптику. У вас гибкая обучающаяся бирюзовая организация? Или ваш миф настолько силен, что это уже выглядит, как секта?
Мы думаем, что мы работаем с внедрением автоматизированных систем. Но на самом деле мы работаем с изменениями.
Системы не было, система появилась. Это изменение.
Оно меняет:
- способ осуществления деятельности, структуру механизма организации (очевидно)
- возможности организации к адаптации (то, что делали руками, можно быстро поменять, а вот то, что зашито в программную систему...)
- распределение мест хранения и способов распространения информации
- соответственно, распределение власти. Та информация, которую раньше я раздавал порционно и в нужном мне ключе, теперь доступна всем. Ой-ой, я потерял рычаг манипуляций. И какие-то там итшники, у которых и бизнес-целей нет, стали вдруг очень важны — ведь без них ничего не будет работать.
- культуру. У нас была культура взаимных одолжений, а теперь в вашей системе нужно всё делать в срок и одинаково для всех. Нарастает отчуждение, разрушаются неформальные связи. Или наоборот, возникают тайные практики противодействия и фальсификации данных.
- ограничения. Ура, мы теперь можем ограничивать сотрудников так, как раньше и подумать не могли!
- гибкость. У нас не было никаких процессов, мы были супер-гибкими, каждый проект могли делать индивидуально. А в вашей системе нужно делать всё одинаково, слишком узкие рамки.
Мне кажется, мы чаще всего смотрим из метафоры машины, где вся деятельность выглядит, как набор бизнес-процессов, а шаги бизнес-процесса всегда выполняются четко, в рамках регламента, и, в общем, неважно кем — лучше бы роботами, конечно.
В связи с этим вопрос: какая метафора лучше всего подходит, если мы собираемся внедрять в организацию ИИ? Или, того хуже, перестраивать организацию по принципу AI-first?
И что хочу сказать: очень большое упущение в образовании бизнес-аналитиков — практически полное игнорирование теорий менеджмента! Если мы посмотрим на BABoK, он не основан ни на какой теории, это просто сборник некоторых практик "из полей".
Взять, хотя бы, модель организации. Есть такая книга, аж 1986 года, "Образы организаций" канадского профессора Гэрета Моргана. Он говорит, что любая модель организации следует какой-то метафоре, и приводит их 8:
1. Машина, механизм, состоящий из соединенных деталей.
2. Организм, пытающийся выживать и адаптироваться к меняющейся окружающей среде.
3. Мозг, постоянно получающий и обрабатывающий информацию, принимающий решения.
4. Культура, общество в миниатюре. Со своими суб-культурами, ценностями, нормами, верованиями, ритуалами.
5. Политическая система. Организация — это игра, борьба разных акторов за влияние и власть.
6. Психическая тюрьма. Организация — это набор мифов и историй, ограничивающих мысли, идеи и действия людей.
7. Инструмент доминирования. Организации нужны, чтобы подавлять и эксплуатировать людей.
8. Непрерывный поток трансформаций. Организация постоянно должна находиться в поиске и постоянно меняться в ответ на вызовы.
А теперь думаем: как аналитики, мы с какой метафорой работаем?
Важно, что это не типология организаций, а метафоры — как мы смотрим. Это значит, что на каждую организацию можно посмотреть через любую оптику. У вас гибкая обучающаяся бирюзовая организация? Или ваш миф настолько силен, что это уже выглядит, как секта?
Мы думаем, что мы работаем с внедрением автоматизированных систем. Но на самом деле мы работаем с изменениями.
Системы не было, система появилась. Это изменение.
Оно меняет:
- способ осуществления деятельности, структуру механизма организации (очевидно)
- возможности организации к адаптации (то, что делали руками, можно быстро поменять, а вот то, что зашито в программную систему...)
- распределение мест хранения и способов распространения информации
- соответственно, распределение власти. Та информация, которую раньше я раздавал порционно и в нужном мне ключе, теперь доступна всем. Ой-ой, я потерял рычаг манипуляций. И какие-то там итшники, у которых и бизнес-целей нет, стали вдруг очень важны — ведь без них ничего не будет работать.
- культуру. У нас была культура взаимных одолжений, а теперь в вашей системе нужно всё делать в срок и одинаково для всех. Нарастает отчуждение, разрушаются неформальные связи. Или наоборот, возникают тайные практики противодействия и фальсификации данных.
- ограничения. Ура, мы теперь можем ограничивать сотрудников так, как раньше и подумать не могли!
- гибкость. У нас не было никаких процессов, мы были супер-гибкими, каждый проект могли делать индивидуально. А в вашей системе нужно делать всё одинаково, слишком узкие рамки.
Мне кажется, мы чаще всего смотрим из метафоры машины, где вся деятельность выглядит, как набор бизнес-процессов, а шаги бизнес-процесса всегда выполняются четко, в рамках регламента, и, в общем, неважно кем — лучше бы роботами, конечно.
В связи с этим вопрос: какая метафора лучше всего подходит, если мы собираемся внедрять в организацию ИИ? Или, того хуже, перестраивать организацию по принципу AI-first?
❤20👍11👏2🤔2👎1
Ещё одна метафора — организация, как ролевая игра. У Моргана такой нет, в 1986 это было не очень развито. Впрочем, и сейчас это не такая распространенная метафора, хотя в проектном бизнесе она очень продуктивна! В конце концов, каждый проект — это как рейд в игре!
Метафора ведь хороша чем — она сразу задает понимание, что есть в мире, и что с чем связано. Вот в ролевых играх на основе фэнтези есть расы — каждая со своими способностями и ценностями, есть классы (маг, воин и т.п.), есть какая-то типовая механика (например, собирается рейд на какого-нибудь монстра).
Такую метафору организации когда-то подробно расписал Алексей Кулаков (JetStyle, Ridero).
Вот краткий пересказ: сотрудников компании обычно можно отнести к трем фэнтезийным расам — гномы, эльфы и тролли. У них разные этические системы (понимание того, что хорошо) и взгляд на мир.
👴 Гномы на все смотрят, как на ресурс, из которого можно получить золото. Соответственно, хорошо умеют выстраивать из ресурсов механизмы для зарабатывания этого золота. Работники в этом смысле тоже попадают в категорию ресурсов. И разговоры гномы всегда ведут о ресурсах, о потоках (золота) и об их контроле. Про это же все решения гномов. Самое ценное для гнома — больше ресурсов и контроля. Соответственно, его можно убедить, предложив контроль/ресурс или напугав возможной потерей ресурсов. Самое страшное преступление для гнома — воровство и растрата ресурсов. Стиль управления — директивный, ресурсы должны делать, что им сказали.
🧝♀️Эльфы — про любовь и хорошие отношения. Эльфы строят отношения, создают атмосферу, гасят конфликты, ведут переговоры, занимаются дипломатией, выяснением, как помочь, как сделать лучше и т.п., чтобы всем было хорошо. [У Леши это не написано, но я думаю, бывают и темные эльфы, которые искусно плетут интриги, манипулируют чувствами и мастерски стравливают людей друг с другом]. Стиль принятия решений эльфов ужасен: это консенсус. Пока все не договорятся, дальше не двинемся. Эти разговоры могут продолжаться многими часами. Основная идея эльфа — сотрудники должны работать добровольно. Если не работают — нужно с ними поговорить. При этом эльфы не могут образовывать команды и ужасно ревнивы. Главные грехи для эльфа — измена и дезертирство. Ты что, не любишь нашу команду?!
Третья раса, распространенная в ИТ — 🧌тролли. Если гномы — про ресурсы, эльфы — про отношения, то тролли — про истину. Троллей интересует, как устроен мир на самом деле. И они до этого докопаются, а потом расскажут в самый неподходящий момент. При этом им вообще безразличны и чувства окружающих, и гномские потоки денег. Если кто-то где-то неправ или о чем-то не знает — нужно ему срочно об этом рассказать! [Я думаю, что троллей должно быть особенно много среди системных аналитиков и архитекторов]. Главная цель тролля — революция. Всё должно быть перестроено, потому что всё не так! Стиль управления троллей — доказательства. Мы будем делать так, потому что это правильно. Вот примеры из литературы, вот данные, вот факты. Самые страшные грехи — сокрытие/искажение правды и неприятие фактов.
Все три этики конфликтуют между собой, но все они нужны организации, иначе наступает дисфункция.
А кроме ролей есть ещё функции (классы): маги, жрецы и воины.
🔰 Маги всегда хотят сделать что-нибудь новое, первыми и таким способом, которым никто не делал. Или убедиться, что так сделать невозможно. Практическое применение и тем более деньги их не интересует, только приоритет. Для магов главное — эксперимент.
🧘♂️ Жрецы рассказывают людям, кто они, зачем они вместе и ради чего работают. И какие соратники им нужны, а какие нет. Главное для жрецов — миссия.
🦾 Воины отвечают за захват внешнего мира в самом широком смысле. Новые продажи, новые продукты, новые рынки. Воин готов терпеть боль, свою и чужую. Обычно это продавцы 😁
В компании нужны все расы и все классы. Они балансируют друг-друга. Когда маги зарубаются с воинами, нужен жрец, который им напомнит, зачем мы все здесь. Когда тролли подкидывают идею магам, нужен гном, чтобы сделать на этом деньги.
Как вам метафора? Встречали этих персонажей на работе?
Метафора ведь хороша чем — она сразу задает понимание, что есть в мире, и что с чем связано. Вот в ролевых играх на основе фэнтези есть расы — каждая со своими способностями и ценностями, есть классы (маг, воин и т.п.), есть какая-то типовая механика (например, собирается рейд на какого-нибудь монстра).
Такую метафору организации когда-то подробно расписал Алексей Кулаков (JetStyle, Ridero).
Вот краткий пересказ: сотрудников компании обычно можно отнести к трем фэнтезийным расам — гномы, эльфы и тролли. У них разные этические системы (понимание того, что хорошо) и взгляд на мир.
🧝♀️Эльфы — про любовь и хорошие отношения. Эльфы строят отношения, создают атмосферу, гасят конфликты, ведут переговоры, занимаются дипломатией, выяснением, как помочь, как сделать лучше и т.п., чтобы всем было хорошо. [У Леши это не написано, но я думаю, бывают и темные эльфы, которые искусно плетут интриги, манипулируют чувствами и мастерски стравливают людей друг с другом]. Стиль принятия решений эльфов ужасен: это консенсус. Пока все не договорятся, дальше не двинемся. Эти разговоры могут продолжаться многими часами. Основная идея эльфа — сотрудники должны работать добровольно. Если не работают — нужно с ними поговорить. При этом эльфы не могут образовывать команды и ужасно ревнивы. Главные грехи для эльфа — измена и дезертирство. Ты что, не любишь нашу команду?!
Третья раса, распространенная в ИТ — 🧌тролли. Если гномы — про ресурсы, эльфы — про отношения, то тролли — про истину. Троллей интересует, как устроен мир на самом деле. И они до этого докопаются, а потом расскажут в самый неподходящий момент. При этом им вообще безразличны и чувства окружающих, и гномские потоки денег. Если кто-то где-то неправ или о чем-то не знает — нужно ему срочно об этом рассказать! [Я думаю, что троллей должно быть особенно много среди системных аналитиков и архитекторов]. Главная цель тролля — революция. Всё должно быть перестроено, потому что всё не так! Стиль управления троллей — доказательства. Мы будем делать так, потому что это правильно. Вот примеры из литературы, вот данные, вот факты. Самые страшные грехи — сокрытие/искажение правды и неприятие фактов.
Все три этики конфликтуют между собой, но все они нужны организации, иначе наступает дисфункция.
А кроме ролей есть ещё функции (классы): маги, жрецы и воины.
В компании нужны все расы и все классы. Они балансируют друг-друга. Когда маги зарубаются с воинами, нужен жрец, который им напомнит, зачем мы все здесь. Когда тролли подкидывают идею магам, нужен гном, чтобы сделать на этом деньги.
Как вам метафора? Встречали этих персонажей на работе?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤23😁13🔥5🤔1💯1
Для лидов-аналитиков контента почему-то мало, попробую разбавить. Будет пост для лидов.
Основная забота лидов — конечно, отслеживать производительность. Одновременно поддерживать командный дух и вообще хорошее самочувствие (well-being).
Для разработчиков есть много фреймворков для оценки и производительности, и самочувствия, и других факторов. Есть DORA, SPACE, DevEx, а самый новый, 2025 года, объединивший их все — DX Core 4
Я (с помощью ИИ) попробовал адаптировать DX Core 4 для системных аналитиков. Вот что получилось.
Фреймворк состоит из четырех блоков:
1. Скорость
2. Эффективность
3. Качество
4. Влияние
Скорость
Главная метрика: производительность, объем поставок — сколько аналитических артефактов передается разработчикам в неделю / месяц (смотря какие у вас характерные скорости). Это общая метрика на подразделения / гильдии, ни в коем случае не персональная!
Вторичные метрики:
- Скорость прохождения требований: Сколько времени в среднем проходит от постановки задачи до передачи итогового артефакта разработчикам. Так как задачи бывают очень разного объема и их сложно сравнивать, тут можно ввести категоризацию по масштабу (но не сильно сложную, .
- Скорость согласования требований со стейкхолдерами (среднее время полного цикла согласования)
- Воспринимаемая скорость поставки (оценочно, как аналитикам кажется: быстро они сдают свои артефакты?)
Эффективность
Главная метрика комплексная: AXI, Analyst Experience Index, Индекс опыта аналитика
Собираем индивидуальные оценки удовлетворенности от каждого аналитика по шкале от "Совершенно не удовлетворен" до "Вполне удовлетворен"
Компоненты AXI:
- Доступ к стейкхолдерам и экспертам предметной области
- Качество имеющейся документации
- Инструменты моделирования и анализа
- Процессы ревью требований
- Взаимодействие с другими командами и ролями
- Ясность целей и задач бизнеса
- Наличие времени на глубокую проработку (против контекстных переключений)
- Процессы управления изменением требований
- Доступ к данным для анализа
Дополнительные метрики:
- Время до 10-го сданного артефакта (для новых аналитиков)
- Легкость сбора требований (субъективная)
- Частота ухода ценных аналитиков из организации / команды
Качество
Ключевая метрика: уровень дефектов требований. Доля требований, потребовавших дополнительных уточнений или переделывания после передачи в разработку.
Вторичные метрики:
- Доля пропущенных требований (обнаруженных уже в процессе разработки/тестирования)
- Удовлетворенность стейкхолдеров взаимодействием с аналитиками
- Доля переделок в коде из-за ошибок анализа
- Актуальность документации / архитектурных схем и т.п.
Влияние (Импакт)
Главная метрика: Доля времени, потраченная на принципиально новые функции (в отличии от времени на некоторое улучшение существующих функций или отработки дефектов)
Дополнительные метрики:
- Среднее соотношение времени на анализ и на разработку для одной единицы функциональности (пользовательской истории, фичи)
- Ценность для бизнеса в пересчете на аналитика (очень сложно посчитать, тут если только вы считаете ROI конкретной фичи)
- Соотношение выпущенных фичей (если у вас бывает, что аналитик работает "в стол")
Как это применять: ну, в идеале, должна быть триангуляция, то есть получение объективных данных (из систем), субъективных (опросных), и взгляда с другой стороны (стейкхолдеры, разработчики).
На практике можно для начала провести опрос, чтобы понять базовые значения, с которых стартуем. Вот ссылка на заготовку для опросов.
Главное, нужно следовать нескольким правилам:
1. Это не оценка людей, это оценка процессов
2. Чинить нужно одну вещь за один раз (за квартал, например)
3. Метрики работают только вместе (чтобы не ухудшать одну метрику за счет других)
Вот такой инструмент, как вам? Я бы с большим интересом поговорил про опыт внедрения!
Основная забота лидов — конечно, отслеживать производительность. Одновременно поддерживать командный дух и вообще хорошее самочувствие (well-being).
Для разработчиков есть много фреймворков для оценки и производительности, и самочувствия, и других факторов. Есть DORA, SPACE, DevEx, а самый новый, 2025 года, объединивший их все — DX Core 4
Я (с помощью ИИ) попробовал адаптировать DX Core 4 для системных аналитиков. Вот что получилось.
Фреймворк состоит из четырех блоков:
1. Скорость
2. Эффективность
3. Качество
4. Влияние
Скорость
Главная метрика: производительность, объем поставок — сколько аналитических артефактов передается разработчикам в неделю / месяц (смотря какие у вас характерные скорости). Это общая метрика на подразделения / гильдии, ни в коем случае не персональная!
Вторичные метрики:
- Скорость прохождения требований: Сколько времени в среднем проходит от постановки задачи до передачи итогового артефакта разработчикам. Так как задачи бывают очень разного объема и их сложно сравнивать, тут можно ввести категоризацию по масштабу (но не сильно сложную, .
- Скорость согласования требований со стейкхолдерами (среднее время полного цикла согласования)
- Воспринимаемая скорость поставки (оценочно, как аналитикам кажется: быстро они сдают свои артефакты?)
Эффективность
Главная метрика комплексная: AXI, Analyst Experience Index, Индекс опыта аналитика
Собираем индивидуальные оценки удовлетворенности от каждого аналитика по шкале от "Совершенно не удовлетворен" до "Вполне удовлетворен"
Компоненты AXI:
- Доступ к стейкхолдерам и экспертам предметной области
- Качество имеющейся документации
- Инструменты моделирования и анализа
- Процессы ревью требований
- Взаимодействие с другими командами и ролями
- Ясность целей и задач бизнеса
- Наличие времени на глубокую проработку (против контекстных переключений)
- Процессы управления изменением требований
- Доступ к данным для анализа
Дополнительные метрики:
- Время до 10-го сданного артефакта (для новых аналитиков)
- Легкость сбора требований (субъективная)
- Частота ухода ценных аналитиков из организации / команды
Качество
Ключевая метрика: уровень дефектов требований. Доля требований, потребовавших дополнительных уточнений или переделывания после передачи в разработку.
Вторичные метрики:
- Доля пропущенных требований (обнаруженных уже в процессе разработки/тестирования)
- Удовлетворенность стейкхолдеров взаимодействием с аналитиками
- Доля переделок в коде из-за ошибок анализа
- Актуальность документации / архитектурных схем и т.п.
Влияние (Импакт)
Главная метрика: Доля времени, потраченная на принципиально новые функции (в отличии от времени на некоторое улучшение существующих функций или отработки дефектов)
Дополнительные метрики:
- Среднее соотношение времени на анализ и на разработку для одной единицы функциональности (пользовательской истории, фичи)
- Ценность для бизнеса в пересчете на аналитика (очень сложно посчитать, тут если только вы считаете ROI конкретной фичи)
- Соотношение выпущенных фичей (если у вас бывает, что аналитик работает "в стол")
Как это применять: ну, в идеале, должна быть триангуляция, то есть получение объективных данных (из систем), субъективных (опросных), и взгляда с другой стороны (стейкхолдеры, разработчики).
На практике можно для начала провести опрос, чтобы понять базовые значения, с которых стартуем. Вот ссылка на заготовку для опросов.
Главное, нужно следовать нескольким правилам:
1. Это не оценка людей, это оценка процессов
2. Чинить нужно одну вещь за один раз (за квартал, например)
3. Метрики работают только вместе (чтобы не ухудшать одну метрику за счет других)
Вот такой инструмент, как вам? Я бы с большим интересом поговорил про опыт внедрения!
1👍20❤11🔥1🥴1
Мой менти столкнулся с проблемой, которую не знаю, как быстро решить. Возможно, вы тоже с таким встречались. По-английски называется "Игра принеси-мне-камень" (Bring me a rock), прием психологического насилия, когда человек просит принести камень, вы ему приносите, а он говорит — нет, это не такой камень. А какой нужен? Не знаю, ты принеси, посмотрю — скажу.
Раньше в такую игру любили поиграть заказчики — "ой, ну тут что-то не то... а что не то, мы не знаем..." — но теперь мы столкнулись с игрой со стороны разработчиков. Выглядит так: ну, вы тут напридумывали, здорово, но мы так сделать не можем. Давайте как-нибудь по-другому. А как по-другому? Не знаем, вы же с пользователями общаетесь. Так мы точно не сможем сделать. Принесите камень, который нам подойдет.
Есть множество статей на эту тему, с общим посылом: это игра, в которой единственный способ выиграть — не играть вообще. К сожалению, мы не можем выйти из игры и перестать работать с этой командой (ну, или можем — выход есть всегда, в том числе из компании). Остается что: 1) пытаться договориться с разработчиками и 2) эскалировать на руководителя. Эскалация сработает, если у вас в принципе выстроен механизм медиации, если руководители уделяют внимание психологической обстановке, пресекают буллинг и работают с установками работников.
Вариант "договориться" — это если разработчики готовы договариваться. Исходим из того, что у всех нас одна общая цель, нет конкуренции между аналитиками и разработчиками, нет каких-то политических игр и подстав. Тут может быть всякое — аналитики и разработчики могут вообще подчиняться разным руководителям (я видел варианты, что даже разным C-level: аналитики — директору по технологиям, а разработчики — техническому, и их конкуренция транслируется до рядовых исполнителей), аналитики могут постоянно меняться и команде не понравился конкретный аналитик и т.д. Тут проблема не техническая, но парадоксальным образом иногда решение оптимальнее искать вне координат проблемы: если проблема политическая, то решение должно быть техническим, и наоборот. Это вообще полезное правило — неразрешимое противоречие в одной системе координат нужно решать в другом измерении.
Допустим, у всех одна искренняя цель, но сделать мы так не можем. А как можем, мы сами не знаем. Тут нужно заметить, что фраза "мы так сделать не можем" очень часто означает "мы так делать не хотим, потому что..." и вот тут возможны варианты:
* сделать можно, очень много переделывать, но на задачу отведено мало времени и есть риск что-то упустить
* сделать можно, но это будет очередной костыль (архитектура уже давно не соответствует потребностям бизнеса, но времени и ресурсов на рефакторинг так же давно не выделялись)
* сделать можно, но придется отказаться от готового компонента (и нести в дальнейшем риски и тратить ресурсы на развитие)
* сделать можно, но это выглядит, как ультра-локальное изменение и частный случай, который больше нигде и никогда не получится использовать
* сделать можно, но очевидное решение будет сильно нагружать бэк/фронт, или будет слишком медленным. Возможно, тут чисто математическая сложность.
Всё это можно "вскрыть", если действовать осторожно и не идти на конфликт. И если разработчики готовы говорить откровенно, а не ты дурак, ничего не понимаешь, мы так и думали, аналитики бесполезны.
Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить?
Ну и рассчитывал бы на сессию совместного проектирования. А вот цикл "вот вам постановка - мы так не можем" обычно ни к чему хорошему не приводит, только к выгоранию аналитика.
Раньше в такую игру любили поиграть заказчики — "ой, ну тут что-то не то... а что не то, мы не знаем..." — но теперь мы столкнулись с игрой со стороны разработчиков. Выглядит так: ну, вы тут напридумывали, здорово, но мы так сделать не можем. Давайте как-нибудь по-другому. А как по-другому? Не знаем, вы же с пользователями общаетесь. Так мы точно не сможем сделать. Принесите камень, который нам подойдет.
Есть множество статей на эту тему, с общим посылом: это игра, в которой единственный способ выиграть — не играть вообще. К сожалению, мы не можем выйти из игры и перестать работать с этой командой (ну, или можем — выход есть всегда, в том числе из компании). Остается что: 1) пытаться договориться с разработчиками и 2) эскалировать на руководителя. Эскалация сработает, если у вас в принципе выстроен механизм медиации, если руководители уделяют внимание психологической обстановке, пресекают буллинг и работают с установками работников.
Вариант "договориться" — это если разработчики готовы договариваться. Исходим из того, что у всех нас одна общая цель, нет конкуренции между аналитиками и разработчиками, нет каких-то политических игр и подстав. Тут может быть всякое — аналитики и разработчики могут вообще подчиняться разным руководителям (я видел варианты, что даже разным C-level: аналитики — директору по технологиям, а разработчики — техническому, и их конкуренция транслируется до рядовых исполнителей), аналитики могут постоянно меняться и команде не понравился конкретный аналитик и т.д. Тут проблема не техническая, но парадоксальным образом иногда решение оптимальнее искать вне координат проблемы: если проблема политическая, то решение должно быть техническим, и наоборот. Это вообще полезное правило — неразрешимое противоречие в одной системе координат нужно решать в другом измерении.
Допустим, у всех одна искренняя цель, но сделать мы так не можем. А как можем, мы сами не знаем. Тут нужно заметить, что фраза "мы так сделать не можем" очень часто означает "мы так делать не хотим, потому что..." и вот тут возможны варианты:
* сделать можно, очень много переделывать, но на задачу отведено мало времени и есть риск что-то упустить
* сделать можно, но это будет очередной костыль (архитектура уже давно не соответствует потребностям бизнеса, но времени и ресурсов на рефакторинг так же давно не выделялись)
* сделать можно, но придется отказаться от готового компонента (и нести в дальнейшем риски и тратить ресурсы на развитие)
* сделать можно, но это выглядит, как ультра-локальное изменение и частный случай, который больше нигде и никогда не получится использовать
* сделать можно, но очевидное решение будет сильно нагружать бэк/фронт, или будет слишком медленным. Возможно, тут чисто математическая сложность.
Всё это можно "вскрыть", если действовать осторожно и не идти на конфликт. И если разработчики готовы говорить откровенно, а не ты дурак, ничего не понимаешь, мы так и думали, аналитики бесполезны.
Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить?
Ну и рассчитывал бы на сессию совместного проектирования. А вот цикл "вот вам постановка - мы так не можем" обычно ни к чему хорошему не приводит, только к выгоранию аналитика.
❤25👍13👌3😁2
Раз уж я блогер, должен реагировать на хайповые темы. Даже и с запозданием. Ладно, я всё пропустил. Но всё равно, вот вам: группа Angine de Poitrine. Переводится как "Боль за грудиной" или "Стенокардия". Ребята умудрились в эпоху тотального нейрослопа сделать что-то настолько неожиданное, что никакой нейросети с самой высокой температурой не приснится.
По форме это "экспериментальный микротоновый математический рок с элементами костюмированного перформанса". И это меня прямо вернуло на 25 лет назад, когда я активно программировал, и, конечно, делал это под музыку.
Итак, неожиданный пост про фоновую музыку для работы.
На созвонах фоновой музыки обычно не бывает. Хотя интересно было бы представить — вот ваш типичный созвон, какую бы музыку вы к нему подобрали?..
А когда мы сосредоточенно работаем над чем-то, будь то код, диаграмма или документ, музыка помогает или мешает? При программировании у меня почти всегда что-то играло на фоне. И почти всегда это было что-то хитрое с музыкальной точки зрения. И это не снобизм, а насущная необходимость! Прямые биты с размером 4/4 в сочетании с однообразной работой меня укачивают, и уже через короткое время я засыпаю, причем скорость не важна — монотонный хардкор или транс тоже усыпляют, если под них не танцевать или вести машину на высокой скорости (а если танцевать — вгоняют в тот самый транс).
В общем, это всё не то — фоновая музыка должна не усыплять, а наоборот обострять чувства и стимулировать мозг.
Поэтому мой набор для программирования в начале 2000-х был весьма диковат: Сергей Курехин, John Zorn, Les Hurlements d’Leo, Eläkeläiset, саундтрек "Бойцовского клуба", который The Dust Brothers, их последователи The Chemical Brothers и прочий брейк-бит, The Prodigy, Lemon Jelly, Эдуард Артемьев, Skanatra и т.д. Видите какую-нибудь логику? Я вот тоже сначала нет, а теперь понимаю: основное свойство — неожиданность. Неожиданность тут двух типов: музыкальная (необычные размеры, ломанный бит, сваливание чуть ли не в чистый шум — ой, это я ещё про japanoise забыл написать, Merzbow, Masonna, The Gerogerigegege — тоже было!), либо культурная — различные перепевки, каверы и прочая культурная мешанина.
Ну и микротональная музыка Angine de Poitrine из этой же серии — микротоны, это же звуки с интервалами вне европейского равномерно темперированного строя, то есть ноты, которые "между" соседних клавиш на фортепьяно или "внутри" ладов на гитаре (у Khn de Poitrine на грифах гитары вдвое больше ладов, чем обычно). Чаще всего это звучит для нашего уха фальшиво, но тут всё получилось.
Короче, тут чистая математика — нарезка диапазона частот на необычные ноты, и применение странных ритмических размеров, далеких от 4/4: 7/8, 11/8 и т.п. И даже если убрать микротоны, это математический рок, mathrock — рок со странными размерами и их сменой внутри одной композиции. А уж этого мат-рока очень много (особенно почему-то много японского мат-рока, даже с вокалом). И это у меня теперь будет базовой музыкой для фоновой работы, а то всё предыдущее я уже наизусть.
В чем тут фишка? Это всё про дофаминовую стимуляцию. Дофамин — гормон радости ожидания нового. При программировании он и так вырабатывается, потому что ты ждешь, что оно заработает, а оно не работает, а потом как заработало! Выплеск дофамина. Главная фишка для выработки дофамина — неожиданность. Когда результат известен — награды не будет. Когда есть только шанс получить что-то интересное (или ещё более интересное!) — работает дофамин. Этот гормон стимулирует интерес и обучение. Но только в условиях безопасности, иначе он сразу перебивается адреналином! Дофаминовый транс или "состояние потока" заставляет программистов писать лучший код, а аналитиков — лучшие документы. Math-rock с неожиданными и меняющимися ритмами делает мозгу щекотно как раз за счет промахов в ожидании следующей ноты: думал, сейчас будет очередная доля? А нет! Получи выброс дофамина!
Вот такой музыкальный биохакинг.
По форме это "экспериментальный микротоновый математический рок с элементами костюмированного перформанса". И это меня прямо вернуло на 25 лет назад, когда я активно программировал, и, конечно, делал это под музыку.
Итак, неожиданный пост про фоновую музыку для работы.
На созвонах фоновой музыки обычно не бывает. Хотя интересно было бы представить — вот ваш типичный созвон, какую бы музыку вы к нему подобрали?..
А когда мы сосредоточенно работаем над чем-то, будь то код, диаграмма или документ, музыка помогает или мешает? При программировании у меня почти всегда что-то играло на фоне. И почти всегда это было что-то хитрое с музыкальной точки зрения. И это не снобизм, а насущная необходимость! Прямые биты с размером 4/4 в сочетании с однообразной работой меня укачивают, и уже через короткое время я засыпаю, причем скорость не важна — монотонный хардкор или транс тоже усыпляют, если под них не танцевать или вести машину на высокой скорости (а если танцевать — вгоняют в тот самый транс).
В общем, это всё не то — фоновая музыка должна не усыплять, а наоборот обострять чувства и стимулировать мозг.
Поэтому мой набор для программирования в начале 2000-х был весьма диковат: Сергей Курехин, John Zorn, Les Hurlements d’Leo, Eläkeläiset, саундтрек "Бойцовского клуба", который The Dust Brothers, их последователи The Chemical Brothers и прочий брейк-бит, The Prodigy, Lemon Jelly, Эдуард Артемьев, Skanatra и т.д. Видите какую-нибудь логику? Я вот тоже сначала нет, а теперь понимаю: основное свойство — неожиданность. Неожиданность тут двух типов: музыкальная (необычные размеры, ломанный бит, сваливание чуть ли не в чистый шум — ой, это я ещё про japanoise забыл написать, Merzbow, Masonna, The Gerogerigegege — тоже было!), либо культурная — различные перепевки, каверы и прочая культурная мешанина.
Ну и микротональная музыка Angine de Poitrine из этой же серии — микротоны, это же звуки с интервалами вне европейского равномерно темперированного строя, то есть ноты, которые "между" соседних клавиш на фортепьяно или "внутри" ладов на гитаре (у Khn de Poitrine на грифах гитары вдвое больше ладов, чем обычно). Чаще всего это звучит для нашего уха фальшиво, но тут всё получилось.
Короче, тут чистая математика — нарезка диапазона частот на необычные ноты, и применение странных ритмических размеров, далеких от 4/4: 7/8, 11/8 и т.п. И даже если убрать микротоны, это математический рок, mathrock — рок со странными размерами и их сменой внутри одной композиции. А уж этого мат-рока очень много (особенно почему-то много японского мат-рока, даже с вокалом). И это у меня теперь будет базовой музыкой для фоновой работы, а то всё предыдущее я уже наизусть.
В чем тут фишка? Это всё про дофаминовую стимуляцию. Дофамин — гормон радости ожидания нового. При программировании он и так вырабатывается, потому что ты ждешь, что оно заработает, а оно не работает, а потом как заработало! Выплеск дофамина. Главная фишка для выработки дофамина — неожиданность. Когда результат известен — награды не будет. Когда есть только шанс получить что-то интересное (или ещё более интересное!) — работает дофамин. Этот гормон стимулирует интерес и обучение. Но только в условиях безопасности, иначе он сразу перебивается адреналином! Дофаминовый транс или "состояние потока" заставляет программистов писать лучший код, а аналитиков — лучшие документы. Math-rock с неожиданными и меняющимися ритмами делает мозгу щекотно как раз за счет промахов в ожидании следующей ноты: думал, сейчас будет очередная доля? А нет! Получи выброс дофамина!
Вот такой музыкальный биохакинг.
❤23❤🔥2👍2🔥2👏2
Ещё из актуального: в отличие от некоторых школ, которые считают нормальным в конце года просто оповестить смской учащихся и педагогов о закрытии одним днем и отправить всех в комиссию по банкротству в Делавэре, Systems.Education доводит все дела до конца.
Завтра завершается последний поток трёхмесячного интенсива Systems Analyst Bootcamp, и можно посетить открытое финальное демо.
Там можно увидеть презентацию команд, оценить результаты и задать вопросы. И присмотреть себе аналитиков, если вам нужны в команду джуны+ / почти миддлы.
Обучались они вот по этой программе.
Порядок проведения демо - по ссылке.
Финальное демо пройдёт в онлайн-формате 6 и 7 мая с 18:00 до 20:00 МСК
Будем рады вашему присутствию!
Запиcываться через @systemseducation
Завтра завершается последний поток трёхмесячного интенсива Systems Analyst Bootcamp, и можно посетить открытое финальное демо.
Там можно увидеть презентацию команд, оценить результаты и задать вопросы. И присмотреть себе аналитиков, если вам нужны в команду джуны+ / почти миддлы.
Обучались они вот по этой программе.
Порядок проведения демо - по ссылке.
Финальное демо пройдёт в онлайн-формате 6 и 7 мая с 18:00 до 20:00 МСК
Будем рады вашему присутствию!
Запиcываться через @systemseducation
👍5🔥2❤1
Я тут немного учусь на "настоящего управленца" (бесит это слово, честно говоря), и вот что наблюдаю.
Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово.
Но масса организаций работают безо всяких процессов или проектов, а управление осуществляется путем поручений. То есть, работник сидит и ждет, когда ему что-то поручат делать. Поручили — делает, не поручили — сидит дальше. И выполняет не конкретный процесс, а поручение руководителя. Основной деятельностью в такой системе является получение поручений и документов сверху и расписывание их на исполнителей. Ну и контроль потом. Но много где нет и этого, а поручения выдаются устно, слабо контролируются, а процесс исполнения даже типовых поручений придумывается каждый раз заново.
И вот тут второе: что делает руководитель в таких системах? Интересное дело: в основном работает с мотивацией. Потому что в процессах можно поставить KPI и измерять какие-то показатели, оптимизировать шаги. А если у вас управление по поручениям, то ваша основная метрика — своевременное исполнение. Точнее: 1) исполнение в принципе и 2) исполнение в срок. И тут нужно как-то людьми манипулировать, чтобы они всё это делали (а они обычно не хотят, потому что нет смысла — не видно какой-то великой цели, сплошное реагирование и тушение пожаров).
Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя.
То есть, получается, что человек знает очень много о себе: как он принимает решения, на что реагирует, в чем имеет сильные стороны, а где слаб. И то же самое знает про своих сотрудников и про своих контрагентов (или про своих руководителей). И, соответственно, умеет подобрать правильные подходы ко всем и в любой ситуации. Я писал про тетраграмматон Кулакова — это же та же схема: типирование + рекомендации лидеру, что делать (вставать в уравновешивающую позицию — если у вас в команде сплошные тролли и эльфы, вам нужно действовать, как гном, и строить продажи).
Один мой знакомый постоянно именно этим занимается, причем тратит довольно большие деньги на серьезные коммерческие тесты (тестирует себя) и даже сертифицировался для проведения диагностики (чтобы исследовать свою команду), потом загоняет эту информацию в ИИ, вместе с описанием коллег и руководителей, и гоняет в ИИ до посинения сценарии развития событий, диалогов, реакций на возможные действия. Я немного скептически относился к такому развлечению, но, послушав с десяток действующих руководителей разных организаций — впрочем, в основном образовательных — уже стал думать, что что-то в этом есть.
То есть, если вы руководитель или лид команды, вы должны постоянно этим заниматься — досконально знать себя, своих людей, окружающих людей, среду в вашей команде, среду в организации, и всё это постоянно учитывать (а часто ещё и менять). А не "выстраивать процессы", как часто говорят.
Знаете ли вы себя и команду?
Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово.
Но масса организаций работают безо всяких процессов или проектов, а управление осуществляется путем поручений. То есть, работник сидит и ждет, когда ему что-то поручат делать. Поручили — делает, не поручили — сидит дальше. И выполняет не конкретный процесс, а поручение руководителя. Основной деятельностью в такой системе является получение поручений и документов сверху и расписывание их на исполнителей. Ну и контроль потом. Но много где нет и этого, а поручения выдаются устно, слабо контролируются, а процесс исполнения даже типовых поручений придумывается каждый раз заново.
И вот тут второе: что делает руководитель в таких системах? Интересное дело: в основном работает с мотивацией. Потому что в процессах можно поставить KPI и измерять какие-то показатели, оптимизировать шаги. А если у вас управление по поручениям, то ваша основная метрика — своевременное исполнение. Точнее: 1) исполнение в принципе и 2) исполнение в срок. И тут нужно как-то людьми манипулировать, чтобы они всё это делали (а они обычно не хотят, потому что нет смысла — не видно какой-то великой цели, сплошное реагирование и тушение пожаров).
Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя.
То есть, получается, что человек знает очень много о себе: как он принимает решения, на что реагирует, в чем имеет сильные стороны, а где слаб. И то же самое знает про своих сотрудников и про своих контрагентов (или про своих руководителей). И, соответственно, умеет подобрать правильные подходы ко всем и в любой ситуации. Я писал про тетраграмматон Кулакова — это же та же схема: типирование + рекомендации лидеру, что делать (вставать в уравновешивающую позицию — если у вас в команде сплошные тролли и эльфы, вам нужно действовать, как гном, и строить продажи).
Один мой знакомый постоянно именно этим занимается, причем тратит довольно большие деньги на серьезные коммерческие тесты (тестирует себя) и даже сертифицировался для проведения диагностики (чтобы исследовать свою команду), потом загоняет эту информацию в ИИ, вместе с описанием коллег и руководителей, и гоняет в ИИ до посинения сценарии развития событий, диалогов, реакций на возможные действия. Я немного скептически относился к такому развлечению, но, послушав с десяток действующих руководителей разных организаций — впрочем, в основном образовательных — уже стал думать, что что-то в этом есть.
То есть, если вы руководитель или лид команды, вы должны постоянно этим заниматься — досконально знать себя, своих людей, окружающих людей, среду в вашей команде, среду в организации, и всё это постоянно учитывать (а часто ещё и менять). А не "выстраивать процессы", как часто говорят.
Знаете ли вы себя и команду?
💯13🤔7❤3😢3🔥1
Вынесу из комментов: я тут нашел хорошую таблицу, связывающую проектное и процессное управление. Это стандарт P3M3, часть PRINCE2.
Почему-то многие считают, что проектное управление предшествует процессному. Продолжая предыдущий пост, зачастую организации пытаются перейти к проектному управлению от управления по поручениям.
Ну а что: проект — это же просто набор поручений! (Задач).
А процессы — это что-то сложное и непонятно.
А потом, конечно, они спрашивают — а почему это у нас проекты как-то плохо запускаются? А завершаются ещё хуже?..
А потому что ваши проекты опираются на хаотическую деятельность, ad-hoc. Или, того хуже, на героическую. Когда каждый проект вытаскивают отдельные герои, в отсутствие ресурсов и поддержки. Главное, это же очень удобно — зачем налаживать управление, если каждый раз находятся герои, которые и так смогут. Культура постоянного подвига. (Если кому-то пришлось совершить подвиг, значит до этого кто-то другой плохо выполнил свою работу. Всегда!)
Я тут критиковал процессный подход, но в случае проектной деятельности именно установленные процессы должны стать опорой для проектов. Нет процессов = нет стабильной и предсказуемой проектной деятельности. Если вы читали PMBoK — там исключительно процессы описываются, это стандарт в процессной логике.
Обратите также внимание, с какого уровня начинается управление процессами. С 4-го, предпоследнего! До этого ничем управлять невозможно, можно только руководить (в смысле микроменеджмента). А системно оптимизировать процессы можно только на пятом уровне зрелости!
У организации, как у человека, есть зона ближайшего развития. Вы не можете перейти от хаоса к оптимизации*, не пройдя промежуточные шаги! У меня когда-то один студент писал диплом по управлению требованиями, и вывел там ФОРМУЛУ: 5-2=3. Если организация находится на 2 уровне зрелости, и собирается оптимизировать управление требованиями, ей нужно пройти ещё три уровня. По-другому никак!
Поэтому, пожалуйста, будьте осторожны со словом "оптимизировать", учитывайте промежуточные состояния. Возможно, сначала вам нужно будет разобраться с такими словами, как "определить", "внедрить" и "измерить".
* впрочем, есть теория хаоса и понятие странных аттракторов, но это совсем другая математика (и картина мира) и другой способ управления. И ещё одна метафора организации, кстати.
Почему-то многие считают, что проектное управление предшествует процессному. Продолжая предыдущий пост, зачастую организации пытаются перейти к проектному управлению от управления по поручениям.
Ну а что: проект — это же просто набор поручений! (Задач).
А процессы — это что-то сложное и непонятно.
А потом, конечно, они спрашивают — а почему это у нас проекты как-то плохо запускаются? А завершаются ещё хуже?..
А потому что ваши проекты опираются на хаотическую деятельность, ad-hoc. Или, того хуже, на героическую. Когда каждый проект вытаскивают отдельные герои, в отсутствие ресурсов и поддержки. Главное, это же очень удобно — зачем налаживать управление, если каждый раз находятся герои, которые и так смогут. Культура постоянного подвига. (Если кому-то пришлось совершить подвиг, значит до этого кто-то другой плохо выполнил свою работу. Всегда!)
Я тут критиковал процессный подход, но в случае проектной деятельности именно установленные процессы должны стать опорой для проектов. Нет процессов = нет стабильной и предсказуемой проектной деятельности. Если вы читали PMBoK — там исключительно процессы описываются, это стандарт в процессной логике.
Обратите также внимание, с какого уровня начинается управление процессами. С 4-го, предпоследнего! До этого ничем управлять невозможно, можно только руководить (в смысле микроменеджмента). А системно оптимизировать процессы можно только на пятом уровне зрелости!
У организации, как у человека, есть зона ближайшего развития. Вы не можете перейти от хаоса к оптимизации*, не пройдя промежуточные шаги! У меня когда-то один студент писал диплом по управлению требованиями, и вывел там ФОРМУЛУ: 5-2=3. Если организация находится на 2 уровне зрелости, и собирается оптимизировать управление требованиями, ей нужно пройти ещё три уровня. По-другому никак!
Поэтому, пожалуйста, будьте осторожны со словом "оптимизировать", учитывайте промежуточные состояния. Возможно, сначала вам нужно будет разобраться с такими словами, как "определить", "внедрить" и "измерить".
* впрочем, есть теория хаоса и понятие странных аттракторов, но это совсем другая математика (и картина мира) и другой способ управления. И ещё одна метафора организации, кстати.
🔥10❤🔥3❤1👍1💯1
Здесь мог быть остроумный кликбейт
Но не будем тратить время. Приглашаем на последний поток программы Интеграция и архитектура систем для аналитиков, которую проведет Андрей Бураков (ex-NextWay).
Кому полезно:
• Хотите перейти в архитектуру, но задачи на работе не дают развиваться
• Изучили кучу материалов про архитектуру и паттерны, но в голове осталась каша
• Ищите работу, но пугают System Design секции
Чему научитесь:
• Осознанно использовать технологии интеграции: Message Brokers, REST, RPC, WebSockets, GraphQL
• Выбирать подходящие хранилища данных (микро)сервисов: реляционные, NoSQL, NewSQL
• Уместно использовать архитектурные паттерны, для обеспечения производительности, масштабируемости, отказоустойчивости систем
• Разберетесь в инфраструктуре для деплоя и управления сервисами в промышленных средах: Docker, Kubernetes, Service Mesh
📆 13 мая — 21 июня, каждую среду и воскресенье
🔗 Смотрите подробности и регистрируйтесь на сайте
Реклама. ИП Бураков Андрей Олегович
ИНН 632133429581
Но не будем тратить время. Приглашаем на последний поток программы Интеграция и архитектура систем для аналитиков, которую проведет Андрей Бураков (ex-NextWay).
Кому полезно:
• Хотите перейти в архитектуру, но задачи на работе не дают развиваться
• Изучили кучу материалов про архитектуру и паттерны, но в голове осталась каша
• Ищите работу, но пугают System Design секции
Чему научитесь:
• Осознанно использовать технологии интеграции: Message Brokers, REST, RPC, WebSockets, GraphQL
• Выбирать подходящие хранилища данных (микро)сервисов: реляционные, NoSQL, NewSQL
• Уместно использовать архитектурные паттерны, для обеспечения производительности, масштабируемости, отказоустойчивости систем
• Разберетесь в инфраструктуре для деплоя и управления сервисами в промышленных средах: Docker, Kubernetes, Service Mesh
🔗 Смотрите подробности и регистрируйтесь на сайте
Реклама. ИП Бураков Андрей Олегович
ИНН 632133429581
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍2🔥2👎1
Ещё один пост про руководителей и лидов. Конечно, хочется написать именно для руководителей аналитиков, но тут первичны навыки управления, а процесс зачастую вторичен. Вся специфика бизнес- и системного анализа заключается в поиске верного места для этой функции в общей логике создания ПО. Зачем мы это делаем? Для чего мы нужны? Какую ценность мы приносим? Что без нас будет работать хуже?
А вот принципы руководства не очень сильно зависят от функции и сути деятельности, которой ты руководишь. Поэтому профессиональные управленцы довольно легко могут переходить из одной предметной области в другую, особенно если им хватает ума не залезать в конкретную технологию работы и не пытаться в ней что-то менять.
Самый лучший вариант, конечно, на стыке: понимать и в управлении, и в технологии. Это такое же сильное сочетание, как понимание технологии и ИТ, или ИТ и бизнеса.
Но я хотел написать про чистое управление. Я наконец дослушал курс "История бюрократии", и кое-что из него извлек. (Стоит заметить, что курс про государственное управление, и это, конечно, не то же самое, что управление организацией. Но это ещё одна метафора — организация, как государство. Кроме того, нужно учитывать, что государства у нас практически всегда начинают с персонального управления, это тоже накладывает определенную оптику).
Итак, что мы можем полезного извлечь из уроков гос.управления (что прослеживается во многих государствах и системах):
1. Первое, что нужно сделать — перепись. Для государства это связано со сбором налогов, а для руководителя организации — с пониманием ресурсов, которыми он располагает. Я наблюдал несколько раз смену руководителей или объединение организаций, и опытные люди всегда начинают с этого. Что мы имеем? Что нам оставил предшественник? Ещё это очень важно, чтобы зафиксировать точку "0" — с чего мы стартуем, и отделить унаследованные косяки от наших собственных. Так что одним из результатов "переписи" должен быть список проблем, уже имеющихся на момент принятия вами руководства.
2. Второе — сохранение и опора на существующую организацию (в курсе — аристократию). Не надо ссориться, нужно встроить имеющихся людей в свою систему. Не свергать князей, а выдавать им ярлыки :)
3. Но если вы хотите что-то всерьез поменять — стройте параллельные управленческие структуры из новых людей. Какие-нибудь временные комитеты, комиссии, советы; отлично тут работают проекты. Главное — выдернуть людей из существующей структуры и наделить чрезвычайными полномочиями, лучше всего — максимально неопределенными!. Я работал на многих проектах в кризисе, и это то, что всегда делают антикризисные менеджеры — создают параллельные структуры со специальными полномочиями и подотчетностью первому лицу (или вообще совету директоров). Часто приводят с собой варягов, не связанных с организацией. В общем, преторианская гвардия и чиновники особых поручений.
4. Для остальных нужно установить понятные правила игры: что можно, что нельзя, и как решаются конфликты. Где правда? Древнерусские установления так и назывались — Правда. Обычно они отменяли всякую дичь типа кровной мести и вводили более гуманные порядки.
5. Люди, которых вы привлекаете, должны быть лично обязаны вам и зависеть от вашего успеха. Опять же, тут отлично подходят проекты (а процессы наоборот вредят). Если у вас есть процесс и, не дай б-г, владелец этого процесса — это как поместная аристократия, наделенная землей. Сядет на этот процесс или ресурс, и будет вести себя, как его хозяин. А если у вас постоянно временные проекты, и основные деньги исходят из оплаты этих проектов — проектами владеете вы, и можете рулить этим по своему усмотрению — начинать проекты, останавливать проекты, привлекать людей к проектам (или не привлекать, пусть сидят на голой зарплате).
6*. Для придания себе дополнительной власти можно опереться на людей и группировки, которым до этого не давали голоса.
Рекомендации макиавеллианские, но это опыт поколений автократов. В демократии всё по-другому, а приведенный рецепт — это как раз инструкция по её демонтажу. Тут думайте сами — где вы и чего хотите.
А вот принципы руководства не очень сильно зависят от функции и сути деятельности, которой ты руководишь. Поэтому профессиональные управленцы довольно легко могут переходить из одной предметной области в другую, особенно если им хватает ума не залезать в конкретную технологию работы и не пытаться в ней что-то менять.
Самый лучший вариант, конечно, на стыке: понимать и в управлении, и в технологии. Это такое же сильное сочетание, как понимание технологии и ИТ, или ИТ и бизнеса.
Но я хотел написать про чистое управление. Я наконец дослушал курс "История бюрократии", и кое-что из него извлек. (Стоит заметить, что курс про государственное управление, и это, конечно, не то же самое, что управление организацией. Но это ещё одна метафора — организация, как государство. Кроме того, нужно учитывать, что государства у нас практически всегда начинают с персонального управления, это тоже накладывает определенную оптику).
Итак, что мы можем полезного извлечь из уроков гос.управления (что прослеживается во многих государствах и системах):
1. Первое, что нужно сделать — перепись. Для государства это связано со сбором налогов, а для руководителя организации — с пониманием ресурсов, которыми он располагает. Я наблюдал несколько раз смену руководителей или объединение организаций, и опытные люди всегда начинают с этого. Что мы имеем? Что нам оставил предшественник? Ещё это очень важно, чтобы зафиксировать точку "0" — с чего мы стартуем, и отделить унаследованные косяки от наших собственных. Так что одним из результатов "переписи" должен быть список проблем, уже имеющихся на момент принятия вами руководства.
2. Второе — сохранение и опора на существующую организацию (в курсе — аристократию). Не надо ссориться, нужно встроить имеющихся людей в свою систему. Не свергать князей, а выдавать им ярлыки :)
3. Но если вы хотите что-то всерьез поменять — стройте параллельные управленческие структуры из новых людей. Какие-нибудь временные комитеты, комиссии, советы; отлично тут работают проекты. Главное — выдернуть людей из существующей структуры и наделить чрезвычайными полномочиями, лучше всего — максимально неопределенными!. Я работал на многих проектах в кризисе, и это то, что всегда делают антикризисные менеджеры — создают параллельные структуры со специальными полномочиями и подотчетностью первому лицу (или вообще совету директоров). Часто приводят с собой варягов, не связанных с организацией. В общем, преторианская гвардия и чиновники особых поручений.
4. Для остальных нужно установить понятные правила игры: что можно, что нельзя, и как решаются конфликты. Где правда? Древнерусские установления так и назывались — Правда. Обычно они отменяли всякую дичь типа кровной мести и вводили более гуманные порядки.
5. Люди, которых вы привлекаете, должны быть лично обязаны вам и зависеть от вашего успеха. Опять же, тут отлично подходят проекты (а процессы наоборот вредят). Если у вас есть процесс и, не дай б-г, владелец этого процесса — это как поместная аристократия, наделенная землей. Сядет на этот процесс или ресурс, и будет вести себя, как его хозяин. А если у вас постоянно временные проекты, и основные деньги исходят из оплаты этих проектов — проектами владеете вы, и можете рулить этим по своему усмотрению — начинать проекты, останавливать проекты, привлекать людей к проектам (или не привлекать, пусть сидят на голой зарплате).
6*. Для придания себе дополнительной власти можно опереться на людей и группировки, которым до этого не давали голоса.
Рекомендации макиавеллианские, но это опыт поколений автократов. В демократии всё по-другому, а приведенный рецепт — это как раз инструкция по её демонтажу. Тут думайте сами — где вы и чего хотите.
❤7👍7🔥1