Собственно, по управлению требованиями у нас есть целый ГОСТ Р 59194-2020.
Вот его основные положения.
1. Есть два вида деятельности:
— разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию).
— контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон).
2. Требования могут быть представлены в форме базы данных или документа.
3. Есть исходные требования — фиксирующие потребности заинтересованных сторон и служащие для валидации,
и есть проектные требования — для разработки различной документации готового объекта и для верификации.
4. Есть два типа "контрольных рубежей":
— на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
— на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
5. При проверке требований выполняют их валидацию и верификацию.
При валидации проверяют:
— полноту покрытия спецификацией исходных требований
— правильность выражения потребностей или отражения принятого технического решения
— наличие связи с потребностями или родительским требованием
— непротиворечивость
При верификации:
— что требования относятся к одному объекту (!)
— что требования соответствуют критериям качества
— что у них правильно заполнены атрибуты, они правильно классифицированы и связаны
— установлены критерии верификации и валидации объекта, который будет разработан по этим требованиям.
6. Минимальный набор атрибутов требования:
— Уникальный идентификатор
— Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа)
— Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!)
7. Очень сильная идея: требования являются частью конфигурации!
И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи").
То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой!
Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации).
Про конфигурации очень часто не задумываются, пока не обнаруживают себя в ситуации, когда развернуто 8-10 экземпляров одной и той же системы, отличающихся набором данных, справочников, функций, набором ролей, подключенных внешних систем и заглушек и средств мониторинга.
Причем никто в точности не знает — сколько их точно развернуто, где, чем они друг от друга отличаются и кто к ним имеет доступ.
Вот тут-то управление конфигурациями и начинается!
Вот его основные положения.
1. Есть два вида деятельности:
— разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию).
— контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон).
2. Требования могут быть представлены в форме базы данных или документа.
3. Есть исходные требования — фиксирующие потребности заинтересованных сторон и служащие для валидации,
и есть проектные требования — для разработки различной документации готового объекта и для верификации.
4. Есть два типа "контрольных рубежей":
— на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
— на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
5. При проверке требований выполняют их валидацию и верификацию.
При валидации проверяют:
— полноту покрытия спецификацией исходных требований
— правильность выражения потребностей или отражения принятого технического решения
— наличие связи с потребностями или родительским требованием
— непротиворечивость
При верификации:
— что требования относятся к одному объекту (!)
— что требования соответствуют критериям качества
— что у них правильно заполнены атрибуты, они правильно классифицированы и связаны
— установлены критерии верификации и валидации объекта, который будет разработан по этим требованиям.
6. Минимальный набор атрибутов требования:
— Уникальный идентификатор
— Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа)
— Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!)
7. Очень сильная идея: требования являются частью конфигурации!
И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи").
То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой!
Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации).
Про конфигурации очень часто не задумываются, пока не обнаруживают себя в ситуации, когда развернуто 8-10 экземпляров одной и той же системы, отличающихся набором данных, справочников, функций, набором ролей, подключенных внешних систем и заглушек и средств мониторинга.
Причем никто в точности не знает — сколько их точно развернуто, где, чем они друг от друга отличаются и кто к ним имеет доступ.
Вот тут-то управление конфигурациями и начинается!
👍8🔥7❤1🤔1
Я учу людей уже больше 15 лет — сначала в университетах, потом на тренингах. За это время через меня прошло, наверное, больше тысячи учеников. И вот что я заметил: кроме знаний и навыков в людях существуют некоторые базовые реакции и вообще отношение к делу, которые очень сложно изменить.
В модели KSA это третья буква — Attitude, в переводе: отношение, подход, жизненная позиция. Я уже писал про неё пару раз. И это отношение очень хорошо проявляется на тренинге.
Почти на каждом курсе по выявлению требований и проектированию систем появляется задача поиска внешней документации. Люди выбирают предметную область, в которой есть регуляторные документы: стандарты, приказы, регламенты. Либо (на тренингах по проектированию интеграций) возникают интеграции с внешними системами — государственными или стандартными в отрасли — например, 1С.
И среди многих сотен участников моих образовательных событий за все годы я могу по пальцам пересчитать людей, которые действительно пошли и почитали эти документы! Регламенты, стандарты, документацию по способам интеграции. Единицы! В основном все говорят: ну, мы предположим. Или: мы понимаем, что так нужно сделать, и в реальном проекте мы бы нашли эти документы и изучили их, а на тренинге — да ну, зачем.
Доходит до смешного: я прихожу, скажем, на второй день тренинга, и показываю группе документацию или даже тестовый эндпоинт, которые я нашел по пути домой. Очень интересно, говорят участники, и продолжают выдумывать удобные им форматы.
Это то самое отношение. Это естественная реакция на новое. Я — даже на тренинге, и даже для участников учебного проекта — не могу оставить какой—то вопрос повисшим в воздухе. Мне нужно разобраться и найти источники. С одной стороны это любопытство — а как они вот это всё спроектировали? С другой — тревожность: как же я оставлю в проекте вопрос, который от меня не зависит, непроясненным. Это срабатывает на автомате: обнаружил внешние требования — нашел их источник. (Так же у меня на автомате срабатывает фактчекинг и поиск исходного источника при прочтении новостей).
И это отношение очень важно для аналитика! Любопытство, желание докопаться до источников, опасение оставить в проекте дырку или голые предположения. Тем более, что очень часто все документы есть на расстоянии буквально пары кликов — вбить поисковый запрос и прочитать первые две-три страницы в выдаче.
И ведь как интересно может быть!
Помню, когда я вел тренинг Сергея Нужненко про ручку, мы загадали участникам написать ТЗ на ручки для детского самоката. Так как это товар для детей, было очевидно, что он зарегулирован. И действительно, есть ГОСТ Р ИСО 8124-1-2014, где детским самокатам посвящен отдельный раздел 4.29 и разделы 5.26-30 с методами испытаний. Это же просто песня! Во-первых, можно сразу брать из документа готовые требования. Во-вторых, я надолго зачитался самим стандартом и пришел в восторг — как много, всё-таки, требований к физическому изделию — там и размеры, и прочность, и острые углы, и акустика, и магнитные свойства, и электрические — вот где действительно требуется анализ требований!
Конечно, такое отношение не возникает на тренингах — просто не хватает времени. Возможно, его можно воспитать в университете за годы обучения. Или на работе — при понятной и быстрой обратной связи и влиянии среды (что касается ценностей, мы ориентируемся на окружающих — теория разбитых окон работает в обе стороны).
Ну и смежный вопрос — как проверить этот самые attitudes на собеседовании? (И есть ли у нанимающего менеджера они в списке проверок). Вообще они легко проверяются при помощи небольшого тестового, требующего изучения внешней документации, но я слышал, что тестовые задания сейчас очень негативно воспринимаются кандидатами...
В модели KSA это третья буква — Attitude, в переводе: отношение, подход, жизненная позиция. Я уже писал про неё пару раз. И это отношение очень хорошо проявляется на тренинге.
Почти на каждом курсе по выявлению требований и проектированию систем появляется задача поиска внешней документации. Люди выбирают предметную область, в которой есть регуляторные документы: стандарты, приказы, регламенты. Либо (на тренингах по проектированию интеграций) возникают интеграции с внешними системами — государственными или стандартными в отрасли — например, 1С.
И среди многих сотен участников моих образовательных событий за все годы я могу по пальцам пересчитать людей, которые действительно пошли и почитали эти документы! Регламенты, стандарты, документацию по способам интеграции. Единицы! В основном все говорят: ну, мы предположим. Или: мы понимаем, что так нужно сделать, и в реальном проекте мы бы нашли эти документы и изучили их, а на тренинге — да ну, зачем.
Доходит до смешного: я прихожу, скажем, на второй день тренинга, и показываю группе документацию или даже тестовый эндпоинт, которые я нашел по пути домой. Очень интересно, говорят участники, и продолжают выдумывать удобные им форматы.
Это то самое отношение. Это естественная реакция на новое. Я — даже на тренинге, и даже для участников учебного проекта — не могу оставить какой—то вопрос повисшим в воздухе. Мне нужно разобраться и найти источники. С одной стороны это любопытство — а как они вот это всё спроектировали? С другой — тревожность: как же я оставлю в проекте вопрос, который от меня не зависит, непроясненным. Это срабатывает на автомате: обнаружил внешние требования — нашел их источник. (Так же у меня на автомате срабатывает фактчекинг и поиск исходного источника при прочтении новостей).
И это отношение очень важно для аналитика! Любопытство, желание докопаться до источников, опасение оставить в проекте дырку или голые предположения. Тем более, что очень часто все документы есть на расстоянии буквально пары кликов — вбить поисковый запрос и прочитать первые две-три страницы в выдаче.
И ведь как интересно может быть!
Помню, когда я вел тренинг Сергея Нужненко про ручку, мы загадали участникам написать ТЗ на ручки для детского самоката. Так как это товар для детей, было очевидно, что он зарегулирован. И действительно, есть ГОСТ Р ИСО 8124-1-2014, где детским самокатам посвящен отдельный раздел 4.29 и разделы 5.26-30 с методами испытаний. Это же просто песня! Во-первых, можно сразу брать из документа готовые требования. Во-вторых, я надолго зачитался самим стандартом и пришел в восторг — как много, всё-таки, требований к физическому изделию — там и размеры, и прочность, и острые углы, и акустика, и магнитные свойства, и электрические — вот где действительно требуется анализ требований!
Конечно, такое отношение не возникает на тренингах — просто не хватает времени. Возможно, его можно воспитать в университете за годы обучения. Или на работе — при понятной и быстрой обратной связи и влиянии среды (что касается ценностей, мы ориентируемся на окружающих — теория разбитых окон работает в обе стороны).
Ну и смежный вопрос — как проверить этот самые attitudes на собеседовании? (И есть ли у нанимающего менеджера они в списке проверок). Вообще они легко проверяются при помощи небольшого тестового, требующего изучения внешней документации, но я слышал, что тестовые задания сейчас очень негативно воспринимаются кандидатами...
🔥24👍11❤5🤔1
Ваше API не REST! Ну и что?
Слова "REST API" уже несколько потеряли свой смысл, и только пуристы и зануды вспоминают Леонарда Ричардсона с его четырьмя уровнями зрелости REST API и Роя Филдинга с его диссертацией. Это как Конституция — все слышали, что она есть, но мало кто её сам читал, а уж когда доходит дело до применения... Мы используем http — значит, у нас уже REST!
В реальной практике чего только не бывает, и CRUD вокруг ресурса — под что REST наилучшим способом заточен — бывает как раз не так уж часто. В сервисах и микросервисах часто в API выставляют некие функций (у которых даже имена, как у функций: getClientPortfolio, validatePassport, saveFile), и близко не покрывающие матрицу действий по созданию, чтению, изменению и удалению.
И это оправдано! Ну вот какой ресурс мы создаем или читаем при проверке паспорта заёмщика? Да мы его просто проверяем.
не-REST API — это нормально. Если вы осознанно выбрали этот вариант, и понимаете плюсы и минусы. Удаленный вызов процедуры, RPC, как паттерн имеет смысл. Только давайте будем честны перед собой и не будем называть это REST. С другой стороны, а как называть, если это не SOAP, а что-то более легкое и на JSON-чиках?
Вообще, с 2005 года существует и развивается протокол JSON-RPC, сейчас уже версии 2.0. Хотите RPC на JSONах — возьмите хоть что-то более-менее стандартизованное, не изобретайте велосипед. Есть уже готовые реализации протокола почти на любом языке.
Официальный сайт https://www.jsonrpc.org/
Есть свой эквивалент сваггера и OpenAPI: OpenRPC, который одновременно и документацию генерит, и работает как WSDL для SOAP — то есть, позволяет получить весь контракт сервиса JSON-RPC.
Короче! Не придумывайте свои велосипеды, используйте готовые!
В англоязычной среде есть термин 'bikeshadding', "обсуждение сарая для велосипедов". Велосипеды здесь по совпадению, а может быть и нет. Источником является история про комиссию, которая должна была согласовать проект атомной электростанции, но на каждом совещании занималась рассмотрением мелких вопросов вроде сарайчика для велосипедов — из каких он должен быть материалов и где установлен? Другое название этого эффекта — "Закон тривиальности":
Это типичное проявление когнитивного искажения, связанного с подменой объекта: мы избегаем думать о сложном и труднодоступном объекте, предпочитая обсуждать нечто другое — явно или неявно.
В общем, прекращайте обсуждать сарайчик для велосипедов! Решите главное: у вас REST или RPC. Решили? Берите готовый стандарт: OpenAPI и JSON:API для REST, JSON-RPC или SOAP для RPC, и двигайтесь дальше. Там, глядишь, и до gRPC доживете :)
Слова "REST API" уже несколько потеряли свой смысл, и только пуристы и зануды вспоминают Леонарда Ричардсона с его четырьмя уровнями зрелости REST API и Роя Филдинга с его диссертацией. Это как Конституция — все слышали, что она есть, но мало кто её сам читал, а уж когда доходит дело до применения... Мы используем http — значит, у нас уже REST!
В реальной практике чего только не бывает, и CRUD вокруг ресурса — под что REST наилучшим способом заточен — бывает как раз не так уж часто. В сервисах и микросервисах часто в API выставляют некие функций (у которых даже имена, как у функций: getClientPortfolio, validatePassport, saveFile), и близко не покрывающие матрицу действий по созданию, чтению, изменению и удалению.
И это оправдано! Ну вот какой ресурс мы создаем или читаем при проверке паспорта заёмщика? Да мы его просто проверяем.
не-REST API — это нормально. Если вы осознанно выбрали этот вариант, и понимаете плюсы и минусы. Удаленный вызов процедуры, RPC, как паттерн имеет смысл. Только давайте будем честны перед собой и не будем называть это REST. С другой стороны, а как называть, если это не SOAP, а что-то более легкое и на JSON-чиках?
Вообще, с 2005 года существует и развивается протокол JSON-RPC, сейчас уже версии 2.0. Хотите RPC на JSONах — возьмите хоть что-то более-менее стандартизованное, не изобретайте велосипед. Есть уже готовые реализации протокола почти на любом языке.
Официальный сайт https://www.jsonrpc.org/
Есть свой эквивалент сваггера и OpenAPI: OpenRPC, который одновременно и документацию генерит, и работает как WSDL для SOAP — то есть, позволяет получить весь контракт сервиса JSON-RPC.
Короче! Не придумывайте свои велосипеды, используйте готовые!
В англоязычной среде есть термин 'bikeshadding', "обсуждение сарая для велосипедов". Велосипеды здесь по совпадению, а может быть и нет. Источником является история про комиссию, которая должна была согласовать проект атомной электростанции, но на каждом совещании занималась рассмотрением мелких вопросов вроде сарайчика для велосипедов — из каких он должен быть материалов и где установлен? Другое название этого эффекта — "Закон тривиальности":
"Участники обсуждения всегда придают чрезмерное значение тривиальным вопросам"
или
"Время, потраченное на обсуждение пункта повестки, обратно пропорционально его важности"
Это типичное проявление когнитивного искажения, связанного с подменой объекта: мы избегаем думать о сложном и труднодоступном объекте, предпочитая обсуждать нечто другое — явно или неявно.
В общем, прекращайте обсуждать сарайчик для велосипедов! Решите главное: у вас REST или RPC. Решили? Берите готовый стандарт: OpenAPI и JSON:API для REST, JSON-RPC или SOAP для RPC, и двигайтесь дальше. Там, глядишь, и до gRPC доживете :)
👍19🔥8❤2
В этом году я член ПК Летнего Аналитического Фестиваля, он состоится в Подмосковье 13-14 июля, и остается чуть больше недели, чтобы подать заявку на доклад!
Подавайте заявку, даже если вы ещё ни разу нигде не выступали, но очень хотите попробовать. ЛАФ в этом смысле — одна из самых демократичных конференций.
Темы, которые мы ждем больше всего:
- Проектирование, интеграция и архитектура
- Практики использования инструментов для системных аналитиков
- Продуктовые практики
- Использование AI-инструментов
А также:
- Разработка и управление требованиями
- Развитие и саморазвитие аналитика
- Soft skills
- Лидерство и управление командой
- Другие темы, которые помогут расширить кругозор аналитика
Мы будем рады рассказам и рефлексии личного опыта в реальных проектах, а также любым интерактивным форматам: мастер-классам, воркшопам, деловым играм, круглым столам и дискуссиям.
Зарегистрировать заявку на доклад можно здесь: https://events-pro.ru/conference/fe501f51-4043-4340-882b-55e5cd97f1a5/become_speaker
(Если совсем сомневаетесь — можете мне в личные сообщения написать с идеей, обсудим)
Для докладчиков проживание в отеле Sheraton Skypoint Luxe 5* БЕСПЛАТНО при включении вашего выступления в программу.
Срок подачи заявок - до 20 апреля 2024 года.
Подавайте заявку, даже если вы ещё ни разу нигде не выступали, но очень хотите попробовать. ЛАФ в этом смысле — одна из самых демократичных конференций.
Темы, которые мы ждем больше всего:
- Проектирование, интеграция и архитектура
- Практики использования инструментов для системных аналитиков
- Продуктовые практики
- Использование AI-инструментов
А также:
- Разработка и управление требованиями
- Развитие и саморазвитие аналитика
- Soft skills
- Лидерство и управление командой
- Другие темы, которые помогут расширить кругозор аналитика
Мы будем рады рассказам и рефлексии личного опыта в реальных проектах, а также любым интерактивным форматам: мастер-классам, воркшопам, деловым играм, круглым столам и дискуссиям.
Зарегистрировать заявку на доклад можно здесь: https://events-pro.ru/conference/fe501f51-4043-4340-882b-55e5cd97f1a5/become_speaker
(Если совсем сомневаетесь — можете мне в личные сообщения написать с идеей, обсудим)
Для докладчиков проживание в отеле Sheraton Skypoint Luxe 5* БЕСПЛАТНО при включении вашего выступления в программу.
Срок подачи заявок - до 20 апреля 2024 года.
👍13🔥4
На корпоративных тренингах на рабочем месте часто бывает ситуация, когда люди отваливаются: вчера ещё было 3 человека в команде, а сегодня, смотришь — остался только один, остальных растащили на встречи.
И часто этот оставшийся работает лучше и быстрее, чем до этого они работали втроем!
Я и сам сталкивался с таким, как участник: на одном курсе по управлению проектами мы выполняли задание сначала индивидуально, а потом то же задание в группах. По идее, результат группы должен быть лучше самого лучшего индивидуального результата, но моя группа сумела даже ухудшить мой результат :) Инициативу захватила одна участница, которая, видимо, очень хотела показать свои лидерские качества, а проще всего это сделать, если всех критиковать, подвергать сомнению и настаивать на собственной правоте. А то какой же я лидер, если просто прислушиваюсь к другим! Я в это играть не очень хотел, ну и вот. Не хотите ко мне прислушиваться — садитесь в лужу, bon voyage.
У этого явления есть название: эффект Рингельмана. В ИТ мы знаем его следствие, известное как Закон Брукса:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
Эффект Рингельмана формулируется так:
«Личная продуктивность отдельных членов группы снижается по мере роста численности группы»
Изучал он этот эффект на примере перетягивания каната — в принципе, деятельность, похожая на создание ИТ-продукта.
В исследованиях Рингельмана общая продуктивность группы уже на 5 участниках составляет только 3.5 (считая эталонную продуктивность каждого в отдельности за 1), а после 7 практически перестает расти, застывая на отметке 3.92.
Обычно эффект объясняют двумя причинами: "социальной ленью" и потерей координации.
Если мы видим, что над той же задачей работает кто-то ещё, мы уже не так сильно вкладываемся. Это "социальная лень" или "социальное бездействие".
Если наши действия нескоординированы, мы, как минимум тратим время на их координацию (в том числе — выясняя, кто тут главный), как максимум — начинаем действовать разнонаправлено, разбалансируя работу.
Что тут можно сделать?
Брукс предлагал выстраивать группы вокруг признанного лидера и эксперта, по типу операционной бригады (всегда есть главный хирург, который делает операцию, остальные ему ассистируют).
Agile говорит, что команда должна быть не больше, чем можно накормить двумя пиццами (5-7 человек).
Исследования сообщают, что социальное бездействие ослабевает, если:
1. У людей есть общая разделяемая цель
2. Вклад каждого участника может быть идентифицирован и оценен
3. Люди чувствуют свою незаменимость
В целом, это вопрос мотивации.
А вот координация — вопрос технический, это "харды" организации работ. Сам Рингельман, кроме перетягивания каната, изучал ещё перетаскивание камней при помощи веревок и перемещением тележек мускульной силой (он вообще занимался организацией работ в сельском хозяйстве, и работал примерно в одно время с Тейлором и Гастевым). Измеряя силы, прикладываемые работниками к камню, он выяснил, что основная проблема в синхронизации усилий: то один начинает не вовремя, то тянут в разные стороны. Про мотивацию он как раз не писал.
В общем, эти харды применимы к любым работам:
- нужно обеспечить последовательность работ;
- устранить потери (объект работы ждёт человека; человек ждёт объект работы);
- по возможности убрать одновременные разнонаправленные работы над одним объектом;
- очертить каждому участнику границу работ и поставить точную цель;
- определить, формализовать и ограничить по срокам процесс принятия решений;
В конечном счете это всё про разделение (объектов и выполняемых над ними работ), объединение (результатов работ в единое целое) и принятие решений.
Хм, кажется, опять получилось про анализ и архитектуру.
И часто этот оставшийся работает лучше и быстрее, чем до этого они работали втроем!
Я и сам сталкивался с таким, как участник: на одном курсе по управлению проектами мы выполняли задание сначала индивидуально, а потом то же задание в группах. По идее, результат группы должен быть лучше самого лучшего индивидуального результата, но моя группа сумела даже ухудшить мой результат :) Инициативу захватила одна участница, которая, видимо, очень хотела показать свои лидерские качества, а проще всего это сделать, если всех критиковать, подвергать сомнению и настаивать на собственной правоте. А то какой же я лидер, если просто прислушиваюсь к другим! Я в это играть не очень хотел, ну и вот. Не хотите ко мне прислушиваться — садитесь в лужу, bon voyage.
У этого явления есть название: эффект Рингельмана. В ИТ мы знаем его следствие, известное как Закон Брукса:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
Эффект Рингельмана формулируется так:
«Личная продуктивность отдельных членов группы снижается по мере роста численности группы»
Изучал он этот эффект на примере перетягивания каната — в принципе, деятельность, похожая на создание ИТ-продукта.
В исследованиях Рингельмана общая продуктивность группы уже на 5 участниках составляет только 3.5 (считая эталонную продуктивность каждого в отдельности за 1), а после 7 практически перестает расти, застывая на отметке 3.92.
Обычно эффект объясняют двумя причинами: "социальной ленью" и потерей координации.
Если мы видим, что над той же задачей работает кто-то ещё, мы уже не так сильно вкладываемся. Это "социальная лень" или "социальное бездействие".
Если наши действия нескоординированы, мы, как минимум тратим время на их координацию (в том числе — выясняя, кто тут главный), как максимум — начинаем действовать разнонаправлено, разбалансируя работу.
Что тут можно сделать?
Брукс предлагал выстраивать группы вокруг признанного лидера и эксперта, по типу операционной бригады (всегда есть главный хирург, который делает операцию, остальные ему ассистируют).
Agile говорит, что команда должна быть не больше, чем можно накормить двумя пиццами (5-7 человек).
Исследования сообщают, что социальное бездействие ослабевает, если:
1. У людей есть общая разделяемая цель
2. Вклад каждого участника может быть идентифицирован и оценен
3. Люди чувствуют свою незаменимость
В целом, это вопрос мотивации.
А вот координация — вопрос технический, это "харды" организации работ. Сам Рингельман, кроме перетягивания каната, изучал ещё перетаскивание камней при помощи веревок и перемещением тележек мускульной силой (он вообще занимался организацией работ в сельском хозяйстве, и работал примерно в одно время с Тейлором и Гастевым). Измеряя силы, прикладываемые работниками к камню, он выяснил, что основная проблема в синхронизации усилий: то один начинает не вовремя, то тянут в разные стороны. Про мотивацию он как раз не писал.
В общем, эти харды применимы к любым работам:
- нужно обеспечить последовательность работ;
- устранить потери (объект работы ждёт человека; человек ждёт объект работы);
- по возможности убрать одновременные разнонаправленные работы над одним объектом;
- очертить каждому участнику границу работ и поставить точную цель;
- определить, формализовать и ограничить по срокам процесс принятия решений;
В конечном счете это всё про разделение (объектов и выполняемых над ними работ), объединение (результатов работ в единое целое) и принятие решений.
Хм, кажется, опять получилось про анализ и архитектуру.
👍41❤15🔥3
Отличное задание для проверки аналитика на собеседовании:
предложите кандидату написать требования для управления роботом-пылесосом.
А потом посмотрите — появится ли в списке требований обнаружение собачьих/кошачьих💩 и остановка в этой ситуации.
Конечно, можно наткнуться на человека, у которого есть дети и/или домашние животные, и который сам оказывался в ситуации, когда робот-пылесос не обладал такой функцией, въехал в :poop: и потом разнес его по всему дому...
Но если животных нет, то какой ход мысли должен быть у аналитика, чтобы выявить такую функцию? Какие вопросы можно задать, чтобы выйти на такую потребность? А после этого ещё оценить, насколько сложно реализовать такую функцию при помощи имеющихся технологий, и насколько нужно её реализовывать, какова её востребованность и влияние на пользователей?
В реальном мире такая функция появилась далеко не сразу — то ли про неё и правда не подумали, то ли не знали, как решить, пока не развились технологии уверенного распознавания образов. Но уж этого-то наверняка было много сообщений от пользователей, можно целый spreadshit составить (pun intended).
⬇️ ⬇️ ⬇️
В книге Яна Александера 'Discovering Requirements' (не того, который актер озвучания в Last of Us, а английского учёного в области инженерии требований) разделяются 'greenfield development' и 'brownfield development' — проекты, стартующие с нуля, и проекты развития/модернизации существующей системы.
Сбор требований к проектам разного вида имеет свои особенности. В случае Brownfield обычно имеется большое число жалоб, обращений пользователей, предложений и -- очень важный источник — народные сценарии работы, прихватки и инструкции. В компаниях они иногда написаны на клейких листочках, иногда передаются друг-другу в виде доковских файлов или постов на форуме;
в старое время я видел тетрадки с записанными рукой шагами для получения какого-нибудь отчета (пойти в настройки, переключить там галочку, потом пойти в отчет, задать такие-то параметры, сохранить в xml, запустить скрипт, который написал парень, работавший здесь 4 года назад, открыть в Excel вот в этом шаблоне, вписать на первой странице точные даты начала и окончания квартала — и отчет готов!).
Это всегда просто кладезь информации о том, как пользователи обходят несовершенство системы!
Рассуждая дальше о greenfield и brownfield, Александер отмечает, что в университетах и на курсах практически всегда говорят о первой ситуации (сбор требований к новой системе), а в жизни чаще встречается второй вариант: доработка существующей системы. Правда, сам он тоже не слишком много внимания уделяет этой теме, зато упоминает корпоративную археологию! — когда нужно найти описания и причины текущего состояния системы, прокопавшись через несколько культурных слоев документации.
Удивительно, но книга Александера никогда не переводилась на русский (написана в 2009). А по содержанию и концентрации смысла она точно не хуже Вигерса!
предложите кандидату написать требования для управления роботом-пылесосом.
А потом посмотрите — появится ли в списке требований обнаружение собачьих/кошачьих
Конечно, можно наткнуться на человека, у которого есть дети и/или домашние животные, и который сам оказывался в ситуации, когда робот-пылесос не обладал такой функцией, въехал в :poop: и потом разнес его по всему дому...
Но если животных нет, то какой ход мысли должен быть у аналитика, чтобы выявить такую функцию? Какие вопросы можно задать, чтобы выйти на такую потребность? А после этого ещё оценить, насколько сложно реализовать такую функцию при помощи имеющихся технологий, и насколько нужно её реализовывать, какова её востребованность и влияние на пользователей?
В реальном мире такая функция появилась далеко не сразу — то ли про неё и правда не подумали, то ли не знали, как решить, пока не развились технологии уверенного распознавания образов. Но уж этого-то наверняка было много сообщений от пользователей, можно целый spreadshit составить (pun intended).
В книге Яна Александера 'Discovering Requirements' (не того, который актер озвучания в Last of Us, а английского учёного в области инженерии требований) разделяются 'greenfield development' и 'brownfield development' — проекты, стартующие с нуля, и проекты развития/модернизации существующей системы.
Сбор требований к проектам разного вида имеет свои особенности. В случае Brownfield обычно имеется большое число жалоб, обращений пользователей, предложений и -- очень важный источник — народные сценарии работы, прихватки и инструкции. В компаниях они иногда написаны на клейких листочках, иногда передаются друг-другу в виде доковских файлов или постов на форуме;
в старое время я видел тетрадки с записанными рукой шагами для получения какого-нибудь отчета (пойти в настройки, переключить там галочку, потом пойти в отчет, задать такие-то параметры, сохранить в xml, запустить скрипт, который написал парень, работавший здесь 4 года назад, открыть в Excel вот в этом шаблоне, вписать на первой странице точные даты начала и окончания квартала — и отчет готов!).
Это всегда просто кладезь информации о том, как пользователи обходят несовершенство системы!
Рассуждая дальше о greenfield и brownfield, Александер отмечает, что в университетах и на курсах практически всегда говорят о первой ситуации (сбор требований к новой системе), а в жизни чаще встречается второй вариант: доработка существующей системы. Правда, сам он тоже не слишком много внимания уделяет этой теме, зато упоминает корпоративную археологию! — когда нужно найти описания и причины текущего состояния системы, прокопавшись через несколько культурных слоев документации.
Удивительно, но книга Александера никогда не переводилась на русский (написана в 2009). А по содержанию и концентрации смысла она точно не хуже Вигерса!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32💩12🔥11❤5
Обещал написать, какими вопросами можно зацепить функции для робота-пылесоса.
В целом, всё сводится к анализу контекста и окружения: нам нужно понять, что может находиться вокруг робота во время работы и с чем он может столкнуться. Также нужно немного подвигать временное окно — что было до того, как началось выполнение действия, и что может быть после.
Я пользуюсь набором простых вопросов (иногда в уме, иногда в явном виде — для сложных проектов) для каждого действия (сценария).
Вопросы:
* Для чего? (Вариант: что будет дальше?)
* Какое обратное действие?
* Кто? (роль; есть ли дополнительные признаки и условия?)
* Когда? (ограничения на допустимые состояния; триггеры автоматического запуска)
* Где? (какое устройство? что вокруг?)
* С кем? Кто рядом?
* Сколько? (любой численный показатель, который может описывать процесс)
* Как? (какие есть альтернативные способы выполнения действия и какие ограничения?)
* Какой? (особенности, классификаторы и состояния объекта)
* Что нужно/может быть до начала действия? (в описании use case это нужно писать в "предусловия", но мало кто пишет)
* Что уменьшается/увеличивается в процессе? (например, при записи на курс уменьшается число свободных мест; у робота тратится заряд и увеличивается убранная площадь)
* Чем заканчивается действие? (Постусловия, что будет создано? что поменяется? есть ли триггер на прерывание длительного действия?)
* Что может помешать выполнить действие?
* Что будет, если каких-то объектов 0,1,N? (Например, один студент записывается на курс. Может ли на курс записаться N студентов одним действием? А N студентов параллельно?)
Можно добавить вопросы безопасности:
* Чем система может навредить при выполнении действия?
* Какую информацию нельзя показывать/изменять при выполнении действия?
* Что может сделать злоумышленник при выполнении действия?
На фичу из предыдущего поста могут навести вопросы "Кто рядом?" (дети, домашние животные), "Что было до?" (что от них могло остаться на полу?), "Что может помешать?", "Чем система может навредить?"
В целом, всё сводится к анализу контекста и окружения: нам нужно понять, что может находиться вокруг робота во время работы и с чем он может столкнуться. Также нужно немного подвигать временное окно — что было до того, как началось выполнение действия, и что может быть после.
Я пользуюсь набором простых вопросов (иногда в уме, иногда в явном виде — для сложных проектов) для каждого действия (сценария).
Вопросы:
* Для чего? (Вариант: что будет дальше?)
* Какое обратное действие?
* Кто? (роль; есть ли дополнительные признаки и условия?)
* Когда? (ограничения на допустимые состояния; триггеры автоматического запуска)
* Где? (какое устройство? что вокруг?)
* С кем? Кто рядом?
* Сколько? (любой численный показатель, который может описывать процесс)
* Как? (какие есть альтернативные способы выполнения действия и какие ограничения?)
* Какой? (особенности, классификаторы и состояния объекта)
* Что нужно/может быть до начала действия? (в описании use case это нужно писать в "предусловия", но мало кто пишет)
* Что уменьшается/увеличивается в процессе? (например, при записи на курс уменьшается число свободных мест; у робота тратится заряд и увеличивается убранная площадь)
* Чем заканчивается действие? (Постусловия, что будет создано? что поменяется? есть ли триггер на прерывание длительного действия?)
* Что может помешать выполнить действие?
* Что будет, если каких-то объектов 0,1,N? (Например, один студент записывается на курс. Может ли на курс записаться N студентов одним действием? А N студентов параллельно?)
Можно добавить вопросы безопасности:
* Чем система может навредить при выполнении действия?
* Какую информацию нельзя показывать/изменять при выполнении действия?
* Что может сделать злоумышленник при выполнении действия?
На фичу из предыдущего поста могут навести вопросы "Кто рядом?" (дети, домашние животные), "Что было до?" (что от них могло остаться на полу?), "Что может помешать?", "Чем система может навредить?"
👍28❤5🔥3💩1
Пятничный пост (не очень серьезный)
Набор вопросов из предыдущего поста можно обобщить и использовать для рассмотрения системы в целом.
Интересно, что список вопросов можно взять примерно тот же, что используется коучами для самоопределения людей :)
Вот, например, пирамида Дилтса (не путать с Маслоу и Минто!).
Её уровни:
1. Окружение. Кто вокруг, контекст, использующая система. От кого мы зависим, чьё мнение про систему для нас важно. На кого мы хотим повлиять.
2. Поведение. Это функции системы. Что система делает, как ведёт себя в зависимости от реакции пользователя/внешней среды.
3. Способности (capabilities) — возможности системы. Что система потенциально может делать (и что ей сделать будет трудно). Тут связь с архитектурой.
4. Ценности и принципы. Продуктовые параметры. Что для нас, хорошо, и что — плохо? На что мы никогда не пойдем? Что мы будет поддерживать изо всех сил? Что для нас ценно, а что неважно? (Важны ли данные пользователя, или их можно потерять? Важна ли безопасность? Важна ли социальная составляющая, и какие именно взаимодействия мы хотим поддерживать? Исходя из чего мы выбираем, что делать?)
5. Идентичность — вот эта система, она кто? Ведь обычно система представляет опосредованное взаимодействие людей (вы могли бы пойти в банк и общаться с операционистом, но используете банковское приложение). И вот эта система для пользователя — кто? Помощник? Советник? Контролер? Наставник? Диджей? Экспертный продавец? И т.п. Например, для одной школьной системы мы пришли к выводу, что система, которую задумывали, как дневник, на самом деле должна вести себя как тьютор — не ругать за ошибки, а спрашивать про настрой и мягко вести к цели.
6. Миссия — зачем мы делаем систему? Какое влияние хотим оказать на мир?
Как говорят коучи, решение любой проблемы находится на более высоких уровнях пирамиды. Если у вас противоречивые требования к функциям — проверьте уровни способностей, ценностей и идентичности. Если вы затрудняетесь с определением архитектуры — подумайте над идентичностью и миссией.
Набор вопросов из предыдущего поста можно обобщить и использовать для рассмотрения системы в целом.
Интересно, что список вопросов можно взять примерно тот же, что используется коучами для самоопределения людей :)
Вот, например, пирамида Дилтса (не путать с Маслоу и Минто!).
Её уровни:
1. Окружение. Кто вокруг, контекст, использующая система. От кого мы зависим, чьё мнение про систему для нас важно. На кого мы хотим повлиять.
2. Поведение. Это функции системы. Что система делает, как ведёт себя в зависимости от реакции пользователя/внешней среды.
3. Способности (capabilities) — возможности системы. Что система потенциально может делать (и что ей сделать будет трудно). Тут связь с архитектурой.
4. Ценности и принципы. Продуктовые параметры. Что для нас, хорошо, и что — плохо? На что мы никогда не пойдем? Что мы будет поддерживать изо всех сил? Что для нас ценно, а что неважно? (Важны ли данные пользователя, или их можно потерять? Важна ли безопасность? Важна ли социальная составляющая, и какие именно взаимодействия мы хотим поддерживать? Исходя из чего мы выбираем, что делать?)
5. Идентичность — вот эта система, она кто? Ведь обычно система представляет опосредованное взаимодействие людей (вы могли бы пойти в банк и общаться с операционистом, но используете банковское приложение). И вот эта система для пользователя — кто? Помощник? Советник? Контролер? Наставник? Диджей? Экспертный продавец? И т.п. Например, для одной школьной системы мы пришли к выводу, что система, которую задумывали, как дневник, на самом деле должна вести себя как тьютор — не ругать за ошибки, а спрашивать про настрой и мягко вести к цели.
6. Миссия — зачем мы делаем систему? Какое влияние хотим оказать на мир?
Как говорят коучи, решение любой проблемы находится на более высоких уровнях пирамиды. Если у вас противоречивые требования к функциям — проверьте уровни способностей, ценностей и идентичности. Если вы затрудняетесь с определением архитектуры — подумайте над идентичностью и миссией.
🔥17❤7👍6
Вопрос "кем является система" для меня связан с вопросом "какие социальные взаимодействия поддерживает система"?
Проще говоря, как у вас люди общаются друг с другом через систему.
В российской практике профессиональной ориентации очень часто применяют типологию профессий Е.А.Климова: вот эти вот ЧЕЛОВЕК-ПРИРОДА, ЧЕЛОВЕК-ТЕХНИКА, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, ЧЕЛОВЕК-ЧЕЛОВЕК. Вы, возможно, помните из школы. За пределами пост-советских стран такая типология, правда, не встречается.
Так вот — работа с информационными системами, это, конечно, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, но в современных реалиях это почти всегда ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА-ЧЕЛОВЕК. Вы через систему взаимодействуете с другими людьми опосредовано. Система может вам помогать это делать, а может мешать или диктовать свои способы взаимодействия, часто неестественные.
У Джоела Спольски, которого я считаю одним из лучших авторов по проектированию интерфейсов, есть книга: User Interface Design For Programmers, в русском переводе Руководство по UI дизайну для программистов (тут сразу pdf).
Это 2001 год, а примеры там вообще из 90-х. Но принципиально ничего не поменялось... в интерфейсах. А вот в проектировании поменялось — теперь мы почти всегда проектируем социальные системы. Джоел написал об этом в 2004: It’s Not Just Usability, перевод: Не юзабилити единым, а ещё раньше в 2003: Building Communities with Software, перевод не нашел.
Один из примеров — интерфейс Napster (если вы помните такое приложение, кхе-кхе). Интерфейс был ужасен. Программа работала только на Windows. Это было одно из самых популярных приложений в мире. В 2000 году Napster создавал от 40 до 60% трафика в частных сетях и в сетях университетов.
Если вы делаете то, что нужно людям — они будут мириться с любым интерфейсом. Сейчас, наверное, можно привести в пример красноглазые интерфейсы в области крипты.
Вывод: проектировать нужно не значки на экране, а взаимодействие между людьми. Что они делают друг для друга. Как они относятся друг к другу. Что нельзя делать по отношению друг к другу. Как сообща бороться с вредоносными участниками.
Есть масса приложений с красивыми интерфейсами, совершенно не учитывающими — как именно люди общаются и взаимодействуют в каком-то процессе. Школьные дневники. Запись ко врачу и хранение истории приемов. Социальные сети (нечеловеческий LinkedIn чего стоит!). Системы приема докладов на конференции. Системы управления задачами и документацией.
Джоел приводит в пример свой FogBugz — багтрекер, в котором люди действительно работали над исправлением дефектов, в отличие от других систем, которые "was never getting used, because it did not align with the way people wanted to work together" (кстати, не доверяйте переводам, там эта фраза переврана до противоположного смысла). Про FogBugz не знаю, не видел, а Trello, разработанная в той же компании, конечно, почти эталонная по интерфейсу легковесная система управления задачами.
Практически невозможно спроектировать хорошее социальное взаимодействие, если смотрите изнутри системы. Поэтому я считаю почти бесполезным описание вариантов использования в виде CRUDL вокруг сущности. Не поняв, в чем смысл каждой операции — в чем её социальный смысл! — вы не сможете определить функции и отсутствие функций, которые сформируют и определят нужное поведение.
В принципе, можно было бы отмахнуться от рассуждений какого-то там очередного программиста-предпринимателя. Ну он же не дизайнер и не психолог, что нам втирает. Если бы не одно "но": Джоел Спольски — создатель StackOverflow. Социального сервиса, который собрал крупнейшее сообщество разработчиков и в определенном смысле перевернул способ обучения програмиированию и разработки. Я бы прислушался.
Проще говоря, как у вас люди общаются друг с другом через систему.
В российской практике профессиональной ориентации очень часто применяют типологию профессий Е.А.Климова: вот эти вот ЧЕЛОВЕК-ПРИРОДА, ЧЕЛОВЕК-ТЕХНИКА, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, ЧЕЛОВЕК-ЧЕЛОВЕК. Вы, возможно, помните из школы. За пределами пост-советских стран такая типология, правда, не встречается.
Так вот — работа с информационными системами, это, конечно, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, но в современных реалиях это почти всегда ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА-ЧЕЛОВЕК. Вы через систему взаимодействуете с другими людьми опосредовано. Система может вам помогать это делать, а может мешать или диктовать свои способы взаимодействия, часто неестественные.
У Джоела Спольски, которого я считаю одним из лучших авторов по проектированию интерфейсов, есть книга: User Interface Design For Programmers, в русском переводе Руководство по UI дизайну для программистов (тут сразу pdf).
Это 2001 год, а примеры там вообще из 90-х. Но принципиально ничего не поменялось... в интерфейсах. А вот в проектировании поменялось — теперь мы почти всегда проектируем социальные системы. Джоел написал об этом в 2004: It’s Not Just Usability, перевод: Не юзабилити единым, а ещё раньше в 2003: Building Communities with Software, перевод не нашел.
Один из примеров — интерфейс Napster (если вы помните такое приложение, кхе-кхе). Интерфейс был ужасен. Программа работала только на Windows. Это было одно из самых популярных приложений в мире. В 2000 году Napster создавал от 40 до 60% трафика в частных сетях и в сетях университетов.
Если вы делаете то, что нужно людям — они будут мириться с любым интерфейсом. Сейчас, наверное, можно привести в пример красноглазые интерфейсы в области крипты.
Вывод: проектировать нужно не значки на экране, а взаимодействие между людьми. Что они делают друг для друга. Как они относятся друг к другу. Что нельзя делать по отношению друг к другу. Как сообща бороться с вредоносными участниками.
Есть масса приложений с красивыми интерфейсами, совершенно не учитывающими — как именно люди общаются и взаимодействуют в каком-то процессе. Школьные дневники. Запись ко врачу и хранение истории приемов. Социальные сети (нечеловеческий LinkedIn чего стоит!). Системы приема докладов на конференции. Системы управления задачами и документацией.
Джоел приводит в пример свой FogBugz — багтрекер, в котором люди действительно работали над исправлением дефектов, в отличие от других систем, которые "was never getting used, because it did not align with the way people wanted to work together" (кстати, не доверяйте переводам, там эта фраза переврана до противоположного смысла). Про FogBugz не знаю, не видел, а Trello, разработанная в той же компании, конечно, почти эталонная по интерфейсу легковесная система управления задачами.
Практически невозможно спроектировать хорошее социальное взаимодействие, если смотрите изнутри системы. Поэтому я считаю почти бесполезным описание вариантов использования в виде CRUDL вокруг сущности. Не поняв, в чем смысл каждой операции — в чем её социальный смысл! — вы не сможете определить функции и отсутствие функций, которые сформируют и определят нужное поведение.
В принципе, можно было бы отмахнуться от рассуждений какого-то там очередного программиста-предпринимателя. Ну он же не дизайнер и не психолог, что нам втирает. Если бы не одно "но": Джоел Спольски — создатель StackOverflow. Социального сервиса, который собрал крупнейшее сообщество разработчиков и в определенном смысле перевернул способ обучения програмиированию и разработки. Я бы прислушался.
👍22
Примеры социальных функций в приложениях и сложностей с ними:
1) геймификация. Вообще геймификация очень часто вовлекает нескольких пользователей — знакомых друг с другом или нет, и может очень легко привести к непредсказуемым последствиям.
В одну систему с электронными школьными дневниками хотели добавить элементы геймификации — с целью мотивировать школьников лучше учиться. Вот только кем становится система после этого? Не берет ли она на себя функции учителя? Что делать учителю, как работать параллельно с "электронным учителем"?
Если в качестве геймификации используется соревновательность — допустимо ли это, и не вызовет ли нездоровой конкуренции в классе? Может ли учитель отключить геймификацию для своих классов? И что будет, если учитель по одному предмету включит, а по другому — выключит? Или включать/выключать нужно во всей школе? В общем, вопросов было больше, чем ответов, и геймификацию так и не запустили.
Потому что система изначально была про коммуникацию учителя с учениками и родителями — практически, аватар учителя, а когда в ней появилась функция, не представляющая учителя/школу, а представляющая кого-то третьего — кого-то, кто развлекает и играет со школьниками, а не все учителя согласны с таким представлением.
2) баны. В одном сообществе были личные баны — один пользователь мог забанить другого и не видеть его постов и комментариев. В какой-то момент забаненному перестали показывать комментарии забанившего, а стали показывать плейсхолдер <здесь комментарий от пользователя, который вас забанил>. Что тут началось! Люди обнаружили, что кем-то забанены, начинают выяснять — кем? Кто меня забанил? Ах, этот! Вот ведь гад!
Сообщество бурлит, число взаимных банов (в ответ) растёт, связность падает, кто-то решил вообще удалиться... А всего-то маленькая функция!
Джоел упоминает множество non-features, функций, которых нет в продукте. Для аналитика это очень странно — некоторые стандарты даже напрямую запрещают писать "отрицательные требования" — чего не должно быть в системе. А вот с точки зрения требований к социальной системе это может быть критически важно!
1) геймификация. Вообще геймификация очень часто вовлекает нескольких пользователей — знакомых друг с другом или нет, и может очень легко привести к непредсказуемым последствиям.
В одну систему с электронными школьными дневниками хотели добавить элементы геймификации — с целью мотивировать школьников лучше учиться. Вот только кем становится система после этого? Не берет ли она на себя функции учителя? Что делать учителю, как работать параллельно с "электронным учителем"?
Если в качестве геймификации используется соревновательность — допустимо ли это, и не вызовет ли нездоровой конкуренции в классе? Может ли учитель отключить геймификацию для своих классов? И что будет, если учитель по одному предмету включит, а по другому — выключит? Или включать/выключать нужно во всей школе? В общем, вопросов было больше, чем ответов, и геймификацию так и не запустили.
Потому что система изначально была про коммуникацию учителя с учениками и родителями — практически, аватар учителя, а когда в ней появилась функция, не представляющая учителя/школу, а представляющая кого-то третьего — кого-то, кто развлекает и играет со школьниками, а не все учителя согласны с таким представлением.
2) баны. В одном сообществе были личные баны — один пользователь мог забанить другого и не видеть его постов и комментариев. В какой-то момент забаненному перестали показывать комментарии забанившего, а стали показывать плейсхолдер <здесь комментарий от пользователя, который вас забанил>. Что тут началось! Люди обнаружили, что кем-то забанены, начинают выяснять — кем? Кто меня забанил? Ах, этот! Вот ведь гад!
Сообщество бурлит, число взаимных банов (в ответ) растёт, связность падает, кто-то решил вообще удалиться... А всего-то маленькая функция!
Джоел упоминает множество non-features, функций, которых нет в продукте. Для аналитика это очень странно — некоторые стандарты даже напрямую запрещают писать "отрицательные требования" — чего не должно быть в системе. А вот с точки зрения требований к социальной системе это может быть критически важно!
👍20
Удивительные локальные понятия иногда рождаются в местной языковой среде. Вот, например, "техническое задание", "ТЗ" — документ, содержательных аналогов которому трудно найти где-то кроме стран бывш. СССР.
Или вот, например, "справочник" — применительно к типу таблиц в БД. С первого взгляда, вроде бы это dictionary, но есть нюансы. Во-первых, dictionary — это дословно "словарь", то есть хранилище пар "ключ":"значение". Во-вторых, это тип данных из языка Python, а не концепция из моделирования баз данных. В БД есть только entity/relation, иногда встречаются lookup tables или reference tables. Словосочетание database dictionary означает "словарь данных" — мета-описание структуры данных в БД.
У нас же смысл "справочника" варьируется:
➡️ от, действительно, "словаря" (как отраженного в таблице перечислимого типа, чисто для производительности и компактности: чтобы не хранить в таблицах типовые тексты, а хранить только их коды, вытаскивая тексты только для отображения пользователю) — по-английски это будет dictionary или reference table.
➡️ до обозначения вообще любой сущности: "справочник сотрудников", "справочник клиентов", "справочник товаров". Это по смыслу близко к "основным данным" (master data) — сущностям, которые описывают структуру бизнеса, в отличие от транзакционных данных, фиксирующих события или действия в рамках структуры.
В промежутке между словарями и основными данными могут лежать разнообразные виды данных, меняющихся с разной скоростью. Ну, скажем, валюты меняются редко, а сделки на Форексе совершаются ежедневно сотнями штук. А в другом бизнесе каждая сделка — это событие, потому что под неё заводится проект, и проект тоже считается справочником.
Из-за таких нечетких определений бывает трудно установить единый язык в команде, если люди пришли их разных компаний, где справочниками называли разное, и объяснить новичкам, что же такое, всё-таки, справочник?..
Очень путающая концепция, как по мне. Всегда нужно уточнять, в каком смысле мы это слово используем.
Или вот иногда говорят "справочники и классификаторы", имея в виду, что справочник может иметь множество полей (например, справочник адресов или справочник изделий, а классификатор — это справочник только с одним не-идентифицирующим полем, то есть словарь.
А ведь есть ещё НСИ — "нормативно-справочная информация" и управление ей (RDM, Reference Data Managemanet), и управление основными данными (MDM, Master Data Management). Причем русский термин "Управление НСИ" часто переводят как MDM, хотя DAMA-DMBOK (свод знаний по управлению данными) их явно различает — справочные данные всегда описывают другие данные, а основные данные описывают реальные объекты.
DAMA-DMBOK даже говорит, что цели управления НСИ и управления основными данными отличаются:
◀️ для основных данных это контроль идентификаторов и значений, решение вопросов идентификации ("это одна и та же сущность, или разные?")
◀️ для справочных данных — контроль допустимых множеств значений и их актуальности.
Соответственно, формулирование бизнес-правил часто сводится к проверкам допустимости различных сочетаний основных данных, справочных данных и транзакционных (примеры: "в женское купе может купить билет только пассажир женского пола", "в списке студентов курса представитель вуза может увидеть только контактные студентов из своего вуза").
В общем, рекомендую в своих проектах четко определить, что вы называете справочником; что у вас относится к основным данным и к транзакционным (если вы используете такие термины), и чем вы управляете, когда говорите об управлении НСИ и основными данными.
Или вот, например, "справочник" — применительно к типу таблиц в БД. С первого взгляда, вроде бы это dictionary, но есть нюансы. Во-первых, dictionary — это дословно "словарь", то есть хранилище пар "ключ":"значение". Во-вторых, это тип данных из языка Python, а не концепция из моделирования баз данных. В БД есть только entity/relation, иногда встречаются lookup tables или reference tables. Словосочетание database dictionary означает "словарь данных" — мета-описание структуры данных в БД.
У нас же смысл "справочника" варьируется:
В промежутке между словарями и основными данными могут лежать разнообразные виды данных, меняющихся с разной скоростью. Ну, скажем, валюты меняются редко, а сделки на Форексе совершаются ежедневно сотнями штук. А в другом бизнесе каждая сделка — это событие, потому что под неё заводится проект, и проект тоже считается справочником.
Из-за таких нечетких определений бывает трудно установить единый язык в команде, если люди пришли их разных компаний, где справочниками называли разное, и объяснить новичкам, что же такое, всё-таки, справочник?..
Очень путающая концепция, как по мне. Всегда нужно уточнять, в каком смысле мы это слово используем.
Или вот иногда говорят "справочники и классификаторы", имея в виду, что справочник может иметь множество полей (например, справочник адресов или справочник изделий, а классификатор — это справочник только с одним не-идентифицирующим полем, то есть словарь.
А ведь есть ещё НСИ — "нормативно-справочная информация" и управление ей (RDM, Reference Data Managemanet), и управление основными данными (MDM, Master Data Management). Причем русский термин "Управление НСИ" часто переводят как MDM, хотя DAMA-DMBOK (свод знаний по управлению данными) их явно различает — справочные данные всегда описывают другие данные, а основные данные описывают реальные объекты.
DAMA-DMBOK даже говорит, что цели управления НСИ и управления основными данными отличаются:
Соответственно, формулирование бизнес-правил часто сводится к проверкам допустимости различных сочетаний основных данных, справочных данных и транзакционных (примеры: "в женское купе может купить билет только пассажир женского пола", "в списке студентов курса представитель вуза может увидеть только контактные студентов из своего вуза").
В общем, рекомендую в своих проектах четко определить, что вы называете справочником; что у вас относится к основным данным и к транзакционным (если вы используете такие термины), и чем вы управляете, когда говорите об управлении НСИ и основными данными.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤6👏1
Наткнулся на интересный набор паттернов обмена сообщениями от Microsoft Azure. Так как это паттерны, реализовать их можно на любых технологиях.
Так сказать, следующий уровень проектирования интеграций, когда вы уже уверенно владеете нюансами REST и представляете, как работают очереди и брокеры, и готовы принимать более тонкие архитектурные решения.
Всего там 42 паттерна, они достаточно произвольно объединены в три категории:
— управление данными,
— архитектура и реализация
— обмен сообщениями.
Это "китайская классификация" по Борхесу; мне, например, сложно понять, почему CQRS — это "архитектура", а хореография — "обмен сообщениями". В любом случае, паттерны интересные, а ещё есть анти-паттерны, как делать не надо — тоже полезно знать при проектировании решения; и архитектурные принципы. Повторюсь, что это довольно общие вещи, относящиеся не только к продуктам на основе Azure — они в том или ином виде реализованы и в AWS, и в других системах.
Все паттерны имеет смысл изучить, если вы собираетесь расти в архитекторы, или хотя бы хотите понимать, о чём они говорят. Но некоторые, связанные с интеграциями и API, встречаются и при проработке решений аналитиками, даже без всяких архитектурных глубин. Я вытащил три штуки, с которыми сталкивался недавно сам или к которым мы приходили с моими менти.
Итак, паттерны:
* Асинхронный запрос-ответ.
В общем, простая идея про запросы, длительность обработки которых на сервере может занять больше, чем 100 мс, а очереди/брокера у вас нет или вы не хотите их использовать — и вы используете поллинг. Первым запросом запускаете процесс на сервере, а сервер возвращает 202 (Accepted) и ссылку, которую нужно поллить. Клиент регулярно ходит по этой ссылке и проверяет — выполнился ли запрос. Пока он не выполнен — сервер возвращает 200 (OK). Когда результат готов — 302 (Found) и переадресует на место, где лежит результат.
Как вариант, тут можно было бы использовать WebHook, но далеко не все клиенты поддерживают вызовы к ним — технически или по соображениям безопасности.
* Квитанция (claim-check).
Если вы собираетесь передавать большой объем данных, имеет смысл не загружать систему передачи (например, брокера или очередь), а выслать "квитанцию" с токеном, по которому клиент сможет забрать ответ из хранилища статических данных. Также паттерн можно использовать, когда нужна дополнительная защита, чтобы чувствительные данные не проходили через брокер/очередь/прокси и т.п. Ну и в принципе неплохо бы защищать статику каким-нибудь токеном, чтобы не было ситуаций с утечкой документов, доступных по прямым адресам без всякой проверки — про это следующий паттерн.
* Valet Key — не знаю, как перевести на русский, видел автоматический перевод "ключ камердинера", но не встречал такого употребления в живой среде. Это как раз токен из предыдущего паттерна: когда вы получаете статический ресурс, если он не должен быть общедоступным — защищайте его токеном. То есть, клиент сначала запрашивает ресурс у приложения, приложение отдает ссылку на ресурс + токен (либо токен зашит прямо в URL), и передает токен хранилищу. Хранилище обрабатывает запрос к ресурсу только с токеном — так гарантируется, что запросивший клиент — именно тот, кому выдали разрешение, а ещё можно ограничить действие токена по времени.
Этот паттерн также описан в книге O'Reilly 'Cloud Architecture Patterns' — хотя остальные паттерны в ней в основном низкоуровневые.
Где можно использовать эти паттерны? Например, при запросе большого отчета, который относительно долго формируется. "Заказать" формирование мы можем через асинхронный запрос и поллинг, либо через очередь запросов, потом получим "квитанцию" с токеном доступа, а сам сформированный отчет ляжет в файловое хранилище. Файловое хранилище отдаст готовый отчет только клиенту, предъявившему квитанцию с токеном. Про истечении времени жизни токена отчет будет удален.
Так сказать, следующий уровень проектирования интеграций, когда вы уже уверенно владеете нюансами REST и представляете, как работают очереди и брокеры, и готовы принимать более тонкие архитектурные решения.
Всего там 42 паттерна, они достаточно произвольно объединены в три категории:
— управление данными,
— архитектура и реализация
— обмен сообщениями.
Это "китайская классификация" по Борхесу; мне, например, сложно понять, почему CQRS — это "архитектура", а хореография — "обмен сообщениями". В любом случае, паттерны интересные, а ещё есть анти-паттерны, как делать не надо — тоже полезно знать при проектировании решения; и архитектурные принципы. Повторюсь, что это довольно общие вещи, относящиеся не только к продуктам на основе Azure — они в том или ином виде реализованы и в AWS, и в других системах.
Все паттерны имеет смысл изучить, если вы собираетесь расти в архитекторы, или хотя бы хотите понимать, о чём они говорят. Но некоторые, связанные с интеграциями и API, встречаются и при проработке решений аналитиками, даже без всяких архитектурных глубин. Я вытащил три штуки, с которыми сталкивался недавно сам или к которым мы приходили с моими менти.
Итак, паттерны:
* Асинхронный запрос-ответ.
В общем, простая идея про запросы, длительность обработки которых на сервере может занять больше, чем 100 мс, а очереди/брокера у вас нет или вы не хотите их использовать — и вы используете поллинг. Первым запросом запускаете процесс на сервере, а сервер возвращает 202 (Accepted) и ссылку, которую нужно поллить. Клиент регулярно ходит по этой ссылке и проверяет — выполнился ли запрос. Пока он не выполнен — сервер возвращает 200 (OK). Когда результат готов — 302 (Found) и переадресует на место, где лежит результат.
Как вариант, тут можно было бы использовать WebHook, но далеко не все клиенты поддерживают вызовы к ним — технически или по соображениям безопасности.
* Квитанция (claim-check).
Если вы собираетесь передавать большой объем данных, имеет смысл не загружать систему передачи (например, брокера или очередь), а выслать "квитанцию" с токеном, по которому клиент сможет забрать ответ из хранилища статических данных. Также паттерн можно использовать, когда нужна дополнительная защита, чтобы чувствительные данные не проходили через брокер/очередь/прокси и т.п. Ну и в принципе неплохо бы защищать статику каким-нибудь токеном, чтобы не было ситуаций с утечкой документов, доступных по прямым адресам без всякой проверки — про это следующий паттерн.
* Valet Key — не знаю, как перевести на русский, видел автоматический перевод "ключ камердинера", но не встречал такого употребления в живой среде. Это как раз токен из предыдущего паттерна: когда вы получаете статический ресурс, если он не должен быть общедоступным — защищайте его токеном. То есть, клиент сначала запрашивает ресурс у приложения, приложение отдает ссылку на ресурс + токен (либо токен зашит прямо в URL), и передает токен хранилищу. Хранилище обрабатывает запрос к ресурсу только с токеном — так гарантируется, что запросивший клиент — именно тот, кому выдали разрешение, а ещё можно ограничить действие токена по времени.
Этот паттерн также описан в книге O'Reilly 'Cloud Architecture Patterns' — хотя остальные паттерны в ней в основном низкоуровневые.
Где можно использовать эти паттерны? Например, при запросе большого отчета, который относительно долго формируется. "Заказать" формирование мы можем через асинхронный запрос и поллинг, либо через очередь запросов, потом получим "квитанцию" с токеном доступа, а сам сформированный отчет ляжет в файловое хранилище. Файловое хранилище отдаст готовый отчет только клиенту, предъявившему квитанцию с токеном. Про истечении времени жизни токена отчет будет удален.
👍21❤6
UML умер, но никто этого не заметил?
Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.
Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)
Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.
Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.
Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".
Интересными мне показались два поинта в статье:
1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.
2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.
Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.
В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.
UML каждая команда может использовать внутри себя, если захочет. А может использовать любой другой способ записи идей на салфетках, главное, чтобы работало.
А вы применяете UML? Насколько часто, и что именно из него?
Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.
Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)
Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.
Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.
Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".
Интересными мне показались два поинта в статье:
1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.
2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.
Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.
В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.
UML каждая команда может использовать внутри себя, если захочет. А может использовать любой другой способ записи идей на салфетках, главное, чтобы работало.
А вы применяете UML? Насколько часто, и что именно из него?
👍43🤔23❤7😢2💩2
Пост про "смерть UML" оказался очень неоднозначным и спорным. Поэтому я бы хотел провести опрос, чтобы иметь какие-то количественные оценки. В 2014 году исследователи из Трирского университета проводили опрос про использование диаграмм, эскизов и набросков при разработке и проектировании ПО в Германии и США. Я взял их опросник и перевел на русский: https://forms.gle/zU7PncWsWc9u3cXZ6
Я был бы вам очень благодарен, если бы вы прошли его. Это займет буквально 5-7 минут. В опросе у германских исследователей приняло участие 350 респондентов, и я надеюсь, мы сможем собрать не меньшее по мощности исследование. В результате мы точно узнаем — кто и как использует диаграммы при разработке ПО.
Если у вас есть возможность — отправьте опросник своим коллегам и знакомым, в том числе программистам; так мы обеспечим представительство большего числа профессий в ИТ. Результаты опубликую в канале. И тогда мы узнаем — кто, где и как использует диаграммы и UML!
Я был бы вам очень благодарен, если бы вы прошли его. Это займет буквально 5-7 минут. В опросе у германских исследователей приняло участие 350 респондентов, и я надеюсь, мы сможем собрать не меньшее по мощности исследование. В результате мы точно узнаем — кто и как использует диаграммы при разработке ПО.
Если у вас есть возможность — отправьте опросник своим коллегам и знакомым, в том числе программистам; так мы обеспечим представительство большего числа профессий в ИТ. Результаты опубликую в канале. И тогда мы узнаем — кто, где и как использует диаграммы и UML!
👌16👍4🔥3
Промежуточные итоги по опросу:
164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.
Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)
Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%
Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования
Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию
Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.
Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).
Корреляции показателей пока не считал, там должно быть интересно.
Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!
В общем, что хочу сказать — пока каких-то крупных инсайтов нет, но что бы я выделил:
⭐️ Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет. Такие дела.
⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.
⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.
⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?
В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."
Статья классная, попробую перевести её, как будет время.
А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.
164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.
Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)
Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%
Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования
Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию
Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.
Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).
Корреляции показателей пока не считал, там должно быть интересно.
Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!
В общем, что хочу сказать — пока каких-то крупных инсайтов нет, но что бы я выделил:
⭐️ Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет. Такие дела.
⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.
⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.
⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?
В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."
Статья классная, попробую перевести её, как будет время.
А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.
👍34❤13🔥4
Всем привет! Осталось 11 дней, чтобы подать доклад на конференцию Flow 2024 Autumn (дедлайн 1 июня). Сама конференция будет 17 сентября онлайн и 24-25 сентября оффлайн, в этом году в Санкт-Петербурге.
Я там член ПК, с удовольствием рассмотрю заявку и помогу с докладом.
Конференция, в отличие от других по системному анализу, с большим уклоном в архитектуру и хардкорные темы. Что интересно:
➡️ Всё про требования (в т.ч. инструменты, подходы, стандарты)
➡️ Всё про интеграцию
➡️ Бизнес и продуктовый анализ
➡️ Данные
➡️ Архитектура (DDD, микросервисы и всякое такое)
➡️ Всё остальное (в т.ч. импортозамещение, low-code, организация работы аналитиков)
Присоединяйтесь!
Я там член ПК, с удовольствием рассмотрю заявку и помогу с докладом.
Конференция, в отличие от других по системному анализу, с большим уклоном в архитектуру и хардкорные темы. Что интересно:
Присоединяйтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
Flow 2025 Autumn. Конференция по системному и бизнес-анализу
Flow 2025 Autumn | Подача заявки на доклад | Конференция по системному и бизнес анализу
Всё о том, как стать спикером Flow 2025 Autumn: как подать заявку, как выбрать тему, какие доклады подойдут, как выглядит процесс рассмотрения
👍3🔥2
Потерянное звено в UML.
Две вещи в UML всегда вызывали у меня вопросы:
1. Разрыв между диаграммой вариантов использования и более детальным дизайном. Use Case Diagram показывает названия вариантов использования, а где же их сценарии? Диаграмма последовательности помогает не всегда — она сфокусирована на передаче сообщений, и не показывает внутреннюю работу. А также не всегда сценарий юскейса линейный.
2. Необычные значки на диаграмме последовательности. Вот эти кружочки: boundary, control, entity — что это такое? Они больше нигде в UML не используются.
Оказывается, ответ на это один — Robustness Diagram! (диаграмма устойчивости) Вот она, на картинке. Она раскрывает сценарий отдельного юскейса. Куда пользователь обращается (с каким экраном и элементом интерфейса он взаимодействует), как система это обрабатывает (осуществляет проверки, выполняет команду или целую транзакцию), какие данные при этом использует или создает.
При этом соблюдаются следующие правила:
* Actor может взаимодействовать только с boundary (интерфейсом)
* Boundary взаимодействует только с актором и контроллером, но не с данными напрямую
* Контроллеры связывают boundary с данными, и могут общаться друг с другом (тут можно показать микросервисы)
* Entity взаимодействует только с контроллером
Знакомая раскладка? Похоже на паттерн MVC. Но из без него можно использовать, просто для проверки, что у нас есть интерфейс под каждую задачу, есть бизнес-логика и у нас есть все данные, которые нужны для выполнения юскейса. Поэтому это и диаграмма устойчивости — позволяет проверить, что всё на месте и ничего не забыли.
На сайте Аджайл-моделирования диаграмму хвалят, и добавляют, что на неё стоит вынести также вещи, понятные бизнес-заказчикам:
* Отчеты (это тоже Boundary)
* По контроллеру на каждое бизнес-правило
* Каждая бизнес-сущность зафиксирована как entity
* Контроллер, который управляет всем юскейсом в целом
Диаграмма не вошла в стандарт UML, но набросать дизайн реализации юскейса в этой нотации довольно удобно.
(Картинки отсюда)
Две вещи в UML всегда вызывали у меня вопросы:
1. Разрыв между диаграммой вариантов использования и более детальным дизайном. Use Case Diagram показывает названия вариантов использования, а где же их сценарии? Диаграмма последовательности помогает не всегда — она сфокусирована на передаче сообщений, и не показывает внутреннюю работу. А также не всегда сценарий юскейса линейный.
2. Необычные значки на диаграмме последовательности. Вот эти кружочки: boundary, control, entity — что это такое? Они больше нигде в UML не используются.
Оказывается, ответ на это один — Robustness Diagram! (диаграмма устойчивости) Вот она, на картинке. Она раскрывает сценарий отдельного юскейса. Куда пользователь обращается (с каким экраном и элементом интерфейса он взаимодействует), как система это обрабатывает (осуществляет проверки, выполняет команду или целую транзакцию), какие данные при этом использует или создает.
При этом соблюдаются следующие правила:
* Actor может взаимодействовать только с boundary (интерфейсом)
* Boundary взаимодействует только с актором и контроллером, но не с данными напрямую
* Контроллеры связывают boundary с данными, и могут общаться друг с другом (тут можно показать микросервисы)
* Entity взаимодействует только с контроллером
Знакомая раскладка? Похоже на паттерн MVC. Но из без него можно использовать, просто для проверки, что у нас есть интерфейс под каждую задачу, есть бизнес-логика и у нас есть все данные, которые нужны для выполнения юскейса. Поэтому это и диаграмма устойчивости — позволяет проверить, что всё на месте и ничего не забыли.
На сайте Аджайл-моделирования диаграмму хвалят, и добавляют, что на неё стоит вынести также вещи, понятные бизнес-заказчикам:
* Отчеты (это тоже Boundary)
* По контроллеру на каждое бизнес-правило
* Каждая бизнес-сущность зафиксирована как entity
* Контроллер, который управляет всем юскейсом в целом
Диаграмма не вошла в стандарт UML, но набросать дизайн реализации юскейса в этой нотации довольно удобно.
(Картинки отсюда)
👍26🤔6✍2❤2
Хм. Почему-то отвалился чат. Если хотите обсудить диаграмму робастности — комментируйте это сообщение.
Что я делаю с ChatGPT прямо сейчас (и это выглядит как чертова магия!)
В ChatGPT теперь можно вставлять файлы и скриншоты. И если вставить скриншот таблицы, то можно попросить сделать SQL-стейтмент для создания этой таблицы в БД, и INSERT INTO со всеми значениями из таблицы!!!1
Скреппинг данных никогда не был таким простым.
Upd: это мне в бесплатный аккаунт раскатили модель 4o, возможно, вы про неё слышали. Это сейчас самый топ, она по всем показателям пока впереди других LLM.
В ChatGPT теперь можно вставлять файлы и скриншоты. И если вставить скриншот таблицы, то можно попросить сделать SQL-стейтмент для создания этой таблицы в БД, и INSERT INTO со всеми значениями из таблицы!!!1
Скреппинг данных никогда не был таким простым.
Upd: это мне в бесплатный аккаунт раскатили модель 4o, возможно, вы про неё слышали. Это сейчас самый топ, она по всем показателям пока впереди других LLM.
🔥37👍7
Как правильно отмечают в комментариях к посту про Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram.
Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже.
Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро.
Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность:
1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов;
2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости;
3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов.
Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь.
Не знаю, как вас, а меня так ещё учили в институте, хотя в любой практической задаче было очевидно, что такой подход плохо работает. Якобсон одним из первых показал, что идти нужно от задач пользователя, а классы нужно делать такие, какие удобно, а не только как отражение сущностей реального мира.
Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах.
Вот, например, идея с разбиением архитектуры на элементы с разной скоростью изменения. Что-то может меняться, что-то остаётся. Это и обеспечивает устойчивость, робастность.
Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований!
Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.
Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже.
Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро.
Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность:
1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов;
2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости;
3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов.
Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь.
Не знаю, как вас, а меня так ещё учили в институте, хотя в любой практической задаче было очевидно, что такой подход плохо работает. Якобсон одним из первых показал, что идти нужно от задач пользователя, а классы нужно делать такие, какие удобно, а не только как отражение сущностей реального мира.
Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах.
Вот, например, идея с разбиением архитектуры на элементы с разной скоростью изменения. Что-то может меняться, что-то остаётся. Это и обеспечивает устойчивость, робастность.
Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований!
Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.
👍6🔥5🤔2