Ну всё, можно считать себя экспертом: Карл Вигерс говорит от требованиях то же и теми же словами, что и я (https://news.1rj.ru/str/systemswing/450), правда, чуть раньше — в 2021 году:
Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.
Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")
Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что
И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!
В общем, любопытно. Напишу больше, как дочитаю📕
Люди часто говорят о сборе требований к программному проекту, но это создает неверное впечатление. Слово «сбор» предполагает, что требования уже лежат где-то в готовом виде и только и ждут, чтобы их подобрали. Когда я слышу, как кто-то говорит «сбор требований», в моем воображении всплывает картинка сбора цветов или охоты за пасхальными яйцами. Увы, это не так просто.
Требования редко существуют в сознании пользователей в полностью сформированном виде, готовом для передачи бизнес-аналитику или команде разработки, только спроси. Создание набора требований определенно подразумевает этап сбора некой информации, но также включает открытие и изобретение (курсив мой. Смотрите, даже Вигерс пишет, что мы изобретаем требования!). Термин «выявление требований» (requirements elicitation) точнее описывает, как люди из ИТ сотрудничают с заинтересованными сторонами, чтобы изучить, как те работают сейчас, и определить, какие возможности должна предоставлять будущая программная система.
Согласно словарю The American Heritage Dictionary of the English Language (2020), под словом elicitation подразумевается выманивание, вытягивание или провоцирование. Слова «выманивание» и «вытягивание» точнее описывают процесс, чем слова выявление или сбор.
Самые бесполезные вопросы, которые не следует задавать при изучении требований: «Чего вы хотите?» и «Каковы ваши требования?». Такие расплывчатые вопросы вызывают поток множества случайных — но важных, конечно — сведений, смешанных с посторонней информацией и приправленных невысказанными предположениями. Бизнес-аналитик не просто записывает все, что ему говорят заинтересованные стороны. Опытный БА фасилитирует обсуждение, направляя участников на раскрытие имеющего отношение к проблеме знания в структурированном виде.
Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.
Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")
Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что
Две основные практики выявления требований — телепатия и ясновидение. Они не работают. (Урок 13)
Большая группа людей не способна организованно покинуть горящую комнату, не говоря уж о том, чтобы коллективно сформулировать какое-то требование (Урок 14)
И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!
В общем, любопытно. Напишу больше, как дочитаю
Please open Telegram to view this post
VIEW IN TELEGRAM
👍35❤17🔥8👏1
Вообще вот эта зацикленность на отработанных часах — типичное проявление когнитивного искажения "подмена атрибута" (Attribute substitution). В русской Википедии про него статьи нет, поэтому российские специалисты по когнитивным искажениям, которых вы могли слышать на каких-нибудь конференциях, про него никогда не упоминают.
Подмена (или подстановка) атрибута — это когда мы вместо какого-то сложного явления, о котором энергозатратно или непонятно как думать, или оно сложнее доступно для наблюдения, подставляем явление более простое в понимании и доступное. Но другое. И происходит это для мозга незаметно.
Это, например, объясняет множество оптических иллюзий, связанных с оценкой размера объектов, показанных в перспективе (одинаковые по размеру объекты кажутся меньше или больше в зависимости от расположения). Мозг натренирован распознавать трехмерные объекты, он их и распознает, подставляя 3D-модель вместо 2D-рисунков.
В управлении происходит то же самое: нас ведь должны интересовать не отработанные часы, а число выполненных задач. Ну, вдумайтесь в эту фразу: "мы вам платим за отработанное время". Ну бред же. А ещё точнее — даже число успешно выполненных задач так себе показатель, по настоящему нас должна интересовать принесенная польза. Какое-то время назад велись даже разговоры про Agile Manifesto 2.1, с тезисом Business value over working software — Ценность для бизнеса важнее работающего ПО.
Поэтому разговоры о подсчете часов — это подмена непонятного и недоступного "числа задач" (список которых не ведется, да и что считать задачей?..) или, спаси и помилуй, некоей "бизнес-ценности", на простые и понятные часы. Часы легко измерить, очень просто понять и объяснить другим, что это такое, да и пронаблюдать проще простого: вот же, сидит человек, часы идут!
Но если вам вдруг нужно оценить сроки завершения проекта, все эти часы работают очень плохо (про это было множество исследований — любая другая оценка, не привязанная ко времени, дает более точный результат). Человеку вообще сложно оценивать вещи и предсказывать, более-менее хорошо это начинает получаться после долгих специальных тренировок.
Лучше всего — не предсказывать, а экстраполировать. Начать с каких-то данных, и продолжить их в будущее. Когда-то давно я подсмотрел у Макса Дорофеева (Cartmendum) классный инструмент оценки сроков завершения проекта — Enhanced Burn-Down Chart, расширенная диаграмма сгорания работ. Идея очень простая: сравниваем, сколько задач выполнено, и сколько новых насыпалось. Где их линии трендов пересекутся — там проект и закончится, с большой вероятностью. А если не пересекутся — не закончится никогда. Применял его на нескольких проектах — работает, как часы. Против математики не попрёшь!
Подмена (или подстановка) атрибута — это когда мы вместо какого-то сложного явления, о котором энергозатратно или непонятно как думать, или оно сложнее доступно для наблюдения, подставляем явление более простое в понимании и доступное. Но другое. И происходит это для мозга незаметно.
Это, например, объясняет множество оптических иллюзий, связанных с оценкой размера объектов, показанных в перспективе (одинаковые по размеру объекты кажутся меньше или больше в зависимости от расположения). Мозг натренирован распознавать трехмерные объекты, он их и распознает, подставляя 3D-модель вместо 2D-рисунков.
В управлении происходит то же самое: нас ведь должны интересовать не отработанные часы, а число выполненных задач. Ну, вдумайтесь в эту фразу: "мы вам платим за отработанное время". Ну бред же. А ещё точнее — даже число успешно выполненных задач так себе показатель, по настоящему нас должна интересовать принесенная польза. Какое-то время назад велись даже разговоры про Agile Manifesto 2.1, с тезисом Business value over working software — Ценность для бизнеса важнее работающего ПО.
Поэтому разговоры о подсчете часов — это подмена непонятного и недоступного "числа задач" (список которых не ведется, да и что считать задачей?..) или, спаси и помилуй, некоей "бизнес-ценности", на простые и понятные часы. Часы легко измерить, очень просто понять и объяснить другим, что это такое, да и пронаблюдать проще простого: вот же, сидит человек, часы идут!
Но если вам вдруг нужно оценить сроки завершения проекта, все эти часы работают очень плохо (про это было множество исследований — любая другая оценка, не привязанная ко времени, дает более точный результат). Человеку вообще сложно оценивать вещи и предсказывать, более-менее хорошо это начинает получаться после долгих специальных тренировок.
Лучше всего — не предсказывать, а экстраполировать. Начать с каких-то данных, и продолжить их в будущее. Когда-то давно я подсмотрел у Макса Дорофеева (Cartmendum) классный инструмент оценки сроков завершения проекта — Enhanced Burn-Down Chart, расширенная диаграмма сгорания работ. Идея очень простая: сравниваем, сколько задач выполнено, и сколько новых насыпалось. Где их линии трендов пересекутся — там проект и закончится, с большой вероятностью. А если не пересекутся — не закончится никогда. Применял его на нескольких проектах — работает, как часы. Против математики не попрёшь!
👍43❤3
Как выглядит на практике работа с Enhanced Burndown Chart.
Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале.
В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация).
Это бы не было проблемой, если бы с ожиданиями заказчика заранее поработали, и если бы хотя бы раз в месяц ему выдавали полезные результаты. В принципе, тогда бы и вопроса про сходимость проекта не возникло. Реальные продукты, которые развиваются, могут вообще не сходиться — у них нет финальной точки, после которой разработка останавливается. Но можно выделить промежуточные крупные этапы, сходимость к которым можно оценить.
Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет.
Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам):
* объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации;
* посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее;
* если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно;
* наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12).
Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?
Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале.
В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация).
Это бы не было проблемой, если бы с ожиданиями заказчика заранее поработали, и если бы хотя бы раз в месяц ему выдавали полезные результаты. В принципе, тогда бы и вопроса про сходимость проекта не возникло. Реальные продукты, которые развиваются, могут вообще не сходиться — у них нет финальной точки, после которой разработка останавливается. Но можно выделить промежуточные крупные этапы, сходимость к которым можно оценить.
Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет.
Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам):
* объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации;
* посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее;
* если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно;
* наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12).
Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?
👍18
Никто не может объять необъятное. Сколько не изучай методы проектирования API, всегда найдется что-то новое. Или старое. Вот, например, текст, который мне раньше не попадался, и идеи, которые в нём приводятся, тоже отдельно не встречались (хотя сам я их использовал при проектировании, так часто бывает).
Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.
Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:
Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.
1️⃣ Перечислите все данные, которые клиентское приложение может захотеть получить или передать в сервис. Назовем их семантическими дескрипторами — они имеют смысл и описывают, что происходит в приложении. Важно: это точка зрения именно клиента! Примеры для приложения для ведения списка дел:
id: уникальный идентификатор каждой записи в системе;
noscript: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")
2️⃣ Нарисуйте диаграмму состояний
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел➡️ одно дело). Трансформации помечаются как безопасные (идемпотентные) или небезопасные (неидемпотентные). Названия переходов-трансформаций — это тоже семантические дескрипторы.
3️⃣ Согласуйте "магические имена"
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
noscript -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)
(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)
4️⃣ Выберите Media Type
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).
5️⃣ Создайте "семантический профиль"
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).
6️⃣ Напишите или сгенерируйте серверный и клиентский код.
7️⃣ Опубликуйте описание API в каталоге
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).
Вот такие шаги :)
С одной стороны, сейчас звучит немного наивно, с другой — если задуматься, то часто ли мы делаем эти шаги и вообще задумываемся об этих вещах? Нам бы с эндпоинтами и кодами ошибок разобраться...
Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.
Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:
Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.
id: уникальный идентификатор каждой записи в системе;
noscript: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
noscript -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)
(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).
Вот такие шаги :)
С одной стороны, сейчас звучит немного наивно, с другой — если задуматься, то часто ли мы делаем эти шаги и вообще задумываемся об этих вещах? Нам бы с эндпоинтами и кодами ошибок разобраться...
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍3
Стартовал образовательный сезон — даже не знаю, какой по счёту — 17?.. Кажется, я начал регулярно преподавать в 2007 году, разработал и вел курс "Технологии программирования" в МИЭМе. До этого никто и никогда не рассказывал студентам про паттерны, VCS и таск-трекеры, представляете?
Стартую бодро, с корпоративного курса по проектированию интеграций, группа подобралась отличная!
Сразу после курса еду на Flow 2024 Autumn — рассказывать о результатах исследования по использованию диаграмм.
В октябре будет открытый тренинг по системному анализу и разработке требований — пройдем в деталях весь путь от первоначальной задумки до готового ТЗ. Подойдет тем, кто хочет систематизировать знания в системном анализе и овладеть основными техниками — отзывам, курс очень хорошо собирает в единую картину разрозненные знания, если вы осваивали системный анализ по книгам и самостоятельно.
В ноябре опять открытый очный курс в Москве, но уже по основам проектирования интеграций. В каком-то смысле — развитие и продолжение тренинга по разработке требований, но теперь у вас не одна система, а интегрированный комплекс.
Потом, вероятно, будет Analyst Days, ну и между этим всем ещё наверняка парочку корпоративных воткнут.
Сезон! Все хотят учиться! (Если вы тоже хотите — приходите в личку за промокодами)
Стартую бодро, с корпоративного курса по проектированию интеграций, группа подобралась отличная!
Сразу после курса еду на Flow 2024 Autumn — рассказывать о результатах исследования по использованию диаграмм.
В октябре будет открытый тренинг по системному анализу и разработке требований — пройдем в деталях весь путь от первоначальной задумки до готового ТЗ. Подойдет тем, кто хочет систематизировать знания в системном анализе и овладеть основными техниками — отзывам, курс очень хорошо собирает в единую картину разрозненные знания, если вы осваивали системный анализ по книгам и самостоятельно.
В ноябре опять открытый очный курс в Москве, но уже по основам проектирования интеграций. В каком-то смысле — развитие и продолжение тренинга по разработке требований, но теперь у вас не одна система, а интегрированный комплекс.
Потом, вероятно, будет Analyst Days, ну и между этим всем ещё наверняка парочку корпоративных воткнут.
Сезон! Все хотят учиться! (Если вы тоже хотите — приходите в личку за промокодами)
👍8🔥4❤2
На тренинге возник вопрос: вот я аналитик/менеджер/заказчик. Разработчики или архитекторы приносят проект архитектуры. Как мне понять — он хороший или нет? Соответствует ли он требованиям бизнеса? Подойдет ли? Не будет ли с такой архитектурой проблем в дальнейшем, а если будут — то в каком месте они могут возникнуть? И как вообще разработчики и архитекторы придумывают эту архитектуру? Что бы почитать или какой курс пройти на эту тему?
Мне, в первую очередь, приходит в голову книга Алекса Сюя про прохождение System Design Interview. Но для совсем начинающих там очень хороша первая глава ("Масштабирование от 0 до миллионов пользователей"), а дальше начинаются частности — примеры рассуждений при проектировании конкретных систем, причем зачастую низкоуровневых: ограничителя трафика, хранилища ключ-значение, генератора уникальных идентификаторов и т.п. Нет, там есть, конечно, проектирование новостной ленты, мессенджера, youtube и google drive, что можно соотнести с прикладными задачами, но половина примеров — чисто инфраструктурные, и тут, мне кажется, разрыв с первой вводной главой слишком велик — нужно предварительное понимание, например, как работает кэш, а это и не каждый программист понимает.
Первая глава последовательно вводит некоторые базовые идеи, рассказывающие о начальных принципах архитектуры:
* система с одним сервером (имеется в виду веб или мобильное приложение с бэкендом);
* выделение базы данных (и короткий обзор реляционных и NoSQL);
* вертикальное и горизонтальное масштабирование;
* балансировщики нагрузки;
* репликация;
* кэширование;
* системы с сохранением состояния и без сохранения состояния;
* очереди сообщений и т.д.
А вот более сложные концепции, типа CAP-теоремы, технологий опроса (polling, long polling, WebSocket...), стратегии гарантированной доставки или примеры решений по обработке ошибок — "зарыты" в описании конкретных примеров. Причем заранее не угадаешь — где будет про проектирование API (тема подходит для технического менеджера или аналитика), а где про префиксные деревья (тема чисто программистская).
Кроме того, почти во всех решениях у Сюя акцент ставится на масштабируемости, миллионах и миллиардах пользователей, а в наших задачах ведущей характеристикой может быть совсем другое — стоимость решения или его надежность.
К сожалению, я не знаю хорошей книги или курса, где были бы одновременно описаны основные концепции, важные для архитектурного проектирования, и на таком уровне, чтобы не приходилось впиливаться в глубины алгоритмов. Если встречали такое — дайте мне знать.
Мне, в первую очередь, приходит в голову книга Алекса Сюя про прохождение System Design Interview. Но для совсем начинающих там очень хороша первая глава ("Масштабирование от 0 до миллионов пользователей"), а дальше начинаются частности — примеры рассуждений при проектировании конкретных систем, причем зачастую низкоуровневых: ограничителя трафика, хранилища ключ-значение, генератора уникальных идентификаторов и т.п. Нет, там есть, конечно, проектирование новостной ленты, мессенджера, youtube и google drive, что можно соотнести с прикладными задачами, но половина примеров — чисто инфраструктурные, и тут, мне кажется, разрыв с первой вводной главой слишком велик — нужно предварительное понимание, например, как работает кэш, а это и не каждый программист понимает.
Первая глава последовательно вводит некоторые базовые идеи, рассказывающие о начальных принципах архитектуры:
* система с одним сервером (имеется в виду веб или мобильное приложение с бэкендом);
* выделение базы данных (и короткий обзор реляционных и NoSQL);
* вертикальное и горизонтальное масштабирование;
* балансировщики нагрузки;
* репликация;
* кэширование;
* системы с сохранением состояния и без сохранения состояния;
* очереди сообщений и т.д.
А вот более сложные концепции, типа CAP-теоремы, технологий опроса (polling, long polling, WebSocket...), стратегии гарантированной доставки или примеры решений по обработке ошибок — "зарыты" в описании конкретных примеров. Причем заранее не угадаешь — где будет про проектирование API (тема подходит для технического менеджера или аналитика), а где про префиксные деревья (тема чисто программистская).
Кроме того, почти во всех решениях у Сюя акцент ставится на масштабируемости, миллионах и миллиардах пользователей, а в наших задачах ведущей характеристикой может быть совсем другое — стоимость решения или его надежность.
К сожалению, я не знаю хорошей книги или курса, где были бы одновременно описаны основные концепции, важные для архитектурного проектирования, и на таком уровне, чтобы не приходилось впиливаться в глубины алгоритмов. Если встречали такое — дайте мне знать.
❤20👍7
Мы с уточкой передаем всем подписчикам большой привет с конференции Flow'2024, поздравляем с днём системного аналитика, и желаем удачных проектов, интересных задач, успешного профессионального развития, достижения личных и карьерных целей, а также всеобщего процветания!
Ура!🎆 🎆 🎆
Ура!
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤42🍾19
Ладно, а теперь серьёзно: второй день Flow начинается с двух докладов, в которых есть кое-что общее. Один — рассказ Дениса Котова про метод разработки BPMN. Так и называется: "BPMN — стандарт, но все всё равно рисуют ерунду. Что делать?". Проблема в том, что BPMN — стандарт графической нотации. Что может быть и что не может быть нарисовано. Но как выявлять процесс и его шаги — об этом BPMN не говорит. Не задаёт методику работы.
Второй — интерактивный и провокационный — доклад Сергея Нужненко "Как аналитику подняться от уровня «ноги с ушами» и стать инженером". Сергей показывает задачки с собеседований, вроде бы несложные, но на них срезается половина аналитиков. А чтобы не срезаться — вспоминает методы структурного анализа, откуда к нам пришли IDEF0 и DFD, и которые являются именно методами, то есть инструкциями, как действовать, какие шаги выполнять и как результаты предыдущего шага трансформировать на следующем шаге.
В этом проблема: если мы возьмем те же UML или BPMN, это будут просто нотации. В случае UML "Три амиго" объединились для унификации нотации: какие графические элементы что означают, какие виды диаграмм имеет смысл выделить. Но они не договорились (и не собирались!) про метод их создания — с каких диаграмм нужно начинать, и какие вообще использовать. Метод у каждого был свой — у Буча имени Буча; у Рамбо — Object-Modeling Technique, OMT; у Якобсона — Objectory или OOSE (кстати, только в нём была Use Case Diagram). UML задумывался как нотация, которая поддерживает любую методологию — хоть одну из начальных, хоть какую-то новую.
На практике произошло вот что: UML все начали использовать, но методологий никаких изучать не стали.
То же касается интеграций: все уже знают, какими свойствами обладают разные технологии интеграций, и даже изучили OpenAPI и Swagger, но мало у кого есть метод проектирования API.
Отсюда часто возникает вопрос: вот я прочитал много книг и статей про UML, юскейсы, API — но не понимаю, как всё это связать? Когда использовать одно, когда другое? В голове какая-то каша.
А нужен метод работы! Или, по руководству INCOSE, набор формальных преобразований. Здесь мы с ними сходимся: если вы в принципе готовы рассматривать идею "требований", как отдельно существующих вещей, то эти требования обязаны быть результатом формальных преобразований:
Второй — интерактивный и провокационный — доклад Сергея Нужненко "Как аналитику подняться от уровня «ноги с ушами» и стать инженером". Сергей показывает задачки с собеседований, вроде бы несложные, но на них срезается половина аналитиков. А чтобы не срезаться — вспоминает методы структурного анализа, откуда к нам пришли IDEF0 и DFD, и которые являются именно методами, то есть инструкциями, как действовать, какие шаги выполнять и как результаты предыдущего шага трансформировать на следующем шаге.
В этом проблема: если мы возьмем те же UML или BPMN, это будут просто нотации. В случае UML "Три амиго" объединились для унификации нотации: какие графические элементы что означают, какие виды диаграмм имеет смысл выделить. Но они не договорились (и не собирались!) про метод их создания — с каких диаграмм нужно начинать, и какие вообще использовать. Метод у каждого был свой — у Буча имени Буча; у Рамбо — Object-Modeling Technique, OMT; у Якобсона — Objectory или OOSE (кстати, только в нём была Use Case Diagram). UML задумывался как нотация, которая поддерживает любую методологию — хоть одну из начальных, хоть какую-то новую.
На практике произошло вот что: UML все начали использовать, но методологий никаких изучать не стали.
То же касается интеграций: все уже знают, какими свойствами обладают разные технологии интеграций, и даже изучили OpenAPI и Swagger, но мало у кого есть метод проектирования API.
Отсюда часто возникает вопрос: вот я прочитал много книг и статей про UML, юскейсы, API — но не понимаю, как всё это связать? Когда использовать одно, когда другое? В голове какая-то каша.
А нужен метод работы! Или, по руководству INCOSE, набор формальных преобразований. Здесь мы с ними сходимся: если вы в принципе готовы рассматривать идею "требований", как отдельно существующих вещей, то эти требования обязаны быть результатом формальных преобразований:
Формулировка требования — это итог формального преобразования одной или нескольких потребностей в согласованное обязательство. Это обязательство возлагают на сущность. Суть обязательства — при определенных ограничениях выполнять некоторую функцию или обладать некоторым качеством.
👍23🔥14👎1
Одним из самых главных инсайтов 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