📝 Экспозиция сеттинга, или установка "правил игры". Тут могут быть разные подходы, но в любом случае, так или иначе, мы должны ввести читателя в курс дела. Мы можем это делать сразу одним куском, или разбивая на части и помещая введение и объяснение перед очередными несколькими элементами, в которых используется это очередное правило. И наоборот — когда мы описываем какой-то процесс, мы до этого должны представить читателю сеттинг, в рамках которого это происходит. Это у нас кто? Это они делают зачем? Используя что? По каким правилам?
📈 Темпо-ритм документа. Если мы подразумеваем, что хоть кто-нибудь хоть когда-нибудь будет линейно читать наш документ, стоит задуматься про его темп и ритм (скорость и внутренние циклы). В техническом тексте это регулируется длиной и подробностью блоков, переходов с одной темы на другую. Темпо-ритм придумал Станиславский ("нарастание или спад, ускорение или замедление, плавное течение или бурное развитие сценического действия"). В первом приближении это означает, что вообще что-то должно меняться. Если весь текст состоит из однообразных блоков — получается сплошное однотонное бу-бу-бу, читатель от этого быстро устаёт и перестаёт различать их. Нужно как-то чередовать. Тут можно вспомнить принципы визуального монтажа "по крупности": нельзя монтировать встык планы одной или смежной крупности (кроме сочетания "крупный план-деталь"), нужно монтировать через план.
Можно попробовать применить это и к тексту: сначала даём общий план, потом приближаемся, углубляемся в детали, отдаляемся, уходим опять к общему — и снова, так создаётся определенный ритм.
А какие ещё идеи можно применить к технической документации из области литературного творчества?
Можно попробовать применить это и к тексту: сначала даём общий план, потом приближаемся, углубляемся в детали, отдаляемся, уходим опять к общему — и снова, так создаётся определенный ритм.
А какие ещё идеи можно применить к технической документации из области литературного творчества?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍3
Регулярные выражения, RegEx или RegExp.
Написал для участников тренинга, вдруг вам тоже пригодится.
Интересно, что у аналитиков регулярно встречается запрос на SQL (и на собеседованиях дают задачки на него), а вот про регулярные выражения почему-то не вспоминают. То ли они аналитикам не нужны, то ли считается, что это знание "по умолчанию", ну что про них говорить :) Между тем, я вижу на курсах, что многие аналитики вообще про них не знают, а они начинают всплывать при интеграциях: при валидации параметров входящих сообщений (pattern в схеме данных в OpenAPI), при мэппинге данных, при указании имен файлов в файловом обмене.
Это специальный язык, через который можно задать условия для текста. То есть, найти в тексте такую подстроку, которая удовлетворяет этим условиям.
Для чего может использоваться:
🔹 проверка формата текстового значения (валидация — например, в json schema или xsd, причём валидировать можно как значения, так и названия полей);
🔹 поиск (например, в текстовом файле, CSV, таблице Excel или в БД);
🔹 извлечение подстроки из текста;
🔹 подсчет числа вхождений, соответствующих маске;
🔹 замена подстроки, подходящей под маску;
🔹 очистка данных (удаление кавычек, двойных пробелов, скобок и т.п., извлечение значений: ФИО, дат, телефонов, URL, email)
Регэкспы распространены повсеместно: от утилиты командной строки grep, выполняющей поиск в файлах и постоянно использующейся программистами и админами (отсюда глагол "грепать", "грепнуть" — получить подмножество соответствующих строк из исходного файла), до библиотек во всех языках программирования, функций в SQL, инструментов поиска в текстовых редакторах и интернет-поисковиках.
Синтаксис регулярных выражений стандартизован как часть стандарта POSIX. На практике чаще применяется более мощный PCRE, родом из языка Perl, так что в каждой конкретной системе синтаксис выражений может немного отличаться.
Движки выполнения хорошо оптимизированы и работают быстро; под регулярными выражениями лежит хорошая математика, и в среднем их вычислительная сложность линейна — O(n) — но можно написать такое выражение, которое надолго завесит ваш поиск :)
Язык задания паттернов в своей основе прост:
— просто набор символов -> полное совпадение с учетом регистра (по умолчанию. можно отключить учёт регистра)
— . -> любой символ
— вертикальная палка | -> одно или другое: елка|ёлка
— скобки -> область действия и последовательность операторов, как в математике: (е|ё)лка, Ната(л(ь|и)я|ша)
— квадратные скобки -> любой из указанных символов: [её]лка, Натал[ьи]я, [0-9] - цифры, [A-Z] - буквы латиницы в верхнем регистре
- [^] -> отрицание, символ, не входящий в набор: [^аеёиоуэюя] означает "любой символ, кроме гласных букв".
Квантификаторы:
? -> ноль или один предыдущий символ: RegExp? найдет и RegEx, и RegExp
* -> ноль или несколько предыдущих символов
+ -> один или несколько предыдущих символов
{n} -> повтор предыдущего символа n раз. {n,m} - повтор от n до m раз
^ и $ -> начало и конец строки. \w — слово, \b — граница слова (но только для английского языка!).
Пример: ^(?:\d{3}-){2}\d{4}$ - строка, содержащая телефонный номер. Или так: ^[0-9]{3}-[0-9]{3}-[0-9]{4}$.
Дальше начинается сплошной драконий покер: можно искать слово X, за которым не следует слово Y; строки, в которых упоминается Z, но не упоминается W, и так далее. Инструмент невероятно мощный, можно с ним удивительные вещи делать. Правда, разобраться в уже готовых регэкспах бывает сложно, их обзывают write only, а выглядят они, как шифр на клингонском.
Почитать вводную статью на русском: https://techrocks.ru/2022/05/31/regex-complete-guide/
Пройти подробнейший tutorial на английском: https://www.regular-expressions.info/tutorial.html
Попробовать составить и поотлаживать регулярные выражения: https://regex101.com/
Вот тут примеры пожестче: https://habr.com/ru/articles/349860/
Кстати, ChatGPT умеет по текстовому описанию умеет строить регулярные выражения (но рекомендую проверять, как обычно — он может и ошибок насажать).
Написал для участников тренинга, вдруг вам тоже пригодится.
Интересно, что у аналитиков регулярно встречается запрос на SQL (и на собеседованиях дают задачки на него), а вот про регулярные выражения почему-то не вспоминают. То ли они аналитикам не нужны, то ли считается, что это знание "по умолчанию", ну что про них говорить :) Между тем, я вижу на курсах, что многие аналитики вообще про них не знают, а они начинают всплывать при интеграциях: при валидации параметров входящих сообщений (pattern в схеме данных в OpenAPI), при мэппинге данных, при указании имен файлов в файловом обмене.
Это специальный язык, через который можно задать условия для текста. То есть, найти в тексте такую подстроку, которая удовлетворяет этим условиям.
Для чего может использоваться:
🔹 проверка формата текстового значения (валидация — например, в json schema или xsd, причём валидировать можно как значения, так и названия полей);
🔹 поиск (например, в текстовом файле, CSV, таблице Excel или в БД);
🔹 извлечение подстроки из текста;
🔹 подсчет числа вхождений, соответствующих маске;
🔹 замена подстроки, подходящей под маску;
🔹 очистка данных (удаление кавычек, двойных пробелов, скобок и т.п., извлечение значений: ФИО, дат, телефонов, URL, email)
Регэкспы распространены повсеместно: от утилиты командной строки grep, выполняющей поиск в файлах и постоянно использующейся программистами и админами (отсюда глагол "грепать", "грепнуть" — получить подмножество соответствующих строк из исходного файла), до библиотек во всех языках программирования, функций в SQL, инструментов поиска в текстовых редакторах и интернет-поисковиках.
Синтаксис регулярных выражений стандартизован как часть стандарта POSIX. На практике чаще применяется более мощный PCRE, родом из языка Perl, так что в каждой конкретной системе синтаксис выражений может немного отличаться.
Движки выполнения хорошо оптимизированы и работают быстро; под регулярными выражениями лежит хорошая математика, и в среднем их вычислительная сложность линейна — O(n) — но можно написать такое выражение, которое надолго завесит ваш поиск :)
Язык задания паттернов в своей основе прост:
— просто набор символов -> полное совпадение с учетом регистра (по умолчанию. можно отключить учёт регистра)
— . -> любой символ
— вертикальная палка | -> одно или другое: елка|ёлка
— скобки -> область действия и последовательность операторов, как в математике: (е|ё)лка, Ната(л(ь|и)я|ша)
— квадратные скобки -> любой из указанных символов: [её]лка, Натал[ьи]я, [0-9] - цифры, [A-Z] - буквы латиницы в верхнем регистре
- [^] -> отрицание, символ, не входящий в набор: [^аеёиоуэюя] означает "любой символ, кроме гласных букв".
Квантификаторы:
? -> ноль или один предыдущий символ: RegExp? найдет и RegEx, и RegExp
* -> ноль или несколько предыдущих символов
+ -> один или несколько предыдущих символов
{n} -> повтор предыдущего символа n раз. {n,m} - повтор от n до m раз
^ и $ -> начало и конец строки. \w — слово, \b — граница слова (но только для английского языка!).
Пример: ^(?:\d{3}-){2}\d{4}$ - строка, содержащая телефонный номер. Или так: ^[0-9]{3}-[0-9]{3}-[0-9]{4}$.
Дальше начинается сплошной драконий покер: можно искать слово X, за которым не следует слово Y; строки, в которых упоминается Z, но не упоминается W, и так далее. Инструмент невероятно мощный, можно с ним удивительные вещи делать. Правда, разобраться в уже готовых регэкспах бывает сложно, их обзывают write only, а выглядят они, как шифр на клингонском.
Почитать вводную статью на русском: https://techrocks.ru/2022/05/31/regex-complete-guide/
Пройти подробнейший tutorial на английском: https://www.regular-expressions.info/tutorial.html
Попробовать составить и поотлаживать регулярные выражения: https://regex101.com/
Вот тут примеры пожестче: https://habr.com/ru/articles/349860/
Кстати, ChatGPT умеет по текстовому описанию умеет строить регулярные выражения (но рекомендую проверять, как обычно — он может и ошибок насажать).
👍25🔥7❤1
Взялся писать пост про различные свойства систем (нефункциональные требования, фитнесс-функция и всякое такое), но столкнулся с известной проблемой великого и могучего...
С защищенностью, надежностью и точностью у нас всё просто, без нюансов — мы за всю историю эти штуки редко видели, много разных слов не успели придумать.
(Пост пишу, завтра закину).
UPD: вы не переживайте, в русском языке зато есть много слов про эмоции и отношения, эквивалентов которым нет в других языках.
С защищенностью, надежностью и точностью у нас всё просто, без нюансов — мы за всю историю эти штуки редко видели, много разных слов не успели придумать.
(Пост пишу, завтра закину).
UPD: вы не переживайте, в русском языке зато есть много слов про эмоции и отношения, эквивалентов которым нет в других языках.
😁24👎5❤2
Есть много акронимов и отдельных свойств архитектуры:
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)
🔥18👍6👌1
3. Как мы систему эксплуатируем. В штатном и нештатном режиме, как входим и выходим из нештатного режима; как обеспечиваем альтернативные способы функционирования при отказе частей (business continuity plan); какие есть средства диагностики и поиска неисправностей (например, можно ли проверить отдельно работу какой-то подсистемы или функции на проде?), какие есть методы устранения сбоев? А средства прогнозирования сбоев?
4. И вот чего никогда не видел - средства вывода системы из эксплуатации.
Про фитнесс-функцию сегодня не влезло, и так телеграм на два поста побил :(
Ставьте какую-нибудь положительную реакцию, если тема интересна, и стоит продолжать.
А вы сами в какой мере сталкиваетесь с проработкой показателей качества?
4. И вот чего никогда не видел - средства вывода системы из эксплуатации.
Про фитнесс-функцию сегодня не влезло, и так телеграм на два поста побил :(
Ставьте какую-нибудь положительную реакцию, если тема интересна, и стоит продолжать.
А вы сами в какой мере сталкиваетесь с проработкой показателей качества?
🔥35👍13👌1
Продолжаем тему нефункциональных требований и атрибутов качества.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
➕ доступность (aviability): готовность предоставлять работающий сервис (вероятность, что система будет работать, когда мы к ней обратимся);
➕ надежность (reliability): неизменность параметров сервиса во времени;
➕ безопасность (safety): из-за сбоя не будет катастрофических последствий для пользователей и окружения;
➕ целостность (integrity): система не развалится при сбое и данные не будут искажены;
➕ ремонтопригодность (maintainability): систему можно будет починить после сбоя: обнаружить дефект, перезапустить, восстановить данные.
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты➡️ угрозы ➡️ меры.
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект➡️ ошибка ➡️ отказ, который, в свою очередь, приводит к ошибке в смежной системе и т.д.
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍2
Соответственно, мы можем принять меры в отношении всех этих угроз.
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?
👍15
https://youtu.be/sjNKAd5l88M?si=vOtZ0sT_mSC8mgSv&t=2m27s
Прекрасное у Жванецкого про ИТ-системы в управлении, ну и вообще про управление на основе данных. (с 2:27)
В принципе, с 1985 года ничего и не поменялось!
Пока данные введут — подправят, после обработки — сдвигают...
Поэтому, кстати, многие системные аналитики не копают в сторону бизнес-смысла, а то ведь можно и докопаться.
Прекрасное у Жванецкого про ИТ-системы в управлении, ну и вообще про управление на основе данных. (с 2:27)
В принципе, с 1985 года ничего и не поменялось!
Пока данные введут — подправят, после обработки — сдвигают...
Поэтому, кстати, многие системные аналитики не копают в сторону бизнес-смысла, а то ведь можно и докопаться.
YouTube
Михаил Жванецкий - фельетон "Непереводимая игра слов" (1985)
Фельетон "Непереводимая игра слов". Исполняет автор - писатель-сатирик Михаил Жванецкий.
Фрагмент концертной программы "Новогоднее представление. "Голубой огонек".
Главная редакция музыкальных программ, 1985 г.
#гостелерадиофонд #НовогодняяКарусель…
Фрагмент концертной программы "Новогоднее представление. "Голубой огонек".
Главная редакция музыкальных программ, 1985 г.
#гостелерадиофонд #НовогодняяКарусель…
😁7
Слышали ли вы об инициативе SEMAT и стандарте OMG Essence?
Была такая великая инициатива Ивара Якобсона (который придумал UML, use cases и RUP), многие известные люди подписались: мол, в методиках разработки творится какая-то ересь непонятная, каждый изобретает свою методологию, а как их сравнить и как выбрать подходящую — непонятно.
В общем, придумали структуру для описания процесса (а заодно и проверки — как идут дела), провели как стандарт у своих друзей OMG (которые стандартизируют UML и BPMN), разрекламировали — Якобсон с коллегами даже в Россию несколько раз приезжал, выступал на SECR.
Идея была такая: разработаем структуру описания, а потом будем описывать существующие практики в этой структуре — "эссенциализировать" практики. На текущий момент описан SCRUM, базовые идеи Agile, Agile at scale, OpenUP, и, говорят, внутри в консалтинговой компании Якобсона есть описания процессов Spotify, SAFe и т.д. В принципе, в основном он эту тему и двигает, неясно — есть ли кто там ещё.
На удивление, есть ГОСТ Р 57195-2016, соответствующий OMG Essence. Вот только описания практик на русском нет.
Как думаете, интересная это тема — иметь библиотеку практик сразу в стандартном виде, готовую для внедрения, с чек-листами?
Была такая великая инициатива Ивара Якобсона (который придумал UML, use cases и RUP), многие известные люди подписались: мол, в методиках разработки творится какая-то ересь непонятная, каждый изобретает свою методологию, а как их сравнить и как выбрать подходящую — непонятно.
В общем, придумали структуру для описания процесса (а заодно и проверки — как идут дела), провели как стандарт у своих друзей OMG (которые стандартизируют UML и BPMN), разрекламировали — Якобсон с коллегами даже в Россию несколько раз приезжал, выступал на SECR.
Идея была такая: разработаем структуру описания, а потом будем описывать существующие практики в этой структуре — "эссенциализировать" практики. На текущий момент описан SCRUM, базовые идеи Agile, Agile at scale, OpenUP, и, говорят, внутри в консалтинговой компании Якобсона есть описания процессов Spotify, SAFe и т.д. В принципе, в основном он эту тему и двигает, неясно — есть ли кто там ещё.
На удивление, есть ГОСТ Р 57195-2016, соответствующий OMG Essence. Вот только описания практик на русском нет.
Как думаете, интересная это тема — иметь библиотеку практик сразу в стандартном виде, готовую для внедрения, с чек-листами?
👍32❤1
Слышали ли вы о SEMAT Essence и что думаете?
Anonymous Poll
60%
Впервые слышу, непонятно — что это и для чего
28%
Впервые слышу, интересно!
9%
Не в первый раз попадается, но так и не ясно, как применить
1%
Знаю и применяю!
1%
Другое (напишу в комментах) / посмотреть результаты
Стартовали Winter Analytical Weekend! Максим Цепков ведёт текстовую трансляцию впечатлений от докладов в своём канале: https://news.1rj.ru/str/mtsepkov
Telegram
Максим Цепков
Автор @MaximTsepkov, сайт http://mtsepkov.org - менеджмент самоуправления, soft skill модели, конференции.
Forwarded from Максим Цепков (Maxim Tsepkov)
Сегодня - на http://waw-conf.ru мой доклад - открывающий, о будущам общества, ИТ и аналитиков. Презентация - у меня на сайте https://mtsepkov.org/Future-WAW
Forwarded from Максим Цепков (Maxim Tsepkov)
#wawconf Алишер Умаров. Аналитик 2.0 - Шестирукий Шива или как выжить в современных реалиях с ИИ.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
👍14
Зимние аналитические выходные (WAW-conf) получились, и, кажется, получились огненными!
Давно я не слышал столько восторженных отзывов. И докладчики, и программа, и мастер-классы, и дискуссии, и кулуары, и афтепати, и, конечно, участники — всё сложилось, как пазл, несмотря на отдельные косяки и шероховатости.
Очень мощная и заряженная движуха получилась, с нетворкингом, горящими глазами и вдохновением, как минимум, до лета.
В общем, первый запуск прошёл отлично, настоящий праздник среди зимы
❄️🔥 🎆
Давно я не слышал столько восторженных отзывов. И докладчики, и программа, и мастер-классы, и дискуссии, и кулуары, и афтепати, и, конечно, участники — всё сложилось, как пазл, несмотря на отдельные косяки и шероховатости.
Очень мощная и заряженная движуха получилась, с нетворкингом, горящими глазами и вдохновением, как минимум, до лета.
В общем, первый запуск прошёл отлично, настоящий праздник среди зимы
❄️
Please open Telegram to view this post
VIEW IN TELEGRAM
👏13👍2🔥2🥰2
На WAW я проводил мастер-класс по проектированию процесса разработки при помощи карт состояний Essence.
Карты состояний можно использовать для разных задач, например — выяснения текущего состояния проекта или синхронизации понимания в команде.
Мы пробовали спроектировать процесс сначала по вехам (то есть, в какие моменты мы останавливаемся и принимаем решение — идём дальше или нет?), потом в деталях: какие артефакты нам нужны и какие дела нужно сделать, чтобы прийти к этой вехе.
У двух команд ситуации отличались. В первом кейсе была веб-студия, заказное ПО. Во втором — внутренняя разработка или даже выбор готового решения.
И вот вроде делать в любом проекте нужно одно и то же: выявить стейкхолдеров; понять, что им нужно; зафиксировать; продумать решение; сделать его; а для этого — собрать команду и выполнить работу.
Это как раз объекты ядра из Essence: стейкхолдер, потребность, требования, система, работа, команда, технология работы. Так называемые Альфы. За состоянием чего нужно следить в любом проекте.
Но вот группировка и временные промежутки между разными состояниями ключевых альф в каждом проекте разные.
Так произошло и у нас на МК: у веб-студии процесс получился равномерный, это видно на флипчарте — сначала пресейл, потом ТЗ и дизайн, потом собираем команду и начинаем разрабатывать, потом сдаем и запускаем. Такой почти классический водопад.
Для внутренней разработки карточки сгруппированы по-другому: чтобы вообще что-то начать делать с системой, нужно сначала понять потребности. Поэтому состояния альф "стейкхолдеры" и "потребность" сгруппированы в начале проекта, потом идут требования, а потом — выбор системы из тех, что есть на рынке, или уж своя разработка.
Мы не дошли до альф команды и работы, там интересно — команду нужно было бы пересобирать после выбора: делать своё или брать готовое, то есть начальные состояния команды были бы где-то в середине.
Получилось довольно наглядно, и это всего лишь за один час! А за день можно и весь процесс спроектировать.
Карты состояний можно использовать для разных задач, например — выяснения текущего состояния проекта или синхронизации понимания в команде.
Мы пробовали спроектировать процесс сначала по вехам (то есть, в какие моменты мы останавливаемся и принимаем решение — идём дальше или нет?), потом в деталях: какие артефакты нам нужны и какие дела нужно сделать, чтобы прийти к этой вехе.
У двух команд ситуации отличались. В первом кейсе была веб-студия, заказное ПО. Во втором — внутренняя разработка или даже выбор готового решения.
И вот вроде делать в любом проекте нужно одно и то же: выявить стейкхолдеров; понять, что им нужно; зафиксировать; продумать решение; сделать его; а для этого — собрать команду и выполнить работу.
Это как раз объекты ядра из Essence: стейкхолдер, потребность, требования, система, работа, команда, технология работы. Так называемые Альфы. За состоянием чего нужно следить в любом проекте.
Но вот группировка и временные промежутки между разными состояниями ключевых альф в каждом проекте разные.
Так произошло и у нас на МК: у веб-студии процесс получился равномерный, это видно на флипчарте — сначала пресейл, потом ТЗ и дизайн, потом собираем команду и начинаем разрабатывать, потом сдаем и запускаем. Такой почти классический водопад.
Для внутренней разработки карточки сгруппированы по-другому: чтобы вообще что-то начать делать с системой, нужно сначала понять потребности. Поэтому состояния альф "стейкхолдеры" и "потребность" сгруппированы в начале проекта, потом идут требования, а потом — выбор системы из тех, что есть на рынке, или уж своя разработка.
Мы не дошли до альф команды и работы, там интересно — команду нужно было бы пересобирать после выбора: делать своё или брать готовое, то есть начальные состояния команды были бы где-то в середине.
Получилось довольно наглядно, и это всего лишь за один час! А за день можно и весь процесс спроектировать.
👍24
Конец зимы получается очень горячим! 🔥
Не успел опомниться от Winter Analytical Weekend, а скоро уже и весенний Flow, где я эксперт и член ПК.
Программа Flow готова уже на 100%, это будет интенсив в онлайне 12 марта, и будет много докладов про самые практические вещи в работе аналитика: про требования, интеграции и архитектуру. Ну и про ИИ, куда же теперь без него!
Часть программы уже на сайте, а цена более чем демократичная.
Вероятно, я там буду в качестве эксперта представлять некоторые доклады, а может даже и вести дискуссию в главной студии. Хороший подарок прямо к моему дню рождения!🎁
А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.
Курс, на самом деле, просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.
А в апреле будет его сиквел: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.
Потом я до лета ухожу в отпуск, и буду работать только точечно с людьми, которые у меня консультируются и проходят менторинг (есть и такая опция!)
А ещё в ближайшее время будет запускается несколько курсов от хороших друзей, о чем напишу на неделе, не переключайтесь! 📺👀
Не успел опомниться от Winter Analytical Weekend, а скоро уже и весенний Flow, где я эксперт и член ПК.
Программа Flow готова уже на 100%, это будет интенсив в онлайне 12 марта, и будет много докладов про самые практические вещи в работе аналитика: про требования, интеграции и архитектуру. Ну и про ИИ, куда же теперь без него!
Часть программы уже на сайте, а цена более чем демократичная.
Вероятно, я там буду в качестве эксперта представлять некоторые доклады, а может даже и вести дискуссию в главной студии. Хороший подарок прямо к моему дню рождения!
А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.
Курс, на самом деле, просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.
А в апреле будет его сиквел: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.
Потом я до лета ухожу в отпуск, и буду работать только точечно с людьми, которые у меня консультируются и проходят менторинг (есть и такая опция!)
А ещё в ближайшее время будет запускается несколько курсов от хороших друзей, о чем напишу на неделе, не переключайтесь! 📺
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15
Продолжу про чек-листы из Essence (из ГОСТ 57195).
Я, когда не забываю, обязательно включаю формулировки из них в план проекта. Эти чек-листы "капитанские", но, как любой чек-лист, почти всегда выполняются, но если вдруг один пункт не выполняется — это окупает все предыдущие разы.
Вот, например, чек-листы к "Требованиям":
Состояние "Сформулированы":
✅ Первоначальная группа заинтересованных сторон согласна, что система должна быть произведена.
✅ Заинтересованные стороны, которые будут использовать новую систему, идентифицированы.
✅ Заинтересованные стороны, которые профинансируют начальную работу по созданию новой системы, идентифицированы.
✅ Существует очевидная возможность, которую реализует новая система.
Тут вроде всё очевидно, нужно понять — что делаем, зачем, кто будет пользоваться и кто оплатит.
Состояние "Требования ограничены":
✅ Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы.
✅ Заинтересованные стороны согласны с назначением новой системы.
✅ Определено, что будет считаться положительным эффектом от внедрения новой системы.
✅ Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения.
✅ Технология описания требований согласована.
✅ Механизмы управления требованиями есть в наличии.
✅ Приоритезационная схема ясна.
✅ Ограничения определены и приняты во внимание.
✅ Допущения ясно сформулированы.
Вот тут уже начинаются проблемы. Положительный эффект? Далеко не в каждом проекте удается зафиксировать. Пределы решения? (Можно ещё перевести, как границы). Не всегда фиксируют. Да ещё чтобы все их поняли?
Технология описания. То есть, мы в каком виде требования формулируем? User story? JTBD? Классические ФТ?
Механизмы управления требованиями? Это вообще что?
и т.д.
Конечно, можно прожить и без этого. Тут как с дефектами: само по себе наличие дефектов в системе ещё не означает, что это дефект проявится. То, что вы не поставили галочку в чек-листе, ещё не значит, что проект обязательно провалится. Но это риск. В стандарте этого нет, но к каждому пункту можно приписать набор рисков, которые могут сработать, если это состояние не достигнуто.
Отсутствие приоритезационной схемы может повлечь впихивание в продукт функций по принципу "приоритет у того, кто громче кричит". Отсутствие механизмов управления приводит к проблемам с устаревшими требованиями и соотнесением релизов с набором требований.
Про непроговоренные со стейкхолдерами пределы, допущения и ограничения даже не буду говорить, не люблю ужастики.
В общем, всё это может не выстрелить, но в какой-то момент — особенно когда вы руководите системным анализом не одном проекте, а, скажем, в пяти-шести.
Я так в один момент обнаружил, что у меня в проекте есть в каком-то виде все 30 процессов, описанных в ISO 12207, и за всеми нужно приглядывать, и хорошо бы их как-то разложить на людей, а не контролировать каждый самому. Первый признак инженерной деятельности — систематизация.
Возвращаясь к чек-листам: замечательные пункты
✅ Происхождение требований ясно.
✅ Обоснование требований ясно.
Вот тут, боюсь, 80% проектов и срежется. Откуда вообще эти требования взялись? Ну, это же "по умолчанию". Это "система так требует". "Эти требования мы всегда вписываем". "Нам на курсах сказали, что так надо". "Это было в примере". "Заказчик сказал, что это нужно обязательно". Нет, я понимаю, что никогда нет времени разбираться с этим, потому что и так часов мало. Но тогда какие риски мы принимаем и не учитываем?
Я, когда не забываю, обязательно включаю формулировки из них в план проекта. Эти чек-листы "капитанские", но, как любой чек-лист, почти всегда выполняются, но если вдруг один пункт не выполняется — это окупает все предыдущие разы.
Вот, например, чек-листы к "Требованиям":
Состояние "Сформулированы":
✅ Первоначальная группа заинтересованных сторон согласна, что система должна быть произведена.
✅ Заинтересованные стороны, которые будут использовать новую систему, идентифицированы.
✅ Заинтересованные стороны, которые профинансируют начальную работу по созданию новой системы, идентифицированы.
✅ Существует очевидная возможность, которую реализует новая система.
Тут вроде всё очевидно, нужно понять — что делаем, зачем, кто будет пользоваться и кто оплатит.
Состояние "Требования ограничены":
✅ Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы.
✅ Заинтересованные стороны согласны с назначением новой системы.
✅ Определено, что будет считаться положительным эффектом от внедрения новой системы.
✅ Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения.
✅ Технология описания требований согласована.
✅ Механизмы управления требованиями есть в наличии.
✅ Приоритезационная схема ясна.
✅ Ограничения определены и приняты во внимание.
✅ Допущения ясно сформулированы.
Вот тут уже начинаются проблемы. Положительный эффект? Далеко не в каждом проекте удается зафиксировать. Пределы решения? (Можно ещё перевести, как границы). Не всегда фиксируют. Да ещё чтобы все их поняли?
Технология описания. То есть, мы в каком виде требования формулируем? User story? JTBD? Классические ФТ?
Механизмы управления требованиями? Это вообще что?
и т.д.
Конечно, можно прожить и без этого. Тут как с дефектами: само по себе наличие дефектов в системе ещё не означает, что это дефект проявится. То, что вы не поставили галочку в чек-листе, ещё не значит, что проект обязательно провалится. Но это риск. В стандарте этого нет, но к каждому пункту можно приписать набор рисков, которые могут сработать, если это состояние не достигнуто.
Отсутствие приоритезационной схемы может повлечь впихивание в продукт функций по принципу "приоритет у того, кто громче кричит". Отсутствие механизмов управления приводит к проблемам с устаревшими требованиями и соотнесением релизов с набором требований.
Про непроговоренные со стейкхолдерами пределы, допущения и ограничения даже не буду говорить, не люблю ужастики.
В общем, всё это может не выстрелить, но в какой-то момент — особенно когда вы руководите системным анализом не одном проекте, а, скажем, в пяти-шести.
Я так в один момент обнаружил, что у меня в проекте есть в каком-то виде все 30 процессов, описанных в ISO 12207, и за всеми нужно приглядывать, и хорошо бы их как-то разложить на людей, а не контролировать каждый самому. Первый признак инженерной деятельности — систематизация.
Возвращаясь к чек-листам: замечательные пункты
✅ Происхождение требований ясно.
✅ Обоснование требований ясно.
Вот тут, боюсь, 80% проектов и срежется. Откуда вообще эти требования взялись? Ну, это же "по умолчанию". Это "система так требует". "Эти требования мы всегда вписываем". "Нам на курсах сказали, что так надо". "Это было в примере". "Заказчик сказал, что это нужно обязательно". Нет, я понимаю, что никогда нет времени разбираться с этим, потому что и так часов мало. Но тогда какие риски мы принимаем и не учитываем?
👍17❤3
На WAW много говорили о развитии системных аналитиков и возможном карьерном пути.
Почему-то считается, что следующий шаг в карьере для СА — это архитектор (развитие технической экспертизы и навыков проектирования) или продакт-менеджер (развитие в сторону бизнес-потребностей, выявления и представления интересов пользователей, когда их очень много, и с каждым не поговоришь).
Между этими направлениями есть Technical Product Manager, человек, отвечающий за стратегию технологического развития продукта (такой продвинутый в технике Product Owner), в отличие от PMа, который больше про продуктовые метрики и маркетинг. Да, менеджеры продуктов тоже постоянно находятся в поисках себя и самоопределении.
Но был также доклад Бориса Вольфсона, который описал ещё одно направление развития: стратегический консалтинг. Это разработка и имплементация не просто технической стратегии, а бизнесовой. И у опытного фулл-стек аналитика есть все качества для этого:
🔸умение прослеживать связи от бизнес-показателей до конкретных процессов;
🔸 учёт многих факторов и точек зрения;
🔸 умение организовать и фасилитировать продуктивные встречи;
🔸 навык упаковки идей в компактную форму с отточенными формулировками;
🔸 навык проектирования метрик для процессов;
🔸 навык убеждения :)
🔸 и одно из самых важных: навык говорить "нет" и отказываться от лишних фич, а в случае стратегии — о лишних продуктов, рынков и направлений, т.к. стратегия — это про фокусировку.
Я не очень-то думал в эту сторону, хотя сам занимался построением стратегии и проведением стратегических сессий! И знаю людей, которые тоже выходят на разработку стратегии, находясь на высоких позициях в анализе.
Борис, со своей стороны, считает, что системность подхода и внимательность к деталям — это то, что может очень здорово помочь топам, т.к. они зачастую этими качествами не обладают. И это тоже правда, у них там другое — смелость, харизма, политическое чутье, умение воспользоваться шансом, а вот проработка детальных стратегий, на удивление, не всегда сильная сторона.
В докладе был предложен конкретный фреймворк (мы же любим фреймворки!):
Playing-to-Win.
Модель из 5 частей:
Winning Aspiration — наше стремление, зачем вообще существует эта организация или команда?
Where to play — где мы играем? Что является нашим рынком и как его описать? И куда мы точно не идём.
How to win — как мы выигрываем? Что мы конкретно делаем, чтобы выиграть? В чём наше "нечестное преимущество"? И чего мы точно не делаем?
Capabilities — какие способности должны быть у компании, чтобы сыграть так, как мы спланировали? Что компания должна уметь делать? Можно оформить это в виде Activity System Map, которую предложил Портер.
Management System — и наконец, как всё это управляется?
Ответы на эти 5 вопросов и составляют стратегию, а книге (ну конечно, есть книга! Playing to Win: How Strategy Really Works, Roger Martin, Alan G. Lafley, 2013) описан в деталях воркшоп по разработке стратегии.
А Борис, со своей стороны, разработал "6-страничник" для описания стратегии, основанный на этом подходе.
Так что, если выдаётся возможность, старайтесь участвовать в разработке стратегии для вашей компании, это очень увлекательно и полезно! :)
Почему-то считается, что следующий шаг в карьере для СА — это архитектор (развитие технической экспертизы и навыков проектирования) или продакт-менеджер (развитие в сторону бизнес-потребностей, выявления и представления интересов пользователей, когда их очень много, и с каждым не поговоришь).
Между этими направлениями есть Technical Product Manager, человек, отвечающий за стратегию технологического развития продукта (такой продвинутый в технике Product Owner), в отличие от PMа, который больше про продуктовые метрики и маркетинг. Да, менеджеры продуктов тоже постоянно находятся в поисках себя и самоопределении.
Но был также доклад Бориса Вольфсона, который описал ещё одно направление развития: стратегический консалтинг. Это разработка и имплементация не просто технической стратегии, а бизнесовой. И у опытного фулл-стек аналитика есть все качества для этого:
🔸умение прослеживать связи от бизнес-показателей до конкретных процессов;
🔸 учёт многих факторов и точек зрения;
🔸 умение организовать и фасилитировать продуктивные встречи;
🔸 навык упаковки идей в компактную форму с отточенными формулировками;
🔸 навык проектирования метрик для процессов;
🔸 навык убеждения :)
🔸 и одно из самых важных: навык говорить "нет" и отказываться от лишних фич, а в случае стратегии — о лишних продуктов, рынков и направлений, т.к. стратегия — это про фокусировку.
Я не очень-то думал в эту сторону, хотя сам занимался построением стратегии и проведением стратегических сессий! И знаю людей, которые тоже выходят на разработку стратегии, находясь на высоких позициях в анализе.
Борис, со своей стороны, считает, что системность подхода и внимательность к деталям — это то, что может очень здорово помочь топам, т.к. они зачастую этими качествами не обладают. И это тоже правда, у них там другое — смелость, харизма, политическое чутье, умение воспользоваться шансом, а вот проработка детальных стратегий, на удивление, не всегда сильная сторона.
В докладе был предложен конкретный фреймворк (мы же любим фреймворки!):
Playing-to-Win.
Модель из 5 частей:
Winning Aspiration — наше стремление, зачем вообще существует эта организация или команда?
Where to play — где мы играем? Что является нашим рынком и как его описать? И куда мы точно не идём.
How to win — как мы выигрываем? Что мы конкретно делаем, чтобы выиграть? В чём наше "нечестное преимущество"? И чего мы точно не делаем?
Capabilities — какие способности должны быть у компании, чтобы сыграть так, как мы спланировали? Что компания должна уметь делать? Можно оформить это в виде Activity System Map, которую предложил Портер.
Management System — и наконец, как всё это управляется?
Ответы на эти 5 вопросов и составляют стратегию, а книге (ну конечно, есть книга! Playing to Win: How Strategy Really Works, Roger Martin, Alan G. Lafley, 2013) описан в деталях воркшоп по разработке стратегии.
А Борис, со своей стороны, разработал "6-страничник" для описания стратегии, основанный на этом подходе.
Так что, если выдаётся возможность, старайтесь участвовать в разработке стратегии для вашей компании, это очень увлекательно и полезно! :)
👍14🔥3❤2😁1