Аналитик · Организация работ · Требования

Формат требований, который вам необходим

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

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

Кратко о себе: сертифицированный бизнес-аналитик (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 «Приоритизация требований»

Аналитик · Организация работ

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

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

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

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

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

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

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

Аналитик · Организация работ · Развитие

Как определить подход к бизнес-анализу и создать его план?

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

Источник: https://business-analysis-excellence.com/business-analysis-approach-plan/

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

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

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

Continue reading «Как определить подход к бизнес-анализу и создать его план?»

Аналитик · Организация работ

Первые пять шагов начинающего бизнес-аналитика в новом проекте

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

 

Шаг 1. А что это за проект?

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

Шаг 2. Читайте, читайте и читайте!

Второй шаг, за который стоит взяться, это прочесть как можно больше доступных материалов, касающихся проекта. Настолько, насколько это возможно. Чтобы ускорить свое понимание начинающему аналитику не очень хочется ходить и задавать вопросы везде и каждому.  Будьте активны: идите и узнавайте всю информацию в документации. Ее будет много. Читайте в тех объемах, который позволяют умственные способности. Так или иначе, у вас накопится основная информация и сложится базовое понимание. А еще, на старте, можете попросить членов команды разъяснять некоторые из областей, которые вы, возможно, так и не поймете из прочитанного.

Шаг 3. Узнавайте людей

Узнайте, “кто есть кто” в вашем проекте, а еще тех, кто с ним тесно  связан. У вас будет команда, и вы столкнетесь с тем, что не всегда понимаете у кого какие роли. Поэтому начинайте выяснять, что делает  каждый в команде проекта. Поговорите с ними, чтобы понять конкретные обязанности. Это даст представление о том, к кому за какой информацией можно обратиться. Возможно, позже вы сможете приступить к анализу заинтересованных сторон проекта. Так что обращайтесь к людям, которые скорее всего и окажутся этими заинтересованными сторонами.

Шаг 4. Поймите свои задачи

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

Шаг 5. Начните и уточняйте каждый шаг

Это просто планирование и осуществление бизнес анализа. Так как вы пока начинающий, вам не придется идти и разрабатывать целый план бизнес-анализа и бизнес подход. Но поговорите с командой проекта и поймите, что от вас ожидается. Тогда вы будете в состоянии целенаправленно работать и предоставлять  практические результаты. Здесь очень важно удерживать связь и ссылаться на своих коллег, команду разработчиков и людей более опытных. Они смогут помочь и подтвердить, что действия, которые вы собираетесь осуществить, — это то, что они от вас ожидали. Именно так вы начнете быстро развиваться.

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

И еще раз:

  1. Прежде всего поймите, какого размера  ваш проект.
  2. Поторопитесь с документацией.
  3. Начинайте узнавать и понимать членов вашей проектной команды и заинтересованные стороны проекта.
  4. Поговорите с вашим менеджером и поймите, что именно вы должны предпринять, чтобы сделать первый шаг.
  5. Продумайте, как вы собираетесь работать, что вам нужно делать, и никогда не переставайте сверяться с коллегами, просить проверить на правильном ли вы пути.

Запись и перевод: Ольга Мезенцева

Источник: https://www.youtube.com/watch?v=LViNZyOKeUs

Автор: Esta Lessing (CBAP), Мельбурн, Австралия

 

 

 

 

Организация работ · Совмещение

Руководитель проекта и аналитик

Автор статьи: Илья Корнипаев, автор книги «Требования для программного обеспечения: рекомендации по сбору и документированию», которую вы можете найти в разделе Книги по управлению требованиями


Рекомендации в виде размышлений о методах контроля работы аналитика на ранних этапах выполнения проекта и оценке качества работы аналитика.

Очень часто в работе я сталкиваюсь с ситуациями, когда руководитель проекта (ПМ) пытается исполнять роль аналитика. Также бывают проекты, где есть один аналитик, а ПМ пытается играть роль второго аналитика – участвует в интервью, рецензирует документы и т.п. Люди, несомненно, бывают разными. В этих случаях ПМ полностью владеет ситуацией на проекте на этапе анализа и может достаточно точно, хотя и субъективно сразу оценить работу аналитика. Некоторым ПМам удается такое совмещение ролей, а некоторым не очень (что по моему опыту случается чаще).

Однако давайте рассмотрим проект, где ПМ не пытается играть роль аналитика (ни первого номера, ни второго), а занимается исключительно функциями, свойственными роли руководителя. Каким же образом ПМ может убедиться, что работа на этом этапе проекта идет по плану и дела идут в целом хорошо?

Первое это собственно план. Планировать начальные фазы проекта очень сложно, ввиду высокой неопределенности и недостатка объективной информации. План может содержать некоторое количество интервью, встреч, и других активностей, которые легко контролировать по факту. Сходил аналитик на встречу, зафиксировал результаты в протоколе (или другом документе) закрываем задачу и т.д. Другие задачи в плане, связанные с разработкой документов контролировать сложнее. План помимо задач по разработке документов должен содержать достаточно точек контроля и соответствующих задач по проверке документов и их согласованию. Также необходимо запланировать заранее задачи по исправлению недочетов, найденных в процессе проверок и согласований.

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

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

ПМы, не желающие вдаваться в подробности содержания документов (требований, спецификаций и т.п.) и доверяющие аналитикам, приходят и спрашивают: «сколько тебе еще осталось писать требования?», «успеешь к пятнице?», «сколько ты уже написал?». Ответы практически всегда бывают положительны и оптимистичны, что, естественно, не гарантирует того, что документ будет полностью завершен к запланированному сроку.

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

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

Второй объективный фактор контроля хода работы – это анализ покрытия.

Этот метод работает только в случае, если:

  1. на входе в начале проекта вы получили от заказчика требования (или другой подобный документ)
  2. импортировали исходный документ в систему управления требованиями
  3. отдельно от исходного документа начали разработку вашей версии детальных требований/спецификации в той же системе
  4. проставляете связи от требований в вашем документе к требованиям в исходном документе

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

Дальше уже можно проверять собственно сам документ целиком. Для приблизительной оценки готовности документа и качества работы аналитика можно считать ошибки и замечания, сделанные в процессе проверки. А можно использовать атрибуты – например, в системе управления требованиями добавить новый атрибут и назвать его «статус проверки». В ходе проверки заполнять этот статус для каждого требования, и после проверки смотреть, какой процент требований в документе не прошел проверку, а какой нет. Такие статусные атрибуты можно также добавить для согласований с заказчиком, разработчиками и тестировщиками.

Если говорить о ретроспективной оценке качества работы аналитиков в проекте, то тут несомненное лидерство за таким показателем, как количество запросов на изменения, поступивших в ходе работы над проектом и в процессе эксплуатации сданной системы. Можно измерять в штуках, а можно и в затратах на доработку связанных с этими запросами на изменения. Конечно, у части из таких запросов может быть причина, лежащая за пределами возможностей предсказания вашей команды (например, мировой финансовый кризис). Но при прочих равных, чем больше запросов на изменения поступает в ходе проекта и после него, тем хуже сработали аналитики.

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