Существует огромное количество книг и статей, которые подробно описывают, как выполнять ту или иную работу аналитика, однако, зачастую, многие подходы требуют существенной адаптации к реалиям работы в аутсорсинговой ИТ-компании. Многие идеи звучат весьма заманчиво и логично, но на практике не применимы (либо применимы с большими оговорками) в виду специфики. Да и в целом, стоит заметить, что роль аналитика весьма нова для наших ИТ компаний.
Если рассмотреть деятельность любой аутсорсинговой компании, то цель компании – заработать много денег путем продажи как можно больше ресурсов на как можно долгий срок, ставя максимально высокие внешние ставки и максимально низкие внутренние помогать людям устранять их проблемы при помощи ИТ-решений. Любая аутсорсинговая компания предоставляет сервис, и в основу этого сервиса, как правило, входит, непосредственно, разработка программного обеспечения. Данный факт исторически обусловлен, т.к. на заре становления аутсорсинговых ИТ-компаний заказчики снабжали проектные команды спецификациями и работа шла именно в соответствии с ними. Однако у разработчиков и тестировщиков неизбежно возникали вопросы по тому либо иному аспекту спецификации и на эти вопросы непременно должен был кто-то отвечать. В своем большинстве, все подобные вопросы шли через менеджера либо технического лидера проекта, которые активно взаимодействовали с заказчиком. Именно эти люди знали все тонкости. Однако такая активность могла занимать значительное время и отрывать их от основных обязанностей. Так или иначе, сформировалась потребность в новой роли на проектах: ИТ-аналитик (бизнес-аналитик, системный аналитик). Именно ИТ-аналитик и отвечает за работу с требованиями.
На любом проекте, от нас, как аналитиков, требуется добиться того, чтобы команда разработчиков знала, что им разрабатывать, команда тестировщиков – чему должно соответствовать то, что разработали разработчики, а заказчик – что он получит в итоге. Как правило, чтобы решить данную задачу, мы пишем спецификацию на программное обеспечение (software requirements specification, далее SRS), которая обычно содержит функциональные и нефункциональное требования, предъявляемые к системе. Именно этот документ необходим разработчиками и тестировщикам, а иногда и заказчикам (как минимум, они должны принимать участие в согласовании и утверждении данного документа). В общем случае для того, чтобы написать SRS, необходимо предпринять ряд шагов. Упрощено, эти шаги такие: сбор требований -> анализ требований -> документирование требований -> проверка требований. Цепочка весьма логична, однако есть некоторые нюансы.
Начнем, пожалуй, с проектных процессов. Кто определяет процесс на проекте? Менеджер и заказчик. Фактически, для нас это означает, что на каждом новом проекте работать мы будем по-разному. А значит, прошлый опыт нужно будет адаптировать к новым реалиям, либо вообще отказаться от него. В этом плане, конечно же, было бы удобнее работать по одному процессу на всех проектах, но во многих ли компаниях процессы строго регламентированы? Многие ли компании соответствуют уровню зрелости (CMMI), хотя бы 3го уровня?
Дальше – больше. Чтобы написать SRS, нужно четко понимать, какие бизнес-задачи должно решать данное ПО, какие есть ограничения, какие реальные бизнес-потребности существуют у заказчика и как пользователи будут использовать ПО. Аналитик без опыта ничего не стоит, потому что он просто не знает ответов на эти вопросы. Однако всегда есть возможность во всем этом разобраться, правда это стоит времени и денег, да и заказчики не склонны платить за обучение чужих сотрудников. Тем не менее, если аналитик не понимает, почему нужно ПО, то он просто превращается в секретаршу, которая записывает все «хотелки» заказчика. К счастью, понимание приходит со временем (у каждого данное время индивидуально) и у аналитика появляется реальный опыт.
А теперь посмотрим на типы проектов в компаниях. Они во многом различаются между собой, в том числе и по домену. Один проект – это e-commerce, второй – это accounting, третий – это просто сайт-визитка. Много ли аутсорсинговых компаний, которые занимаются проектами только специфического домена? Конечно, можно утверждать, что в компании есть много аналитиков с различной специализацией. А может ли компания обеспечить 100% загрузку каждого аналитика проектами, которые соответствуют его специализации?
А вот ещё один интересный момент. Представим, что стартует новый проект. Что конкретно должен делать аналитик? Как отмечалось выше, работа может происходить по схеме «сбор требований -> анализ требований -> документирование требований -> проверка требований». Реализация двух последних шагов весьма тривиальна: проверка требований, как правило, достигается за счет вовлечения subject matter experts в процесс согласования и утверждение спецификации, а документирование требований осуществляется в соответствии с каким-либо шаблоном (например, вот таким: http://processimpact.com/process_assets/srs_template.doc). Но вот реализация первых двух шагов может вызвать затруднение у неопытных аналитиков.
Проблем много, но они все решаемы. И чем более опытен аналитик, тем успешнее он справляется с ними. Однако сколько аналитиков работает на типичном проекте? Я думаю, что в большинстве случаев ответ будет «один». Тогда как же происходит преемственность и передача знаний?
Все поставленные вопросы ещё раз подчеркивают актуальность создания белорусского сообщества аналитиков для обмена опыта и обсуждения новых идей.
Автор: Андрей Шелуховский
Обсуждение на форуме: http://analyst.by/forum/materialy-saita/analitik-v-autsorsingovoi-kompanii
