Информация и еда на Flow
Приехала на оффлайн-часть конференции Flow в Санкт-Петербург. Я очень хорошо себя чувствую в формате, когда еда, кофе и комфорт где-то неподалеку, а мне остается только получать информацию. Поэтому и приехала. Вот только, когда не выбираешься из отеля, то мозг отказывается верить, что я в другом городе 💁♀️
Приятно было увидеть среди участников и организаторов коллег, кого обычно вижу на видео или читаю в их каналах. Не помню, когда видела столько известных экспертов в одном зале одновременно. Может быть, просто я раньше не читала столько экспертных телеграмм-каналов? 😊
Вчера, в первый из двух оффлайн - дней послушала 5 докладов, расскажу о двух.
📍Расчет надежности на этапе системного анализа. Докладчик рассказал как просчитывал надежность системы, на основании данных о надежности ее отдельных компонентов. Предлагается представить систему как параллельно или последовательно связанные сервисы, по аналогии с электросетью, и из вероятности бесперебойной работы каждого подсчитать аналогичную вероятность для всей системы. Подход вызвал массу вопросов в части сбора такой статистики, влияния нагрузки на надежность системы, влияния нестабильности сети, учета взаимного влияния компонент. Спикер ответил, что хотя эти факторы не учтены, теоретические выкладки по предложенному подходу в его опыте подтверждаются практикой.
📍Как с помощью метрик улучшить процессы анализа и проектирования: инструменты и подходы. Доклад был не столько об улучшении процесса анализа, как об улучшении документирования пользовательских метрик. Спикер рассказала об опыте внедрения подходов к проектированию метрик. Сначала аналитики и разработчики договорились о том какие типы событий ометричивать, пришли к соглашению о названиях, затем в шаблон описания требований добавили раздел для описания метрик и создали перечень всех имеющихся метрик. Перечень создали средством построения дашбордов (в компании используют Redash), чтобы не заниматься заполнением вручную. Кроме этого организовали для бизнес-заказчиков шаблон запроса на добавление новых метрик, чтобы ускорить разработку метрик и не остаться без документации.
Самое интересное началось после окончания первого дня. Одновременно с афтерпати организаторы затеяли обсуждение в формате открытого микрофона. Это назвали Fail Night. Любой желающий мог поделиться историей неуспеха и ответить на вопросы из зала. Спикеры подобрались с юмором, а зал в хорошем настроении, так что было легкое ощущение стендапа. Обсудили зачем нужно описание архитектуры, какие ступоры и конфузы случались при публичных выступлениях, а еще несделанные проекты, которые принесли успех совсем другим людям.
Когда на афтерпати ко мне подошла исследователь от организатора конференции (Jugru) и попросила ответить на пару вопросов, то тут уж я честно рассказала и что стендов от партнеров почти не было, и что печенек совсем не было, а ведь мне так важно, чтобы еда была где-то неподалеку 🐹
#конференции
Приехала на оффлайн-часть конференции Flow в Санкт-Петербург. Я очень хорошо себя чувствую в формате, когда еда, кофе и комфорт где-то неподалеку, а мне остается только получать информацию. Поэтому и приехала. Вот только, когда не выбираешься из отеля, то мозг отказывается верить, что я в другом городе 💁♀️
Приятно было увидеть среди участников и организаторов коллег, кого обычно вижу на видео или читаю в их каналах. Не помню, когда видела столько известных экспертов в одном зале одновременно. Может быть, просто я раньше не читала столько экспертных телеграмм-каналов? 😊
Вчера, в первый из двух оффлайн - дней послушала 5 докладов, расскажу о двух.
📍Расчет надежности на этапе системного анализа. Докладчик рассказал как просчитывал надежность системы, на основании данных о надежности ее отдельных компонентов. Предлагается представить систему как параллельно или последовательно связанные сервисы, по аналогии с электросетью, и из вероятности бесперебойной работы каждого подсчитать аналогичную вероятность для всей системы. Подход вызвал массу вопросов в части сбора такой статистики, влияния нагрузки на надежность системы, влияния нестабильности сети, учета взаимного влияния компонент. Спикер ответил, что хотя эти факторы не учтены, теоретические выкладки по предложенному подходу в его опыте подтверждаются практикой.
📍Как с помощью метрик улучшить процессы анализа и проектирования: инструменты и подходы. Доклад был не столько об улучшении процесса анализа, как об улучшении документирования пользовательских метрик. Спикер рассказала об опыте внедрения подходов к проектированию метрик. Сначала аналитики и разработчики договорились о том какие типы событий ометричивать, пришли к соглашению о названиях, затем в шаблон описания требований добавили раздел для описания метрик и создали перечень всех имеющихся метрик. Перечень создали средством построения дашбордов (в компании используют Redash), чтобы не заниматься заполнением вручную. Кроме этого организовали для бизнес-заказчиков шаблон запроса на добавление новых метрик, чтобы ускорить разработку метрик и не остаться без документации.
Самое интересное началось после окончания первого дня. Одновременно с афтерпати организаторы затеяли обсуждение в формате открытого микрофона. Это назвали Fail Night. Любой желающий мог поделиться историей неуспеха и ответить на вопросы из зала. Спикеры подобрались с юмором, а зал в хорошем настроении, так что было легкое ощущение стендапа. Обсудили зачем нужно описание архитектуры, какие ступоры и конфузы случались при публичных выступлениях, а еще несделанные проекты, которые принесли успех совсем другим людям.
Когда на афтерпати ко мне подошла исследователь от организатора конференции (Jugru) и попросила ответить на пару вопросов, то тут уж я честно рассказала и что стендов от партнеров почти не было, и что печенек совсем не было, а ведь мне так важно, чтобы еда была где-то неподалеку 🐹
#конференции
Аналитики и их диаграммы. Второй день 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 чаще используют. А вы как думаете, какие?
Завершал конференцию доклад Александры Клименко о коммуникациях "Как расти в карьере, налаживать связи и двигать проект вперед, если ты аналитик?". Здесь можно было выходить к микрофонам и тренироваться в предложенных сценариях коммуникации. В этих сценариях нужно суметь правильно отреагировать на эмоции собеседника или обозначить свои границы, когда тебе говорят что-то вроде "Аналитики такие нежные пошли! " Сложно пересказывать интерактив, буду надеяться, что рано или поздно появятся записи и тогда смогу обратить ваше внимание на них 🔅
#конференции
Осенний аналитический марафон
Сегодня я снова о конференции. На этот раз об Analyst Marathon #11, которая прошла 28 сентября. На улице с утра в субботу шел дождь, в моем фитнес-зале всю прошлую неделю шел ремонт, так почему бы не подключиться к душевной онлайн-конференции?
На этой конференции мне очень нравится традиция общаться в чатике, через него идет фасилитация, в нем же можно найти программу и задать вопрос. Доклады идут в записи и спикер успевает прочесть вопросы перед сессией вопросов-ответов, иногда отвечает в чате пока идет доклад 🌱
Давно договорилась сама с собой, что рассказывать обо всех докладах – неблагодарное занятие, поэтому напишу о тех, что остались в моей записной книжке.
📍Системный аналитик в водовороте событий: проектируем метрики продукта Доклад Никиты Харичкина начался с того, как важно проследить путь от идеи фичи до понимания как она работает после внедрения. Затем определились термины "событие" – уникальный набор параметров в конкретный момент времени, "метрика" – конечные измеримые показатели, собираемые из события. Было много прикладной информации о том как собрать и вести каталог событий.
Записала себе шаги проектирования событий и метрик при работе над каждой новой фичей:
- обсудить с продактом, нужно ли изменение модели событий,
- спроектировать и описать новые события,
- связать события с метриками,
- передать в разработку,
- передать BI специалисту,
- отследить корректность данных и расчетов в BI.
За прошедшую неделю это второй доклад про метрики, что я слышу, и каждый раз из зала был вопрос про отмену события. Если событие отменено, как это фиксировать и учитывать в метриках? В общих словах – отмена чего-либо такое же событие, которое должно регистрироваться и анализироваться при расчете метрик.
Понравился ответ на вопрос о различии метрик и логов. Логи – это черный ящик, где пишется все подряд и нужна расшифровка, а метрики – приборная панель, которая постоянно дает ожидаемую информацию.
📌Пигмалион. Как воспитать стейкхолдера, доклад Ирины Гертовской. Это был развернутый рассказ о базовых техниках анализа заинтересованных сторон (луковичной диаграмме, карте стейкхолдеров) с небольшими комментариями из практического опыта и сценариями на примере персонажей пьесы Бернарда Шоу "Пигмалион".
Здесь я записала фразу "думай о клиенте своего клиента". Если идет работа над приложением для врачей, то "клиенты клиента" – это пациенты, у них могут быть свои интересы, связанные с системой.
📌Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях В этом докладе Михаил Максимов один вывод последовательно нанизывал на другой и в завершении привел разбор примера. Разговор шел о том, как выбрать нужный для конкретной задачи тип модели и нотацию. Важно понять для кого, какой целью, в какой срок строится модель. При выборе нужно подумать, какое представление и с каких точек зрения (организационной, действий и бизнес-процессов, функциональной или информационной структуры, информационных потоков, автоматизации операций) потребуется для решения задачи.
#конференции
Сегодня я снова о конференции. На этот раз об Analyst Marathon #11, которая прошла 28 сентября. На улице с утра в субботу шел дождь, в моем фитнес-зале всю прошлую неделю шел ремонт, так почему бы не подключиться к душевной онлайн-конференции?
На этой конференции мне очень нравится традиция общаться в чатике, через него идет фасилитация, в нем же можно найти программу и задать вопрос. Доклады идут в записи и спикер успевает прочесть вопросы перед сессией вопросов-ответов, иногда отвечает в чате пока идет доклад 🌱
Давно договорилась сама с собой, что рассказывать обо всех докладах – неблагодарное занятие, поэтому напишу о тех, что остались в моей записной книжке.
📍Системный аналитик в водовороте событий: проектируем метрики продукта Доклад Никиты Харичкина начался с того, как важно проследить путь от идеи фичи до понимания как она работает после внедрения. Затем определились термины "событие" – уникальный набор параметров в конкретный момент времени, "метрика" – конечные измеримые показатели, собираемые из события. Было много прикладной информации о том как собрать и вести каталог событий.
Записала себе шаги проектирования событий и метрик при работе над каждой новой фичей:
- обсудить с продактом, нужно ли изменение модели событий,
- спроектировать и описать новые события,
- связать события с метриками,
- передать в разработку,
- передать BI специалисту,
- отследить корректность данных и расчетов в BI.
За прошедшую неделю это второй доклад про метрики, что я слышу, и каждый раз из зала был вопрос про отмену события. Если событие отменено, как это фиксировать и учитывать в метриках? В общих словах – отмена чего-либо такое же событие, которое должно регистрироваться и анализироваться при расчете метрик.
Понравился ответ на вопрос о различии метрик и логов. Логи – это черный ящик, где пишется все подряд и нужна расшифровка, а метрики – приборная панель, которая постоянно дает ожидаемую информацию.
📌Пигмалион. Как воспитать стейкхолдера, доклад Ирины Гертовской. Это был развернутый рассказ о базовых техниках анализа заинтересованных сторон (луковичной диаграмме, карте стейкхолдеров) с небольшими комментариями из практического опыта и сценариями на примере персонажей пьесы Бернарда Шоу "Пигмалион".
Здесь я записала фразу "думай о клиенте своего клиента". Если идет работа над приложением для врачей, то "клиенты клиента" – это пациенты, у них могут быть свои интересы, связанные с системой.
📌Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях В этом докладе Михаил Максимов один вывод последовательно нанизывал на другой и в завершении привел разбор примера. Разговор шел о том, как выбрать нужный для конкретной задачи тип модели и нотацию. Важно понять для кого, какой целью, в какой срок строится модель. При выборе нужно подумать, какое представление и с каких точек зрения (организационной, действий и бизнес-процессов, функциональной или информационной структуры, информационных потоков, автоматизации операций) потребуется для решения задачи.
#конференции
Отцы и дети. Немного истории
Это что-то очень сильно бумерское – настырно читать тексты, которые не приносят ни информации, ни радости. Я как зачарованный кролик каждый раз вычитываю пост вида "какая ерунда этот ваш 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
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
Две разные причины одинаковых неудач
За этот пост я принималась пять раз и пять раз откладывала. Угол темы какой-то коварный, но все равно хочу поделиться наблюдением.
В роли ментора у меня есть возможность наблюдать очень разных менти. Бывает, кто-то делает первые шаги в профессии после вуза. Бывает, после 15-20 лет работы с финансовыми отчетами кто-то хочет заняться проектированием ИТ-систем. Свои учебные цели и те и другие проваливают с одинаковым результатом, но интересно наблюдать какие разные причины.
🔅У тех, кто начале карьеры, бывает много энтузиазма и желания "горы свернуть", но мало готовности отрабатывать навык на кейсах и задачках. Есть ощущение, что можно быстро разобраться и этого достаточно. Послушать новое, пару раз попробовать и вот уже новая строчка вписывается в резюме. При этом навык не появился и не получается уверенно решать задачи.
🔅Оказалось, что люди с опытом тоже легко проваливают отработку навыков. Самое обидное, что в некоторых я неожиданно узнавала себя слов в слово. "У меня хорошее образование и большой опыт, я быстро освою эти ваши C4/Rest Api/Описания фич/что угодно еще." "Я 15 лет занимаюсь SAP, ну что я диаграмму последовательности не пойму что ли?" При этом мешают сосредоточиться уже не только дофамины с эндорфинами, но и груз ответственности: работа, родительские собрания в школе и ежедневный список из десятка дел. В общей суматохе бывает тяжело запомнить что такое "функциональные требования". И непонятно зачем запоминать, неужели "на месте не разберемся"? Результат тот же – навык не формируется даже на уровне тестовых заданий.
Какими бы ни были причины завышенных ожиданий, это первое, с чем нужно работать, чтобы получить результат. Рассчитать нагрузку, время и быть готовым к рутине нужно обязательно, если вы решили делать что-то новое в карьере.
#мысливслух
За этот пост я принималась пять раз и пять раз откладывала. Угол темы какой-то коварный, но все равно хочу поделиться наблюдением.
В роли ментора у меня есть возможность наблюдать очень разных менти. Бывает, кто-то делает первые шаги в профессии после вуза. Бывает, после 15-20 лет работы с финансовыми отчетами кто-то хочет заняться проектированием ИТ-систем. Свои учебные цели и те и другие проваливают с одинаковым результатом, но интересно наблюдать какие разные причины.
🔅У тех, кто начале карьеры, бывает много энтузиазма и желания "горы свернуть", но мало готовности отрабатывать навык на кейсах и задачках. Есть ощущение, что можно быстро разобраться и этого достаточно. Послушать новое, пару раз попробовать и вот уже новая строчка вписывается в резюме. При этом навык не появился и не получается уверенно решать задачи.
🔅Оказалось, что люди с опытом тоже легко проваливают отработку навыков. Самое обидное, что в некоторых я неожиданно узнавала себя слов в слово. "У меня хорошее образование и большой опыт, я быстро освою эти ваши C4/Rest Api/Описания фич/что угодно еще." "Я 15 лет занимаюсь SAP, ну что я диаграмму последовательности не пойму что ли?" При этом мешают сосредоточиться уже не только дофамины с эндорфинами, но и груз ответственности: работа, родительские собрания в школе и ежедневный список из десятка дел. В общей суматохе бывает тяжело запомнить что такое "функциональные требования". И непонятно зачем запоминать, неужели "на месте не разберемся"? Результат тот же – навык не формируется даже на уровне тестовых заданий.
Какими бы ни были причины завышенных ожиданий, это первое, с чем нужно работать, чтобы получить результат. Рассчитать нагрузку, время и быть готовым к рутине нужно обязательно, если вы решили делать что-то новое в карьере.
#мысливслух
10 моих любимых постов
Этому каналу исполнился год. Начала его вести, чтобы посмотреть, что из этого получится, да так и осталась☺️
Здесь собралось 180 постов, иногда я к ним возвращаюсь, чтобы сверить впечатления от разных сезонов одной и той же конференции, сослаться на собственную подборку или посмотреть, какие вопросы придумывала.
Обнаружилось, что есть посты-любимчики. Они не всегда лучшие по стилю, сейчас написала бы иначе. Просто в них что-то вложено из опыта или проведены раскопки материалов, поэтому мне их интересно перечитывать. Просмотров у таких тоже обычно чуть больше. Собрала их списком, если ищете, что почитать - заходите!🌱
▫️О кнопочных телефонах и об источниках требований
▫️Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
▫️Как я искала сложности и что из этого вышло, часть 1
▫️Как я искала сложности и что из этого вышло, часть 2
▫️Что такое прототипы и какими они бывают?
▫️Как аналитику избежать когнитивных искажений?
▫️Чашки и их свойства в разных системах
▫️Нужно ли аналитику работать в Figma?
▫️История про детство и компьютер
▫️Что важно для выявления требований?
#навигация
Этому каналу исполнился год. Начала его вести, чтобы посмотреть, что из этого получится, да так и осталась
Здесь собралось 180 постов, иногда я к ним возвращаюсь, чтобы сверить впечатления от разных сезонов одной и той же конференции, сослаться на собственную подборку или посмотреть, какие вопросы придумывала.
Обнаружилось, что есть посты-любимчики. Они не всегда лучшие по стилю, сейчас написала бы иначе. Просто в них что-то вложено из опыта или проведены раскопки материалов, поэтому мне их интересно перечитывать. Просмотров у таких тоже обычно чуть больше. Собрала их списком, если ищете, что почитать - заходите!🌱
▫️О кнопочных телефонах и об источниках требований
▫️Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
▫️Как я искала сложности и что из этого вышло, часть 1
▫️Как я искала сложности и что из этого вышло, часть 2
▫️Что такое прототипы и какими они бывают?
▫️Как аналитику избежать когнитивных искажений?
▫️Чашки и их свойства в разных системах
▫️Нужно ли аналитику работать в Figma?
▫️История про детство и компьютер
▫️Что важно для выявления требований?
#навигация
Please open Telegram to view this post
VIEW IN TELEGRAM
С кем важно говорить о требованиях на самом деле?
Когда работала в заказной разработке, то заинтересованные стороны по сути назначались. Кого выделили поговорить от заказчика, с тем и говоришь. Аналитик не был допущен к внутренней кухне настолько, чтобы понять, какой вес в компании имеет этот "назначенный". Когда оказалась во внутренней разработке, первое время двигалась привычным путем. Кто принес запрос, у того искала требования. Кто чаще приходит и громче кричит, того требования важнее. Начала различать характеристики заинтересованных сторон только когда поняла, что требования почему-то сложно согласовываются и вообще превращаются в полнейшее "не то".
Роли
Роль определяет задачи, за которые отвечает заинтересованная сторона внутри организации. Бывает, что по формальному названию должности эти задачи не вполне очевидны. Что далеко ходить? Например, где-то аналитик может отвечать и за задачи архитектуры, и за дизайн, и за пользовательскую документацию, а где-то он отвечает за составление требований и немного за тестирование.
Люди часто дают комментарии к требованиям вне сферы своей ответственности, это бывает очень заметно при согласовании больших документов. Понимание роли помогает решить, какой комментарий точно придется учитывать, а за какой достаточно вежливо поблагодарить.
Отношения
Как только в компании планируются изменения, у них сразу появляются друзья и враги.
Тот, кто заинтересован в результатах вашей задачи, может давать больше информации, активно загружать аналитика своими идеями. Жаль, что заинтересованность не обязательно совпадает с важной ролью и полномочиями в принятии решений.
Например, когда аналитик выбирается "в поля" пообщаться с конечными пользователями, то часто видит очень высокую заинтересованность. Это же те, кто каждый день спотыкается о наши поля и кнопки! У них много идей и требований. Вернувшись на рабочее место, аналитик обнаруживает, что полномочий принимать решения и высокого влияния у коллег "в полях" совсем немного.
Отношение к задаче может меняться со временем и это тоже приходится отслеживать. Например, если функция не внедряется вовремя, то и заинтересованность может снизиться.
Полномочия
Казалось бы понятная штука – полномочия в принятии решений, но и здесь есть нюансы.
Бывает, что полномочия делегируются и это важно понять вовремя. Вероятно, не директор, а кто-то из ключевых экспертов в его команде, будет согласовывать требования или предоставлять информацию.
Бывает и наоборот, мы считаем, что кто-то из тех, с кем мы контактируем по вопросам требований может принимать решения, а на самом деле – нет. Однажды я долго собирала по вопросу работы с отчетами целую группу людей и они честно приходили на встречи и пытались что-то рассказать и сформулировать. Сформулировать не получалось. Вопрос был не в сфере их полномочий, и почему-то это не проговаривалось явно на встречах, возможно из-за боязни потерять статус, но принимать решение никто не был готов. Получилось много лишних разговоров, вопрос решился на более высоком уровне принятия решений.
Уровень власти или влияния
Эта характеристика не обязательно совпадает с ролью или должностью заинтересованной стороны.
Во многих командах бывают сотрудники, которые настолько давно работают и так серьезно вовлечены в процесс, что их мнению доверяют без сомнений и много обращаются к ним при принятии решений, особенно в операционной деятельности. Мне запомнился случай, когда при согласовании новых функций системы, я не обсудила их с таким вот влиятельным экспертом. Он был на тот момент в отпуске, я не стала его дожидаться. Потом пришлось дожидаться всей ИТ-команде, когда он выставил замечания уже на этапе разработки. Игнорировать комментарии было невозможно по причине высокого влияния автора. Понимание расстановки сил среди заинтересованных сторон помогло бы сберечь время.
#инструменты
Когда работала в заказной разработке, то заинтересованные стороны по сути назначались. Кого выделили поговорить от заказчика, с тем и говоришь. Аналитик не был допущен к внутренней кухне настолько, чтобы понять, какой вес в компании имеет этот "назначенный". Когда оказалась во внутренней разработке, первое время двигалась привычным путем. Кто принес запрос, у того искала требования. Кто чаще приходит и громче кричит, того требования важнее. Начала различать характеристики заинтересованных сторон только когда поняла, что требования почему-то сложно согласовываются и вообще превращаются в полнейшее "не то".
Роли
Роль определяет задачи, за которые отвечает заинтересованная сторона внутри организации. Бывает, что по формальному названию должности эти задачи не вполне очевидны. Что далеко ходить? Например, где-то аналитик может отвечать и за задачи архитектуры, и за дизайн, и за пользовательскую документацию, а где-то он отвечает за составление требований и немного за тестирование.
Люди часто дают комментарии к требованиям вне сферы своей ответственности, это бывает очень заметно при согласовании больших документов. Понимание роли помогает решить, какой комментарий точно придется учитывать, а за какой достаточно вежливо поблагодарить.
Отношения
Как только в компании планируются изменения, у них сразу появляются друзья и враги.
Тот, кто заинтересован в результатах вашей задачи, может давать больше информации, активно загружать аналитика своими идеями. Жаль, что заинтересованность не обязательно совпадает с важной ролью и полномочиями в принятии решений.
Например, когда аналитик выбирается "в поля" пообщаться с конечными пользователями, то часто видит очень высокую заинтересованность. Это же те, кто каждый день спотыкается о наши поля и кнопки! У них много идей и требований. Вернувшись на рабочее место, аналитик обнаруживает, что полномочий принимать решения и высокого влияния у коллег "в полях" совсем немного.
Отношение к задаче может меняться со временем и это тоже приходится отслеживать. Например, если функция не внедряется вовремя, то и заинтересованность может снизиться.
Полномочия
Казалось бы понятная штука – полномочия в принятии решений, но и здесь есть нюансы.
Бывает, что полномочия делегируются и это важно понять вовремя. Вероятно, не директор, а кто-то из ключевых экспертов в его команде, будет согласовывать требования или предоставлять информацию.
Бывает и наоборот, мы считаем, что кто-то из тех, с кем мы контактируем по вопросам требований может принимать решения, а на самом деле – нет. Однажды я долго собирала по вопросу работы с отчетами целую группу людей и они честно приходили на встречи и пытались что-то рассказать и сформулировать. Сформулировать не получалось. Вопрос был не в сфере их полномочий, и почему-то это не проговаривалось явно на встречах, возможно из-за боязни потерять статус, но принимать решение никто не был готов. Получилось много лишних разговоров, вопрос решился на более высоком уровне принятия решений.
Уровень власти или влияния
Эта характеристика не обязательно совпадает с ролью или должностью заинтересованной стороны.
Во многих командах бывают сотрудники, которые настолько давно работают и так серьезно вовлечены в процесс, что их мнению доверяют без сомнений и много обращаются к ним при принятии решений, особенно в операционной деятельности. Мне запомнился случай, когда при согласовании новых функций системы, я не обсудила их с таким вот влиятельным экспертом. Он был на тот момент в отпуске, я не стала его дожидаться. Потом пришлось дожидаться всей ИТ-команде, когда он выставил замечания уже на этапе разработки. Игнорировать комментарии было невозможно по причине высокого влияния автора. Понимание расстановки сил среди заинтересованных сторон помогло бы сберечь время.
#инструменты
Учебные цели и эксперты
Статистика канала подсказывает, что я уже две недели ни о чем не рассказывала. Так усердно доделывала свою часть учебных материалов для корпоративного курса, что не осталось времени ни на что другое☺️
Это не первый мой опыт работы над учебными материалами и не первый раз в соавторстве с такими же как я аналитиками, имеющими большой коммерческий опыт, но не профессиональными педагогами. Хочу поделиться наблюдениями.
Эксперты берут на себя участие в образовательных проектах в желании поучаствовать в обмене знаниями, передать тот уникальный опыт, что именно они считают важным. Мотивация бывает разной, не берусь утверждать, что это единственный драйвер, но он важен. Когда-то свой первый курс я готовила под надзором методологов, им приходилось постоянно корректировать мои настроения. Оказывалось так, что цели преподавателя могут не совпасть с целями обучения.
У каждого курса есть учебная цель, ориентированная на аудиторию и те навыки, что она после курса должна приобрести. Люди приходят учиться с соответствующими ожиданиями и уровнем подготовки.
Впервые мне поручили обучение сотрудника давным-давно еще в компании ЕПАМ и дело закончилось тем, что мой менти уволился. Старшие товарищи говорили, что от перегруза премудростями😎
Если учащиеся делают первые шаги в профессии, то рассчитывают получить начальные прикладные навыки для решения задач анализа, вероятно, даже в конкретной предметной области. Эксперта может ожидать разочарование, если пришел в образование с миссией "передать максимум знаний". У обучающегося на курсе не обязательно есть цель именно "получить максимум знаний".
В модерируемом курсе, когда проводятся семинары и лекции, есть возможность скорректировать рассказ и некоторые материалы под нужды аудитории непосредственно в потоке. Мне именно этим нравится менторинг, что в нем я отвечаю на конкретный запрос конкретного менти. Сложнее с обратной связью по немодерируемым курсам, где учащиеся самостоятельно знакомятся с материалом и делятся впечатлениями после прохождения, когда время уже потрачено. Тут особенно интересно понимать учебные цели. Иначе может получиться материал, сам по себе не вредный и интересный, подготовленный с большим трудом и привлечением массы источников, но смогут ли выпускники его освоить и применить? О чем-то похожем писала в посте Аналитик с опытом может быть новичком!
#мысливслух
Статистика канала подсказывает, что я уже две недели ни о чем не рассказывала. Так усердно доделывала свою часть учебных материалов для корпоративного курса, что не осталось времени ни на что другое
Это не первый мой опыт работы над учебными материалами и не первый раз в соавторстве с такими же как я аналитиками, имеющими большой коммерческий опыт, но не профессиональными педагогами. Хочу поделиться наблюдениями.
Эксперты берут на себя участие в образовательных проектах в желании поучаствовать в обмене знаниями, передать тот уникальный опыт, что именно они считают важным. Мотивация бывает разной, не берусь утверждать, что это единственный драйвер, но он важен. Когда-то свой первый курс я готовила под надзором методологов, им приходилось постоянно корректировать мои настроения. Оказывалось так, что цели преподавателя могут не совпасть с целями обучения.
У каждого курса есть учебная цель, ориентированная на аудиторию и те навыки, что она после курса должна приобрести. Люди приходят учиться с соответствующими ожиданиями и уровнем подготовки.
Впервые мне поручили обучение сотрудника давным-давно еще в компании ЕПАМ и дело закончилось тем, что мой менти уволился. Старшие товарищи говорили, что от перегруза премудростями
Если учащиеся делают первые шаги в профессии, то рассчитывают получить начальные прикладные навыки для решения задач анализа, вероятно, даже в конкретной предметной области. Эксперта может ожидать разочарование, если пришел в образование с миссией "передать максимум знаний". У обучающегося на курсе не обязательно есть цель именно "получить максимум знаний".
В модерируемом курсе, когда проводятся семинары и лекции, есть возможность скорректировать рассказ и некоторые материалы под нужды аудитории непосредственно в потоке. Мне именно этим нравится менторинг, что в нем я отвечаю на конкретный запрос конкретного менти. Сложнее с обратной связью по немодерируемым курсам, где учащиеся самостоятельно знакомятся с материалом и делятся впечатлениями после прохождения, когда время уже потрачено. Тут особенно интересно понимать учебные цели. Иначе может получиться материал, сам по себе не вредный и интересный, подготовленный с большим трудом и привлечением массы источников, но смогут ли выпускники его освоить и применить? О чем-то похожем писала в посте Аналитик с опытом может быть новичком!
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
Что здесь есть о BPMN?
Когда-то я публиковала здесь задачки по BPMN и немножко придумывала сама. Напомню о них, чтобы не потерялись и пригодились всем, кто до них еще не добрался.
🔅Сколько нужно времени, чтобы проснуться и выпить кофе?
🔅Вопросы для процессных аналитиков
🔅Разнообразие начальных событий в BPMN
#навигация
Когда-то я публиковала здесь задачки по BPMN и немножко придумывала сама. Напомню о них, чтобы не потерялись и пригодились всем, кто до них еще не добрался.
🔅Сколько нужно времени, чтобы проснуться и выпить кофе?
🔅Вопросы для процессных аналитиков
🔅Разнообразие начальных событий в BPMN
#навигация
Задачка из книги Емельяна Игнатьева:
В шесть часов утра в воскресенье гусеница начала всползать на дерево. В течение дня, т. е. до 18 часов, она всползала на высоту 5 м, а в течение ночи спускалась на 2 м. В какой день и час она всползет на высоту 9 м?
В шесть часов утра в воскресенье гусеница начала всползать на дерево. В течение дня, т. е. до 18 часов, она всползала на высоту 5 м, а в течение ночи спускалась на 2 м. В какой день и час она всползет на высоту 9 м?
Anonymous Quiz
31%
среда в 6 ч 00 мин
42%
вторник в 13 ч 12 мин
28%
вторник в 18ч 00 мин
0%
среда в 13 ч 12 мин
Подборка о работе с процессами
Вы помните, какой сегодня день недели? Или как и я начали день с полным ощущением понедельника?
Вчера, как бывает по воскресеньям, разбирала список для чтения. Еще и поэтому сложно вытряхнуть из головы понедельник 🤷♀️ Зато получилась подборка об управлении процессами.
📍Нюансы менеджмента процессов на примере процесса «Управление инцидентами ИТ» Эту статью оставила в закладках, чтобы еще раз перечитать. Здесь на конкретном примере показано управление процессом и почему сначала должен появиться управляемый процесс и уже после KPI.
📍Путеводитель по методологиям совершенствования процессов — 2023 Перевод статьи о методологиях улучшения процессов: что это такое, для чего применяются и какими бывают. Всего в стать перечислено 12 методологий.
📍Российское представительство ABPMP (Ассоциация профессионалов управления бизнес-процессами) опубликовало на Rutube свои материалы. Можно найти полезные видео о моделировании процессов и их оптимизации. И все это от настоящих мастеров.
📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если честно, то сначала хотела пройти мимо этой статьи, но решила, что если кто-то еще в начале пути БА, то статья может пригодиться.
#что_почитать
Вы помните, какой сегодня день недели? Или как и я начали день с полным ощущением понедельника?
Вчера, как бывает по воскресеньям, разбирала список для чтения. Еще и поэтому сложно вытряхнуть из головы понедельник 🤷♀️ Зато получилась подборка об управлении процессами.
📍Нюансы менеджмента процессов на примере процесса «Управление инцидентами ИТ» Эту статью оставила в закладках, чтобы еще раз перечитать. Здесь на конкретном примере показано управление процессом и почему сначала должен появиться управляемый процесс и уже после KPI.
📍Путеводитель по методологиям совершенствования процессов — 2023 Перевод статьи о методологиях улучшения процессов: что это такое, для чего применяются и какими бывают. Всего в стать перечислено 12 методологий.
📍Российское представительство ABPMP (Ассоциация профессионалов управления бизнес-процессами) опубликовало на Rutube свои материалы. Можно найти полезные видео о моделировании процессов и их оптимизации. И все это от настоящих мастеров.
📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если честно, то сначала хотела пройти мимо этой статьи, но решила, что если кто-то еще в начале пути БА, то статья может пригодиться.
#что_почитать
Что посоветуете почитать?
Меня в последнее время слегка озадачивает вопрос вида "а что мне почитать для начала?", когда слышу его от ребят совсем без знаний в какой-либо из разновидностей анализа. Есть ощущение, что первые шаги нужно делать через общение с человеком, а не через книгу или видео. Чтобы можно было задавать вопросы и получать ответы. В каких-то случаях даже группа в мессенджере не самый плохой вариант.
Однажды я встретила человека, который без предварительной подготовки, по совету родственника осилил все 716 страниц книги Вигерса про разработку требований. Не будем сейчас обсуждать выбор и недостатки этой книги, сейчас речь о другом. Такое чтение оказалось травматичным, когда нет даже примерного понимания специфики задач и нет возможности поэтапно своими руками пробовать прочитанное. В моем примере, на любую рекомендацию новой книги ответ был: "Я так сгорел за чтением этой непонятной нудной книги, что не предлагайте мне больше ничего читать, не смогу себя заставить!"
Еще заметила, что многое из книги запоминается в искаженном или устаревшем варианте и переучиваться будет трудно. Вспомнилось как я учила немецкий по учебникам из 50х☺️ . Научиться было интересно, а других книг под рукой не оказалось. Когда потом попала на языковые курсы, то оказалось, что часть прилежно выученных слов уже не используются и даже орфографию успели изменить слегка.
На прошлой неделе мне снова задали похожий вопрос: "Я не аналитик, я работаю в продажах. Хочу понять, какие задачи решают аналитики. Посоветуйте, что почитать для общего понимания?" И я в очередной раз задумалась, что предложить, чтобы не испугать и при этом дать информацию? Предложила книгу Ильи Корнипаева "Требования для программного обеспечения: рекомендации по сбору и документированию"📚
А у вас есть любимая книга для начинающих?
#мысливслух
Меня в последнее время слегка озадачивает вопрос вида "а что мне почитать для начала?", когда слышу его от ребят совсем без знаний в какой-либо из разновидностей анализа. Есть ощущение, что первые шаги нужно делать через общение с человеком, а не через книгу или видео. Чтобы можно было задавать вопросы и получать ответы. В каких-то случаях даже группа в мессенджере не самый плохой вариант.
Однажды я встретила человека, который без предварительной подготовки, по совету родственника осилил все 716 страниц книги Вигерса про разработку требований. Не будем сейчас обсуждать выбор и недостатки этой книги, сейчас речь о другом. Такое чтение оказалось травматичным, когда нет даже примерного понимания специфики задач и нет возможности поэтапно своими руками пробовать прочитанное. В моем примере, на любую рекомендацию новой книги ответ был: "Я так сгорел за чтением этой непонятной нудной книги, что не предлагайте мне больше ничего читать, не смогу себя заставить!"
Еще заметила, что многое из книги запоминается в искаженном или устаревшем варианте и переучиваться будет трудно. Вспомнилось как я учила немецкий по учебникам из 50х
На прошлой неделе мне снова задали похожий вопрос: "Я не аналитик, я работаю в продажах. Хочу понять, какие задачи решают аналитики. Посоветуйте, что почитать для общего понимания?" И я в очередной раз задумалась, что предложить, чтобы не испугать и при этом дать информацию? Предложила книгу Ильи Корнипаева "Требования для программного обеспечения: рекомендации по сбору и документированию"📚
А у вас есть любимая книга для начинающих?
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня еду на Analyst Days-19. Признаться честно, программу смотрю только по дороге к месту проведения. Уверена, что хорошо проведу время, встречу знакомых. На лендинге конференции обещают 1211 участников. Ну и, конечно, узнаю, что подобрал в этот раз программный комитет конференции. Обязательно напишу тут, что успею послушать.
С конференциями мне стало сложно. Чем больше времени проводишь в профессии, тем труднее найти что-то совсем новое. Приходится немного наморщить лоб, чтобы понять – это именно мне так скучно или доклад и правда про очевидное? Когнитивные искажения на конференциях ведь тоже не отключаются 🤷♀️
А еще спикеры на отраслевых конференциях повторяют свои доклады. Когда сравнительно часто бываешь, то очень заметен один и тот же материал под разными названиями, а тем более под тем же названием. Так что я точно знаю на какой доклад не пойду, потому что уже слышала его на Flow в сентябре.
Наверное, вы узнали на фото двух колобков с прошедших Analyst Days, а третий колобок – наша кошка, которая равнодушна к конференциям и совсем не уважает мои трофеи😎
#мысливслух #конференции
С конференциями мне стало сложно. Чем больше времени проводишь в профессии, тем труднее найти что-то совсем новое. Приходится немного наморщить лоб, чтобы понять – это именно мне так скучно или доклад и правда про очевидное? Когнитивные искажения на конференциях ведь тоже не отключаются 🤷♀️
А еще спикеры на отраслевых конференциях повторяют свои доклады. Когда сравнительно часто бываешь, то очень заметен один и тот же материал под разными названиями, а тем более под тем же названием. Так что я точно знаю на какой доклад не пойду, потому что уже слышала его на Flow в сентябре.
Наверное, вы узнали на фото двух колобков с прошедших Analyst Days, а третий колобок – наша кошка, которая равнодушна к конференциям и совсем не уважает мои трофеи
#мысливслух #конференции
Please open Telegram to view this post
VIEW IN TELEGRAM
Analyst Days – 19. Впечатления
Итак, прошла очередная конференция Analyst Days.
Атмосфера как обычно теплая и яркая, стенды светились, ребусы разгадывались, квизы проходились. Народ с удовольствием толпился и общался.
Забавно, но именно на таких мероприятиях можно поближе разглядеть коллег, кого до этого наблюдала только на видеоконференциях. Такие уж непростые времена настали, чтобы в оффлайне поговорить с коллегами, нужно купить билет☺️
Игрушки и шопперы раздавали все те же, что и год назад. Все мы родом из детства и любим новые игрушки, поэтому я немного переживала, что получу дубликат той, что уже есть. Выдохнула, когда достала из сумки R2-D2 😊
Меня приятно удивило, что докладчики представляли очень разные города. Кроме Москвы и Санкт-Петербурга насчитала еще 15 городов.
За два дня послушала 10 докладов и одну дискуссию. Послушала и не смогла определить для какой целевой аудитории их подобрали. Если для совсем начинающих аналитиков, то интересны ли разговоры о матрицах компетенций, типовых запущенных болячках и переговорах с бизнесом, люди же еще туда не дошли? Если для специалистов с опытом больше года, то интересно ли им послушать про User Story и еще про отличия логической модели данных от физической?
Пока я пыталась сегментировать аудиторию, она вовсю задавала вопросы о наболевшем. Вот примеры из моих заметок, наверняка и вам откликается что-то из этого:
📌Как поддерживать актуальность документации, если часть вопросов разработчики решают сами в обход аналитика?
📌Если аналитик исследует рынок, то как быть с продактом?
📌Не сбегут ли все системные аналитики, если их заставлять проводить дискавери?
📌Что делать, если люди привыкли к документации в файлах, а не в вики-системах?
📌Как оценивают кандидата при найме, если нет матрицы компетенций? Что человеку делать, если приняли на работу, а через пол-года требуют соответствовать некоей матрице?
Из всего услышанного выделила для себя доклад "Пять граней мышления аналитика" Григория Печенкина. Для меня всегда большое удовольствие послушать спикеров с огромным опытом в индустрии. Докладчик прекрасно вовлекал зал в ход своих мыслей и зал не оставался равнодушным. Речь шла о том, что хороший аналитик – это специалист с особым типом мышления, которое складывается из пяти составляющих:
📍Системное мышление, которое воспитывается через понимание предметной области как совокупности взаимодействующих систем, включенных в надсистему. Помните разговоры о теории систем и системной инженерии?
📍Логическое мышление. Как умение видеть взаимосвязи между объектами, их свойствами и явлениями, а еще работать с когнитивными искажениями.
📍Понимание мира интересов. Действующие лица предметной области могут быть отнесены к той или иной системе, или надсистеме в зависимости от их интересов. Хороший аналитик умеет это понять.
📍Критическое мышление помогает через сомнение прийти к истине. Хороший аналитик умеет критически осмыслить гипотезы.
📍Визуальное мышление помогает через визуальные модели работать с информацией и направлять ход мысли.
Может быть еще кто-то из нас побывал на Analyst Days? Поделитесь впечатлениями в комментариях🌱
#конференции
Итак, прошла очередная конференция Analyst Days.
Атмосфера как обычно теплая и яркая, стенды светились, ребусы разгадывались, квизы проходились. Народ с удовольствием толпился и общался.
Забавно, но именно на таких мероприятиях можно поближе разглядеть коллег, кого до этого наблюдала только на видеоконференциях. Такие уж непростые времена настали, чтобы в оффлайне поговорить с коллегами, нужно купить билет
Игрушки и шопперы раздавали все те же, что и год назад. Все мы родом из детства и любим новые игрушки, поэтому я немного переживала, что получу дубликат той, что уже есть. Выдохнула, когда достала из сумки R2-D2 😊
Меня приятно удивило, что докладчики представляли очень разные города. Кроме Москвы и Санкт-Петербурга насчитала еще 15 городов.
За два дня послушала 10 докладов и одну дискуссию. Послушала и не смогла определить для какой целевой аудитории их подобрали. Если для совсем начинающих аналитиков, то интересны ли разговоры о матрицах компетенций, типовых запущенных болячках и переговорах с бизнесом, люди же еще туда не дошли? Если для специалистов с опытом больше года, то интересно ли им послушать про User Story и еще про отличия логической модели данных от физической?
Пока я пыталась сегментировать аудиторию, она вовсю задавала вопросы о наболевшем. Вот примеры из моих заметок, наверняка и вам откликается что-то из этого:
📌Как поддерживать актуальность документации, если часть вопросов разработчики решают сами в обход аналитика?
📌Если аналитик исследует рынок, то как быть с продактом?
📌Не сбегут ли все системные аналитики, если их заставлять проводить дискавери?
📌Что делать, если люди привыкли к документации в файлах, а не в вики-системах?
📌Как оценивают кандидата при найме, если нет матрицы компетенций? Что человеку делать, если приняли на работу, а через пол-года требуют соответствовать некоей матрице?
Из всего услышанного выделила для себя доклад "Пять граней мышления аналитика" Григория Печенкина. Для меня всегда большое удовольствие послушать спикеров с огромным опытом в индустрии. Докладчик прекрасно вовлекал зал в ход своих мыслей и зал не оставался равнодушным. Речь шла о том, что хороший аналитик – это специалист с особым типом мышления, которое складывается из пяти составляющих:
📍Системное мышление, которое воспитывается через понимание предметной области как совокупности взаимодействующих систем, включенных в надсистему. Помните разговоры о теории систем и системной инженерии?
📍Логическое мышление. Как умение видеть взаимосвязи между объектами, их свойствами и явлениями, а еще работать с когнитивными искажениями.
📍Понимание мира интересов. Действующие лица предметной области могут быть отнесены к той или иной системе, или надсистеме в зависимости от их интересов. Хороший аналитик умеет это понять.
📍Критическое мышление помогает через сомнение прийти к истине. Хороший аналитик умеет критически осмыслить гипотезы.
📍Визуальное мышление помогает через визуальные модели работать с информацией и направлять ход мысли.
Может быть еще кто-то из нас побывал на Analyst Days? Поделитесь впечатлениями в комментариях🌱
#конференции
Please open Telegram to view this post
VIEW IN TELEGRAM