Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано.
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
1❤22👍11🔥6👏1🤣1
Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку).
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
💎 Уникальность — насколько этот контекст важен для успеха организации?
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
⚙️ Роль в бизнес-модели:
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
📊 Стадия эволюции (по Wardley map):
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2👌1
Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО?
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
👍13❤4🔥1
Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
❤7🔥4👍3
Нужно, наверное, какие-то итоги года подвести.
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
🎄 🎁 🥂 🎆
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
Please open Telegram to view this post
VIEW IN TELEGRAM
2🎉58❤33🔥12🎄4🥰3
С наступившим Новым годом!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
❤29🎉7🔥5👍1
Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО".
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
🔥10❤8👏7
Так, что-то каникулы канала неожиданно затянулись. Уже и новый год прошел, и старый, и день святого Валентина, и китайский Новый год начался, совмещенный с Масленицей. Кажется, такой паузы я ещё не делал.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногуразбирать ёлку восстанавливать ритм публикаций. Нести свет просвещения в области системного анализа. Надеюсь, вы скучали.
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногу
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
👍23❤4🕊3
Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом?
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
👍27❤6
Меня иногда спрашивают — откуда я беру темы и как ищу неожиданные ракурсы. В основном из смежных областей. Всегда бывает интересно послушать, какие нашли решения похожих проблем в других индустриях.
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
👍26❤13🔥6💯2👏1
Помните карту с 162 атрибутами качества программных систем? У нас для качества требований столько не наберется, но вот ученые в эмпирических исследованиях обнаружили 111 (не знаю, как они считали, у меня получилось 89, но всё равно впечатляет!)
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
1🔥14👍4👏2❤1
Залез в mermaid.js по какой-то надобности, а он теперь mermaid.ai, весь такой ИИ-интегрированный.
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
1🔥7❤6👍1
Я в последнее время в связи с использованием ИИ заметил вот что: можно, конечно, загонять в него формальные промпты по какой-то структуре (многие из которых упомянуты тут), но вообще он итак неплохо работает, в режиме обычного человеческого диалога, а не вот этих формальных рамок.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
1❤26👍14🔥3👎1
Если вы думаете, что ИИ победно шествует по рынку труда, то нет. Свежий анализ Anthropic показывает, что ещё толком ничего не началось.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
1👍18🤔5