Ни для кого не секрет, что аналитики – одна из самых вольно и многогранно трактуемых профессий.
И, несмотря на наличие целых двух профессиональных стандартов, каждая компания индивидуально очерчивает круг задач, возложенных на специалиста, занимающего эту должность.
В своей статье я хочу поделиться своим личным опытом и рассказать, какие роли может совмещать аналитик во время обычного проекта, какие задачи закрыть, а также куда развиваться, если основная работа по проекту становится совсем скучной.
Я надеюсь, что моя история поможет вам с удивлением узнать, на что похожи ваши собратья, а также обозначит возможные точки роста и развития.
Отказ от ответственности
Все, о чем пойдет речь дальше, — это сугубо личный опыт в вполне специфическом виде деятельности, заключающемся в разработке и внедрении нестандартных решений на базе конкретной системы со своей платформой и собственным языком программирования.При этом данная деятельность дополнительно ограничена предметной спецификой внедряемой системы, а также внутренними технологиями вендора, выступающими в качестве локальных стандартов.
Ну и как вишенка на торте, эта деятельность осуществляется в пользу кровавого предприятия.
И когда я говорю о кровавом предприятии, я имею в виду проекты в очень крупных компаниях - почти все нефтегазовые, крупнейшие банки, промышленники, ритейл и т.д. Соответственно, аналитик, о котором пойдет речь в статье, — это человек, существующий внутри всей вышеупомянутой парадигмы.
Более того, это вполне реальный и живой человек, каким бы сферическим конем в вакууме он ни казался вам во время чтения.
Прелюдия
Вообще тема самоопределения аналитика в космосе достаточно взрывоопасна.Каждый раз, когда в профессиональных сообществах, на форумах, митапах, конференциях или в телеграм-чатах поднимается вопрос «кто все-таки эти чертовы аналитикиЭ», начинаются ожесточенные холивары, в ходе которых одни аналитики доказывают другим аналитикам, что каждый из них должен и должен Я не делаю.
Становится еще смешнее (или грустнее), когда на эту тему начинают говорить разного рода HR-специалисты или методисты.
Во всех этих холиварах я предпочитаю занимать позицию, суть которой заключается в одном-единственном слове – специфичность.
Другими словами, каждому необходимо понимать, что набор функций и задач аналитика всегда будет сильно различаться в зависимости от конечного работодателя, проекта и команды.
Вам может быть интересно, почему я вдруг решил, что могу об этом поговорить? Это просто.
Достаточно перечислить роли, которые я меняю на протяжении любого своего проекта:
- бизнес-аналитик;
- Системный аналитик;
- UI/UX дизайнер;
- технический писатель;
- тестер;
- учитель;
- поддерживать
- наставник;
- Технический руководитель;
- Руководитель группы.
Рынок
Однако начнем издалека.Точнее, от той ситуации, которая сейчас сложилась на рынке.
Если зайти, например, на хедхантер и вбить в строку поиска слово «аналитик», нас засыплет всем богатством фантазий и интерпретаций по теме.
Конечно, чаще всего встречаются обычные аналитики.
Без всяких разъяснений, от греха подальше.
В описаниях этих вакансий можно увидеть множество интересных функций, задач, должностных обязанностей и требований к кандидатам.
Некоторые работодатели осмеливаются заявить о категорировании бизнес- и системных аналитиков в своих вакансиях и тем самым практически роют себе яму.
Они даже не представляют, сколько самих аналитиков погибло в этой кровавой битве.
Оптимизированная и емкая категория ИТ-аналитиков довольно популярна.
В их описании обычно присутствует целое российское поле экспериментов с обязанностями, ограничивающееся, по сути, только ИТ-сферой.
Эти вакансии больше всего напоминают мне истории о тысячах программистов, которых регулярно просят починить пылесос или чайник.
Наиболее честно поступают те, кто хотя бы в заголовке пытается указать, что именно нужно будет «проанализировать».
В результате появляются совершенно разные вакансии, такие как «Аналитик SQL», «Аналитик бизнес-процессов», «Аналитик требований», «Аналитик 1С», «Аналитик продаж», «Аналитик маркетинга» и т. д. Однако это не предотвращает различий.
в задачах даже в вакансиях с двумя одинаковыми названиями.
Стандарты
Казалось бы, точку в этой истории должны были поставить профессиональные стандарты, задачей которых является именно зафиксировать цели конкретной профессиональной деятельности и дать комплексное описание трудовых функций специалиста, действий, совершаемых в рамках их реализации, а также необходимые знания и навыки.Но не тут-то было.
Конечно, мы должны радоваться, что стандарты все еще существуют, хотя и появились сравнительно недавно.
Осенью стандарту системного аналитика исполнится пять лет. Значительно позже планку бизнес-аналитика повысили – этому нет и года.
Интересно, что эти стандарты декларируют различие между бизнесом и системным аналитиком уже на уровне кодов профессиональной сферы: для системного аналитика код 06, а для бизнес-аналитика - 08. Другими словами, системный аналитик аналитик относится к профессиональной сфере «коммуникации, информационные и коммуникационные технологии», а бизнес-аналитик – к сфере «финансы и экономика».
И никакого ИТ для тебя.
Если перейти к целям профессиональной деятельности, закрепленным в стандартах, разница станет еще более очевидной и занимательной.
Системному аналитику, поскольку он относится к сфере ИТ, поручается с чистой совестью работать с требованиями, упоминая программное обеспечение, автоматизированные системы, в общем, все, что мы любим.
Бизнес-аналитик, в свою очередь, работает не с требованиями, а с потребностями, но его цель ориентирована на изменения в организации, приносящие пользу.
И, заметьте, ни слова о системах или программно-аппаратных комплексах.
При этом огромное количество тех, кто создает различного рода программные продукты, имеют в трудовых книжках простую запись «бизнес-аналитик».
Впрочем, зачем далеко ходить, лично меня восемь лет называли кем угодно, выполняющим одни и те же функции.
Поэтому, чтобы не ввязываться в терминологические споры, в дальнейшем повествовании я все же буду использовать самое общее и нейтральное слово «аналитик».
Миссии
Перейдем к конкретике.Любой проект, в котором так или иначе участвует наш аналитик, проходит через 4 глобальные миссии, назовем их предпродажной, предпроектной, проектной и внедренческой.
Конечно, аналитик может не участвовать во всех миссиях, а может подключиться к любой из них изолированно, но раз уж мы переходим в супергеройский режим, поговорим подробно о каждой.
Сразу оговорюсь: сопровождение как миссию я убрал из списка совершенно сознательно, потому что.
держать на этих задачах специалиста высокого уровня считаю нерационально.
предпродажа
Первая миссия — это, конечно же, предпродажа.Стоит отметить, что не все и не всегда привлекают к этой миссии аналитиков, считая предпродажи прерогативой продавцов и менеджеров проектов.
Однако со временем аналитики смогли доказать свою полезность и жизнеспособность на данном этапе.
Во-первых, аналитик на пресейле, конечно, полезен своей экспертизой.
Причём как предметные, так и системные.
Выезжая с продавцом на встречи и демонстрации, аналитик разговаривает со специалистами предметной области на одном языке и помогает продавцу ориентироваться в различных ситуациях, связанных с характерной профессиональной лексикой и терминологией.
Кроме того, обладая более глубоким знанием продаваемой системы и большим опытом проектирования, аналитик быстро и точно ориентируется в возможностях реализации пожеланий Заказчика, а также убедительно рассказывает о существующем опыте решения подобных задач.
После серии успешных встреч аналитик начинает работать изолированно от продавца и самостоятельно выезжает к Заказчику, выполняя экспресс-исследование процессов, существующих систем, требующих замены, инфраструктуры, которую необходимо будет встроить и т. д.
Результатом всех этих мероприятий являются намеченные контуры будущего проекта, а также предварительное техническое задание, по которому можно будет сделать первичную оценку сроков, трудоемкости и стоимости работ.
Предпроект
После завершения продажи и начала организационных мероприятий по подписанию договора и ритуальных танцев по инициированию проекта аналитик может уже не сидеть без дела, а приступить к предварительной работе.На этом этапе в его распоряжении уже может быть много информации для исследования: это и результаты экспресс-анализа, и заметки с встреч, и итоговое техническое задание, на которое подписывалась команда, и, если повезет, множество различных стандартов и правил Заказчика, требования которых необходимо будет учитывать при дальнейшем проектировании.
Другими словами, в вашей голове формируется гора неструктурированных данных, которые необходимо обработать, и концепция будущего решения.
Чаще всего эта миссия характерна для масштабных проектов с большой командой.
Именно в них аналитик становится техническим руководителем и решает, что, образно говоря, мы построим на этом проекте — пароход или самолет. Он также координирует команду на протяжении всего проекта, помогая выбрать оптимальные технические и предметные решения, а также обеспечивая целостность проектируемой системы.
Постепенно погружаясь в контекст будущего проекта, аналитик рисует его структуру и определяет, на какие условно обособленные компоненты его можно разделить.
После чего вместе с руководителем проекта распределяет команду по выделенным блокам.
Здесь очень важно учитывать взаимосвязи модулей будущей системы и понимать, какой именно объём работы можно безболезненно выделить в самостоятельный блок.
Изучив всю имеющуюся на данный момент информацию, аналитик строит концепцию автоматизации, где крупными мазками обрисовывает скелет будущей системы.
Именно эти решения лягут в основу всей дальнейшей работы и зададут направление аналитикам, решающим свои локальные проблемы на независимых блоках.
Также помимо концепции уже могут появиться первые технологические схемы, пока еще на верхнем уровне.
Чаще всего это в некотором роде побочный эффект погружения аналитика в проект – результат анализа имеющейся информации.
Но в будущем аналитики по блокам также смогут использовать эти схемы при выезде к Заказчику для детального изучения.
Кроме того, концепция тесно связана с архитектурой решения – здесь аналитик взаимодействует с ведущим разработчиком, интегрируя будущую систему в существующий ландшафт Заказчика и определяя объем необходимых интеграций и миграций, как начальных, так и регулярных.
При этом аналитик не только готовит себя к предстоящему проекту, но и одновременно готовит к нему рабочую группу Заказчика – тех людей, которые в дальнейшем станут основными источниками требований к будущей системе.
Аналитик проводит встречи с рабочей группой и демонстрирует коробочную версию системы, уделяя особое внимание тем модулям и функциям, которые затронет предстоящее внедрение.
Основная задача здесь — погрузить Заказчика в контекст системы, чтобы снизить барьер и добиться более осознанного отношения к формированию требований.
На демонстрациях аналитик показывает «вживую», как пункты технического задания вписываются или впишутся в существующую систему.
Именно здесь происходят самые первые связи между пунктами технического задания и реальными потребностями Заказчика.
Проект
Основная работа, конечно, начинается непосредственно над проектом.Именно на этом этапе происходит постоянная смена ролей.
Во-первых, аналитик тесно сотрудничает с Заказчиком в роли бизнес-аналитика.
При этом он может как изредка выезжать на встречи и собеседования, так и вообще находиться на территории Заказчика постоянно.
На этом этапе проводится углубленное исследование процессов компании, выявляются узкие места и потребности в автоматизации, предоставляются консультации по возможным решениям выявленных проблем.
Причем эти решения могут быть не только системными, но и административно-организационными.
По результатам исследования рождаются подробные схемы и описания бизнес-процессов «как есть» и «как будет», со всеми тонкостями и возможными сценариями развития событий.
Попутно выявляются и собираются требования к объектам будущей системы.
При сборе информации бизнес-аналитик трансформируется в системного аналитика, подгоняя требования Заказчика под возможности конкретной системы.
На этом этапе осуществляется проектирование модулей системы, при этом опытный аналитик самостоятельно оценивает возможности реализации того или иного требования и ищет пути обхода возможных ограничений платформы.
Однако недостаток опыта всегда можно компенсировать консультациями с ведущим разработчиком проекта.
На этом же этапе аналитик становится дизайнером, проектирующим и рисующим макеты будущих интерфейсов системы.
Здесь важно учитывать не только визуальную составляющую, но и основные постулаты UX, а также логику процессов, в которых будут участвовать проектируемые объекты.
Все экранные формы рано или поздно должны будут формировать одну логичную и гармоничную картину, а система должна будет одинаково реагировать на одинаковые действия пользователя.
Отдельный этап — проектирование всевозможных интеграций и миграций.
Здесь все зависит от опыта аналитика и его системных компетенций.
В целом, аналитик должен понимать место системы в общем ландшафте и хорошо понимать ее взаимодействие с другими системами Заказчика.
Это взаимодействие должно быть описано хотя бы на уровне подключения сущностей, правил передачи данных и отображения деталей.
Техническую часть проектирования обычно берет на себя разработчик.
После того, как все решения спроектированы, аналитик становится техническим писателем и пишет большой и красивый документ, в котором подробно описывается будущая система.
В данный документ включены ранее разработанные схемы и описания процессов и интерфейсов с подробным описанием применяемой логики элементов, а также другие описания изменений, которые необходимо выполнить в системе для реализации спроектированных решений.
Здесь аналитику может помочь выверенная структура документа и готовые шаблоны, позволяющие ничего не упустить.
После завершения этапа документации фундаментальная работа проходит как минимум две проверки – ведущим аналитиком и ведущим разработчиком команды.
И, если возможно, также внешняя проверка коллег из других команд и проектов.
После рассмотрения документ отправляется Заказчику на согласование.
Причем, на него не наваливают непонятный многостраничный Талмуд, а сначала демонстрируют в виде презентации с пояснениями, песнями, танцами и веселыми картинками.
Далее аналитик сопровождает процесс согласования, отвечая на вопросы Заказчика, корректируя те или иные формулировки, а при необходимости дополнительно уточняя требования и решения.
После успешного утверждения документ отправляется на разработку.
В этот момент наш аналитик берет небольшой перерыв.
По мере разработки он, конечно, включается в работу над проектом, но с заметно меньшей нагрузкой.
Его задачи в основном — отвечать на вопросы разработчиков и периодически уточнять требования у Заказчика.
Когда разработка завершена, аналитик становится тестировщиком и приступает к длительному, вдумчивому и скрупулезному тестированию разработанных решений.
Сразу отмечу, что речь идет о пользовательском тестировании, но это не значит, что оно поверхностное.
Проверяется каждая кнопка, каждое окно, каждая ветка маршрута, строятся все формы отчетности, запускаются все скрипты.
В этом случае тестирование делится на два больших этапа.
Первый этап касается проверки основных функций.
Здесь все должно работать так, как написано в документации, и так, как если бы за компьютером сидел опытный и знающий пользователь.
После того как все положительные варианты использования проверены, аналитик начинает «ломать» систему и тестировать ее с позиции неопытного пользователя, которому лень даже читать инструкции.
Отдельно хотелось бы обратить внимание на то, что на этом этапе могут быть уточнены требования и доработаны решения.
Когда тестирование наконец завершено, мы готовы к следующей миссии.
Выполнение
На этом этапе аналитик участвует в развертывании и настройке системы на серверах Заказчика.Изначально создается тестовая схема, на которой рабочая группа совместно с командой проекта проведет финальное тестирование решения.
Чтобы обеспечить это тестирование, аналитик пишет тест-кейсы, продумывая, какие сценарии нужно будет пройти Заказчику, чтобы охватить максимальное количество функций за ограниченный период тестирования и убедить рабочую группу, что все работает как надо.
Конечно, этап тестирования снова приводит к циклу уточнения требований, доработок системы и повторных испытаний, но неисчерпаемые пожелания Заказчика должны быть существенно ограничены во времени и трудоемкости, стараясь учесть только самые критические моменты.
Основная задача — быстро войти в эксплуатацию для живых пользователей, как бы негуманно это ни звучало.
На этом этапе аналитик превращается в тренера-преподавателя, обучающего рядовых пользователей будущей системы.
Обучение может осуществляться различными способами: очные курсы с практическими заданиями и итоговой аттестацией, семинары, вебинары, видеоролики, скринкасты и т. д. При этом пишутся инструкции для пользователей (хотя в целом их разработка начинается на этапе внутреннего тестирования).
Наконец, когда все испытания и обучение завершены, система запускается в опытную эксплуатацию, а аналитик становится опорой, обеспечивающей постоянные консультации и поддержку пользователей Заказчика.
Как и обучение, поддержка тоже может быть самой разной – от живого бега по этажам до дежурства на горячей линии.
В процессе работы от пользователей начинают поступать запросы, которые позволяют аналитику вспомнить, что он еще аналитик, и вновь погрузиться в работу с требованиями, управление запросами на изменения и последующими дополнительными модификациями.
Конечно, как вы понимаете, эти модификации тоже потом будут нуждаться в тестировании, развертывании и далее по кругу.
Рано или поздно проект завершается, передается в специализированные службы на поддержку, и наш аналитик получает заветный носок.
Бонусный уровень
Помимо внешних проектных задач, у аналитика достаточно много внутренних задач, в которых он также может развиваться и реализовываться.Прежде всего, это наставничество.
Каждый новый сотрудник компании обязательно получает персонального наставника на первые 3-4 месяца работы.
Наставник составляет план личного развития, помогает новичку адаптироваться, изучать продукцию и технологии, узнавать все о внутренней кухне и в целом становится практически мамой.
Также, если аналитик успешно завершил несколько проектов и набрался опыта, он может выступать рецензентом решений своих коллег по другим проектам.
Более того, его можно включить непосредственно в команду релиза основного продукта, как технического или профильного эксперта.
Следующий шаг – развитие внутренних технологий компании.
Этот этап требует солидного опыта и неистребимого желания сделать мир лучше.
Часто – несмотря.
По умолчанию поощряется трансляция незаменимого опыта в массы любыми способами – публикации на внутренних и внешних платформах, доклады и вебинары, внутреннее обучение для менее опытных сотрудников и т.д. Со временем, при желании, наш шива-аналитик может взять на себя руководство группой или отделом, стать внешним общественным экспертом компании и даже оказывать выездные консультационные услуги сторонним компаниям, партнерам или потенциальным Заказчикам.
Эпик-фейл
Ну не может все быть так радужно, скажите вы мне.И вы будете правы.
Рано или поздно наш аналитик столкнется с самой большой ловушкой под названием сверхквалификация.
В этот момент аналитик оказывается в довольно сложном положении.
Внутри компании достигнуты все возможные вершины, реализованы крупнейшие проекты и практически не осталось ничего, что могло бы удивить или заинтересовать.
Задачи, которые кажутся сложными для других, для такого аналитика становятся рутинными.
Более того, специалисту такого уровня становится довольно сложно реализовать себя где-то еще.
Для подобных компаний, которым можно продать экспертизу, это востребовано, но очень дорого.
Эти затраты придется компенсировать проектами, которые еще предстоит приобрести.
И давайте будем честными — компания предпочла бы взять менее дорогого сотрудника и вырастить его самостоятельно, постепенно интегрируя его в команду и добиваясь лояльности.
Но для компаний другого профиля вся эта гигантская экспертиза совершенно неактуальна.
Но сокращать карьеру и финансы специалиста почти вдвое неинтересно ни компании, ни самому специалисту.
Однако я уверен, что выход из этого лабиринта есть и наш аналитик его обязательно найдет. И если присутствующие готовы поделиться своим опытом жизни в таких ситуациях, давайте пообщаемся в комментариях! Теги: #Анализ и проектирование систем #аналитик #проектированиесистем #разработка #системный анализ #бизнес-анализ #внедрение ИС
-
Выпуск Freebsd 8.1 Доступен
19 Oct, 24 -
Совместное Использование Веб-Альбомов Picasa
19 Oct, 24 -
Тысячи Видеокарт Ati Radeon Содержат Дефект
19 Oct, 24
