Channel: Системный сдвиг
Красивая картинка про оценки трудоемкости разработки софта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
This media is not supported in your browser
VIEW IN TELEGRAM
В вебинаре про карту интеграций был вопрос про первую версию, которая с кружочками. Точнее, про инструмент, в котором я её визуализировал.
Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.
Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery
В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.
А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/
Я тащусь от красивых визуализаций.
В другой жизни я бы, наверное, был бы владельцем студии инфографики и интерактивных сервисов, но не сложилось.
Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.
Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery
В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.
А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/
Я тащусь от красивых визуализаций.
В другой жизни я бы, наверное, был бы владельцем студии инфографики и интерактивных сервисов, но не сложилось.
Отличный подгон от Андрея Буракова — репозиторий со ссылками на тему интеграций: https://github.com/stn1slv/awesome-integration
Там много ссылок на конкретные продукты для разных кейсов:
API Management
API Design
API Documentation
API Gateway
API Testing
BPM
Data Mapping Solution и т.д.,
а ещё ссылки на разные паттерны, нужно будет тоже собрать каталог с переводом.
Ну и вообще рекомендую канал Андрея Yet Another Analyst — он сам много пишет про интеграции, очень часто провокационные посты, но это взгляд реального практика.
Вот про шины: Страх и ненависть в шиномонтаже
А вот про гарантии доставки: часть 1 и часть 2 (спойлер: это не гарантии доставки, это гарантии обработки!)
Или про разные цели инженера, продакта и предпринимателя (can relate, всё так и есть, это я вам как человек, побывавший во всех трех позициях могу сказать. А при попытке совместить — то ещё расщепление личности начинается).
В общем, держите канал "ещё одного аналитика". А на самом деле — ещё и архитектора, и предпринимателя👀
Там много ссылок на конкретные продукты для разных кейсов:
API Management
API Design
API Documentation
API Gateway
API Testing
BPM
Data Mapping Solution и т.д.,
а ещё ссылки на разные паттерны, нужно будет тоже собрать каталог с переводом.
Ну и вообще рекомендую канал Андрея Yet Another Analyst — он сам много пишет про интеграции, очень часто провокационные посты, но это взгляд реального практика.
Вот про шины: Страх и ненависть в шиномонтаже
А вот про гарантии доставки: часть 1 и часть 2 (спойлер: это не гарантии доставки, это гарантии обработки!)
Или про разные цели инженера, продакта и предпринимателя (can relate, всё так и есть, это я вам как человек, побывавший во всех трех позициях могу сказать. А при попытке совместить — то ещё расщепление личности начинается).
В общем, держите канал "ещё одного аналитика". А на самом деле — ещё и архитектора, и предпринимателя
Please open Telegram to view this post
VIEW IN TELEGRAM
Очень частый вопрос, про который вам не расскажут ни в каких материалах по подготовке к собеседованиям.
Поэтому он обычно возникает уже у работающих аналитиков: как составить документ требований?
А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.
Для документов системного анализа она тоже подходит, но давайте раскрою чуть конкретнее. Мы, на самом деле, этими документами хотим убедить заказчиков, что:
- система/доработка нужна;
- она решит проблему заказчика;
- она гораздо сложнее, чем думал заказчик (поэтому нужно дать больше денег).
Итак, принципы пирамиды Куприянова:
1. Документ строится от общего к частному (от бизнес-понятий и целей к деталям реализации) и от знакомого к новому (от того, что уже есть, к тому, что будет). Что знакомо вашим заказчикам? Они сами и их задачи. Поэтому в начале приводим цели создания системы — на языке бизнеса, перечисляем роли пользователей и их задачи (они должны себя узнать). Можно привести обобщенную модель бизнес-процесса — на этом уровне без деталей.
2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.
3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.
4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.
5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)
На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой
/интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.
Дальше начинается новое, что мы собственно предлагаем сделать. Сценарии юскейсов: а как пользователи будут достигать своих целей. Архитектура: как мы обеспечим показатели назначения и качества. Как мы это покажем в интерфейсах пользователя и API?
Этого ещё нет, это наши проектные решения. Из решений могут следовать новые требования. Они относятся к элементам решения: экранам, API, отчетам. Обычно эта часть документа более подробная. Может быть это даже отдельные документы. И так доходим до деталей реализации, которые бизнес-заказчик и смотреть не будет, это техника.
Поэтому он обычно возникает уже у работающих аналитиков: как составить документ требований?
А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.
Для документов системного анализа она тоже подходит, но давайте раскрою чуть конкретнее. Мы, на самом деле, этими документами хотим убедить заказчиков, что:
- система/доработка нужна;
- она решит проблему заказчика;
- она гораздо сложнее, чем думал заказчик (поэтому нужно дать больше денег).
Итак, принципы пирамиды Куприянова:
1. Документ строится от общего к частному (от бизнес-понятий и целей к деталям реализации) и от знакомого к новому (от того, что уже есть, к тому, что будет). Что знакомо вашим заказчикам? Они сами и их задачи. Поэтому в начале приводим цели создания системы — на языке бизнеса, перечисляем роли пользователей и их задачи (они должны себя узнать). Можно привести обобщенную модель бизнес-процесса — на этом уровне без деталей.
2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.
3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.
4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.
5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)
На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой
/интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.
Дальше начинается новое, что мы собственно предлагаем сделать. Сценарии юскейсов: а как пользователи будут достигать своих целей. Архитектура: как мы обеспечим показатели назначения и качества. Как мы это покажем в интерфейсах пользователя и API?
Этого ещё нет, это наши проектные решения. Из решений могут следовать новые требования. Они относятся к элементам решения: экранам, API, отчетам. Обычно эта часть документа более подробная. Может быть это даже отдельные документы. И так доходим до деталей реализации, которые бизнес-заказчик и смотреть не будет, это техника.
Есть такой клёвый инструмент — Tech Radar, радар используемых технологий в компании.
Придумали его thoughtworks — компания, в которой, например, работает Мартин Фаулер в классной должности Chief Scientist (я бы тоже таким работал!)
Это такое графическое представление разных технологий, которые использует или к которым присматривается компания. В оригинале он разбит на четыре сектора: техники/подходы, инструменты, платформы, языки/фреймворки. В каждом секторе есть 4 кольца:
Adopt — то, что в компании активно используется и является практически стандартом.
Trial — то, что готово к использованию, даже где-то применяется в исследовательских целях, но в этом мы не так уверены, как в предыдущих технологиях.
Assess — то, к чему мы присматриваемся, но пока даже не проводим исследования
Hold — то, что уже не должно применяться в новых проектах, но может ещё оставаться в легаси
Для крупных компаний с десятками и сотнями команд это хороший ориентир для разработчиков при старте новых проектов — а что у нас есть, на чем делать будем. Так же это и для привлечения специалистов работает — смотрите, какой у нас стек модный! — поэтому многие их публикуют в открытом доступе.
Вот, например, Т-Банк: https://radar.tinkoff.ru/
Мы тут видим в Adopt: OpenAPI, Scrum/Kanban, Feature Toggle, а вот DDD — только в Trial.
Нас интересует, понятно, сектор "Техники", может быть — "Инструменты" (хотя часто их не очень-то различают).
Вот Авито: https://techradar.avito.ru/
Swagger 2.0 — в Adopt, OpenAPI 3.0 — в Assess
МТС: https://mts-digital.ru/technology/techradar/
В Adopt есть Archi(!), а в Hold — Figma(!). Зато в фреймворках есть gRPC.
HH: https://hh.ru/article/techradar
В общем, практически ни у кого ничего по системному анализу! А очень зря, между прочим.
Если у вас хоть сколько-нибудь аналитиков в компании есть — имеет смысл такую карту составить.
Там будут, конечно, только техники, подходы и инструменты, но уже это само по себе полезно.
Что мы сейчас применяем — юзер-стори или юскейсы? А диаграммы мы рисуем где — в draw.io или в plantuml?
И для себя полезно понимать, и новички не будут сомневаться. Такая ситуационная инженерия метода работы на минималках.
У самих thoughtworks на радаре совсем другое, там сплошной ИИ:
В Adopt: RAG, в Trial: Small language models, генерация синтетических данных для тестов, LLM для реверс-инженеринга, вызовы функций из LLM и всякое такое. А ещё — Domain Storytelling! Как облегченная версия Event Storming'a. При этом DDD даже нет на радаре, это у них вообще "фундаментальный подход к созданию ПО". А Event Storming у них вошел в Adopt ещё в 2018 году.
В Assess — тоже сплошной LLM, но ещё, например, GraphQL как инструмент talk-to-data: когда LLM-ка для ответа на вопрос формирует запрос GraphQL, вызывает его, парсит и отвечает по-человечески.
В общем, прямо разительные отличия: в наших-то радарах вообще про ИИ мало. И это октябрь прошлого года! Новый техрадар от thoughtworks выходит буквально сейчас: ещё не опубликован, пока только представлен в вебинарах, буквально позавчера.
Опубликуют — посмотрим, какой там прогресс. Сами они называют ситуацию с LLM "кембрийским взрывом". Кто не запрыгнет — останется вендобионтом 😂
Придумали его thoughtworks — компания, в которой, например, работает Мартин Фаулер в классной должности Chief Scientist (я бы тоже таким работал!)
Это такое графическое представление разных технологий, которые использует или к которым присматривается компания. В оригинале он разбит на четыре сектора: техники/подходы, инструменты, платформы, языки/фреймворки. В каждом секторе есть 4 кольца:
Adopt — то, что в компании активно используется и является практически стандартом.
Trial — то, что готово к использованию, даже где-то применяется в исследовательских целях, но в этом мы не так уверены, как в предыдущих технологиях.
Assess — то, к чему мы присматриваемся, но пока даже не проводим исследования
Hold — то, что уже не должно применяться в новых проектах, но может ещё оставаться в легаси
Для крупных компаний с десятками и сотнями команд это хороший ориентир для разработчиков при старте новых проектов — а что у нас есть, на чем делать будем. Так же это и для привлечения специалистов работает — смотрите, какой у нас стек модный! — поэтому многие их публикуют в открытом доступе.
Вот, например, Т-Банк: https://radar.tinkoff.ru/
Мы тут видим в Adopt: OpenAPI, Scrum/Kanban, Feature Toggle, а вот DDD — только в Trial.
Нас интересует, понятно, сектор "Техники", может быть — "Инструменты" (хотя часто их не очень-то различают).
Вот Авито: https://techradar.avito.ru/
Swagger 2.0 — в Adopt, OpenAPI 3.0 — в Assess
МТС: https://mts-digital.ru/technology/techradar/
В Adopt есть Archi(!), а в Hold — Figma(!). Зато в фреймворках есть gRPC.
HH: https://hh.ru/article/techradar
В общем, практически ни у кого ничего по системному анализу! А очень зря, между прочим.
Если у вас хоть сколько-нибудь аналитиков в компании есть — имеет смысл такую карту составить.
Там будут, конечно, только техники, подходы и инструменты, но уже это само по себе полезно.
Что мы сейчас применяем — юзер-стори или юскейсы? А диаграммы мы рисуем где — в draw.io или в plantuml?
И для себя полезно понимать, и новички не будут сомневаться. Такая ситуационная инженерия метода работы на минималках.
У самих thoughtworks на радаре совсем другое, там сплошной ИИ:
В Adopt: RAG, в Trial: Small language models, генерация синтетических данных для тестов, LLM для реверс-инженеринга, вызовы функций из LLM и всякое такое. А ещё — Domain Storytelling! Как облегченная версия Event Storming'a. При этом DDD даже нет на радаре, это у них вообще "фундаментальный подход к созданию ПО". А Event Storming у них вошел в Adopt ещё в 2018 году.
В Assess — тоже сплошной LLM, но ещё, например, GraphQL как инструмент talk-to-data: когда LLM-ка для ответа на вопрос формирует запрос GraphQL, вызывает его, парсит и отвечает по-человечески.
В общем, прямо разительные отличия: в наших-то радарах вообще про ИИ мало. И это октябрь прошлого года! Новый техрадар от thoughtworks выходит буквально сейчас: ещё не опубликован, пока только представлен в вебинарах, буквально позавчера.
Опубликуют — посмотрим, какой там прогресс. Сами они называют ситуацию с LLM "кембрийским взрывом". Кто не запрыгнет — останется вендобионтом 😂
This media is not supported in your browser
VIEW IN TELEGRAM
ByteByteGo в рассылке подогнал роадмэп развития архитектора ПО.
Посмотрим, какие есть пересечения с системными аналитиками.
1. Языки. Выучить парочку языков программирования для бэкенда. Java, Python, Go, JS. Ну, тут мимо.
2. Инструменты. GitHub, Jenkins, Jira, ELK, Sonar. Аналитик из этого знает обычно Jira и может быть GitHub. GitHub — это хранение исходников и версий (тут, думаю, в первую очередь имеется в виду сама идея работы с git: все эти пуллы, пуши, коммиты, ветки и PR. Кстати, если хотите разобраться и потренироваться — есть вот такой клёвый симулятор: https://learngitbranching.js.org/). Jenkins — это конструктор пайплана CI/CD, Sonar (видимо, всё же SonarQube) — анализатор качества кода. ELK — это типовое решение для сбора и анализа логов, состоящее из трех open source решений: Elasticsearch, Logstash и Kibana. Logstash собирает и парсит логи и складывает их в БД Elasticsearch, а Kibana строит визуализации. Elasticsearch — NoSQL база данных и поисковый движок. Если у вас есть интеграции, скорее всего, у вас уже развернут ELK. Что интересно, аналитик практически никогда не пишет требования к сбору логов. Оно само как-то.
3. Принципы проектирования: ООП и паттерны ООП (называются GoF — Gang of Four, Банда Четырех, по четырем авторам); TDD — разработка через тестирование; Clean Code; это всё про программирование и конструкции внутри программы, аналитикам наверное не особо нужно. А вот о чем аналитик должен иметь представление: DDD, ACID, MVC, CAP-теорема. Если вы работаете с интеграциями — вам важнее ACID и CAP (а может и PACELC), если с вебом — MVC хотя бы на уровне концепции. Ну а DDD в любом случае.
4. Архитектурные паттерны: слоистая архитектура, микросервисы, публикация/подписка, клиент-сервер, EDA (событийно-ориентированная), гексагональная архитектура. Тут лучше всё изучить, особенно если вы занимаетесь интеграциями. Кроме, разве что, гексагональной архитектуры. Почему вообще гексагональная и MVC в разные разделы попали, я не очень понимаю. И куда дели Clean Architecture. Кажется, в 3 разделе больше про внутреннюю архитектуру, а тут больше про распределенные. Ну да ладно. Про разные виды архитектур в Systems.Education вот даже книгу перевели: https://systems.education/software-architecture-patterns
5. Платформенные знания. Контейнеры, оркестрация, облака, бессерверная архитектура, CDN, шлюзы, распределенные системы, CI/CD. Хотя бы понимать на уровне названий — что это такое, когда и для чего используется. API-шлюзы и оркестрация — это практически про интеграцию, CDN — про веб.
6. Данные и аналитика. Это тоже очень часто попадает в задачи аналитика. SQL, NoSQL, Kafkа — это всё знакомые слова. Data Streaming, OLAP, Object Storage, Data Migration — менее знакомые, но про миграции я регулярно слышу доклады, кажется это тоже попадает к аналитику.
7. Сети и безопасность. Уровень ниже, чем обычно смотрит аналитик, но, опять же, базовые понятия нужно знать, если вы работаете с интеграциями — например, разные виды обеспечения безопасности и аутентификации. А если вам критичная скорость, то можно и в TCP/IP занырнуть.
8. Дополнительные навыки: технологии, принятие решений, управление стейкхолдерами, коммуникация, оценки, лидерство. Тут, кажется, больше половины про аналитика, а то и все.
В целом получается, что системный аналитик — это как будто уже наполовину архитектор. Без знания программирования, без заглядывания в код и без конкретных инфраструктурных инструментов.
Сакраментальный вопрос: можно ли всё-таки дорасти до архитектора без опыта промышленного программирования? (Совсем без заглядывания в код и понимания, из чего он состоит, видимо, нет)
Посмотрим, какие есть пересечения с системными аналитиками.
1. Языки. Выучить парочку языков программирования для бэкенда. Java, Python, Go, JS. Ну, тут мимо.
2. Инструменты. GitHub, Jenkins, Jira, ELK, Sonar. Аналитик из этого знает обычно Jira и может быть GitHub. GitHub — это хранение исходников и версий (тут, думаю, в первую очередь имеется в виду сама идея работы с git: все эти пуллы, пуши, коммиты, ветки и PR. Кстати, если хотите разобраться и потренироваться — есть вот такой клёвый симулятор: https://learngitbranching.js.org/). Jenkins — это конструктор пайплана CI/CD, Sonar (видимо, всё же SonarQube) — анализатор качества кода. ELK — это типовое решение для сбора и анализа логов, состоящее из трех open source решений: Elasticsearch, Logstash и Kibana. Logstash собирает и парсит логи и складывает их в БД Elasticsearch, а Kibana строит визуализации. Elasticsearch — NoSQL база данных и поисковый движок. Если у вас есть интеграции, скорее всего, у вас уже развернут ELK. Что интересно, аналитик практически никогда не пишет требования к сбору логов. Оно само как-то.
3. Принципы проектирования: ООП и паттерны ООП (называются GoF — Gang of Four, Банда Четырех, по четырем авторам); TDD — разработка через тестирование; Clean Code; это всё про программирование и конструкции внутри программы, аналитикам наверное не особо нужно. А вот о чем аналитик должен иметь представление: DDD, ACID, MVC, CAP-теорема. Если вы работаете с интеграциями — вам важнее ACID и CAP (а может и PACELC), если с вебом — MVC хотя бы на уровне концепции. Ну а DDD в любом случае.
4. Архитектурные паттерны: слоистая архитектура, микросервисы, публикация/подписка, клиент-сервер, EDA (событийно-ориентированная), гексагональная архитектура. Тут лучше всё изучить, особенно если вы занимаетесь интеграциями. Кроме, разве что, гексагональной архитектуры. Почему вообще гексагональная и MVC в разные разделы попали, я не очень понимаю. И куда дели Clean Architecture. Кажется, в 3 разделе больше про внутреннюю архитектуру, а тут больше про распределенные. Ну да ладно. Про разные виды архитектур в Systems.Education вот даже книгу перевели: https://systems.education/software-architecture-patterns
5. Платформенные знания. Контейнеры, оркестрация, облака, бессерверная архитектура, CDN, шлюзы, распределенные системы, CI/CD. Хотя бы понимать на уровне названий — что это такое, когда и для чего используется. API-шлюзы и оркестрация — это практически про интеграцию, CDN — про веб.
6. Данные и аналитика. Это тоже очень часто попадает в задачи аналитика. SQL, NoSQL, Kafkа — это всё знакомые слова. Data Streaming, OLAP, Object Storage, Data Migration — менее знакомые, но про миграции я регулярно слышу доклады, кажется это тоже попадает к аналитику.
7. Сети и безопасность. Уровень ниже, чем обычно смотрит аналитик, но, опять же, базовые понятия нужно знать, если вы работаете с интеграциями — например, разные виды обеспечения безопасности и аутентификации. А если вам критичная скорость, то можно и в TCP/IP занырнуть.
8. Дополнительные навыки: технологии, принятие решений, управление стейкхолдерами, коммуникация, оценки, лидерство. Тут, кажется, больше половины про аналитика, а то и все.
В целом получается, что системный аналитик — это как будто уже наполовину архитектор. Без знания программирования, без заглядывания в код и без конкретных инфраструктурных инструментов.
Сакраментальный вопрос: можно ли всё-таки дорасти до архитектора без опыта промышленного программирования? (Совсем без заглядывания в код и понимания, из чего он состоит, видимо, нет)
Ооо, IETF вчера выпустило RFC 9759 Unified Time Scaling for Temporal Coordination Frameworks (https://datatracker.ietf.org/doc/html/rfc9759) — фреймворк для оценивания сроков различных работ. Вот этого нам давно не хватало! Привожу таблицу для округления оценок оттуда. Теперь заживем, все эстимейты будут точнее — есть стандарт!
Я вообще редко делаю репосты, но иногда контент того стоит. Вот, например, отличные карточки (и док, пройдите по ссылке, скопируйте себе) про именование топиков в Кафке.
Тема типичная для bikeshedding'а (как это по-русски? Долгое обсуждение мелких малозначительных деталей). Нужно один раз договориться, и придерживаться правил.
Вот тут есть ещё парочка вариантов: https://cnr.sh/posts/2017-08-29-how-paint-bike-shed-kafka-topic-naming-conventions/ , https://www.kadeck.com/blog/kafka-topic-naming-conventions-5-recommendations-with-examples , все сходятся на следующих правилах:
1. маленькими буквами, через точку.
2. использовать названия бизнес-доменов, сущностей и событий, а не названия продюсеров, консьюмеров, схем данных и команд разработки (они могут меняться).
3. выделять внешние (public) и внутренние (private) топики
Про номер версии мнения расходятся, некоторые рекомендуют складывать не в название, а в header, ну это как с версионированием в HTTP: хотите ли вы до конца сохранять обратную совместимость, или хотите, чтобы старые клиенты побыстрее отвалились и перешли на новую версию?
А у вас какие правила именования топиков?
Тема типичная для bikeshedding'а (как это по-русски? Долгое обсуждение мелких малозначительных деталей). Нужно один раз договориться, и придерживаться правил.
Вот тут есть ещё парочка вариантов: https://cnr.sh/posts/2017-08-29-how-paint-bike-shed-kafka-topic-naming-conventions/ , https://www.kadeck.com/blog/kafka-topic-naming-conventions-5-recommendations-with-examples , все сходятся на следующих правилах:
1. маленькими буквами, через точку.
2. использовать названия бизнес-доменов, сущностей и событий, а не названия продюсеров, консьюмеров, схем данных и команд разработки (они могут меняться).
3. выделять внешние (public) и внутренние (private) топики
Про номер версии мнения расходятся, некоторые рекомендуют складывать не в название, а в header, ну это как с версионированием в HTTP: хотите ли вы до конца сохранять обратную совместимость, или хотите, чтобы старые клиенты побыстрее отвалились и перешли на новую версию?
А у вас какие правила именования топиков?
cnr.sh
Kafka Topic Naming Conventions | cnr.sh
Today, I'll be tackling the controversial subject of Kafka topic names. Not only will I review various schemes, but I've decided to take a stand on a few issues and outline my reasoning. Get out ...
Про (не)простые типы данных или что в имени тебе моем?
Вы, наверное, заметили, что я очень люблю стандарты. Ещё я люблю изучать разные стандарты и подходы из разных предметных областей — это тренирует насмотренность и можно подглядеть решения типовых проблем и как с ними справляются. Например, почти у всех есть задачи назначения и контроля полномочий, управления пользователями, какие-то инфраструктурные вещи (синхронизация времени для ведения журналов, например, из PCI DSS).
Я в начале своего трудового пути писал софт для медицины — цифровая обработка ЭКГ, комплекс диагностики тканей в раневой зоне в процессе заживления, ранняя диагностика катаракты глаза — было интересно. Коллеги рядом писали учетный софт для больниц — первые электронные мед.карты, статистика для страховых — тоже любопытно. Это ещё в прошлом веке было.
В медицине есть такой стандарт — HL7, Health Level 7, он ещё в 80-х разрабатывался, до XML, в общем, старинная история. Ну и за это время много кейсов в себя вобрал. Я не знаю, насколько он в России сейчас распространен, но официальный перевод существует (ГОСТ Р ИСО/HL7 27931-2015) и некоторые системы точно его поддерживают.
И вот в этом HL7 есть поле для хранения имени пациента. Ну, что тут можно изобрести? ФИО в одну строку или ФИО в трех полях, какие ещё варианты, казалось бы? В HL7 под имя заведено 15 полей. Ну ладно, под расширенное имя. Поля там такие:
XPN.1 Семейное имя. Это сложный тип, у которого в свою очередь следующие поля:
FN.1 Фамилия
FN.2 Префикс собственной фамилии ("де", "фон")
FN.3 Собственная фамилия (девичья фамилия)
FN.4 Префикс фамилии партнера/супруга
FN.5 Фамилия партнера/супруга
Префикс тут выделяется не просто так, а по прагматичным соображениям: он не участвует в сортировке (иначе все "фоны" были бы на "ф").
XPN.2 Личное имя.
XPN.3 Последующие личные имена, отчество, инициалы (через пробел)
XPN.4 Суффикс ("мл." или "III")
XPN.5 Префикс ("д-р")
XPN.6 Ученая степень / сертификат (раньше тут был справочник степеней, типа "MD" или "PHD", по нашему будет "к.т.н."; с версии 2.5 не используется, см. XPN.14)
XPN.7 Код типа имени (ссылка на справочник типов имен, он достоин быть приведенным целиком:
"псевдоним",
"имя при рождении",
"имя при усыновлении",
"для отображения на экране",
"указанное в лицензии",
"юридически признаваемое",
"девичье",
"кличка, прозвище",
"зарегистрированная кличка (для животных)",
"кодированный псевдоним для анонимизации",
"племенное имя",
"религиозное",
"имя новорожденного до получения документов",
"более неиспользуемое, деднейм",
"временное",
"неправильное",
"неизвестное")
Тут видны разнообразные кейсы, с которыми медицина сталкивается.
XPN.8 Код представления имени (это для иероглифических языков: алфавитное, идеографическое, фонетическое)
XPN.9 Контекст использования имени (ссылка на пользовательский справочник; я не нашел примеров, говорят, это актуально для австралийских аборигенов, которые называют себя разными именами в разных больницах)
XPN.10 Период действия имени (с версии 2.5 не используется, заменен на XPN.12 и XPN.13)
XPN.11 Порядок сборки имени (ссылка на справочник со значениями типа "Prefix Family Middle Given Suffix")
XPN.12 Дата начала действия (да, это ещё и темпоральная таблица!)
XPN.13 Срок действия (последняя дата использования)
XPN.14 Профессиональный суффикс (просто строка, используется только для отображения)
XPN.15 Как обращаться (например, по всем документам человек Владимир, а предпочитает, чтобы его звали Дима. Или у священнослужителей — "отец Иоанн").
Я почему-то не вижу тут признака языка, он есть только в конкретном сообщении, хотя напрашивается несколько вариантов, но видимо как-то с этим справляются.
В общем, пока это самая замороченная система хранения личных имен, которая мне встречалась. Не уверен, что всё из этого я бы стал реализовывать в каждой системе, но вот с разными написаниями, девичьими фамилиями, множественными фамилиями и именами, деднеймами и сроком действия имен приходилось сталкиваться, каждый раз это какое-то мучение.
Вы, наверное, заметили, что я очень люблю стандарты. Ещё я люблю изучать разные стандарты и подходы из разных предметных областей — это тренирует насмотренность и можно подглядеть решения типовых проблем и как с ними справляются. Например, почти у всех есть задачи назначения и контроля полномочий, управления пользователями, какие-то инфраструктурные вещи (синхронизация времени для ведения журналов, например, из PCI DSS).
Я в начале своего трудового пути писал софт для медицины — цифровая обработка ЭКГ, комплекс диагностики тканей в раневой зоне в процессе заживления, ранняя диагностика катаракты глаза — было интересно. Коллеги рядом писали учетный софт для больниц — первые электронные мед.карты, статистика для страховых — тоже любопытно. Это ещё в прошлом веке было.
В медицине есть такой стандарт — HL7, Health Level 7, он ещё в 80-х разрабатывался, до XML, в общем, старинная история. Ну и за это время много кейсов в себя вобрал. Я не знаю, насколько он в России сейчас распространен, но официальный перевод существует (ГОСТ Р ИСО/HL7 27931-2015) и некоторые системы точно его поддерживают.
И вот в этом HL7 есть поле для хранения имени пациента. Ну, что тут можно изобрести? ФИО в одну строку или ФИО в трех полях, какие ещё варианты, казалось бы? В HL7 под имя заведено 15 полей. Ну ладно, под расширенное имя. Поля там такие:
XPN.1 Семейное имя. Это сложный тип, у которого в свою очередь следующие поля:
FN.1 Фамилия
FN.2 Префикс собственной фамилии ("де", "фон")
FN.3 Собственная фамилия (девичья фамилия)
FN.4 Префикс фамилии партнера/супруга
FN.5 Фамилия партнера/супруга
Префикс тут выделяется не просто так, а по прагматичным соображениям: он не участвует в сортировке (иначе все "фоны" были бы на "ф").
XPN.2 Личное имя.
XPN.3 Последующие личные имена, отчество, инициалы (через пробел)
XPN.4 Суффикс ("мл." или "III")
XPN.5 Префикс ("д-р")
XPN.6 Ученая степень / сертификат (раньше тут был справочник степеней, типа "MD" или "PHD", по нашему будет "к.т.н."; с версии 2.5 не используется, см. XPN.14)
XPN.7 Код типа имени (ссылка на справочник типов имен, он достоин быть приведенным целиком:
"псевдоним",
"имя при рождении",
"имя при усыновлении",
"для отображения на экране",
"указанное в лицензии",
"юридически признаваемое",
"девичье",
"кличка, прозвище",
"зарегистрированная кличка (для животных)",
"кодированный псевдоним для анонимизации",
"племенное имя",
"религиозное",
"имя новорожденного до получения документов",
"более неиспользуемое, деднейм",
"временное",
"неправильное",
"неизвестное")
Тут видны разнообразные кейсы, с которыми медицина сталкивается.
XPN.8 Код представления имени (это для иероглифических языков: алфавитное, идеографическое, фонетическое)
XPN.9 Контекст использования имени (ссылка на пользовательский справочник; я не нашел примеров, говорят, это актуально для австралийских аборигенов, которые называют себя разными именами в разных больницах)
XPN.10 Период действия имени (с версии 2.5 не используется, заменен на XPN.12 и XPN.13)
XPN.11 Порядок сборки имени (ссылка на справочник со значениями типа "Prefix Family Middle Given Suffix")
XPN.12 Дата начала действия (да, это ещё и темпоральная таблица!)
XPN.13 Срок действия (последняя дата использования)
XPN.14 Профессиональный суффикс (просто строка, используется только для отображения)
XPN.15 Как обращаться (например, по всем документам человек Владимир, а предпочитает, чтобы его звали Дима. Или у священнослужителей — "отец Иоанн").
Я почему-то не вижу тут признака языка, он есть только в конкретном сообщении, хотя напрашивается несколько вариантов, но видимо как-то с этим справляются.
В общем, пока это самая замороченная система хранения личных имен, которая мне встречалась. Не уверен, что всё из этого я бы стал реализовывать в каждой системе, но вот с разными написаниями, девичьими фамилиями, множественными фамилиями и именами, деднеймами и сроком действия имен приходилось сталкиваться, каждый раз это какое-то мучение.
Если судить по текстам вакансий и публикаций, самая распространенная форма фиксации пользовательских требований сейчас — Jobs To Be Done (в западных компаниях). Другие варианты гораздо реже встречаются.
Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").
Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:
Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>
Работа — это какое-то действие, что-то, что должно быть сделано, и пользователь мог бы сам это как-то сделать, но он "нанимает" ваш продукт или функцию в нём, чтобы продукт это сделал за него. В этом смысле формулировка работы выше, чем описание интерфейсов системы, правило проверки: системы нет, а работа не теряет смысла. (Это же правило работает для проверки формулировок названий юскейсов, кстати.)
Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.
Это добавления формулируются так:
Что даст мне чувство <описание эмоционального состояния пользователя после успешно выполненной работы>
И другие увидят, что я <описание отношения значимых окружающих к пользователю после решения задачи>
Никогда не видел, чтобы эти части появлялись в технических спецификациях.
А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.
Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).
Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.
Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.
Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").
Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:
Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>
Работа — это какое-то действие, что-то, что должно быть сделано, и пользователь мог бы сам это как-то сделать, но он "нанимает" ваш продукт или функцию в нём, чтобы продукт это сделал за него. В этом смысле формулировка работы выше, чем описание интерфейсов системы, правило проверки: системы нет, а работа не теряет смысла. (Это же правило работает для проверки формулировок названий юскейсов, кстати.)
Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.
Это добавления формулируются так:
Что даст мне чувство <описание эмоционального состояния пользователя после успешно выполненной работы>
И другие увидят, что я <описание отношения значимых окружающих к пользователю после решения задачи>
Никогда не видел, чтобы эти части появлялись в технических спецификациях.
А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.
Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).
Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.
Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.
HTML Embed Code: