Ловушки для аналитика в проекте с историей

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

%d0%9d%d0%b0-%d1%80%d0%b0%d1%81%d0%bf%d1%83%d1%82%d1%8c%d0%b5 Большинство проектов, в которых я принимала участие в роли аналитика, были проекты со своей историей.

Что это за проекты:

  1. Раньше для заказчика уже разрабатывались какие-либо проекты, а вы как новый аналитик пришли в очередной проект.
  2. Проект идет уже некоторое время, а вы как аналитик пришли в команду для усиления состава аналитиков или замены кого-то из них.

С какими трудностями аналитик может столкнуться, работая в проекте с историей?

Я выделила основные и самые распространенные ловушки, в которые может попасть аналитик, попавший на проект «с историей».

Ловушка №1. Ожидание экспертных знаний от аналитика

Заказчику нравится работать с одной и той же проектной командой:

  1. Заказчика устраивают знания и опыт проектной команды в предметной области;
  2. Проектная команда знает все о разработанном продукте, процесс разработки новых модулей или развитие существующей функциональности занимает меньшее время.

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

%d0%a3%d1%87%d0%b5%d0%bd%d0%b8%d0%ba

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

Как быть:

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

А) Изучение предметной области:

  • Нормативная документация (Регламенты, промышленные стандарты и т.п.);
  • Проектная документация (техническое задание, руководство пользователя, руководство администратора, функциональные спецификации);
  • Экспертные знания членов проектной команды (аналитиков, внедренцев, тестировщиков, разработчкиов).

Б) Применение теоритических знаний на практике:

  • Привлечение новичка к бизнес-тестированию;
  • Работа на 3-ей линии технической поддержки (аналитик консультирует внедренцев и отвечает на вопросы заказчика по разработанному решению, сначала под контролем ведущего аналитика);
  • Написание небольших частей на разработку новой функциональности или развитие существующей (от простого к сложному).

Ловушка №2. Устоявшийся формат работы: «Здесь так принято»

В начале, небольшое лирическое отступление и рассказать об опыте, который ставился на обезьянах. Несколько обезьян сажали в клетку, в которой посередине был подвешен банан. Каждый раз, как одна из обезьян пыталась сорвать этот банан, все обезьяны в клетке окатывались холодной водой. Так повторялось до тех пор, пока все обезьяны не прекратили попытки сорвать банан. Затем одну обезьяну заменяли на новенькую, которая, конечно же, пыталась сорвать банан, но тут же ее отталкивали и били боле опытные соседки, водой при этом обезьяны не окатывались. Замена обезьян повторялась до тех пор, пока в клетке не осталось ни одной «опытной» обезьяны. Все, кто сидел в клетке ни разу не получали «холодный душ», но ни одна из обезьян не пыталась не пыталась сорвать банан. Почему? Потому что здесь так принято!

%d0%a2%d1%80%d0%b8-%d0%be%d0%b1%d0%b5%d0%b7%d1%8a%d1%8f%d0%bd%d1%8b-%d0%9e%d0%bb%d1%8c%d0%b3%d0%b0-%d0%a1%d0%b8%d0%bc%d0%be%d0%bd%d0%be%d0%b2%d0%b0

Так и новый аналитик, который приходит на проект «с историей» может попасть в подобную ловушку.

Когда на проекте новому аналитику выдают готовое описание процесса, примеры документов и говорят: «Делай вот так». При этом, почему вот так «опытные» товарищи проектной команды не объясняют, потому что для них это «само собой разумеющееся», а новенький аналитик по каким-то причинам не попытался все выяснить.

Что получается: Человек бездумно начинает множить как хорошие, так и плохие практики. Самое страшное, если кто-то со стороны Заказчика, кто также стал «новеньким», спросит, а почему так, а в ответ увидит большие глаза и услышит: «Так всегда было».

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

Кому задавать вопросы? Членам проектной команды: прежде всего ведущему аналитику. Если нет возможности спросить у ведущего аналитика, то поинтересоваться можно у менеджера проекта, владельца продукта, о том в какой форме должны быть представлены требования, как организуется процесс согласования решения, проведение испытаний и т.п. Если спросить совсем некого, то нужно руководствоваться здравым смыслом, и делать так, как вы понимаете и считаете правильным. Подкреплять свое видение правильного можно, например, отдав кусочек своего документа на ревью разработчику/ тестировщику и посмотреть как это будет работать на практике, насколько лучше будет восприниматься новый формат.

А если вы, изучив вопрос о построенном процессе работы, вдруг понимаете, что он неэффективен? В таком случае не нужно множить плохие практики, а нужно проработать свой вариант решения для плавного перехода от старого формата работы к новому, вынести его на обсуждение проектной команды, при необходимости согласовать с Заказчиком. При этом не попасться в другую ловушку: «Вы работаете не так!

Ловушка №3. Вы работаете не так!

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

%d0%9b%d0%b5%d0%bd%d0%b8%d0%bd-%d0%bd%d0%b0-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b5%d0%b2%d0%b8%d1%81%d1%82%d1%81%d0%ba%d0%be%d0%bc-%d0%bc%d0%b8%d1%82%d0%b8%d0%bd%d0%b3%d0%b5-%d0%a1%d0%b5%d1%80%d0%be

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

Как быть:

Вступая на тропу критики текущего решения новичку нужно руководствоваться следующими правилами:

  1. Нельзя обесценивать прошлый опыт проектной команды.
  2. Предлагать свое решение с позиции «взрослый»-«взрослый».
  3. Выдвигая свою идею соотнести пользу и затраты на реализацию идеи.

Ловушка №3. Манипуляция «прошлыми договоренностями»

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

%d0%a3-%d1%80%d0%b0%d0%b7%d0%b8%d0%b1%d1%82%d0%be%d0%b3%d0%be-%d0%ba%d0%be%d1%80%d1%8b%d1%82%d0%b0-%d0%9d%d0%b8%d0%ba%d0%b8%d1%84%d0%be%d1%80-%d0%a0%d0%b0%d1%89%d0%b5%d0%ba%d1%82%d0%b0%d0%b5%d0%b2

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

Как быть:

  • Не давать немедленного ответа, а взять паузу на размышление.
  • Уточнить детали, когда обсуждалось, где фиксировалось.
  • Задать уточняющие вопросы как для запроса на изменение (не акцентируя внимания, что вы рассматриваете ситуацию как ЗИ).
  • Попробовать связаться с аналитиком, работавшем на проекте до вас (возможно,  есть документальные подтверждения договоренностям, о которых вспомнил заказчик).
  • Продумать варианты решения, оценить работы по аналитике и согласовать ответ с менеджером проекта.

 Ловушка №4. Ответственность за документы, автором которых вы не являетесь

У Аркадия Райкина есть известный монолог «Кто сшил костюм?», в котором описывается ситуация с пошивом костюма на заказ, где в результате вместо рукавов пришиты брючины, а вместо брючин рукава. И покупатель задает вопрос: Кто этот костюм сшил? Оказывается, что делали его сразу несколько человек. Кто-то отвечал за пуговицы, кто-то за крой, но никто из них не отвечал за конечный результат.

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

burlaki-na-volge-repin

Почему аналитик не принимает ответственность за решение целом:

  1. Качество написанного такое, что хочется от него отгородиться, и никак не связывать себя с ним.
  2. Аналитик не понимает решение в целом, поэтому хочет отвечать только за понятную ему часть, которую сам и разработал.
  3. Аналитику недостаточно опыта, или в силу характера, он не хочет принимать ответственность за целое решение.

Как быть:

  1. Улучшить качество написанного насколько это возможно в условиях ограничения времени. Либо согласовать вопрос о том, чтобы выделить это время, может быть позднее.
  2. Прояснить все моменты, которые не понятны, либо скорректировать формулировки требований так, чтобы они были понятны.
  3. Принять ответственность за решение внутри себя.

Выводы:

Работать на проектах «с историей» сложнее, чем на новых проектах, где только выстраиваются отношения с Заказчиком и проектной командой.

Для того чтобы успешно работать на таком проекте нужно:

  1. Затратить достаточно большое количество времени на изучение предметной области.
  2. Понять существующие принципы построения работы проектной команды.
  3. Если процесс построен неэффективно, то не опускать руки, а реализовывать изменения к лучшему – постепенно, принимая во внимание ограничения по срокам и ресурсам.
  4. Отвечать не только за конкретную задачу, но и за целостность решения после реализации данной задачи.
  5. Не идти на поводу «прошлых договоренностей», а принимать взвешенное решение согласованное с менеджером проекта.
Запись опубликована в рубрике О работе аналитика. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *