Разговор про когнитивные стратегии напомнил мне старую (1997 года!) культовую и немного эзотерическую книгу (или сборник статей) "Программистский камень" — Programmer's Stone. Книга как раз пытается ответить на вопрос — чем отличаются лучшие программисты в плане мышления.
В первой части авторы предполагают деление людей на "паковщиков" (packers) и "картостроителей" (mappers). Подавляющее большинство людей — "паковщики".
Особенности и стиль рассуждений паковщиков:
1. Запомнить множество инструкций и алгоритмов решения проблем.
2. При встрече с задачей — попробовать вспомнить из своего опыта или спросить у окружающих подходящий алгоритм для решения похожей задачи
3. Предложить решение, аналогичное предыдущему опыту.
4. Следовать алгоритму и убеждать других следовать алгоритму/процедуре.
5. Если люди не следуют процедуре — могут злиться на них и расстраиваться.
6. Ориентированы на процесс.
7. Запутанные задачи (high complexity) вызывают фрустрацию (не находится подходящий алгоритм).
8. Нравятся стандарты, традиции, ритуалы, регулярные, повторяемые действия — так спокойнее. Учатся по книгам и курсам.
9. Склонны к трудоголизму, переработкам.
10. Чаще бывают экстравертами, любят общаться.
Особенности и стиль рассуждений картостроителей:
1. Создать мысленную модель проблемы.
2. Исследовать связи между всеми объектами в проблемной области.
3. Определить требуемый результат и его измеримые показатели.
4. Упростить проблему до минимально разумного уровня (соотнося при этом частные решения с общей картиной и итоговым результатом).
5. Ориентированы на результат. Испытывают трудности с выполнением повторяемых процессов, часто даже бесятся от них. Учатся всему в основном сами, складывая из обрывков знаний общую картину.
6. Генерируют сразу множество идей. Креативны и любопытны. Легко отвлекаются. Могут по цепочке ассоциаций уйти далеко от начальной проблемы.
7. Склонны выявлять паттерны, особые случаи (объект, который чем-то отличается от других похожих), связи, обобщать, переходить на более абстрактный уровень.
8. Любят интеллектуальные вызовы, узнавать новое, придумывать необычные и новые способы выполнить работу, достижение целей неочевидным способом, "хаки".
9. С крайне высокой производительностью работают "в потоке", но не всегда могут войти в поток и удержаться в нём. Без потока производительность наоборот низкая.
10. Интроверты, любят быть в одиночестве, отлично себя чувствуют, когда ни с кем не общаются.
Как вам кажется, какой тип личности больше подходит для системного / бизнес-аналитика?
В этом сборнике статей, который сами авторы называют "проектом", ещё есть рассуждения о качестве и Total Quality Management (и его принципиальных отличий от Тейлоризма и выросшего на этой почве KPI и прочих инструментов контроля) , а в качестве одной из вдохновивших их книг они упоминают "Дзен и искусство уход за мотоциклом". Также там есть обоснования разницы в поведении разницей в выработке гормонов (дофамин vs серотонин, например), но тут я совсем не компетентен. На удивление, перевод "Программистского камня" на русский всё ещё доступен.
В первой части авторы предполагают деление людей на "паковщиков" (packers) и "картостроителей" (mappers). Подавляющее большинство людей — "паковщики".
Особенности и стиль рассуждений паковщиков:
1. Запомнить множество инструкций и алгоритмов решения проблем.
2. При встрече с задачей — попробовать вспомнить из своего опыта или спросить у окружающих подходящий алгоритм для решения похожей задачи
3. Предложить решение, аналогичное предыдущему опыту.
4. Следовать алгоритму и убеждать других следовать алгоритму/процедуре.
5. Если люди не следуют процедуре — могут злиться на них и расстраиваться.
6. Ориентированы на процесс.
7. Запутанные задачи (high complexity) вызывают фрустрацию (не находится подходящий алгоритм).
8. Нравятся стандарты, традиции, ритуалы, регулярные, повторяемые действия — так спокойнее. Учатся по книгам и курсам.
9. Склонны к трудоголизму, переработкам.
10. Чаще бывают экстравертами, любят общаться.
Особенности и стиль рассуждений картостроителей:
1. Создать мысленную модель проблемы.
2. Исследовать связи между всеми объектами в проблемной области.
3. Определить требуемый результат и его измеримые показатели.
4. Упростить проблему до минимально разумного уровня (соотнося при этом частные решения с общей картиной и итоговым результатом).
5. Ориентированы на результат. Испытывают трудности с выполнением повторяемых процессов, часто даже бесятся от них. Учатся всему в основном сами, складывая из обрывков знаний общую картину.
6. Генерируют сразу множество идей. Креативны и любопытны. Легко отвлекаются. Могут по цепочке ассоциаций уйти далеко от начальной проблемы.
7. Склонны выявлять паттерны, особые случаи (объект, который чем-то отличается от других похожих), связи, обобщать, переходить на более абстрактный уровень.
8. Любят интеллектуальные вызовы, узнавать новое, придумывать необычные и новые способы выполнить работу, достижение целей неочевидным способом, "хаки".
9. С крайне высокой производительностью работают "в потоке", но не всегда могут войти в поток и удержаться в нём. Без потока производительность наоборот низкая.
10. Интроверты, любят быть в одиночестве, отлично себя чувствуют, когда ни с кем не общаются.
Как вам кажется, какой тип личности больше подходит для системного / бизнес-аналитика?
В этом сборнике статей, который сами авторы называют "проектом", ещё есть рассуждения о качестве и Total Quality Management (и его принципиальных отличий от Тейлоризма и выросшего на этой почве KPI и прочих инструментов контроля) , а в качестве одной из вдохновивших их книг они упоминают "Дзен и искусство уход за мотоциклом". Также там есть обоснования разницы в поведении разницей в выработке гормонов (дофамин vs серотонин, например), но тут я совсем не компетентен. На удивление, перевод "Программистского камня" на русский всё ещё доступен.
👍18🔥1
Классификация людей на паковщиков и картостроителей в "Программистском камне" спекулятивна — по крайней мере, мне не удалось найти каких-либо научных статей, подтверждающих существование такого деления.
Есть одна популярная статья со ссылками на несколько исследований, в которой говорится о разном настрое на обучение: fixed mindset vs growth mindset: те, кто верят, что в основном способности врожденные, и что человеку дано, то не разовьешь; и те, кто убеждены, что способности можно развивать обучением. Соответственно, первые не очень-то стремятся научиться, а больше стараются получить оценку; вторые наоборот — больше заинтересованы в изучении нового — не ради оценок, а из интереса. Также отличается и реакция на трудности и ошибки: первые скорее всё бросят, вторые наоборот обрадуются сложностям (здесь тонкий момент, речь идёт интеллектуальные сложности, а не политические или социальные, например).
Спекулятивных классификаций много: это и MBTI/соционика, и управленческие стили Адизеса, и спиральная динамика. Из научно подтвержденных, со многими исследованиями: "большая пятерка", OCEAN — openness, conscientiousness, extraversion, agreeableness, neuroticism — открытость новому опыту, добросовестность, экстраверсия, доброжелательность, нейротизм.
В многочисленных исследованиях показано, что связи между факторами незначительны, а независимость дополнительных факторов под вопросом.
Внутри каждого фактора есть дополнительные фасеты (например, этот тест показывает их детализацию):
— Нейротизм: тревожность, злость, депрессия, застенчивость (не путать с интроверсией!), неумеренность, уязвимость.
— Экстраверсия: дружелюбность, общительность, напористость, активность, азарт и жизнерадостность.
— Открытость к опыту: воображение, артистические интересы, эмоциональность, авантюризм, интеллект, либерализм.
— Доброжелательность (договороспособность): доверие, мораль, альтруизм, кооперация, скромность, симпатия к окружающим.
— Добросовестность: эффективность, организованность, послушность, стремление к достижениям, самодисциплина, осторожность.
Фасеты в отдельных факторах могут быть противоположно направлены: например, хотя я, в целом, интроверт, у меня высокие показатели активности и азарта. И наоборот — в части добросовестности проседают послушность и самодисциплина.
Отсюда понятно, какие факторы могут быть полезны аналитикам: экстраверсия, чтобы лучше общаться и навязывать свои идеи; договороспособность, чтобы улаживать конфликты и интересы разных сторон; добросовестность, чтобы организовать свою работу; открытость опыту, чтобы придумывать лучшие решения; низкий невротизм, чтобы не мешал действовать. К сожалению, таких людей почти не бывает, либо они очень быстро становятся начальниками.
Собственно, начальники обычно либо организованные экстравертные доброжелательные экспериментаторы, либо деятельные экстравертные недоброжелательные невротики.
У нормальных людей обычно что-то западает: либо экстраверсия (думаем и анализируем отлично, с людьми поддерживаем хорошие отношения, работу свою можем организовать, но выделиться не можем), либо высокий нейротизм (в спокойной среде можем работать классно, но в реальной жизни всегда очень страшно, настолько, что парализует всю деятельность), либо добросовестность (не можем организоваться для выполнения работы, да и фиг с ней). Если проседает открытость и доброжелательность — скорее всего в принципе будет сложно с работать с людьми и со сложными системами.
NB! Я понимаю, что я сейчас залезаю в область, в которой не являюсь экспертом, так что воспринимайте этот пост с осторожностью, проконсультируйтесь со специалистами!
Есть одна популярная статья со ссылками на несколько исследований, в которой говорится о разном настрое на обучение: fixed mindset vs growth mindset: те, кто верят, что в основном способности врожденные, и что человеку дано, то не разовьешь; и те, кто убеждены, что способности можно развивать обучением. Соответственно, первые не очень-то стремятся научиться, а больше стараются получить оценку; вторые наоборот — больше заинтересованы в изучении нового — не ради оценок, а из интереса. Также отличается и реакция на трудности и ошибки: первые скорее всё бросят, вторые наоборот обрадуются сложностям (здесь тонкий момент, речь идёт интеллектуальные сложности, а не политические или социальные, например).
Спекулятивных классификаций много: это и MBTI/соционика, и управленческие стили Адизеса, и спиральная динамика. Из научно подтвержденных, со многими исследованиями: "большая пятерка", OCEAN — openness, conscientiousness, extraversion, agreeableness, neuroticism — открытость новому опыту, добросовестность, экстраверсия, доброжелательность, нейротизм.
В многочисленных исследованиях показано, что связи между факторами незначительны, а независимость дополнительных факторов под вопросом.
Внутри каждого фактора есть дополнительные фасеты (например, этот тест показывает их детализацию):
— Нейротизм: тревожность, злость, депрессия, застенчивость (не путать с интроверсией!), неумеренность, уязвимость.
— Экстраверсия: дружелюбность, общительность, напористость, активность, азарт и жизнерадостность.
— Открытость к опыту: воображение, артистические интересы, эмоциональность, авантюризм, интеллект, либерализм.
— Доброжелательность (договороспособность): доверие, мораль, альтруизм, кооперация, скромность, симпатия к окружающим.
— Добросовестность: эффективность, организованность, послушность, стремление к достижениям, самодисциплина, осторожность.
Фасеты в отдельных факторах могут быть противоположно направлены: например, хотя я, в целом, интроверт, у меня высокие показатели активности и азарта. И наоборот — в части добросовестности проседают послушность и самодисциплина.
Отсюда понятно, какие факторы могут быть полезны аналитикам: экстраверсия, чтобы лучше общаться и навязывать свои идеи; договороспособность, чтобы улаживать конфликты и интересы разных сторон; добросовестность, чтобы организовать свою работу; открытость опыту, чтобы придумывать лучшие решения; низкий невротизм, чтобы не мешал действовать. К сожалению, таких людей почти не бывает, либо они очень быстро становятся начальниками.
Собственно, начальники обычно либо организованные экстравертные доброжелательные экспериментаторы, либо деятельные экстравертные недоброжелательные невротики.
У нормальных людей обычно что-то западает: либо экстраверсия (думаем и анализируем отлично, с людьми поддерживаем хорошие отношения, работу свою можем организовать, но выделиться не можем), либо высокий нейротизм (в спокойной среде можем работать классно, но в реальной жизни всегда очень страшно, настолько, что парализует всю деятельность), либо добросовестность (не можем организоваться для выполнения работы, да и фиг с ней). Если проседает открытость и доброжелательность — скорее всего в принципе будет сложно с работать с людьми и со сложными системами.
NB! Я понимаю, что я сейчас залезаю в область, в которой не являюсь экспертом, так что воспринимайте этот пост с осторожностью, проконсультируйтесь со специалистами!
🔥11👍3
Говорят, в немецком языке есть словосочетание "Eierlegende Wollmilchsau", что-то вроде "Яйценоская шерстистая молочная свинья" — конкретно вот этот поросёночек, например, из рекламы Volkswagen.
В общем, я теперь знаю, кто является маскотом аналитиков, если верить описаниям типовых вакансий на эту роль 😹😹😹
В общем, я теперь знаю, кто является маскотом аналитиков, если верить описаниям типовых вакансий на эту роль 😹😹😹
😁49
Одна из простых и недооцененных техник при разработке интеграций — составление регламента взаимодействия систем.
В примерах, которые можно найти в Интернете, это обычно целый документ, раскрывающий все аспекты интеграции — вплоть до вопросов безопасности, протоколов, форматов запросов и ответов, и описания ошибок.
Но в первом приближении это может быть одна таблица с полями:
|Система-источник|Система-приёмник|Состав данных|Фильтр|Режим обмена|Цель|Комментарий
То есть, нам нужно указать:
1. Откуда куда какие данные попадают. Детализация тут может быть до названия ("Реквизиты карточки документа"), до перечисления полей ("Карточка документа: Идентификатор документа, Наименование документа, Автор документа, Дата создания, Дата последнего изменения, Номер версии") или даже до конкретного формата (JSON/XML, ссылка на схему).
2. Когда они попадают? По расписанию? По событию внутри системы? По запросу пользователя? ("Запрашиваются при выборе документов, измененных с момента последнего обращения к системе", "выгружается вручную сотрудником время от времени по собственной инициативе") — это в поле "Режим обмена". Тут же можно указать, за кем инициатива по старту передачи — "по запросу <наименование системы-приёмника>" / "по инициативе <наименование системы-источника>" (или, может, по инициативе внешнего оркестратора). Можно это вынести в отдельное поле — "стиль взаимодействия": синхронный запрос / асинхронный запрос / подписка.
3. Фильтр — что именно передаётся. Одна запись, соответствующая запросу (когда запрос по ID), со всеми полями, или только с изменившимися? Набор записей, отобранных по определенному условию? ("Документы с датой обновления, большей даты в запросе").
4. Цель — пожалуй, самое важное поле. Для чего интеграция? В рамках какого процесса? Тут можно указать также метрики и даже ROI.
5. В комментарий можно положить всё, что не вошло в другие поля, например — способ аутентификации или требования по обезличиванию, или технологию передачи (по шине, http-запросом, через файловое хранилище, по почте(!)). Если однотипных комментариев наберётся много — можно завести для них отдельную колонку.
Такую таблицу хорошо бы завести для всех интеграций в ИТ-ландшафте — чтобы не разбирать каждый раз, что куда передается и по какому расписанию. Очень помогает при разработке новых интеграций.
Самое интересное при исследовании — внести ручной перенос данных. Вот это прямо источник предложений по оптимизации работы!
Дальше эту простую таблицу можно наращивать и обогащать деталями: ссылками на форматы запросов и ответов, точными названиями адресов, эндпоинтов, топиков; ссылками на спецификации OpenAPI и AsyncAPI, и т.д. Получится описание актуальной архитектуры, и каждый следующий проект будет делать легче, а оформлять в том же формате, но как проект изменений.
Но начать можно с простой инвентаризации взаимодействий. Первый шаг научного подхода — классификация и учёт!
В примерах, которые можно найти в Интернете, это обычно целый документ, раскрывающий все аспекты интеграции — вплоть до вопросов безопасности, протоколов, форматов запросов и ответов, и описания ошибок.
Но в первом приближении это может быть одна таблица с полями:
|Система-источник|Система-приёмник|Состав данных|Фильтр|Режим обмена|Цель|Комментарий
То есть, нам нужно указать:
1. Откуда куда какие данные попадают. Детализация тут может быть до названия ("Реквизиты карточки документа"), до перечисления полей ("Карточка документа: Идентификатор документа, Наименование документа, Автор документа, Дата создания, Дата последнего изменения, Номер версии") или даже до конкретного формата (JSON/XML, ссылка на схему).
2. Когда они попадают? По расписанию? По событию внутри системы? По запросу пользователя? ("Запрашиваются при выборе документов, измененных с момента последнего обращения к системе", "выгружается вручную сотрудником время от времени по собственной инициативе") — это в поле "Режим обмена". Тут же можно указать, за кем инициатива по старту передачи — "по запросу <наименование системы-приёмника>" / "по инициативе <наименование системы-источника>" (или, может, по инициативе внешнего оркестратора). Можно это вынести в отдельное поле — "стиль взаимодействия": синхронный запрос / асинхронный запрос / подписка.
3. Фильтр — что именно передаётся. Одна запись, соответствующая запросу (когда запрос по ID), со всеми полями, или только с изменившимися? Набор записей, отобранных по определенному условию? ("Документы с датой обновления, большей даты в запросе").
4. Цель — пожалуй, самое важное поле. Для чего интеграция? В рамках какого процесса? Тут можно указать также метрики и даже ROI.
5. В комментарий можно положить всё, что не вошло в другие поля, например — способ аутентификации или требования по обезличиванию, или технологию передачи (по шине, http-запросом, через файловое хранилище, по почте(!)). Если однотипных комментариев наберётся много — можно завести для них отдельную колонку.
Такую таблицу хорошо бы завести для всех интеграций в ИТ-ландшафте — чтобы не разбирать каждый раз, что куда передается и по какому расписанию. Очень помогает при разработке новых интеграций.
Самое интересное при исследовании — внести ручной перенос данных. Вот это прямо источник предложений по оптимизации работы!
Дальше эту простую таблицу можно наращивать и обогащать деталями: ссылками на форматы запросов и ответов, точными названиями адресов, эндпоинтов, топиков; ссылками на спецификации OpenAPI и AsyncAPI, и т.д. Получится описание актуальной архитектуры, и каждый следующий проект будет делать легче, а оформлять в том же формате, но как проект изменений.
Но начать можно с простой инвентаризации взаимодействий. Первый шаг научного подхода — классификация и учёт!
👍29🔥12👎1
Профессия системного аналитика намного старше, чем у нас обычно принято считать (для меня это тоже стало открытием).
Вероятно, она даже появилась раньше, чем профессия программиста(!).
Системные аналитики выросли из подразделений, занимавшихся измерениями и оптимизацией производственных процессов. В каком-то смысле, их работа была похожа на современных BA — они занимались анализом бизнес-процессов, их оптимизацией и внедрением новых. Только в то время (1940-е) это называлось "процедуры".
Аналитики активно использовали различные технические средства: картотеки, журналы, табуляторы, автоматические машины для учёта всего подряд — в фильме "Новые времена" герой Чарли Чаплина пробивает карточку учета рабочего времени, когда идёт в туалет — а появились такие табели ещё в XIX веке. Кстати, одна из компаний, объединенная под маркой IBM, производила автоматы для учёта рабочего времени и измерения производственных операций.
Когда появились компьютеры, именно этим подразделениям поручили разобраться, как можно эффективно применить эти жужжащие и мигающие шкафы в реальном деле. Программисты были готовы написать всё, что угодно, но связать возможности компьютеров и потребности бизнеса могли не все.
В 1960 годы появился термин "MIS" — Management Information Systems, и привычные нам "data management" и "data processing". Отдали это в смешанные отделы, состоящие из разработчиков и аналитиков. Выявлением потребностей бизнеса и проектированием структур БД занялись системные аналитики.
В 1976 году состоялась конференция CPR:Computers and People Research, полностью посвященная профессии "системный аналитик". Доклады на ней один интересней другого:
"Изменение роли системного аналитика", "Перспективы системных аналитиков", "А кто-нибудь здесь системный аналитик?", "Нет такой вещи, как "системный аналитик", "Учебный курс по системному анализу на видеокассетах", "Улучшенные техники выявления общения с пользователями для выявления проблем", "Пробелы в обучении системных аналитиков", "Требования и навыки системных аналитиков" — жаль, что сборника докладов нет в оцифрованном виде, кажется, там масса интересного.
Судя по аннотациям, почти все сходятся в том, что роль аналитика определена нечетко, двусмысленно; непонятно, что этим словом называется; чем аналитик отличается от программиста; чего от таких специалистов хотят и как вообще их готовить. Хм. Кажется, с 1976 года поменялось не так уж много.
К 90-м годам изменения роли (теперь уже ролей!) аналитика продолжаются. Только по публикациям из Google Scholar:
1990: "Идентификация навыков, требуемых для изменяющейся роли системного аналитика"
1992: "Подход к прогнозированию будущих ролей для системного аналитика"
1996: "Изменение ролей системного аналитика"
1996: "Влияние организационных изменений на роль системного аналитика"
ну и дальше всё в таком же духе — роль всё изменяется и изменяется, в последнее время уже в связи с agile:
2020: "New role of systems analysts in Agile requirements engineering";
где-то с 2018 года упоминаний системных аналитиков становится уже мало.
Интересно, что в 90-х некоторый консенсус образуется вокруг идеи, что системный аналитик является агентом изменений в компании, эта идея встречается во многих публикациях. Впрочем, идея не новая: и изменения, и проблемы, с которыми сталкивается системный аналитик, не претерпели большого изменения с 60-х: "One of the greatest challenges to the systems analyst is the potential conflict between the business’s need for change and its employees’ resistance to change." — и это 1964 год!
"Reactions to the installation of MIS may range from failure to use the output to outright sabotage." - а это 1970.
Будь агентом изменений! Преодолевай сопротивление человеков!
"Operating management, the group that should enjoy most of the system benefits, goes farther than any other group in its resistance, and exhibits all three forms: aggression, projection, and avoidance" — а ничего не изменилось, однако.
Вероятно, она даже появилась раньше, чем профессия программиста(!).
Системные аналитики выросли из подразделений, занимавшихся измерениями и оптимизацией производственных процессов. В каком-то смысле, их работа была похожа на современных BA — они занимались анализом бизнес-процессов, их оптимизацией и внедрением новых. Только в то время (1940-е) это называлось "процедуры".
Аналитики активно использовали различные технические средства: картотеки, журналы, табуляторы, автоматические машины для учёта всего подряд — в фильме "Новые времена" герой Чарли Чаплина пробивает карточку учета рабочего времени, когда идёт в туалет — а появились такие табели ещё в XIX веке. Кстати, одна из компаний, объединенная под маркой IBM, производила автоматы для учёта рабочего времени и измерения производственных операций.
Когда появились компьютеры, именно этим подразделениям поручили разобраться, как можно эффективно применить эти жужжащие и мигающие шкафы в реальном деле. Программисты были готовы написать всё, что угодно, но связать возможности компьютеров и потребности бизнеса могли не все.
В 1960 годы появился термин "MIS" — Management Information Systems, и привычные нам "data management" и "data processing". Отдали это в смешанные отделы, состоящие из разработчиков и аналитиков. Выявлением потребностей бизнеса и проектированием структур БД занялись системные аналитики.
В 1976 году состоялась конференция CPR:Computers and People Research, полностью посвященная профессии "системный аналитик". Доклады на ней один интересней другого:
"Изменение роли системного аналитика", "Перспективы системных аналитиков", "А кто-нибудь здесь системный аналитик?", "Нет такой вещи, как "системный аналитик", "Учебный курс по системному анализу на видеокассетах", "Улучшенные техники выявления общения с пользователями для выявления проблем", "Пробелы в обучении системных аналитиков", "Требования и навыки системных аналитиков" — жаль, что сборника докладов нет в оцифрованном виде, кажется, там масса интересного.
Судя по аннотациям, почти все сходятся в том, что роль аналитика определена нечетко, двусмысленно; непонятно, что этим словом называется; чем аналитик отличается от программиста; чего от таких специалистов хотят и как вообще их готовить. Хм. Кажется, с 1976 года поменялось не так уж много.
К 90-м годам изменения роли (теперь уже ролей!) аналитика продолжаются. Только по публикациям из Google Scholar:
1990: "Идентификация навыков, требуемых для изменяющейся роли системного аналитика"
1992: "Подход к прогнозированию будущих ролей для системного аналитика"
1996: "Изменение ролей системного аналитика"
1996: "Влияние организационных изменений на роль системного аналитика"
ну и дальше всё в таком же духе — роль всё изменяется и изменяется, в последнее время уже в связи с agile:
2020: "New role of systems analysts in Agile requirements engineering";
где-то с 2018 года упоминаний системных аналитиков становится уже мало.
Интересно, что в 90-х некоторый консенсус образуется вокруг идеи, что системный аналитик является агентом изменений в компании, эта идея встречается во многих публикациях. Впрочем, идея не новая: и изменения, и проблемы, с которыми сталкивается системный аналитик, не претерпели большого изменения с 60-х: "One of the greatest challenges to the systems analyst is the potential conflict between the business’s need for change and its employees’ resistance to change." — и это 1964 год!
"Reactions to the installation of MIS may range from failure to use the output to outright sabotage." - а это 1970.
Будь агентом изменений! Преодолевай сопротивление человеков!
"Operating management, the group that should enjoy most of the system benefits, goes farther than any other group in its resistance, and exhibits all three forms: aggression, projection, and avoidance" — а ничего не изменилось, однако.
🔥29👍9🤓2🦄2
Судя по всему, опасаться нам не стоит: как бы не называлась задача оптимизации рабочих процессов и подбора для этого доступных технологий, актуальность её не пропадёт. Не удивлюсь, если в каком-нибудь Древнем Египте или Вавилоне были специалисты по внедрению глиняных досок или учёта на папирусах (в широком смысле, письменность как раз и придумали для учёта и оптимизации работ, так что можно приписать эту заслугу системным аналитикам).
Первая интерактивная база данных с контролем целостности и поддержкой транзакций — это, как известно, двойная запись в бухгалтерии, а Лука Пачоли был одним из первых системных аналитиков. Правда, в XV веке такой профессии ещё не было, и его называли просто математиком.
Первая интерактивная база данных с контролем целостности и поддержкой транзакций — это, как известно, двойная запись в бухгалтерии, а Лука Пачоли был одним из первых системных аналитиков. Правда, в XV веке такой профессии ещё не было, и его называли просто математиком.
🔥28😁7👍2👏2💯1
А вот реклама, за которую точно не стыдно: курс Ветчинкина я проходил сам, и считаю на данный момент лучшим по теме микросервисной архитектуры.
Для аналитиков, проектирующих решения, интеграции или описывающих сервисы, отличный уровень погружения: не слишком технический и не слишком общий. На курсе очень много практики, и, что важно — на каждое задание даётся образец решения от автора, что не всегда встретишь.
И ещё мне очень понравился переход и увязка разных уровней рассмотрения: от высокоуровневых решений и нефункциональных требований, до организации команд вокруг сервисов и быстрых примеров, как какая-то концепция может в коде выглядеть.
В общем, от всей души рекомендую!
Для аналитиков, проектирующих решения, интеграции или описывающих сервисы, отличный уровень погружения: не слишком технический и не слишком общий. На курсе очень много практики, и, что важно — на каждое задание даётся образец решения от автора, что не всегда встретишь.
И ещё мне очень понравился переход и увязка разных уровней рассмотрения: от высокоуровневых решений и нефункциональных требований, до организации команд вокруг сервисов и быстрых примеров, как какая-то концепция может в коде выглядеть.
В общем, от всей души рекомендую!
🔥13👍4💩1
Пока искал материалы к посту по историю системных аналитиков, натолкнулся на упоминание "легендарного" Лесли Маттиса (Leslie H. Matthies), "названного "Systems Man of the Year" в 1959 году Национальной Ассоциацией Системного Менеджмента".
Ни следов этой ассоциации, ни упоминаний Леса Маттиса нигде найти не удается, кроме его книг и некролога 2000 года на сайте города Талса в Оклахоме.
Между тем, по-видимому, он первым предложил формат текстового описания деятельности, напоминающий Use Case. И сделал это как раз где-то в середине 50-х. Кто-то даже утверждает, что именно этим форматом вдохновились создатели COBOL (прадедушки всех современных высокоуровневых языков программирования), но достоверно установить это теперь трудно.
Формат этот назывался "Сценарий процедуры" — 'Playnoscript procedure'. Слова "процесс" тогда ещё в языке менеджмента не было, а слов "use case" и подавно. Сценарий же произошел вот откуда: Маттис по образованию был журналистом, а после университета пробовал себя в написании сценариев к пьесам, пока его не наняли во время Второй мировой на авиационный завод кем-то вроде технического писателя — составлять и оптимизировать инструкции к технологическим операциям.
Сценарии выглядели именно как сценарии пьесы: тема и действия акторов.
Каждое действие было пронумеровано, и начиналось с глагола, за которым следует существительное — объект работы; структура: "актор что-то делает с чем-то".
Наиболее часто используемые глаголы ("14 рабочих лошадок сценария"): sends, shows, issues, obtains, records, provides, prepares, uses, checks, places, decides, receives, forwards, requests.
Там же содержится словарь по переводу с бюрократического языка ("Procedur-e-z-e") на обычный:
compilation -> list
classification -> like stuff together
design -> figure out
establish -> set up
increments -> pieces
justification -> reason for
processed -> work on it
procurement -> gets
requirements -> what is needed
sufficient -> enough
и т.д.
Как не хватает такого словаря при составлении требований и юскейсов сейчас!
Ни следов этой ассоциации, ни упоминаний Леса Маттиса нигде найти не удается, кроме его книг и некролога 2000 года на сайте города Талса в Оклахоме.
Между тем, по-видимому, он первым предложил формат текстового описания деятельности, напоминающий Use Case. И сделал это как раз где-то в середине 50-х. Кто-то даже утверждает, что именно этим форматом вдохновились создатели COBOL (прадедушки всех современных высокоуровневых языков программирования), но достоверно установить это теперь трудно.
Формат этот назывался "Сценарий процедуры" — 'Playnoscript procedure'. Слова "процесс" тогда ещё в языке менеджмента не было, а слов "use case" и подавно. Сценарий же произошел вот откуда: Маттис по образованию был журналистом, а после университета пробовал себя в написании сценариев к пьесам, пока его не наняли во время Второй мировой на авиационный завод кем-то вроде технического писателя — составлять и оптимизировать инструкции к технологическим операциям.
Сценарии выглядели именно как сценарии пьесы: тема и действия акторов.
Каждое действие было пронумеровано, и начиналось с глагола, за которым следует существительное — объект работы; структура: "актор что-то делает с чем-то".
Наиболее часто используемые глаголы ("14 рабочих лошадок сценария"): sends, shows, issues, obtains, records, provides, prepares, uses, checks, places, decides, receives, forwards, requests.
Там же содержится словарь по переводу с бюрократического языка ("Procedur-e-z-e") на обычный:
compilation -> list
classification -> like stuff together
design -> figure out
establish -> set up
increments -> pieces
justification -> reason for
processed -> work on it
procurement -> gets
requirements -> what is needed
sufficient -> enough
и т.д.
Как не хватает такого словаря при составлении требований и юскейсов сейчас!
❤33🔥7👍2👏1
Это из книги The Playnoscript Procedure, 1961 год.
А ещё в книге есть оценки зрелости процедур, обзор типовых ошибок и процедуры вокруг процедур (нумерация, индексирование, версионирование, контроль актуальности, пересмотр, изъятие устаревших).
В общем, всё, о чём мы говорим в связи с требованиями, вариантами использования или бизнес-процессами, известно (и забыто) ещё с 50-х годов.
Слов 'systems analyst' там нет, людей в этой роли называют 'Systems Men', "системщики".
Книгу можно взять почитать(!) на часок вот тут: https://archive.org/details/playnoscriptproced0000leli
А ещё в книге есть оценки зрелости процедур, обзор типовых ошибок и процедуры вокруг процедур (нумерация, индексирование, версионирование, контроль актуальности, пересмотр, изъятие устаревших).
В общем, всё, о чём мы говорим в связи с требованиями, вариантами использования или бизнес-процессами, известно (и забыто) ещё с 50-х годов.
Слов 'systems analyst' там нет, людей в этой роли называют 'Systems Men', "системщики".
Книгу можно взять почитать(!) на часок вот тут: https://archive.org/details/playnoscriptproced0000leli
Internet Archive
the playnoscript procedure: a new tool fo administration : lelie h. matthies : Free Download, Borrow, and Streaming : Internet Archive
❤26🔥4👍3
Чему аналитики могут научиться у сценаристов и режиссеров.
В комментарии к посту про Playnoscript Алина Миронова пишет, как ей помогает в системном анализе образование и паттерны мышления сценариста игрового кино:
1. Переход между крупным планом и общим, навык мысленного приближения и отдаления.
2. С одной стороны, не должно быть ничего лишнего, с другой — нужно подвесить чеховское ружье, которое сработает потом.
3. Описание только действий и реакций (пользователь не может догадаться о внутреннем состоянии системы, он может только увидеть что-то).
4. Думать о том, кто это будет читать.
5. Навык придумывания концовок и альтернатив.
Я бы к этому добавил несколько идей, которые я почерпнул, в основном, в канале знакомого сценариста. Они применимы к системному анализу, а точнее — к форме представления результатов, т.к. это тоже литература — не художественная, техническая, - но есть и общие литературные приёмы, обусловленные хотя бы способом восприятия текста - протяженном во времени. Текст не загружается в голову целиком, текст воспринимается читателем в течение времени, и этим восприятием можно (и нужно!) управлять. И вот какие тут есть аспекты:
👀 Чьими глазами мы смотрим в данный момент? Вот этот текст, он с чьей точки зрения написан? С точки зрения пользователя? Или с точки зрения программиста системы? Или с точки зрения DevSecOps инженера? Нельзя в одном описании перескакивать с одной точки зрения на другую. Вообще, у нас про точки зрения целый стандарт есть: ISO 42010 или ГОСТ Р 57100 "Systems and software engineering. Architecture denoscription".
🥸 Кто в какой момент что знает? У сценария это называется "драматическая структура", у проектного документа — просто структура. Есть три лица: автор, пользователь системы и читатель документа. Информация между ними распределена неравномерно: автор знает о системе и её сценариях почти всё, пользователь — только то, что может понять из взаимодействия с системой, читатель — то, что успел узнать из текста. Соотношение этих знаний определяет структуру истории, но и для технических документов было бы неплохо помнить — что мы уже рассказали читателю, а что ещё нет; что уже знает пользователь на каком-то экране, а что от него скрыто.
🏁 Когда заканчивается сцена? Это в проектировании применимо для пользовательских сценариев и бизнес-процессов. Ответ сценариста: сцена заканчивается, когда один из участников достигает своей мини-цели. У каждого участника сценария есть своя мини-цель, если участников много - из этих целей рождается мини-конфликт. Как только цель достигнута, персонажу больше нечего в ней делать — сцена закончилась. Это первый уровень. Второй — сцена заканчивается, когда в ней произошло то, что нужно вам, как проектировщику системы. А вам, как правило, нужно либо подготовить материал для дальнейшего развития сюжета, либо чтобы пользователь что-то понял и, например, приобрел мотив к дальнейшим действиям.
⚔️ Про конфликты и связи между участниками. В составе ролей пользователей (исполнителей процессов, стейкхолдеров — особенно стейкхолдеров!) не должно быть лишних людей. Все должны быть связаны друг с другом через конфликт или через поддержку/заботу. При этом, если мы смотрим с точки зрения главного героя — у него есть те, кто "выше"-главнее, кто его контролирует, кому он отчитывается, и те, кто "ниже": о ком он заботится, кому ставит задачи и т.п. Все должны быть свзязаны со всеми. Помним, что система только лишь отражает взаимодействия между людьми, системы нет — а конфликты и отношения всё равно есть. Хорошо бы их зафиксировать в явном виде, осознанно. (Ещё есть версия, что основные линии конфликта должны составлять треугольник — это верно для драматургии, уж не знаю, насколько это применимо к системному анализу).
♾ Проектирование от конца к началу. Сначала сформулируйте желаемый результат операции. Её финал. К чему мы должны прийти в итоге? Сформулируйте это состояние. Потом начинайте распутывать по шагам от конца к началу — а что было было перед этим? А за шаг до этого? Кто что должен был сделать? Когда понятная цель, проще становится привести к ней всех участников.
В комментарии к посту про Playnoscript Алина Миронова пишет, как ей помогает в системном анализе образование и паттерны мышления сценариста игрового кино:
1. Переход между крупным планом и общим, навык мысленного приближения и отдаления.
2. С одной стороны, не должно быть ничего лишнего, с другой — нужно подвесить чеховское ружье, которое сработает потом.
3. Описание только действий и реакций (пользователь не может догадаться о внутреннем состоянии системы, он может только увидеть что-то).
4. Думать о том, кто это будет читать.
5. Навык придумывания концовок и альтернатив.
Я бы к этому добавил несколько идей, которые я почерпнул, в основном, в канале знакомого сценариста. Они применимы к системному анализу, а точнее — к форме представления результатов, т.к. это тоже литература — не художественная, техническая, - но есть и общие литературные приёмы, обусловленные хотя бы способом восприятия текста - протяженном во времени. Текст не загружается в голову целиком, текст воспринимается читателем в течение времени, и этим восприятием можно (и нужно!) управлять. И вот какие тут есть аспекты:
🏁 Когда заканчивается сцена? Это в проектировании применимо для пользовательских сценариев и бизнес-процессов. Ответ сценариста: сцена заканчивается, когда один из участников достигает своей мини-цели. У каждого участника сценария есть своя мини-цель, если участников много - из этих целей рождается мини-конфликт. Как только цель достигнута, персонажу больше нечего в ней делать — сцена закончилась. Это первый уровень. Второй — сцена заканчивается, когда в ней произошло то, что нужно вам, как проектировщику системы. А вам, как правило, нужно либо подготовить материал для дальнейшего развития сюжета, либо чтобы пользователь что-то понял и, например, приобрел мотив к дальнейшим действиям.
⚔️ Про конфликты и связи между участниками. В составе ролей пользователей (исполнителей процессов, стейкхолдеров — особенно стейкхолдеров!) не должно быть лишних людей. Все должны быть связаны друг с другом через конфликт или через поддержку/заботу. При этом, если мы смотрим с точки зрения главного героя — у него есть те, кто "выше"-главнее, кто его контролирует, кому он отчитывается, и те, кто "ниже": о ком он заботится, кому ставит задачи и т.п. Все должны быть свзязаны со всеми. Помним, что система только лишь отражает взаимодействия между людьми, системы нет — а конфликты и отношения всё равно есть. Хорошо бы их зафиксировать в явном виде, осознанно. (Ещё есть версия, что основные линии конфликта должны составлять треугольник — это верно для драматургии, уж не знаю, насколько это применимо к системному анализу).
♾ Проектирование от конца к началу. Сначала сформулируйте желаемый результат операции. Её финал. К чему мы должны прийти в итоге? Сформулируйте это состояние. Потом начинайте распутывать по шагам от конца к началу — а что было было перед этим? А за шаг до этого? Кто что должен был сделать? Когда понятная цель, проще становится привести к ней всех участников.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍5❤1
📝 Экспозиция сеттинга, или установка "правил игры". Тут могут быть разные подходы, но в любом случае, так или иначе, мы должны ввести читателя в курс дела. Мы можем это делать сразу одним куском, или разбивая на части и помещая введение и объяснение перед очередными несколькими элементами, в которых используется это очередное правило. И наоборот — когда мы описываем какой-то процесс, мы до этого должны представить читателю сеттинг, в рамках которого это происходит. Это у нас кто? Это они делают зачем? Используя что? По каким правилам?
📈 Темпо-ритм документа. Если мы подразумеваем, что хоть кто-нибудь хоть когда-нибудь будет линейно читать наш документ, стоит задуматься про его темп и ритм (скорость и внутренние циклы). В техническом тексте это регулируется длиной и подробностью блоков, переходов с одной темы на другую. Темпо-ритм придумал Станиславский ("нарастание или спад, ускорение или замедление, плавное течение или бурное развитие сценического действия"). В первом приближении это означает, что вообще что-то должно меняться. Если весь текст состоит из однообразных блоков — получается сплошное однотонное бу-бу-бу, читатель от этого быстро устаёт и перестаёт различать их. Нужно как-то чередовать. Тут можно вспомнить принципы визуального монтажа "по крупности": нельзя монтировать встык планы одной или смежной крупности (кроме сочетания "крупный план-деталь"), нужно монтировать через план.
Можно попробовать применить это и к тексту: сначала даём общий план, потом приближаемся, углубляемся в детали, отдаляемся, уходим опять к общему — и снова, так создаётся определенный ритм.
А какие ещё идеи можно применить к технической документации из области литературного творчества?
Можно попробовать применить это и к тексту: сначала даём общий план, потом приближаемся, углубляемся в детали, отдаляемся, уходим опять к общему — и снова, так создаётся определенный ритм.
А какие ещё идеи можно применить к технической документации из области литературного творчества?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍3
Регулярные выражения, RegEx или RegExp.
Написал для участников тренинга, вдруг вам тоже пригодится.
Интересно, что у аналитиков регулярно встречается запрос на SQL (и на собеседованиях дают задачки на него), а вот про регулярные выражения почему-то не вспоминают. То ли они аналитикам не нужны, то ли считается, что это знание "по умолчанию", ну что про них говорить :) Между тем, я вижу на курсах, что многие аналитики вообще про них не знают, а они начинают всплывать при интеграциях: при валидации параметров входящих сообщений (pattern в схеме данных в OpenAPI), при мэппинге данных, при указании имен файлов в файловом обмене.
Это специальный язык, через который можно задать условия для текста. То есть, найти в тексте такую подстроку, которая удовлетворяет этим условиям.
Для чего может использоваться:
🔹 проверка формата текстового значения (валидация — например, в json schema или xsd, причём валидировать можно как значения, так и названия полей);
🔹 поиск (например, в текстовом файле, CSV, таблице Excel или в БД);
🔹 извлечение подстроки из текста;
🔹 подсчет числа вхождений, соответствующих маске;
🔹 замена подстроки, подходящей под маску;
🔹 очистка данных (удаление кавычек, двойных пробелов, скобок и т.п., извлечение значений: ФИО, дат, телефонов, URL, email)
Регэкспы распространены повсеместно: от утилиты командной строки grep, выполняющей поиск в файлах и постоянно использующейся программистами и админами (отсюда глагол "грепать", "грепнуть" — получить подмножество соответствующих строк из исходного файла), до библиотек во всех языках программирования, функций в SQL, инструментов поиска в текстовых редакторах и интернет-поисковиках.
Синтаксис регулярных выражений стандартизован как часть стандарта POSIX. На практике чаще применяется более мощный PCRE, родом из языка Perl, так что в каждой конкретной системе синтаксис выражений может немного отличаться.
Движки выполнения хорошо оптимизированы и работают быстро; под регулярными выражениями лежит хорошая математика, и в среднем их вычислительная сложность линейна — O(n) — но можно написать такое выражение, которое надолго завесит ваш поиск :)
Язык задания паттернов в своей основе прост:
— просто набор символов -> полное совпадение с учетом регистра (по умолчанию. можно отключить учёт регистра)
— . -> любой символ
— вертикальная палка | -> одно или другое: елка|ёлка
— скобки -> область действия и последовательность операторов, как в математике: (е|ё)лка, Ната(л(ь|и)я|ша)
— квадратные скобки -> любой из указанных символов: [её]лка, Натал[ьи]я, [0-9] - цифры, [A-Z] - буквы латиницы в верхнем регистре
- [^] -> отрицание, символ, не входящий в набор: [^аеёиоуэюя] означает "любой символ, кроме гласных букв".
Квантификаторы:
? -> ноль или один предыдущий символ: RegExp? найдет и RegEx, и RegExp
* -> ноль или несколько предыдущих символов
+ -> один или несколько предыдущих символов
{n} -> повтор предыдущего символа n раз. {n,m} - повтор от n до m раз
^ и $ -> начало и конец строки. \w — слово, \b — граница слова (но только для английского языка!).
Пример: ^(?:\d{3}-){2}\d{4}$ - строка, содержащая телефонный номер. Или так: ^[0-9]{3}-[0-9]{3}-[0-9]{4}$.
Дальше начинается сплошной драконий покер: можно искать слово X, за которым не следует слово Y; строки, в которых упоминается Z, но не упоминается W, и так далее. Инструмент невероятно мощный, можно с ним удивительные вещи делать. Правда, разобраться в уже готовых регэкспах бывает сложно, их обзывают write only, а выглядят они, как шифр на клингонском.
Почитать вводную статью на русском: https://techrocks.ru/2022/05/31/regex-complete-guide/
Пройти подробнейший tutorial на английском: https://www.regular-expressions.info/tutorial.html
Попробовать составить и поотлаживать регулярные выражения: https://regex101.com/
Вот тут примеры пожестче: https://habr.com/ru/articles/349860/
Кстати, ChatGPT умеет по текстовому описанию умеет строить регулярные выражения (но рекомендую проверять, как обычно — он может и ошибок насажать).
Написал для участников тренинга, вдруг вам тоже пригодится.
Интересно, что у аналитиков регулярно встречается запрос на SQL (и на собеседованиях дают задачки на него), а вот про регулярные выражения почему-то не вспоминают. То ли они аналитикам не нужны, то ли считается, что это знание "по умолчанию", ну что про них говорить :) Между тем, я вижу на курсах, что многие аналитики вообще про них не знают, а они начинают всплывать при интеграциях: при валидации параметров входящих сообщений (pattern в схеме данных в OpenAPI), при мэппинге данных, при указании имен файлов в файловом обмене.
Это специальный язык, через который можно задать условия для текста. То есть, найти в тексте такую подстроку, которая удовлетворяет этим условиям.
Для чего может использоваться:
🔹 проверка формата текстового значения (валидация — например, в json schema или xsd, причём валидировать можно как значения, так и названия полей);
🔹 поиск (например, в текстовом файле, CSV, таблице Excel или в БД);
🔹 извлечение подстроки из текста;
🔹 подсчет числа вхождений, соответствующих маске;
🔹 замена подстроки, подходящей под маску;
🔹 очистка данных (удаление кавычек, двойных пробелов, скобок и т.п., извлечение значений: ФИО, дат, телефонов, URL, email)
Регэкспы распространены повсеместно: от утилиты командной строки grep, выполняющей поиск в файлах и постоянно использующейся программистами и админами (отсюда глагол "грепать", "грепнуть" — получить подмножество соответствующих строк из исходного файла), до библиотек во всех языках программирования, функций в SQL, инструментов поиска в текстовых редакторах и интернет-поисковиках.
Синтаксис регулярных выражений стандартизован как часть стандарта POSIX. На практике чаще применяется более мощный PCRE, родом из языка Perl, так что в каждой конкретной системе синтаксис выражений может немного отличаться.
Движки выполнения хорошо оптимизированы и работают быстро; под регулярными выражениями лежит хорошая математика, и в среднем их вычислительная сложность линейна — O(n) — но можно написать такое выражение, которое надолго завесит ваш поиск :)
Язык задания паттернов в своей основе прост:
— просто набор символов -> полное совпадение с учетом регистра (по умолчанию. можно отключить учёт регистра)
— . -> любой символ
— вертикальная палка | -> одно или другое: елка|ёлка
— скобки -> область действия и последовательность операторов, как в математике: (е|ё)лка, Ната(л(ь|и)я|ша)
— квадратные скобки -> любой из указанных символов: [её]лка, Натал[ьи]я, [0-9] - цифры, [A-Z] - буквы латиницы в верхнем регистре
- [^] -> отрицание, символ, не входящий в набор: [^аеёиоуэюя] означает "любой символ, кроме гласных букв".
Квантификаторы:
? -> ноль или один предыдущий символ: RegExp? найдет и RegEx, и RegExp
* -> ноль или несколько предыдущих символов
+ -> один или несколько предыдущих символов
{n} -> повтор предыдущего символа n раз. {n,m} - повтор от n до m раз
^ и $ -> начало и конец строки. \w — слово, \b — граница слова (но только для английского языка!).
Пример: ^(?:\d{3}-){2}\d{4}$ - строка, содержащая телефонный номер. Или так: ^[0-9]{3}-[0-9]{3}-[0-9]{4}$.
Дальше начинается сплошной драконий покер: можно искать слово X, за которым не следует слово Y; строки, в которых упоминается Z, но не упоминается W, и так далее. Инструмент невероятно мощный, можно с ним удивительные вещи делать. Правда, разобраться в уже готовых регэкспах бывает сложно, их обзывают write only, а выглядят они, как шифр на клингонском.
Почитать вводную статью на русском: https://techrocks.ru/2022/05/31/regex-complete-guide/
Пройти подробнейший tutorial на английском: https://www.regular-expressions.info/tutorial.html
Попробовать составить и поотлаживать регулярные выражения: https://regex101.com/
Вот тут примеры пожестче: https://habr.com/ru/articles/349860/
Кстати, ChatGPT умеет по текстовому описанию умеет строить регулярные выражения (но рекомендую проверять, как обычно — он может и ошибок насажать).
👍25🔥7❤1
Взялся писать пост про различные свойства систем (нефункциональные требования, фитнесс-функция и всякое такое), но столкнулся с известной проблемой великого и могучего...
С защищенностью, надежностью и точностью у нас всё просто, без нюансов — мы за всю историю эти штуки редко видели, много разных слов не успели придумать.
(Пост пишу, завтра закину).
UPD: вы не переживайте, в русском языке зато есть много слов про эмоции и отношения, эквивалентов которым нет в других языках.
С защищенностью, надежностью и точностью у нас всё просто, без нюансов — мы за всю историю эти штуки редко видели, много разных слов не успели придумать.
(Пост пишу, завтра закину).
UPD: вы не переживайте, в русском языке зато есть много слов про эмоции и отношения, эквивалентов которым нет в других языках.
😁24👎5❤2
Есть много акронимов и отдельных свойств архитектуры:
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)
🔥18👍6👌1
3. Как мы систему эксплуатируем. В штатном и нештатном режиме, как входим и выходим из нештатного режима; как обеспечиваем альтернативные способы функционирования при отказе частей (business continuity plan); какие есть средства диагностики и поиска неисправностей (например, можно ли проверить отдельно работу какой-то подсистемы или функции на проде?), какие есть методы устранения сбоев? А средства прогнозирования сбоев?
4. И вот чего никогда не видел - средства вывода системы из эксплуатации.
Про фитнесс-функцию сегодня не влезло, и так телеграм на два поста побил :(
Ставьте какую-нибудь положительную реакцию, если тема интересна, и стоит продолжать.
А вы сами в какой мере сталкиваетесь с проработкой показателей качества?
4. И вот чего никогда не видел - средства вывода системы из эксплуатации.
Про фитнесс-функцию сегодня не влезло, и так телеграм на два поста побил :(
Ставьте какую-нибудь положительную реакцию, если тема интересна, и стоит продолжать.
А вы сами в какой мере сталкиваетесь с проработкой показателей качества?
🔥35👍13👌1
Продолжаем тему нефункциональных требований и атрибутов качества.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
➕ доступность (aviability): готовность предоставлять работающий сервис (вероятность, что система будет работать, когда мы к ней обратимся);
➕ надежность (reliability): неизменность параметров сервиса во времени;
➕ безопасность (safety): из-за сбоя не будет катастрофических последствий для пользователей и окружения;
➕ целостность (integrity): система не развалится при сбое и данные не будут искажены;
➕ ремонтопригодность (maintainability): систему можно будет починить после сбоя: обнаружить дефект, перезапустить, восстановить данные.
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты➡️ угрозы ➡️ меры.
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект➡️ ошибка ➡️ отказ, который, в свою очередь, приводит к ошибке в смежной системе и т.д.
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍2
Соответственно, мы можем принять меры в отношении всех этих угроз.
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?
👍15
https://youtu.be/sjNKAd5l88M?si=vOtZ0sT_mSC8mgSv&t=2m27s
Прекрасное у Жванецкого про ИТ-системы в управлении, ну и вообще про управление на основе данных. (с 2:27)
В принципе, с 1985 года ничего и не поменялось!
Пока данные введут — подправят, после обработки — сдвигают...
Поэтому, кстати, многие системные аналитики не копают в сторону бизнес-смысла, а то ведь можно и докопаться.
Прекрасное у Жванецкого про ИТ-системы в управлении, ну и вообще про управление на основе данных. (с 2:27)
В принципе, с 1985 года ничего и не поменялось!
Пока данные введут — подправят, после обработки — сдвигают...
Поэтому, кстати, многие системные аналитики не копают в сторону бизнес-смысла, а то ведь можно и докопаться.
YouTube
Михаил Жванецкий - фельетон "Непереводимая игра слов" (1985)
Фельетон "Непереводимая игра слов". Исполняет автор - писатель-сатирик Михаил Жванецкий.
Фрагмент концертной программы "Новогоднее представление. "Голубой огонек".
Главная редакция музыкальных программ, 1985 г.
#гостелерадиофонд #НовогодняяКарусель…
Фрагмент концертной программы "Новогоднее представление. "Голубой огонек".
Главная редакция музыкальных программ, 1985 г.
#гостелерадиофонд #НовогодняяКарусель…
😁7
Слышали ли вы об инициативе SEMAT и стандарте OMG Essence?
Была такая великая инициатива Ивара Якобсона (который придумал UML, use cases и RUP), многие известные люди подписались: мол, в методиках разработки творится какая-то ересь непонятная, каждый изобретает свою методологию, а как их сравнить и как выбрать подходящую — непонятно.
В общем, придумали структуру для описания процесса (а заодно и проверки — как идут дела), провели как стандарт у своих друзей OMG (которые стандартизируют UML и BPMN), разрекламировали — Якобсон с коллегами даже в Россию несколько раз приезжал, выступал на SECR.
Идея была такая: разработаем структуру описания, а потом будем описывать существующие практики в этой структуре — "эссенциализировать" практики. На текущий момент описан SCRUM, базовые идеи Agile, Agile at scale, OpenUP, и, говорят, внутри в консалтинговой компании Якобсона есть описания процессов Spotify, SAFe и т.д. В принципе, в основном он эту тему и двигает, неясно — есть ли кто там ещё.
На удивление, есть ГОСТ Р 57195-2016, соответствующий OMG Essence. Вот только описания практик на русском нет.
Как думаете, интересная это тема — иметь библиотеку практик сразу в стандартном виде, готовую для внедрения, с чек-листами?
Была такая великая инициатива Ивара Якобсона (который придумал UML, use cases и RUP), многие известные люди подписались: мол, в методиках разработки творится какая-то ересь непонятная, каждый изобретает свою методологию, а как их сравнить и как выбрать подходящую — непонятно.
В общем, придумали структуру для описания процесса (а заодно и проверки — как идут дела), провели как стандарт у своих друзей OMG (которые стандартизируют UML и BPMN), разрекламировали — Якобсон с коллегами даже в Россию несколько раз приезжал, выступал на SECR.
Идея была такая: разработаем структуру описания, а потом будем описывать существующие практики в этой структуре — "эссенциализировать" практики. На текущий момент описан SCRUM, базовые идеи Agile, Agile at scale, OpenUP, и, говорят, внутри в консалтинговой компании Якобсона есть описания процессов Spotify, SAFe и т.д. В принципе, в основном он эту тему и двигает, неясно — есть ли кто там ещё.
На удивление, есть ГОСТ Р 57195-2016, соответствующий OMG Essence. Вот только описания практик на русском нет.
Как думаете, интересная это тема — иметь библиотеку практик сразу в стандартном виде, готовую для внедрения, с чек-листами?
👍32❤1