Как же называется эта книга?
Рэймонд М. Смаллиан. Год издания 2021
Открыла вчера эту книгу. Оригинал относится к 1978му году, первый перевод вышел тремя годами позже, а мне попалось издание 2021 года. Это сборник логических задачек с вводными от автора и детальным разбором решений. Задачи идут от простых бытовых к более сложным логическим комбинациям. Каждый раздел в своем контексте и объединяет задачи на конкретную тему и конкретное логическое правило. Я прошла пока только часть:
📍"Головоломки и дурацкие штучки", где собраны логические заморочки на бытовом уровне. Например: Что произойдет, если всесокрушающее ядро попадет в несокрушимый столб?
📍"Рыцари и лжецы", где рыцари всегда говорят правду, а лжецы всегда врут
📍"Алиса в лесу Забывчивости", где живут львы и единороги, которые врут или говорят правду в конкретные дни недели
📍"Из записок инспектора Крэга" с задачками про расследование преступлений. Одну такую задачку напишу ниже, вы пока подумайте, а я дочитаю и завтра напишу ответ в комментариях 😉
Еще есть задачки про оборотней, зомби и других персонажей. По сложности фантазий напоминает книгу Льюиса Кэррола "Алиса в стране чудес"
Что может быть полезно?
Решать логические задачки само по себе не вредно. Есть задачки простые, а есть сложные, в которых можно закопаться надолго и с пользой для мозга провести время.
Я еще не добралась до последних глав, но с удовольствием залипла на задачках средней сложности. Узнала слово "импликация" – это зависимости вида "Если P, то Q".
Кому может быть полезно?
Думаю, что полезно всем, кому интересно потренировать логическое мышление.
#книжки
Рэймонд М. Смаллиан. Год издания 2021
Открыла вчера эту книгу. Оригинал относится к 1978му году, первый перевод вышел тремя годами позже, а мне попалось издание 2021 года. Это сборник логических задачек с вводными от автора и детальным разбором решений. Задачи идут от простых бытовых к более сложным логическим комбинациям. Каждый раздел в своем контексте и объединяет задачи на конкретную тему и конкретное логическое правило. Я прошла пока только часть:
📍"Головоломки и дурацкие штучки", где собраны логические заморочки на бытовом уровне. Например: Что произойдет, если всесокрушающее ядро попадет в несокрушимый столб?
📍"Рыцари и лжецы", где рыцари всегда говорят правду, а лжецы всегда врут
📍"Алиса в лесу Забывчивости", где живут львы и единороги, которые врут или говорят правду в конкретные дни недели
📍"Из записок инспектора Крэга" с задачками про расследование преступлений. Одну такую задачку напишу ниже, вы пока подумайте, а я дочитаю и завтра напишу ответ в комментариях 😉
Еще есть задачки про оборотней, зомби и других персонажей. По сложности фантазий напоминает книгу Льюиса Кэррола "Алиса в стране чудес"
Что может быть полезно?
Решать логические задачки само по себе не вредно. Есть задачки простые, а есть сложные, в которых можно закопаться надолго и с пользой для мозга провести время.
Я еще не добралась до последних глав, но с удовольствием залипла на задачках средней сложности. Узнала слово "импликация" – это зависимости вида "Если P, то Q".
Кому может быть полезно?
Думаю, что полезно всем, кому интересно потренировать логическое мышление.
#книжки
🔥3🤩2
Задачка
На складе было совершено крупное хищение. Преступник (или преступники) вывез награбленное на автомашине. Подозрение пало на трех преступников-рецидивистов А, В и С. Было установлено следующее:
1) Никто, кроме А, В и С, не был замешан в хищении.
2) С никогда не ходит на дело без А (и, возможно, других соучастников).
3) В не умеет водить машину.
Виновен или невиновен А? Напишите ответ в комментарии, завтра поделюсь решением из книжки😎
На складе было совершено крупное хищение. Преступник (или преступники) вывез награбленное на автомашине. Подозрение пало на трех преступников-рецидивистов А, В и С. Было установлено следующее:
1) Никто, кроме А, В и С, не был замешан в хищении.
2) С никогда не ходит на дело без А (и, возможно, других соучастников).
3) В не умеет водить машину.
Виновен или невиновен А? Напишите ответ в комментарии, завтра поделюсь решением из книжки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Что важно для выявления требований?
В выходные прочитала пару постов и статей о сборе\выявлении требований. Столько уже придумано гайдов и фреймворков о том как разговаривать с пользователем, чтобы все выявить! А почему-то не гаснут дискуссии на тему «я все сделал как надо, а они все равно недовольны и меняют требования». Неужели фреймворки не работают? Скорее всего работают, но только для каждого важен свой контекст и точка зрения.
Поделюсь несколькими моментами, которые мне помогают получать информацию для требований.
1️⃣«Знать, а казаться незнающим, — вот совершенство. Не знать, а думать, что знаешь — это болезнь.» Набрела недавно на эту цитату из даосского философского трактата «Дао Дэ Цзин» и формулировки сложились сами собой. Как часто вы идете на встречу с живым желанием услышать что-то новое, а не подтвердить услышанное или выведенное из вашего опыта? Можно пропустить большой пласт информации, если не убрать далеко в сторону кем-то навязанные знания или предварительные выводы.
Например, вы слышите на интервью, что кнопка неудобно расположена, а в голове прокручиваете "ну да, предыдущий аналитик предупреждал, что у них куча капризов" или "это исправлять сложно, так что пойдем дальше". Можно на минуту притвориться, что у вас нет этого знания, и просто спросить "А зачем вы ее нажимаете вообще? Зачем каждый раз так делаете, если неудобно?". Можно узнать, что дело в нелогичном переходе с предыдущей формы, а вовсе не с этой кнопкой, которую сложно подвинуть. И тут мы переходим к следующему пункту.
2️⃣Пользователь может не осознавать того, что мы называем требованиями. Мне нравится как это сказано в книге Синди Альварес «Как создать продукт, который купят»
Глядя на мир из-под опыта построения ИТ-систем, мы часто ждем формулировок в привычной логике и не получаем их или, что еще хуже, получаем что-то что звучит для нас убедительно, но ничего не значит для говорящего. Он просто сказал что-то, что от него ждут, или придумал налету.
На меня когда-то большое впечатление произвело как Алан Купер определил группу уцелевших пользователей
Это фраза из 90х, но и в контексте сегодняшнего дня тоже встречается что-то подобное.
3️⃣Не получится узнать готовый ответ на все вопросы, нужно на основании полученной информации моделировать кейсы и приходить к собственным выводам. Гибкие методологии диктуют нам культуру обратной связи и мы начали ее собирать с ожиданием ответов на многие вопросы. Знать своего пользователя очень полезно, но целью активности должно быть прежде всего наблюдение и сбор информации, а не получение готовых рецептов. Часть требований вы сформулируете сами, на основании моделей, что сможете построить. Хотя и модели, бывает, врут 😊
📚
🔅Что здесь есть о выявлении требований? подборка постов об инструментах выявления требований на этом канале
🔅«Да», «Нет» и «Зачем» не говорить? подборка статей про важность отдельных слов и вопроса "Зачем?"
#мысливслух #что_почитать
В выходные прочитала пару постов и статей о сборе\выявлении требований. Столько уже придумано гайдов и фреймворков о том как разговаривать с пользователем, чтобы все выявить! А почему-то не гаснут дискуссии на тему «я все сделал как надо, а они все равно недовольны и меняют требования». Неужели фреймворки не работают? Скорее всего работают, но только для каждого важен свой контекст и точка зрения.
Поделюсь несколькими моментами, которые мне помогают получать информацию для требований.
1️⃣«Знать, а казаться незнающим, — вот совершенство. Не знать, а думать, что знаешь — это болезнь.» Набрела недавно на эту цитату из даосского философского трактата «Дао Дэ Цзин» и формулировки сложились сами собой. Как часто вы идете на встречу с живым желанием услышать что-то новое, а не подтвердить услышанное или выведенное из вашего опыта? Можно пропустить большой пласт информации, если не убрать далеко в сторону кем-то навязанные знания или предварительные выводы.
Например, вы слышите на интервью, что кнопка неудобно расположена, а в голове прокручиваете "ну да, предыдущий аналитик предупреждал, что у них куча капризов" или "это исправлять сложно, так что пойдем дальше". Можно на минуту притвориться, что у вас нет этого знания, и просто спросить "А зачем вы ее нажимаете вообще? Зачем каждый раз так делаете, если неудобно?". Можно узнать, что дело в нелогичном переходе с предыдущей формы, а вовсе не с этой кнопкой, которую сложно подвинуть. И тут мы переходим к следующему пункту.
2️⃣Пользователь может не осознавать того, что мы называем требованиями. Мне нравится как это сказано в книге Синди Альварес «Как создать продукт, который купят»
Ваш потребитель лучше всех знает, что мешает ему в его собственном мире. Но это не значит, что он может облечь свое знание в слова.
Глядя на мир из-под опыта построения ИТ-систем, мы часто ждем формулировок в привычной логике и не получаем их или, что еще хуже, получаем что-то что звучит для нас убедительно, но ничего не значит для говорящего. Он просто сказал что-то, что от него ждут, или придумал налету.
На меня когда-то большое впечатление произвело как Алан Купер определил группу уцелевших пользователей
Эти люди скрежещут зубами и поневоле мирятся с манерами программ, похожих на танцующих медведей. Они не знают, что компьютеры могут вести себя лучше, но знают, что каждый сеанс работы с компьютером заставляет их чувствовать себя менее уверенно, чем обычно. Подобно феодальным крестьянам средних веков, они не в силах изменить свой статус или хотя бы увидеть глубину собственных лишений, однако четко осознают, что их угнетают.
Это фраза из 90х, но и в контексте сегодняшнего дня тоже встречается что-то подобное.
3️⃣Не получится узнать готовый ответ на все вопросы, нужно на основании полученной информации моделировать кейсы и приходить к собственным выводам. Гибкие методологии диктуют нам культуру обратной связи и мы начали ее собирать с ожиданием ответов на многие вопросы. Знать своего пользователя очень полезно, но целью активности должно быть прежде всего наблюдение и сбор информации, а не получение готовых рецептов. Часть требований вы сформулируете сами, на основании моделей, что сможете построить. Хотя и модели, бывает, врут 😊
📚
🔅Что здесь есть о выявлении требований? подборка постов об инструментах выявления требований на этом канале
🔅«Да», «Нет» и «Зачем» не говорить? подборка статей про важность отдельных слов и вопроса "Зачем?"
#мысливслух #что_почитать
❤4🔥3💯1
Считай, смекай, отгадывай!
Труднев В.П., 1960
После книги Смаллиана решила поискать еще книги с логическими задачами, вдруг пригодится при подготовке к собесам? Отправила запрос в самую главную из моих библиотек, в библиотеку моих родителей. Это довольно большое и разнообразное книгохранилище, где есть много книг по математике. Когда-то в него перекочевали и книги моих бабушек и дедушек. Старые издания интересно держать в руках, потому что они не только носители информации, но и носители следов времени. В них все из прошлого века - от шрифтов до заметок на полях.
Судя по году издания и состоянию, по этой книге Труднева учился еще мой отец. Издания выходили в разные годы: 1960, 1964, 1970, 1980, 1996. Пригодится для подготовки будущих аналитиков лет с семи. В первых разделах объясняются свойства чисел и математических операций. Например, так: "Если ты начнешь считать до миллиарда десятилетним мальчиком, то закончишь счет глубоким 100-летним стариком, работая по 6 часов в сутки". Дальше идут разделы с задачками на вычисления и логику, вроде тех, что на картинках. Задания не требуют сложных вычислений, для большинства не нужно даже ничего записывать, их можно решать устно. Некоторые очень узнаваемы то ли из детства, то ли из задачек, когда-то ходивших по собеседованиям😎
Кому может быть полезно?
Родителям школьников можно решать вместе с детьми задачки на вычисления и логику, а заодно самим потренироваться. Преподавателям можно выбрать пару упражнений для разминки на тренинге.
#книжки
Труднев В.П., 1960
После книги Смаллиана решила поискать еще книги с логическими задачами, вдруг пригодится при подготовке к собесам? Отправила запрос в самую главную из моих библиотек, в библиотеку моих родителей. Это довольно большое и разнообразное книгохранилище, где есть много книг по математике. Когда-то в него перекочевали и книги моих бабушек и дедушек. Старые издания интересно держать в руках, потому что они не только носители информации, но и носители следов времени. В них все из прошлого века - от шрифтов до заметок на полях.
Судя по году издания и состоянию, по этой книге Труднева учился еще мой отец. Издания выходили в разные годы: 1960, 1964, 1970, 1980, 1996. Пригодится для подготовки будущих аналитиков лет с семи. В первых разделах объясняются свойства чисел и математических операций. Например, так: "Если ты начнешь считать до миллиарда десятилетним мальчиком, то закончишь счет глубоким 100-летним стариком, работая по 6 часов в сутки". Дальше идут разделы с задачками на вычисления и логику, вроде тех, что на картинках. Задания не требуют сложных вычислений, для большинства не нужно даже ничего записывать, их можно решать устно. Некоторые очень узнаваемы то ли из детства, то ли из задачек, когда-то ходивших по собеседованиям
Кому может быть полезно?
Родителям школьников можно решать вместе с детьми задачки на вычисления и логику, а заодно самим потренироваться. Преподавателям можно выбрать пару упражнений для разминки на тренинге.
#книжки
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2
Зачем ИТ-аналитикам CJM ?
Когда принялась за пост о CJM, то поняла, что не стану рассказывать как и зачем составляется карта клиентского пути. Это фреймворк, о котором никто не расскажет лучше, чем эксперты в CХ и UX, ниже несколько ссылок с теорией и примерами, которые будут полезны, если вы еще не сталкивались с этим инструментом.
По слову CJM на hh нашлось около тысячи вакансий, из которых 369 отнесены к сфере ИТ. Я познакомилась с этой картой на курсе управления клиентским опытом. Картинка с кучей скриншотов и стикеров – это снимок моего тогдашнего учебного проекта. Когда послушаешь мастеров-исследователей, которые глубоко разбирают мотивацию клиентов, исходя из законов социологии и психологии, то невольно думаешь, а бизнес и системным аналитикам это точно нужно? Прихожу к выводу, что понимание фреймворка точно не повредит и даст некоторое преимущество на рынке труда, но без четкого понимания зачем применяете, ни один инструмент не будет полезным и этот не исключение.
У любого раскрученного фреймворка основной проблемой становится применение "потому что модно", а не потому, что нужно. Кажется, что чем больше и красивее карта, тем полезнее. На деле получается, что карта внушительная, но непонятно, что делать дальше? Нашли какие-то идеи, записали, а сам процесс изменений клиентского пути так и не начался.
CJM – это таблица или ориентированный граф, отражающий путь потребителя между точками контакта. Мне как-то задали вопрос: Если это такая упорядоченная форма клиентского опыта, то можно же построить автоматическое формирование тест-кейсов на ее основе? Увы, это очень эмоциональный инструмент, каждая команда формирует под свои цели и своим языком. Автоматизация потребуется более сложная, чем if A is not EMPTY do B.
Я применяю CJM при исследовании предметной области или при знакомстве с новой для меня группой пользователей, чтобы упорядочить записи с полученной информацией и соображения относительно узких мест. Команды обычно реагируют на мои записи так: "Ух, как красиво! Но букв много и непонятно, что с ними делать." Так что это просто мой рабочий инструмент, который
🌱помогает мне разложить на шаги пользовательский путь,
🌱рассмотреть каждый шаг детально по слоям, заданным картой,
🌱зафиксировать идеи, чтобы вернуться к ним при выборе функционального решения.
Если составление карты не требуют как часть проектных артефактов (что в моем опыте бывало буквально один раз), то она остается частью моих рабочих материалов. Интересно, а ваших командах бывает нужно составить CJM?
📚
📍CJM: теория и примеры В статье есть примеры, составленные автором для S7, Ашана и Делимобиль. Все примеры в Миро, так что поспешите посмотреть 😉
📍Большое клиентское путешествие Описание основ и целей фреймворка
📍Что такое CJM: на примере покупки «теслы» В статье есть ссылки на примеры карт для Яндекс.Такси и для Самоката
#что_почитать #инструменты
Когда принялась за пост о CJM, то поняла, что не стану рассказывать как и зачем составляется карта клиентского пути. Это фреймворк, о котором никто не расскажет лучше, чем эксперты в CХ и UX, ниже несколько ссылок с теорией и примерами, которые будут полезны, если вы еще не сталкивались с этим инструментом.
По слову CJM на hh нашлось около тысячи вакансий, из которых 369 отнесены к сфере ИТ. Я познакомилась с этой картой на курсе управления клиентским опытом. Картинка с кучей скриншотов и стикеров – это снимок моего тогдашнего учебного проекта. Когда послушаешь мастеров-исследователей, которые глубоко разбирают мотивацию клиентов, исходя из законов социологии и психологии, то невольно думаешь, а бизнес и системным аналитикам это точно нужно? Прихожу к выводу, что понимание фреймворка точно не повредит и даст некоторое преимущество на рынке труда, но без четкого понимания зачем применяете, ни один инструмент не будет полезным и этот не исключение.
У любого раскрученного фреймворка основной проблемой становится применение "потому что модно", а не потому, что нужно. Кажется, что чем больше и красивее карта, тем полезнее. На деле получается, что карта внушительная, но непонятно, что делать дальше? Нашли какие-то идеи, записали, а сам процесс изменений клиентского пути так и не начался.
CJM – это таблица или ориентированный граф, отражающий путь потребителя между точками контакта. Мне как-то задали вопрос: Если это такая упорядоченная форма клиентского опыта, то можно же построить автоматическое формирование тест-кейсов на ее основе? Увы, это очень эмоциональный инструмент, каждая команда формирует под свои цели и своим языком. Автоматизация потребуется более сложная, чем if A is not EMPTY do B.
Я применяю CJM при исследовании предметной области или при знакомстве с новой для меня группой пользователей, чтобы упорядочить записи с полученной информацией и соображения относительно узких мест. Команды обычно реагируют на мои записи так: "Ух, как красиво! Но букв много и непонятно, что с ними делать." Так что это просто мой рабочий инструмент, который
🌱помогает мне разложить на шаги пользовательский путь,
🌱рассмотреть каждый шаг детально по слоям, заданным картой,
🌱зафиксировать идеи, чтобы вернуться к ним при выборе функционального решения.
Если составление карты не требуют как часть проектных артефактов (что в моем опыте бывало буквально один раз), то она остается частью моих рабочих материалов. Интересно, а ваших командах бывает нужно составить CJM?
📚
📍CJM: теория и примеры В статье есть примеры, составленные автором для S7, Ашана и Делимобиль. Все примеры в Миро, так что поспешите посмотреть 😉
📍Большое клиентское путешествие Описание основ и целей фреймворка
📍Что такое CJM: на примере покупки «теслы» В статье есть ссылки на примеры карт для Яндекс.Такси и для Самоката
#что_почитать #инструменты
👍6❤2
Учебный год и офферы
На этой неделе начался учебный год, а я так и не написала ни слова про учебу и знания. Решила рассказать несколько историй.
Где-то в семейном архиве есть фото пятидесятилетней давности. На нем десяток широкоплечих парней лет 19ти, с длинными прическами по моде 70х, в брюках-клеш и клетчатых рубашках позируют на фоне доски, у учительского стола. Среди них худенькая застенчивая девушка - преподаватель математики выпускного курса ПТУ, моя мама. В свои двадцать с небольшим она - Ольга Петровна для этих вот парней, среди которых встречались и условно осужденные.
Еще есть фото, где мой отец - молодой преподаватель, у доски внушает студенткам педагогического института что-то из мат.анализа. Студентки улыбчиво смотрят в объектив, потому что снимок это надолго, а с мат. анализом еще непонятно. И только преподаватель серьезно хмурится на свои меловые зарисовки на доске.
Когда-то коробка с мелом стояла дома в прихожей. Мне из нее нельзя было взять мелок, потому что этот мел для записи линейных многочленов на доске, а не для рисования легкомысленных зайцев на асфальте 🐇 Это когда в 90е в университете даже мел куда-то делся, на лекции брался свой.
В 80х в некоторых семьях на дверце холодильника хранились лекарства или даже конфеты, а в преподавательской семье там были лента для пишущей машинки и пузырек спирта. Папа пишет диссертацию, а ее надо писать буквами на пишущей машинке. Чешской рыже-белой капризной красавице нужно буквы протирать спиртом и заправлять хорошую чернильную ленту, чтобы эти буквы потом можно было прочитать. Такие ценные вещи держат в холодильнике, потому что если лента засохнет, а спирт испарится, то научная мысль может иссякнуть.
Дома никто не хотел, чтобы я стала преподавателем. До сих пор считатают это неблагодарным делом. Но, видимо, есть какие-то законы природы, которые меня ведут в это занятие. Мне нравится идея менторства как помощи в получении знаний и умений. Уже несколько лет помогаю разбираться в инструментах анализа тем, кому это интересно.
Несколько месяцев назад менти написала, что получила оффер в большую компанию. Я дня три летала в прекрасном настроении. Мы занимались около восьми месяцев, это был путь от "мне дали почитать Вигерса" до решения замороченных тестовых кейсов. Недавно от другой менти пришло сообщение: "Настя, мне сделали оффер..." И снова несколько дней я в приподнятом состоянии. Успех каждого - это, прежде всего, результат его собственных усилий, но как же здорово понимать, что и я смогла как-то эти усилия поддержать и направить! Тут начинаешь догадываться как может чувствовать себя учитель на выпускном и почему учителю результаты экзаменов бывают интереснее, чем самому ученику 😊
День знаний у каждого свой и в свое время, я это и по семейным архивам знаю и по личному опыту 🌱
#мысливслух #истории
На этой неделе начался учебный год, а я так и не написала ни слова про учебу и знания. Решила рассказать несколько историй.
Где-то в семейном архиве есть фото пятидесятилетней давности. На нем десяток широкоплечих парней лет 19ти, с длинными прическами по моде 70х, в брюках-клеш и клетчатых рубашках позируют на фоне доски, у учительского стола. Среди них худенькая застенчивая девушка - преподаватель математики выпускного курса ПТУ, моя мама. В свои двадцать с небольшим она - Ольга Петровна для этих вот парней, среди которых встречались и условно осужденные.
Еще есть фото, где мой отец - молодой преподаватель, у доски внушает студенткам педагогического института что-то из мат.анализа. Студентки улыбчиво смотрят в объектив, потому что снимок это надолго, а с мат. анализом еще непонятно. И только преподаватель серьезно хмурится на свои меловые зарисовки на доске.
Когда-то коробка с мелом стояла дома в прихожей. Мне из нее нельзя было взять мелок, потому что этот мел для записи линейных многочленов на доске, а не для рисования легкомысленных зайцев на асфальте 🐇 Это когда в 90е в университете даже мел куда-то делся, на лекции брался свой.
В 80х в некоторых семьях на дверце холодильника хранились лекарства или даже конфеты, а в преподавательской семье там были лента для пишущей машинки и пузырек спирта. Папа пишет диссертацию, а ее надо писать буквами на пишущей машинке. Чешской рыже-белой капризной красавице нужно буквы протирать спиртом и заправлять хорошую чернильную ленту, чтобы эти буквы потом можно было прочитать. Такие ценные вещи держат в холодильнике, потому что если лента засохнет, а спирт испарится, то научная мысль может иссякнуть.
Дома никто не хотел, чтобы я стала преподавателем. До сих пор считатают это неблагодарным делом. Но, видимо, есть какие-то законы природы, которые меня ведут в это занятие. Мне нравится идея менторства как помощи в получении знаний и умений. Уже несколько лет помогаю разбираться в инструментах анализа тем, кому это интересно.
Несколько месяцев назад менти написала, что получила оффер в большую компанию. Я дня три летала в прекрасном настроении. Мы занимались около восьми месяцев, это был путь от "мне дали почитать Вигерса" до решения замороченных тестовых кейсов. Недавно от другой менти пришло сообщение: "Настя, мне сделали оффер..." И снова несколько дней я в приподнятом состоянии. Успех каждого - это, прежде всего, результат его собственных усилий, но как же здорово понимать, что и я смогла как-то эти усилия поддержать и направить! Тут начинаешь догадываться как может чувствовать себя учитель на выпускном и почему учителю результаты экзаменов бывают интереснее, чем самому ученику 😊
День знаний у каждого свой и в свое время, я это и по семейным архивам знаю и по личному опыту 🌱
#мысливслух #истории
❤8🥰5❤🔥2👍1
Функциональная декомпозиция
В работе аналитика функциональная декомпозиция выглядит чем-то очень базовым и от этого еще интереснее о ней порассуждать.
Строго говоря, декомпозировать можно не только функции, но и процессы, цели, задачи, роли, компоненты ИТ-архитектуры, источники и результаты работы системы. Аналитики чаще всего имеют дело с функциями. С них обычно начинается любой разговор о будущей системе: "Нам нужно, чтобы система умела....."
Вот такая рекомендация есть в книге "Принципы работы с требованиями к программному обеспечению" Дина Леффингуэлла и Дона Уидрига
Как не запутаться в таком количестве функций? Постепенно двигаться от высокого уровня абстракции к более детальному, то есть разбирая каждую функцию на составляющие до того уровня, которым будет проще управлять. Количество уровней зависит от объема и сложности задачи. Для небольших задач достаточно глубины в 2-3 уровня, для сложных потребуется больше.
Как это поможет? Разбирая сложное на небольшие измеримые части можно добраться до детального понимания, отследить как связаны между собой эти части и найти точки улучшения.
📍Это помогает выявлять и документировать требования по четкой структуре, соответственно декомпозиции.
📍Обозримая упорядоченная структура помогает понять объем задачи или изменений. Так проще заметить разрастание объема и не потерять фокус на основных целях.
📍Измеримым под-функциям проще определить приоритет и запланировать затраты на разработку.
📍При обсуждениях проще выстроить общее понимание сложной системы, если разделить составляющие на более простые части.
Было бы нечестно промолчать про ограничения:
▫️За декомпозиций функций можно упустить другие важные вещи: потоки данных или взаимодействие пользователей. Узкий взгляд именно на функции приводит к потере других важных составляющих системы. Я здесь под "системой" имею в виду именно совокупность взаимодействующих объектов, не обязательно автоматизацию.
▫️Декомпозиция часто основана на предположениях о процессах и связях между функциями. Предположения могут быть ошибочными, в результате вместо прозрачности и упрощения привести к путанице и непониманию.
▫️При функциональной декомпозиции остаются без внимания нефункциональные требования, о которых важно не забыть.
▫️Для сложных систем иерархия функций может оказаться многоуровневой и содержать непростые зависимости между разными уровнями. Обратите внимание, на картинке дерево функций (Feature tree) из статьи К. Вигерса Using Feature Trees To Depict Scope. Здесь всего три уровня, но выглядит ли картина простой?
Сама по себе функциональная декомпозиция не приведет к пониманию всех связей между элементами системы, но задаст ход мысли от общего к частному и поможет подсветить, где искать эти элементы и связи
P.S. В этом контексте вспомнила давний обзор статьи о масштабируемой структуре требований, там есть пример декомпозиции в формате mind map.
#инструменты
В работе аналитика функциональная декомпозиция выглядит чем-то очень базовым и от этого еще интереснее о ней порассуждать.
Строго говоря, декомпозировать можно не только функции, но и процессы, цели, задачи, роли, компоненты ИТ-архитектуры, источники и результаты работы системы. Аналитики чаще всего имеют дело с функциями. С них обычно начинается любой разговор о будущей системе: "Нам нужно, чтобы система умела....."
Вот такая рекомендация есть в книге "Принципы работы с требованиями к программному обеспечению" Дина Леффингуэлла и Дона Уидрига
Количество функций, которое мы позволяем себе рассматривать, будет существенно влиять на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, мы рекомендуем описывать возможности каждой новой системы или дополнения к уже существующей системе как можно более абстрактно, чтобы в результате получить не более 25-99 функций, причем желательно, чтобы их число не превышало 50.
Как не запутаться в таком количестве функций? Постепенно двигаться от высокого уровня абстракции к более детальному, то есть разбирая каждую функцию на составляющие до того уровня, которым будет проще управлять. Количество уровней зависит от объема и сложности задачи. Для небольших задач достаточно глубины в 2-3 уровня, для сложных потребуется больше.
Как это поможет? Разбирая сложное на небольшие измеримые части можно добраться до детального понимания, отследить как связаны между собой эти части и найти точки улучшения.
📍Это помогает выявлять и документировать требования по четкой структуре, соответственно декомпозиции.
📍Обозримая упорядоченная структура помогает понять объем задачи или изменений. Так проще заметить разрастание объема и не потерять фокус на основных целях.
📍Измеримым под-функциям проще определить приоритет и запланировать затраты на разработку.
📍При обсуждениях проще выстроить общее понимание сложной системы, если разделить составляющие на более простые части.
Было бы нечестно промолчать про ограничения:
▫️За декомпозиций функций можно упустить другие важные вещи: потоки данных или взаимодействие пользователей. Узкий взгляд именно на функции приводит к потере других важных составляющих системы. Я здесь под "системой" имею в виду именно совокупность взаимодействующих объектов, не обязательно автоматизацию.
▫️Декомпозиция часто основана на предположениях о процессах и связях между функциями. Предположения могут быть ошибочными, в результате вместо прозрачности и упрощения привести к путанице и непониманию.
▫️При функциональной декомпозиции остаются без внимания нефункциональные требования, о которых важно не забыть.
Каждый сложный объект допускает несколько альтернативных декомпозиций. Исследование всех альтернатив может быть сложной и трудоемкой задачей, тогда как выбор единственной альтернативы может игнорировать важные возможности и привести к неоптимальному решению (Из BABOK 3.0)
▫️Для сложных систем иерархия функций может оказаться многоуровневой и содержать непростые зависимости между разными уровнями. Обратите внимание, на картинке дерево функций (Feature tree) из статьи К. Вигерса Using Feature Trees To Depict Scope. Здесь всего три уровня, но выглядит ли картина простой?
Сама по себе функциональная декомпозиция не приведет к пониманию всех связей между элементами системы, но задаст ход мысли от общего к частному и поможет подсветить, где искать эти элементы и связи
P.S. В этом контексте вспомнила давний обзор статьи о масштабируемой структуре требований, там есть пример декомпозиции в формате mind map.
#инструменты
👍3🔥2
3 статьи про коммуникации. Подборка
Заглянула в свой расползающийся список для чтения. Я придирчивый читатель, из десятка статей на темы коммуникации с заинтересованными сторонами выбрала три, которые на мой взгляд могут быть полезными.
📍Как провести встречу по сбору требований и не провалиться В этой статье мне очень понравилась первая часть рекомендаций к сбору информации перед встречей. Дальше рекомендации по составлению повестки встречи и фиксации результатов, которые вряд ли удивят аналитиков с опытом
📍Эффективное управление отношениями со стейкхолдерами Это перевод статьи из блога Miro, похоже на инструкцию, где перечислены основные инструменты управления заинтересованными сторонами
📍Берем ответственность за вопросы: как задавать их правильно Статья о роли вопросов в коммуникации, еще в ней есть описание методов "5 почему" и "Score+", может быть интересно, если еще не сталкивались с этими методами
#что_почитать
Заглянула в свой расползающийся список для чтения. Я придирчивый читатель, из десятка статей на темы коммуникации с заинтересованными сторонами выбрала три, которые на мой взгляд могут быть полезными.
📍Как провести встречу по сбору требований и не провалиться В этой статье мне очень понравилась первая часть рекомендаций к сбору информации перед встречей. Дальше рекомендации по составлению повестки встречи и фиксации результатов, которые вряд ли удивят аналитиков с опытом
📍Эффективное управление отношениями со стейкхолдерами Это перевод статьи из блога Miro, похоже на инструкцию, где перечислены основные инструменты управления заинтересованными сторонами
📍Берем ответственность за вопросы: как задавать их правильно Статья о роли вопросов в коммуникации, еще в ней есть описание методов "5 почему" и "Score+", может быть интересно, если еще не сталкивались с этими методами
#что_почитать
👍4🔥2
ИТ инсайды
Собрались вместе с другими авторами в папку "ИТ инсайды". В ней 9 каналов.
Ребята рассказывают очень ярко и эмоционально про свою работу, про тренды в ИТ, про PR, безу и менеджмент.
А еще, про СА и БА, GO, фронтенд и, конечно, AI. И, периодически, делают обзоры с крупнейших ИТ конференций.
Перейти к папке "ИТ инсайды"
Собрались вместе с другими авторами в папку "ИТ инсайды". В ней 9 каналов.
Ребята рассказывают очень ярко и эмоционально про свою работу, про тренды в ИТ, про PR, безу и менеджмент.
А еще, про СА и БА, GO, фронтенд и, конечно, AI. И, периодически, делают обзоры с крупнейших ИТ конференций.
Перейти к папке "ИТ инсайды"
Telegram
ИТ Инсайды
Русанова Саша IT devrel HR invites you to add the folder “ИТ Инсайды”, which includes 9 chats.
👍2🤩2
Информация и еда на Flow
Приехала на оффлайн-часть конференции Flow в Санкт-Петербург. Я очень хорошо себя чувствую в формате, когда еда, кофе и комфорт где-то неподалеку, а мне остается только получать информацию. Поэтому и приехала. Вот только, когда не выбираешься из отеля, то мозг отказывается верить, что я в другом городе 💁♀️
Приятно было увидеть среди участников и организаторов коллег, кого обычно вижу на видео или читаю в их каналах. Не помню, когда видела столько известных экспертов в одном зале одновременно. Может быть, просто я раньше не читала столько экспертных телеграмм-каналов? 😊
Вчера, в первый из двух оффлайн - дней послушала 5 докладов, расскажу о двух.
📍Расчет надежности на этапе системного анализа. Докладчик рассказал как просчитывал надежность системы, на основании данных о надежности ее отдельных компонентов. Предлагается представить систему как параллельно или последовательно связанные сервисы, по аналогии с электросетью, и из вероятности бесперебойной работы каждого подсчитать аналогичную вероятность для всей системы. Подход вызвал массу вопросов в части сбора такой статистики, влияния нагрузки на надежность системы, влияния нестабильности сети, учета взаимного влияния компонент. Спикер ответил, что хотя эти факторы не учтены, теоретические выкладки по предложенному подходу в его опыте подтверждаются практикой.
📍Как с помощью метрик улучшить процессы анализа и проектирования: инструменты и подходы. Доклад был не столько об улучшении процесса анализа, как об улучшении документирования пользовательских метрик. Спикер рассказала об опыте внедрения подходов к проектированию метрик. Сначала аналитики и разработчики договорились о том какие типы событий ометричивать, пришли к соглашению о названиях, затем в шаблон описания требований добавили раздел для описания метрик и создали перечень всех имеющихся метрик. Перечень создали средством построения дашбордов (в компании используют Redash), чтобы не заниматься заполнением вручную. Кроме этого организовали для бизнес-заказчиков шаблон запроса на добавление новых метрик, чтобы ускорить разработку метрик и не остаться без документации.
Самое интересное началось после окончания первого дня. Одновременно с афтерпати организаторы затеяли обсуждение в формате открытого микрофона. Это назвали Fail Night. Любой желающий мог поделиться историей неуспеха и ответить на вопросы из зала. Спикеры подобрались с юмором, а зал в хорошем настроении, так что было легкое ощущение стендапа. Обсудили зачем нужно описание архитектуры, какие ступоры и конфузы случались при публичных выступлениях, а еще несделанные проекты, которые принесли успех совсем другим людям.
Когда на афтерпати ко мне подошла исследователь от организатора конференции (Jugru) и попросила ответить на пару вопросов, то тут уж я честно рассказала и что стендов от партнеров почти не было, и что печенек совсем не было, а ведь мне так важно, чтобы еда была где-то неподалеку 🐹
#конференции
Приехала на оффлайн-часть конференции Flow в Санкт-Петербург. Я очень хорошо себя чувствую в формате, когда еда, кофе и комфорт где-то неподалеку, а мне остается только получать информацию. Поэтому и приехала. Вот только, когда не выбираешься из отеля, то мозг отказывается верить, что я в другом городе 💁♀️
Приятно было увидеть среди участников и организаторов коллег, кого обычно вижу на видео или читаю в их каналах. Не помню, когда видела столько известных экспертов в одном зале одновременно. Может быть, просто я раньше не читала столько экспертных телеграмм-каналов? 😊
Вчера, в первый из двух оффлайн - дней послушала 5 докладов, расскажу о двух.
📍Расчет надежности на этапе системного анализа. Докладчик рассказал как просчитывал надежность системы, на основании данных о надежности ее отдельных компонентов. Предлагается представить систему как параллельно или последовательно связанные сервисы, по аналогии с электросетью, и из вероятности бесперебойной работы каждого подсчитать аналогичную вероятность для всей системы. Подход вызвал массу вопросов в части сбора такой статистики, влияния нагрузки на надежность системы, влияния нестабильности сети, учета взаимного влияния компонент. Спикер ответил, что хотя эти факторы не учтены, теоретические выкладки по предложенному подходу в его опыте подтверждаются практикой.
📍Как с помощью метрик улучшить процессы анализа и проектирования: инструменты и подходы. Доклад был не столько об улучшении процесса анализа, как об улучшении документирования пользовательских метрик. Спикер рассказала об опыте внедрения подходов к проектированию метрик. Сначала аналитики и разработчики договорились о том какие типы событий ометричивать, пришли к соглашению о названиях, затем в шаблон описания требований добавили раздел для описания метрик и создали перечень всех имеющихся метрик. Перечень создали средством построения дашбордов (в компании используют Redash), чтобы не заниматься заполнением вручную. Кроме этого организовали для бизнес-заказчиков шаблон запроса на добавление новых метрик, чтобы ускорить разработку метрик и не остаться без документации.
Самое интересное началось после окончания первого дня. Одновременно с афтерпати организаторы затеяли обсуждение в формате открытого микрофона. Это назвали Fail Night. Любой желающий мог поделиться историей неуспеха и ответить на вопросы из зала. Спикеры подобрались с юмором, а зал в хорошем настроении, так что было легкое ощущение стендапа. Обсудили зачем нужно описание архитектуры, какие ступоры и конфузы случались при публичных выступлениях, а еще несделанные проекты, которые принесли успех совсем другим людям.
Когда на афтерпати ко мне подошла исследователь от организатора конференции (Jugru) и попросила ответить на пару вопросов, то тут уж я честно рассказала и что стендов от партнеров почти не было, и что печенек совсем не было, а ведь мне так важно, чтобы еда была где-то неподалеку 🐹
#конференции
❤7🔥3🤩1
Аналитики и их диаграммы. Второй день Flow
Вчера завершилась Flow, а вместе с ней и моя поездка, в которой я так и не увидела в Петербурге ничего, кроме пробки у Московского вокзала 🤷♀️
Организаторы именно во второй день запланировали выступления самых опытных ярких спикеров. Поделюсь впечатлениями от некоторых докладов, что я видела.
📌BPMN — стандарт, но все всё равно рисуют ерунду. Что делать? Доклад Дениса Котова о противоречиях в формальном стандарте BPMN от компании Object Management Group (OMG) и в том числе об использовании дорожек (любимое противоречие автора), которые применяют для выделения ролей в процессе, что совершенно не обязательно и не указано в стандарте, он рекомендует исполнителей прописывать в каждой задаче. Стандарт не решает задачу единого языка для аналитиков. Речь пошла о том, что можно заключить новое общее соглашение о моделировании, чтобы дать общее понимание стандартов BPMN и улучшить работу с диаграммами. Улучшить предлагается среди прочего за счет отказа от редких типов диаграмм (conversation diagram), комплексных шлюзов, некоторых типов задач (global task, script task) и событий (cancel event, multiply event, parallel event), а еще двусмысленных приемов для ленивых аналитиков (ad hoc process).
📌Проекты оптимизации бизнес-процессов — как с ними жить? Здесь был рассказ об опыте спикера в обследовании процессов и внедрении изменений. На основе собственных ошибок и достижений спикер предложила несколько правил. 1) Анализировать данные параллельно с обследованием процесса, чтобы не пропустить важных сценариев, о которых могут не рассказать на обследовании; 2) изучать причины хейта и внимательно работать в первую очередь с основными недоброжелателями изменений; 3) нужно просить примеры, документы, результаты выполненных задач; 4) больше времени выделять на первичное исследование. Мне запомнился слайд, где предлагалась разбивка времени проекта: 40% на первичный анализ, 10% – согласование, 40% разработка, 10% – приемка и кастомизация.
На дискуссии после доклада зазвучали общие для всех боли "как довести требование до разработчика", "как договориться, чтобы выделили столько времени на первичный анализ" 🌱
📌UML и другие графические нотации: что актуально в 2024 году? Исследование, мнения, практика Доклад Юрия Куприянова, в котором он поделился результатами исследования с целью понять насколько UML актуален. Было опрошено 275 респондентов, из них больше половины – это СА и БА. Из сказанного для себя отметила: 1) порядка 80% участников создавали диаграммы хотя бы несколько месяцев назад и что-то использовали из UML, архитекторы и разработчики меньше, СА - больше; 2) на вопрос "зачем создавали" самый частый ответ "как часть документации"; 3) небольшая корреляция между размером компании, использованием Agile, возрастом аналитика и использованием UML. Еще обсудили какие еще нотации применяют коллеги и какие диаграммы UML чаще используют. А вы как думаете, какие?
Завершал конференцию доклад Александры Клименко о коммуникациях "Как расти в карьере, налаживать связи и двигать проект вперед, если ты аналитик?". Здесь можно было выходить к микрофонам и тренироваться в предложенных сценариях коммуникации. В этих сценариях нужно суметь правильно отреагировать на эмоции собеседника или обозначить свои границы, когда тебе говорят что-то вроде "Аналитики такие нежные пошли! " Сложно пересказывать интерактив, буду надеяться, что рано или поздно появятся записи и тогда смогу обратить ваше внимание на них 🔅
#конференции
Вчера завершилась Flow, а вместе с ней и моя поездка, в которой я так и не увидела в Петербурге ничего, кроме пробки у Московского вокзала 🤷♀️
Организаторы именно во второй день запланировали выступления самых опытных ярких спикеров. Поделюсь впечатлениями от некоторых докладов, что я видела.
📌BPMN — стандарт, но все всё равно рисуют ерунду. Что делать? Доклад Дениса Котова о противоречиях в формальном стандарте BPMN от компании Object Management Group (OMG) и в том числе об использовании дорожек (любимое противоречие автора), которые применяют для выделения ролей в процессе, что совершенно не обязательно и не указано в стандарте, он рекомендует исполнителей прописывать в каждой задаче. Стандарт не решает задачу единого языка для аналитиков. Речь пошла о том, что можно заключить новое общее соглашение о моделировании, чтобы дать общее понимание стандартов BPMN и улучшить работу с диаграммами. Улучшить предлагается среди прочего за счет отказа от редких типов диаграмм (conversation diagram), комплексных шлюзов, некоторых типов задач (global task, script task) и событий (cancel event, multiply event, parallel event), а еще двусмысленных приемов для ленивых аналитиков (ad hoc process).
📌Проекты оптимизации бизнес-процессов — как с ними жить? Здесь был рассказ об опыте спикера в обследовании процессов и внедрении изменений. На основе собственных ошибок и достижений спикер предложила несколько правил. 1) Анализировать данные параллельно с обследованием процесса, чтобы не пропустить важных сценариев, о которых могут не рассказать на обследовании; 2) изучать причины хейта и внимательно работать в первую очередь с основными недоброжелателями изменений; 3) нужно просить примеры, документы, результаты выполненных задач; 4) больше времени выделять на первичное исследование. Мне запомнился слайд, где предлагалась разбивка времени проекта: 40% на первичный анализ, 10% – согласование, 40% разработка, 10% – приемка и кастомизация.
На дискуссии после доклада зазвучали общие для всех боли "как довести требование до разработчика", "как договориться, чтобы выделили столько времени на первичный анализ" 🌱
📌UML и другие графические нотации: что актуально в 2024 году? Исследование, мнения, практика Доклад Юрия Куприянова, в котором он поделился результатами исследования с целью понять насколько UML актуален. Было опрошено 275 респондентов, из них больше половины – это СА и БА. Из сказанного для себя отметила: 1) порядка 80% участников создавали диаграммы хотя бы несколько месяцев назад и что-то использовали из UML, архитекторы и разработчики меньше, СА - больше; 2) на вопрос "зачем создавали" самый частый ответ "как часть документации"; 3) небольшая корреляция между размером компании, использованием Agile, возрастом аналитика и использованием UML. Еще обсудили какие еще нотации применяют коллеги и какие диаграммы UML чаще используют. А вы как думаете, какие?
Завершал конференцию доклад Александры Клименко о коммуникациях "Как расти в карьере, налаживать связи и двигать проект вперед, если ты аналитик?". Здесь можно было выходить к микрофонам и тренироваться в предложенных сценариях коммуникации. В этих сценариях нужно суметь правильно отреагировать на эмоции собеседника или обозначить свои границы, когда тебе говорят что-то вроде "Аналитики такие нежные пошли! " Сложно пересказывать интерактив, буду надеяться, что рано или поздно появятся записи и тогда смогу обратить ваше внимание на них 🔅
#конференции
👍5🔥2🤩1
Осенний аналитический марафон
Сегодня я снова о конференции. На этот раз об Analyst Marathon #11, которая прошла 28 сентября. На улице с утра в субботу шел дождь, в моем фитнес-зале всю прошлую неделю шел ремонт, так почему бы не подключиться к душевной онлайн-конференции?
На этой конференции мне очень нравится традиция общаться в чатике, через него идет фасилитация, в нем же можно найти программу и задать вопрос. Доклады идут в записи и спикер успевает прочесть вопросы перед сессией вопросов-ответов, иногда отвечает в чате пока идет доклад 🌱
Давно договорилась сама с собой, что рассказывать обо всех докладах – неблагодарное занятие, поэтому напишу о тех, что остались в моей записной книжке.
📍Системный аналитик в водовороте событий: проектируем метрики продукта Доклад Никиты Харичкина начался с того, как важно проследить путь от идеи фичи до понимания как она работает после внедрения. Затем определились термины "событие" – уникальный набор параметров в конкретный момент времени, "метрика" – конечные измеримые показатели, собираемые из события. Было много прикладной информации о том как собрать и вести каталог событий.
Записала себе шаги проектирования событий и метрик при работе над каждой новой фичей:
- обсудить с продактом, нужно ли изменение модели событий,
- спроектировать и описать новые события,
- связать события с метриками,
- передать в разработку,
- передать BI специалисту,
- отследить корректность данных и расчетов в BI.
За прошедшую неделю это второй доклад про метрики, что я слышу, и каждый раз из зала был вопрос про отмену события. Если событие отменено, как это фиксировать и учитывать в метриках? В общих словах – отмена чего-либо такое же событие, которое должно регистрироваться и анализироваться при расчете метрик.
Понравился ответ на вопрос о различии метрик и логов. Логи – это черный ящик, где пишется все подряд и нужна расшифровка, а метрики – приборная панель, которая постоянно дает ожидаемую информацию.
📌Пигмалион. Как воспитать стейкхолдера, доклад Ирины Гертовской. Это был развернутый рассказ о базовых техниках анализа заинтересованных сторон (луковичной диаграмме, карте стейкхолдеров) с небольшими комментариями из практического опыта и сценариями на примере персонажей пьесы Бернарда Шоу "Пигмалион".
Здесь я записала фразу "думай о клиенте своего клиента". Если идет работа над приложением для врачей, то "клиенты клиента" – это пациенты, у них могут быть свои интересы, связанные с системой.
📌Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях В этом докладе Михаил Максимов один вывод последовательно нанизывал на другой и в завершении привел разбор примера. Разговор шел о том, как выбрать нужный для конкретной задачи тип модели и нотацию. Важно понять для кого, какой целью, в какой срок строится модель. При выборе нужно подумать, какое представление и с каких точек зрения (организационной, действий и бизнес-процессов, функциональной или информационной структуры, информационных потоков, автоматизации операций) потребуется для решения задачи.
#конференции
Сегодня я снова о конференции. На этот раз об Analyst Marathon #11, которая прошла 28 сентября. На улице с утра в субботу шел дождь, в моем фитнес-зале всю прошлую неделю шел ремонт, так почему бы не подключиться к душевной онлайн-конференции?
На этой конференции мне очень нравится традиция общаться в чатике, через него идет фасилитация, в нем же можно найти программу и задать вопрос. Доклады идут в записи и спикер успевает прочесть вопросы перед сессией вопросов-ответов, иногда отвечает в чате пока идет доклад 🌱
Давно договорилась сама с собой, что рассказывать обо всех докладах – неблагодарное занятие, поэтому напишу о тех, что остались в моей записной книжке.
📍Системный аналитик в водовороте событий: проектируем метрики продукта Доклад Никиты Харичкина начался с того, как важно проследить путь от идеи фичи до понимания как она работает после внедрения. Затем определились термины "событие" – уникальный набор параметров в конкретный момент времени, "метрика" – конечные измеримые показатели, собираемые из события. Было много прикладной информации о том как собрать и вести каталог событий.
Записала себе шаги проектирования событий и метрик при работе над каждой новой фичей:
- обсудить с продактом, нужно ли изменение модели событий,
- спроектировать и описать новые события,
- связать события с метриками,
- передать в разработку,
- передать BI специалисту,
- отследить корректность данных и расчетов в BI.
За прошедшую неделю это второй доклад про метрики, что я слышу, и каждый раз из зала был вопрос про отмену события. Если событие отменено, как это фиксировать и учитывать в метриках? В общих словах – отмена чего-либо такое же событие, которое должно регистрироваться и анализироваться при расчете метрик.
Понравился ответ на вопрос о различии метрик и логов. Логи – это черный ящик, где пишется все подряд и нужна расшифровка, а метрики – приборная панель, которая постоянно дает ожидаемую информацию.
📌Пигмалион. Как воспитать стейкхолдера, доклад Ирины Гертовской. Это был развернутый рассказ о базовых техниках анализа заинтересованных сторон (луковичной диаграмме, карте стейкхолдеров) с небольшими комментариями из практического опыта и сценариями на примере персонажей пьесы Бернарда Шоу "Пигмалион".
Здесь я записала фразу "думай о клиенте своего клиента". Если идет работа над приложением для врачей, то "клиенты клиента" – это пациенты, у них могут быть свои интересы, связанные с системой.
📌Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях В этом докладе Михаил Максимов один вывод последовательно нанизывал на другой и в завершении привел разбор примера. Разговор шел о том, как выбрать нужный для конкретной задачи тип модели и нотацию. Важно понять для кого, какой целью, в какой срок строится модель. При выборе нужно подумать, какое представление и с каких точек зрения (организационной, действий и бизнес-процессов, функциональной или информационной структуры, информационных потоков, автоматизации операций) потребуется для решения задачи.
#конференции
🔥2👍1
Отцы и дети. Немного истории
Это что-то очень сильно бумерское – настырно читать тексты, которые не приносят ни информации, ни радости. Я как зачарованный кролик каждый раз вычитываю пост вида "какая ерунда этот ваш BABOK /Вигерс/кто-то там" и каждый раз думаю, а почему? Таких постов в последнее время много и мы с ними часто друг друга встречаем в инфопространстве 🙈 Рискну поделиться своими наблюдениями, и вы пишите свои в комментариях.
Я делала первые шаги в ИТ-анализе примерно за пару лет до выхода первой версии BABOK и узнала о его существовании далеко не сразу. Первое, что мне дали почитать старшие товарищи была книга Коберна "Современные методы описания функциональных требований к системам" (Writing Effective Use Cases, 2002) и это было ощущение "Ух тыыы! Вот же тут все написано, оказывается!" Забавно, что переиздание 2023 года вышло под тем же названием, хотя слово "современные" в этом контексте выглядит немного курьезно 🔅
Первая версия BABOK вышла в 2005 году и она кое-что значила для аналитиков, про них тогда еще мало кто знал. Инженеры и менеджеры к тому времени уже десятки лет как собрались в сообщества и написали себе стандарты. Не то чтобы в стандартах PMI и IEEE и, к слову сказать, в ГОСТ, не было ни слова про анализ и проектирование, но хочется же и своего профессионального признания! Пошло почти двадцать лет, свод знаний по-прежнему верен аналитикам и честно перечисляет список инструментов общими словами, но разочаровывает тех, кому нужны простые и понятные фреймворки.
В 1999 вышло первое издание книги Вигерса "Разработки требований к программному обеспечению" (русская редакция в 2004 г) и оказалась одним из немногих доступных тогда источников знаний для аналитиков.Забавно, что некоторые альтернативные труды тоже из прошлого, просто двадцать лет назад меньше были известны и доступны. Учитывая, что книга постоянно переиздается, она и сейчас – доступный источник, но есть нюансы.
Года три назад, когда еще не протухло мое членство в IIBA, я подключалась к выступлению Карла Вигерса на встрече аналитиков города Портланда. Я полагала, что это будет огромное событие и сотни человек соберутся послушать мастера. Как думаете, сколько человек пришло на встречу? Человек 10. То есть не всегда народ собирается целыми стадионами послушать любое выступление автора 7 книг о разработке ПО еще нескольких о консалтинге.
Набрела в англоязычном сообществе на статью 10 лучших книг по бизнес-анализу для начинающих, где в списке нет "Разработки требований к программному обеспечению". То есть существует где-то мнение, что можно развиваться в профессии без этого фундаментального издания, особенно в БА?
Кто, как и я, начинал карьеру с ощущения от конкретной книги "Ух тыыы! Вот же тут все написано!", не всегда готовы обращаться к другим источникам и это можно понять. Таким путем ведут опыт и привычки. На прошлой неделе слышала в докладе одного известного спикера "Надеюсь, вы хотя бы листали книгу Вигерса"...
Те, кто начинал карьеру уже в VUCA или BANI мире, переосмысливают прежние авторитеты с положенным в этом случае нигилизмом по логике романа Тургенева "Отцы и дети". То есть отрицают прежние авторитеты и манеру речи. Чем чаще слышат "Надеюсь, вы хотя бы листали книгу Вигерса", тем яростнее отрицание😎
У меня под рукой постоянно все три названные здесь книги, но вовсе не потому что без них нельзя называться аналитиком в ИТ, а потому что я с ними знакома не первый год. Они мне пригождаются, когда нужно базовые вещи объяснить кому-то или вспомнить самой. Страницы постоянно заложены какими-то случайными штуками – то квитанциями, то театральными афишками. Рекомендую к прочтению обычно с пояснением "имей в виду, материал давний, знать его полезно, но есть и другие варианты". Некоторые из других вариантов можно найти в этом канале по тегу #книжки
#мысливслух
Это что-то очень сильно бумерское – настырно читать тексты, которые не приносят ни информации, ни радости. Я как зачарованный кролик каждый раз вычитываю пост вида "какая ерунда этот ваш BABOK /Вигерс/кто-то там" и каждый раз думаю, а почему? Таких постов в последнее время много и мы с ними часто друг друга встречаем в инфопространстве 🙈 Рискну поделиться своими наблюдениями, и вы пишите свои в комментариях.
Я делала первые шаги в ИТ-анализе примерно за пару лет до выхода первой версии BABOK и узнала о его существовании далеко не сразу. Первое, что мне дали почитать старшие товарищи была книга Коберна "Современные методы описания функциональных требований к системам" (Writing Effective Use Cases, 2002) и это было ощущение "Ух тыыы! Вот же тут все написано, оказывается!" Забавно, что переиздание 2023 года вышло под тем же названием, хотя слово "современные" в этом контексте выглядит немного курьезно 🔅
Первая версия BABOK вышла в 2005 году и она кое-что значила для аналитиков, про них тогда еще мало кто знал. Инженеры и менеджеры к тому времени уже десятки лет как собрались в сообщества и написали себе стандарты. Не то чтобы в стандартах PMI и IEEE и, к слову сказать, в ГОСТ, не было ни слова про анализ и проектирование, но хочется же и своего профессионального признания! Пошло почти двадцать лет, свод знаний по-прежнему верен аналитикам и честно перечисляет список инструментов общими словами, но разочаровывает тех, кому нужны простые и понятные фреймворки.
В 1999 вышло первое издание книги Вигерса "Разработки требований к программному обеспечению" (русская редакция в 2004 г) и оказалась одним из немногих доступных тогда источников знаний для аналитиков.Забавно, что некоторые альтернативные труды тоже из прошлого, просто двадцать лет назад меньше были известны и доступны. Учитывая, что книга постоянно переиздается, она и сейчас – доступный источник, но есть нюансы.
Года три назад, когда еще не протухло мое членство в IIBA, я подключалась к выступлению Карла Вигерса на встрече аналитиков города Портланда. Я полагала, что это будет огромное событие и сотни человек соберутся послушать мастера. Как думаете, сколько человек пришло на встречу? Человек 10. То есть не всегда народ собирается целыми стадионами послушать любое выступление автора 7 книг о разработке ПО еще нескольких о консалтинге.
Набрела в англоязычном сообществе на статью 10 лучших книг по бизнес-анализу для начинающих, где в списке нет "Разработки требований к программному обеспечению". То есть существует где-то мнение, что можно развиваться в профессии без этого фундаментального издания, особенно в БА?
Кто, как и я, начинал карьеру с ощущения от конкретной книги "Ух тыыы! Вот же тут все написано!", не всегда готовы обращаться к другим источникам и это можно понять. Таким путем ведут опыт и привычки. На прошлой неделе слышала в докладе одного известного спикера "Надеюсь, вы хотя бы листали книгу Вигерса"...
Те, кто начинал карьеру уже в VUCA или BANI мире, переосмысливают прежние авторитеты с положенным в этом случае нигилизмом по логике романа Тургенева "Отцы и дети". То есть отрицают прежние авторитеты и манеру речи. Чем чаще слышат "Надеюсь, вы хотя бы листали книгу Вигерса", тем яростнее отрицание
У меня под рукой постоянно все три названные здесь книги, но вовсе не потому что без них нельзя называться аналитиком в ИТ, а потому что я с ними знакома не первый год. Они мне пригождаются, когда нужно базовые вещи объяснить кому-то или вспомнить самой. Страницы постоянно заложены какими-то случайными штуками – то квитанциями, то театральными афишками. Рекомендую к прочтению обычно с пояснением "имей в виду, материал давний, знать его полезно, но есть и другие варианты". Некоторые из других вариантов можно найти в этом канале по тегу #книжки
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥3💯1
5 статей про требования
Разобрала в выходные свой список для чтения, накопившийся за сентябрь. Выбрала несколько статей по вопросам требований к системам.
📌Критерии качества требований с примерами (Часть 1) Написано от лица тестировщика, для аналитика может быть полезным познакомится с примерами некачественных требований и вспомнить классические критерии: полнота, непротиворечивость, однозначность, корректность, реализуемость, тестируемость, упорядоченность, атомарность и несколько других.
📌Критерии качества требований с примерами (Часть 2) Продолжение предыдущей статьи.
📌Как системный аналитик может data-культуру развивать Статья о том, с чем можно столкнуться при работе с данными, что такое data governance и как проектировать и документировать требования к метрикам. Статья оказалась у меня в закладках после Flow, где выступала автор. О докладе про метрики я писала в своем обзоре.
📌Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью
Описан подход, где логика работы системы изложена графически. Подозреваю, что при таком подходе будут вопросы к полноте требований, но есть свои преимущества.
📌Как написать ТЗ на простую программу (калькулятор) В этой статье очень понравилась идея на примере понятного многим прибора показать ход мысли при описании требований. Как это часто бывает, интересно полистать комментарии с реакцией обитателей Хабра😎
#что_почитать #подборка
Разобрала в выходные свой список для чтения, накопившийся за сентябрь. Выбрала несколько статей по вопросам требований к системам.
📌Критерии качества требований с примерами (Часть 1) Написано от лица тестировщика, для аналитика может быть полезным познакомится с примерами некачественных требований и вспомнить классические критерии: полнота, непротиворечивость, однозначность, корректность, реализуемость, тестируемость, упорядоченность, атомарность и несколько других.
📌Критерии качества требований с примерами (Часть 2) Продолжение предыдущей статьи.
📌Как системный аналитик может data-культуру развивать Статья о том, с чем можно столкнуться при работе с данными, что такое data governance и как проектировать и документировать требования к метрикам. Статья оказалась у меня в закладках после Flow, где выступала автор. О докладе про метрики я писала в своем обзоре.
📌Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью
Описан подход, где логика работы системы изложена графически. Подозреваю, что при таком подходе будут вопросы к полноте требований, но есть свои преимущества.
📌Как написать ТЗ на простую программу (калькулятор) В этой статье очень понравилась идея на примере понятного многим прибора показать ход мысли при описании требований. Как это часто бывает, интересно полистать комментарии с реакцией обитателей Хабра
#что_почитать #подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
Две разные причины одинаковых неудач
За этот пост я принималась пять раз и пять раз откладывала. Угол темы какой-то коварный, но все равно хочу поделиться наблюдением.
В роли ментора у меня есть возможность наблюдать очень разных менти. Бывает, кто-то делает первые шаги в профессии после вуза. Бывает, после 15-20 лет работы с финансовыми отчетами кто-то хочет заняться проектированием ИТ-систем. Свои учебные цели и те и другие проваливают с одинаковым результатом, но интересно наблюдать какие разные причины.
🔅У тех, кто начале карьеры, бывает много энтузиазма и желания "горы свернуть", но мало готовности отрабатывать навык на кейсах и задачках. Есть ощущение, что можно быстро разобраться и этого достаточно. Послушать новое, пару раз попробовать и вот уже новая строчка вписывается в резюме. При этом навык не появился и не получается уверенно решать задачи.
🔅Оказалось, что люди с опытом тоже легко проваливают отработку навыков. Самое обидное, что в некоторых я неожиданно узнавала себя слов в слово. "У меня хорошее образование и большой опыт, я быстро освою эти ваши C4/Rest Api/Описания фич/что угодно еще." "Я 15 лет занимаюсь SAP, ну что я диаграмму последовательности не пойму что ли?" При этом мешают сосредоточиться уже не только дофамины с эндорфинами, но и груз ответственности: работа, родительские собрания в школе и ежедневный список из десятка дел. В общей суматохе бывает тяжело запомнить что такое "функциональные требования". И непонятно зачем запоминать, неужели "на месте не разберемся"? Результат тот же – навык не формируется даже на уровне тестовых заданий.
Какими бы ни были причины завышенных ожиданий, это первое, с чем нужно работать, чтобы получить результат. Рассчитать нагрузку, время и быть готовым к рутине нужно обязательно, если вы решили делать что-то новое в карьере.
#мысливслух
За этот пост я принималась пять раз и пять раз откладывала. Угол темы какой-то коварный, но все равно хочу поделиться наблюдением.
В роли ментора у меня есть возможность наблюдать очень разных менти. Бывает, кто-то делает первые шаги в профессии после вуза. Бывает, после 15-20 лет работы с финансовыми отчетами кто-то хочет заняться проектированием ИТ-систем. Свои учебные цели и те и другие проваливают с одинаковым результатом, но интересно наблюдать какие разные причины.
🔅У тех, кто начале карьеры, бывает много энтузиазма и желания "горы свернуть", но мало готовности отрабатывать навык на кейсах и задачках. Есть ощущение, что можно быстро разобраться и этого достаточно. Послушать новое, пару раз попробовать и вот уже новая строчка вписывается в резюме. При этом навык не появился и не получается уверенно решать задачи.
🔅Оказалось, что люди с опытом тоже легко проваливают отработку навыков. Самое обидное, что в некоторых я неожиданно узнавала себя слов в слово. "У меня хорошее образование и большой опыт, я быстро освою эти ваши C4/Rest Api/Описания фич/что угодно еще." "Я 15 лет занимаюсь SAP, ну что я диаграмму последовательности не пойму что ли?" При этом мешают сосредоточиться уже не только дофамины с эндорфинами, но и груз ответственности: работа, родительские собрания в школе и ежедневный список из десятка дел. В общей суматохе бывает тяжело запомнить что такое "функциональные требования". И непонятно зачем запоминать, неужели "на месте не разберемся"? Результат тот же – навык не формируется даже на уровне тестовых заданий.
Какими бы ни были причины завышенных ожиданий, это первое, с чем нужно работать, чтобы получить результат. Рассчитать нагрузку, время и быть готовым к рутине нужно обязательно, если вы решили делать что-то новое в карьере.
#мысливслух
💯7❤3
10 моих любимых постов
Этому каналу исполнился год. Начала его вести, чтобы посмотреть, что из этого получится, да так и осталась☺️
Здесь собралось 180 постов, иногда я к ним возвращаюсь, чтобы сверить впечатления от разных сезонов одной и той же конференции, сослаться на собственную подборку или посмотреть, какие вопросы придумывала.
Обнаружилось, что есть посты-любимчики. Они не всегда лучшие по стилю, сейчас написала бы иначе. Просто в них что-то вложено из опыта или проведены раскопки материалов, поэтому мне их интересно перечитывать. Просмотров у таких тоже обычно чуть больше. Собрала их списком, если ищете, что почитать - заходите!🌱
▫️О кнопочных телефонах и об источниках требований
▫️Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
▫️Как я искала сложности и что из этого вышло, часть 1
▫️Как я искала сложности и что из этого вышло, часть 2
▫️Что такое прототипы и какими они бывают?
▫️Как аналитику избежать когнитивных искажений?
▫️Чашки и их свойства в разных системах
▫️Нужно ли аналитику работать в Figma?
▫️История про детство и компьютер
▫️Что важно для выявления требований?
#навигация
Этому каналу исполнился год. Начала его вести, чтобы посмотреть, что из этого получится, да так и осталась
Здесь собралось 180 постов, иногда я к ним возвращаюсь, чтобы сверить впечатления от разных сезонов одной и той же конференции, сослаться на собственную подборку или посмотреть, какие вопросы придумывала.
Обнаружилось, что есть посты-любимчики. Они не всегда лучшие по стилю, сейчас написала бы иначе. Просто в них что-то вложено из опыта или проведены раскопки материалов, поэтому мне их интересно перечитывать. Просмотров у таких тоже обычно чуть больше. Собрала их списком, если ищете, что почитать - заходите!🌱
▫️О кнопочных телефонах и об источниках требований
▫️Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
▫️Как я искала сложности и что из этого вышло, часть 1
▫️Как я искала сложности и что из этого вышло, часть 2
▫️Что такое прототипы и какими они бывают?
▫️Как аналитику избежать когнитивных искажений?
▫️Чашки и их свойства в разных системах
▫️Нужно ли аналитику работать в Figma?
▫️История про детство и компьютер
▫️Что важно для выявления требований?
#навигация
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍2❤1