• Victoria

Скажи мне кто твой друг...

Пост обновлен 4 янв. 2019 г.


Всем привет. Для начала хочу рассказать немного о себе. В IT я попала 8 лет назад. За этот сравнительно небольшой отрезок времени (для меня он кажется довольно длинным :)) я прошла путь от QA до FA (functional analyst) и BA (business analyst). Сразу хочу остановить ревностных сторонников BABOK, который не делит аналитиков на FA и BA. Согласна с вами :) Но, в силу специфики работы, эти роли все же делились, и я прошла путь от FA к BA. Будучи аналитиком во всем (профессиональная деформация она такая) задумываюсь о том, что помогло стать аналитиком, а что мешало, что еще можно развивать и улучшать в своих навыках аналитика.

В это статье хотелось бы рассказать (приобретая при этом новый опыт), что же сделало меня аналитиком.

Расскажу о друзьях, которые помогли мне стать Аналитиком, и почему они оказали положительное влияние.


1. Заказчик

Хорошо, когда заказчик попадается понимающий, толковый, готовый прислушиваться к советам. Но везет так далеко не всем…

Хотя нет, я же о друзьях. И везет гораздо чаще, чем нам кажется.

Типичная ситуация, когда есть мы, Команда (аналитики, разработчики, тестировщики и тд), и есть Он (заказчик, Product Owner, BA, подставьте свой вариант), который не разбирается в своем домене, сам не знает, чего хочет, и диктует нам (специалистам!) как и что делать. Отношения строятся так, будто мы представляем два противоположных лагеря, и получаем в итоге знаменитую картинку «что думал заказчик и что он получил». Для устранения противостояния и организации командной работы хорошо бы построить взаимоотношения, основанные на доверии и понимании, не пытаться найти «пробелы» в знаниях заказчика, и в итоге получить результат, устраивающий все стороны. Зачастую мы не знаем, какая внутренняя игра происходит на той стороне, как меняются требования и решения, какое оказывается давление по срокам и ресурсам.


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

Классический пример: команда предлагает одно решение, а заказчик настаивает на другом, которое является «костылем» с точки зрения разработки. На моей практике было немало подобных случаев и все они превращались в спор, отстаивание своей точки зрения и попытками уломать заказчика (что всегда вызывает сопротивление).


Пример из моего опыта. Наше решение обеспечивало обработку и маршрутизацию данных: получить из одной системы и распределить по другим системам. При обсуждении возможных решений заказчик отказывался от наших предложений по оптимизации процесса валидации данных, доработок в части интерфейсов с системами-потребителями данных, и прочих улучшений. Команда пребывала в недоумении, предлагая различные опции, показывая плюсы и минусы каждого. Все было в пустую: заказчик уперся в самое быстрое и некачественное решение из серии «просто заберите и отдайте дальше». На практике все оказалось очень банально. Это решение было временным (на квартал), через квартал данные и их обработка должны были уйти в другую систему. Данная ситуация возникла из-за уже ранее нарушенного доверия между заказчиком и командой. Заказчик не хотел раскрывать все карты, тратить время на объяснения и споры. Данный пример доказывает, что чаще всего для за любым решением стоят объективные причины. Основная задача (и чаще всего самая сложная) до них докопаться. Однако, зная их, можно предложить наилучшее решение, помочь заказчику решить его проблему и проложить мостик для дальнейшей доверительной работы.


2. Девелоперы и тестировщики

Итак, в «войне» с заказчиком мы объединяемся: ПМ, девы, тестировщики, аналитик и т.д. Ну а потом начинается… кто знает, как лучше сделать и что же нужно этому глупому (хотя нет, мы же договорились заказчик - друг) заказчику. И вот здесь всплывает типичное: мы же аналитики, мы же больше всего общаемся с заказчиком, знаем домен и требования. Но не зря говорят о “замыленном взгляде” и “горе от ума”. Все мы люди и порой не замечаем очевидных вещей. Сейчас я с благодарностью вспоминаю тех девелоперов и тестировщиков, которые в свое время доводили до зубовного скрежета своими вопросами из серии: а зачем это нужно? а как будет если… и тд? Спасибо вам (если вдруг кто-то из вас это прочитает вы явно узнаете себя). Сейчас мне этого не хватает.


Когда думаю об этом, всегда вспоминается один яркий пример. Я только пришла на проект и соответственно мне поручили для старта легкую задачку для анализа: необходимо было добавить на скрин опцию удаления значений из словаря данных. Задачка дольно тривиальная и простая. Но не для разработчиков J Тогда меня засыпали кучей вопросов и предложениями как удалять из разного типа словарей (хотя изначально речь шла об одном), а стоит ли показывать удаленные значения, а что если удаленное значение требуется вернуть и т.д. Заказчику предложение понравилось. В итоге маленькое требование превратилось в хороший скоуп работы. Хотя команда могла просто последовать инструкции и добавить кнопку. Было бы это правильно? Формально – да, требование заказчика было бы выполнено. Но на само деле здесь проявилась командная работа, а заказчик получил больше чем хотел, что только укрепило доверительные отношения меду нами (еще один плюс в копилку решений как дружить с заказчиком).


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


3. Кофе брейки, курилики, обеды и тд

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


Совсем недавний пример. Заказчик захотел внедрить Agile. При этом новшества коснулись и анализа: требования предполагалось делить на эпики, фичи и юзер стори, вести требования одновременно в двух систем