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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совмещение

Менеджеры-аналитики или аналитики-менеджеры. Кто они?

Мы взяли интервью у Кристины Никифоровой — руководителя отдела аналитики и менеджера проекта. Есть ли кто-то, чье интервью вам тоже было бы интересно? Пишите на адрес ba.sa.community@gmail.com — организуем!

✍🏻 Итак, Кристина расскажи немного о себе?

Я работаю в группе компаний Asprom Group чуть больше 6 лет. Моя должность Руководитель проектов/Начальник отела аналитики. Наша фирма занимается разработкой и внедрения ECM и PLM систем.

Я пришла работать на позицию младший аналитик, стала РП спустя 1,5 года и еще через 2 года получила степень PME (Project Manager Expert). Занимаюсь обеспечением всех этапов проекта и управлением отделом аналитики. Также в мои обязанности входит обучение новых сотрудников. Если на проекте что-то идет не так, то в первую очередь это моя головная боль.

✍🏻 А как ты попала в компанию? Кем тебя взяли?

Попала обычным способом через вакансию на hh. Это была не первая работа, но первая официальная в ИТ. Я сразу решила, что хочу быть менеджером проекта, однако, без опыта работы такой должности не получить, поэтому начала смотреть ваканчии аналитиков и консультантов по внедрению систем.
До сих пор помню, как шла 2,5 км на каблуках на собеседование под дождем в дикий холод, и говорила мужу, что точно не буду тут работать. Однако, во время собеседования мне сразу сказали, что я принята и попросили выйти в понедельник. Даже шанса подумать не дали. Я растерялась и спросила только адрес 🙂

Continue reading «Менеджеры-аналитики или аналитики-менеджеры. Кто они?»