Спор о том, где бизнес-аналитику работать лучше - в продукте или аутсорсе, в IT-среде так же вечен, как спор между приверженцами Android и IOS. Аутсорсеры обвиняют тех, кто в продукте, в лени, мол, работают не напрягаясь, за сроками не гонятся, один и тот же функционал переделывают много раз. Работающие в продукте же в ответ сообщают, что аутсорсеры интересуются только сроками, оставляя качество за бортом.
Не соглашусь ни с одним, ни с другим.
Мне повезло работать в обоих типах компаний, и, хотя вышеописанные персонажи вполне могут существовать, разница в особенностях работы, конечно, гораздо глубже.
Оговорюсь сразу, что под аутсорсом здесь я имею в виду в первую очередь проекты Fixed price, когда команда в ограниченный срок разрабатывает и внедряет решение в рамках определенного бюджета. Во-первых, у меня просто больше опыта работы именно в таких проектах, а во-вторых, с моей точки зрения, в Time and Material или Dedicated Team проектах команда, управляемая и направляемая заказчиком, становится де-факто частью организации заказчика, включается в ее процессы и работает по продуктовому подходу.
Итак, рассмотрим, с какими особенностями может столкнуться бизнес-аналитик, выбрав продуктовую или аутсорс компанию для работы.
Цикл разработки IT - решения. В продукте и атусорсе
Стандартный SDLC в аутсорсе, выглядит вот так: Подготовка - Исследование- Создание - Ограниченная во времени постпроектная поддержка. Всем спасибо, все свободны, привет, новый клиент.
А в продукте есть еще обратная связь.
И это очень важно. Что бы вы ни сделали, вы видите последствия. Отзывы пользователей, данные аналитики, гнилые помидоры перед дверью офиса - не важно. Вы увидите результат и вам придется с ним что-то делать, а значит, начать весь цикл сначала. Это неизбежно. Команда продукта всегда бегает по этому замкнутому кругу от идеи к отзывам, понемногу нащупывая и направляя продукт в нужное русло.
В аутсорсе круга нет. Фидбек от клиента спустя значительное время после внедрения решения - вещь редкая. И обычно касается каких-то вопиющих недостатков, например, клиента оштрафовали потому, что ваше решение нарушило закон. Тогда может до вас и дойдут отголоски. А если недочет не слишком крупный, да еще и вину подрядчика напрямую не докажешь - никогда вы об этом не узнаете и будете это же решение внедрять на следующих проектах.
Нет петли фидбека - нет набитых шишек - риск незамеченных ошибок сильно возрастает. А значит - читаем теорию, изучаем удачные и неудачные кейсы на смежных проектах и стараемся учиться на чужих ошибках, раз уж на своих не выходит.
Планирование
Поговорим немного о треугольнике Сроки - Стоимость - Содержание(Скоуп).
Стоимость в аутсорсинговом проекте зафиксирована. Нет, конечно всегда есть определенные колебания туда-сюда, но у клиента есть бюджет, превысить который он не может, а подрядчик, конечно, заинтересован в том, чтобы освоить этот бюджет по максимуму. Скоуп тоже обычно известен на раннем этапе - иначе как оценить бюджет?
Основная игра идет по линии “Сроки” - “Размер команды”. Нужно ускориться - набрали побольше людей в команду, идем быстрее плана - освободили часть тушить пожары в других проектах. Конечно, это невозможно без качественного планирования всех работ уже на ранних этапах. Когда я пришла в аутсорс, я никак не могла понять - как можно спланировать свою работу на полгода вперед? Оказалось - можно. Аутсорс планирует четко и быстро. На помощь здесь приходят всевозможные техники оценки, сверху-вниз, снизу-вверх, экспертная оценка… Здесь без них - как без рук.
В продукте все иначе. Планы есть всегда - долгосрочные, краткосрочные. Но, в отличие от аутсорса, скоуп не прибит намертво гвоздями. Наоборот, главная цель продуктовых менеджеров - добиться большего эффекта как можно меньшими средствами. И если продукт достигает запланированных финансовых показателей, имея лишь 20% запланированной функциональности, то кому они нужны, эти оставшиеся 80?
Поэтому основная игра в продукте идет по оси “Время”-”Функциональность”. Хотим быстрее - выбросили лишнее, есть время (и бюджет) - можно и красоту навести.
При таком подходе нет смысла планировать подробно на большой срок вперед, а значит, - аджайл, короткие итерации и проверка после каждой - в ту ли сторону идем.
Аналитик и команда разработки
В продукте аналитик с командой - до конца, точнее, без конца, в замкнутом круге от планирования к фидбеку и сначала. В горе и в радости, как говорится.
В аутсорсе такой тесной связи нет. Часто аналитик уходит в другой проект, когда текущий еще в активной разработке и, к сожалению, возникшие в процессе работы вопросы (а они ох как возникают!) команде приходится решать самостоятельно. Также, в аутсорсе чаще, чем в продуктовой разработке, аналитик работает на нескольких проектах и с несколькими командами одновременно. Не секрет, что на разных этапах проекта загрузка аналитика сильно разнится, а качественное планирование наперед позволяет распределить ресурс оптимальным образом.
Вхождение в проект.
В продуктовой компании аналитик и вся команда, фактически, присутствуют при рождении идеи. Очень часто они сами являются ее авторами - появление идей “снизу” в продуктовой компании обычная практика.
В аутсорсе аналитик приходит тогда, когда решение у заказчика созрело. Может, без деталей, может, в общих чертах, но идея пришла в голову клиенту задолго до того, как он решил пригласить к себе специалистов со стороны. Да, можно попытаться проанализировать решение, можно даже частично изменить его, но отправная точка работы аналитика в аутсорсе - уже созданный кем-то концепт.
В продукте же концепт решения это уже почти конечная стадия, после ста гипотез и двухсот проверок. Все остальное - проработка деталей и превращение этого концепта в готовое решение - самая простая и приятная часть работы.
Правила и формальности
В аутсорсе все просто и понятно. Есть подписанные документы, есть планы, разработанные на их основе. Хочешь изменений на полдороги - конечно, все возможно, но за них нужно платить: деньгами и временем.
В продукте подписи не важны. Стейкхолдер может что угодно подписать, а потом прийти и сказать: “И что? Вы же сами видите - так не работает, нужно делать по другому”. Команда вздыхает и делает по другому - а куда деться, все в одной лодке. Поэтому в продукте редко встречаются формальные согласования документации, в них просто нет смысла. Основной анализ и оценка решения все равно происходит на стадии работающего продукта.
Так что не хотите сюрпризов - поймайте, расскажите, переспросите, и не страшно, что усно - актуальная информация из первых рук здесь важнее, чем подпись. Покажите решение настолько рано, насколько сможете. Классическое “нельзя показывать заказчику полуготовое решение” тут не работает. И все равно - будьте готовы к изменениям и переделкам. Продукт это сплошная череда переделок и изменений, ничего не поделаешь.
Заключение
Подведем итоги. Действительно, тип компании сильно влияет на задачи и стиль работы команды и бизнес-аналитика, как ее части. Тем не менее, аналитик остается мостом между бизнесом и разработкой независимо от процессов, проектов и стейкхолдеров. Это основа работы аналитика, ее цель. А средства … пробуйте, сравнивайте и ищите свою идеальную компанию, где вы сможете реализоваться как специалист на все 100%