Мы публикуем в канале не только свои мысли, но и ссылки на злободневные вопросы к размышлению. А любое размышление посвященное конкретному вопросу - суть анализ.
В чем основная задача аналитика? Вероятно вы задавали себе уже это вопрос. Так вот, основная задача ЛЮБОГО анлитика - это уменьшение энтропии в области его деятельности. Что это значит если мы говорим про системного аналитика? Правильно, основная задача системного аналитика - максимально полное, точное и простое описание функционала, такое что разработчик взяв требования аналитика, сразу понял что к чему и у него не осталось открытых вопросов.
Полезная шпаргалка, призванная облегчить описание и оценку целостности архитектуры ИС (Регулярно обновляется): http://eaonapage.com/Enterprise%20Architecture%20on%20a%20Page%20(v1.2).pdf
Прокачайте навык описания предметной области и используйте его в повседневной жизни (англ.) - Большой плюс опсианного подхода - легкость в освоении и интуитивная понятность формата. http://www.domainstorytelling.org/
Domain Storytelling
A collaborative, visual, and agile way to build domain-driven software
Конец года близок, время подвести итоги!
Все мы знаем, чтобы начать что-то новое, нужно завершить что-то старое. Как же сделать это просто и с пользой? На самом деле очень просто, достаточно актуализировать своё резюме!
Зачем это делать, и в чем польза?
Рассказываю:
1. Структурирование ваших знаний: точно и лаконично сформулировать свои мысли не так то просто, вам потребуется провести анализ того чем вы занимались на протяжении года, вспомнить всё до мельчайших подробностей, вытянуть из них суть, сформулировать и зафиксировать её;
2. Ретроспективный анализ позволит понять где вы работали хорошо, а где чего-то не хватило, чего именно? Какие навыки/знания вам хорошо бы подтянуть? Может быть вы отвлекались от сути и вам просто не хватило времени, а может вы ступили на неизведанную дорогу и переоценили свои силы. Подумайте об этом, как поступить в следующий раз?
3. Вы так же сможете оценить какая работа вам приносила больше удовлетворения, а какая приносила одно лишь раздражение и усталость. Это позволит вам направить свой корабль к наиболее интересным и перспективным берегам.
4. В процессе составления резюме рекомендую так же ознакомиться и с интересующими вас вакансиями, и получить дельту между вашими навыками/знаниями, и требованиями в резюме. Это поможет составить вам маршрут к работе вашей мечты.
Обновление резюме, очень полезное упражнение, потратив на него всего час времени вы сэкономите дни (а может и недели!) напрасных усилий. Даже если вас полностью устраивает текущая работа - обновите резюме! Особенно, если вы актуализировали его более года назад, просто сделайте это чтобы идти дальше.
Конец года – отличное время для подведения итогов!
Все мы знаем, чтобы начать что-то новое, нужно завершить что-то старое. Как же сделать это просто и с пользой? На самом деле очень просто, достаточно актуализировать своё резюме!
Зачем это делать, и в чем польза?
Рассказываю:
1. Структурирование ваших знаний: точно и лаконично сформулировать свои мысли не так то просто, вам потребуется провести анализ того чем вы занимались на протяжении года, вспомнить всё до мельчайших подробностей, вытянуть из них суть, сформулировать и зафиксировать её;
2. Ретроспективный анализ позволит понять где вы работали хорошо, а где чего-то не хватило, чего именно? Какие навыки/знания вам хорошо бы подтянуть? Может быть вы отвлекались от сути и вам просто не хватило времени, а может вы ступили на неизведанную дорогу и переоценили свои силы. Подумайте об этом, как поступить в следующий раз?
3. Вы так же сможете оценить какая работа вам приносила больше удовлетворения, а какая приносила одно лишь раздражение и усталость. Это позволит вам направить свой корабль к наиболее интересным и перспективным берегам.
4. В процессе составления резюме рекомендую так же ознакомиться и с интересующими вас вакансиями, и получить дельту между вашими навыками/знаниями, и требованиями в резюме. Это поможет составить вам маршрут к работе вашей мечты.
Обновление резюме, очень полезное упражнение, потратив на него всего час времени вы сэкономите дни (а может и недели!) напрасных усилий. Даже если вас полностью устраивает текущая работа - обновите резюме! Особенно, если вы актуализировали его более года назад, просто сделайте это чтобы идти дальше.
Конец года – отличное время для подведения итогов!
Data Analyst или Data Scientist?
Последнее время мы все чаще слышим эти слова, и вам кажется что это одна и та же профессия, но на самом деле это не так. В чем же отличие?
Если кратко: аналитик данных (data analyst) это специалист который готовит имеющиеся данные к визуализации, проводит их агрегацию и очистку, строит дашборды и формирует отчеты.
В то время как ученый по данным (data scientist) занимается извлечением полезных знаний из имеющихся данных, для дальнейшего их применения в проверке бизнес-решений и построении предсказательных моделей.
Подробнее: http://ivyproschool.com/blog/2014/10/28/data-analyst-or-data-scientist/
Последнее время мы все чаще слышим эти слова, и вам кажется что это одна и та же профессия, но на самом деле это не так. В чем же отличие?
Если кратко: аналитик данных (data analyst) это специалист который готовит имеющиеся данные к визуализации, проводит их агрегацию и очистку, строит дашборды и формирует отчеты.
В то время как ученый по данным (data scientist) занимается извлечением полезных знаний из имеющихся данных, для дальнейшего их применения в проверке бизнес-решений и построении предсказательных моделей.
Подробнее: http://ivyproschool.com/blog/2014/10/28/data-analyst-or-data-scientist/
Для аккумуляции знаний я начинаю цикл статей посвященный тематике системного анализа, бизнес-анализа и анализа данных.
Я ценю ваше время, потому статьи будут в формате лаконичных, но ёмких блог-постов. В статьях я планирую давать краткую выжимку из теории, которую я буду обильно снабжать практическими советами из своего опыта. В общем – сама суть, без лишней воды, потому вы сразу сможете применить новые знания в своей практике.
Такие статьи будут идти под тэгом #ШколаАналитика
Я ценю ваше время, потому статьи будут в формате лаконичных, но ёмких блог-постов. В статьях я планирую давать краткую выжимку из теории, которую я буду обильно снабжать практическими советами из своего опыта. В общем – сама суть, без лишней воды, потому вы сразу сможете применить новые знания в своей практике.
Такие статьи будут идти под тэгом #ШколаАналитика
Первый пост из цикла #ШколаАналитика посвящен классификации требований. Поехали! https://telegra.ph/Trebovaniya-kakie-i-zachem-01-23
Telegraph
Требования, какие и зачем
Какие бывают требования? В статье я буду использовать классификацию Вигерса, как одну из самых распространенных и достаточно подробных. На самом деле классификации требований (как и определения требований) существует довольно много, но они плюс-минус все…
Иногда я разбираю чужие статьи, интересные и не очень. Вот по ссылке коротенькая статья на тему "Нужен ли аналитик команде?": https://spark.ru/startup/devim/blog/36433/nuzhen-li-analitik-komande
Разложим ее по полочкам, но говорить будем исключительно про разработку в IT.
На мой взгляд статья однобокая, потому что все описанные проблемы сводятся к наладке коммуникации и планирования.
На самом деле, всё обычно обстоит несколько иначе. Так, если у вас пользователи не могут работать с продуктом, а заказчик доволен, то скорее всего вы неправильно выбрали заказчика, или у вас их несколько.
Если у вас проблема с интеграцией вашего продукта в корпоративный ландшафт, вам не аналитик, а архитектор нужен.
Если у вас шквал требований с непонятным приоритетом - вам нужен продакт оунер, который наполнит и приоритезирует беклог.
Если у вас не налажено взаимодействие в команде и люди часто пилят один и тот же функционал параллельно - вам остро необходим проджект-менеджер.
Так зачем вам аналитик? Бизнес-аналитик вам нужен когда у вас есть бизнес-процесс, как понять что он есть? Очень просто - во взаимодействие включено более двух команд и результат этого процесса напрямую зависит от каждой из них.
Системный-аналитик вам нужен когда у вас сложная предметка, интроверты-разработчики, заказчик не доволен результатами, а тестеры непойми что тестируют. Т.е. у вас наблюдается острая нехватка в четких, формализованных и согласованных требований.
Чуть позже напишу свой вариант статьи "Нужен ли вам аналитик".
Разложим ее по полочкам, но говорить будем исключительно про разработку в IT.
На мой взгляд статья однобокая, потому что все описанные проблемы сводятся к наладке коммуникации и планирования.
На самом деле, всё обычно обстоит несколько иначе. Так, если у вас пользователи не могут работать с продуктом, а заказчик доволен, то скорее всего вы неправильно выбрали заказчика, или у вас их несколько.
Если у вас проблема с интеграцией вашего продукта в корпоративный ландшафт, вам не аналитик, а архитектор нужен.
Если у вас шквал требований с непонятным приоритетом - вам нужен продакт оунер, который наполнит и приоритезирует беклог.
Если у вас не налажено взаимодействие в команде и люди часто пилят один и тот же функционал параллельно - вам остро необходим проджект-менеджер.
Так зачем вам аналитик? Бизнес-аналитик вам нужен когда у вас есть бизнес-процесс, как понять что он есть? Очень просто - во взаимодействие включено более двух команд и результат этого процесса напрямую зависит от каждой из них.
Системный-аналитик вам нужен когда у вас сложная предметка, интроверты-разработчики, заказчик не доволен результатами, а тестеры непойми что тестируют. Т.е. у вас наблюдается острая нехватка в четких, формализованных и согласованных требований.
Чуть позже напишу свой вариант статьи "Нужен ли вам аналитик".
SPARK
Нужен ли аналитик команде?
В идеальном IT-мире в каждой команде есть аналитик, а лучше несколько, под разные задачи: системный аналитик для формулировки задач разработчикам, бизнес-аналитик для совершенствования процессов, интеграционный ...
#АналитикДна
Вы спрашивали что такое рекурсия, господа? Отвечаем!
Вот вам пример из реального письма аналитика заказчику:
…Нотификации с обнуленным id будут обрабатываться по правилам, которые будут приняты для обработки нотификаций с обнуленным id…
Пожалуйста, никогда, слышите, никогда так не пишите! А то заказчик сломает мозг уже на третьем цикле рекурсии, пытаясь распарсить фразу которая не имеет смысла.
Вы спрашивали что такое рекурсия, господа? Отвечаем!
Вот вам пример из реального письма аналитика заказчику:
…Нотификации с обнуленным id будут обрабатываться по правилам, которые будут приняты для обработки нотификаций с обнуленным id…
Пожалуйста, никогда, слышите, никогда так не пишите! А то заказчик сломает мозг уже на третьем цикле рекурсии, пытаясь распарсить фразу которая не имеет смысла.
#АнализСреды
Сегодня разбираю статью с хабра: https://habr.com/ru/company/retailrocket/blog/431572/
Статья посвящена такой, до боли знакомой каждому аналитику, теме как «Функциональные требования». Но автор статьи, по-видимому, не читал Вигерса, а потому перемешал понятия, и функциональные требования с НФТ.
Введу небольшой ликбез:
1. User Story – это не что делает пользователь чтобы достичь результата, а что пользователь хочет получить от системы, т.е. это не действие, а результат который ожидает пользователь;
2. Use Cases – да с помощью них можно описывать сценарий использования, системы, но удобен он исключительно в формате когда у вас есть actor (пользователь) и конечный процесс который вы описываете. Не стоит путать Описание UseCase’а и диаграмму UseCases - диаграмма в статичном виде описывает основные сценарии использования системы, для того чтобы выделить её границы из общей среды.
3. Wireframe - это не средство визуализации своей идеи, а макет пользовательского интерфейса. И он относится к НФТ.
Если хотите научиться лучше понимать и разбираться в видах требований почитайте мою статью про требования: https://telegra.ph/Trebovaniya-kakie-i-zachem-01-23
Сегодня разбираю статью с хабра: https://habr.com/ru/company/retailrocket/blog/431572/
Статья посвящена такой, до боли знакомой каждому аналитику, теме как «Функциональные требования». Но автор статьи, по-видимому, не читал Вигерса, а потому перемешал понятия, и функциональные требования с НФТ.
Введу небольшой ликбез:
1. User Story – это не что делает пользователь чтобы достичь результата, а что пользователь хочет получить от системы, т.е. это не действие, а результат который ожидает пользователь;
2. Use Cases – да с помощью них можно описывать сценарий использования, системы, но удобен он исключительно в формате когда у вас есть actor (пользователь) и конечный процесс который вы описываете. Не стоит путать Описание UseCase’а и диаграмму UseCases - диаграмма в статичном виде описывает основные сценарии использования системы, для того чтобы выделить её границы из общей среды.
3. Wireframe - это не средство визуализации своей идеи, а макет пользовательского интерфейса. И он относится к НФТ.
Если хотите научиться лучше понимать и разбираться в видах требований почитайте мою статью про требования: https://telegra.ph/Trebovaniya-kakie-i-zachem-01-23
Хабр
Как писать функциональные требования
Привет, Хабр! Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич. На этапе разработки...
"Мой Круг" опубликовал зарплаты в ИТ за второе полугодие 2018.
В целом для аналитиков всё стабильно:
1. Первым по медиане идет Системный Аналитик – тут без изменений, Хороший системник всегда востребован;
2. Вторым по медиане идет ученый по данным, обратите особое внимание на правый «ус» - 90% перцентиль насколько он длиннее чем у всех остальных, это говорит о том что среди ученых по данным есть «элита», которая получает значительно больше своих коллег. И это не удивительно, т.к. таких специалистов довольно мало на рынке, а спрос на них велик: У компаний накопилось множество данных, и они не знают что с ними делать;
3. Третьими идут Аналитики данных, как отличить аналитика данных от ученого по данным я недавно писал: https://tttttt.me/PowerAnalyst/19. Вкратце аналитик по данным это начинающий ученый по данным;
4. Традиционно группу аналитиков замыкают бизнес-аналитики. Но на самом деле ошибочно относиться к ним как к нижнему слою иерархии! Их позиция обусловлена тем, что «аналитические» позиции начального уровня чаще всего именуются «бизнес-аналитиками». Плюс, стоит заметить, что бизнес-аналитик явление в ИТ не столь популярное, сколь системный аналитик.
Полная версия статьи тут: https://vc.ru/hr/57880-zarplaty-v-it-vo-vtorom-polugodii-2018-goda
В целом для аналитиков всё стабильно:
1. Первым по медиане идет Системный Аналитик – тут без изменений, Хороший системник всегда востребован;
2. Вторым по медиане идет ученый по данным, обратите особое внимание на правый «ус» - 90% перцентиль насколько он длиннее чем у всех остальных, это говорит о том что среди ученых по данным есть «элита», которая получает значительно больше своих коллег. И это не удивительно, т.к. таких специалистов довольно мало на рынке, а спрос на них велик: У компаний накопилось множество данных, и они не знают что с ними делать;
3. Третьими идут Аналитики данных, как отличить аналитика данных от ученого по данным я недавно писал: https://tttttt.me/PowerAnalyst/19. Вкратце аналитик по данным это начинающий ученый по данным;
4. Традиционно группу аналитиков замыкают бизнес-аналитики. Но на самом деле ошибочно относиться к ним как к нижнему слою иерархии! Их позиция обусловлена тем, что «аналитические» позиции начального уровня чаще всего именуются «бизнес-аналитиками». Плюс, стоит заметить, что бизнес-аналитик явление в ИТ не столь популярное, сколь системный аналитик.
Полная версия статьи тут: https://vc.ru/hr/57880-zarplaty-v-it-vo-vtorom-polugodii-2018-goda
#IIBA #DataDriven
Я давно топлю за Data-Driven подход к управлению требованиями, ведь очень часто у компании уже есть данные, но нет инструмента их обработки и анализа. Что же делает типовой аналитик в этой ситуации? Правильно, он привычно идет к пользователям которые знают «как надо», и успешно собирает с них «хотелки», полностью игнорируя наличие дополнительной информации в виде данных.
Почему так происходит? По нескольким причинам:
1. У аналитика недостаточно технических навыков чтобы извлечь данные;
2. Аналитик считает данные — деталями реализации, а значит это уже «работа» девелопера, его же задача, как аналитика, написать «чистые» требования, тем более что заказчик с таким подходом часто согласен;
3. У аналитика нет времени лезть в данные, у него Agile, ему требования нужны сегодня/вчера.
4. Аналитик далёк от бизнеса, даже если он извлечет данные, он не сможет понять историю их появления и то как они могут помочь ему в выявлении требований.
В итоге игнорирование данных может привести как к нескольким циклам переработки требований, так и к полной невозможности реализовать запланированный функционал.
Мое мнение — аналитик должен собрать всю имеющуюся информацию на этапе выявления требований, и уж тем более не упускать такой ценный источник информации как данные, запомните, данные, в отличие от пользователей, никогда не фантазируют и всегда отражают реальное положение вещей.
Крупнейший институт бизнес-анализа (IIBA), так же обратил внимание на указанную проблему, и запустил цикл статей на тему симбиоза бизнес/системного анализа и науки о данных. Первая вышедшая водная статья рассказывает о том как данные преобразуют бизнес.
Я давно топлю за Data-Driven подход к управлению требованиями, ведь очень часто у компании уже есть данные, но нет инструмента их обработки и анализа. Что же делает типовой аналитик в этой ситуации? Правильно, он привычно идет к пользователям которые знают «как надо», и успешно собирает с них «хотелки», полностью игнорируя наличие дополнительной информации в виде данных.
Почему так происходит? По нескольким причинам:
1. У аналитика недостаточно технических навыков чтобы извлечь данные;
2. Аналитик считает данные — деталями реализации, а значит это уже «работа» девелопера, его же задача, как аналитика, написать «чистые» требования, тем более что заказчик с таким подходом часто согласен;
3. У аналитика нет времени лезть в данные, у него Agile, ему требования нужны сегодня/вчера.
4. Аналитик далёк от бизнеса, даже если он извлечет данные, он не сможет понять историю их появления и то как они могут помочь ему в выявлении требований.
В итоге игнорирование данных может привести как к нескольким циклам переработки требований, так и к полной невозможности реализовать запланированный функционал.
Мое мнение — аналитик должен собрать всю имеющуюся информацию на этапе выявления требований, и уж тем более не упускать такой ценный источник информации как данные, запомните, данные, в отличие от пользователей, никогда не фантазируют и всегда отражают реальное положение вещей.
Крупнейший институт бизнес-анализа (IIBA), так же обратил внимание на указанную проблему, и запустил цикл статей на тему симбиоза бизнес/системного анализа и науки о данных. Первая вышедшая водная статья рассказывает о том как данные преобразуют бизнес.
#Лайфхак #БигДата
Когда вам кто-то порядком надоедает рассказами про свою большую бигдату, мощный машинлернинг, и дата-ориентированный подход во всём, есть способ спасти свои уши и здравый смысл одним простым вопросом:
Сколько петабайт данных у вас есть?
Этот вопрос обладает магической силой, услышав его бигдатер уходит в себя и скрывается за горизонтом. Проверено на личном опыте.
Когда вам кто-то порядком надоедает рассказами про свою большую бигдату, мощный машинлернинг, и дата-ориентированный подход во всём, есть способ спасти свои уши и здравый смысл одним простым вопросом:
Сколько петабайт данных у вас есть?
Этот вопрос обладает магической силой, услышав его бигдатер уходит в себя и скрывается за горизонтом. Проверено на личном опыте.