Тем временем продолжается отбор докладов на осеннюю конференцию Flow. Если задумываетесь о выступлении — завтра в 19:00 по Мск будет встреча с программным комитетом, можно задать вопросы про конференцию, тематики докладов, о чем интересно рассказать и что ПК ищет в заявках. Приходите! (А то уже надоели одни и те же спикеры на всех конференциях, если честно)
Я всё больше думаю о том, что наша дисциплина — это смесь управления знаниями и поддержки принятия решений. Обе эти области довольно хорошо проработаны. Про управление знаниями я как-то раз уже писал, а теперь нашел свою старую презентацию с конференции AIST аж 2014 года. Я в ней делал обзор состояния KM в России и мире.
Очень интересные мысли там оказались, и не устаревают!
Например, стратегия управления знаниями. На что мы полагаемся. Тут три варианта:
— техноцентричная (убеждение, что нужно поставить правильную систему, и всё заработает. Люди вообще не важны.)
— организационная (убеждение, что нужно выстроить правильные процессы, и всё заработает. Люди выступают только как роли в процессах)
— экологическая (представление о взаимодействии людей, как о комплексной адаптивной системе, состоящей из множества разных личностей со своими интересами и идентичностями, и среды, в которой они действуют)
Ещё есть две растяжки:
1) как мы обходимся со знаниями: заталкиваем их в людей (push) или предоставляем по мере надобности (pull).
2) к чему мы больше стремимся: к кодификации (извлечению из людей и фиксации где-то отдельно: в документах, чек-листах, процессах и коде) или к персонализации (накоплении экспертности в людях).
Вот в этих координатах можно определить свою стратегию управления знаниями. Или стратегию компании, из которой вы собираетесь знания извлечь, чтобы собрать требования. Понятно, что если они организационно-центричны и стремятся к кодификации, то нужно изучать документы. А если к персонализации — то искать экспертов и разговаривать с ними.
Push и pull можно отличить по отношению к обучению: если вас заранее учат всему на свете, что вам сразу может и не пригодится — это культура push.
По состоянию на 2014 большинство российских компаний тяготели к техноцентричной или — реже — организационной моделям (тогда все себе создавали "корпоративные порталы", превращавшиеся обычно в свалки документов), кодификации и заталкиванию.
Не знаю, как сейчас всё происходит, но, по ощущениям, всё равно очень мало компаний работают по принципам построения экосистемы, персонализации и вытягивания.
Проверочный вопрос: есть ли у вас в каком-либо виде система навигации по людям? Чтобы можно было быстро найти, кого можно спросить про конкретную систему, проект или технологию? И чтобы этого человека действительно можно было спросить, да ещё и получить ответ? (т.е., возможность вытянуть знания закреплена в культуре). Я такое видел может быть пару раз, напишите, если у вас что-то подобное реализовано. Очень интересно, как работает.
Очень интересные мысли там оказались, и не устаревают!
Например, стратегия управления знаниями. На что мы полагаемся. Тут три варианта:
— техноцентричная (убеждение, что нужно поставить правильную систему, и всё заработает. Люди вообще не важны.)
— организационная (убеждение, что нужно выстроить правильные процессы, и всё заработает. Люди выступают только как роли в процессах)
— экологическая (представление о взаимодействии людей, как о комплексной адаптивной системе, состоящей из множества разных личностей со своими интересами и идентичностями, и среды, в которой они действуют)
Ещё есть две растяжки:
1) как мы обходимся со знаниями: заталкиваем их в людей (push) или предоставляем по мере надобности (pull).
2) к чему мы больше стремимся: к кодификации (извлечению из людей и фиксации где-то отдельно: в документах, чек-листах, процессах и коде) или к персонализации (накоплении экспертности в людях).
Вот в этих координатах можно определить свою стратегию управления знаниями. Или стратегию компании, из которой вы собираетесь знания извлечь, чтобы собрать требования. Понятно, что если они организационно-центричны и стремятся к кодификации, то нужно изучать документы. А если к персонализации — то искать экспертов и разговаривать с ними.
Push и pull можно отличить по отношению к обучению: если вас заранее учат всему на свете, что вам сразу может и не пригодится — это культура push.
По состоянию на 2014 большинство российских компаний тяготели к техноцентричной или — реже — организационной моделям (тогда все себе создавали "корпоративные порталы", превращавшиеся обычно в свалки документов), кодификации и заталкиванию.
Не знаю, как сейчас всё происходит, но, по ощущениям, всё равно очень мало компаний работают по принципам построения экосистемы, персонализации и вытягивания.
Проверочный вопрос: есть ли у вас в каком-либо виде система навигации по людям? Чтобы можно было быстро найти, кого можно спросить про конкретную систему, проект или технологию? И чтобы этого человека действительно можно было спросить, да ещё и получить ответ? (т.е., возможность вытянуть знания закреплена в культуре). Я такое видел может быть пару раз, напишите, если у вас что-то подобное реализовано. Очень интересно, как работает.
Telegram
Системный сдвиг
Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии…
🔥14❤8👍2🤔2
Смотрим на API, как программисты.
В сообществе регулярно возникает вопрос — нужно ли аналитику уметь программировать, и зачем.
Покажу пример, как может быть устроена логика мышления например при выборе технологий API, если вы смотрите на них с позиции программиста.
Чуть ли не главное понятие в языках программирования — система типов. Всех программистов в университетах мучают понятиями "статическая типизация", "динамическая типизация", "сильная и слабая типизация". Проблемы с типами являются источником большинства ошибок в программах: не учли значение null; складывали числа, а они оказались строками; вышли за пределы массива; думали, что дробная часть отделяется точкой, а в данных была запятая; и т.п. Ну, и все мы сталкивались с превращением всего подряд в дату в Excel.
А система типов, по одному из определений — синтаксический разрешимый метод доказательства отсутствия определенного поведения программы. Это уже большой успех, потому что вообще говоря вычислить наличие или отсутствия какого-то свойства у программы невозможно — это математически доказано, называется теорема Райса.
Проблема настолько концептуальная, что есть целая математическая теория типов и довольно сложные в понимании модели лямбда-исчислений, лямбда-кубы и прочая функциональщина. Функциональные языки и стали популярны отчасти из-за того, что правильность их программ в некоторых случаях можно доказать.
Запросы и ответы HTTP API по умолчанию вообще никак не типизированы. Это просто строки.
Соответственно, REST API сам по себе тоже не типизирован. По крайней мере Филдинг ничего про это не писал. Он писал только про media types, на уровне всего ответа целиком, а не отдельных его полей. Это всё в русле JavaScript — динамически-типизируемого и слабо-типизированного языка. Погуглите ради интереса "JavaScript memes" — они все про преобразование типов 😹
Но на клиентах это создает бооольшую проблему — фактически, заставляет писать код в "защитном стиле", подразумевая, что снаружи может прийти вообще всё, что угодно. Адовая работа. Гораздо проще использовать типобезопасные (typesafe) языки и технологии — с указанием конкретных типов, их возможных преобразований и отлова ошибок ещё до основной обработки.
Поэтому всё, что появилось после REST — было сразу типобезопасно. Собственно, зачем OpenAPI с его схемами? Если генерировать код и клиентов, и сервера из одной спецификации — он будет типобезопасным.
GraphQL — сразу типобезопасный, потому что для него вообще первичная схема, всё остальное из неё генерится.
Protobuf (и gRPC, соответственно) — сразу типобезопасный, для него тоже первичная схема.
Kafka, как и HTTP, по умолчанию вообще не проверяет содержимое сообщения и его формат. Но есть Kafka Schema Registry — хранилище схем сообщений с готовыми клиентами для продюсеров и консьюмеров.
И вот эта типобезопасность может быть для разработчиков хорошим аргументом для перехода на что-то дальше REST (а хотя бы и на OpenAPI с генерацией кода).
Может ли системный аналитик говорить со своей командой на этом уровне?
В сообществе регулярно возникает вопрос — нужно ли аналитику уметь программировать, и зачем.
Покажу пример, как может быть устроена логика мышления например при выборе технологий API, если вы смотрите на них с позиции программиста.
Чуть ли не главное понятие в языках программирования — система типов. Всех программистов в университетах мучают понятиями "статическая типизация", "динамическая типизация", "сильная и слабая типизация". Проблемы с типами являются источником большинства ошибок в программах: не учли значение null; складывали числа, а они оказались строками; вышли за пределы массива; думали, что дробная часть отделяется точкой, а в данных была запятая; и т.п. Ну, и все мы сталкивались с превращением всего подряд в дату в Excel.
А система типов, по одному из определений — синтаксический разрешимый метод доказательства отсутствия определенного поведения программы. Это уже большой успех, потому что вообще говоря вычислить наличие или отсутствия какого-то свойства у программы невозможно — это математически доказано, называется теорема Райса.
Проблема настолько концептуальная, что есть целая математическая теория типов и довольно сложные в понимании модели лямбда-исчислений, лямбда-кубы и прочая функциональщина. Функциональные языки и стали популярны отчасти из-за того, что правильность их программ в некоторых случаях можно доказать.
Запросы и ответы HTTP API по умолчанию вообще никак не типизированы. Это просто строки.
Соответственно, REST API сам по себе тоже не типизирован. По крайней мере Филдинг ничего про это не писал. Он писал только про media types, на уровне всего ответа целиком, а не отдельных его полей. Это всё в русле JavaScript — динамически-типизируемого и слабо-типизированного языка. Погуглите ради интереса "JavaScript memes" — они все про преобразование типов 😹
Но на клиентах это создает бооольшую проблему — фактически, заставляет писать код в "защитном стиле", подразумевая, что снаружи может прийти вообще всё, что угодно. Адовая работа. Гораздо проще использовать типобезопасные (typesafe) языки и технологии — с указанием конкретных типов, их возможных преобразований и отлова ошибок ещё до основной обработки.
Поэтому всё, что появилось после REST — было сразу типобезопасно. Собственно, зачем OpenAPI с его схемами? Если генерировать код и клиентов, и сервера из одной спецификации — он будет типобезопасным.
GraphQL — сразу типобезопасный, потому что для него вообще первичная схема, всё остальное из неё генерится.
Protobuf (и gRPC, соответственно) — сразу типобезопасный, для него тоже первичная схема.
Kafka, как и HTTP, по умолчанию вообще не проверяет содержимое сообщения и его формат. Но есть Kafka Schema Registry — хранилище схем сообщений с готовыми клиентами для продюсеров и консьюмеров.
И вот эта типобезопасность может быть для разработчиков хорошим аргументом для перехода на что-то дальше REST (а хотя бы и на OpenAPI с генерацией кода).
Может ли системный аналитик говорить со своей командой на этом уровне?
🔥20❤11👍11
Я давно подозреваю, что Agile (в частности — малые размеры итераций) имеет математическое обоснование -- из теории вероятностей или теории игр. А также, что развитие роли системного аналитика и применение agile-методик являются двумя разными ответами на одну и ту же проблему — несоответствие функций и свойств поставленного ПО ожиданиям заказчика и пользователей.
И вот одно из подтверждений -- задача о разорении игрока. Формулируется она так: два игрока садятся за стол и играют в стохастическую игру — например, делают ставки и подбрасывают монетки. Как будет развиваться игра в зависимости от начального капитала каждого игрока, размера ставок, стратегии изменения ставки и вероятности выигрыша в конкретном подбрасывании (монета честная, или одна сторона выпадает чаще)?
Почему задача о разорении: доказано, что если игрок повышает ставку после каждого выигрыша, и не понижает её после проигрыша, то он неизбежно разорится. А также, если шансы хоть немного против игрока, а у его противника денег сильно больше (игрок против казино), то игрок с меньшим капиталом тоже рано или поздно разорится (для этого небольшого смещения на рулетке есть 0, а в некоторых ещё 00 и 000 — именно за их счет казино в конечном счете всегда выигрывает ).
Это всё очень напоминает ситуацию, когда небольшая компания по разработке ПО берет регулярные заказы у крупной компании (с бесконечным количеством денег). Ну или наоборот — небольшая компания обращается к системному интегратору с бесконечным количеством денег. Дальше понятно. Если меньшая компания и не разорится, всё равно может сильно пострадать — рано или поздно.
Что тут можно сделать:
1) увеличивать вероятность исхода "в свою пользу". В ИТ-проектах вероятность успешного результата проекта всё-таки не 50/50, а немного выше: 60/40. Тогда вероятность не разориться уже становится около 55%! А при попадании в цель 80/20 — вероятность уже больше 93%!!! Ого. Это путь аналитиков — стараться разобраться в проекте и повысить вероятность его успеха вдвое (кстати, нигде не видел исследований, насколько улучшение качества сбора и анализа требований повышает вероятность успеха проекта).
2) уменьшать размер ставки: не весь проект целиком, а порезанный на небольшие спринты. Уменьшение ставки в одной игре раз в 10 радикально увеличивает количество игр, за которое игрок с большим банком вас переиграет, то есть он просто не будет успевать, и шансы на успех приближаются к 98-99%. Неплохо, да? Это путь agile — вести разработку небольшими частями (снижать размер ставки).
Это, конечно, очень огрубленно, и в реальности нужно учитывать много чего: во-первых, разработка — игра с ненулевой суммой, и когда разработчик выигрывает, заказчик тоже выигрывает. Во-вторых, когда заказчик проигрывает — разработчик не всегда получает штраф. В-третьих, проигрыш — это ведь не совсем проигрыш, это просто шаг на пути к совместном с заказчиком понимании и задачи, и решения (но это, кстати, не меняет математической модели — она про случайные блуждания, так что неважно, с какой целью мы блуждаем). В четвертых, блуждания на самом деле не такие уж случайные — если мы учимся, то процесс должен сходиться, а не быть случайным.
Впрочем, вывода это не меняет — почти во всех случаях выгоднее двигаться небольшими шагами с маленькими ставками. Кроме одного: когда вы знаете, что шансы не в вашу пользу, лучший вариант — влупить весь банк в первую ставку и гордо уйти в закат, хоть с проигрышем, хоть с победой, и никогда больше не играть с этим противником. Хм. А ведь похоже на стратегию многих компаний.
И вот одно из подтверждений -- задача о разорении игрока. Формулируется она так: два игрока садятся за стол и играют в стохастическую игру — например, делают ставки и подбрасывают монетки. Как будет развиваться игра в зависимости от начального капитала каждого игрока, размера ставок, стратегии изменения ставки и вероятности выигрыша в конкретном подбрасывании (монета честная, или одна сторона выпадает чаще)?
Почему задача о разорении: доказано, что если игрок повышает ставку после каждого выигрыша, и не понижает её после проигрыша, то он неизбежно разорится. А также, если шансы хоть немного против игрока, а у его противника денег сильно больше (игрок против казино), то игрок с меньшим капиталом тоже рано или поздно разорится (для этого небольшого смещения на рулетке есть 0, а в некоторых ещё 00 и 000 — именно за их счет казино в конечном счете всегда выигрывает ).
Это всё очень напоминает ситуацию, когда небольшая компания по разработке ПО берет регулярные заказы у крупной компании (с бесконечным количеством денег). Ну или наоборот — небольшая компания обращается к системному интегратору с бесконечным количеством денег. Дальше понятно. Если меньшая компания и не разорится, всё равно может сильно пострадать — рано или поздно.
Что тут можно сделать:
1) увеличивать вероятность исхода "в свою пользу". В ИТ-проектах вероятность успешного результата проекта всё-таки не 50/50, а немного выше: 60/40. Тогда вероятность не разориться уже становится около 55%! А при попадании в цель 80/20 — вероятность уже больше 93%!!! Ого. Это путь аналитиков — стараться разобраться в проекте и повысить вероятность его успеха вдвое (кстати, нигде не видел исследований, насколько улучшение качества сбора и анализа требований повышает вероятность успеха проекта).
2) уменьшать размер ставки: не весь проект целиком, а порезанный на небольшие спринты. Уменьшение ставки в одной игре раз в 10 радикально увеличивает количество игр, за которое игрок с большим банком вас переиграет, то есть он просто не будет успевать, и шансы на успех приближаются к 98-99%. Неплохо, да? Это путь agile — вести разработку небольшими частями (снижать размер ставки).
Это, конечно, очень огрубленно, и в реальности нужно учитывать много чего: во-первых, разработка — игра с ненулевой суммой, и когда разработчик выигрывает, заказчик тоже выигрывает. Во-вторых, когда заказчик проигрывает — разработчик не всегда получает штраф. В-третьих, проигрыш — это ведь не совсем проигрыш, это просто шаг на пути к совместном с заказчиком понимании и задачи, и решения (но это, кстати, не меняет математической модели — она про случайные блуждания, так что неважно, с какой целью мы блуждаем). В четвертых, блуждания на самом деле не такие уж случайные — если мы учимся, то процесс должен сходиться, а не быть случайным.
Впрочем, вывода это не меняет — почти во всех случаях выгоднее двигаться небольшими шагами с маленькими ставками. Кроме одного: когда вы знаете, что шансы не в вашу пользу, лучший вариант — влупить весь банк в первую ставку и гордо уйти в закат, хоть с проигрышем, хоть с победой, и никогда больше не играть с этим противником. Хм. А ведь похоже на стратегию многих компаний.
🔥25❤8👍3
Срочно в номер! Мы все неправильно понимали, как работают методы HTTP!
Всегда ведь всем говорят, что REST строится вокруг методов HTTP, а они соответствуют операциям CRUD:
POST — это Create,
GET — Read,
PUT — Update,
DELETE — Delete.
Но не всё так просто. Есть документ с объяснением семантики HTTP — RFC 7231, 'HTTP/1.1 Semantics and Content', датируется 2014 годом, за авторством самого Роя Филдинга (и обновлённый в 2022 как RFC 9110)
Там всё написано, из первых уст, так сказать.
Понятнее всего с GET — это действительно запрос получения ресурса.
Создание ресурса — это PUT: 'The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.'
То есть PUT может и изменять ресурс, и создавать его. Главное — в PUT создается или изменяется ресурс по конкретному адресу (URI). Понятно, что это не сработает, если мы включаем в URI идентификатор, который выдает сервер (его и знать может только сервер). Но мы, например, можем положить через PUT оценку конкретным пользователем товара или статьи: тогда первый PUT создаст оценку, последующие её поменяют, но доступна она всегда будет по одному и тому же URI. В этом примере понятно, почему PUT небезопасный: кроме самой оценки конкретного пользователя ещё поменяется и общая оценка товара (и б-г знает что ещё — может быть, место в поисковой выдаче, а может этот товар попадет на главную, и т.п.).
DELETE — это не совсем удаление. Это скорее отключение ресурса — по этому URI он больше не будет доступен. Что там внутри сервера при этом произойдет — только его дело. Может быть, на самом деле всё удалится. Может быть, пометится как удаленный. Может быть, отправится в архив и появится по новому адресу (поэтому DELETE тоже небезопасная операция). В RFC сказано, что DELETE достаточно редкая операция, и может применяться к ресурсам, созданным при помощи PUT. Могут быть интересные истории, например с ресурсом, указывающим на "последнюю версию статьи". Если сказать ему DELETE — что должно произойти? Вся статья удалиться, или удалиться последняя версия, и на этом же URI должна восстановиться предыдущая версия?.. Возникает неоднозначность семантики.
И самое сложное — POST. Это вовсе не создание ресурса, как мы всегда думали. Это, вообще говоря, просто семантическая дыра: 'The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.'
То есть, как хотите, так и понимайте. Единственный смысл — мы хотим что-то сказать серверу, вот как. А дальше сервер уже будет решать, в соответствии с "собственной специфической семантикой ресурса". Это может быть:
— передача блока данных для обработки (не факт, что что-то тут создается!);
— создание нового ресурса, у которого ещё нет идентификатора и URI (обратите внимание, URI у ресурса появляется уже позже: мы обращаемся к одному адресу — к сервису, по сути, — чтобы создать ресурс по другому адресу);
— добавление данных к имеющемуся ресурсу (!!!)
Мы можем через POST создать один ресурс, несколько новых ресурсов, дополнить существующий ресурс, вообще ничего не создавать.
Кажется, самого Филдинга не очень заботило, строите ли вы своё API через CRUD, или нет. Его гораздо больше интересовало, чтобы ваше API было самоописательным и предлагало список действий, которые вы можете осуществить с его ресурсами.
И, конечно, в его диссертации вообще не упоминаются ни POST (там только GET и HEAD из методов упоминаются), ни CRUD.
В отдельном посте на эту темы он так и говорит: вся эта возня с методами просто не важна для обсуждения архитектурного стиля REST, главное — соблюдать единообразие и не делать получение данных через POST (а то кэширование и перезапросы работать не будут).
Так что POST — это операция со смыслом 'this action isn’t worth standardizing', "это действие не стоит стандартизации".
Как видно из поста Филдинга, в нулевые было распространено представление, что "настоящий" REST должен вообще обходиться без POST(!), видимо были сильны ассоциации с SOAP.
Всегда ведь всем говорят, что REST строится вокруг методов HTTP, а они соответствуют операциям CRUD:
POST — это Create,
GET — Read,
PUT — Update,
DELETE — Delete.
Но не всё так просто. Есть документ с объяснением семантики HTTP — RFC 7231, 'HTTP/1.1 Semantics and Content', датируется 2014 годом, за авторством самого Роя Филдинга (и обновлённый в 2022 как RFC 9110)
Там всё написано, из первых уст, так сказать.
Понятнее всего с GET — это действительно запрос получения ресурса.
Создание ресурса — это PUT: 'The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.'
То есть PUT может и изменять ресурс, и создавать его. Главное — в PUT создается или изменяется ресурс по конкретному адресу (URI). Понятно, что это не сработает, если мы включаем в URI идентификатор, который выдает сервер (его и знать может только сервер). Но мы, например, можем положить через PUT оценку конкретным пользователем товара или статьи: тогда первый PUT создаст оценку, последующие её поменяют, но доступна она всегда будет по одному и тому же URI. В этом примере понятно, почему PUT небезопасный: кроме самой оценки конкретного пользователя ещё поменяется и общая оценка товара (и б-г знает что ещё — может быть, место в поисковой выдаче, а может этот товар попадет на главную, и т.п.).
DELETE — это не совсем удаление. Это скорее отключение ресурса — по этому URI он больше не будет доступен. Что там внутри сервера при этом произойдет — только его дело. Может быть, на самом деле всё удалится. Может быть, пометится как удаленный. Может быть, отправится в архив и появится по новому адресу (поэтому DELETE тоже небезопасная операция). В RFC сказано, что DELETE достаточно редкая операция, и может применяться к ресурсам, созданным при помощи PUT. Могут быть интересные истории, например с ресурсом, указывающим на "последнюю версию статьи". Если сказать ему DELETE — что должно произойти? Вся статья удалиться, или удалиться последняя версия, и на этом же URI должна восстановиться предыдущая версия?.. Возникает неоднозначность семантики.
И самое сложное — POST. Это вовсе не создание ресурса, как мы всегда думали. Это, вообще говоря, просто семантическая дыра: 'The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.'
То есть, как хотите, так и понимайте. Единственный смысл — мы хотим что-то сказать серверу, вот как. А дальше сервер уже будет решать, в соответствии с "собственной специфической семантикой ресурса". Это может быть:
— передача блока данных для обработки (не факт, что что-то тут создается!);
— создание нового ресурса, у которого ещё нет идентификатора и URI (обратите внимание, URI у ресурса появляется уже позже: мы обращаемся к одному адресу — к сервису, по сути, — чтобы создать ресурс по другому адресу);
— добавление данных к имеющемуся ресурсу (!!!)
Мы можем через POST создать один ресурс, несколько новых ресурсов, дополнить существующий ресурс, вообще ничего не создавать.
Кажется, самого Филдинга не очень заботило, строите ли вы своё API через CRUD, или нет. Его гораздо больше интересовало, чтобы ваше API было самоописательным и предлагало список действий, которые вы можете осуществить с его ресурсами.
И, конечно, в его диссертации вообще не упоминаются ни POST (там только GET и HEAD из методов упоминаются), ни CRUD.
В отдельном посте на эту темы он так и говорит: вся эта возня с методами просто не важна для обсуждения архитектурного стиля REST, главное — соблюдать единообразие и не делать получение данных через POST (а то кэширование и перезапросы работать не будут).
Так что POST — это операция со смыслом 'this action isn’t worth standardizing', "это действие не стоит стандартизации".
Как видно из поста Филдинга, в нулевые было распространено представление, что "настоящий" REST должен вообще обходиться без POST(!), видимо были сильны ассоциации с SOAP.
1👍26❤7
А вот в 2014 в связи с CQRS обсуждался "REST без PUT" — ничего менять вообще нельзя, можно только постить новые версии ресурсов. (Там же, кстати, интересное рассуждение про CRUD и грануляцию ресурсов — мол, это создает слишком болтливые API и переносит бизнес-логику на клиентов).
В общем, надеюсь, мне удалось вас запутать, и при случае вы можете запутать вашего интервьюера (не знаю только, на пользу ли это вам пойдет).
Upd.: пока выглядит так, что если вы досконально знаете стандарты и активно пытаетесь им следовать — вы идете против мейнстрима и хотите странного.
В общем, надеюсь, мне удалось вас запутать, и при случае вы можете запутать вашего интервьюера (не знаю только, на пользу ли это вам пойдет).
Upd.: пока выглядит так, что если вы досконально знаете стандарты и активно пытаетесь им следовать — вы идете против мейнстрима и хотите странного.
😁34💯3
Вчера выпрыгнула на меня реклама очередного курса по системному анализу от конторы из четырех букв, я аж опешил от такого откровенного вранья.
Что, друзья-аналитики, влияют ваши решения на прибыль компаний и стратегические решения?
Это на тренингах тоже часто встречается: говоришь, опирайтесь на цели бизнеса. Не является целью создания системы создание системы. Цель всегда вне и выше системы (проверка: никакой системы нет, а цель сохраняется, переформулировать её не нужно).
Ну и люди сразу начинают писать про повышение прибыли, долю на рынке и прочие страшные вещи. Камон, где ваши артефакты, а где прибыль. На прибыль и продакт-то с трудом влияет, далеко не напрямую.
Я вот всем рассказываю про четыре уровня карты Нортона-Каплана, которая Balanced Scorecards. Снизу-вверх:
👉 обучение/ развитие/инновации,
👉 внутренние процессы,
👉 удовлетворенность и поведение клиентов,
👉 финансы.
Вы или ваши системы на каком уровне работают? Я вот делал системы для обучения и инноваций, это нижний уровень, от них вообще до финансов далеко (хотя некоторые умудрялись считать ROI даже, а некоторые наоборот — принципиально ничего не считали в деньгах).
В основном мы наверное занимаемся внутренними процессами. Какой-нибудь документооборот — как он влияет на финансовый результат или, прости господи, стратегию — пойди посчитай.
Если (если!) у вас система показателей в организации простроена, тогда можно и проследить влияние на финансы. Только оно будет, скорее всего, через несколько шагов. А так — смотрите на то, что поближе. Скорость процесса улучшить, число ручных проверок снизить, повысить контроль там где его не было, убрать/ускорить ручной ввод. Если на уровне продукта — повысить LT (а лучше LTV), DAU/WAU/MAU, повторные покупки, виральность, число шагов в конверсиях — короче, всё про поведение и удовлетворенность. А уж там и до финансов как-нибудь доберемся.
Впрочем, не знаю, может я от жизни отстал, и системные аналитики действительно стали на прибыль и стратегию влиять?
Что, друзья-аналитики, влияют ваши решения на прибыль компаний и стратегические решения?
Это на тренингах тоже часто встречается: говоришь, опирайтесь на цели бизнеса. Не является целью создания системы создание системы. Цель всегда вне и выше системы (проверка: никакой системы нет, а цель сохраняется, переформулировать её не нужно).
Ну и люди сразу начинают писать про повышение прибыли, долю на рынке и прочие страшные вещи. Камон, где ваши артефакты, а где прибыль. На прибыль и продакт-то с трудом влияет, далеко не напрямую.
Я вот всем рассказываю про четыре уровня карты Нортона-Каплана, которая Balanced Scorecards. Снизу-вверх:
Вы или ваши системы на каком уровне работают? Я вот делал системы для обучения и инноваций, это нижний уровень, от них вообще до финансов далеко (хотя некоторые умудрялись считать ROI даже, а некоторые наоборот — принципиально ничего не считали в деньгах).
В основном мы наверное занимаемся внутренними процессами. Какой-нибудь документооборот — как он влияет на финансовый результат или, прости господи, стратегию — пойди посчитай.
Если (если!) у вас система показателей в организации простроена, тогда можно и проследить влияние на финансы. Только оно будет, скорее всего, через несколько шагов. А так — смотрите на то, что поближе. Скорость процесса улучшить, число ручных проверок снизить, повысить контроль там где его не было, убрать/ускорить ручной ввод. Если на уровне продукта — повысить LT (а лучше LTV), DAU/WAU/MAU, повторные покупки, виральность, число шагов в конверсиях — короче, всё про поведение и удовлетворенность. А уж там и до финансов как-нибудь доберемся.
Впрочем, не знаю, может я от жизни отстал, и системные аналитики действительно стали на прибыль и стратегию влиять?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25💯9❤7👌3👏1
Продолжая тему про стратегию: лично мне не удавалось никак влиять на стратегию ни из роли аналитика, ни из роли программиста, ни из роли техлида. Вся стратегия только с C-level начинается.
Или из интересной роли советника. Это самая высокая роль, в которой ещё можно оставаться специалистом и индивидуальным контрибьютором, а не руководителем. Я говорю про советника директора, ну или одного из директоров (я, например, был советником директора по технологиям. В смысле, не советник по технологиям, а директор). Мистическая это должность, загадочная для всех. Чем он занимается — только сам директор и знает. Отчитывается тоже только перед своим директором. Вроде бы ничем формально не управляет, но статус высокий. Хотя может и порулить каким-нибудь временным проектом. В общем — чиновник по особым поручениям.
Вот тут можно поупражняться в стратегировании — ты их, зачастую, сам и пишешь или фасилитируешь встречи по их разработке.
Как туда попадают — не скажу, меня по карьерной лестнице так тащило (причем иногда эту должность под меня делали — подкиньте мысль начальству/HR).
Про стратегию на WAW был отличный доклад Бориса Вольфсона: в принципе, стратегия это набор трёх решений:
— где играем?
— как выигрываем? (за счет чего)
— что не делаем?
и как всё это связано с конкретными проектами.
Поэтому системному и даже бизнес-аналитику до этих вопросов далеко. Вот быть проводником стратегии аналитик может. Особенно последних двух вопросов.
Или из интересной роли советника. Это самая высокая роль, в которой ещё можно оставаться специалистом и индивидуальным контрибьютором, а не руководителем. Я говорю про советника директора, ну или одного из директоров (я, например, был советником директора по технологиям. В смысле, не советник по технологиям, а директор). Мистическая это должность, загадочная для всех. Чем он занимается — только сам директор и знает. Отчитывается тоже только перед своим директором. Вроде бы ничем формально не управляет, но статус высокий. Хотя может и порулить каким-нибудь временным проектом. В общем — чиновник по особым поручениям.
Вот тут можно поупражняться в стратегировании — ты их, зачастую, сам и пишешь или фасилитируешь встречи по их разработке.
Как туда попадают — не скажу, меня по карьерной лестнице так тащило (причем иногда эту должность под меня делали — подкиньте мысль начальству/HR).
Про стратегию на WAW был отличный доклад Бориса Вольфсона: в принципе, стратегия это набор трёх решений:
— где играем?
— как выигрываем? (за счет чего)
— что не делаем?
и как всё это связано с конкретными проектами.
Поэтому системному и даже бизнес-аналитику до этих вопросов далеко. Вот быть проводником стратегии аналитик может. Особенно последних двух вопросов.
lafest.ru
Борис Вольфсон. Ландшафт стратегий в большой компании
Вас интересуют, как гармонизировать работу между различными подразделениями и достигать стратегических целей в огромной компании? Борис Вольфсон в своём выступлении на Зимних Аналитических выходных 2024 года делится своим опытом и прибывает к ключевым решениям…
👍13❤🔥1👏1
Что вы представляете себе, когда слышите про схему организационной структуры? Наверняка — древовидную иерархическую диаграмму с прямоугольничками — отделами и должностями.
Но ещё лет 100 назад всё было не так очевидно.
Вот, например, организационная схема ТЕО — Театрального отдела Наркомпроса, составленная В.Э.Мейерхольдом, возглавлявшим этот отдел в 1920-1921 годах (с сентября по февраль, если быть точным).
В интернете её нет, я сфотографировал её в доме-музее Мейерхольда в Пензе, она там в уголочке скромно висит.
Ну красота же? Это вам не бездушные орг.чарты, это больше похоже на супрематизм Малевича (с которым Мейерхольд сотрудничал).
Подписи разобрать сложно, но справа вверху явно читается "ТЕО 1920-1921", "Отделов и секций". Дальше я немного теряюсь, может быть вы сможете лучше распознать. В центре зеленый треугольник — "Кино"? Под ним — "Те. Прос." и "Те. Обр.", то есть — театральное просвещение и образование? Справа в синем треугольнике — "Всеобуч"? (то есть, тут показаны ещё и смежные программы). Слева красный треугольник — ЦУТ, видимо "Центральное управление театрами"?
Среди мелкого текста можно разобрать "городской", "цирк", "школа", "массовых действий", "нац. меньшинств". ИИ где-то там видит ещё "режиссёрские курсы", "ТЕАТР", "Гостеатр", "Театр драмы", "Кукольный театр", "Мюзик-холл", "учреждения", "гос. труппы", "самодеятельность", "областные театры".
То есть это не только оргструктура, это ещё направления и области, которые контролирует и развивает ТЕО. Мейерхольд собирался радикально перестроить все театры (потому и был руководителем так недолго), и ему нужно было определить стратегию, так что это ещё и стратегический документ.
Как вам нравится такая визуализация? Использовали бы в своих проектах?
Но ещё лет 100 назад всё было не так очевидно.
Вот, например, организационная схема ТЕО — Театрального отдела Наркомпроса, составленная В.Э.Мейерхольдом, возглавлявшим этот отдел в 1920-1921 годах (с сентября по февраль, если быть точным).
В интернете её нет, я сфотографировал её в доме-музее Мейерхольда в Пензе, она там в уголочке скромно висит.
Ну красота же? Это вам не бездушные орг.чарты, это больше похоже на супрематизм Малевича (с которым Мейерхольд сотрудничал).
Подписи разобрать сложно, но справа вверху явно читается "ТЕО 1920-1921", "Отделов и секций". Дальше я немного теряюсь, может быть вы сможете лучше распознать. В центре зеленый треугольник — "Кино"? Под ним — "Те. Прос." и "Те. Обр.", то есть — театральное просвещение и образование? Справа в синем треугольнике — "Всеобуч"? (то есть, тут показаны ещё и смежные программы). Слева красный треугольник — ЦУТ, видимо "Центральное управление театрами"?
Среди мелкого текста можно разобрать "городской", "цирк", "школа", "массовых действий", "нац. меньшинств". ИИ где-то там видит ещё "режиссёрские курсы", "ТЕАТР", "Гостеатр", "Театр драмы", "Кукольный театр", "Мюзик-холл", "учреждения", "гос. труппы", "самодеятельность", "областные театры".
То есть это не только оргструктура, это ещё направления и области, которые контролирует и развивает ТЕО. Мейерхольд собирался радикально перестроить все театры (потому и был руководителем так недолго), и ему нужно было определить стратегию, так что это ещё и стратегический документ.
Как вам нравится такая визуализация? Использовали бы в своих проектах?
1🔥21🗿6⚡5❤3
McKinsey опубликовал карту принятия решений агентными ИИ. Точнее — какие решения можно им отдать и какую роль играет человек.
Получилась матрица, для разнообразия не 2x2, как обычно у консалтеров, а аж 3x3 — мир становится сложнее.
Ну хоть координат пока две:
— Риск от последствий неверного решения
— Сложность решения
Соответственно, риски могут быть трёх уровней:
— низкие (либо низка вероятность, либо почти нет урона)
— средние (потеряем много денег или репутацию)
— необратимые (может произойти что-то фатальное: гибель или ранения людей, разорение компаний, отзыв лицензий/запрет деятельности, падение рынков)
Сложность тоже делится на три уровня:
— низкая (простые повторяющиеся действия)
— средняя (есть некий паттерн, но в общем действия не совсем точно повторяются)
— высокая (ситуация сильно неоднозначная)
И дальше смотрим на пересечениях — какую роль играет ИИ, какую человек.
В правом верхнем — только решение человека. В левом нижнем — ИИ может действовать самостоятельно, без присмотра.
Дальше начинаются всякие интересные сочетания:
ИИ как исполнитель (принимает решения сам, человек мониторит)
ИИ как оператор (выполняет процесс, человек вовлекается в сложных случаях)
ИИ как ассистент (поддерживает, не принимает решения)
ИИ как коллаборатор (дает советы, человек валидирует)
В общем, тут нет сильно нового, я всё это видел лет 20 назад на фондовом рынке. ИИ тогда не очень был развит, но были алгоритмы и, прости господи, экспертные системы / системы поддержки принятия решений.
У нас были безрисковые роботы, про которых точно было известно, что они могут принести прибыль, но не могут сыграть в убыток (в основном за счет времени — если успеют, получат прибыль, если нет — ничего не получат, вот и всё. Риска нет.) Они просто запускались утром и отключались вечером, за ними особо и не следил никто, разве что для улучшения алгоритмов и скорости.
Были роботы с риском — они работали под пристальным наблюдением.
Были операции в миддле и бэке, проходящие автоматически — контроль рисков, формирование обязательств, проводок — человек за ними только следил, но в некоторых случаях брал управление на себя (или сама система передавала управления — что-то здесь я не понимаю, нужно вмешательство человека).
Была система, анализирующая и показывающая разные параметры сводного портфеля бумаг или валютной позиции — вот так, и вот так, и ещё в таком разрезе, эти данные подсветим, здесь подчеркнем, нужно обратить внимание, но финальное решение всегда за человеком. Или, например, калькулятор опционной стратегии — система посчитает, но решает трейдер всё равно.
Ну и были решения, которые вообще без всяких систем принимались, исключительно людьми.
А теперь всё то же не на рынке есть, а, например, в программировании или управлении продуктом. Ну и в анализе тоже будет.
Что уже сейчас можно отдать агентам?
Или иначе: где обычно находятся решения аналитика? Мне кажется (давайте поспорим!), что аналитик обычно работает в зоне низкого-среднего риска и средней-высокой сложности. С очень редкими попаданиями в зону высокого риска — туда аналитика не всегда пускают; точнее, там он выполняет как раз роль ИИ: makes recommendations, support humans. Это, кстати, и есть направление роста — хотите расти, идите туда, где ваши решения имеют больший риск.
Кстати, ИИ пока (пока!) не может удерживать под контролем долгосрочные дела — например, вести бухгалтерский баланс в течение года. Стратегические решения, от которых зависят будущие ситуации, пока плохо им всем даются. GPT o3, o4-mini и Gemini 2.5 Pro даже первый месяц не смогли корректно закрыть, Grok после 5-го месяца стал расходиться больше чем на 5%, а Claude Sonnet — после 8-го.
Получилась матрица, для разнообразия не 2x2, как обычно у консалтеров, а аж 3x3 — мир становится сложнее.
Ну хоть координат пока две:
— Риск от последствий неверного решения
— Сложность решения
Соответственно, риски могут быть трёх уровней:
— низкие (либо низка вероятность, либо почти нет урона)
— средние (потеряем много денег или репутацию)
— необратимые (может произойти что-то фатальное: гибель или ранения людей, разорение компаний, отзыв лицензий/запрет деятельности, падение рынков)
Сложность тоже делится на три уровня:
— низкая (простые повторяющиеся действия)
— средняя (есть некий паттерн, но в общем действия не совсем точно повторяются)
— высокая (ситуация сильно неоднозначная)
И дальше смотрим на пересечениях — какую роль играет ИИ, какую человек.
В правом верхнем — только решение человека. В левом нижнем — ИИ может действовать самостоятельно, без присмотра.
Дальше начинаются всякие интересные сочетания:
ИИ как исполнитель (принимает решения сам, человек мониторит)
ИИ как оператор (выполняет процесс, человек вовлекается в сложных случаях)
ИИ как ассистент (поддерживает, не принимает решения)
ИИ как коллаборатор (дает советы, человек валидирует)
В общем, тут нет сильно нового, я всё это видел лет 20 назад на фондовом рынке. ИИ тогда не очень был развит, но были алгоритмы и, прости господи, экспертные системы / системы поддержки принятия решений.
У нас были безрисковые роботы, про которых точно было известно, что они могут принести прибыль, но не могут сыграть в убыток (в основном за счет времени — если успеют, получат прибыль, если нет — ничего не получат, вот и всё. Риска нет.) Они просто запускались утром и отключались вечером, за ними особо и не следил никто, разве что для улучшения алгоритмов и скорости.
Были роботы с риском — они работали под пристальным наблюдением.
Были операции в миддле и бэке, проходящие автоматически — контроль рисков, формирование обязательств, проводок — человек за ними только следил, но в некоторых случаях брал управление на себя (или сама система передавала управления — что-то здесь я не понимаю, нужно вмешательство человека).
Была система, анализирующая и показывающая разные параметры сводного портфеля бумаг или валютной позиции — вот так, и вот так, и ещё в таком разрезе, эти данные подсветим, здесь подчеркнем, нужно обратить внимание, но финальное решение всегда за человеком. Или, например, калькулятор опционной стратегии — система посчитает, но решает трейдер всё равно.
Ну и были решения, которые вообще без всяких систем принимались, исключительно людьми.
А теперь всё то же не на рынке есть, а, например, в программировании или управлении продуктом. Ну и в анализе тоже будет.
Что уже сейчас можно отдать агентам?
Или иначе: где обычно находятся решения аналитика? Мне кажется (давайте поспорим!), что аналитик обычно работает в зоне низкого-среднего риска и средней-высокой сложности. С очень редкими попаданиями в зону высокого риска — туда аналитика не всегда пускают; точнее, там он выполняет как раз роль ИИ: makes recommendations, support humans. Это, кстати, и есть направление роста — хотите расти, идите туда, где ваши решения имеют больший риск.
Кстати, ИИ пока (пока!) не может удерживать под контролем долгосрочные дела — например, вести бухгалтерский баланс в течение года. Стратегические решения, от которых зависят будущие ситуации, пока плохо им всем даются. GPT o3, o4-mini и Gemini 2.5 Pro даже первый месяц не смогли корректно закрыть, Grok после 5-го месяца стал расходиться больше чем на 5%, а Claude Sonnet — после 8-го.
👍21❤5🔥2🤔2
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
🔥45😁11❤4👍3👻2
Вот интересно, в одной дискуссии мнения разделились — правда ли, что все побежали срочно везде внедрять ИИ? Есть KPI, цели, метрики. Или как-то так, самотеком? Поэтому сейчас будет мини-опрос, как у вас (и где вы — в РФ или нет).
Как у вас в компании внедряется ИИ — активно и целенаправлено, или самотеком?
Anonymous Poll
47%
Активно внедряется (РФ)
6%
Активно внедряется (не РФ)
34%
Пущено на самотек (РФ)
5%
Пущено на самотек (не РФ)
7%
У нас ИИ вообще запрещен
❤2
Люблю, когда люди пишут и развивают свои каналы. Но иногда немного дополнительной мотивации не помешает. Systems.education объявляет конкурс на посты про системный и бизнес-анализ, проектирование систем. Я там буду в жюри. Пишите, почитаем!
❤3🔥2👍1
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
🏆 Конкурс авторских публикаций «Продолжи мысль» от Systems.Education
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
⏰Прием заявок до 11.08 включительно
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
👍8❤2🔥1
Пост на злобу дня: Аэрофлот упал, но быстро поднялся. В других отраслях тоже проблемы — то ли из-за атак, то ли по другим причинам.
Это всё, с одной стороны, про безопасность, а с другой — про непрерывность бизнеса. Обычно это считают подразделом безопасности — требования иметь планы BCP и DRP описаны в стандарте ISO 27001, в основном в виде сохранения защиты данных при авариях/чрезвычайных происшествий.
BCP — Business Continuity Plan: как мы собираемся работать, несмотря ни на что (атаки, аварии, стихийные бедствия, другие форс-мажоры).
DRP — Disaster Recovery Plan: как мы собираемся восстанавливаться после аварии.
Это очень клёвые документы, особенно если они разработаны по-честному, а не для галочки/чтобы пройти аудит. Это как аптечка в походе — обычно не нужна, но если нужна, то очень.
Близки к этому понятия RTO — Recovery Time Objective, целевое время восстановления, и RPO — Recovery Point Objective, целевая точка восстановления (а к какому, собственно, состоянию мы восстанавливаемся, что мы готовы потерять? далеко не факт, что ответ "ничего не готовы").
Я вам честно скажу — не знаю, как это в крупных компаниях организовано. Вроде интернет говорит, что есть какие-то отдельные BCM — Business Continuity Managers, менеджеры по непрерывности бизнеса. Не знаю, не видел.
В проектах, где я в разработке таких планов участвовал, всегда была рабочая группа из представителей бизнеса (операционного подразделения, клиентского, рисков), безопасности, ИТ и с обязательными участием бизнес- и системных аналитиков. Потому что бизнес выдает требования и оценивает последствия рисков, ИТ предлагает решения, а прокапыванием и проектированием деталей занимается аналитик. Ну а кто кроме БА знает, что в процессе может пойти не так и как его можно выполнить альтернативно?
Какие процессы наиболее критичны? Какая последовательность восстановления? Какие системы наиболее критичны для работы?
Есть документ, который даже в названии содержит слово "анализ": BIA — Business Impact Analysis.
Это вообще кайфовый документ для людей, склонных к упорядочиванию всего: вот у нас есть такой риск, что случится, если он реализуется? Что кто будет делать? Что кто не сможет сделать? Какие процессы остановятся/замедлятся? К чему это приведет? Что мы потеряем в деньгах и репутации, чем навредим людям, партнерам и обществу?
Упражнение в чем-то напоминает то, что дает Сергей Нужненко: Какие входы у вас есть? Какие выходы? Какие ресурсы? Как это всё управляется? Что будет, если потоки на них прервутся/замедлятся? Люди не смогут войти в здание, оборвется электричество, заболеют ключевые сотрудники, будут уничтожены данные / виртуальные сервера, прекратится доступ к Интернету или отдельным сервисам?
В конце концов, у армии США есть даже план по отражению угрозы нашествия зомби (CONPLAN 8888), а чем мы хуже?
В отличие от анализа рисков BIA (а также BCP и DRP) подразумевает ещё и необходимые ресурсы. Например, в одной организации мне гордо показывали серверную с собственным охлаждением, резервным питанием и выводом для подключения внешнего генератора. На мой вопрос, а заключен ли договор с поставщиками таких генераторов, ну или хотя бы есть ли их список под рукой, люди только удивленно хлопали глазами. Конечно, когда через год возник локальный пожар в щитке и серверная осталась без электричества, никакой внешний генератор быстро не приехал.
А в другой компании наоборот — не говоря о резервировании ИТ, был даже заключен договор на целый резервный офис с подготовленным оборудованием и периодически проводились учения по его развертыванию.
Это всё, с одной стороны, про безопасность, а с другой — про непрерывность бизнеса. Обычно это считают подразделом безопасности — требования иметь планы BCP и DRP описаны в стандарте ISO 27001, в основном в виде сохранения защиты данных при авариях/чрезвычайных происшествий.
BCP — Business Continuity Plan: как мы собираемся работать, несмотря ни на что (атаки, аварии, стихийные бедствия, другие форс-мажоры).
DRP — Disaster Recovery Plan: как мы собираемся восстанавливаться после аварии.
Это очень клёвые документы, особенно если они разработаны по-честному, а не для галочки/чтобы пройти аудит. Это как аптечка в походе — обычно не нужна, но если нужна, то очень.
Близки к этому понятия RTO — Recovery Time Objective, целевое время восстановления, и RPO — Recovery Point Objective, целевая точка восстановления (а к какому, собственно, состоянию мы восстанавливаемся, что мы готовы потерять? далеко не факт, что ответ "ничего не готовы").
Я вам честно скажу — не знаю, как это в крупных компаниях организовано. Вроде интернет говорит, что есть какие-то отдельные BCM — Business Continuity Managers, менеджеры по непрерывности бизнеса. Не знаю, не видел.
В проектах, где я в разработке таких планов участвовал, всегда была рабочая группа из представителей бизнеса (операционного подразделения, клиентского, рисков), безопасности, ИТ и с обязательными участием бизнес- и системных аналитиков. Потому что бизнес выдает требования и оценивает последствия рисков, ИТ предлагает решения, а прокапыванием и проектированием деталей занимается аналитик. Ну а кто кроме БА знает, что в процессе может пойти не так и как его можно выполнить альтернативно?
Какие процессы наиболее критичны? Какая последовательность восстановления? Какие системы наиболее критичны для работы?
Есть документ, который даже в названии содержит слово "анализ": BIA — Business Impact Analysis.
Это вообще кайфовый документ для людей, склонных к упорядочиванию всего: вот у нас есть такой риск, что случится, если он реализуется? Что кто будет делать? Что кто не сможет сделать? Какие процессы остановятся/замедлятся? К чему это приведет? Что мы потеряем в деньгах и репутации, чем навредим людям, партнерам и обществу?
Упражнение в чем-то напоминает то, что дает Сергей Нужненко: Какие входы у вас есть? Какие выходы? Какие ресурсы? Как это всё управляется? Что будет, если потоки на них прервутся/замедлятся? Люди не смогут войти в здание, оборвется электричество, заболеют ключевые сотрудники, будут уничтожены данные / виртуальные сервера, прекратится доступ к Интернету или отдельным сервисам?
В конце концов, у армии США есть даже план по отражению угрозы нашествия зомби (CONPLAN 8888), а чем мы хуже?
В отличие от анализа рисков BIA (а также BCP и DRP) подразумевает ещё и необходимые ресурсы. Например, в одной организации мне гордо показывали серверную с собственным охлаждением, резервным питанием и выводом для подключения внешнего генератора. На мой вопрос, а заключен ли договор с поставщиками таких генераторов, ну или хотя бы есть ли их список под рукой, люди только удивленно хлопали глазами. Конечно, когда через год возник локальный пожар в щитке и серверная осталась без электричества, никакой внешний генератор быстро не приехал.
А в другой компании наоборот — не говоря о резервировании ИТ, был даже заключен договор на целый резервный офис с подготовленным оборудованием и периодически проводились учения по его развертыванию.
❤13👍5🔥2