Скажи мне кто твой друг...
Обновлено: 4 янв. 2019 г.
Всем привет. Для начала хочу рассказать немного о себе. В IT я попала 8 лет назад. За этот сравнительно небольшой отрезок времени (для меня он кажется довольно длинным :)) я прошла путь от QA до FA (functional analyst) и BA (business analyst). Сразу хочу остановить ревностных сторонников BABOK, который не делит аналитиков на FA и BA. Согласна с вами :) Но, в силу специфики работы, эти роли все же делились, и я прошла путь от FA к BA. Будучи аналитиком во всем (профессиональная деформация она такая) задумываюсь о том, что помогло стать аналитиком, а что мешало, что еще можно развивать и улучшать в своих навыках аналитика.
В это статье хотелось бы рассказать (приобретая при этом новый опыт), что же сделало меня аналитиком.
Расскажу о друзьях, которые помогли мне стать Аналитиком, и почему они оказали положительное влияние.
1. Заказчик
Хорошо, когда заказчик попадается понимающий, толковый, готовый прислушиваться к советам. Но везет так далеко не всем…
Хотя нет, я же о друзьях. И везет гораздо чаще, чем нам кажется.
Типичная ситуация, когда есть мы, Команда (аналитики, разработчики, тестировщики и тд), и есть Он (заказчик, Product Owner, BA, подставьте свой вариант), который не разбирается в своем домене, сам не знает, чего хочет, и диктует нам (специалистам!) как и что делать. Отношения строятся так, будто мы представляем два противоположных лагеря, и получаем в итоге знаменитую картинку «что думал заказчик и что он получил». Для устранения противостояния и организации командной работы хорошо бы построить взаимоотношения, основанные на доверии и понимании, не пытаться найти «пробелы» в знаниях заказчика, и в итоге получить результат, устраивающий все стороны. Зачастую мы не знаем, какая внутренняя игра происходит на той стороне, как меняются требования и решения, какое оказывается давление по срокам и ресурсам.
Основой хороших отношений с заказчиком является доверие. Без него работать очень сложно, и порой это вызывает только еще большее непонимание и конфликты.
Классический пример: команда предлагает одно решение, а заказчик настаивает на другом, которое является «костылем» с точки зрения разработки. На моей практике было немало подобных случаев и все они превраща