Надоело писать ТЗ по шаблону? Я расскажу, как я избежала скучных требований, заинтересовала команду, и
предложила заказчику приятную “плюшку”.

Автор: Грицышина Динара

Кратко о себе: сертифицированный бизнес-аналитик (Certified Professional Requirements Engineering Foundation Level, Certified Professional in Requirements Writing) с опытом более 4-х лет. Вела русскоязычные и иностранные проекты, на последнем работала около 2-х лет. Вела документацию на английском языке. Общалась с иностранными коллегами.
В настоящий момент работаю в продуктовой компании, познаю новые прелести работы аналитика.
Задумываюсь иногда, чем я могла бы заниматься, и в голову не приходит ничего увлекательнее аналитики.

 

Continue reading «Формат требований, который вам необходим» →

Эта статья для системных аналитиков, которым интересно, какими программами пользуются в работе их коллеги. Понятно, что набор ключевых систем в рамках одной компании будет совпадать. Но иногда вы 5 лет сидите с коллегой за соседними столами, ходите вместе пить чай и совершенно случайно узнаете, что есть офигенный инструмент, значительно облегчающий ему жизнь. И оказывается, что он тратит минуты на то, на что у вас уходит час.

Автор статьи: Анна Гасраталиева, соавтор ITworks!, ведущий аналитик и тимлид в компании Nexign (бывш. «Петер-Сервис»)

Ниже представлен мой список используемых инструментов, бережно собранный за 7 лет работы аналитиком. Большая часть этих программ была у кого-то увидена и только благодаря отзывчивости коллег заняла свое место в моем профессиональном арсенале. Чем-то я пользуюсь часто, чем-то редко, но каждая из них мною любима и нужна.

Continue reading «Рабочее место одного системного аналитика» →

Статья — участник конкурса от ITWorks!

Источник: https://www.bridging-the-gap.com/requirements-prioritization/

Автор:  Laura Brandenburg

Вольный перевод: Анна Гасраталиева

Попросите заинтересованных лиц на своем проекте определить приоритеты требований, и вы, вероятно, услышите стоны. С одной стороны, все мы понимаем, что бюджеты проектов ограничены, а приоритетность требований помогает получить максимальную выгоду от инвестиций в технологии. Но с другой стороны, маленькая часть каждого из нас хочет все это сразу и прямо сейчас.

И именно поэтому мы сопротивляемся приоритизации требований. Если вы уже считаете себя “слишком бизнес-ориентированным,” значит вам стоит сосредоточиться как раз на том, чтобы помочь заинтересованным лицам получить четкое представление о том, что по-настоящему важно.

Continue reading «Приоритизация требований» →

Статья — участник конкурса от ITWorks!

Источник: “Success Secrets for the Business Analyst‟s Mind”,2018, доступ по подписке: https://business-analysis-excellence.com

Автор: Esta Lessing, Certified Business Analyst Professional (CBAP), Melbourne, Australia

Перевод: Ольга Мезенцева

Вы подаетесь на гораздо большее количество вакансий, чем действительно нужно?

Люди не понимают, насколько важно сопроводительное письмо для поиска работы. И даже не понимают, насколько важно само резюме! Я просмотрела много резюме и прочитала много сопроводительных писем к ним, и была поражена тем, что люди теряют большие возможности, не представляя себя должным образом.

Сэкономишь на копейку, потеряешь миллион: если не писать соответствующее сопроводительное письмо для каждой вакансии то, скорее всего, получится сэкономить много времени. И подать заявку на гораздо меньшее количество рабочих мест. Стоит настроить себя на более плодотворные и продуктивные усилия по поиску работы. Следуйте таким советам:

Совет 1. Пишите сопроводительное письмо на каждую вакансию

И не надо жаловаться или отказываться от этого. Важно «настроить» свое сопроводительное письмо конкретно для той работы, куда вы подаете заявку. Его же там будут читать! Обратитесь к человеку, который представляет компанию по имени (если вы его знаете), используйте ту же терминологию, что и в вакансии, рекламе компании. И укажите конкретное название обязанностей и должности/вакансии точно так, как они там указаны.

