Услышал тут про интересную практику: когда бизнес-аналитики сопровождают разработку какой-то фичи до конца.
То есть, не просто выявляют и фиксируют требования, а прослеживают весь дальнейший путь: координируют проработку архитектуры и разбивку требований на задачи для отдельных команд (команды там организованы по подсистемам и платформам), отслеживают выполнение задач, участвуют в тестировании, приемке и раскатке на прод, готовят оповещения о новой фиче и обучают пользователей и поддержку, если нужно; сообщают бизнес-заказчикам о текущем статусе, решают организационные проблемы, когда где-то что-то встало, и отслеживает потом практику использования.
Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'
То есть, это такая промежуточная роль между аналитиком и продактом — вы ещё не отвечаете за успех всего продукта, но отвечаете за успех и смысл одной фичи. В отличие от роли БА — это не просто анализ, но включает в себя ещё большой кусок координации действий или даже прямого управления. В статьях упоминается, что иногда фича-оунер собирает временную команду под разработку фичи, и работает отчасти как скрам-мастер (в той части, где нужно устранять препятствия для продуктивной работы команды).
Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.
Звучит очень круто — для тех, кто стремится охватить весь процесс целиком, всё контролировать и связывать — от бизнес-целей до технических деталей.
Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.
Забавно почитать, как у программистов-"я-хочу-просто-писать-код-отстаньте-от-меня" через силу отрастают менеджерские, аналитические и продуктовые функции. Как в фильме ужасов, когда кого-то укусил монстр или кто-то что-то не то выпил. У БА-"я-хочу-просто-описывать-требования-отстаньте-от-меня" тоже что-то примерно такое же происходит. Сложно отращивать новые лапки и усики.
Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).
Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.
Как пишут на scrum.org:
Ну и когда у тебя есть эта самая Accountability — ты не просто отмахиваешься "на моем участке всё сделано, это дальше разработчики всё не так поняли", а идёшь и добиваешься значимого результата. Не всем нужно, не все могут. Но в этом и рост.
То есть, не просто выявляют и фиксируют требования, а прослеживают весь дальнейший путь: координируют проработку архитектуры и разбивку требований на задачи для отдельных команд (команды там организованы по подсистемам и платформам), отслеживают выполнение задач, участвуют в тестировании, приемке и раскатке на прод, готовят оповещения о новой фиче и обучают пользователей и поддержку, если нужно; сообщают бизнес-заказчикам о текущем статусе, решают организационные проблемы, когда где-то что-то встало, и отслеживает потом практику использования.
Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'
То есть, это такая промежуточная роль между аналитиком и продактом — вы ещё не отвечаете за успех всего продукта, но отвечаете за успех и смысл одной фичи. В отличие от роли БА — это не просто анализ, но включает в себя ещё большой кусок координации действий или даже прямого управления. В статьях упоминается, что иногда фича-оунер собирает временную команду под разработку фичи, и работает отчасти как скрам-мастер (в той части, где нужно устранять препятствия для продуктивной работы команды).
Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.
Звучит очень круто — для тех, кто стремится охватить весь процесс целиком, всё контролировать и связывать — от бизнес-целей до технических деталей.
Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.
Забавно почитать, как у программистов-"я-хочу-просто-писать-код-отстаньте-от-меня" через силу отрастают менеджерские, аналитические и продуктовые функции. Как в фильме ужасов, когда кого-то укусил монстр или кто-то что-то не то выпил. У БА-"я-хочу-просто-описывать-требования-отстаньте-от-меня" тоже что-то примерно такое же происходит. Сложно отращивать новые лапки и усики.
Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).
Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.
Как пишут на scrum.org:
Ответственность — обязательство выполнить задачу. Ответственность часто заключается в выполнении работы и создании ее результата.
Подотчетность — принятие на себя ответственности за результаты или итог работы. Готовность нести последствия и отвечать за сделанный выбор.
Ну и когда у тебя есть эта самая Accountability — ты не просто отмахиваешься "на моем участке всё сделано, это дальше разработчики всё не так поняли", а идёшь и добиваешься значимого результата. Не всем нужно, не все могут. Но в этом и рост.
❤28👍16🫡4🔥2🤔1
В посте про теорему Эрроу в комментах совершенно справедливо написали, что есть варианты, когда мы всё же можем обойтись без диктатора при голосовании.
Тут стоит заметить, что приоритизация бэклога вообще не всегда выглядит как голосование, а скорее как торг индивидуально с каждым стейкхолдером. Но иногда выглядит. Плюс — математика на то и математика, чтобы описывать модель реальности, тем более когда это касается социальных процессов.
Модели полезны тем, что дают советы по возможным действиям. Вы можете завести демократическое голосование, но тогда решение может быть неоптимальным или выборы могут зациклиться. Или вам нужно единоличное принятие решения. Или вы можете подкидывать кандидатов-"спойлеров", оттягивающих голоса у реальных альтернатив. Ни разу не слышал про такое, но математика говорит, что должно сработать: подкинуть явно непроходную фичу, но часть стейкхолдеров на неё отвлечётся и не будет возражать против нужных функций. Как легендарный атомный взрыв в фильме Гайдая — специально чтобы отвлечь внимание цензуры. (Если что, я не призываю манипулировать стейкхолдерами, хотя иногда ну очень хочется).
Теорема Эрроу выглядит настолько обескураживающей, что многие предпринимали усилия к её обходу. Например, доказано, что можно найти удовлетворяющее решение без диктатора... при бесконечном количестве избирателей! Что ж, математика иногда не очень практична.
Более реалистичный вариант предложен Дунканом Блэком в форме теоремы "медианного избирателя": если предпочтения голосующих распределены вдоль какой-то оси — в политике, например, между "левыми" и "правыми" — голосование работает без ограничений теоремы Эрроу, и диктатор не нужен (а оптимальная стратегия для кандидата — найти медиану среди предпочтений, и декларировать максимально близкую к ней позицию). В требованиях это может быть ось "безопасность"-"удобство", или "стабильность работы"-"гибкость", то есть любые разумные конфликтующие требования с возможными промежуточными состояниями.
А в книгах ещё говорится, что нужно избегать конфликтующих требований! Да совсем наоборот — нужно тщательно оберегать конфликты, иначе придётся вводить диктатуру!
Отсюда же следует, что анемичные, мало чем отличающиеся друг от друга требования тяжелее всего приоритизировать.
Тут опять вмешивается математика с уточнением, что ось распределения предпочтений должна быть только одна! В многомерном пространстве теорема медианного избирателя уже не работает.
Ну и, наконец, всем условиям теоремы Эрроу без привлечения диктатора соответствуют системы с упорядоченными оценками альтернатив (научно говоря, не ординалистские, а кардиналистские — то есть, не просто упорядоченные, а ещё и с приписанными числами или даже лингвистическими переменными "хуже", "лучше", "отлично" и т.п.)
Например, уже трёхзначаная шкала [-1,0,+1] уже лучше, чем просто упорядочивание (для большого числа избирателей, для малочисленных групп лучше использовать [-2,-1,0,+1,+2]). Недостатком тут является неустойчивость системы выборов к согласованным стратегиям голосующих и манипулируемости. Тут можно говорить об открытости и закрытости информации: знают ли участники о выборах других участников. И могут ли они менять свои голоса после того, как узнают о голосах других участников. Это всё сильно усложняет выборы, тут уже какие-то другие модели нужны (напишите мне, если знаете про них).
Я сам часто использую для оценки функций кардиналистский подход со шкалой [0,1,3,9]. Я не нашел модели, которая бы математически обосновывала такой выбор, подсмотрел у старших товарищей чисто в виде эмпирического правила. Но работает отлично!
Следующий уровень сложности — мультикритериальный выбор и аналог теоремы Эрроу в этой ситуации. Но это тема для следующих постов.
[Если вас интересует хороший обзор темы, рекомендую вот эту статью: https://plato.stanford.edu/entries/arrows-theorem/ ]
Тут стоит заметить, что приоритизация бэклога вообще не всегда выглядит как голосование, а скорее как торг индивидуально с каждым стейкхолдером. Но иногда выглядит. Плюс — математика на то и математика, чтобы описывать модель реальности, тем более когда это касается социальных процессов.
Модели полезны тем, что дают советы по возможным действиям. Вы можете завести демократическое голосование, но тогда решение может быть неоптимальным или выборы могут зациклиться. Или вам нужно единоличное принятие решения. Или вы можете подкидывать кандидатов-"спойлеров", оттягивающих голоса у реальных альтернатив. Ни разу не слышал про такое, но математика говорит, что должно сработать: подкинуть явно непроходную фичу, но часть стейкхолдеров на неё отвлечётся и не будет возражать против нужных функций. Как легендарный атомный взрыв в фильме Гайдая — специально чтобы отвлечь внимание цензуры. (Если что, я не призываю манипулировать стейкхолдерами, хотя иногда ну очень хочется).
Теорема Эрроу выглядит настолько обескураживающей, что многие предпринимали усилия к её обходу. Например, доказано, что можно найти удовлетворяющее решение без диктатора... при бесконечном количестве избирателей! Что ж, математика иногда не очень практична.
Более реалистичный вариант предложен Дунканом Блэком в форме теоремы "медианного избирателя": если предпочтения голосующих распределены вдоль какой-то оси — в политике, например, между "левыми" и "правыми" — голосование работает без ограничений теоремы Эрроу, и диктатор не нужен (а оптимальная стратегия для кандидата — найти медиану среди предпочтений, и декларировать максимально близкую к ней позицию). В требованиях это может быть ось "безопасность"-"удобство", или "стабильность работы"-"гибкость", то есть любые разумные конфликтующие требования с возможными промежуточными состояниями.
А в книгах ещё говорится, что нужно избегать конфликтующих требований! Да совсем наоборот — нужно тщательно оберегать конфликты, иначе придётся вводить диктатуру!
Отсюда же следует, что анемичные, мало чем отличающиеся друг от друга требования тяжелее всего приоритизировать.
Тут опять вмешивается математика с уточнением, что ось распределения предпочтений должна быть только одна! В многомерном пространстве теорема медианного избирателя уже не работает.
Ну и, наконец, всем условиям теоремы Эрроу без привлечения диктатора соответствуют системы с упорядоченными оценками альтернатив (научно говоря, не ординалистские, а кардиналистские — то есть, не просто упорядоченные, а ещё и с приписанными числами или даже лингвистическими переменными "хуже", "лучше", "отлично" и т.п.)
Например, уже трёхзначаная шкала [-1,0,+1] уже лучше, чем просто упорядочивание (для большого числа избирателей, для малочисленных групп лучше использовать [-2,-1,0,+1,+2]). Недостатком тут является неустойчивость системы выборов к согласованным стратегиям голосующих и манипулируемости. Тут можно говорить об открытости и закрытости информации: знают ли участники о выборах других участников. И могут ли они менять свои голоса после того, как узнают о голосах других участников. Это всё сильно усложняет выборы, тут уже какие-то другие модели нужны (напишите мне, если знаете про них).
Я сам часто использую для оценки функций кардиналистский подход со шкалой [0,1,3,9]. Я не нашел модели, которая бы математически обосновывала такой выбор, подсмотрел у старших товарищей чисто в виде эмпирического правила. Но работает отлично!
Следующий уровень сложности — мультикритериальный выбор и аналог теоремы Эрроу в этой ситуации. Но это тема для следующих постов.
[Если вас интересует хороший обзор темы, рекомендую вот эту статью: https://plato.stanford.edu/entries/arrows-theorem/ ]
Telegram
Системный сдвиг
Открытие дня — оказывается, провал коллективного принятия проектировочных решений, то, что называется "Design by Committee" — имеет строгое математическое доказательство и называется "Теорема Эрроу о диктатуре".
Это что-то вроде CAP-теоремы для выборов:…
Это что-то вроде CAP-теоремы для выборов:…
👍9👏6❤2
А у вас какой стиль принятия решений?
Задачу аналитика часто рассматривают как добывание информации для принятия решений — продактом, проджектом, архитектором, командой разработки, заказчиком. То есть, ты накопай и проанализируй, а мы выберем. Ну или выбор спихивают на аналитика тоже.
В большинстве случаев это не работает, потому что те, кому аналитик поставляет информацию, просто не умеют их принимать.
Обычно же как происходит: решения принимаются интуитивно, иррационально, искаженно (в смысле — с применением всех известных когнитивных искажений), бессистемно, ситуационно, под влиянием личностных факторов и [не]формального авторитета.
Ну или вот как на диаграмме. Про Analysis Paralysis вы наверное все слышали, а вот его противоположность — инстинктивная гибель — по-английски тоже красиво звучит: Extinct by Instinct. Это когда решения принимаются спонтанно и вообще без какого-бы то ни было обоснования.
Аналитических параличей бывает, кстати, четыре вида:
↗️ паралич методов анализа, когда мы пытаемся рассмотреть уже имеющуюся информацию ещё вот с такой стороны, и вот с такой, и вот через такую модель, и вот таким методом проанализировать. Ой, вот тут ещё можно веса поправить. А тут попробовать не через модель бизнес-процессов зайти, а сделать Event Storming. И переформулировать наши требования в виде Job-story, кажется, это лучше подойдет. А вы знаете, что бизнес-процессы можно замоделировать в виде марковского процесса?
💥 паралич возможностей, когда мы ищем всё новую и новую информацию, вскрываем всё новые кейсы и граничные ситуации (это моя фишка, люблю такое);
❓ паралич принятия решения — похож на предыдущий, но тут мы перебираем возможные решения: а можно вот так сделать, а ещё можно вот так, и вот такой ещё вариант есть, а как бы нам выбрать самый лучший. Кстати, я ещё два варианта придумал, как это можно решить. Это у заказчиков бывает, особенно когда предыдущее решение уже детально проработано;
🌩 паралич неопределенности: мы не можем двигаться дальше, потому что не знаем всех последствий решения. Давайте ещё проведем ещё одно исследование с пользователями. И заложим возможность изменения на случай смены законодательства. И учтем возможное развитие технологий. И предусмотрим уход с рынка вендора нашей шины данных.
Хотя иногда, надо признать, эти осторожные парни бывают правы!
Upd. : Вы картинку-то внимательно изучили?🧐
Задачу аналитика часто рассматривают как добывание информации для принятия решений — продактом, проджектом, архитектором, командой разработки, заказчиком. То есть, ты накопай и проанализируй, а мы выберем. Ну или выбор спихивают на аналитика тоже.
В большинстве случаев это не работает, потому что те, кому аналитик поставляет информацию, просто не умеют их принимать.
Обычно же как происходит: решения принимаются интуитивно, иррационально, искаженно (в смысле — с применением всех известных когнитивных искажений), бессистемно, ситуационно, под влиянием личностных факторов и [не]формального авторитета.
Ну или вот как на диаграмме. Про Analysis Paralysis вы наверное все слышали, а вот его противоположность — инстинктивная гибель — по-английски тоже красиво звучит: Extinct by Instinct. Это когда решения принимаются спонтанно и вообще без какого-бы то ни было обоснования.
Аналитических параличей бывает, кстати, четыре вида:
Хотя иногда, надо признать, эти осторожные парни бывают правы!
Upd. : Вы картинку-то внимательно изучили?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍21🤝8😁7
Кто лучше всех учит навыку?
Я давно знал, что самый лучший тренер/учитель — не тот, у кого больше опыта и достижений в том деле, которому он учит. Поэтому гнаться за тем, чтобы учиться у лучшего в своем деле не всегда полезно. Даже наоборот — часто бывает, что человек реально мастер, но объяснить, как он это делает, не может.
Ну просто многие вещи он уже делает на автомате, и даже не замечает, что их делает.
Но у меня был вопрос — а какими тогда качествами должен обладать хороший тренер? Именно тренер, тот, кто ставит навык деятельности. Так-то многие просто лекциями занимаются, донесением информации и иногда передачей ценностных установок, если повезет. А вот как выбрать именно тренера?
И тут недавно я получил ответ на одном занятии. Хотя, в общем, и раньше можно было додуматься.
Хороший тренер — это тот, кто разделяет деятельность, которой он учит, на минимальные составляющие, вычленяет в деятельности подопечного эти составляющие и корректирует те, что нуждаются в улучшении.
Соответственно, определить хорошего тренера (или хороший курс) можно по степени детализации той деятельности, которой он учит, в его материалах. Если у вас вся детализация работы аналитика на уровне "а сейчас напишем требования" — это примерно как в анекдоте "дорисуйте остальную сову".
Это давно известно в спорте — я вот в институте немного занимался тяжелой атлетикой, и у нас в зале висели кинограммы рывка и толчка: покадровая съемка каждого упражнения, 15-20 фото на упражнение + траектория движения грифа штанги чуть ли не по сантиметрам. А так-то кажется — ну что там, взял, поднял.
Соответственно, примерно столько мелких движений, а нюансов их выполнения — ещё больше.
И хороший тренер должен, во-первых, все их знать, а, во-вторых — уметь распознавать и корректировать, и знать, какие обычно вызывают проблемы у начинающих. Например, типичные проблемы начинающих аналитиков при составлении документа требований: последовательность изложения, структурность, соблюдение уровней, целостность набора требований. При формулировании отдельных требований тоже есть ошибки, связанные с формулировками.
Поэтому почти бессмысленны курсы и материалы, которые выглядят как набор тем. Ну, вы будете это знать (наверное). А как вы будете это применять? В какой последовательности? Как одно вытекает из другого? Какие проблемы могут возникнуть на каждой связке? У нас на тренингах участники удивляются чуть ли не после каждого шага: ой, мы теперь хотим вернуться и дописать/переписать требования. Ну да: потому что требования в спецификации — это не начальный артефакт, а конечный, мы в этой форме фиксируем результаты анализа.
То есть, важно не "что", а "как". По этой же причине "не работают" ГОСТы — в них написано "что", но почти никогда не написано "как".
С другой стороны, простой раскладки деятельности на отдельные составные части недостаточно, а на начальной стадии она даже вредна. Если вы начнете докапываться до мелких деталей у человека, который в целом не понимает, как что-то делать — пользы это не принесет. Нужно общее понимание, гештальт. Вы можете очень долго фокусироваться на отдельных движениях руками, ногами и телом, когда учитесь езде на велосипеде, но пока не "щёлкнет" — вы не поедете. Причем никто не сможет вам объяснить рассудочно и логично, что нужно делать. То есть, может, но это не поможет.
Тоже, кстати, довольно часто встречается у людей, которые переходят в профессию аналитика из других — в самом начале можно видеть, как у них "не щелкает" и они вообще не понимают, что тут происходит. Их тексты не складываются в единое целое (и одним из приемов является составление таблицы вместо текста), их диаграммы выглядят как нагромождение геометрических фигур и значков.
Я давно знал, что самый лучший тренер/учитель — не тот, у кого больше опыта и достижений в том деле, которому он учит. Поэтому гнаться за тем, чтобы учиться у лучшего в своем деле не всегда полезно. Даже наоборот — часто бывает, что человек реально мастер, но объяснить, как он это делает, не может.
Ну просто многие вещи он уже делает на автомате, и даже не замечает, что их делает.
Но у меня был вопрос — а какими тогда качествами должен обладать хороший тренер? Именно тренер, тот, кто ставит навык деятельности. Так-то многие просто лекциями занимаются, донесением информации и иногда передачей ценностных установок, если повезет. А вот как выбрать именно тренера?
И тут недавно я получил ответ на одном занятии. Хотя, в общем, и раньше можно было додуматься.
Хороший тренер — это тот, кто разделяет деятельность, которой он учит, на минимальные составляющие, вычленяет в деятельности подопечного эти составляющие и корректирует те, что нуждаются в улучшении.
Соответственно, определить хорошего тренера (или хороший курс) можно по степени детализации той деятельности, которой он учит, в его материалах. Если у вас вся детализация работы аналитика на уровне "а сейчас напишем требования" — это примерно как в анекдоте "дорисуйте остальную сову".
Это давно известно в спорте — я вот в институте немного занимался тяжелой атлетикой, и у нас в зале висели кинограммы рывка и толчка: покадровая съемка каждого упражнения, 15-20 фото на упражнение + траектория движения грифа штанги чуть ли не по сантиметрам. А так-то кажется — ну что там, взял, поднял.
Соответственно, примерно столько мелких движений, а нюансов их выполнения — ещё больше.
И хороший тренер должен, во-первых, все их знать, а, во-вторых — уметь распознавать и корректировать, и знать, какие обычно вызывают проблемы у начинающих. Например, типичные проблемы начинающих аналитиков при составлении документа требований: последовательность изложения, структурность, соблюдение уровней, целостность набора требований. При формулировании отдельных требований тоже есть ошибки, связанные с формулировками.
Поэтому почти бессмысленны курсы и материалы, которые выглядят как набор тем. Ну, вы будете это знать (наверное). А как вы будете это применять? В какой последовательности? Как одно вытекает из другого? Какие проблемы могут возникнуть на каждой связке? У нас на тренингах участники удивляются чуть ли не после каждого шага: ой, мы теперь хотим вернуться и дописать/переписать требования. Ну да: потому что требования в спецификации — это не начальный артефакт, а конечный, мы в этой форме фиксируем результаты анализа.
То есть, важно не "что", а "как". По этой же причине "не работают" ГОСТы — в них написано "что", но почти никогда не написано "как".
С другой стороны, простой раскладки деятельности на отдельные составные части недостаточно, а на начальной стадии она даже вредна. Если вы начнете докапываться до мелких деталей у человека, который в целом не понимает, как что-то делать — пользы это не принесет. Нужно общее понимание, гештальт. Вы можете очень долго фокусироваться на отдельных движениях руками, ногами и телом, когда учитесь езде на велосипеде, но пока не "щёлкнет" — вы не поедете. Причем никто не сможет вам объяснить рассудочно и логично, что нужно делать. То есть, может, но это не поможет.
Тоже, кстати, довольно часто встречается у людей, которые переходят в профессию аналитика из других — в самом начале можно видеть, как у них "не щелкает" и они вообще не понимают, что тут происходит. Их тексты не складываются в единое целое (и одним из приемов является составление таблицы вместо текста), их диаграммы выглядят как нагромождение геометрических фигур и значков.
🔥20❤10👍10💯6🤔1
Эти наблюдения полезны и тем, кто развивает у себя в компании систему наставничества. Кто будет лучшим наставником? Не просто тот, кто лучше других выдает результат, а тот, кто:
1) выдает результат,
2) очень хорошо понимает, из каких отдельных действий состоит этот результат (то есть, скорее всего, обладает высокой степенью рефлексии),
3) понимает и может увидеть деятельность подопечного во всей целостности, как гештальт.
1) выдает результат,
2) очень хорошо понимает, из каких отдельных действий состоит этот результат (то есть, скорее всего, обладает высокой степенью рефлексии),
3) понимает и может увидеть деятельность подопечного во всей целостности, как гештальт.
🔥21💯6👍3❤2
В продолжение предыдущего поста — именно потому, что в открытом доступе просто нет публикаций, разбирающих в деталях последовательность работы системного аналитика, почти бесполезно спрашивать генеративные ИИ про конкретную последовательность действий при анализе и проектировании систем со всеми нюансами.
В лучшем случае вы получите оочень общее описание процесса или пересказ какой-нибудь модели SDLC. Везде происходит какая-то магия при переходе от целей к решениям: "сначала выявите всех стейкхолдеров, потом зафикисруйте их интересы и пожелания, и на основе них разработайте требования". Вроде всё понятно, но что конкретно делать-то?
Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.
Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).
К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.
Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.
В общем, во всех этих методиках происходит составление списков (входящих данных, функций, юскейсов, событий), и аккуратное прослеживание каждого элемента списка вглубь системы (при получении этого события какую функцию мы запускаем? при активации этого юскейса в этом интерфейсе — какие данные куда передаются и как меняются?..), так мы и приходим к требованиям и спецификациям.
Вот даже INCOSE говорит, что мы должны прийти к реализованной системе путем формальных трансформаций потребностей (needs) стейкхолдеров в требования (requirements), потом в спецификации, а потом уже в самую систему.
Сначала, помню, меня это предположение возмутило: да как так? Создание требований — это творческий процесс, а не формальный! Но сейчас соглашусь: да, нужно просто аккуратно всё выявить и последовательно трансформировать, и получится хороший результат.
Кстати, в последней версии руководства INCOSE рекомендует начать выявление требований с "концепта жизненного цикла" системы, а перед потребностями ставит "ожидания от мира". Это что-то новенькое, напишу отдельным постом.
В лучшем случае вы получите оочень общее описание процесса или пересказ какой-нибудь модели SDLC. Везде происходит какая-то магия при переходе от целей к решениям: "сначала выявите всех стейкхолдеров, потом зафикисруйте их интересы и пожелания, и на основе них разработайте требования". Вроде всё понятно, но что конкретно делать-то?
Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.
Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).
К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.
Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.
В общем, во всех этих методиках происходит составление списков (входящих данных, функций, юскейсов, событий), и аккуратное прослеживание каждого элемента списка вглубь системы (при получении этого события какую функцию мы запускаем? при активации этого юскейса в этом интерфейсе — какие данные куда передаются и как меняются?..), так мы и приходим к требованиям и спецификациям.
Вот даже INCOSE говорит, что мы должны прийти к реализованной системе путем формальных трансформаций потребностей (needs) стейкхолдеров в требования (requirements), потом в спецификации, а потом уже в самую систему.
Сначала, помню, меня это предположение возмутило: да как так? Создание требований — это творческий процесс, а не формальный! Но сейчас соглашусь: да, нужно просто аккуратно всё выявить и последовательно трансформировать, и получится хороший результат.
Кстати, в последней версии руководства INCOSE рекомендует начать выявление требований с "концепта жизненного цикла" системы, а перед потребностями ставит "ожидания от мира". Это что-то новенькое, напишу отдельным постом.
🔥32👍11🤯3
Руководство по написанию требований INCOSE версии 4 только на первый взгляд не сильно отличается от предыдущей версии, для которой есть русский перевод. На уровне источников требований есть одно принципиальное различие: теперь главным, самым верхним источником считаются "концепции жизненного цикла". Это новое понятие, в предыдущей версии всё начиналось со стратегии компании, а потом шли интересы стейкхолдеров.
Давайте разбираться. Во-первых, кроме Руководства по написанию требований у INCOSE теперь есть ещё один документ: Needs and Requirements Manual (NRM), выпущенный в 2024 году, то есть совсем свежий. Почему один из них guide, а другой manual, и как это адекватно перевести на русский, непонятно. Видимо, дело в размере — guide всего 140 страниц, а manual — почти 500!
Во-вторых, в мануале есть детальное объяснение всей используемой онтологии. Руководство её только использует.
Всё начинается с Сущности (Entity). Сущность — это то, к чему применяется концепция, потребность или требование. Сущности бывают трех типов:
— физические или программные (системы или части систем),
— процессные (включая сюда модели и рабочие инструкции),
— бизнес или люди (тут могут быть компании, подразделения или роли).
Следующее понятие: Концепт (или концепция, concept): текстовое или графическое представление, которое кратко выражает, как именно сущность может решить проблему, устранить угрозу, реализовать возможность, миссию, цели, задачи и меры, для решения которых она предназначена.
Идея решения, короче.
Ещё раз: в мануале от крупного индустриального сообщества инженеров написано черным по белому, что всё начинается с идеи решения, а не интересов или требований.
На самом деле, это ещё в ГОСТ 34.601—90 написано, но кто ж его читал. И в ГОСТ Р 59793—2021 повторено. Если вас в следующий раз попросят всё "по ГОСТу" делать, вы людям этот самый ГОСТ покажите, там начинается всё не с ТЗ, а с обследования, формирования пользовательских требований и разработки вариантов концепции АС (нескольких!). А ТЗ — это третья по счету стадия, перед ним ещё 2 стадии и 8 этапов работ, на минуточку.
Концепции, из которых проистекают потребности, берутся не любые, а именно концепции жизненного цикла. Правда, не уточняется — ЖЦ чего именно. Судя по этапам — сущности. То есть, как организация собирается управлять, приобретать, проектировать, разрабатывать, строить/программировать, интегрировать, верифицировать, валидировать, передавать, инсталлировать, эксплуатировать, поддерживать, обслуживать и выводить из эксплуатации сущность.
Кажется, из всего этого аналитик обычно думают про эксплуатацию и в последнее время про интеграцию.
В общем, у нас на каждый этап жизненного цикла есть некая концепция, из неё следуют свои стейкхолдеры и их потребности. Ну дальше всё по цепочке: потребности, требования, проектировочные решения, архитектура, спецификации, система.
Что интересно: почти везде вместе со словом "анализ" используется хитрое слово 'maturation' — "вызревание". То есть, пока вы анализируете, эти самые концепции и потребности "вызревают" в головах и стейкхолдеров. Это, мне кажется, ещё круче, чем elicitation (извлечение, добыча) — нечего там добывать, оно созреть должно!
Ещё одна важная деталь: в мануале ясно написано, что первично установленные значения целевых показателей и метрик очень часто не являются осуществимыми, и приходят к каким-то реальным значениям только через несколько итераций анализа и "дозревания", да и то с оговоркой "с приемлемым уровнем риска для этой стадии жизненного цикла"! (Кто вообще оценивает уровень риска?)
В общем, кажется, у нас есть довольно свежий документ (или даже книга), требующий пристального изучения. Я бы сказал, выглядит как минимум на уровне Вигерса, а то и лучше (но более формально, конечно, больше на стандарт похоже).
Давайте разбираться. Во-первых, кроме Руководства по написанию требований у INCOSE теперь есть ещё один документ: Needs and Requirements Manual (NRM), выпущенный в 2024 году, то есть совсем свежий. Почему один из них guide, а другой manual, и как это адекватно перевести на русский, непонятно. Видимо, дело в размере — guide всего 140 страниц, а manual — почти 500!
Во-вторых, в мануале есть детальное объяснение всей используемой онтологии. Руководство её только использует.
Всё начинается с Сущности (Entity). Сущность — это то, к чему применяется концепция, потребность или требование. Сущности бывают трех типов:
— физические или программные (системы или части систем),
— процессные (включая сюда модели и рабочие инструкции),
— бизнес или люди (тут могут быть компании, подразделения или роли).
Следующее понятие: Концепт (или концепция, concept): текстовое или графическое представление, которое кратко выражает, как именно сущность может решить проблему, устранить угрозу, реализовать возможность, миссию, цели, задачи и меры, для решения которых она предназначена.
Идея решения, короче.
Ещё раз: в мануале от крупного индустриального сообщества инженеров написано черным по белому, что всё начинается с идеи решения, а не интересов или требований.
На самом деле, это ещё в ГОСТ 34.601—90 написано, но кто ж его читал. И в ГОСТ Р 59793—2021 повторено. Если вас в следующий раз попросят всё "по ГОСТу" делать, вы людям этот самый ГОСТ покажите, там начинается всё не с ТЗ, а с обследования, формирования пользовательских требований и разработки вариантов концепции АС (нескольких!). А ТЗ — это третья по счету стадия, перед ним ещё 2 стадии и 8 этапов работ, на минуточку.
Концепции, из которых проистекают потребности, берутся не любые, а именно концепции жизненного цикла. Правда, не уточняется — ЖЦ чего именно. Судя по этапам — сущности. То есть, как организация собирается управлять, приобретать, проектировать, разрабатывать, строить/программировать, интегрировать, верифицировать, валидировать, передавать, инсталлировать, эксплуатировать, поддерживать, обслуживать и выводить из эксплуатации сущность.
Кажется, из всего этого аналитик обычно думают про эксплуатацию и в последнее время про интеграцию.
В общем, у нас на каждый этап жизненного цикла есть некая концепция, из неё следуют свои стейкхолдеры и их потребности. Ну дальше всё по цепочке: потребности, требования, проектировочные решения, архитектура, спецификации, система.
Что интересно: почти везде вместе со словом "анализ" используется хитрое слово 'maturation' — "вызревание". То есть, пока вы анализируете, эти самые концепции и потребности "вызревают" в головах и стейкхолдеров. Это, мне кажется, ещё круче, чем elicitation (извлечение, добыча) — нечего там добывать, оно созреть должно!
Ещё одна важная деталь: в мануале ясно написано, что первично установленные значения целевых показателей и метрик очень часто не являются осуществимыми, и приходят к каким-то реальным значениям только через несколько итераций анализа и "дозревания", да и то с оговоркой "с приемлемым уровнем риска для этой стадии жизненного цикла"! (Кто вообще оценивает уровень риска?)
В общем, кажется, у нас есть довольно свежий документ (или даже книга), требующий пристального изучения. Я бы сказал, выглядит как минимум на уровне Вигерса, а то и лучше (но более формально, конечно, больше на стандарт похоже).
👍30🔥12❤6
Вышел очередной Requests for Startups от известнейшего акселератора Y Combinator. Не то чтобы я собирался подавать туда заявку, но я регулярно мониторю их запросы, чтобы понять — что сейчас вообще востребовано и куда рынок смотрит.
Конечно, в последнее время там сплошной ИИ. Конечно, они идут за глобальными событиями — в 2020-21 был биотех и противодействие глобальным эпидемиям, а в 2024 появились военные технологии (ну в смысле — защитные, defence). Climate-tech, в том числе про разные источники энергии и электрические автомобили там вообще чуть ли не в каждом наборе. Биология, здравоохранение, климат, технологии безопасности, роботы и генеративный ИИ для программирования и инженерии.
Весной 2025 все хотели AI-агентов и RPA на новом уровне. Такие агенты, сякие агенты, инструменты для создания AI-агентов, софт для потребления AI-агентами (B2A). Скреппинг, машинно-читаемая информация и API на новом уровне — не для людей, а для ИИ. В общем, понятная история, это мы и без YC знали.
И тут! В запросе на летний набор 2025, внезапно — образование! Чтобы вы понимали, про образование и EdTech Y Combinator в последний раз спрашивал в 2017 году! Ну, может быть помните — бум MOOCов, Coursera, edX, вот это всё. В 2010-2016 был прямо бум. Российские проекты примерно тогда же появились - Нетология, Skyeng.
А потом — как отрезало. В смысле инвестиций. Последний всплеск был в 2020-21, когда был ковид и самоизоляция, а потом на радостях все дружно вышли на биржу. Но революции не случилось. Дизрапта индустрии не произошло. Мы не бросили учиться у живых учителей, школы и университеты не закрываются массово, люди не покупают подписку на обучение в течение всей жизни, как было обещано. Отлично себя чувствует только токсичная зеленая сова Duo (цепляет здорово, кстати — мало чем в жизни я каждый день занимаюсь уже несколько лет — ну вот в канал пишу 😹 ). EdTech уже практически стал ругательным словом, можно найти множество статей с заголовками 'EdTech is dead' на разные лады.
И тут, внезапно, запрос от YC. Аж в двух видах:
1) Персональный AI тьютор. С идеями от "Мемекса" Ванновара Буша (это 1940-е годы) до "Алмазного букваря" Нила Стивенсона. Идеальный ИИ-учитель, который сгенерирует контент специально для вас лично, причем хоть текст, хоть инфографику, хоть видео с озвучкой. Хотели бы такого персонального учителя в кармане, который бы помог вам разобраться в любой теме в любой момент, и с настроенным на вас уровнем погружения?
2) Будущее образования. Опять двадцать пять. Нет, ну 1.5 миллиардов обучающихся в мире — это прямо лакомый рынок! Как-то даже обидно признать, что ничего на нём не меняется — как 100 лет назад учились (а то и 200, и 400), так и сейчас учатся. Ну и, конечно, AI тут сейчас всё поменяет. Они там честно пишут — не знаем, что конкретно "всё" — we're still very early in figuring out what AI can truly achieve here — и как на этом заработать, но должно же уже что-то поменяться в обучении, сколько можно!
Я-то сам с 2006 года, а то и раньше увлечен идеями преподавания, и применения технологий в образовании, и кое-что даже сам делал. Меня это, конечно, радует. Но вот какая это может быть идея?
Если бы было возможно всё, что угодно — каким бы вы видели идеальный способ обучения?
(картинка из детского сериала по Звездным Войнам — давным-давно, в очень далекой Галактике, где летают звездолеты и стреляют лазерами, обучение происходит точно так же, как у нас — и всей разницы, что учитель — дроид).
Конечно, в последнее время там сплошной ИИ. Конечно, они идут за глобальными событиями — в 2020-21 был биотех и противодействие глобальным эпидемиям, а в 2024 появились военные технологии (ну в смысле — защитные, defence). Climate-tech, в том числе про разные источники энергии и электрические автомобили там вообще чуть ли не в каждом наборе. Биология, здравоохранение, климат, технологии безопасности, роботы и генеративный ИИ для программирования и инженерии.
Весной 2025 все хотели AI-агентов и RPA на новом уровне. Такие агенты, сякие агенты, инструменты для создания AI-агентов, софт для потребления AI-агентами (B2A). Скреппинг, машинно-читаемая информация и API на новом уровне — не для людей, а для ИИ. В общем, понятная история, это мы и без YC знали.
И тут! В запросе на летний набор 2025, внезапно — образование! Чтобы вы понимали, про образование и EdTech Y Combinator в последний раз спрашивал в 2017 году! Ну, может быть помните — бум MOOCов, Coursera, edX, вот это всё. В 2010-2016 был прямо бум. Российские проекты примерно тогда же появились - Нетология, Skyeng.
А потом — как отрезало. В смысле инвестиций. Последний всплеск был в 2020-21, когда был ковид и самоизоляция, а потом на радостях все дружно вышли на биржу. Но революции не случилось. Дизрапта индустрии не произошло. Мы не бросили учиться у живых учителей, школы и университеты не закрываются массово, люди не покупают подписку на обучение в течение всей жизни, как было обещано. Отлично себя чувствует только токсичная зеленая сова Duo (цепляет здорово, кстати — мало чем в жизни я каждый день занимаюсь уже несколько лет — ну вот в канал пишу 😹 ). EdTech уже практически стал ругательным словом, можно найти множество статей с заголовками 'EdTech is dead' на разные лады.
И тут, внезапно, запрос от YC. Аж в двух видах:
1) Персональный AI тьютор. С идеями от "Мемекса" Ванновара Буша (это 1940-е годы) до "Алмазного букваря" Нила Стивенсона. Идеальный ИИ-учитель, который сгенерирует контент специально для вас лично, причем хоть текст, хоть инфографику, хоть видео с озвучкой. Хотели бы такого персонального учителя в кармане, который бы помог вам разобраться в любой теме в любой момент, и с настроенным на вас уровнем погружения?
2) Будущее образования. Опять двадцать пять. Нет, ну 1.5 миллиардов обучающихся в мире — это прямо лакомый рынок! Как-то даже обидно признать, что ничего на нём не меняется — как 100 лет назад учились (а то и 200, и 400), так и сейчас учатся. Ну и, конечно, AI тут сейчас всё поменяет. Они там честно пишут — не знаем, что конкретно "всё" — we're still very early in figuring out what AI can truly achieve here — и как на этом заработать, но должно же уже что-то поменяться в обучении, сколько можно!
Я-то сам с 2006 года, а то и раньше увлечен идеями преподавания, и применения технологий в образовании, и кое-что даже сам делал. Меня это, конечно, радует. Но вот какая это может быть идея?
Если бы было возможно всё, что угодно — каким бы вы видели идеальный способ обучения?
(картинка из детского сериала по Звездным Войнам — давным-давно, в очень далекой Галактике, где летают звездолеты и стреляют лазерами, обучение происходит точно так же, как у нас — и всей разницы, что учитель — дроид).
👍19❤3
Понял, что на тренинге по проектированию интеграций каждый раз упоминаю политический уровень модели OSI. Ну, тот самый, 8-ой.
Технологии интераций — это 7 уровень, прикладной. Там живет REST (HTTP), и чуть выше -- SOAP (хотя он использует HTTP только как транспорт), GraphQL, gRPC.
А вот выше — политика. Интересы, влияние, торг, уступки, борьба за ресурсы. Почему вообще мы должны вносить изменения в нашу систему, чтобы поддерживать вашу интеграцию? Это вам нужно или нам? Кто кому диктует правила? Кто вкладывает какие ресурсы? Что вы готовы предложить в свою очередь?
Вопросы симметрии и асимметрии: вы достаточно большие, чтобы диктовать всем клиентам свои стандарты, и клиентам не остается ничего другого, кроме как подстроиться под них? Или вам придется подстраиваться под клиентов?
В одном проекте я спроектировал клёвое веб-API — на основе международного отраслевого стандарта, с использованием терминов из контролируемых словарей, с несколькими уровнями совместимости, с профилями для разных юскейсов — заглядение, а не API. Высокотехнологичное. Но клиенты сказали — не-а. Мы так не можем, давайте мы вам просто эксельки пришлем, а вы их распарсите как-нибудь. Кому больше нужно, чтобы наши данные оказались у вас? В этом проекте оказалось, что больше нужно было нам, а не клиентам, и пришлось парсить эксельки, и разбираться со всеми последствиями. Высокотехнологичное API так и осталось памятником самому себе, как Царь-пушка.
Вопрос политики. Вопрос торговли. Балансирования интересов. Мы вам, а вы нам. Если вы говорите с архитектором смежной системы — скорее он будет до последнего сопротивляться внесению в свою систему каких-то новых функций или отращивания новых способов взаимодействия. Пользуйтесь тем, что есть, не нужно ничего менять. Ну, мы можем добавить в ответ пару полей.
Соответственно, интеграции — это место столкновения множества интересов — бизнеса, разных подразделений, владельцев систем, безопасности. И это не решается "управлением стейкхолдерами", как пишут в книгах, потому что политика внутри организации часто руководствуется скрытой повесткой, которую не озвучивают на совещаниях и про которую никто не расскажет вам на интервью.
Два зама сговорились и "дружат" против третьего, чтобы поставить на его место своего человека. Руководитель одного из подразделений хочет отгрызть себе дополнительную зону влияния. Два подразделения бьются за одну область ответственности. Новый зам собирает под себя разрозненные функции, с ним борются люди из старой команды. Группа стейкхолдеров хотят развалить проект и обвинить в этом другую группу. Кто-то хочет получить контроль над важными данными (например, отчетами для руководителя или политиками выделения ресурсов). Это всё примеры политических игр, которые я наблюдал своими глазами. И это игры, которые могут определять согласие или противодействие вопросам развития систем и их интеграции.
В конечном счете, это можно свести к деньгам и добавить уровень финансов (какие решения мы принимаем, учитывая их стоимость на текущий момент и денежный поток на перспективу). Политические вопросы на этом уровне становятся вопросами стимулов и баланса краткосрочных и долгосрочных решений. Это можно было бы просчитать, о некоторые, кажется, борются за власть из чистой любви к ней.
Я, к сожалению, в политике не очень ловок, поэтому на верхних уровнях не всегда выигрываю. Точнее, я хорошо выступаю в ситуации консенсусного подхода. Есть два подхода: консенсусный и конфронтационный. Консенсусный подход подразумевает стремление к согласию и сотрудничеству, поиск компромиссов и стремление удовлетворить интересы всех сторон. Конфронтационный подход ставит на первое место столкновение интересов, противостояние и борьбу за достижение собственных целей за счет других. Иными словами — вера в умножение ресурсов и win-win решения, или вера в ограниченность ресурсов и убежденность, что всегда есть победитель и проигравший.
И это нас приводит ещё к одному уровню — идеологическому, или философским основаниям организации. Но это уже совсем сложная история.
А вы принимаете в расчет эти уровни?
Технологии интераций — это 7 уровень, прикладной. Там живет REST (HTTP), и чуть выше -- SOAP (хотя он использует HTTP только как транспорт), GraphQL, gRPC.
А вот выше — политика. Интересы, влияние, торг, уступки, борьба за ресурсы. Почему вообще мы должны вносить изменения в нашу систему, чтобы поддерживать вашу интеграцию? Это вам нужно или нам? Кто кому диктует правила? Кто вкладывает какие ресурсы? Что вы готовы предложить в свою очередь?
Вопросы симметрии и асимметрии: вы достаточно большие, чтобы диктовать всем клиентам свои стандарты, и клиентам не остается ничего другого, кроме как подстроиться под них? Или вам придется подстраиваться под клиентов?
В одном проекте я спроектировал клёвое веб-API — на основе международного отраслевого стандарта, с использованием терминов из контролируемых словарей, с несколькими уровнями совместимости, с профилями для разных юскейсов — заглядение, а не API. Высокотехнологичное. Но клиенты сказали — не-а. Мы так не можем, давайте мы вам просто эксельки пришлем, а вы их распарсите как-нибудь. Кому больше нужно, чтобы наши данные оказались у вас? В этом проекте оказалось, что больше нужно было нам, а не клиентам, и пришлось парсить эксельки, и разбираться со всеми последствиями. Высокотехнологичное API так и осталось памятником самому себе, как Царь-пушка.
Вопрос политики. Вопрос торговли. Балансирования интересов. Мы вам, а вы нам. Если вы говорите с архитектором смежной системы — скорее он будет до последнего сопротивляться внесению в свою систему каких-то новых функций или отращивания новых способов взаимодействия. Пользуйтесь тем, что есть, не нужно ничего менять. Ну, мы можем добавить в ответ пару полей.
Соответственно, интеграции — это место столкновения множества интересов — бизнеса, разных подразделений, владельцев систем, безопасности. И это не решается "управлением стейкхолдерами", как пишут в книгах, потому что политика внутри организации часто руководствуется скрытой повесткой, которую не озвучивают на совещаниях и про которую никто не расскажет вам на интервью.
Два зама сговорились и "дружат" против третьего, чтобы поставить на его место своего человека. Руководитель одного из подразделений хочет отгрызть себе дополнительную зону влияния. Два подразделения бьются за одну область ответственности. Новый зам собирает под себя разрозненные функции, с ним борются люди из старой команды. Группа стейкхолдеров хотят развалить проект и обвинить в этом другую группу. Кто-то хочет получить контроль над важными данными (например, отчетами для руководителя или политиками выделения ресурсов). Это всё примеры политических игр, которые я наблюдал своими глазами. И это игры, которые могут определять согласие или противодействие вопросам развития систем и их интеграции.
В конечном счете, это можно свести к деньгам и добавить уровень финансов (какие решения мы принимаем, учитывая их стоимость на текущий момент и денежный поток на перспективу). Политические вопросы на этом уровне становятся вопросами стимулов и баланса краткосрочных и долгосрочных решений. Это можно было бы просчитать, о некоторые, кажется, борются за власть из чистой любви к ней.
Я, к сожалению, в политике не очень ловок, поэтому на верхних уровнях не всегда выигрываю. Точнее, я хорошо выступаю в ситуации консенсусного подхода. Есть два подхода: консенсусный и конфронтационный. Консенсусный подход подразумевает стремление к согласию и сотрудничеству, поиск компромиссов и стремление удовлетворить интересы всех сторон. Конфронтационный подход ставит на первое место столкновение интересов, противостояние и борьбу за достижение собственных целей за счет других. Иными словами — вера в умножение ресурсов и win-win решения, или вера в ограниченность ресурсов и убежденность, что всегда есть победитель и проигравший.
И это нас приводит ещё к одному уровню — идеологическому, или философским основаниям организации. Но это уже совсем сложная история.
А вы принимаете в расчет эти уровни?
2👍50❤11🔥3👎1😭1
Окружающие вас люди, рабочая обстановка в целом, создают условия
для повышения уровня Вашей личностной свободы или повышения
зависимости; активности или пассивности?
для повышения уровня Вашей личностной свободы или повышения
зависимости; активности или пассивности?
Anonymous Poll
29%
Повышения личной свободы и активности (свободное творчество)
14%
Повышение личной свободы и пассивности (безмятежное потребление)
30%
Повышение зависимости и активности (карьерный успех в коллективе)
27%
Повышение зависимости и пассивности (послушное следование правилам)
Всем привет! Мне для одного исследования нужно знать влияние рабочей среды на личность. Ответьте, пожалуйста, на один вопрос про среду в вашей компании (можно также дать более расширенный ответ в комментарии).
🤝4
В комментариях интересуются — что за исследование. Расскажу чуть подробнее.
Я изучаю образовательную среду по методике В.А. Ясвина. Он предлагает модель из двух координат: свобода—зависимость и активность—пассивность. Разработанная для общеобразовательных школ, она показывает — кого, скорее всего, формирует эта среда. Но эту же модель можно применить и для семьи, и для общества в целом, и для рабочей среды. (Кстати, многие говорят, что это хорошая модель для выяснения обстановки в компании на собеседовании)
Мало того — Ясвин вводит понятие "общественного ветра" — а что у нас в обществе вообще происходит, мы куда движемся? Он ссылается на свои исследования в РФ и Латвии в 2000-х, в которых направление этого ветра однозначно определялось в сторону "пассивной зависимости". Соответственно, организация или школа может двигаться "по ветру" или "против ветра".
Для исследования конкретной школы мне нужно было сделать поправку "на ветер", и я подумал, что в профессиональной среде, да ещё в ИТ, этот "ветер" может быть направлен и в другую сторону. Судя по опросу, так и оказалось! Причем я-то думал, что вектор будет сдвинут в сторону карьерной среды (активная зависимость), а его повернуло вообще в творческую! (активная свобода). Это удивительный результат, и наверное, он требует дополнительного изучения и обсуждения.
У меня даже возникла гипотеза, что дело в самой роли аналитика. Ведь аналитик, по сути — не командный игрок. Редко можно увидеть команду из системных аналитиков. Как правило, это индивидуальный вид спорта. Да, ты со всеми общаешься, но ты никому не принадлежишь (и часто это имеет свои плюсы: можно занимать роль медиатора и примирителя конфликтующих сторон). Отсюда и свобода, ну а активность нам тоже положена по профессии. Вот и получается творческая среда!
А если вы хотите более точно проанализировать свою среду, у Ясвина есть 6 диагностических вопросов: 3 про свободу и 3 про активность. Они изначально для школ, я немного их подкорректировал, чтобы подходили для рабочей среды:
3 вопроса про свободу и зависимость:
1. Чьи интересы и ценности ставятся на первое место в данной среде? а) личности; б) группы.
2. Кто к кому подстраивается в процессе взаимодействия? а) руководитель и правила к сотруднику; б) сотрудник к правилам и руководителю.
3. Какая форма работы преимущественно осуществляется в данной среде? а) индивидуальная; б) групповая.
Соответственно, ставите по 1 баллу в "Свободу" за каждый ответ а), и по 1 баллу в "Зависимость" за каждый ответ б).
Вопросы про активность и пассивность:
4. Практикуется ли в данной среде наказание сотрудников? (в любом виде: запреты, штрафы, отстранение от работ, выговоры, озвучивание перед всеми, увольнение, "серьезный разговор" и т.п.): а) нет; б) да.
5. Стимулируется ли в данной образовательной среде проявление сотрудником какой-либо инициативы? а) да; б) нет.
6. Находят ли какой-либо положительный отклик в данной образовательной среде те или иные творческие проявления сотрудников? а) да; б) нет.
По 1 баллу в "Активность" за каждый ответ а), и по 1 баллу в "Пассивность" за каждый ответ б).
То есть, по каждой оси может быть максимум 3 балла, они формируют один из 9 векторов. Потом можете добавить поправку на общественный ветер. И сравнить, например — к чему вы сами стремитесь, и что вам дает среда — она вас усиливает, или с ней приходится бороться? Как устроена среда, в которой вы учитесь, она вас к чему двигает?.. Например, обилие внешней мотивации, постоянные соревнования, KPI, достигаторство и подчеркнутые поощрения формируют скорее честолюбцев или лицемеров (смотря что преобладает: активность или зависимость), и плохо работают на творческий тип.
Я изучаю образовательную среду по методике В.А. Ясвина. Он предлагает модель из двух координат: свобода—зависимость и активность—пассивность. Разработанная для общеобразовательных школ, она показывает — кого, скорее всего, формирует эта среда. Но эту же модель можно применить и для семьи, и для общества в целом, и для рабочей среды. (Кстати, многие говорят, что это хорошая модель для выяснения обстановки в компании на собеседовании)
Мало того — Ясвин вводит понятие "общественного ветра" — а что у нас в обществе вообще происходит, мы куда движемся? Он ссылается на свои исследования в РФ и Латвии в 2000-х, в которых направление этого ветра однозначно определялось в сторону "пассивной зависимости". Соответственно, организация или школа может двигаться "по ветру" или "против ветра".
Для исследования конкретной школы мне нужно было сделать поправку "на ветер", и я подумал, что в профессиональной среде, да ещё в ИТ, этот "ветер" может быть направлен и в другую сторону. Судя по опросу, так и оказалось! Причем я-то думал, что вектор будет сдвинут в сторону карьерной среды (активная зависимость), а его повернуло вообще в творческую! (активная свобода). Это удивительный результат, и наверное, он требует дополнительного изучения и обсуждения.
У меня даже возникла гипотеза, что дело в самой роли аналитика. Ведь аналитик, по сути — не командный игрок. Редко можно увидеть команду из системных аналитиков. Как правило, это индивидуальный вид спорта. Да, ты со всеми общаешься, но ты никому не принадлежишь (и часто это имеет свои плюсы: можно занимать роль медиатора и примирителя конфликтующих сторон). Отсюда и свобода, ну а активность нам тоже положена по профессии. Вот и получается творческая среда!
А если вы хотите более точно проанализировать свою среду, у Ясвина есть 6 диагностических вопросов: 3 про свободу и 3 про активность. Они изначально для школ, я немного их подкорректировал, чтобы подходили для рабочей среды:
3 вопроса про свободу и зависимость:
1. Чьи интересы и ценности ставятся на первое место в данной среде? а) личности; б) группы.
2. Кто к кому подстраивается в процессе взаимодействия? а) руководитель и правила к сотруднику; б) сотрудник к правилам и руководителю.
3. Какая форма работы преимущественно осуществляется в данной среде? а) индивидуальная; б) групповая.
Соответственно, ставите по 1 баллу в "Свободу" за каждый ответ а), и по 1 баллу в "Зависимость" за каждый ответ б).
Вопросы про активность и пассивность:
4. Практикуется ли в данной среде наказание сотрудников? (в любом виде: запреты, штрафы, отстранение от работ, выговоры, озвучивание перед всеми, увольнение, "серьезный разговор" и т.п.): а) нет; б) да.
5. Стимулируется ли в данной образовательной среде проявление сотрудником какой-либо инициативы? а) да; б) нет.
6. Находят ли какой-либо положительный отклик в данной образовательной среде те или иные творческие проявления сотрудников? а) да; б) нет.
По 1 баллу в "Активность" за каждый ответ а), и по 1 баллу в "Пассивность" за каждый ответ б).
То есть, по каждой оси может быть максимум 3 балла, они формируют один из 9 векторов. Потом можете добавить поправку на общественный ветер. И сравнить, например — к чему вы сами стремитесь, и что вам дает среда — она вас усиливает, или с ней приходится бороться? Как устроена среда, в которой вы учитесь, она вас к чему двигает?.. Например, обилие внешней мотивации, постоянные соревнования, KPI, достигаторство и подчеркнутые поощрения формируют скорее честолюбцев или лицемеров (смотря что преобладает: активность или зависимость), и плохо работают на творческий тип.
👍18🤔8❤3🔥1
Аналитик как медиатор. У аналитика много задач, и одна из них — разрешение конфликтов.
Вообще для аналитика правильная роль — сторонняя, аналитик не владеет какой-либо системой и не защищает её.
Если он начинает выступать в роли владельца — он уже скорее архитектор или технический продакт-менеджер.
А часто, особенно в проектах интеграции, аналитик не представляет интересы одной из из систем, он объединяет разные системы (их разных владельцев и стейкхолдеров). И тут можно легко столкнуться с конфликтом. Интеграции же очень конфликтогенная тема:
кто владеет данными и не хочет их отдавать; кто с какой системой готов взаимодействовать, а с какой нет; кто готов на доработки, а кто нет; какая система к какой будет подстраиваться; какая система обнаруживает и пытается исправить ошибки, и т.п.
Мой учитель и соавтор даже диссертацию защитил про конфликты в ИТ-проектах. И основная мысль — не бывает проектов без конфликтов, а если вам кажется, что у вас такой — скорее всего, вы не всё знаете.
Но если вы уже столкнулись с конфликтом — нужно его решать. И здесь плохая ситуация — паралич, когда каждая сторона стоит на своем и не хочет двигаться (а самая плохая — когда они ещё и говорить друг с другом отказываются).
Аналитик тут может занять позицию медиатора — посредника в конфликте. Вообще медиация — это внесудебный институт урегулирования конфликтов и споров, у нас в обществе он не очень развит (хотя есть целый федеральный закон и профстандарт), а вот в рабочих ситуациях может помочь. Медиатор сам не принимает решения, но может выступить организатором и фасилитатором принятия решения.
Что делает медиатор:
— снимает эмоциональное напряжение, дает высказаться, выйти чувствам.
— выясняет предпосылки, цели и потребности, стоящие за каждой позицией.
— выявляет общие потребности (ну хоть что-то общее обычно есть).
В теории ограничений Голдратта есть инструмент "Грозовая туча", он работает похожим образом — исходя из конфликтующих положений строят условия, при которых эти положения реализуются, а условия приводят к единой цели. Всё-таки, в рабочей обстановке даже у разных подразделений цели должны где-то сходиться.
В процессе медиации посредник говорит сначала индивидуально с каждой стороной конфликта, потом доносит позиции и возможную общую почву для переговоров. Потом организует общую встречу. Тут главное — добиться, чтобы все чувства были высказаны, и стороны начали спокойно разговаривать, чтобы отношения были восстановлены.
Иногда удивительный эффект возникает, если просто озвучить свои чувства.
Есть разные подходы к медиации, и один из них — нарративная медиация, основанная на историях. Медиатор пересказывает своими словами историю, которую слышит от каждой из сторон, но без обвинений и эмоций, излагая только факты и иногда называя чувства сторон (например, "опасение", "тревога", "неуверенность" и т.п.).
Если конфликт давнишний — можно попробовать обратиться к моменту в прошлом, когда всё ещё было хорошо. Впрочем, это только инструмент - медиатор должен быть сосредоточен на будущем, а не на прошлом.
Часто действительно бывает, что стороны исходят из разных предпосылок, которые может быть вообще лежат на разных уровнях, но сами они этого не понимают — но тогда и решение можно искать на разных уровнях. Например, разработчики столкнулись с техническими проблемами, которые могут быть решены на организационном уровне, но с точки зрения разработки эти варианты не видны.
Ну и медиатор должен вести стороны конфликта к осознанию реальных перспектив решения, а не максималистских позиций. Можно хотеть очень многого, но не получить в итоге ничего, и только продолжать тратить силы и ресурсы в конфликте. У аналитика тут тоже выигрышная позиция, т.к. он может подсветить в деталях реальную картину.
В общем, советую всем аналитикам хотя бы в общих чертах изучить темы конфликтологии, теории игр и медиации — интересные инструменты открываются.
Вообще для аналитика правильная роль — сторонняя, аналитик не владеет какой-либо системой и не защищает её.
Если он начинает выступать в роли владельца — он уже скорее архитектор или технический продакт-менеджер.
А часто, особенно в проектах интеграции, аналитик не представляет интересы одной из из систем, он объединяет разные системы (их разных владельцев и стейкхолдеров). И тут можно легко столкнуться с конфликтом. Интеграции же очень конфликтогенная тема:
кто владеет данными и не хочет их отдавать; кто с какой системой готов взаимодействовать, а с какой нет; кто готов на доработки, а кто нет; какая система к какой будет подстраиваться; какая система обнаруживает и пытается исправить ошибки, и т.п.
Мой учитель и соавтор даже диссертацию защитил про конфликты в ИТ-проектах. И основная мысль — не бывает проектов без конфликтов, а если вам кажется, что у вас такой — скорее всего, вы не всё знаете.
Но если вы уже столкнулись с конфликтом — нужно его решать. И здесь плохая ситуация — паралич, когда каждая сторона стоит на своем и не хочет двигаться (а самая плохая — когда они ещё и говорить друг с другом отказываются).
Аналитик тут может занять позицию медиатора — посредника в конфликте. Вообще медиация — это внесудебный институт урегулирования конфликтов и споров, у нас в обществе он не очень развит (хотя есть целый федеральный закон и профстандарт), а вот в рабочих ситуациях может помочь. Медиатор сам не принимает решения, но может выступить организатором и фасилитатором принятия решения.
Что делает медиатор:
— снимает эмоциональное напряжение, дает высказаться, выйти чувствам.
— выясняет предпосылки, цели и потребности, стоящие за каждой позицией.
— выявляет общие потребности (ну хоть что-то общее обычно есть).
В теории ограничений Голдратта есть инструмент "Грозовая туча", он работает похожим образом — исходя из конфликтующих положений строят условия, при которых эти положения реализуются, а условия приводят к единой цели. Всё-таки, в рабочей обстановке даже у разных подразделений цели должны где-то сходиться.
В процессе медиации посредник говорит сначала индивидуально с каждой стороной конфликта, потом доносит позиции и возможную общую почву для переговоров. Потом организует общую встречу. Тут главное — добиться, чтобы все чувства были высказаны, и стороны начали спокойно разговаривать, чтобы отношения были восстановлены.
Иногда удивительный эффект возникает, если просто озвучить свои чувства.
Есть разные подходы к медиации, и один из них — нарративная медиация, основанная на историях. Медиатор пересказывает своими словами историю, которую слышит от каждой из сторон, но без обвинений и эмоций, излагая только факты и иногда называя чувства сторон (например, "опасение", "тревога", "неуверенность" и т.п.).
Если конфликт давнишний — можно попробовать обратиться к моменту в прошлом, когда всё ещё было хорошо. Впрочем, это только инструмент - медиатор должен быть сосредоточен на будущем, а не на прошлом.
Часто действительно бывает, что стороны исходят из разных предпосылок, которые может быть вообще лежат на разных уровнях, но сами они этого не понимают — но тогда и решение можно искать на разных уровнях. Например, разработчики столкнулись с техническими проблемами, которые могут быть решены на организационном уровне, но с точки зрения разработки эти варианты не видны.
Ну и медиатор должен вести стороны конфликта к осознанию реальных перспектив решения, а не максималистских позиций. Можно хотеть очень многого, но не получить в итоге ничего, и только продолжать тратить силы и ресурсы в конфликте. У аналитика тут тоже выигрышная позиция, т.к. он может подсветить в деталях реальную картину.
В общем, советую всем аналитикам хотя бы в общих чертах изучить темы конфликтологии, теории игр и медиации — интересные инструменты открываются.
❤38🔥20👍13❤🔥2
Преподавание в ML – штука непростая
С одной стороны, оно становится всё более техническим: нужно объяснять не только линейную алгебру, но и архитектуру трансформеров, пайплайны, метрики, устройства токенизации и fine-tuning. С другой – важно выстроить образовательную траекторию, создать комфортную среду для студентов и развить критическое мышление.
Особенно интересен тип преподавателей, которые одновременно делают курсы и участвуют в реальных проектах: сдают задачи в проде, участвуют в ресерче, запускают хакатоны.
Таких не очень много, и важно их поддерживать. Я увидел, что Яндекс в этом году фокусирует свою премию ML Prize на преподавателях. Делюсь, потому что это редкий случай, когда преподавательская практика становится объектом внимания в профессиональном сообществе.
Три направления:
- преподаватели с опытом 3+ лет
- молодые специалисты (1–3 года)
- руководители ML-программ.
Награда – денежные выплаты и гранты на Yandex Cloud, которые можно использовать для запуска курсов, хакатонов, исследований.
Не часто бывает, чтобы системное и образовательное усилие оказывалось на переднем плане. Может, это сдвиг. А может, исключение. Но зафиксировать стоит.
С одной стороны, оно становится всё более техническим: нужно объяснять не только линейную алгебру, но и архитектуру трансформеров, пайплайны, метрики, устройства токенизации и fine-tuning. С другой – важно выстроить образовательную траекторию, создать комфортную среду для студентов и развить критическое мышление.
Особенно интересен тип преподавателей, которые одновременно делают курсы и участвуют в реальных проектах: сдают задачи в проде, участвуют в ресерче, запускают хакатоны.
Таких не очень много, и важно их поддерживать. Я увидел, что Яндекс в этом году фокусирует свою премию ML Prize на преподавателях. Делюсь, потому что это редкий случай, когда преподавательская практика становится объектом внимания в профессиональном сообществе.
Три направления:
- преподаватели с опытом 3+ лет
- молодые специалисты (1–3 года)
- руководители ML-программ.
Награда – денежные выплаты и гранты на Yandex Cloud, которые можно использовать для запуска курсов, хакатонов, исследований.
Не часто бывает, чтобы системное и образовательное усилие оказывалось на переднем плане. Может, это сдвиг. А может, исключение. Но зафиксировать стоит.
👍10❤5
Слушайте, я понял, что не показывал вам классный инструмент — радар для определения, подходит ли вам Agile, водопад (Plan-driven) или гибридный подход.
Я когда-то про эти критерии когда-то писал, но там ссылка уже протухла, ну и там была просто картинка, а тут — интерактивный чарт, на котором вы можете оценить свой проект.
Вот: https://suitabilityfilter.com/
Оси оценки:
— Доступ к заказчику (на ежедневной основе)
— Приверженность agile-подходу спонсора проекта
— Доверие команде со стороны заказчика
— Разрешается ли команде принимать решения самостоятельно
— Возможность инкрементальной поставки продукта
— Критичность ошибок в продукте (время, деньги, критичные деньги, жизни людей)
— Вероятность изменения требований (% изменившихся требований за месяц)
— Размер команды
— Опыт членов команды
Сразу понятно, почему конкретно в вашем случае Agile не подходит.
Попробуйте, напишите в комментариях — что у вас получилось? Очень интересно.
Я когда-то про эти критерии когда-то писал, но там ссылка уже протухла, ну и там была просто картинка, а тут — интерактивный чарт, на котором вы можете оценить свой проект.
Вот: https://suitabilityfilter.com/
Оси оценки:
— Доступ к заказчику (на ежедневной основе)
— Приверженность agile-подходу спонсора проекта
— Доверие команде со стороны заказчика
— Разрешается ли команде принимать решения самостоятельно
— Возможность инкрементальной поставки продукта
— Критичность ошибок в продукте (время, деньги, критичные деньги, жизни людей)
— Вероятность изменения требований (% изменившихся требований за месяц)
— Размер команды
— Опыт членов команды
Сразу понятно, почему конкретно в вашем случае Agile не подходит.
Попробуйте, напишите в комментариях — что у вас получилось? Очень интересно.
🔥19❤6👍6
Мы тут с коллегами из нескольких школ и конференций решили сделать большое исследование индустрии системного и бизнес-анализа в РФ и не только.
Хотим узнать про отрасль, её размер, зрелость и вообще.
А что бы вы хотели узнать про нашу индустрию? Что интересно узнать про развитие СА/БА в компаниях и про людей? (Ну, помимо очевидного вопроса -- сколько зарабатывают люди в соседней организации)
Напишите в комментариях!
👇👇👇
Хотим узнать про отрасль, её размер, зрелость и вообще.
А что бы вы хотели узнать про нашу индустрию? Что интересно узнать про развитие СА/БА в компаниях и про людей? (Ну, помимо очевидного вопроса -- сколько зарабатывают люди в соседней организации)
Напишите в комментариях!
👇👇👇
👍22
Выяснили тут на тренинге, что не все знают разницу между сбоем, ошибкой, отказом и т.д. Я и сам-то забываю иногда. А это важно при проектировании интеграций и архитектуры.
Есть ГОСТ Р 27.102-2021 "Надежность в технике. НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения". Там всё есть.
Запишу для себя и для вас верные термины:
Работоспособное состояние: состояние объекта, в котором значения всех параметров, характеризующих его способность выполнять заданные функции, соответствуют требованиям нормативной и технической документации. При этом он прямо сейчас может и не выполнять свою функцию, например, потому что нет команды или внешних ресурсов. Но остается работоспособным.
Короче, это про функции. Для сложных объектов может быть частично работоспособное состояние, когда часть функций ещё выполняется, а часть уже нет. Есть ещё исправное и неисправное состояние, а ещё — рабочее и нерабочее. Рабочее состояние — объект выполняет какую-то свою функцию прямо сейчас.
Исправное и неисправное состояние — это про любые параметры, как связанные с выполнением функций, так и нет.
Поэтому работоспособный объект может находиться в неисправном состоянии, вот так.
Опасное состояние: состояние объекта, которому соответствует высокая вероятность или высокая значимость неблагоприятных последствий для людей, окружающей среды и материальных ценностей.
Отказ: событие, заключающееся в нарушении работоспособного состояния объекта. То есть, он становится частично или полностью неработоспособным, перестает выполнять одну или все функции.
Сбой: самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. В общем, если вы обратились к системе и получили ответ 500, а потом снова обратились, и получили нормальный ответ — это был сбой.
На практике термин "сбой" часто используют в смысле "самоустраняющийся отказ" (и к нему можно применить показатель "среднее время восстановления после сбоя"), а "отказ" — как нарушение работоспособности, требующая вмешательства.
Ошибка — строго говоря, это действие человека, последствием которого явился дефект (ошибка при разработке) или повреждение (нарушение исправного состояния объекта, обычно из-за внешних воздействий или дефекта).
Дефект — это несоответствие объекта требованиям, установленным в документации. Дефект может проявляться только при определенных обстоятельствах, и приводить к сбою или отказу.
Надежность: свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность объекта выполнять требуемые функции в заданных режимах, условиях применения, стратегиях технического обслуживания, хранения и транспортирования.
Безотказность: Свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки в заданных режимах и условиях применения. То есть, вообще говоря, объект может быть неисправен, но продолжать функционировать — и сохранять безотказность!
Доступность (availability) этом стандарте приравнивается к готовности: способность объекта выполнять требуемые функции в заданных условиях, в заданный момент или период времени при условии, что все необходимые внешние ресурсы обеспечены.
При этом надежность объекта и готовность объекта не зависят друг от друга!
А вот эту загадку я уже оставляю вам — как такое может быть? (Upd: ответ в комментариях)
Есть ГОСТ Р 27.102-2021 "Надежность в технике. НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения". Там всё есть.
Запишу для себя и для вас верные термины:
Работоспособное состояние: состояние объекта, в котором значения всех параметров, характеризующих его способность выполнять заданные функции, соответствуют требованиям нормативной и технической документации. При этом он прямо сейчас может и не выполнять свою функцию, например, потому что нет команды или внешних ресурсов. Но остается работоспособным.
Короче, это про функции. Для сложных объектов может быть частично работоспособное состояние, когда часть функций ещё выполняется, а часть уже нет. Есть ещё исправное и неисправное состояние, а ещё — рабочее и нерабочее. Рабочее состояние — объект выполняет какую-то свою функцию прямо сейчас.
Исправное и неисправное состояние — это про любые параметры, как связанные с выполнением функций, так и нет.
Поэтому работоспособный объект может находиться в неисправном состоянии, вот так.
Опасное состояние: состояние объекта, которому соответствует высокая вероятность или высокая значимость неблагоприятных последствий для людей, окружающей среды и материальных ценностей.
Отказ: событие, заключающееся в нарушении работоспособного состояния объекта. То есть, он становится частично или полностью неработоспособным, перестает выполнять одну или все функции.
Сбой: самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. В общем, если вы обратились к системе и получили ответ 500, а потом снова обратились, и получили нормальный ответ — это был сбой.
На практике термин "сбой" часто используют в смысле "самоустраняющийся отказ" (и к нему можно применить показатель "среднее время восстановления после сбоя"), а "отказ" — как нарушение работоспособности, требующая вмешательства.
Ошибка — строго говоря, это действие человека, последствием которого явился дефект (ошибка при разработке) или повреждение (нарушение исправного состояния объекта, обычно из-за внешних воздействий или дефекта).
Дефект — это несоответствие объекта требованиям, установленным в документации. Дефект может проявляться только при определенных обстоятельствах, и приводить к сбою или отказу.
Надежность: свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность объекта выполнять требуемые функции в заданных режимах, условиях применения, стратегиях технического обслуживания, хранения и транспортирования.
Безотказность: Свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки в заданных режимах и условиях применения. То есть, вообще говоря, объект может быть неисправен, но продолжать функционировать — и сохранять безотказность!
Доступность (availability) этом стандарте приравнивается к готовности: способность объекта выполнять требуемые функции в заданных условиях, в заданный момент или период времени при условии, что все необходимые внешние ресурсы обеспечены.
При этом надежность объекта и готовность объекта не зависят друг от друга!
А вот эту загадку я уже оставляю вам — как такое может быть? (Upd: ответ в комментариях)
❤32🔥11👍2
Давно не писал ничего про ИИ, а вот хорошая раскладка по уровням освоения ИИ-скиллов от CEO Zapier.
Как пишет их CEO, это не чек-лист, а просто примеры навыков для понимания — на каком этапе человек в освоении ИИ.
1. Неприемлющий: Сопротивляется использованию ИИ-инструментов и скептически оценивает их пользу.
2. Способный: Использует наиболее популярные инструменты. Скорее всего — опыт использования менее 3-х месяцев.
3. Адаптирующий: Встраивает ИИ в личный рабочий процесс. Тюнит промпты, выстраивает цепочки из моделей, автоматизирует задачи для роста эффективности.
4. Трансформирующий: Использует ИИ не как просто инструмент, но переосмысляет стратегию и создает такую пользу, о которой нельзя было и думать два года назад.
Если говорить о системном анализе, я пока не видел и не слышал о применении на 4 уровне, только редкие одиночные примеры 3-го.
Ну и, кстати, — как бы могли уровни выглядеть для системного аналитика? Что-нибудь вроде такого:
1. Отказывается использовать ИИ, считая его ненадёжным. Пишет требования и составляет диаграммы вручную. Не автоматизирует анализ или моделирование систем.
2. Использует ChatGPT для генерации черновиков требований, user stories и диаграмм. Проверяет корректность ИИ-вывода вручную. Знает базовые понятия LLM и применяет шаблоны промптов.
3. Автоматизирует анализ пользовательских интервью и составление требований с помощью ИИ. Применяет LLM для генерации и валидации моделей (BPMN, UML). Проверяет и устраняет пробелы в требованиях через автоматическое сравнение и трассировку разных видов требований и моделей. Оптимизирует промпты.
4. Формирует основанный на ИИ процесс сбора, генерации и валидации требований. Создает LLM-агентов для анализа требований, отслеживания изменений и генерации спецификаций. Внедряет ИИ в аналитические процессы на уровне организации, сокращая время анализа на 30-50%
Что думаете? Возможен 4-й вариант? Или ИИ-трансформирующий аналитик должен делать что-то другое?
Как пишет их CEO, это не чек-лист, а просто примеры навыков для понимания — на каком этапе человек в освоении ИИ.
1. Неприемлющий: Сопротивляется использованию ИИ-инструментов и скептически оценивает их пользу.
2. Способный: Использует наиболее популярные инструменты. Скорее всего — опыт использования менее 3-х месяцев.
3. Адаптирующий: Встраивает ИИ в личный рабочий процесс. Тюнит промпты, выстраивает цепочки из моделей, автоматизирует задачи для роста эффективности.
4. Трансформирующий: Использует ИИ не как просто инструмент, но переосмысляет стратегию и создает такую пользу, о которой нельзя было и думать два года назад.
Если говорить о системном анализе, я пока не видел и не слышал о применении на 4 уровне, только редкие одиночные примеры 3-го.
Ну и, кстати, — как бы могли уровни выглядеть для системного аналитика? Что-нибудь вроде такого:
1. Отказывается использовать ИИ, считая его ненадёжным. Пишет требования и составляет диаграммы вручную. Не автоматизирует анализ или моделирование систем.
2. Использует ChatGPT для генерации черновиков требований, user stories и диаграмм. Проверяет корректность ИИ-вывода вручную. Знает базовые понятия LLM и применяет шаблоны промптов.
3. Автоматизирует анализ пользовательских интервью и составление требований с помощью ИИ. Применяет LLM для генерации и валидации моделей (BPMN, UML). Проверяет и устраняет пробелы в требованиях через автоматическое сравнение и трассировку разных видов требований и моделей. Оптимизирует промпты.
4. Формирует основанный на ИИ процесс сбора, генерации и валидации требований. Создает LLM-агентов для анализа требований, отслеживания изменений и генерации спецификаций. Внедряет ИИ в аналитические процессы на уровне организации, сокращая время анализа на 30-50%
Что думаете? Возможен 4-й вариант? Или ИИ-трансформирующий аналитик должен делать что-то другое?
🔥20👍6❤3👎2
На днях готовил велосипеды к сезону, сразу 4 штуки — чистил, смазывал, подтягивал. Очень медитативное занятие. Сразу вспомнил книгу, про которую забыл здесь написать — "Дзен и искусство ухода за мотоциклом" Робета Пирсига.
Книга не про дзен и не про мотоциклы, хотя и про них тоже. Но больше она про то — на что мы обращаем внимание, а что игнорируем; что мы хотим делать, а чего (может быть, неосознанно) — избегаем; что мы проверяем, а про что на автомате думаем — "ну, это точно не то"; что для нас важно, и что бы — нам хотелось — подольше длилось, а что — поскорее бы закончилось. Ну и про человека, который хотел понять, что такое "качество" и в итоге сошел с ума.
Кстати, почему-то из названия на русском убрали вторую часть: исследование ценностей. Про ценности в книге много, и много про философию, хотя герой иногда переиначивает мысли классических философов под свои цели и идеи.
Но безотносительно правильности всех идей, книга-то сейчас суперактуальна! Особенно в связи с появлением генеративного ИИ.
Она про отношение к работе.
Вот цитата про механиков, которые не хотят разбираться (и не чувствуют качества):
Вот это как раз про неравнодушие. Ты или хочешь побыстрее закончить задачу и забыть про неё, либо ты хочешь сделать свою работу максимально качественно. Я всегда стремлюсь к качеству, поэтому некоторые мои постоянные заказчики говорят: Юра будет делать дольше других, но разберется на гораздо более глубоком уровне (и спроектирует систему, которая будет без больших изменений работать много лет — это уже из опыта).
Тут ИИ поможет тем, кто хочет быстрее расправиться с задачей — и неважно, какой ценой и с каким качеством она будет сделана. ИИ просто усиливает это желание не иметь ничего общего с задачей. А тем, кто хочет качественно выполнить работу — ИИ помогает в рутинных процессах и как терпеливый (и иногда даже знающий и остроумный!) собеседник.
А ещё, всё-таки, там есть про разделение функции и конструкции, про существование системы и её восприятие, про деление системы на отдельные функциональные узлы и компоненты, и про научный метод. Так что можно рекомендовать, как введение в системный анализ и методологию науки.
Книга не про дзен и не про мотоциклы, хотя и про них тоже. Но больше она про то — на что мы обращаем внимание, а что игнорируем; что мы хотим делать, а чего (может быть, неосознанно) — избегаем; что мы проверяем, а про что на автомате думаем — "ну, это точно не то"; что для нас важно, и что бы — нам хотелось — подольше длилось, а что — поскорее бы закончилось. Ну и про человека, который хотел понять, что такое "качество" и в итоге сошел с ума.
Кстати, почему-то из названия на русском убрали вторую часть: исследование ценностей. Про ценности в книге много, и много про философию, хотя герой иногда переиначивает мысли классических философов под свои цели и идеи.
Но безотносительно правильности всех идей, книга-то сейчас суперактуальна! Особенно в связи с появлением генеративного ИИ.
Она про отношение к работе.
Вот цитата про механиков, которые не хотят разбираться (и не чувствуют качества):
Они были как зрители. Такое чувство, будто сами туда только что забрели, а им сунули в руки по гаечному ключу. Нет причастности к работе. Нет такого, мол: «Я – механик». Ровно в 17:00 или когда у них там заканчиваются их восемь часов, они отключаются – и больше ни единой мысли о работе. Они и на работе стараются о ней не думать. По-своему они достигли того же, что и Джон с Сильвией, – живут бок о бок с техникой, но не имеют с ней ничего общего. Вернее, что-то общее с ней у них таки есть, но их собственные «я» – где-то вне ее, отстранены, удалены. Они работают, но им все равно.
За работой я думал как раз об этом наплевательстве в инструкциях к цифровым компьютерам – я редактирую такие тексты. Одиннадцать месяцев в году зарабатываю на жизнь тем, что пишу и правлю технические инструкции, – и знаю, что в них полно ошибок, двусмысленностей, упущений и таких искажений информации, что приходится перечитывать по шесть раз, чтобы хоть что-то понять. Но теперь меня впервые поразило вот что: насколько эти инструкции согласуются с тем зрительским отношением, что я видел в мастерской. Эти инструкции – для зрителей. Они подобраны под такой формат. В каждой строчке сквозит идея: «вот машина, изолированная во времени и пространстве от всего остального во вселенной; она не имеет отношения к тебе, ты не имеешь отношения к ней, знай верти определенные ручки, поддерживай уровень питания, проверяй условия возникновения ошибки…» – и так далее. Вот в чем дело. Механики по своему отношению к машине ничем не отличались от отношения инструкции к машине или от меня, привезшего машину к ним. Мы все были зрителями. И тут меня осенило, что не существует инструкции по истинному уходу за мотоциклом, по самому важному аспекту. Неравнодушие к тому, что делаешь, либо считается несущественным, либо принимается как должное.
Вот это как раз про неравнодушие. Ты или хочешь побыстрее закончить задачу и забыть про неё, либо ты хочешь сделать свою работу максимально качественно. Я всегда стремлюсь к качеству, поэтому некоторые мои постоянные заказчики говорят: Юра будет делать дольше других, но разберется на гораздо более глубоком уровне (и спроектирует систему, которая будет без больших изменений работать много лет — это уже из опыта).
Тут ИИ поможет тем, кто хочет быстрее расправиться с задачей — и неважно, какой ценой и с каким качеством она будет сделана. ИИ просто усиливает это желание не иметь ничего общего с задачей. А тем, кто хочет качественно выполнить работу — ИИ помогает в рутинных процессах и как терпеливый (и иногда даже знающий и остроумный!) собеседник.
А ещё, всё-таки, там есть про разделение функции и конструкции, про существование системы и её восприятие, про деление системы на отдельные функциональные узлы и компоненты, и про научный метод. Так что можно рекомендовать, как введение в системный анализ и методологию науки.
❤27🔥12👍7👎1👏1
Мы на тренинге по интеграциям много разбираем обработку ошибок и мониторинг, захватываем иногда и тему поэтапного раскатывания обновлений (и автоматического отката, если что-то пошло не так), а тут на днях просто эпичная иллюстрация основных концепций.
Может быть вы слышали про падение сервисов Google 12 июня. Почти 8 часов API гугловских облачных продуктов выдавало ошибку 503 на каждый запрос.
Что произошло:
Любое обращение к API в Гугле проходит предварительный контроль: авторизацию, политики доступа, не выбрана ли квота доступа к API и т.п. Это региональный сервис, раскатанный на каждом региональном сервере. Он быстро ходит в свою базу, проверяет политики и разрешает исполнение вызова API или запрещает его. Базы с политиками синхронизированы и реплицируются почти мгновенно. Для скорости работы сервис выполнен в виде бинарника.
29 мая 2025 г. в сервис контроля была добавлена новая фича — дополнительная проверка. Обычно новые версии автоматически накатываются на внутренние проекты, и если там всё хорошо — постепенно раскатываются на все регионы. Если на какой-то стадии пошли ошибки — обновление так же автоматически откатывается. Обычно для обновлений делают "красную кнопку" — флаг, выключающий именно эту новую проверку. Ну и вообще на фичу принято вешать фича-флаги для быстрого включения/отключения.
Но вот эта новая фича по какой-то причине не имела ни красной кнопки, ни фича-флагов. А так как в базу политик не было добавлено записей о новой политике — фича не срабатывала, и обновление без ошибок раскатилось на все регионы. Вот только в нем был дефект, классический студенческий — отсутствовала проверка пустого значения!
И когда 12 июня в базу наконец добавили новую политику — случайно забыли заполнить пару полей. База политик, как мы помним, реплицируется почти мгновенно. А новый бинарник уже был раскатан во всех регионах. И он — угадайте — начал падать с null pointer exception, соответственно перекрывая доступ к вызову API.
Тут начинается какой-то процедурал-боевик, как в кино. За 2 минуты Site Reliability Engineering team отловила и оценила уровень проблемы. За 10 — выяснила причину(!). Ещё за 15 была готова "красная кнопка". Примерно через 40 минут красную кнопку раскатали, и региональные сервера начали возвращаться к работе.
Но в нагруженном регионе (us-central-1) сработал "эффект толпы": накопившиеся перезапросы стали класть поднимающийся сервис контроля политик. Потому что, вы не поверите, для этого сервиса не был настроен механизм экспоненциального откладывания ретраев, поэтому его бомбардировали все сразу. Точнее, даже экспоненциального рандомизированного откладывания. Вот тут писал про них и давал ссылку на хорошую статью. Так что всё остальное время инженеры разбирались с маршрутизацией трафика на менее нагруженные сервера.
Итого:
— Не было проверки на пустые значения;
— Не было "красной кнопки"/фича-флагов;
— Критичные управляющие данные реплицировались одномоментно, а не инкрементно по регионам;
— Код и управляющие данные накатывались в разное время, код не тестировался на разных вариантах корректных и испорченных данных;
— На критичном сервисе не был настроен механизм экспоненциального откладывания ретраев.
Я не знаю, насколько тут помог бы системный аналитик (их в Гугле вроде бы и нет), но каждый раз на тренинге я долблю и долблю: пропишите обработку всех технических ошибок и ошибок в данных! Примите решение по стратегии гарантий доставки! Если есть перепосылки-ретраи — определите механизм задержки и рассинхронизации ретраев! Это выглядит сложно и заморочено, но может уронить нагруженный сервис на несколько часов, как мы видим.
Сам же Гугл обещает, по итогам инцидента:
— сделать сервис проверки политик модульным (чтобы падение одной проверки не валило весь сервис — вот для чего нужно уходить с монолита!)
— Провести аудит всех глобально реплицируемых данных
— Принудить всех изготовителей бинарников использовать фича-флаги
— Улучшить статический анализ кода и тестирование (ну null pointer-то как пропустили?!)
Отчет об инциденте. Будьте внимательны при проектировании API!
Может быть вы слышали про падение сервисов Google 12 июня. Почти 8 часов API гугловских облачных продуктов выдавало ошибку 503 на каждый запрос.
Что произошло:
Любое обращение к API в Гугле проходит предварительный контроль: авторизацию, политики доступа, не выбрана ли квота доступа к API и т.п. Это региональный сервис, раскатанный на каждом региональном сервере. Он быстро ходит в свою базу, проверяет политики и разрешает исполнение вызова API или запрещает его. Базы с политиками синхронизированы и реплицируются почти мгновенно. Для скорости работы сервис выполнен в виде бинарника.
29 мая 2025 г. в сервис контроля была добавлена новая фича — дополнительная проверка. Обычно новые версии автоматически накатываются на внутренние проекты, и если там всё хорошо — постепенно раскатываются на все регионы. Если на какой-то стадии пошли ошибки — обновление так же автоматически откатывается. Обычно для обновлений делают "красную кнопку" — флаг, выключающий именно эту новую проверку. Ну и вообще на фичу принято вешать фича-флаги для быстрого включения/отключения.
Но вот эта новая фича по какой-то причине не имела ни красной кнопки, ни фича-флагов. А так как в базу политик не было добавлено записей о новой политике — фича не срабатывала, и обновление без ошибок раскатилось на все регионы. Вот только в нем был дефект, классический студенческий — отсутствовала проверка пустого значения!
И когда 12 июня в базу наконец добавили новую политику — случайно забыли заполнить пару полей. База политик, как мы помним, реплицируется почти мгновенно. А новый бинарник уже был раскатан во всех регионах. И он — угадайте — начал падать с null pointer exception, соответственно перекрывая доступ к вызову API.
Тут начинается какой-то процедурал-боевик, как в кино. За 2 минуты Site Reliability Engineering team отловила и оценила уровень проблемы. За 10 — выяснила причину(!). Ещё за 15 была готова "красная кнопка". Примерно через 40 минут красную кнопку раскатали, и региональные сервера начали возвращаться к работе.
Но в нагруженном регионе (us-central-1) сработал "эффект толпы": накопившиеся перезапросы стали класть поднимающийся сервис контроля политик. Потому что, вы не поверите, для этого сервиса не был настроен механизм экспоненциального откладывания ретраев, поэтому его бомбардировали все сразу. Точнее, даже экспоненциального рандомизированного откладывания. Вот тут писал про них и давал ссылку на хорошую статью. Так что всё остальное время инженеры разбирались с маршрутизацией трафика на менее нагруженные сервера.
Итого:
— Не было проверки на пустые значения;
— Не было "красной кнопки"/фича-флагов;
— Критичные управляющие данные реплицировались одномоментно, а не инкрементно по регионам;
— Код и управляющие данные накатывались в разное время, код не тестировался на разных вариантах корректных и испорченных данных;
— На критичном сервисе не был настроен механизм экспоненциального откладывания ретраев.
Я не знаю, насколько тут помог бы системный аналитик (их в Гугле вроде бы и нет), но каждый раз на тренинге я долблю и долблю: пропишите обработку всех технических ошибок и ошибок в данных! Примите решение по стратегии гарантий доставки! Если есть перепосылки-ретраи — определите механизм задержки и рассинхронизации ретраев! Это выглядит сложно и заморочено, но может уронить нагруженный сервис на несколько часов, как мы видим.
Сам же Гугл обещает, по итогам инцидента:
— сделать сервис проверки политик модульным (чтобы падение одной проверки не валило весь сервис — вот для чего нужно уходить с монолита!)
— Провести аудит всех глобально реплицируемых данных
— Принудить всех изготовителей бинарников использовать фича-флаги
— Улучшить статический анализ кода и тестирование (ну null pointer-то как пропустили?!)
Отчет об инциденте. Будьте внимательны при проектировании API!
👍47❤10🔥4👀3