Part 1. Первый опыт и шишки
Я пришел в сферу как практик, не проходя курсы и изучая все самостоятельно — набивая шишки и читая книжки :) Если вы прошли академическое обучение, потом сдали сертификацию и вообще все четко и по плану – это другой путь, со своими «приколами».
Начну с начала, как говорится, — с момента вхождения в профессию и первого (раза) опыта.
Лично у меня все началось со внедрения. Внедрение — это такая работа, когда тебе дают большой (и тупой) напильник, показывают кучу необработанного материала и картинку с “лошадью”. Задача — выпилить лошадь. При том, что заказчик на нее потом залезет и попытается проскакать километров эдак 10. Правда, быстро поймет, что лошадь лишь отдаленно напоминает изначальную задумку, вообще неживая и использовать ее максимально эффективно можно только как вешалку для одежды (прямо как стул в углу комнаты).
Естественно, пока ты молод и зелен, работаешь ты даже не с целой лошадью, а скорее с правым задним копытом или левым ухом, это как повезет. Бывает, что и другие части тела попадаются…
Можно легко догадаться, что лошадки у меня получались то без ноги, то без головы, то без хвоста. Иногда голема удавалось даже оживить — но творения были в лучших хоррор-традициях. Тем не менее, структуру лошади и ее возможности (в моем случае лошадь = ERP-система) я уже знал и даже мог подсказать незадачливому пользователю, что стоять сзади коня не стоит — можно и в лоб получить.
В общем, с бизнес-анализом первое время работа была связана мало и больше похожа на сисадмина/техподдержку/консультанта из магазина в одном флаконе. Но стоит отдать должное: она привила внимание к деталям и научила эмпатии. Без этих навыков сложно быть аналитиком – понять боль стейкхолдера, избежать missed requirements, да и досконально стори не написать.
Однажды я угробил 50000 записей в продакшн базе, которые, (Слава богу, науке и Украине) благодаря крутому коллеге и частичной дубликации данных в двух БД, потом были восстановлены. Помню этот жизненный урок и теперь сначала запускаю все запросы на стейджинг-окружении (а лучше локально или вообще в БД не лезу, по возможности).
В первый раз оптимизировал бизнес с помощью трех галочек согласования документа и нескольких правил. Раздал доступ разным пользователям и обеспечил невозможность нажать одну галочку, если уже нажали другую. Доволен был собой как слон. Пользователи правда все так же распечатывали этот документ и носили на подпись начальникам…
Было весело — мы много летали в командировки, много общались, и по истечении нескольких лет проектная команда ощущалась как семья. Я растил софт скилы, тестировал UI, делал запросы в БД (хехе), много общался с конечными пользователями и даже побывал в телефонной техподдержке. И однажды увидел у коллеги творение Вигерса “Разработка требований к программному обеспечению”. Предо мной открылся портал (в ад) в мир качественных требований и системного подхода к их описанию. До сих пор считаю ее отличным пособием по входу в профессию. Но курсы, конечно, лучше :)
Параллельно с чтением Вигерса в свободное время на работе повлялось все больше активностей вроде “посмотреть, как работает начальник отдела, выслушать жалобы (и мат) — все записать и передать разработчикам”. В тот момент я не знал, как правильно назвать мои записки. Это теперь я уже в курсе, что такое single user requirements documented by natural language. Или bugreport (в зависимости от того, как громко матюгался пользователь, озвучивая замечание).
Первые техники сбора требований — интервьюирование и наблюдение — тоже были сразу опробованы на практике, а потом уже подкреплены теорией. Немного позже стало известно, что перед тем, как интервьюировать стейкхолдера, нужно подготовить агенду, набросать вопросы, а лучше прийти с прототипом. А в начале пути ты с максимально учтивым видом заглядываешь в кабинет и такой: “Как у Вас дела? Работает система?” и слушаешь час, как беднягу работа достала, и вообще начальник у него – ***** (цензура не позволяет написать это слово, тк многие начальники могут узнать себя). Но после таких разговоров я уходил с четкой мыслью “нужно облегчить ему жизнь” и продолжал читать полезные ресурсы, чтобы понимать, как именно это можно сделать.
Спустя несколько лет работы с ERP, несколько месяцев усиленной подготовки и немало потраченных нервов, я ушел в другую компанию и полноценный (ура!) бизнес-анализ. О чем расскажу немного позже.
Опытом поделился, свою историю рассказывать начал. И подытожить хочу вот чем
- В начале очень нужен ментор. Без него никак. Информации море, и стоит чуть копнуть — сразу тонешь. Круто, если у ментора все по полочкам и есть (хотя бы какой-то) план, которого вы придерживаетесь. Меня мой первый ментор научил быть дотошным, рисовать IDEF0 диаграммы (и немножко BPMN), и что конечному пользователю нужны максимально подробные инструкции.
- Будет много косяков. Сначала — вообще тьма, потом меньше. К этому нужно быть готовым и стараться не воспринимать каждый, как последний (на этом месте работы). К сожалению или к счастью, ошибки — очень действенный механизм мотивации и адаптации, и мы на них нехило так учимся. Здесь под “мы” я имею в виду тех, кто хочет расти, а не просиживать штаны на работе.
- По бизнес-анализу очень много информации и теории, в частности. Подходов к требованиям несколько, техник масса, моделей и нотаций тоже хватает. А если в первый год открыть BABOK, то можно и кукухой поехать. Основной совет — узнали что-то новое и сразу применяем, потому что забудется. На практике очень важно иметь общее понимание между командой разработки и заказчиком, а этого можно достигнуть, просто разговаривая с обеими сторонами. Да, занимает много времени, да, не всегда эффективно — зато работает. А используя богатый аналитический инструментарий, мы лишь повышаем качество и скорость своей работы, хотя цель остается прежней.
Автор: Stsiapan Sazanavets