Continue reading «Как написать сопроводительное письмо к резюме бизнес-аналитика» →

Статья — участник конкурса от ITWorks!

Источник: https://business-analysis-excellence.com/requirements-conflict-8-ways-manage-sticky-stakeholder/

Перевод: Максим Мишин

Каждый бизнес-аналитик сталкивался со «скользким стейкхолдером» (под стейкхолдером мы понимаем заинтересованную сторону проекта со стороны бизнес-заказчика) хотя бы в одном проекте, не так ли? Что ж, у меня были эти встречи в разных формах, контекстах и степенях серьезности на протяжении всей моей карьеры в качестве бизнес-аналитика. Я считаю, что мне очень повезло разобраться в таких ситуациях позитивным и конструктивным образом … в большинстве случаев!

Что касается роли бизнес-аналитика, независимо от того, выполняется ли она в проекте по методике Agile, водопада или просто в процессе изменения бизнес-процесса, «проблемы», с которыми мы сталкиваемся при работе с стейкхолдерами, всегда каким-то образом связаны с конфликтом их требований.

Continue reading «8 способов управлять стейкхолдерами в проекте» →

Статья — участник конкурса от ITWorks!

Источник: https://www.bridging-the-gap.com/user-stories-use-cases/

Автор:  Laura Brandenburg

Вольный перевод: Анна Гасраталиева

От переводчика: на нашем практикуме в ITWorks начинающие аналитики постоянно спрашивают “Зачем нам эти варианты использования? Все уже давно пишут истории!” или “А мы должны и истории и сценарии писать? Чем они отличаются?”

Я планировала написать свою статью по этой теме, чтобы не объяснять это каждый раз, но тут наткнулась на статью от Лоры, которая достаточно четко выразила главную причину, почему так важно понять оба инструмента.  В переводе ее статьи я буду использовать сокращение UC и «истории», но если вы все еще путаетесь в этих терминах, то вот расшифровка:

• Пользовательские истории — User Stories (в переводе будут сокращаться до US или “истории”)
• Варианты использования (в русскоязычных статья достаточно хорошо прижилось сокращение ВИ) — прецеденты, сценарии использования, Use Cases (в переводе будут сокращаться до US или “сценарии”)

(строго говоря, сценарии и варианты использования это не совсем одно и то же, но мы оставим это за рамками статьи)

Итак, поехали.

Continue reading «Пользовательские истории против вариантов использования (User Stories Versus Use Cases)» →

Статья — участник конкурса от ITWorks!

Источник: “Success Secrets for the Business Analyst‟s Mind”,2018, доступ по подписке: https://business-analysis-excellence.com

Автор: Esta Lessing, Certified Business Analyst Professional (CBAP), Melbourne, Australia

Перевод: Ольга Мезенцева

Роль бизнес-аналитика лучше всего описывается с точки зрения жизненного цикла разработки системы (SDLC).

SDLC — это процесс или методология, широко применяющаяся ко всем проектам. Это серия фаз, которые пройдет каждый проект, и все, что его будет касаться, с точки зрения этой методологии. Ее также можно сравнить с любой деятельностью, которую можно разбить на этапы «начать, делать работу и закончить» с тем ключевым отличием, что у SDLC заранее определены фазы.

SDLC состоит из набора конкретных действий, которые должны выполняться в течение каждой из фаз. SDLC применяется более или менее подобным образом, как и куда бы вы его не применяли. Будучи бизнес-аналитиком, вы всегда (если вы находитесь в среде проекта) выполняете свою роль части SDLC. Ваша роль меняется по мере того, как меняется SDLC в течение жизненного цикла. Давайте рассмотрим, что бизнес-аналитик обычно делаете на каждом этапе.

Continue reading «Что делает бизнес-аналитик на рабочем месте?» →