В комментариях к предыдущему посту пишут, что продакт и не должен самостоятельно никаких целей определять, его задача — достигать заданных бизнесом показателей.
На это есть ответ в том же канале Product Games — кстати, очень рекомендую, если интересуетесь управлением продуктами. Я на несколько каналов продакт-менеджеров подписан, но они все почему-то странные — либо там бородатые мужики, которые все посты пишут матом, либо сплошная реклама каких-нибудь своих курсов. В этом смысле Product Games — прямо глоток свежего воздуха и чистой речи! (Реклама там тоже есть, но не чрезмерно).
Так вот, пост про разницу в понимании роли менеджера по продукту в разных странах:
в Европе это, действительно — чел, который координирует процессы, принимает готовый roadmap, и KPI — это «чтобы все были довольны». До пользователей далеко, решения принимаются "где-то наверху".
в США — PM отвечает за рост, влияет на стратегию, напрямую работает с выручкой, ценой и активацией. Много автономии, скорости и доверия.
В РФ я сталкивался с разными ожиданиями, даже пытался об этом рассказывать почти 10 лет назад на AgileDays.
Разброс, который я видел: от почти маркетингового содержания — закупка трафика, тюнинг конверсий и лендингов, активации и допродажи, и неважно, в чем вообще смысл продукта (помню, меня это поразило в Нетологии — когда я заикнулся про результат обучения для клиента и улучшение методик, тамошние продакты меня просто не поняли), до мини-CEO своего продукта, с владением бюджетом и ответственностью за бизнес-показатели.
Где-то посередине оказываются "продакты по европейскому образцу" — операционные менеджеры, своими управленческими и лидерскими усилиями переводящие чьё-то видение и роадмэп в реально работающий продукт.
На самом деле CEO ведь тоже не самый главный — он отвечает перед собственниками, инвесторами и советом директоров. И как мини-CEO, тоже будешь отвечать, и делать то, что тебе ставят как KPI.
Я в одной компании присутствовал при смене формы с некоммерческого партнерства (где вся прибыль тратилась на улучшение инфраструктуры и качества услуг, в том числе на удержание топовых экспертов в своей отрасли) на акционерное общество (предназначенное для извлечения прибыли). Это, знаете, как проснуться в совершенно другой организации. Ещё вчера все дружно работали над улучшением качества, а сегодня все всем стали врагами и только и думают — как бы порезать косты и побольше показать дохода.
Или, например, ты думаешь, что твои клиенты — обучающиеся, и выстраиваешь весь продукт под них, а совет директоров тебе говорит: думать нужно о ректорах региональных вузов, основные деньги будем брать от них. То есть продукт резко стал не B2C, а B2B (я придумал обозначение U2U — University to university), и всё совсем другое. Ну и продакт не нужен, больше нужны прошаренные сейлзы. Собственно, продуктовая история на этом закончилась.
Так что нужно выбирать, и выбирать аккуратно. Я про себя точно знаю, что в чистый маркетинг я не хочу идти, мне важно видеть, как идея превращается в работающий продукт и приносит пользу людям. Это, кстати, и в отчете видно: от продактов хотят достижения бизнес-показателей, но только 12% радует эта работа. Остальных больше драйвит создание чего-то нового, креативное решение проблем, глубокое понимание проблем пользователей и внедрение инноваций.
На это есть ответ в том же канале Product Games — кстати, очень рекомендую, если интересуетесь управлением продуктами. Я на несколько каналов продакт-менеджеров подписан, но они все почему-то странные — либо там бородатые мужики, которые все посты пишут матом, либо сплошная реклама каких-нибудь своих курсов. В этом смысле Product Games — прямо глоток свежего воздуха и чистой речи! (Реклама там тоже есть, но не чрезмерно).
Так вот, пост про разницу в понимании роли менеджера по продукту в разных странах:
в Европе это, действительно — чел, который координирует процессы, принимает готовый roadmap, и KPI — это «чтобы все были довольны». До пользователей далеко, решения принимаются "где-то наверху".
в США — PM отвечает за рост, влияет на стратегию, напрямую работает с выручкой, ценой и активацией. Много автономии, скорости и доверия.
В РФ я сталкивался с разными ожиданиями, даже пытался об этом рассказывать почти 10 лет назад на AgileDays.
Разброс, который я видел: от почти маркетингового содержания — закупка трафика, тюнинг конверсий и лендингов, активации и допродажи, и неважно, в чем вообще смысл продукта (помню, меня это поразило в Нетологии — когда я заикнулся про результат обучения для клиента и улучшение методик, тамошние продакты меня просто не поняли), до мини-CEO своего продукта, с владением бюджетом и ответственностью за бизнес-показатели.
Где-то посередине оказываются "продакты по европейскому образцу" — операционные менеджеры, своими управленческими и лидерскими усилиями переводящие чьё-то видение и роадмэп в реально работающий продукт.
На самом деле CEO ведь тоже не самый главный — он отвечает перед собственниками, инвесторами и советом директоров. И как мини-CEO, тоже будешь отвечать, и делать то, что тебе ставят как KPI.
Я в одной компании присутствовал при смене формы с некоммерческого партнерства (где вся прибыль тратилась на улучшение инфраструктуры и качества услуг, в том числе на удержание топовых экспертов в своей отрасли) на акционерное общество (предназначенное для извлечения прибыли). Это, знаете, как проснуться в совершенно другой организации. Ещё вчера все дружно работали над улучшением качества, а сегодня все всем стали врагами и только и думают — как бы порезать косты и побольше показать дохода.
Или, например, ты думаешь, что твои клиенты — обучающиеся, и выстраиваешь весь продукт под них, а совет директоров тебе говорит: думать нужно о ректорах региональных вузов, основные деньги будем брать от них. То есть продукт резко стал не B2C, а B2B (я придумал обозначение U2U — University to university), и всё совсем другое. Ну и продакт не нужен, больше нужны прошаренные сейлзы. Собственно, продуктовая история на этом закончилась.
Так что нужно выбирать, и выбирать аккуратно. Я про себя точно знаю, что в чистый маркетинг я не хочу идти, мне важно видеть, как идея превращается в работающий продукт и приносит пользу людям. Это, кстати, и в отчете видно: от продактов хотят достижения бизнес-показателей, но только 12% радует эта работа. Остальных больше драйвит создание чего-то нового, креативное решение проблем, глубокое понимание проблем пользователей и внедрение инноваций.
5🔥13👍6👎1👏1🤔1
У Жени Калинина ("Школа трекеров") в рассылке подсмотрел отличную мысль про применение ИИ в бизнесе. Сейчас же все побежали, всем везде нужен ИИ. В какую тусовку не придёшь — все обсуждают ИИ.
У аналииков ИИ, у разработчиков ИИ, у архитекторов, у девопсов, у врачей, у учителей, у писателей — все только про ИИ говорят (имея в виду в основном LLM, конечно). В последнее время — про агентов.
Но эффект не очень виден — по крайне мере, не очень однозначен. Кому-то помогает, а кому-то вообще нет. На Pimon я слушал доклад про инструмент для настройки мэппинга и преобразования данных в шине при помощи LLM. У слушателей был главный вопрос — зачем?
Так вот, с точки зрения бизнеса, внедрение ИИ — это гипотеза. Гипотеза, что есть шанс преодолеть какое-то ограничение в бизнесе (обычно лежащее в цепочке генерации ценности). И тестировать нужно не все вообще гипотезы, а только те, что позволяют преодолеть главное на текущий момент ограничение.
И вот (цитирую рассылку) ИИ очень хорошо решает проблему, когда у вас чего-то много и вы не успеваете это обрабатывать. То есть приходится от чего-то отказываться. Например, у меня в бытность CPO всегда было в бэклоге штук 40-50 гипотез и идей, которые стоит попробовать, но до них руки не доходят. Даже подумать про них пристально нет времени. У меня и KPI такой был специальный — время зависания новой идеи среди входящих, до принятия решения по ней.
Типичная задача для ИИ-агента. Можно в него вгрузить описание продукта, роадмэп, основных стейкхолдеров и метрики, и пусть себе анализирует, насколько идею будет сложно сделать и насколько большой она потенциально даст эффект. Да, он это посчитает как-то по среднему. Но это будет уже что-то, к этому можно отнестить. Зато машина железная, считает быстро и не останавливается на поспать. В первом приближении он бы мои 50 идей разобрал до детального состояния за день, только токены подбрасывай.
Если бы, конечно, именно это было главным ограничением.
Мы же помним, что по Голдратту главное ограничение в каждый момент одно. И отследить его можно по недозагруженности следующего звена в производственной цепочке. Руки и головы есть, но они ждут задачу — не хватает входящих деталей (в нашем случае — информации. В наших проектах вообще только две причины простоев: любо люди ждут информацию, либо информация ждет людей).
Если у вас и так сильно загружены разработчики — нет смысла увеличивать число написанных постановок, их всё равно будет некому делать. Нужно сначала разработку разгрузить. И так далее. Опасность тут в том, что у нас зачастую каждая функция отвечает за себя, а не за весь процесс от начала до конца. А локальная оптимизация одного участка ведет к росту незавершенки, а не росту выпуска. Я до сих пор вижу, как в одном продукте продолжают реализацию разработанной мной ещё в 2022 году дорожной карты; я уже три года там не работаю, а они её всё никак не сделают.
Другой эффект, о котором тоже нужно помнить — узкое место есть всегда. И как только вы разгрузили его в одном месте, оно тут же появляется в другом, и нужно теперь найти новое ограничение.
В общем, применяйте генеративный ИИ не где попало, а где у вас сейчас главное ограничение! Тогда и эффект будет значимый.
У аналииков ИИ, у разработчиков ИИ, у архитекторов, у девопсов, у врачей, у учителей, у писателей — все только про ИИ говорят (имея в виду в основном LLM, конечно). В последнее время — про агентов.
Но эффект не очень виден — по крайне мере, не очень однозначен. Кому-то помогает, а кому-то вообще нет. На Pimon я слушал доклад про инструмент для настройки мэппинга и преобразования данных в шине при помощи LLM. У слушателей был главный вопрос — зачем?
Так вот, с точки зрения бизнеса, внедрение ИИ — это гипотеза. Гипотеза, что есть шанс преодолеть какое-то ограничение в бизнесе (обычно лежащее в цепочке генерации ценности). И тестировать нужно не все вообще гипотезы, а только те, что позволяют преодолеть главное на текущий момент ограничение.
И вот (цитирую рассылку) ИИ очень хорошо решает проблему, когда у вас чего-то много и вы не успеваете это обрабатывать. То есть приходится от чего-то отказываться. Например, у меня в бытность CPO всегда было в бэклоге штук 40-50 гипотез и идей, которые стоит попробовать, но до них руки не доходят. Даже подумать про них пристально нет времени. У меня и KPI такой был специальный — время зависания новой идеи среди входящих, до принятия решения по ней.
Типичная задача для ИИ-агента. Можно в него вгрузить описание продукта, роадмэп, основных стейкхолдеров и метрики, и пусть себе анализирует, насколько идею будет сложно сделать и насколько большой она потенциально даст эффект. Да, он это посчитает как-то по среднему. Но это будет уже что-то, к этому можно отнестить. Зато машина железная, считает быстро и не останавливается на поспать. В первом приближении он бы мои 50 идей разобрал до детального состояния за день, только токены подбрасывай.
Если бы, конечно, именно это было главным ограничением.
Мы же помним, что по Голдратту главное ограничение в каждый момент одно. И отследить его можно по недозагруженности следующего звена в производственной цепочке. Руки и головы есть, но они ждут задачу — не хватает входящих деталей (в нашем случае — информации. В наших проектах вообще только две причины простоев: любо люди ждут информацию, либо информация ждет людей).
Если у вас и так сильно загружены разработчики — нет смысла увеличивать число написанных постановок, их всё равно будет некому делать. Нужно сначала разработку разгрузить. И так далее. Опасность тут в том, что у нас зачастую каждая функция отвечает за себя, а не за весь процесс от начала до конца. А локальная оптимизация одного участка ведет к росту незавершенки, а не росту выпуска. Я до сих пор вижу, как в одном продукте продолжают реализацию разработанной мной ещё в 2022 году дорожной карты; я уже три года там не работаю, а они её всё никак не сделают.
Другой эффект, о котором тоже нужно помнить — узкое место есть всегда. И как только вы разгрузили его в одном месте, оно тут же появляется в другом, и нужно теперь найти новое ограничение.
В общем, применяйте генеративный ИИ не где попало, а где у вас сейчас главное ограничение! Тогда и эффект будет значимый.
3👍26🔥12❤4
По поводу продуктового подхода мы тут немного зарубились в комментах с Димой Безуглым. Я, причем, даже вполне одобряю и приветствую этот самый продуктовый подход, но давайте поймем, в чем он выражается?
Я считаю — у любого явления должны быть свои проявления. За изменением в способе мышления должна следовать перестройка способа деятельности. И это можно отследить. Ну не может быть такого, что делаем мы всё так же, как и раньше, но теперь у нас продуктовый подход! Хотя, если посмотреть на Agile и SAFe...
И наоборот — в конце концов, мы же знаем, что критерием научного подхода является не доказательство правильности, а фальсифицируемость — какие признаки помогут нам установить, что продуктовым подходом тут и не пахнет?
Есть хороший пример про школы, мне один директор подсказал: руководство может сколько угодно говорить, как они ориентированы на ребенка, но посмотрите — на каком уровне висят плакаты на стенах? На уровне глаз детей или взрослых?
Вот хочется такие же критерии про продуктовый подход. Заходишь в офис, и сразу видишь — тут продуктовый подход. А вот у этой — не-а, вообще другой какой-то. Что это может быть?
Ну, точно понятно, когда не. Это мне в одной организации директор по разработке говорил — а кто такие продакты? Какая от них польза? Как пользователи работают — бизнес-аналитики опишут. Удобные интерфейсы дизайнеры нарисуют. Даже CSI и NPS мы в опросах выясняем регулярно. Roadmap по функциям верхнее начальство спустит, исходя из своих соображений. А продакты ваши что делают?
Тут как раз всё понятно. И, глядишь, года через три — они уже и сами продактов нанимают, разобрались.
А вот если даже и продакты есть, как узнать — настоящие они, или для виду? Может это и не продакты вовсе, а, например, маркетологи. Или PO с чисто технической ролью — карточки по канбан-доске двигать.
Я попробую накинуть, а вы, пожалуйста, отреагируйте как-нибудь — отзывается, или совсем не то:
* Связь функций и деятельности пользователей. Вот прямо в явном виде: есть такой документ/рисунок, где видно, как какая-то функция на какую-то деятельность влияет. Может быть даже функция-деятельность-метрика (внедрение функции ведет к изменению деятельности, что ведет к изменению целевой метрики). Это, если роль пользователя добавить, Impact map получается. Ну или карта гипотез, как её Александр Бындю перебрендировал.
(Вот как надо, кстати говоря! Я на курсе-то примерно то же самое рассказывал, только упаковать не сумел).
В общем, ни курс не был востребован, ни живьем я ни у кого такой карты не видел (ну, кроме как у себя). Ну ладно, изменение деятельности — это слишком сложно, но хотя бы связь функций с метриками? То есть, набиваем бэклог не по принципу "что влезает", а по текущим целям и показателями продуктовых метрик. Можно даже таблицу составить — какая функция на какую метрику и в каком масштабе влияет. Мне Леша Кулаков (директор по продукту Ridero) такую показывал — у него ещё шкала влияния была нелинейная: 1,3,9. Гипотезы, конечно, но хоть что-то.
Или хотя бы связку функций с ролями. Помню, у меня в одном продукие было штук 12 стейкхолдеров, я себе огромный Mind Map распечатал, и фломастерами там закрашивал — в какую сторону сейчас продукт движется, чьи потребности он в первую очередь обслуживает и где проблемы возникают.
Критерий: есть ли артефакт, в котором можно посмотреть — какие функции для кого и зачем сделаны? Как они должны были повлиять на поведение/метрики, и как реально повлияли?
* Структура и предмет коммуникации. Это сложнее вытащить, но можно по назначенным встречам посмотреть. Кто, с кем и о чем говорит? Если мы хотим внедрить сквозное понимание, зачем мы каждое движение в продукте делаем, то обсуждаем ли мы цели продукта с разработкой и поддержкой? А берем их откуда, это с кем обсуждаем и как часто? Пользователи в этом участвуют?
* Представленность пользователей продукта. Откуда мы вообще узнаем о пользователях? Насколько мы от них далеки? Кто их вообще видел в последний раз? Как мы их слышим? Являются ли сами члены команды пользователями?
Вот что сразу в голову приходит, на что ещё стоит посмотреть?
Я считаю — у любого явления должны быть свои проявления. За изменением в способе мышления должна следовать перестройка способа деятельности. И это можно отследить. Ну не может быть такого, что делаем мы всё так же, как и раньше, но теперь у нас продуктовый подход! Хотя, если посмотреть на Agile и SAFe...
И наоборот — в конце концов, мы же знаем, что критерием научного подхода является не доказательство правильности, а фальсифицируемость — какие признаки помогут нам установить, что продуктовым подходом тут и не пахнет?
Есть хороший пример про школы, мне один директор подсказал: руководство может сколько угодно говорить, как они ориентированы на ребенка, но посмотрите — на каком уровне висят плакаты на стенах? На уровне глаз детей или взрослых?
Вот хочется такие же критерии про продуктовый подход. Заходишь в офис, и сразу видишь — тут продуктовый подход. А вот у этой — не-а, вообще другой какой-то. Что это может быть?
Ну, точно понятно, когда не. Это мне в одной организации директор по разработке говорил — а кто такие продакты? Какая от них польза? Как пользователи работают — бизнес-аналитики опишут. Удобные интерфейсы дизайнеры нарисуют. Даже CSI и NPS мы в опросах выясняем регулярно. Roadmap по функциям верхнее начальство спустит, исходя из своих соображений. А продакты ваши что делают?
Тут как раз всё понятно. И, глядишь, года через три — они уже и сами продактов нанимают, разобрались.
А вот если даже и продакты есть, как узнать — настоящие они, или для виду? Может это и не продакты вовсе, а, например, маркетологи. Или PO с чисто технической ролью — карточки по канбан-доске двигать.
Я попробую накинуть, а вы, пожалуйста, отреагируйте как-нибудь — отзывается, или совсем не то:
* Связь функций и деятельности пользователей. Вот прямо в явном виде: есть такой документ/рисунок, где видно, как какая-то функция на какую-то деятельность влияет. Может быть даже функция-деятельность-метрика (внедрение функции ведет к изменению деятельности, что ведет к изменению целевой метрики). Это, если роль пользователя добавить, Impact map получается. Ну или карта гипотез, как её Александр Бындю перебрендировал.
(Вот как надо, кстати говоря! Я на курсе-то примерно то же самое рассказывал, только упаковать не сумел).
В общем, ни курс не был востребован, ни живьем я ни у кого такой карты не видел (ну, кроме как у себя). Ну ладно, изменение деятельности — это слишком сложно, но хотя бы связь функций с метриками? То есть, набиваем бэклог не по принципу "что влезает", а по текущим целям и показателями продуктовых метрик. Можно даже таблицу составить — какая функция на какую метрику и в каком масштабе влияет. Мне Леша Кулаков (директор по продукту Ridero) такую показывал — у него ещё шкала влияния была нелинейная: 1,3,9. Гипотезы, конечно, но хоть что-то.
Или хотя бы связку функций с ролями. Помню, у меня в одном продукие было штук 12 стейкхолдеров, я себе огромный Mind Map распечатал, и фломастерами там закрашивал — в какую сторону сейчас продукт движется, чьи потребности он в первую очередь обслуживает и где проблемы возникают.
Критерий: есть ли артефакт, в котором можно посмотреть — какие функции для кого и зачем сделаны? Как они должны были повлиять на поведение/метрики, и как реально повлияли?
* Структура и предмет коммуникации. Это сложнее вытащить, но можно по назначенным встречам посмотреть. Кто, с кем и о чем говорит? Если мы хотим внедрить сквозное понимание, зачем мы каждое движение в продукте делаем, то обсуждаем ли мы цели продукта с разработкой и поддержкой? А берем их откуда, это с кем обсуждаем и как часто? Пользователи в этом участвуют?
* Представленность пользователей продукта. Откуда мы вообще узнаем о пользователях? Насколько мы от них далеки? Кто их вообще видел в последний раз? Как мы их слышим? Являются ли сами члены команды пользователями?
Вот что сразу в голову приходит, на что ещё стоит посмотреть?
👍11❤4🤣3
Отдельная тема для интеграций — сериализация данных. Про неё почему-то мало говорят на "курсах по интеграциям и проектированию API".
А это, между тем, чуть ли не половина успеха интеграционного решения.
Вот, например, CSV. Существует же чуть ли не с 1972 года, говорят, его удобно было на перфокартах пробивать. И ведь до сих пор активно используется! Весь ETL, вся BigData, весь ML на нём только и держится.
А почему? Потому что
* человекочитаемый
* самый легковесный из человеко-читаемых (из оверхеда — только разделители, кавычки, переносы строк и символы экранирования — почти ничего, если сравнивать с JSON или XML)
* самый быстрый для обработки (до 300 тыс. строк в сек, какое API столько выдержит?), отлично параллелится
С другой стороны:
* не стандартизованный (а вы видели CSV с табуляцией? А с палками | в качестве разделителей? А с крышками ^?)
* бессхемный, нетипизированный
* плоский
* невероятно хрупкий — одна лишняя запятая, кавычка или разрыв строки, и конец обработке
Но если мы это понимаем, то можем предположить, что на каждую проблему должно быть своё решение. И действительно — есть CSV Schema , правда в статусе вечного драфта. С другой стороны, есть стандарт метаданных для описания табличных данных в Вебе: https://www.w3.org/TR/tabular-data-primer/
Как обычно, если нет одного стандарта, значит их будет два.
Ну и, конечно, есть альтернативный формат на основе JSON, берущий лучшее из двух миров — JSON Lines, JSONL.
Выглядит примерно так:
Решена проблема с внезапными разрывами строк, вложенными объектами и неоднозначностью разделителей. Правда, для него даже RFC пока нет.
В общем, всё укладывается в теорию гибридов Клейтона Кристенсена — в процессе подрывной инновации индустрия проходит стадию гибридов: парусно-паровые суда, гибридные автомобили, я в одном музее выдел даже гибрид шпаги и пистолета. У нас в интеграциях — странные наполовину JSONы, наполовину CSV; или вот диковинные гибриды JSON и XML (в NoSQL языке запросов JSONiq):
Так что, если вы видите какой-то гибрид (например, гибрид редактора кода и ИИ-генератора), это значит, что мы посреди подрывной инновации.
Правда, Кристенсен это писал про смешанное обучение, но пока подрыва школьной системы не видно — тут ковид одновременно и дал мощный толчок, и так всех напугал, что все хотят вернуться обратно к очным форматам. Ну посмотрим.
А это, между тем, чуть ли не половина успеха интеграционного решения.
Вот, например, CSV. Существует же чуть ли не с 1972 года, говорят, его удобно было на перфокартах пробивать. И ведь до сих пор активно используется! Весь ETL, вся BigData, весь ML на нём только и держится.
А почему? Потому что
* человекочитаемый
* самый легковесный из человеко-читаемых (из оверхеда — только разделители, кавычки, переносы строк и символы экранирования — почти ничего, если сравнивать с JSON или XML)
* самый быстрый для обработки (до 300 тыс. строк в сек, какое API столько выдержит?), отлично параллелится
С другой стороны:
* не стандартизованный (а вы видели CSV с табуляцией? А с палками | в качестве разделителей? А с крышками ^?)
* бессхемный, нетипизированный
* плоский
* невероятно хрупкий — одна лишняя запятая, кавычка или разрыв строки, и конец обработке
Но если мы это понимаем, то можем предположить, что на каждую проблему должно быть своё решение. И действительно — есть CSV Schema , правда в статусе вечного драфта. С другой стороны, есть стандарт метаданных для описания табличных данных в Вебе: https://www.w3.org/TR/tabular-data-primer/
Как обычно, если нет одного стандарта, значит их будет два.
Ну и, конечно, есть альтернативный формат на основе JSON, берущий лучшее из двух миров — JSON Lines, JSONL.
Выглядит примерно так:
["Name", "Session", "Score", "Completed"]
["Gilbert", "2013", 24, true]
["Alexa", "2013", 29, true]
["May", "2012B", 14, false]
["Deloise", "2012A", 19, true]
Решена проблема с внезапными разрывами строк, вложенными объектами и неоднозначностью разделителей. Правда, для него даже RFC пока нет.
В общем, всё укладывается в теорию гибридов Клейтона Кристенсена — в процессе подрывной инновации индустрия проходит стадию гибридов: парусно-паровые суда, гибридные автомобили, я в одном музее выдел даже гибрид шпаги и пистолета. У нас в интеграциях — странные наполовину JSONы, наполовину CSV; или вот диковинные гибриды JSON и XML (в NoSQL языке запросов JSONiq):
[ xs:date("1066-10-14"), <mercury>Hg</mercury>, "ice cream" ]Так что, если вы видите какой-то гибрид (например, гибрид редактора кода и ИИ-генератора), это значит, что мы посреди подрывной инновации.
Правда, Кристенсен это писал про смешанное обучение, но пока подрыва школьной системы не видно — тут ковид одновременно и дал мощный толчок, и так всех напугал, что все хотят вернуться обратно к очным форматам. Ну посмотрим.
😁11❤6👍5🔥2
Сегодня на Flow Андрей Дмитриев представил первые результаты исследования аналитиков. Помните, я кидал ссылку на опрос?
Вот, можно посмотреть на нас всех в массе. Потом ещё будет детальный анализ, а пока вот что известно:
В основном (>50%) аналитики работают в финтехе/банках, заказной разработке и e-commerce. И, в принципе, хотели бы там работать (это привлекательные направления). Но вот вторые тройки выглядят по-разному: в реале это телеком, госка и интеграторы, а в желаемом — HealthTech, MediaTech и инфраструктурные продукты. К ним примыкают образовательные сервисы. Вот чем мы на самом деле хотим заниматься! Здоровьем, развлечениями, инфраструктурой и образованием!
А меньше всего хотят заниматься инфобезом и промышленной сферой.
43% респондентов часто испытывают "синдром самозванца". То есть, сомневаются, что их деятельность — это вообще системный анализ.
Вот, можно посмотреть на нас всех в массе. Потом ещё будет детальный анализ, а пока вот что известно:
В основном (>50%) аналитики работают в финтехе/банках, заказной разработке и e-commerce. И, в принципе, хотели бы там работать (это привлекательные направления). Но вот вторые тройки выглядят по-разному: в реале это телеком, госка и интеграторы, а в желаемом — HealthTech, MediaTech и инфраструктурные продукты. К ним примыкают образовательные сервисы. Вот чем мы на самом деле хотим заниматься! Здоровьем, развлечениями, инфраструктурой и образованием!
А меньше всего хотят заниматься инфобезом и промышленной сферой.
43% респондентов часто испытывают "синдром самозванца". То есть, сомневаются, что их деятельность — это вообще системный анализ.
❤17👍10😱2🙈1
Из каких ролей переходят в аналитики? Мы не знаем. Самый популярный ответ — другое (36%). На втором месте — первая работа в ИТ (21%). На третьем — другая роль в ИТ (не разработчик, не QA, не из поддержки и не тех.пис) — 19%.
Среди предыдущих профессий есть авиадиспетчер, юрист, геолог, пиццамейкер и проектировщик мостов.
Стажеров-системных аналитиков не бывает (1%)
Про задачи: что приходится делать и что нравится делать. Удивительно, но первая тройка совпадает: что делают, то и нравится (ну или наоборот). Это работа с требованиями, с моделями бизнес-процессов и проектирование интеграций.
А вот следующая тройка желаемого: проектирование архитектуры, проектирование систем и ресерч.
Но приходится заниматься управлением изменениями, написанием документации и поддержкой.
Соответственно, все хотят прокачать навыки в system design, solution architecture и проектировании интеграций.
Если это правда — что, нужно срочно делать образовательные продукты для аналитиков по архитектуре и system design?
Среди предыдущих профессий есть авиадиспетчер, юрист, геолог, пиццамейкер и проектировщик мостов.
Стажеров-системных аналитиков не бывает (1%)
Про задачи: что приходится делать и что нравится делать. Удивительно, но первая тройка совпадает: что делают, то и нравится (ну или наоборот). Это работа с требованиями, с моделями бизнес-процессов и проектирование интеграций.
А вот следующая тройка желаемого: проектирование архитектуры, проектирование систем и ресерч.
Но приходится заниматься управлением изменениями, написанием документации и поддержкой.
Соответственно, все хотят прокачать навыки в system design, solution architecture и проектировании интеграций.
Если это правда — что, нужно срочно делать образовательные продукты для аналитиков по архитектуре и system design?
👍24❤8💯7🔥1
Я привез на Flow обновленную карту интеграций.
Обновлений много:
* Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки"
* Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS, REST уровня 3)
* Добавлены JSON:API, HAL, JSON-LD
* SOAP включен в асинхронные методы
* Добавлен WS-RM для SOAP — протокол гарантированной доставки
* Добавлены подходы к целостности транзакций: ACID и BASE
* Добавлено описание паттернов API Gateway и ESB
* Добавлено описание ETL-процесса
* Добавлена CAP-теорема
* Добавлено описание семантик гарантированной доставки
* Раздел "Особенности" объединен с разделом "Когда использовать"
* Исправлены опечатки
А самое главное — я, кажется, придумал шаблон для описания любой технологии интеграции!
Какие вопросы мы должны задать, когда смотрим на технологию?
1. Что это? Протокол, язык, набор принципов, конкретный продукт?
2. Какой верхнеуровневый паттерн? (по Грегору Хопу: файловый обмен, общая БД, удаленный вызов, сообщения)
3. Режим взаимодействия — синхронный или асинхронный? (скорость против пропускной способности)
4. Семантика запроса / интеграционный стиль: RPC, Query, ресурсный (REST 2 lvl — ресурсы и методы HTTP), гипермедиа (REST 3 lvl, HATEOAS), стриминг, публикация/подписка — в общем, как мы смотрим на интеграцию?
5. Протокол: опираемся на HTTP или используем что-то низкоуровневое? Если HTTP — то используем ли строку запроса и хедеры? То есть, получится ли подключить кэширование, маршрутизацию и все эти готовые штуки?
6. Формат сериализации: текстовый или бинарный? Есть ли схема? Обязательна ли она? Насколько строгая типизация? Есть ли сложные структуры: вложенные объекты, массивы, maps, множества?
7. Есть ли возможность определять и передавать кастомные ошибки?
8. Есть ли встроенные средства гарантированной доставки, и какие семантики поддерживаются?
9. Что с безопасностью? Шифрование, аутентификация, контроль прав.
10. Скорость сериализации / десериализации, размер сообщений
11. Есть ли инструменты преобразования данных?
12. Есть ли язык определения интерфейсов / спецификаций?
13. Статус стандартизации / распространенность / надежность / поддержка в разных языках и фреймворках
14. Какие особенные фишки есть у технологии?
15. С какими проблемами мы столкнемся?
Вот такие 15 вопросов, возможно ещё что-то появится. Но уже с этим можно оценивать и сравнивать разные технологии — насколько они близки, что будет стоить переход и имеет ли он смысл, как вообще об этом думать.
Ссылка на актуальную версию карты: https://disk.yandex.ru/i/k69r0Qr39_1P-w
Обновлений много:
* Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки"
* Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS, REST уровня 3)
* Добавлены JSON:API, HAL, JSON-LD
* SOAP включен в асинхронные методы
* Добавлен WS-RM для SOAP — протокол гарантированной доставки
* Добавлены подходы к целостности транзакций: ACID и BASE
* Добавлено описание паттернов API Gateway и ESB
* Добавлено описание ETL-процесса
* Добавлена CAP-теорема
* Добавлено описание семантик гарантированной доставки
* Раздел "Особенности" объединен с разделом "Когда использовать"
* Исправлены опечатки
А самое главное — я, кажется, придумал шаблон для описания любой технологии интеграции!
Какие вопросы мы должны задать, когда смотрим на технологию?
1. Что это? Протокол, язык, набор принципов, конкретный продукт?
2. Какой верхнеуровневый паттерн? (по Грегору Хопу: файловый обмен, общая БД, удаленный вызов, сообщения)
3. Режим взаимодействия — синхронный или асинхронный? (скорость против пропускной способности)
4. Семантика запроса / интеграционный стиль: RPC, Query, ресурсный (REST 2 lvl — ресурсы и методы HTTP), гипермедиа (REST 3 lvl, HATEOAS), стриминг, публикация/подписка — в общем, как мы смотрим на интеграцию?
5. Протокол: опираемся на HTTP или используем что-то низкоуровневое? Если HTTP — то используем ли строку запроса и хедеры? То есть, получится ли подключить кэширование, маршрутизацию и все эти готовые штуки?
6. Формат сериализации: текстовый или бинарный? Есть ли схема? Обязательна ли она? Насколько строгая типизация? Есть ли сложные структуры: вложенные объекты, массивы, maps, множества?
7. Есть ли возможность определять и передавать кастомные ошибки?
8. Есть ли встроенные средства гарантированной доставки, и какие семантики поддерживаются?
9. Что с безопасностью? Шифрование, аутентификация, контроль прав.
10. Скорость сериализации / десериализации, размер сообщений
11. Есть ли инструменты преобразования данных?
12. Есть ли язык определения интерфейсов / спецификаций?
13. Статус стандартизации / распространенность / надежность / поддержка в разных языках и фреймворках
14. Какие особенные фишки есть у технологии?
15. С какими проблемами мы столкнемся?
Вот такие 15 вопросов, возможно ещё что-то появится. Но уже с этим можно оценивать и сравнивать разные технологии — насколько они близки, что будет стоить переход и имеет ли он смысл, как вообще об этом думать.
Ссылка на актуальную версию карты: https://disk.yandex.ru/i/k69r0Qr39_1P-w
Яндекс Диск
Integrations Tech 1.1.0.pdf
Посмотреть и скачать с Яндекс Диска
1🔥80👍17❤7
Flow 25 Kupriyanov.pptx
11 MB
А вот и презентация с доклада про карту интеграций. Она отчасти повторяет карту, но в постраничном формате, и задает ту самую рамку для рассмотрения любой технологии.
Через эту рамку я попробовал несколько технологий разложить:
JSON-RPC: протокол
Паттерн: удаленный вызов
Режим взаимодействия: синхронный
Семантика запроса: RPC
Протокол: не зависит от протокола. Существующие реализации: HTTP, WebSockets, TCP
Формат: текстовый, JSON, свой формат вызовов и ответов. Схемы нет.
Ошибки: встроенные + кастомные (код+описание)
Инструменты преобразования данных: встроенных нет
Безопасность: встроенная в HTTP (SSL)
Семантика доставки: at-most-once
Язык спецификаций: OpenRPC (необязательный; есть генерация кода)
Фишки: легковесный, пакетные запросы
Проблемы: затруднен роутинг, кэширование, мониторинг, передача бинарных данных
Кейсы применения: взаимодействие ИИ-агентов с системами и сервисами (MCP), крипта, отправка команд.
Apache Thrift: язык описания данных и интерфейсов (IDL) + фреймворк кодогенерации
Паттерн: удаленный вызов
Режим взаимодействия: синхронный, асинхронный
Семантика запроса: RPC
Протокол: TCP-сокеты, файл, память, IPC-сокеты, HTTP
Формат: бинарный, компактный, JSON.
Схема: обязательна. Строгая типизация. Сложные структуры.
Ошибки: специальный тип exception
Инструменты преобразования данных: нет
Безопасность: TLS, SASL
Семантика доставки: at-most-once
Язык спецификаций: Thrift (обязателен, генерация кода обязательна)
Фишки: вариативность форматов сериализации и транспортных протоколов
Проблемы: плохая документация, поддерживаемые функции различаются в разных языках.
Кейсы применения: Взаимодействие с разнотипными фронтами; сериализация данных без использования транспортных функций, в т.ч. в Kafka.
И так можно любой способ интеграции расписать, даже совершенно новый для вас.
(Upd.: В комментах есть в формате PDF, а то, говорят, в PPTX красивые шрифты побились :( )
Через эту рамку я попробовал несколько технологий разложить:
JSON-RPC: протокол
Паттерн: удаленный вызов
Режим взаимодействия: синхронный
Семантика запроса: RPC
Протокол: не зависит от протокола. Существующие реализации: HTTP, WebSockets, TCP
Формат: текстовый, JSON, свой формат вызовов и ответов. Схемы нет.
Ошибки: встроенные + кастомные (код+описание)
Инструменты преобразования данных: встроенных нет
Безопасность: встроенная в HTTP (SSL)
Семантика доставки: at-most-once
Язык спецификаций: OpenRPC (необязательный; есть генерация кода)
Фишки: легковесный, пакетные запросы
Проблемы: затруднен роутинг, кэширование, мониторинг, передача бинарных данных
Кейсы применения: взаимодействие ИИ-агентов с системами и сервисами (MCP), крипта, отправка команд.
Apache Thrift: язык описания данных и интерфейсов (IDL) + фреймворк кодогенерации
Паттерн: удаленный вызов
Режим взаимодействия: синхронный, асинхронный
Семантика запроса: RPC
Протокол: TCP-сокеты, файл, память, IPC-сокеты, HTTP
Формат: бинарный, компактный, JSON.
Схема: обязательна. Строгая типизация. Сложные структуры.
Ошибки: специальный тип exception
Инструменты преобразования данных: нет
Безопасность: TLS, SASL
Семантика доставки: at-most-once
Язык спецификаций: Thrift (обязателен, генерация кода обязательна)
Фишки: вариативность форматов сериализации и транспортных протоколов
Проблемы: плохая документация, поддерживаемые функции различаются в разных языках.
Кейсы применения: Взаимодействие с разнотипными фронтами; сериализация данных без использования транспортных функций, в т.ч. в Kafka.
И так можно любой способ интеграции расписать, даже совершенно новый для вас.
(Upd.: В комментах есть в формате PDF, а то, говорят, в PPTX красивые шрифты побились :( )
🔥32❤5👍2🙏2
На любой конференции важны не только доклады, но и кулуары. На Flow для этого есть специальный формат — дискуссионная зона, где можно ещё долго обсуждать доклад и связанные темы, иногда это обсуждение длится дольше, чем сам доклад, и даже превращается в мастер-класс.
А для спикеров есть спикерский ужин. Это лучший нетворкинг, поэтому всех призываю подавать доклады, если вы хотите от конфы именно новых встреч и знакомств. А ещё можно узнать что-нибудь новое или осмыслить существующее.
Я вот, например, в разговоре с Дмитрием Таболичем сформулировал важное понимание про роль архитектора. Обсуждали мы доклад Дениса Бескова про пошаговый алгоритм проектирования архитектуры систем. Ну или system design. Денис его перед конференцией показывал в чате архитекторов (RASA Chat) и у себя в канале.
И вот среди архитекторов в чате разгорелось обсуждение, суть которого свелась к следующему (пересказываю своими словами):
Задачи архитектора настолько разноплановы и разносторонни, что свести их к какой-то единой схеме, или, упаси б-г, алгоритму — совершенно не представляется возможным. Поэтому заниматься таким не нужно, и даже вредно. Всё, что делает архитектор — уникально. Любая систематизация — обман для профанов. Никакие стандарты, таксономии и алгоритмы не работают. Каждый проект уникален, и к каждому нужно подходить с особой стороны, а с какой — может знать только архитектор. Поэтому советы тут скорее навредят и направят не в том направлении. Поэтому и советов никаких никому давать нельзя. В лучшем случае их может давать один опытный архитектор другому опытному архитектору. А тот, естественно, их с негодованием будет отвергать, так как советчик не в курсе всей полноты и сложности ситуации, советует глупость, и вообще, судя по всему, архитектором не является.
Из этого вытекает одно очень важное следствие: обучить архитектора невозможно. Так как всё меняется, один проект не похож на другой, в разное время приходится делать разное — то и определить, кто такой архитектор и чем он занимается, не представляется возможным. Значит, нельзя построить программу обучения архитекторов, это профанация. Чему бы на этой программе не учили — это будет однобокий взгляд и только часть правды. Всей же сложности, с которой архитектор сталкивается в работе передать нельзя, см. выше. Столь же бесперспективной и вредной является идея профессионального стандарта архитектора — это просто оксюморон. А тем более — попытка задавать требования к образованию или уровню квалификации.
Но если научиться быть архитектором невозможно, то откуда тогда берутся архитекторы? И вот тут я словил инсайт: дело в том, что архитекторами просто становятся. Невозможно научиться, нужно стать им. Просто в какой-то момент ты понимаешь — да, я архитектор. Появляется такое внутреннее неоспоримое убеждение. После этого, конечно, тебе уже не нужны никакие подпорки в виде алгоритмов, стандартов или чего-то там, они даже смешны. Ведь ты — архитектор [Гарри], и всё, что ты делаешь — дело архитектора. И никто другой тебе не может сказать, что ты — не он. Да кто ты такой, чтобы мне говорить, кто я такой? Сам ты не архитектор. Косвенным признаком можно считать, когда архитекторы тебя признают в тусовке своим. Как лебедя из сказки Андерсена. Думаешь — пусть они меня заклюют, эти прекрасные птицы, ан нет, не клюют — прислушиваются даже и кивают.
Вот, и это не про обучение. Разве гадкий утенок пытался научиться, как стать лебедем? Он просто был им. Так и архитектор — просто в какой-то момент им становишься, и всё, уже никто не сомневается.
Это не про насмотренность, опыт или экспертность в программировании. Это про уверенность. У аналитиков, правда, с этим большие проблемы — видели в опросе, 54% испытывают синдром самозванца часто или всегда. Обращали внимание, как люди говорят о своей профессии? "Ну, я работаю кем-то вроде системного аналитика..."
Ни один программист не скажет, что работает "кем-то вроде фронтендера", у них всё чётко. И архитектор не будет сомневаться. Так что нужно качать не столько знания, сколько уверенность в себе и самоопределение.
А для спикеров есть спикерский ужин. Это лучший нетворкинг, поэтому всех призываю подавать доклады, если вы хотите от конфы именно новых встреч и знакомств. А ещё можно узнать что-нибудь новое или осмыслить существующее.
Я вот, например, в разговоре с Дмитрием Таболичем сформулировал важное понимание про роль архитектора. Обсуждали мы доклад Дениса Бескова про пошаговый алгоритм проектирования архитектуры систем. Ну или system design. Денис его перед конференцией показывал в чате архитекторов (RASA Chat) и у себя в канале.
И вот среди архитекторов в чате разгорелось обсуждение, суть которого свелась к следующему (пересказываю своими словами):
Задачи архитектора настолько разноплановы и разносторонни, что свести их к какой-то единой схеме, или, упаси б-г, алгоритму — совершенно не представляется возможным. Поэтому заниматься таким не нужно, и даже вредно. Всё, что делает архитектор — уникально. Любая систематизация — обман для профанов. Никакие стандарты, таксономии и алгоритмы не работают. Каждый проект уникален, и к каждому нужно подходить с особой стороны, а с какой — может знать только архитектор. Поэтому советы тут скорее навредят и направят не в том направлении. Поэтому и советов никаких никому давать нельзя. В лучшем случае их может давать один опытный архитектор другому опытному архитектору. А тот, естественно, их с негодованием будет отвергать, так как советчик не в курсе всей полноты и сложности ситуации, советует глупость, и вообще, судя по всему, архитектором не является.
Из этого вытекает одно очень важное следствие: обучить архитектора невозможно. Так как всё меняется, один проект не похож на другой, в разное время приходится делать разное — то и определить, кто такой архитектор и чем он занимается, не представляется возможным. Значит, нельзя построить программу обучения архитекторов, это профанация. Чему бы на этой программе не учили — это будет однобокий взгляд и только часть правды. Всей же сложности, с которой архитектор сталкивается в работе передать нельзя, см. выше. Столь же бесперспективной и вредной является идея профессионального стандарта архитектора — это просто оксюморон. А тем более — попытка задавать требования к образованию или уровню квалификации.
Но если научиться быть архитектором невозможно, то откуда тогда берутся архитекторы? И вот тут я словил инсайт: дело в том, что архитекторами просто становятся. Невозможно научиться, нужно стать им. Просто в какой-то момент ты понимаешь — да, я архитектор. Появляется такое внутреннее неоспоримое убеждение. После этого, конечно, тебе уже не нужны никакие подпорки в виде алгоритмов, стандартов или чего-то там, они даже смешны. Ведь ты — архитектор [Гарри], и всё, что ты делаешь — дело архитектора. И никто другой тебе не может сказать, что ты — не он. Да кто ты такой, чтобы мне говорить, кто я такой? Сам ты не архитектор. Косвенным признаком можно считать, когда архитекторы тебя признают в тусовке своим. Как лебедя из сказки Андерсена. Думаешь — пусть они меня заклюют, эти прекрасные птицы, ан нет, не клюют — прислушиваются даже и кивают.
Вот, и это не про обучение. Разве гадкий утенок пытался научиться, как стать лебедем? Он просто был им. Так и архитектор — просто в какой-то момент им становишься, и всё, уже никто не сомневается.
Это не про насмотренность, опыт или экспертность в программировании. Это про уверенность. У аналитиков, правда, с этим большие проблемы — видели в опросе, 54% испытывают синдром самозванца часто или всегда. Обращали внимание, как люди говорят о своей профессии? "Ну, я работаю кем-то вроде системного аналитика..."
Ни один программист не скажет, что работает "кем-то вроде фронтендера", у них всё чётко. И архитектор не будет сомневаться. Так что нужно качать не столько знания, сколько уверенность в себе и самоопределение.
🔥38🤔7👌3🫡3💯2
Посты про роль архитектора вызвали просто бурю обсуждений в комментах. Попробую ещё с одной стороны зайти.
Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем?
Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена.
Предлагалось деление на проектирование и сбор материалов для проектирования.
Но мне кажется (из опыта работы архитектором и опыта работы с архитекторами), что архитектор не обязательно проектирует. Продуктом архитектора часто является не сама архитектура системы, а решения относительно архитектуры.
Причём часто это могут быть решения о том, чего мы не делаем. Или что мы делаем не в системе. В общем, мы можем рассмотреть деятельность архитектора через рамку принятия решений.
А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт.
То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы.
И архитектор не столько проектирует, сколько решает конфликты. А решать их можно по-разному: сотрудничать, побеждать, искать компромисс, избегать, приспосабливаться, находить взаимовыгодные решения.
У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах.
Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон.
Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать.
Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем?
Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена.
Предлагалось деление на проектирование и сбор материалов для проектирования.
Но мне кажется (из опыта работы архитектором и опыта работы с архитекторами), что архитектор не обязательно проектирует. Продуктом архитектора часто является не сама архитектура системы, а решения относительно архитектуры.
Причём часто это могут быть решения о том, чего мы не делаем. Или что мы делаем не в системе. В общем, мы можем рассмотреть деятельность архитектора через рамку принятия решений.
А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт.
То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы.
И архитектор не столько проектирует, сколько решает конфликты. А решать их можно по-разному: сотрудничать, побеждать, искать компромисс, избегать, приспосабливаться, находить взаимовыгодные решения.
У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах.
Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон.
Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать.
👍21❤3🔥2👎1
Завершая тему про конфликты. Аналитик, конечно же, тоже работает с конфликтами. Вообще, если вы не нашли ни одного конфликта в своем проекте — это очень тревожный сигнал, возможно, вы что-то упускаете.
На днях мне попалась книга Патрика Ленсиони "5 пороков команды", и второй по счету порок — страх конфликтов (до него — отсутствие доверия, а за ним — безответственность, нетребовательность, безразличие к результатам. Ленсиони рисует пирамидку, и говорит, что один порок тянет за собой следующий).
Так вот, про страх конфликтов. Тут Ленсиони говорит про скучные совещания. А скучные они ровно потому, что на них не вскрываются и не обсуждаются никакие конфликты. Если нет конфликта — такое совещание вообще не нужно. Это может быть запрос информации, или оповещение, в общем — это совещание должно быть письмом. А в настоящем совещании должна быть драматургия, конфликт!
И если кажется, что его нет, то нужно поискать. По-английски он даже использует фразу conflict mining — добыча конфликтов.
И это задача лидера — искать их, вытаскивать и обострять, не давать закапывать.
Ну и задача аналитика тоже. И тут можно задать резонный вопрос: должен ли аналитик быть лидером? Или он должен только готовить материалы для принятия решений, а обеспечивать их принятие должна какая-то другая роль, от которой это лидерство ожидают? Тот же тех.лид, или архитектор — не видел архитекторов, которые не были бы лидерами и не могли бы принимать решения и добиваться принятия решений — тогда это не архитектор, а проектировщик.
В этом смысле мне лично очень нравится роль фасилитатора или даже медиатора. Я (как аналитик) — внешний для вашего бизнеса и для ваших систем актор. Я не встаю ни на чью сторону, я не ангажирован. Я представляю интересы бизнеса (владельца, вообще говоря, CEO) и моя задача — обеспечить решение задачи наиболее эффективным способом.
Это, конечно, относится к аналитикам, не аллоцированным по командам. Изнутри команды трудно позиционировать себя независимым невовлеченным экспертом.
Но уж конфликты выкапывать нужно как можно раньше! Вопрос, конечно — как в вашей организации в целом принято обращаться с конфликтами — вытаскивать или замалчивать? И какие типовые способы решения применяются.
На днях мне попалась книга Патрика Ленсиони "5 пороков команды", и второй по счету порок — страх конфликтов (до него — отсутствие доверия, а за ним — безответственность, нетребовательность, безразличие к результатам. Ленсиони рисует пирамидку, и говорит, что один порок тянет за собой следующий).
Так вот, про страх конфликтов. Тут Ленсиони говорит про скучные совещания. А скучные они ровно потому, что на них не вскрываются и не обсуждаются никакие конфликты. Если нет конфликта — такое совещание вообще не нужно. Это может быть запрос информации, или оповещение, в общем — это совещание должно быть письмом. А в настоящем совещании должна быть драматургия, конфликт!
И если кажется, что его нет, то нужно поискать. По-английски он даже использует фразу conflict mining — добыча конфликтов.
И это задача лидера — искать их, вытаскивать и обострять, не давать закапывать.
Ну и задача аналитика тоже. И тут можно задать резонный вопрос: должен ли аналитик быть лидером? Или он должен только готовить материалы для принятия решений, а обеспечивать их принятие должна какая-то другая роль, от которой это лидерство ожидают? Тот же тех.лид, или архитектор — не видел архитекторов, которые не были бы лидерами и не могли бы принимать решения и добиваться принятия решений — тогда это не архитектор, а проектировщик.
В этом смысле мне лично очень нравится роль фасилитатора или даже медиатора. Я (как аналитик) — внешний для вашего бизнеса и для ваших систем актор. Я не встаю ни на чью сторону, я не ангажирован. Я представляю интересы бизнеса (владельца, вообще говоря, CEO) и моя задача — обеспечить решение задачи наиболее эффективным способом.
Это, конечно, относится к аналитикам, не аллоцированным по командам. Изнутри команды трудно позиционировать себя независимым невовлеченным экспертом.
Но уж конфликты выкапывать нужно как можно раньше! Вопрос, конечно — как в вашей организации в целом принято обращаться с конфликтами — вытаскивать или замалчивать? И какие типовые способы решения применяются.
❤18🔥10🤔9👍4
Системный сдвиг pinned «Я привез на Flow обновленную карту интеграций. Обновлений много: * Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки" * Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS…»
Давайте легкую тему для пятницы. Как вы даете имена своим системам или их версиям?
У меня с этим всегда были проблемы. Самая моя долгоживущая система долго вообще никак не называлась. Ей уже полгода пользовались, а названия не было. Пользователи её называли "считалка". Ну, такое. В итоге назвали её АСК: Автоматизированная система казначейства. Причем он оказался мужчиной: "Опять это вас АСК не работает!"
А другую систему, для маржинальной торговли, тоже долго не называли, потом так и прижилось - Margin Trading.
Ещё в одной системе были десятки сервисов с трехбуквенными аббревиатурами: PLP, PLE, XLE, LMS, LRS, FMS и т.д. Своим всё понятно, человек со стороны не разберется.
Кому-то это легко дается легко — мой младший ребенок отлично придумывает названия: смастерил что-то из лего, и говорит — это Шушик! Смотришь — ну точно, вылитый Шушик, по-другому и не назовешь.
Мне это дается мучительно. Если бы я давал какой-нибудь системе имя, поступил бы как Шарик из Простоквашино: написал бы первое пришедшее в голову, например "утюг".
В одной компании версии систем называли именами озер: Байкал, Селигер, Сенеж. Стойкая ассоциация с чем-то военным.
В другой компании — очень российской! — версии были по номерам, но сама система называлась почему-то по имени города в Калифорнии - Аламеда.
В иностранном ПО любят кроме номеров версиям давать ещё и кодовые имена. У ОС Android это были разные сласти: мармелад, нуга, пирог, орео. У Microsoft - названия городов. У Apple - то примечательные места, то города, то кошки, то сорта яблок.
У OpenEdX релизы именуются по видам деревьев, выбранных по первым буквам алфавита. Правда, они дошли уже до Ulmo (Эвкрифия сердцелистная) и Verawood (на русском вообще названия нет), не знаю, что дальше будут делать.
Самые креативные названия версий у Ubuntu, есть даже целая страница: https://wiki.ubuntu.com/DevelopmentCodeNames, там у них всякие "Бдительные Бородавочники" и "Сметливые Селезни" (прилагательное + животное на одну букву).
У Intel кодовые имена процессоров назывались по горам, рекам, озерам и городам вокруг мест, где расположены фабрики по производству. До сих пор помню фотку в офисе Бабаяна: "Команда Эльбруса покорила МакКинли" (гора на Аляске, кодовое имя одной из версий процессора Itanium).
Фантазия разнообразна: кто-то использует имена героев фильмов, кто-то — названия химических элементов, женские имена, названия национальных парков, драгоценных камней, звезд и планет, и так далее. Хотя планеты у нас и сами названы по именам римских богов. А вот астрофизик Батыгин собирается назвать предсказанную им транснептуновую планету "Белая стрекоза любви". Почему нет.
Я пытался найти какие-то исследования о воздействии именований релизов... на что-нибудь. Но не нашел. Попадаются только статьи про автоматическую генерацию описаний — release notes. Так что мы не знаем — приносит ли кодовое именование пользу, или это просто приятное развлечение.
А как у вас принято именовать релизы? Номера, кодовые имена, какие-то правила их присвоения?
У меня с этим всегда были проблемы. Самая моя долгоживущая система долго вообще никак не называлась. Ей уже полгода пользовались, а названия не было. Пользователи её называли "считалка". Ну, такое. В итоге назвали её АСК: Автоматизированная система казначейства. Причем он оказался мужчиной: "Опять это вас АСК не работает!"
А другую систему, для маржинальной торговли, тоже долго не называли, потом так и прижилось - Margin Trading.
Ещё в одной системе были десятки сервисов с трехбуквенными аббревиатурами: PLP, PLE, XLE, LMS, LRS, FMS и т.д. Своим всё понятно, человек со стороны не разберется.
Кому-то это легко дается легко — мой младший ребенок отлично придумывает названия: смастерил что-то из лего, и говорит — это Шушик! Смотришь — ну точно, вылитый Шушик, по-другому и не назовешь.
Мне это дается мучительно. Если бы я давал какой-нибудь системе имя, поступил бы как Шарик из Простоквашино: написал бы первое пришедшее в голову, например "утюг".
В одной компании версии систем называли именами озер: Байкал, Селигер, Сенеж. Стойкая ассоциация с чем-то военным.
В другой компании — очень российской! — версии были по номерам, но сама система называлась почему-то по имени города в Калифорнии - Аламеда.
В иностранном ПО любят кроме номеров версиям давать ещё и кодовые имена. У ОС Android это были разные сласти: мармелад, нуга, пирог, орео. У Microsoft - названия городов. У Apple - то примечательные места, то города, то кошки, то сорта яблок.
У OpenEdX релизы именуются по видам деревьев, выбранных по первым буквам алфавита. Правда, они дошли уже до Ulmo (Эвкрифия сердцелистная) и Verawood (на русском вообще названия нет), не знаю, что дальше будут делать.
Самые креативные названия версий у Ubuntu, есть даже целая страница: https://wiki.ubuntu.com/DevelopmentCodeNames, там у них всякие "Бдительные Бородавочники" и "Сметливые Селезни" (прилагательное + животное на одну букву).
У Intel кодовые имена процессоров назывались по горам, рекам, озерам и городам вокруг мест, где расположены фабрики по производству. До сих пор помню фотку в офисе Бабаяна: "Команда Эльбруса покорила МакКинли" (гора на Аляске, кодовое имя одной из версий процессора Itanium).
Фантазия разнообразна: кто-то использует имена героев фильмов, кто-то — названия химических элементов, женские имена, названия национальных парков, драгоценных камней, звезд и планет, и так далее. Хотя планеты у нас и сами названы по именам римских богов. А вот астрофизик Батыгин собирается назвать предсказанную им транснептуновую планету "Белая стрекоза любви". Почему нет.
Я пытался найти какие-то исследования о воздействии именований релизов... на что-нибудь. Но не нашел. Попадаются только статьи про автоматическую генерацию описаний — release notes. Так что мы не знаем — приносит ли кодовое именование пользу, или это просто приятное развлечение.
А как у вас принято именовать релизы? Номера, кодовые имена, какие-то правила их присвоения?
👍11😁7❤4🔥1
Какие вы знаете методы приоритизации? Например, функций продукта или пользовательских историй?
MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает?
В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4.
Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного.
Например, просто попарное сравнение функций. Из пары десятков сложно выбрать, но уже из двух-то можно сказать, какая выглядит более важной? И, может быть, даже без строгого анализа, чисто интуитивно. Ну или поставить на групповое обсуждение, тоже интересно.
Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков.
Идея довольно простая — все начинают с одинакового значения рейтинга, а после каждой "игры" (в нашем случае — выбора из двух) победитель получает прирост рейтинга с учетом рейтинга того, кого он победил.
Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога).
Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7.
Попробуйте, очень интересно, что у вас получится?
MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает?
В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4.
Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного.
Например, просто попарное сравнение функций. Из пары десятков сложно выбрать, но уже из двух-то можно сказать, какая выглядит более важной? И, может быть, даже без строгого анализа, чисто интуитивно. Ну или поставить на групповое обсуждение, тоже интересно.
Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков.
Идея довольно простая — все начинают с одинакового значения рейтинга, а после каждой "игры" (в нашем случае — выбора из двух) победитель получает прирост рейтинга с учетом рейтинга того, кого он победил.
Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога).
Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7.
Попробуйте, очень интересно, что у вас получится?
🔥27❤6🤔1
Я уже писал про митап Pimon 2025, посвященный ESB — очень классный, это фактически специализированная конференция про шины.
И в комментариях спрашивали про записи. Я обещал написать, когда опубликуют записи. И вот они опубликованы:
Интеграционные платформы: Панацея или лишний слой?», Антон Копылов, «Аксеникс» видео | презентация
«ESB в России: тренды и перспективы. Результаты исследования», Александр Жиляев, Size Marketing видео | презентация
«Российские платформы ESB: критерии выбора, практическое применение», Сергей Скирдин, «Белый Код» видео | презентация
«Применение нейросети для трансформации сообщений в FESB», Олег Рубцов и Франклин Банкуе, «Неолант Тенакс» видео | презентация
«Integration Gears: новый модуль Monitoring Center», Антон Курудинов, «ЛАБ СП» видео | презентация
«Прототип инструмента для миграции с SAP PO на Integration Gears», Денис Бекишев, «ЛАБ СП» видео | презентация
«JSON-first integration flows», Марат Бареев, BeringPro видео | презентация
«Репликация в «Нормализаторе», Леонид Шумский и Александр Грищенко, «Т1» видео | презентация
«Подсистема интеграции для 1С:Предприятия», Андрей Соколов и Сергей Сулимов, «Корус Консалтинг» видео | презентация
Ну или все видео в одном плейлисте: https://youtube.com/playlist?list=PLHiGNvm26VdMoauuMRoSOxQV7tkq-7iie
Надеюсь, в следующем году мероприятие будет ещё масштабнее!
И в комментариях спрашивали про записи. Я обещал написать, когда опубликуют записи. И вот они опубликованы:
Интеграционные платформы: Панацея или лишний слой?», Антон Копылов, «Аксеникс» видео | презентация
«ESB в России: тренды и перспективы. Результаты исследования», Александр Жиляев, Size Marketing видео | презентация
«Российские платформы ESB: критерии выбора, практическое применение», Сергей Скирдин, «Белый Код» видео | презентация
«Применение нейросети для трансформации сообщений в FESB», Олег Рубцов и Франклин Банкуе, «Неолант Тенакс» видео | презентация
«Integration Gears: новый модуль Monitoring Center», Антон Курудинов, «ЛАБ СП» видео | презентация
«Прототип инструмента для миграции с SAP PO на Integration Gears», Денис Бекишев, «ЛАБ СП» видео | презентация
«JSON-first integration flows», Марат Бареев, BeringPro видео | презентация
«Репликация в «Нормализаторе», Леонид Шумский и Александр Грищенко, «Т1» видео | презентация
«Подсистема интеграции для 1С:Предприятия», Андрей Соколов и Сергей Сулимов, «Корус Консалтинг» видео | презентация
Ну или все видео в одном плейлисте: https://youtube.com/playlist?list=PLHiGNvm26VdMoauuMRoSOxQV7tkq-7iie
Надеюсь, в следующем году мероприятие будет ещё масштабнее!
🔥11❤6👍1
Самое интересное на Pimon, как мне показалось, было выступление Сергея Скирдина с обзором российских ESB, а точнее — критериев их оценки. Я послушал доклад, скачал обзор, прочел несколько постов Сергея на Хабре.
Вот что мне показалось любопытным:
Во-первых, в РФ вендоров ESB больше 40 штук! Это само по себе удивительно, потому что в Википедии всего 28 во всем мире перечислено, а на Capterra и того меньше — 19 (но там, как обычно, мусор какой-то).
Если копнуть глубже, становится понятен такой разброс: российские "продукты" — это, в большинстве случаев, просто сборки open-source компонент, дополненные специфическими российскими адаптерами и прошедшие специфическую российскую сертификацию. Иногда там что-то свое дописано, иногда к сборке прилагается методика внедрения.
Поэтому очень круто, что такие обзоры появляются — если вы собираетесь внедрять шину, а доступны только российские решения — хорошо бы в них разобраться, что там на самом деле внутри.
Во-вторых, и это, на мой взгляд, недостаток — у нас нет эталонного набора функций для ESB. Этот термин вообще зыбкий — то ли корпоративная шина, то ли интеграционный фреймворк, то ли движок бизнес-процессов, то ли брокер сообщений — все по-разному называют. Как в анекдоте: почему иногда говорят "Будапешт", а иногда — "Бухарест"?..
Тут бы хотелось какую-то классификацию, ну или профили — как сборки типовых функций. Сергей, насколько я понял, выделяет следующие:
1. Набор типов коннекторов и возможности их конфигурации. Тут нужно раскрывать, что там внутри: правила, форматы, фильтры, протоколы.
2. Функции и возможности преобразования данных
3. Настройка маршрутизации и, как расширение, целых сценариев и бизнес-процессов
4. Проверки корректности данных и контрактов
5. Мониторинг и траблшутинг — тоже в широком смысле, от логов до механизмов гарантированной доставки и очередей ошибок
6. В принципе наличие очередей, их виды и назначение
Пока это всё описано немного бессистемно, выхвачены какие-то отдельные фишки, описание функциональности перемешаны с описанием интерфейсов и нефункциональными требованиями, в общем, интересно, но винегрет. Я, как вы понимаете, люблю систематизацию, и в идеале хотел бы видеть какую-то таблицу с референсным набором функций и галочками. Ну или в графическом виде.
Надеюсь, такая работа ведется (и готов участвовать, кстати).
То же касается и НФТ: выцеплены отдельные характеристики, но хочется систематизации.
В-третьих, из любопытного: в продуктах появляется ИИ. Обычно это почему-то LLama, а используется она для составления маршрутов и настройки преобразований, или для выявления нестандартного поведения и ошибок (вот это интересно!)
Ну и про остальные критерии: понятно, что при примерно одинаковых функциях и примерно одинаковых показателях нагрузки и скорости отличия кроются в деталях, и нужен более детальный анализ. Но можно посмотреть на косвенные признаки: насколько компания давно на рынке, какая у неё история, насколько активно продукт развивается, есть ли специалисты по нему, и — очень мне понравилось — возвращает ли компания в open source свои разработки? Участвует ли в развитии проектов, на которых основывается? Выкладывает ли собственные инструменты? Вот это очень классный критерий. Ведь внутрь проприетарной системы не залезешь, а открытое ПО контролирует сообщество. К сожалению, как раз этот критерий в обзоре не раскрыт, а было бы очень интересно.
С другой стороны, если анализировать продуктовую сторону такого обзора, возникают некоторые сомнения — кому и в какой момент он нужен? Шину выбирают не так часто, а меняют и того реже. И если так, то обзор должен стоить довольно дорого, и быть довольно детальным, с результатами пилотов и экспериментов, с рассмотрением типовых кейсов (это, кстати, раскрыто у Сергея в серии постов — некоторые решения он пилотировал). На западных рынках есть такой тип компаний: технологический брокер, или консультант по выбору ПО. Который только советует и выбирает, но не ведет сам проект внедрения (этим занимаются интеграторы). Интересно, есть ли у нас похожие сервисы, и готовы компании платить за такую услугу?
Вот что мне показалось любопытным:
Во-первых, в РФ вендоров ESB больше 40 штук! Это само по себе удивительно, потому что в Википедии всего 28 во всем мире перечислено, а на Capterra и того меньше — 19 (но там, как обычно, мусор какой-то).
Если копнуть глубже, становится понятен такой разброс: российские "продукты" — это, в большинстве случаев, просто сборки open-source компонент, дополненные специфическими российскими адаптерами и прошедшие специфическую российскую сертификацию. Иногда там что-то свое дописано, иногда к сборке прилагается методика внедрения.
Поэтому очень круто, что такие обзоры появляются — если вы собираетесь внедрять шину, а доступны только российские решения — хорошо бы в них разобраться, что там на самом деле внутри.
Во-вторых, и это, на мой взгляд, недостаток — у нас нет эталонного набора функций для ESB. Этот термин вообще зыбкий — то ли корпоративная шина, то ли интеграционный фреймворк, то ли движок бизнес-процессов, то ли брокер сообщений — все по-разному называют. Как в анекдоте: почему иногда говорят "Будапешт", а иногда — "Бухарест"?..
Тут бы хотелось какую-то классификацию, ну или профили — как сборки типовых функций. Сергей, насколько я понял, выделяет следующие:
1. Набор типов коннекторов и возможности их конфигурации. Тут нужно раскрывать, что там внутри: правила, форматы, фильтры, протоколы.
2. Функции и возможности преобразования данных
3. Настройка маршрутизации и, как расширение, целых сценариев и бизнес-процессов
4. Проверки корректности данных и контрактов
5. Мониторинг и траблшутинг — тоже в широком смысле, от логов до механизмов гарантированной доставки и очередей ошибок
6. В принципе наличие очередей, их виды и назначение
Пока это всё описано немного бессистемно, выхвачены какие-то отдельные фишки, описание функциональности перемешаны с описанием интерфейсов и нефункциональными требованиями, в общем, интересно, но винегрет. Я, как вы понимаете, люблю систематизацию, и в идеале хотел бы видеть какую-то таблицу с референсным набором функций и галочками. Ну или в графическом виде.
Надеюсь, такая работа ведется (и готов участвовать, кстати).
То же касается и НФТ: выцеплены отдельные характеристики, но хочется систематизации.
В-третьих, из любопытного: в продуктах появляется ИИ. Обычно это почему-то LLama, а используется она для составления маршрутов и настройки преобразований, или для выявления нестандартного поведения и ошибок (вот это интересно!)
Ну и про остальные критерии: понятно, что при примерно одинаковых функциях и примерно одинаковых показателях нагрузки и скорости отличия кроются в деталях, и нужен более детальный анализ. Но можно посмотреть на косвенные признаки: насколько компания давно на рынке, какая у неё история, насколько активно продукт развивается, есть ли специалисты по нему, и — очень мне понравилось — возвращает ли компания в open source свои разработки? Участвует ли в развитии проектов, на которых основывается? Выкладывает ли собственные инструменты? Вот это очень классный критерий. Ведь внутрь проприетарной системы не залезешь, а открытое ПО контролирует сообщество. К сожалению, как раз этот критерий в обзоре не раскрыт, а было бы очень интересно.
С другой стороны, если анализировать продуктовую сторону такого обзора, возникают некоторые сомнения — кому и в какой момент он нужен? Шину выбирают не так часто, а меняют и того реже. И если так, то обзор должен стоить довольно дорого, и быть довольно детальным, с результатами пилотов и экспериментов, с рассмотрением типовых кейсов (это, кстати, раскрыто у Сергея в серии постов — некоторые решения он пилотировал). На западных рынках есть такой тип компаний: технологический брокер, или консультант по выбору ПО. Который только советует и выбирает, но не ведет сам проект внедрения (этим занимаются интеграторы). Интересно, есть ли у нас похожие сервисы, и готовы компании платить за такую услугу?
👍5❤2
Обнаружил у себя привычку анализировать различные сбои с точки зрения их возможного предотвращения системным аналитиком. Вот если бы на проекте был аналитик — смог бы он задуматься о возможном сбое?
Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)
Ну и что, всё то же, что и в других случаях: гонки параллельной записи, непредсказуемый эффект ретраев, плохо выстроенные границы транзакций, отсутствие проверок пустых значений, зажатые таймауты.
Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика.
Технически там вот что произошло: в AWS есть база DynamoDB, в которой хранится много всего интересного (например, настройки других сервисов). Эта база очень широко распараллелена, поэтому нужно балансировать нагрузку, динамически масштабировать, отключать и подключать вылетевшие и восстановившиеся копии. Это делается через DNS, поэтому планы DNS меняются очень динамично. Но в какой-то момент одно из изменений зависло, пересеклось с другими транзакциями и ушло в ретраи. Пока оно пыталось отретраиться, планы успели поменяться уже несколько раз. А отдельный процесс после успешной смены конфигурации ходит по узлам и удаляет старые планы. И вот в зазоре между обновлением плана и запуском очистки наконец успешно сработал один из ретраев, и переписал все планы на старую версию. Процесс очистки обнаружил план старой версии, и тут же его удалил. В DNS не осталось записей. А так как актуального плана не было, не на чем было основывать новые версии, и план вообще перестал обновляться, застряв в пустом состоянии.
Потом по цепочке всё начало валиться, в том числе перестали создаваться инстансы динамического масштабирования серверов EC2 — потому что даже после восстановления доступа к DynamoDB запросов на их создание скопилось столько, что их менеджер начал тормозить, и создание новых инстансов отваливалось по таймауту.
Непонятно, могли ли тут заранее помочь аналитики. Мне кажется, не особо. Возможно, помогло бы моделирование сценариев, но вся архитектура скорее всего развивалась эволюционно, и на каждое небольшое изменение имитационный сценарий не будешь запускать. Это особенно касается гонок параллельных процессов с учетом ретраев, потому что в голове такое сложно уложить, все варианты не учтешь.
Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь.
Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.
Отдельная тема — стратегия восстановления. Если у вас накопилось много сообщений или заданий в очередях, пока какой-то сервис лежал — как вы будете их накатывать? Если все сразу — это может превысить планируемую пиковую нагрузку, нужно как-то хитрее.
А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?
Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)
Ну и что, всё то же, что и в других случаях: гонки параллельной записи, непредсказуемый эффект ретраев, плохо выстроенные границы транзакций, отсутствие проверок пустых значений, зажатые таймауты.
Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика.
Технически там вот что произошло: в AWS есть база DynamoDB, в которой хранится много всего интересного (например, настройки других сервисов). Эта база очень широко распараллелена, поэтому нужно балансировать нагрузку, динамически масштабировать, отключать и подключать вылетевшие и восстановившиеся копии. Это делается через DNS, поэтому планы DNS меняются очень динамично. Но в какой-то момент одно из изменений зависло, пересеклось с другими транзакциями и ушло в ретраи. Пока оно пыталось отретраиться, планы успели поменяться уже несколько раз. А отдельный процесс после успешной смены конфигурации ходит по узлам и удаляет старые планы. И вот в зазоре между обновлением плана и запуском очистки наконец успешно сработал один из ретраев, и переписал все планы на старую версию. Процесс очистки обнаружил план старой версии, и тут же его удалил. В DNS не осталось записей. А так как актуального плана не было, не на чем было основывать новые версии, и план вообще перестал обновляться, застряв в пустом состоянии.
Потом по цепочке всё начало валиться, в том числе перестали создаваться инстансы динамического масштабирования серверов EC2 — потому что даже после восстановления доступа к DynamoDB запросов на их создание скопилось столько, что их менеджер начал тормозить, и создание новых инстансов отваливалось по таймауту.
Непонятно, могли ли тут заранее помочь аналитики. Мне кажется, не особо. Возможно, помогло бы моделирование сценариев, но вся архитектура скорее всего развивалась эволюционно, и на каждое небольшое изменение имитационный сценарий не будешь запускать. Это особенно касается гонок параллельных процессов с учетом ретраев, потому что в голове такое сложно уложить, все варианты не учтешь.
Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь.
Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.
Отдельная тема — стратегия восстановления. Если у вас накопилось много сообщений или заданий в очередях, пока какой-то сервис лежал — как вы будете их накатывать? Если все сразу — это может превысить планируемую пиковую нагрузку, нужно как-то хитрее.
А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?
🔥15👍8❤7
Ну что, аналитики, настало ваше время! Самый модный способ разработки программ с помощью ИИ сейчас — SDD, spec-driven development. Человек пишет требования и спецификации, ИИ пишет по ним код. Программисты не нужны.
Вот сейчас мы и посмотрим — насколько важная роль разработчика и что он вообще делает, и насколько точно аналитики могут формулировать требования и задачи.
Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте!
Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь.
Три основные идеи SDD:
1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации.
2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации.
3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается.
Отдельно от самих спецификаций живет существующая кодовая база, принципы архитектурного разбиения, разнообразные правила именования и оформления кода и т.п.
Работает примерно так:
Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи).
Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...).
Проект представляет собой описание устройства будущей системы:
Архитектура:
Компоненты архитектуры
Потоки данных
Компоненты и интерфейсы
Модели данных и т.д.
Задачи — это как в таск-трекере. Создай функцию такую-то, напиши набор тестов, добавь функцию фильтрации и т.п. Каждая задача имеет ссылку на требование.
У Spec Kit всё примерно так же, но перед требованиями есть ещё общий документ "Constitution" (Конституция), это что-то вроде системного промпта, где перечислены главные правила, вроде "Никакого кода без заранее написанных юнит-тестов" и "Обязательная модульность: каждая фича реализуется как отдельно стоящая библиотека".
В промптах используется очень много чеклистов для проверки каждого шага (правда, проверяет их сам же ИИ).
Tessl пока выглядит, как база спецификаций для агентов, создающих других агентов. Там некая смесь задач и инструкций по генерации, это уже совсем близко к коду.
Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы...
В общем, пока возникает множество вопросов. Удобнее ли проверять спеки, тест-кейсы и задачи, чем проверять код? В какой момент нужно переходить от проработки спецификации к написанию (или исправлению) кода? Какие вообще есть кейсы: написание системы с нуля, доработки, исправления багов, рефакторинг — и в каких случаях SDD оправдано, а когда скорее вредит?
Поминается MDD, который так и не взлетел. А я думаю, вопросы-то совсем концептуальные — могут ли в принципе существовать спецификации отдельно от кода? Есть ли граница между проработкой требований и проектированием? Что составляет суть работы программиста, если спецификации и модели уже готовы? Кажется, тут есть что-то, чего мы не очень улавливаем, и всё время думаем, что это автоматическая перекладка требований в код. Возможно, глядя в зеркало ИИ, мы лучше поймем свою собственную деятельность.
Вот сейчас мы и посмотрим — насколько важная роль разработчика и что он вообще делает, и насколько точно аналитики могут формулировать требования и задачи.
Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте!
Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь.
Три основные идеи SDD:
1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации.
2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации.
3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается.
Отдельно от самих спецификаций живет существующая кодовая база, принципы архитектурного разбиения, разнообразные правила именования и оформления кода и т.п.
Работает примерно так:
Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи).
Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...).
Проект представляет собой описание устройства будущей системы:
Архитектура:
Компоненты архитектуры
Потоки данных
Компоненты и интерфейсы
Модели данных и т.д.
Задачи — это как в таск-трекере. Создай функцию такую-то, напиши набор тестов, добавь функцию фильтрации и т.п. Каждая задача имеет ссылку на требование.
У Spec Kit всё примерно так же, но перед требованиями есть ещё общий документ "Constitution" (Конституция), это что-то вроде системного промпта, где перечислены главные правила, вроде "Никакого кода без заранее написанных юнит-тестов" и "Обязательная модульность: каждая фича реализуется как отдельно стоящая библиотека".
В промптах используется очень много чеклистов для проверки каждого шага (правда, проверяет их сам же ИИ).
Tessl пока выглядит, как база спецификаций для агентов, создающих других агентов. Там некая смесь задач и инструкций по генерации, это уже совсем близко к коду.
Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы...
В общем, пока возникает множество вопросов. Удобнее ли проверять спеки, тест-кейсы и задачи, чем проверять код? В какой момент нужно переходить от проработки спецификации к написанию (или исправлению) кода? Какие вообще есть кейсы: написание системы с нуля, доработки, исправления багов, рефакторинг — и в каких случаях SDD оправдано, а когда скорее вредит?
Поминается MDD, который так и не взлетел. А я думаю, вопросы-то совсем концептуальные — могут ли в принципе существовать спецификации отдельно от кода? Есть ли граница между проработкой требований и проектированием? Что составляет суть работы программиста, если спецификации и модели уже готовы? Кажется, тут есть что-то, чего мы не очень улавливаем, и всё время думаем, что это автоматическая перекладка требований в код. Возможно, глядя в зеркало ИИ, мы лучше поймем свою собственную деятельность.
👍22🔥11❤8
Так, ну мы доигрались. Обсуждения продуктового подхода в комментах к одному там посту таки вылились в целый баттл! Будем в четверг разбираться - есть всё-таки за продуктовым подходом новая философия, или это просто удобный способ работать с требованиями, гипотезами и релизами (ну и вытягивания денег из пользователей, ничего личного).
Приходите! За кого будете болеть?
Приходите! За кого будете болеть?
🔥12😁2👍1