Аналитик · Интервью · Развитие · Сертификация

Хочу, чтобы через год в России было намного больше сертифицированных бизнес-аналитиков!

Интервью с аналитиком из Америки! Статья о том, как получить CBAP, авторские материалы, которые вы можете использовать при подготовке, и советы для тех, кто планирует изучать BABOK.

Continue reading «Хочу, чтобы через год в России было намного больше сертифицированных бизнес-аналитиков!»

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интервью

Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 3. Активности и планы, советы аналитикам

Активности и планы, советы аналитикам


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

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

 Как иллюстрация того, о чем я. Недавно ко мне на собеседование пришел ведущий аналитик со стажем что-то около 12 лет. Знаете, почему он уходит с достаточно оплачиваемого места работы? Потому что потребности в серьезном системном анализе у бизнеса нет. Разработка ведется итерациями на основании очень высокоуровневых “историй”.  Детализация не проводится. Всесторонний и глубокий анализ не проводится. Детали выясняются “по ходу реализации”, импакт на “соседние” подсистемы и компоненты общего контура автоматизации не происходит. Интерфейсные взаимодействия не прорабатываются.  Ну и качество продукта думаю вам уже понятно исходя из сказанного…

 Вернусь к ответу на вопрос…

Управление требованиями не существует как дисциплина “сама в себе”. Например, в CMMI если вы посмотрите внимательно есть Requirements development и Requirements Management. Они по определению сильно связаны. Да и вообще — весь процесс разработки — цельный процесс и многие дисциплины выполняются параллельно, итеративно, с сильным им пактом друг на друга.

 На мой взгляд кабан доска, например, — это совсем не про управление требованиями. Да и, собственно, если в проекте нет хотя бы 3 типов требований, их статусов и трассировок между ними, — то о каком управлении требованиями идет речь? Нет его. Равно как и системного анализа с большой вероятностью “нормального” нет в этом случае. Continue reading «Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 3. Активности и планы, советы аналитикам»

Интервью

Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 2. Об опыте работы аналитиком и проектах

Опыт работы аналитиком и работа на проектах


Как вы стали аналитиком?

Андрей: Как я говорил раньше — я поступил в ВУЗ — тогда он назывался “Севастопольский Приборостроительный Институт” (СПИ) на специальность 2202 “Информация” и, в принципе, нас и учили быть теми кто впоследствии становится системными аналитиками или системными архитекторами. Бондарев Владимир, Чернега Виктор и другие замечательные люди, преподаватели и педагоги факультета АВТ СПИ, — те люди, которые научили любить систематизацию, программирование, научили думать и подходить к решению задач нестандартно.  

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

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

 Как вы стали начальником отдела аналитики?  Что нужно сделать аналитику, чтобы его назначили начальником отдела аналитики?

Андрей: Просто продолжу воспоминания… Continue reading «Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 2. Об опыте работы аналитиком и проектах»

Интервью

Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 1. О написанных книгах

Вопросы, связанные с написанием книг


Как вам пришла идея написать книгу «Путь аналитика»?

Андрей: В 2009 году мы собрались с коллегами в неформальной обстановке и делились проблемами становления отдела анализа и производственными проблемами, с которыми сталкивались в работе. Одним из наиболее проблемных мест в области разработки ПО было и остается отсутствие у разных участников проектных команд одинакового понимания роли системного аналитика, методов его работы, методов анализа.

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

Я поделился этой идеей с Верой Ивановой, которая поддержала мою затею и согласилась выступить соавтором книги.

Вера: Я поддержала идею Андрея! У нас уже было создано много методологических материалов и возникло желание поделиться опытом.

На тот момент мы уже не работали вместе в одной компании, а идея написать книгу позволила нам снова поработать вместе над одним проектом. Continue reading «Интервью Андрея Перервы и Веры Ивановой, авторов книги «Путь аналитика». Часть 1. О написанных книгах»

Конференции

Анонс конференции «Проектирование бизнес-архитектур 2017»

Шестая конференция «Проектирование бизнес-архитектур 2017» — ключевое событие года для профессионалов по проектированию бизнес-архитектур и управлению бизнес-процессами. В рамках этого мероприятия ведущие эксперты расскажут о наиболее современных и эффективных подходах к развитию организаций, поделятся best practice их применения.

В программе:

  • 12 спикеров, среди которых – признанные методологи и эксперты в таких предметных областях как BA, BPM, LEAN, ТРИЗ, системная инженерия, мотивация персонала и т.д.;
  • Кейсы от ведущих консультантов по управлению с примерами решения бизнес-задач;
  • Открытое обсуждение каждого доклада;
  • Специальные гости конференции:

Роджер Берлтон — сооснователь, ведущий колонки «Бизнес-архитектура» портала BPTrends.com, автор одной из первых книг по BPM «Business Process Management: Profiting from Process», один из разработчиков IIBA’s BABOK v.3, участник разработки Business Architecture Guild body of knowledge (BIZBOK) с доклдадом «Мечта архитектора: бизнес в стиле Agile».

Диляра Гайсина — директор консультационной практики PricewaterhouseCoopers в сфере оказания услуг финансовым организациям России, Центральной и Восточной Европы с докладом «Трансформация современных бизнес-моделей в сторону экосистем».

Для кого: 

Конференция будет интересна начинающим специалистам и экспертам в области бизнес-архитектур и бизнес-процессов, топ-менеджерам и собственникам, заинтересованным в развитии компаний на основе системного подхода.

Даты проведения: 26-27 октября 2017 г.

Место проведения: Москва, отель «Милан» (м. Домодедовская).

Организаторы:

Как это было в прошлом году: Отчет и краткий видеорепортаж по итогам прошлогодней конференции 

Условия участия и регистрация

 

 

Релокация · Совмещение

Бесценный опыт переезда и работы в Лондоне от Катерины Неткачёвой

Около пяти лет назад Катерина переехала в Англию и готова поделиться с вами опытом релокации. В этой статье вы узнаете о визах, проблемах переезда и особенностях устройства на работу в Лондоне. А также о том, как зарекомендовать себя на новом месте. Легко, с душой и интересом 🙂

Традиционное английское чаепитие, куда ж без него?
(многоярусная этажерка вкусняшек — это на двоих, сама я всё не съем :))

Continue reading «Бесценный опыт переезда и работы в Лондоне от Катерины Неткачёвой»