Всем привет. Для начала хочу рассказать немного о себе. В IT я попала 8 лет назад. За этот сравнительно небольшой отрезок времени (для меня он кажется довольно длинным :)) я прошла путь от QA до FA (functional analyst) и BA (business analyst). Сразу хочу остановить ревностных сторонников BABOK, который не делит аналитиков на FA и BA. Согласна с вами :) Но, в силу специфики работы, эти роли все же делились, и я прошла путь от FA к BA. Будучи аналитиком во всем (профессиональная деформация она такая) задумываюсь о том, что помогло стать аналитиком, а что мешало, что еще можно развивать и улучшать в своих навыках аналитика.
В это статье хотелось бы рассказать (приобретая при этом новый опыт), что же сделало меня аналитиком.
Расскажу о друзьях, которые помогли мне стать Аналитиком, и почему они оказали положительное влияние.
1. Заказчик
Хорошо, когда заказчик попадается понимающий, толковый, готовый прислушиваться к советам. Но везет так далеко не всем…
Хотя нет, я же о друзьях. И везет гораздо чаще, чем нам кажется.
Типичная ситуация, когда есть мы, Команда (аналитики, разработчики, тестировщики и тд), и есть Он (заказчик, Product Owner, BA, подставьте свой вариант), который не разбирается в своем домене, сам не знает, чего хочет, и диктует нам (специалистам!) как и что делать. Отношения строятся так, будто мы представляем два противоположных лагеря, и получаем в итоге знаменитую картинку «что думал заказчик и что он получил». Для устранения противостояния и организации командной работы хорошо бы построить взаимоотношения, основанные на доверии и понимании, не пытаться найти «пробелы» в знаниях заказчика, и в итоге получить результат, устраивающий все стороны. Зачастую мы не знаем, какая внутренняя игра происходит на той стороне, как меняются требования и решения, какое оказывается давление по срокам и ресурсам.
Основой хороших отношений с заказчиком является доверие. Без него работать очень сложно, и порой это вызывает только еще большее непонимание и конфликты.
Классический пример: команда предлагает одно решение, а заказчик настаивает на другом, которое является «костылем» с точки зрения разработки. На моей практике было немало подобных случаев и все они превращались в спор, отстаивание своей точки зрения и попытками уломать заказчика (что всегда вызывает сопротивление).
Пример из моего опыта. Наше решение обеспечивало обработку и маршрутизацию данных: получить из одной системы и распределить по другим системам. При обсуждении возможных решений заказчик отказывался от наших предложений по оптимизации процесса валидации данных, доработок в части интерфейсов с системами-потребителями данных, и прочих улучшений. Команда пребывала в недоумении, предлагая различные опции, показывая плюсы и минусы каждого. Все было в пустую: заказчик уперся в самое быстрое и некачественное решение из серии «просто заберите и отдайте дальше». На практике все оказалось очень банально. Это решение было временным (на квартал), через квартал данные и их обработка должны были уйти в другую систему. Данная ситуация возникла из-за уже ранее нарушенного доверия между заказчиком и командой. Заказчик не хотел раскрывать все карты, тратить время на объяснения и споры. Данный пример доказывает, что чаще всего для за любым решением стоят объективные причины. Основная задача (и чаще всего самая сложная) до них докопаться. Однако, зная их, можно предложить наилучшее решение, помочь заказчику решить его проблему и проложить мостик для дальнейшей доверительной работы.
2. Девелоперы и тестировщики
Итак, в «войне» с заказчиком мы объединяемся: ПМ, девы, тестировщики, аналитик и т.д. Ну а потом начинается… кто знает, как лучше сделать и что же нужно этому глупому (хотя нет, мы же договорились заказчик - друг) заказчику. И вот здесь всплывает типичное: мы же аналитики, мы же больше всего общаемся с заказчиком, знаем домен и требования. Но не зря говорят о “замыленном взгляде” и “горе от ума”. Все мы люди и порой не замечаем очевидных вещей. Сейчас я с благодарностью вспоминаю тех девелоперов и тестировщиков, которые в свое время доводили до зубовного скрежета своими вопросами из серии: а зачем это нужно? а как будет если… и тд? Спасибо вам (если вдруг кто-то из вас это прочитает вы явно узнаете себя). Сейчас мне этого не хватает.
Когда думаю об этом, всегда вспоминается один яркий пример. Я только пришла на проект и соответственно мне поручили для старта легкую задачку для анализа: необходимо было добавить на скрин опцию удаления значений из словаря данных. Задачка дольно тривиальная и простая. Но не для разработчиков J Тогда меня засыпали кучей вопросов и предложениями как удалять из разного типа словарей (хотя изначально речь шла об одном), а стоит ли показывать удаленные значения, а что если удаленное значение требуется вернуть и т.д. Заказчику предложение понравилось. В итоге маленькое требование превратилось в хороший скоуп работы. Хотя команда могла просто последовать инструкции и добавить кнопку. Было бы это правильно? Формально – да, требование заказчика было бы выполнено. Но на само деле здесь проявилась командная работа, а заказчик получил больше чем хотел, что только укрепило доверительные отношения меду нами (еще один плюс в копилку решений как дружить с заказчиком).
Моя нынешняя команда не устраивает таких челенджей, задают очень мало вопросов и просто кодят и тестят, а не разрабатывают и отвечают за качество. Поделитесь опытом, если сталкивались с этим и смогли переломить тенденцию.
3. Кофе брейки, курилики, обеды и тд
Говорить о том, что мозгу нужны перерывы, я не буду. Это банально и понятно. Но хочу подчеркнуть, что кухонные разговоры не так уж бесполезны, как может показаться. Просто познакомиться с коллегами из других проектов, наладить связи для обмена опытом, узнать, чем дышит окружающий мир, чем интересуются и что сейчас популярно у разработчиков и прочее. Когда все сидят носом в монитор, такие вопросы возникают намного реже, а вот в неформальной обстановке можно неплохо прокачаться и получить пинок для какой-то новой мысли :)
Совсем недавний пример. Заказчик захотел внедрить Agile. При этом новшества коснулись и анализа: требования предполагалось делить на эпики, фичи и юзер стори, вести требования одновременно в двух системах. В общем нововведения вызывали очень много вопросов из серии «зачем и почему». При этом ответы на них были довольно туманные и чувствовалось отсутствие понимания и у представителя заказчика. А вот кухонные разговоры расставили все на свои места J. При общении за чашкой чая с коллегой из другого проекта выяснилось, что нововведение коснулось многих проектов. А некоторые непонятные требования к процессу анализа были добавлены, чтобы несколько команд могли работать над ними параллельно, но чтобы гранулярность позволяла разделять работу и отслеживать прогресс.
и еще немного довольно стандартных друзей без подвоха
4. Тренинги, communities, self learning
Без этого никуда. Кто-то предпочитает тренинги, кто-то самостоятельное обучение. Тренинги помогают систематизировать то, что есть в голове, найти пробелы в собственных знаниях, осознать ошибки, услышать что-то новое (включая ту же литературу для самообучения). И обмен опытом. Как правило, проблемы у всех аналитиков похожие. И на общих мероприятиях можно услышать решение для конкретной проблемы, ну или просто поплакаться друг дружке в жилетку. Кто же поймет аналитика лучше, чем другой аналитик!
Ндавно на одной из таких встреч речь шла о декомпозиции, которую применяют все каждый день, даже неосознанно в бытовых повседневных делах. Тем не менее, было интересно кто какие принципы и методы использует в работе для декомпозиции и приоритизации, в частности задач анализа. Для себя я открыла несколько новых подходов такие как 100$ и 5 почему (слышала ли о них раньше, но точно не использовала).
И отдельный абзац выделю для BABOK. Не буду призывать считать это библией для аналитиков, но думаю каждому хорошему аналитику стоит прочитать BABOK хотя бы раз, а лучше два: начинающие аналитики узнают, что может быть в их арсенале, а для опытным он поможет структурировать имеющийся опыт. Про необходимость прочтения для сертификации говорить ничего не буду. Здесь мне еще похвастаться нечем. Лень она увы такая, мощная и изобретательная штука на отговорки :)
5. Собеседование
Один из лучших способов оценить собственные знания. Даже если нет желания менять работу, все же можно пройти несколько интервью в разных компаниях (надеюсь рекрутеры не читают этот блог и не видят подобные советы). Это позволит получить независимую оценку знания, понять запросы рынка и вашу рыночную стоимость. Более простой вариант – попросить коллег провести такое интервью. Условия не столь экстремальны, однако тоже поможет в выявлении пробелов. Когда долго работаешь на одном проекте, то используешь один и тот же набор навыков аналитика, и не замечаешь, как начинаешь терять неиспользуемые. Совсем недавно практиковала такое с коллегой из соседнего проекта. Я просила не щадить и задавать побольше каверзных вопросов. Интересно отметить, что часть вопросов неосознанно были вызваны наболевшими проблемами на проекте. Получился тоже своеобразный обмен опытом в форме вопросов и ответов. Такие вот интервью помогают держать скилы в тонусе.
На пути к хорошему аналитику врагов нет, кроме нас самих нашей лени, а все остальные, в конечном итоге, только закаляют в нас Аналитика. Не забывайте спрашивать себя иногда: а чем я сейчас занимаюсь? как я развиваюсь? там ли я где хочу быть?
Поделитесь своим опытом что помогло вам стать аналитиком.