Одним из самых главных инсайтов Flow для меня стало вот это разделение нотации и метода. Часто их не разделяют, и от этого много путаницы.
Вот смотрите:
UML — это нотация. Booch, OMT, OOSE, Iconix (и даже C4!) — методы применения этой нотации.
IDEF0 — это метод. Так и называется: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ", есть рекомендации по стандартизации Р 50.1.028-2001.
BPMN — нотация. Есть книга Брюса Сильвера 'BPMN Method and Style' (https://methodandstyle.com/books/bpmn-method-and-style/), вот в ней предложен метод создания BPMN-дигарамм.
DFD — нотация, а структурный анализ — набор методов.
DDD — набор идей и паттернов, Event Storming — метод.
Agile — декларация ценностей, SCRUM и SAFe — методы ведения деятельности по разработке ПО.
ГОСТ 34 — описание содержания документов, "Руководство по написанию требований INCOSE" — метод.
REST — набор принципов, OpenAPI — язык описаний API, 'Design and Build Great Web APIs' Майка Амундсена — метод их проектирования.
User Story — формат фиксации требований, а Impact mapping и User Story Mapping — методы работы с ними. А JTBD, например, не просто формат записи, но ещё и имеет некоторые элементы метода.
И так во всём. Если вы изучите нотацию или язык, но не изучите метод — вы не будете знать, что и как делать. И ценность, например, наших курсов в том, что мы не рассказываем о технологиях и нотациях, а даем метод их применения. Изучать нужно методы, и на собеседованиях спрашивать о методах работы!
Вот смотрите:
UML — это нотация. Booch, OMT, OOSE, Iconix (и даже C4!) — методы применения этой нотации.
IDEF0 — это метод. Так и называется: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ", есть рекомендации по стандартизации Р 50.1.028-2001.
BPMN — нотация. Есть книга Брюса Сильвера 'BPMN Method and Style' (https://methodandstyle.com/books/bpmn-method-and-style/), вот в ней предложен метод создания BPMN-дигарамм.
DFD — нотация, а структурный анализ — набор методов.
DDD — набор идей и паттернов, Event Storming — метод.
Agile — декларация ценностей, SCRUM и SAFe — методы ведения деятельности по разработке ПО.
ГОСТ 34 — описание содержания документов, "Руководство по написанию требований INCOSE" — метод.
REST — набор принципов, OpenAPI — язык описаний API, 'Design and Build Great Web APIs' Майка Амундсена — метод их проектирования.
User Story — формат фиксации требований, а Impact mapping и User Story Mapping — методы работы с ними. А JTBD, например, не просто формат записи, но ещё и имеет некоторые элементы метода.
И так во всём. Если вы изучите нотацию или язык, но не изучите метод — вы не будете знать, что и как делать. И ценность, например, наших курсов в том, что мы не рассказываем о технологиях и нотациях, а даем метод их применения. Изучать нужно методы, и на собеседованиях спрашивать о методах работы!
👍41🔥24👎2👌1
Kupriyanov_flow_UML.pdf
9.6 MB
Публикую презентацию с Flow про UML. Нужно тему сворачивать, а то уже, говорят, приклеилась слава, что "Куприянов всем говорит, что UML умер". Так вот — UML жив, и неплохо себя чувствует. Прямо по Жванецкому: "И что смешно — министр мясной и молочной промышленности есть и очень хорошо выглядит". Или как в "Кин-дза-дзе": "Побойся неба! ПЖ жив! И я счастлив!" (да, я бумер, и мемы у меня бумерские).
Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы:
80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы.
84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют.
Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики.
Разработчики меньше всего пользуются UML. Архитекторы — и так, и так. Аналитики — скорее будут рисовать UML, а не что-то другое. С разработчиками есть и ещё одна проблема — они даже говорить о UML не хотят, так что сложно было найти респондентов.
Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%.
Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется.
Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации.
К диаграммам: создают часто (в этот день, на днях, в течение этого месяца...), меняют тоже часто, почти все диаграммы сохраняют ("это часть документации!"). В основном рисуют, чтобы зафиксировать требования или презентовать решение/архитектуру.
Соответственно, на диаграмме будет архитектура или схема интеграции.
Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую.
Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже.
Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная).
Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало.
Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.
Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы:
80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы.
84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют.
Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики.
Разработчики меньше всего пользуются UML. Архитекторы — и так, и так. Аналитики — скорее будут рисовать UML, а не что-то другое. С разработчиками есть и ещё одна проблема — они даже говорить о UML не хотят, так что сложно было найти респондентов.
Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%.
Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется.
Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации.
К диаграммам: создают часто (в этот день, на днях, в течение этого месяца...), меняют тоже часто, почти все диаграммы сохраняют ("это часть документации!"). В основном рисуют, чтобы зафиксировать требования или презентовать решение/архитектуру.
Соответственно, на диаграмме будет архитектура или схема интеграции.
Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую.
Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже.
Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная).
Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало.
Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.
👍25🏆11❤5🔥2
Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉).
Вот смотрите:
Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.
Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.
После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.
После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов.
Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)
И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.
Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно).
Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает:
— А вот у вас герой выходит из здания, а сумка при нём?
— Какая сумка?
— Ну, две сцены назад у него была кожаная сумка, она сейчас с ним?
Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5.
Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду.
Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое.
И сценарист начинает переделывать или уточнять сценарий после всех замечаний.
Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!
Вот смотрите:
Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.
Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.
После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.
После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов.
Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)
И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.
Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно).
Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает:
— А вот у вас герой выходит из здания, а сумка при нём?
— Какая сумка?
— Ну, две сцены назад у него была кожаная сумка, она сейчас с ним?
Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5.
Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду.
Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое.
И сценарист начинает переделывать или уточнять сценарий после всех замечаний.
Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!
🔥59❤🔥9❤6👍2🤔1
Про концепции продуктов. Для кино есть логлайн, для [ИТ-]продуктов есть формула, в которой отражены примерно похожие вещи.
Состав концепции:
* описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний.
* задача, которую решают эти люди — чего они хотят или что им нужно делать по работе.
* препятствие — что мешает им выполнять эту задачу
* что мы для них делаем (какую систему создаем)
* как они будут решать свою проблему, когда система будет готова
* за счет чего проблема будет решена? (какое ключевое свойство нашего решения)
Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш.
В виде формулы это выглядит так:
Примеры:
"Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения".
Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября.
Давайте посмотрим пример ИТ-систем:
"Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся".
"Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта."
"Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе."
Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой:
"Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость"
Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров).
Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать.
Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).
Состав концепции:
* описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний.
* задача, которую решают эти люди — чего они хотят или что им нужно делать по работе.
* препятствие — что мешает им выполнять эту задачу
* что мы для них делаем (какую систему создаем)
* как они будут решать свою проблему, когда система будет готова
* за счет чего проблема будет решена? (какое ключевое свойство нашего решения)
Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш.
В виде формулы это выглядит так:
Для <описание аудитории>, которые хотят <описание задачи>, но не могут, потому что <описание препятствия>, мы делаем <тип решения>, которое поможет им <описание решения проблемы>, за счет того, что <ключевое свойство решения>.
Примеры:
"Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения".
Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября.
Давайте посмотрим пример ИТ-систем:
"Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся".
"Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта."
"Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе."
Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой:
"Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость"
Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров).
Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать.
Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).
👍19❤7🔥6
Написал супер-краткий конспект книги Вигерса. А то тут ходит конспект на 70 страниц, и люди просят краткое изложение краткого конспекта. Итак, специально для тех, у кого нет времени читать ни 700, ни 70 страниц, циничный конспект:
Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:
Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.
Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:
Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно.
Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.
Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.
* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.
Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.
* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.
ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.
Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.
Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.
Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты.
Вот и всё, не благодарите.
(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)
Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:
Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации.
Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.
Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:
В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.
Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно.
Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.
Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.
* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.
Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.
* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.
ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.
Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.
Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.
Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты.
Вот и всё, не благодарите.
(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)
😁71🔥27👍22❤6👎3
Я знаю, что дошучивать не хорошо, но вчера в пост всё не уместилось — ещё в книге Вигерса есть части, которые будут полезны для лидов или тех, кто хочет им стать.
Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так.
Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе:
Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса. Ну допустим.
Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований. Уже рыдаю.
Обязанность №3. Точно и конкретно описать требования к системе. Началась бульварная фантастика.
Обязанность №4. По запросу принимать своевременные решения относительно требований. Фантастика продолжается.
Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований. Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости.
Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера.
Обязанность №7. Проверять требования и оценивать прототипы. Покажите финальный дизайн.
Обязанность №8. Определить критерии приемки. Вот увижу, тогда скажу — то или не то.
Обязанность №9. Своевременно сообщать об изменениях требований.😭
Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5.
До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования. Вот в это охотно верю.
Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните:
"Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше».
Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее!
Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно.
Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски.
Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений.
Тут уже и сам Вигерс шутит:
* не откусывайте кусок, который не сможете прожевать
* получайте максимум удовольствия от малых побед (больших побед у вас будет немного)
* давите мягко, но постоянно
* концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз).
* ищите союзников (растите их; благодарите их; награждайте их)
А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?)
Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории:
* сделали не то, что нужно
* не сделали то, что нужно
Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!
Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так.
Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе:
Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса. Ну допустим.
Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований. Уже рыдаю.
Обязанность №3. Точно и конкретно описать требования к системе. Началась бульварная фантастика.
Обязанность №4. По запросу принимать своевременные решения относительно требований. Фантастика продолжается.
Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований. Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости.
Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера.
Обязанность №7. Проверять требования и оценивать прототипы. Покажите финальный дизайн.
Обязанность №8. Определить критерии приемки. Вот увижу, тогда скажу — то или не то.
Обязанность №9. Своевременно сообщать об изменениях требований.
Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5.
До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования. Вот в это охотно верю.
Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните:
Оба описанных подхода игнорируют реальность, которая такова, что на ранних этапах работы над проектом нельзя знать абсолютно всех требований и со временем они неизбежно меняются.
"Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше».
Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее!
Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно.
Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски.
Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений.
Тут уже и сам Вигерс шутит:
* не откусывайте кусок, который не сможете прожевать
* получайте максимум удовольствия от малых побед (больших побед у вас будет немного)
* давите мягко, но постоянно
* концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз).
* ищите союзников (растите их; благодарите их; награждайте их)
А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?)
Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории:
* сделали не то, что нужно
* не сделали то, что нужно
Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤30🔥22😁11👍7
Мы уверено преодолели отметку в 7000 подписчиков! Спасибо вам! 🙏🙏🙏Надеюсь и дальше вас радовать смешными и полезными постами.
А в комментах к этому посту предлагаю всем знакомиться, и написать — вдруг вам нужна какая-нибудь помощь? Может, вы ищете работу, или наоборот — нового коллегу, или совет, или ментора. Напишите! Нас тут много, возможно вам помогут!
Ну и, как я знаю, у многих из вас есть свои каналы — напишите про них, а я потом сделаю общий пост про ваши каналы — пусть у вас тоже будут новые подписчики!
А в комментах к этому посту предлагаю всем знакомиться, и написать — вдруг вам нужна какая-нибудь помощь? Может, вы ищете работу, или наоборот — нового коллегу, или совет, или ментора. Напишите! Нас тут много, возможно вам помогут!
Ну и, как я знаю, у многих из вас есть свои каналы — напишите про них, а я потом сделаю общий пост про ваши каналы — пусть у вас тоже будут новые подписчики!
1👍37🔥6🙏2🎃1🦄1
Главная проблема у Вигерса — это, конечно, полное отсутствие хоть каких-нибудь слов о проектировании API.
Абсолютно ничего. Хотя вся база для проектирования есть, и главное — это диаграммы. DFD в главе 12 (стр. 269) и, ещё лучше — Карта диалоговых окон на стр. 280 (напоминаю, что я даю страницы по изданию BHV 2013 г.).
Я такую диаграмму на тренингах обычно называю "схема навигации". Это очень простая диаграмма: прямоугольники — отдельные экраны (или разные состояния одного экрана), а стрелки — переходы с одного экрана к другому. Это очень мощный инструмент, необходимый и для проектирования интерфейсов, и для создания API. С точки зрения интерфейсов мы проверяем все варианты использования — буквально задавая вопрос "а на каком экране происходит этот шаг сценария?" (конечно, нас интересуют шаги, где пользователь вводит данные или дает команду, и те, где система запрашивает пользователя, предлагает выбор, предоставляет информацию или оповещает пользователя о чем-то).
Эта же диаграмма в какой-то мере повторяет диаграмму состояний — если у вас изменилось состояние ключевого объекта, то, скорее всего, это изменение инициировано действиями в интерфейсе (мы можем проверить полноту требований через проверку наличия требований/сценариев для всех переходов на диаграмме состояний). Тут же можно задать вопросы про обратные действия и возвраты — на диаграмме они будут видны особенно ясно: если у вас есть тупик, экран только с входящими переходами, это странно. Вы с него никуда не уйдете?
В общем, если к каждому экрану приписать состав данных, которые выводится на экране и которые вводятся, а также основное действие пользователя на этом экране и второстепенные — будет сразу понятно, как визуально выстроить экран, и дизайнер скажет вам спасибо!
Но эта же информация пригодится вам и для проектирования REST API! Именно REST, т.к. речь идёт о состоянии. Это распространенная ошибка — считать, что в REST нет состояния. Состояние клиента очень даже есть! (И это один из критериев, что вам подходит REST). Просто это состояние локализовано на клиенте, и не хранится на сервере (а только запрашиваются данные для смены состояния, Representational State Transfer). Вот ваша схема экранов и переходов как раз и является диаграммой возможных состояний клиента! И каждый переход — это вызов API. Нужно только к переходу дописать название эндпоинта, параметры и ответ. В таком виде диаграмма представлена в статье Майка Амундсена, про которую я уже писал, и которую, оказывается, давно перевел пользователь Andrei Gordienkov.
Тут может возникнуть вопрос — а если изменения происходят на сервере, и должны быть переданы на клиент? Во-первых, как это нарисовать? (Ну, тут я обычно рисую вместо экрана звездочку, и стрелку от неё к нужному экрану, где эти изменения должны быть отображены — состояние клиента изменилось). Во-вторых, что это за вызов? Очевидно, что это уже не REST, а нечто другое — Long Polling, WebHook, WebSockets, GraphQL или gRPC в режиме подписки/стриминга.
И всё, считайте, что эндпоинты API у вас уже готовы. Одновременно с дизайном.
Абсолютно ничего. Хотя вся база для проектирования есть, и главное — это диаграммы. DFD в главе 12 (стр. 269) и, ещё лучше — Карта диалоговых окон на стр. 280 (напоминаю, что я даю страницы по изданию BHV 2013 г.).
Я такую диаграмму на тренингах обычно называю "схема навигации". Это очень простая диаграмма: прямоугольники — отдельные экраны (или разные состояния одного экрана), а стрелки — переходы с одного экрана к другому. Это очень мощный инструмент, необходимый и для проектирования интерфейсов, и для создания API. С точки зрения интерфейсов мы проверяем все варианты использования — буквально задавая вопрос "а на каком экране происходит этот шаг сценария?" (конечно, нас интересуют шаги, где пользователь вводит данные или дает команду, и те, где система запрашивает пользователя, предлагает выбор, предоставляет информацию или оповещает пользователя о чем-то).
Эта же диаграмма в какой-то мере повторяет диаграмму состояний — если у вас изменилось состояние ключевого объекта, то, скорее всего, это изменение инициировано действиями в интерфейсе (мы можем проверить полноту требований через проверку наличия требований/сценариев для всех переходов на диаграмме состояний). Тут же можно задать вопросы про обратные действия и возвраты — на диаграмме они будут видны особенно ясно: если у вас есть тупик, экран только с входящими переходами, это странно. Вы с него никуда не уйдете?
В общем, если к каждому экрану приписать состав данных, которые выводится на экране и которые вводятся, а также основное действие пользователя на этом экране и второстепенные — будет сразу понятно, как визуально выстроить экран, и дизайнер скажет вам спасибо!
Но эта же информация пригодится вам и для проектирования REST API! Именно REST, т.к. речь идёт о состоянии. Это распространенная ошибка — считать, что в REST нет состояния. Состояние клиента очень даже есть! (И это один из критериев, что вам подходит REST). Просто это состояние локализовано на клиенте, и не хранится на сервере (а только запрашиваются данные для смены состояния, Representational State Transfer). Вот ваша схема экранов и переходов как раз и является диаграммой возможных состояний клиента! И каждый переход — это вызов API. Нужно только к переходу дописать название эндпоинта, параметры и ответ. В таком виде диаграмма представлена в статье Майка Амундсена, про которую я уже писал, и которую, оказывается, давно перевел пользователь Andrei Gordienkov.
Тут может возникнуть вопрос — а если изменения происходят на сервере, и должны быть переданы на клиент? Во-первых, как это нарисовать? (Ну, тут я обычно рисую вместо экрана звездочку, и стрелку от неё к нужному экрану, где эти изменения должны быть отображены — состояние клиента изменилось). Во-вторых, что это за вызов? Очевидно, что это уже не REST, а нечто другое — Long Polling, WebHook, WebSockets, GraphQL или gRPC в режиме подписки/стриминга.
И всё, считайте, что эндпоинты API у вас уже готовы. Одновременно с дизайном.
2👍26❤11🤔3🤡1
Сколько вы знаете способов передачи данных на клиент по инициативе сервера?
В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.
Я насчитал 6 (добавляйте, если знаете ещё):
1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.
2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.
3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.
4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).
5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.
6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.
Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.
На самом деле, внутри GraphQL либо WebSocket, либо multipart subnoscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).
А стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.
Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.
В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.
Я насчитал 6 (добавляйте, если знаете ещё):
1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.
2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.
3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.
4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).
5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.
6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.
Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.
На самом деле, внутри GraphQL либо WebSocket, либо multipart subnoscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).
А стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.
Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.
👍30❤13⚡4🙏1
Пришли дети, увидели открытый draw.io, ой, а что это за стикмены? Слово за слово, нарисовали диаграмму.
Вопросы:
— содержит ли эта диаграмма элементы UML?
— это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?)
— какой процесс тут, собственно, изображен?
Вопросы:
— содержит ли эта диаграмма элементы UML?
— это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?)
— какой процесс тут, собственно, изображен?
🤣105🔥5👍3
В этом году я пошел учиться — прямо по-настоящему, на 2.5 года, в магистратуру. Вот такой неожиданный поворот, хотя, как я вижу по окружению, пошли учиться многие. Коллективное помешательство — видимо, солнечная активность вызывает тягу к новым знаниям.
И вот что интересно: все практики и подходы, о которых мы говорили в 2010-2012 годах, которые развивали и проектировали — и тогда это был какой-то невероятный полуподпольный эксперимент — все вот они, в обычном вузовском образовании! Ну ладно, не совсем в обычном, из верхнего перцентиля, но — тут.
Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил).
Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее.
Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей)
И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой.
Управленцам — анализировать и оценивать ситуации, разрабатывать стратегии и планы по их реализации, программистам — проектировать и писать программы, архитекторам — обеспечивать развитие больших систем, аналитикам — выяснять детали и обозначать пространство возможных решений.
И если вместо того, чтобы что-то сделать, вам предлагают послушать, как что-то сделать — это не обучение, а ознакомление с материалом.
С другой стороны, без ознакомления тоже не обойтись. Можно сразу выдать задание, ничего особо не объясняя, а потом демонстративно сажать людей в лужу, отмечая недостатки результата. Некоторым ведущим это очень нравится, они называют такое действо "проблематизацией", или "приземлением", или даже "сбиванием короны" — то есть, демонстрацией человеку, что его предыдущие знания и навыки ни на что не годятся.
Подразумевается, что человек немедленно всё осознает, и дальше со всей внимательностью будет изучать то, что ему дальше расскажут и покажут.
На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно).
Часто говорят, что не хватило времени или не было чётко поставлено задание. В большинстве случаев это так и есть, и любимая фраза ведущих: "у вас никогда не будет хватать времени и вы никогда не получите точного задания". Это тоже отчасти правда, но уж очень напоминает газлайтинг.
Собственно, в этот момент вся ситуация становится токсичной — в большей или меньшей степени, планово или неосознанно, но токсичной. То есть, это манипуляция.
В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!)
Адепты такого подхода отвечают, что любое обучение — это манипуляция, имея в виду, в первую очередь, мотивацию у детей и подростков. Возможно это и так, но если мы говорим об обучении заинтересованных взрослых, то у них с мотивацией обычно всё в порядке — они же ещё и свои деньги вам принесли, какое ещё подтверждение мотивации вам нужно? (Если мы пытаемся учить взрослых насильно — тогда да, нужны специальные техники).
Другой вариант — такие манипуляции — часть культуры той среды, в которой обучающимся придётся потом работать, поэтому нужно научиться их распознавать и обрабатывать в безопасной ситуации. По моим наблюдениям, именно такая культурная среда у нас в госпроектах, и тут, наверное, такая подготовка оправдана.
Хотя, на мой взгляд, лучше бы образованию заняться изменением этой культуры, а не её трансляцией.
И вот что интересно: все практики и подходы, о которых мы говорили в 2010-2012 годах, которые развивали и проектировали — и тогда это был какой-то невероятный полуподпольный эксперимент — все вот они, в обычном вузовском образовании! Ну ладно, не совсем в обычном, из верхнего перцентиля, но — тут.
Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил).
Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее.
Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей)
И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой.
Управленцам — анализировать и оценивать ситуации, разрабатывать стратегии и планы по их реализации, программистам — проектировать и писать программы, архитекторам — обеспечивать развитие больших систем, аналитикам — выяснять детали и обозначать пространство возможных решений.
И если вместо того, чтобы что-то сделать, вам предлагают послушать, как что-то сделать — это не обучение, а ознакомление с материалом.
С другой стороны, без ознакомления тоже не обойтись. Можно сразу выдать задание, ничего особо не объясняя, а потом демонстративно сажать людей в лужу, отмечая недостатки результата. Некоторым ведущим это очень нравится, они называют такое действо "проблематизацией", или "приземлением", или даже "сбиванием короны" — то есть, демонстрацией человеку, что его предыдущие знания и навыки ни на что не годятся.
Подразумевается, что человек немедленно всё осознает, и дальше со всей внимательностью будет изучать то, что ему дальше расскажут и покажут.
На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно).
Часто говорят, что не хватило времени или не было чётко поставлено задание. В большинстве случаев это так и есть, и любимая фраза ведущих: "у вас никогда не будет хватать времени и вы никогда не получите точного задания". Это тоже отчасти правда, но уж очень напоминает газлайтинг.
Собственно, в этот момент вся ситуация становится токсичной — в большей или меньшей степени, планово или неосознанно, но токсичной. То есть, это манипуляция.
В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!)
Адепты такого подхода отвечают, что любое обучение — это манипуляция, имея в виду, в первую очередь, мотивацию у детей и подростков. Возможно это и так, но если мы говорим об обучении заинтересованных взрослых, то у них с мотивацией обычно всё в порядке — они же ещё и свои деньги вам принесли, какое ещё подтверждение мотивации вам нужно? (Если мы пытаемся учить взрослых насильно — тогда да, нужны специальные техники).
Другой вариант — такие манипуляции — часть культуры той среды, в которой обучающимся придётся потом работать, поэтому нужно научиться их распознавать и обрабатывать в безопасной ситуации. По моим наблюдениям, именно такая культурная среда у нас в госпроектах, и тут, наверное, такая подготовка оправдана.
Хотя, на мой взгляд, лучше бы образованию заняться изменением этой культуры, а не её трансляцией.
14👍23❤11🤔4💯3👎1
Я лично глубоко убежден, что обучение должно и может происходить в экологичной среде и без всяких манипуляций.
А с мотивацией можно работать отдельно, если это требуется.
К сожалению, эта часть технологий пока не дошла до учреждений высшего образования. Про экологичное и уважительное общение там ещё мало кто слышал — наоборот, хвалятся, чей профессор больше жестит, хамит и троллит.
Интересно здесь сравнить реакцию студентов в зависимости от возраста и области деятельности — я когда-то преподавал в департаменте медиа ВШЭ, куда обычно идут сразу после бакалавриата — то есть, молодые, просвещенные и эмансипированные люди, и вот там профессорам приходилось тяжело — с их пафосом, снобизмом и сексистскими шуточками старого образца.
Не знаю, как с этим обстоит сейчас дело в технических и итшных вузах, да и в компаниях, но, кажется, в нормальной компании и общение должно быть нормальным, а иначе бы все из них сбежали — при таком-то рынке кандидата!
Тут мне скажут, что давно я в крупных компаниях не работал, и компанию с нормальной культурой общения ещё поискать нужно. Напишите — как у вас, насколько экологичная атмосфера в этом плане?
Ну а для тех, кто организует, выбирает или проектирует обучение, повторю ещё раз:
1⃣ Освоение навыков происходит только в практической деятельности, соответствующей навыку (прохождение тестов учит проходить тесты, ну ещё способствует запоминанию, если вам это требуется).
2⃣ Манипуляции результатами через нарушения в организации деятельности (чрезмерное сокращение времени на задание, нечеткие инструкции или требования к результату, намеренный или случайный пропуск шагов при работе по методике) приводят не к обучению, а к отторжению (и иногда — к сплочению группы против ведущих, тоже результат).
3⃣ Уважительное общение и поддержка желательного поведения даёт при обучении гораздо больший эффект, чем выискивание и подчеркивание ошибок.
4⃣ Без лекционной части не обойтись, но старайтесь доносить одну сильную мысль за один смысловой блок — объем внимания человека ограничен.
5⃣ В практических заданиях сталкивайте человека со средой, фактами и логическими промахами, а не с мнением ведущего (особенно если это мнение выглядит как "к чему бы тут докопаться").
Так что спасибо этому обучению, я лучше стал понимать свои ценности и методы в обучении — на контрасте.
А с мотивацией можно работать отдельно, если это требуется.
К сожалению, эта часть технологий пока не дошла до учреждений высшего образования. Про экологичное и уважительное общение там ещё мало кто слышал — наоборот, хвалятся, чей профессор больше жестит, хамит и троллит.
Интересно здесь сравнить реакцию студентов в зависимости от возраста и области деятельности — я когда-то преподавал в департаменте медиа ВШЭ, куда обычно идут сразу после бакалавриата — то есть, молодые, просвещенные и эмансипированные люди, и вот там профессорам приходилось тяжело — с их пафосом, снобизмом и сексистскими шуточками старого образца.
Не знаю, как с этим обстоит сейчас дело в технических и итшных вузах, да и в компаниях, но, кажется, в нормальной компании и общение должно быть нормальным, а иначе бы все из них сбежали — при таком-то рынке кандидата!
Тут мне скажут, что давно я в крупных компаниях не работал, и компанию с нормальной культурой общения ещё поискать нужно. Напишите — как у вас, насколько экологичная атмосфера в этом плане?
Ну а для тех, кто организует, выбирает или проектирует обучение, повторю ещё раз:
1⃣ Освоение навыков происходит только в практической деятельности, соответствующей навыку (прохождение тестов учит проходить тесты, ну ещё способствует запоминанию, если вам это требуется).
2⃣ Манипуляции результатами через нарушения в организации деятельности (чрезмерное сокращение времени на задание, нечеткие инструкции или требования к результату, намеренный или случайный пропуск шагов при работе по методике) приводят не к обучению, а к отторжению (и иногда — к сплочению группы против ведущих, тоже результат).
3⃣ Уважительное общение и поддержка желательного поведения даёт при обучении гораздо больший эффект, чем выискивание и подчеркивание ошибок.
4⃣ Без лекционной части не обойтись, но старайтесь доносить одну сильную мысль за один смысловой блок — объем внимания человека ограничен.
5⃣ В практических заданиях сталкивайте человека со средой, фактами и логическими промахами, а не с мнением ведущего (особенно если это мнение выглядит как "к чему бы тут докопаться").
Так что спасибо этому обучению, я лучше стал понимать свои ценности и методы в обучении — на контрасте.
27❤31👍17👎5🤔4💯1
Опять дискуссии в разных группах подкидывают темы для постов. Вот, например, конференции. Многие пишут, что не видят смысла, что дорого, и при этом особо ничего нового, и ничему не научишься за эти деньги.
Мне кажется (как члену ПК нескольких конференций и много выступавшему чуваку), что конференции нужны для того, чтобы понять "где мы сейчас" и "что нового и актуального появилось". Это не совсем про учебу -- за один доклад ничему не научишься, а мастер-классы на конференциях ограничены по времени и их обычно не очень много.
А вот именно понять, чем индустрия дышит, что обсуждет, что нового появилось -- вот для этого. Можно читать форумы и статьи, но тут есть некоторое сведенная воедино силами программного комитета картина, курированный контент. То есть, не выдумки отдельных авторов, а репортажи о реальных делах.
Что с этим дальше делать -- конечно же, принимать решения. Моими первыми конференциями были, кажется, IT-people и RuCamp. Это был просто другой мир, после затхлых банков (это было время, когда итшников в банках ещё считали центром расходов и неизбежными дармоедами, и относились соответственно) и примерно таких же вузов. Во многом эти события определили мою дальнейшую траекторию. И я очень жалею, что не попал в те тусовки, в которые в итоге попал благодаря этим конференциям, ещё раньше (например, прозевал расцвет рунета).
Сейчас, конечно, таких мощных событий не очень много -- информации полно, удивить людей сложно. Но, повторюсь, в идеале -- конференция должна быть срезом, демонстрировать state-of-the-art индустрии и давать взглянуть в будущее.
Возможно, сами проблемы, которые поднимают в докладах, не новые, но новыми должны быть подходы и решения, или хотя бы взгляд на них. Программистам проще -- у них постоянно появляются новые технологии, даже языки, инструменты и т.п. Вот они друг другу рассказывают, как их применять, и что будет дальше.
У аналитиков, наверное, новое не так часто возникает, поэтому и кажется, что всё одно и то же. Ну, это тоже некоторый ответ -- раз всё одно и то же, значит что, индустрия стагнирует и не развивается? Все книжки друг другу кидают, так они ещё из прошлого века. Вигерс 2013, но это переиздание, первая версия написана в 1999. Купер и "Психбольница в руках пациентов" -- 1998. Что нового появилось? Какие новые технологии, какие вызовы?
Если они есть -- решением по выходе с конференции должно быть "о! вот как у них! вот о чем они думают и как работают! Надо у нас тоже такое внедрить, пойду читать подробнее". Или "о, блин, вот как можно-то! а у нас какая-то фигня происходит, пойду в нормальную компанию работать". То есть, какой-то инсайт, озарение. Ещё на конференции ходят, когда в компании нет профессионального сообщества -- убедиться, что ты такой в мире не один, и есть много людей, которые сталкиваются с похожими проблемами и которых волнует то же, что и тебя. Но это не настолько ценно обычно, чтобы свои деньги платить, это входит в мотивационный пакет компании.
Если всего этого с участниками не происходит -- значит, ПК плохо сделали свою работу, ну или в индустрии правда всё тухло. Или вы переросли эту конференцию, и вам на ней нужно выступать :)
Это, кстати, проблема -- опытных товарищей уже сложно чем-то удивить, они всегда ноют, что для них всё скучно и всё уже было. Эту задачу пока никто не решил (я не видел). Ну вот мы делали WAW в прошлом году, там все общались и это было очень ценно, но можно ли это повторить -- не знаю, будем пробовать. Задача сложная.
Напишите -- а вы зачем ходите на конференции, или почему не ходите, если не?
Мне кажется (как члену ПК нескольких конференций и много выступавшему чуваку), что конференции нужны для того, чтобы понять "где мы сейчас" и "что нового и актуального появилось". Это не совсем про учебу -- за один доклад ничему не научишься, а мастер-классы на конференциях ограничены по времени и их обычно не очень много.
А вот именно понять, чем индустрия дышит, что обсуждет, что нового появилось -- вот для этого. Можно читать форумы и статьи, но тут есть некоторое сведенная воедино силами программного комитета картина, курированный контент. То есть, не выдумки отдельных авторов, а репортажи о реальных делах.
Что с этим дальше делать -- конечно же, принимать решения. Моими первыми конференциями были, кажется, IT-people и RuCamp. Это был просто другой мир, после затхлых банков (это было время, когда итшников в банках ещё считали центром расходов и неизбежными дармоедами, и относились соответственно) и примерно таких же вузов. Во многом эти события определили мою дальнейшую траекторию. И я очень жалею, что не попал в те тусовки, в которые в итоге попал благодаря этим конференциям, ещё раньше (например, прозевал расцвет рунета).
Сейчас, конечно, таких мощных событий не очень много -- информации полно, удивить людей сложно. Но, повторюсь, в идеале -- конференция должна быть срезом, демонстрировать state-of-the-art индустрии и давать взглянуть в будущее.
Возможно, сами проблемы, которые поднимают в докладах, не новые, но новыми должны быть подходы и решения, или хотя бы взгляд на них. Программистам проще -- у них постоянно появляются новые технологии, даже языки, инструменты и т.п. Вот они друг другу рассказывают, как их применять, и что будет дальше.
У аналитиков, наверное, новое не так часто возникает, поэтому и кажется, что всё одно и то же. Ну, это тоже некоторый ответ -- раз всё одно и то же, значит что, индустрия стагнирует и не развивается? Все книжки друг другу кидают, так они ещё из прошлого века. Вигерс 2013, но это переиздание, первая версия написана в 1999. Купер и "Психбольница в руках пациентов" -- 1998. Что нового появилось? Какие новые технологии, какие вызовы?
Если они есть -- решением по выходе с конференции должно быть "о! вот как у них! вот о чем они думают и как работают! Надо у нас тоже такое внедрить, пойду читать подробнее". Или "о, блин, вот как можно-то! а у нас какая-то фигня происходит, пойду в нормальную компанию работать". То есть, какой-то инсайт, озарение. Ещё на конференции ходят, когда в компании нет профессионального сообщества -- убедиться, что ты такой в мире не один, и есть много людей, которые сталкиваются с похожими проблемами и которых волнует то же, что и тебя. Но это не настолько ценно обычно, чтобы свои деньги платить, это входит в мотивационный пакет компании.
Если всего этого с участниками не происходит -- значит, ПК плохо сделали свою работу, ну или в индустрии правда всё тухло. Или вы переросли эту конференцию, и вам на ней нужно выступать :)
Это, кстати, проблема -- опытных товарищей уже сложно чем-то удивить, они всегда ноют, что для них всё скучно и всё уже было. Эту задачу пока никто не решил (я не видел). Ну вот мы делали WAW в прошлом году, там все общались и это было очень ценно, но можно ли это повторить -- не знаю, будем пробовать. Задача сложная.
Напишите -- а вы зачем ходите на конференции, или почему не ходите, если не?
❤14👍9🤡3👾1
Ещё немного инсайтов про конференции. Вот про нетворкинг спикеров — это правда. Я в свое время с очень крутыми людьми познакомился и пообщался именно в спикерской или в ПК.
Тут дело в том, что у вас есть общее занятие, а за этим занятием и общение идёт легче и знакомство. А вот у тебя в докладе то-то и то-то, а меня был вот такой опыт — и понеслось. Можно, конечно, и просто так спикера поймать — кстати, не бойтесь это делать, спикеры — такие же люди, и скорее всего будут открыты к разговору не только сразу после докладов, но и в другое время.
Но при подготовке доклада приходится общаться с другими — и крутыми! — людьми, к которым потом можно придти и со своим вопросом или идеей. А ещё на некоторых конференциях для спикеров устраивают отдельный нетворкинг, что тоже очень круто. (А где делают несколько конференций — ещё и нетворкинг для членов ПК). В этом смысле был очень хорош ЛАФ, который и начинался как посиделки за шашлыком, и сейчас продолжает эту традицию, но почему-то не все доходят — видимо, не знают главной фишки :)
В общем, запишу и для себя, и для всех, кто организует конференции — хотите эффективного нетворкинга — придумывайте деятельность, объединяющую людей, в рамках которой люди будут знакомиться, общаться и перемешиваться. На докладах нетворкинг не происходит.
Тут дело в том, что у вас есть общее занятие, а за этим занятием и общение идёт легче и знакомство. А вот у тебя в докладе то-то и то-то, а меня был вот такой опыт — и понеслось. Можно, конечно, и просто так спикера поймать — кстати, не бойтесь это делать, спикеры — такие же люди, и скорее всего будут открыты к разговору не только сразу после докладов, но и в другое время.
Но при подготовке доклада приходится общаться с другими — и крутыми! — людьми, к которым потом можно придти и со своим вопросом или идеей. А ещё на некоторых конференциях для спикеров устраивают отдельный нетворкинг, что тоже очень круто. (А где делают несколько конференций — ещё и нетворкинг для членов ПК). В этом смысле был очень хорош ЛАФ, который и начинался как посиделки за шашлыком, и сейчас продолжает эту традицию, но почему-то не все доходят — видимо, не знают главной фишки :)
В общем, запишу и для себя, и для всех, кто организует конференции — хотите эффективного нетворкинга — придумывайте деятельность, объединяющую людей, в рамках которой люди будут знакомиться, общаться и перемешиваться. На докладах нетворкинг не происходит.
❤8👍4💯2
Forwarded from Публичность и самореализация IT-специалистов (Natalia Semenova)
На прошлой неделе посетила сразу 3 конференции: Joker, Heisenbug и Mobius. Проводила глубинные интервью, пытаясь выяснить следующие вопросы:
- Зачем ходят на конференции?
- Какие видят альтернативы?
- Зачем выступают на конференциях?
- Почему не выступают?
Пока выборка не насколько большая, чтоб делать глобальные выводы. А вот некоторыми интересными наблюдениями хочу поделиться:
- Java-разработчики отмечают, что уровень контента на конференциях сильно упал за последние пару лет🔔
- Миддлы ходят на конфы в основном за тем, чтоб узнать что-то новое, собрать "спойлеры", которые потом поизучать
- Сеньоры и старше ходят на конфы в первую очередь за нетворкингом. Полезного контента для себя особо не ждут и не видят
- Разрабы показали крайнюю степень социофобии. Выступают те, кто "родился болтуном", остальные даже супер-экспертные профи - предпочитают общение с монитором. Тех, кто преодолевает это блокер - единицы ((
- У тестировщиков, аналитиков и менеджеров такой массовой проблемы с коммуникацией не наблюдается ))
- У спикеров везде своя тусовка и нетворкинг на порядок качественнее, чем у обычных участников 😎
- Выступают ради популяризации практик и походов, развития личного бренда, и потому что любят выступать )
- И нашла несколько звезд, которые выступают для того, чтоб делиться лучшими ноу-хау, и вернуть обществу "должок" (говорят, когда начинали свой путь - очень много полезного узнавали именно с конференций)
Все, без выводов. Я призадумалась. Вам тоже на подумать, что с этим делать 👀
- Зачем ходят на конференции?
- Какие видят альтернативы?
- Зачем выступают на конференциях?
- Почему не выступают?
Пока выборка не насколько большая, чтоб делать глобальные выводы. А вот некоторыми интересными наблюдениями хочу поделиться:
- Java-разработчики отмечают, что уровень контента на конференциях сильно упал за последние пару лет
- Миддлы ходят на конфы в основном за тем, чтоб узнать что-то новое, собрать "спойлеры", которые потом поизучать
- Сеньоры и старше ходят на конфы в первую очередь за нетворкингом. Полезного контента для себя особо не ждут и не видят
- Разрабы показали крайнюю степень социофобии. Выступают те, кто "родился болтуном", остальные даже супер-экспертные профи - предпочитают общение с монитором. Тех, кто преодолевает это блокер - единицы ((
- У тестировщиков, аналитиков и менеджеров такой массовой проблемы с коммуникацией не наблюдается ))
- У спикеров везде своя тусовка и нетворкинг на порядок качественнее, чем у обычных участников 😎
- Выступают ради популяризации практик и походов, развития личного бренда, и потому что любят выступать )
- И нашла несколько звезд, которые выступают для того, чтоб делиться лучшими ноу-хау, и вернуть обществу "должок" (говорят, когда начинали свой путь - очень много полезного узнавали именно с конференций)
Все, без выводов. Я призадумалась. Вам тоже на подумать, что с этим делать 👀
Please open Telegram to view this post
VIEW IN TELEGRAM
10🔥10👍5❤2
Продолжая тему конференций — не кажется ли вам, что популярность тем хардов и софтов на конференциях меняется циклично?
В какой-то момент, ещё лет 5 назад, чуть ли не половина докладов была про софты: как продуктивно работать, как проводить совещания, как не выгореть, как избегать конфликтов или наоборот манипулировать. Про разные там модели личности были популярны доклады, про балансы работы и жизни. Я на ЛАФе в 2022 году даже слышал доклад про то, как устроить себе саббатикал — то есть, уйти в долгий отпуск. В докладе было про 5 месяцев, но вообще саббатикал может быть и на год; в университетах его дают профессорам каждые 7 лет (или даже 5), Дональд Кнут написал TeX как раз во время такого отпуска.
В общем, разговоров про людей и про жизнь было много. Потом маятник качнулся назад — всем захотелось хардов, технологий интеграции, архитектуры и всякого такого. Некоторые конференции даже принципиально не брали доклады на темы софт-скиллов и управления людьми — только хардкор!
И, кажется, у аудитории опять назрела потребность поговорить не про интеграции и не про ИИ, а про себя — про людей, то есть. Чтобы и про выгорание — которое никуда не делось, и про развитие — и собственное, и своих сотрудников, если вы лид/начальник подразделения. И про поиск, и про адаптацию, и про управление, и про взаимодействие со стейкхолдерами, и про противодействие манипуляциям.
Я вижу это по запросам на менторинг/консультации (а на Flow, например, была такая активность — "спроси эксперта", вот я был тем экспертом, и угадайте — про что был вопрос? Точно не про интеграции :))
Ещё примерно те же темы поднимались в опросе, который я когда-то проводил — и проблемы тоже совсем не с технологиями связаны и не с техниками анализа, а в основном с людьми.
Как вам кажется — актуальные темы про людей в системном анализе? Что бы вы хотели услышать и обсудить про всё, что не харды?
Давайте продолжим эту практику — спросите меня о чем-нибудь, что относится к людям? Как быть с собой и как быть с другими. Постараюсь вам ответить, насколько смогу. Ну и других опытных коллег призываю отвечать, по возможности.
Пишите в комментах вопросы, которые вас беспокоят, и на которые у вас нет ответа — будем разбираться!
В какой-то момент, ещё лет 5 назад, чуть ли не половина докладов была про софты: как продуктивно работать, как проводить совещания, как не выгореть, как избегать конфликтов или наоборот манипулировать. Про разные там модели личности были популярны доклады, про балансы работы и жизни. Я на ЛАФе в 2022 году даже слышал доклад про то, как устроить себе саббатикал — то есть, уйти в долгий отпуск. В докладе было про 5 месяцев, но вообще саббатикал может быть и на год; в университетах его дают профессорам каждые 7 лет (или даже 5), Дональд Кнут написал TeX как раз во время такого отпуска.
В общем, разговоров про людей и про жизнь было много. Потом маятник качнулся назад — всем захотелось хардов, технологий интеграции, архитектуры и всякого такого. Некоторые конференции даже принципиально не брали доклады на темы софт-скиллов и управления людьми — только хардкор!
И, кажется, у аудитории опять назрела потребность поговорить не про интеграции и не про ИИ, а про себя — про людей, то есть. Чтобы и про выгорание — которое никуда не делось, и про развитие — и собственное, и своих сотрудников, если вы лид/начальник подразделения. И про поиск, и про адаптацию, и про управление, и про взаимодействие со стейкхолдерами, и про противодействие манипуляциям.
Я вижу это по запросам на менторинг/консультации (а на Flow, например, была такая активность — "спроси эксперта", вот я был тем экспертом, и угадайте — про что был вопрос? Точно не про интеграции :))
Ещё примерно те же темы поднимались в опросе, который я когда-то проводил — и проблемы тоже совсем не с технологиями связаны и не с техниками анализа, а в основном с людьми.
Как вам кажется — актуальные темы про людей в системном анализе? Что бы вы хотели услышать и обсудить про всё, что не харды?
Давайте продолжим эту практику — спросите меня о чем-нибудь, что относится к людям? Как быть с собой и как быть с другими. Постараюсь вам ответить, насколько смогу. Ну и других опытных коллег призываю отвечать, по возможности.
Пишите в комментах вопросы, которые вас беспокоят, и на которые у вас нет ответа — будем разбираться!
👍16
Раз зашла речь про софт-скиллы, напомню ещё раз анекдотическую ситуацию с половиной статей про эти самые софт-скиллы: https://news.1rj.ru/str/systemswing/213
Помните! Если вы видите в какой-нибудь статье фразу "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." — это из книги 1918 (не опечатка!) года про обучение инженеров в США, и главный "софт-скилл" там — твердость характера!
Помните! Если вы видите в какой-нибудь статье фразу "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." — это из книги 1918 (не опечатка!) года про обучение инженеров в США, и главный "софт-скилл" там — твердость характера!
Telegram
Системный сдвиг
Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно…
🔥15👍9😁4
В обсуждении софт-скиллов и хард-скиллов возник вопрос -- а какие, собственно, у аналитика хард-скиллы? Ну, кроме, цитирую, "сбора требований и базовых знаний по отрисовке диаграмм". Если речь про знание технологий, то любой программист погружен в нюансы технологии гораздо больше аналитика.
Про харды именно по анализу напишу чуть позже, а вот про знания технологий вспомнил хорошую метафору из Руководства по написанию требований INCOSE:
Про харды именно по анализу напишу чуть позже, а вот про знания технологий вспомнил хорошую метафору из Руководства по написанию требований INCOSE:
Представим, что на дворе 1930-е годы. На выставке инструментов для лесного хозяйства фирма Андреаса Штиля только что представила бензопилу, способную сделать революцию в отрасли. Герои нашей истории работают в небольшой компании, занимаются валкой леса. Её менеджеры только что вернулись с выставки. Просто взять и начать валить деревья с большей скоростью — это прекрасно. Но ведь нельзя просто так взять и посадить первого попавшегося представителя какой-нибудь из заинтересованных сторон за стол и попросить его написать требования для закупки бензопилы. Системное мышление заставляет задуматься: как же эта новая технология будет применяться с точки зрения бизнес-операций?Эта метафора показывает разницу между использованием технологии и системным анализом использования технологии. Программисты, безусловно, отлично знают все детали технологий, но задача аналитика (на мой взгляд) -- рассмотреть технологию и её влияние в комплексе и с разных сторон.
К сожалению, менеджмент также не может с пользой для дела прийти к заинтересованным сторонам, видимым с точки зрения бизнес-операций, и попросить их сформулировать потребности и требования к возможностям, открываемым новой бензопилой. Операционные менеджеры ведь управляют лесорубами, которые работают топорами. А эти серьезные мужчины вряд ли смогут рассказать, что им придется делать с новым инструментом: они никогда этого не делали, их никто не учил, не проводил инструктаж по безопасности или обслуживанию пилы. Или, что более вероятно, не захотят помогать: ведь в лучшем случае им придется переучиваться. А в худшем вообще остаться без работы.
Похожая ситуация с отделом снабжения. Его сотрудники знают своё дело — и в мельчайших подробностях! Сколько топоров ломается на метр поваленного леса (и сколько нужно закупить и доставить) известно. Но совершенно непонятно, как поддерживать работу новой бензопилой: что делать с топливом, смазкой, где всё это хранить, сколько запчастей и какие закупать, как часто. Как вообще узнать, что всё это нужно?
Перед тем, как на уровне бизнес-операций кто-то сможет ответить на все эти вопросы (то есть, выполнить требования), на уровне бизнес-менеджмента необходимо решить, как и зачем внедрять технологию на предприятии. Предприятию нужны эти бензопилы, чтобы быстрее валить деревья? Или скорость работы должна остаться такой же, просто выполнять ее хочется эффективнее (например, уволив несколько сотрудников)? В любом из этих случаев придется решить, что делать с людьми: переучивать ли их или нанять новых?
Обслуживание топоров устоялось: торговцы не просто продают инструмент, но и отвечают за его состояние. Сломалось топорище? Просто отправляем его торговцу, он заменит. Затупилось лезвие? Снова к торговцу: он заточит. А с кем и как вести дела, если закупить бензопилы? Как поддержать снабжение? Как перевозить материалы— топливо, масла — с которыми сегодня в компании никто не работает? Как и кто эту новую способность предприятия (все эти двигатели, цепи) будет поддерживать? Как поменять структуру организации? Как внедрять эту новую способность: выдать всем операторам бензопилы сразу, командам по очереди или начать скаких-то определенных регионов? Если начать валить деревья быстрее, нужно ли будет найти дополнительный транспорт для перевозки материала? Не придется ли расширять лесопилку? В конце концов, бизнес-менеджменту придется решить, стоит ли поставлять больше продукции и наводнить ею рынок, обрушив таким образом цены.
🔥30👍16❤7💯1