Обзор профессий бизнес-аналитика и системного аналитика
В комментариях к этому посту меня спросили про профессии бизнес- и системного аналитика. Я проработала в этой сфере 8 лет, больше все-таки системным аналитиком, нежели бизнес, и, честно, очень люблю эту работу. Нет ничего приятнее, когда твоими руками хаос, царивший в компании, потихоньку преображается в некое подобие порядка. Оговорюсь, что все, написанное ниже, является исключительно моими субъективными выкладками - если кто-то может что-то добавить или опровергнуть, я буду только рада.
Оговорюсь еще раз: под «аналитиком» я понимаю тут сразу две профессии: бизнес-аналитик и системный аналитик. В чем различие между ними, я объясню немного ниже.
Итак: кто такой аналитик? Ответ на этот вопрос я придумала, когда меня начали спрашивать о том, чем я занимаюсь, люди, далекие от этой области. Им я отвечала: «я говорю программистам, что им делать, а потом говорю пользователям, как им с этим жить». Так что если вы когда-нибудь объясняли программисту, что его программа неправильно посчитала сумму («нужно это и это сложить, потом умножить на курс, потом округлить - а у вас тут в другом порядке и сумма получается больше на копейку») или рассказывали новичку о работе в вашем отделе («делаешь счет-фактуру, Люда выдает ей номер, потом подписываешь у Ивана Ивановича и отдаешь кладовщику; если Иван Иванович сказал переделать, то новый номер брать не нужно») - то, поздравляю вас, вы уже работали аналитиком.
Системные аналитики как правило больше занимаются разработкой и внедрением программ, то есть их работа похожа на первую часть примера. Бизнес-аналитики больше занимаются бизнес-процессами: это такая штука, которая описывает, кто, как и в какой последовательности что делает («менеджер формирует счет-фактуру, ответственный менеджер присваивает ей номер, директор подписывает, и т.п.») - т.е. в чистом виде вторая часть примера. На мой субъективный взгляд, разница между этими двумя профессиями условна: если ты внедряешь программу, то тебе нужно знать, как и кто с ней работает; а если ты занят бизнес-процессами, то, скорее всего, одним или несколькими действующими лицами бизнес-процесса станут программы (счет-фактура формируется в Экселе, кладовщик выписывает товары по счет-фактуре в 1С и пр.). Но, тем не менее, я больше была системным аналитиком, больше знаю про особенности именно этой профессии и написанной в большей степени относится к этой профессии.
Как выглядит работа аналитика? В общем случае так: пользователи решают, что им нужна какая-то программа; аналитик выясняет, что конкретно им нужно сделать, «переводит» эти требования на язык, понятный программистам, те разрабатывают программу, аналитик помогает пользователям начать с ней работать (внедряет программу), все счастливы. Бывает, что нужно сделать только одну часть работы - только составить требования к новому программному продукту; только обучить пользователей; только написать документацию - но общий процесс «жизни» программы именно таков.
Часто пользователи не знают, что именно им нужно или даже не подозревают об этом, и тогда аналитик проводит обследование - выясняет реальное положение вещей в компании (как правило, результат обследования оказывается для людей, в ней работающих, большим сюрпризом). Такое обследование можно проводить с целью внедрить какую-то программу (или, например, выбрать программу для внедрения) - или с целью улучшить бизнес-процессы компании, и про эту работу я знаю совсем мало.
Работа аналитика, на мой взгляд, это ежедневный поиск компромисса. Компромисс нужен при разработке программы: можно сделать программу, которая будет делать абсолютно все, но ее будут делать очень долго (а за это время то, что нужно компании, успеет сто раз поменяться) - а если сделать программу, которая делает мало, то люди будут недовольны. Компромисс нужен при работе с людьми: пользователи не хотят работать с новой программой, т.к. привыкли к старой, их начальник требует, чтобы все уже было готово, тестеры через неделю уходят на другой проект и их нужно загружать работой сейчас, сисадмины выключают сервер для проведения своих профилактических работ ровно тогда, когда он нужен вам, и т.п. При идеальном положении вещей все эти заботы должны лечь на плечи менеджера проектов, но очень часто получается так, что их целиком или частично берет на себя аналитик.
Какова специфика рынка работы аналитиков?
В очень многих компаниях, особенно крупных, особенно иностранных, аналитики по умолчанию работают ненормированный рабочий день - с овертаймами, причем зачастую неоплачиваемыми. Увы, это грустная традиция, пришедшая к нам с Запада - если вам удается этого избежать, то вы счастливчик.
Очень большая текучка кадров - то есть вакансии есть почти всегда. Не знаю только, как обстоит дело с позициями для людей без опыта в этой сфере. В крупных компаниях, вроде больших 1С-франчайзи (БиТ и пр.), системных интергаторах типа Люксофта, такие позиции должны быть почти всегда, не знаю только, берут ли на них не студентов.
Большая разница существует между работой в компании, услуги которой покупают другие компании, и работой на внутренних проектах, т.е. в IT-подразделении компании, когда ты внедряешь что-то в соседнем отделе. В первом случае я постоянно чувствовала себя между молотом и наковальней: ты хочешь сделать для клиента все хорошо, а твой начальник торопит тебя, т.к. уже хочет занять тебя в новом проекте. При работе внутри компании, с другой стороны, тебя больше касаются внутренние интриги: начальник этого отдела хочет внедрять программу, начальник соседнего отдела этого совсем не хочет, вышестоящий начальник ни в чем не разбирается, и т.п.
Что нужно знать и уметь аналитику?
Аккуратность и дотошность: документировать свои действия, своевременно делать бэкапы, вычитывать большое количество документации. Умение писать документацию: ничего не забыть, писать на понятном пользователю - или программисту, языке.
Знание предметной области, в которой идет внедрение. Это знание, конечно, приходит с опытом, но когда, исходя из своего опыта, ты можешь подсказать пользователю, чего он хочет (а это, как правило, пользователю очень сложно сформулировать), знаешь, что он, вероятно, будет делать, понимаешь, какие ошибки он будет совершать в работе (а если пользователь может сделать ошибку, он ее гарантированно сделает), можешь аргументировано с ним спорить о том, как и что должно работать - это очень помогает.
Знание программ, внедрение которых идет на проекте. Это не значит, что вы должны уметь программировать: я последний раз писала программу еще в студенчестве. Но вам нужны знания программирования, которые помогут вам говорить с программистами на их языке, может дадут возможность ткнуть им пальцем в ошибку в коде (не всегда возможно, код часто бывает закрыт от аналитиков), смогут дать вам возможность составить запрос к базе, чтобы проанализировать данные (язык запросов, sql, очень полезное знание, на самом элементарном уровне).
Что касается специализированных программ для аналитика, то, по моему мнению, это лишнее. Само собой, программу, которую ты внедряешь, нужно знать лучше разработчика. Остальное же, что пишут в требованиях к соискателям, опционально: Word, Excel, Visio для диаграмм и процессов - универсальные инструменты. Некоторые требуют знание UML/Rational Rose: это нотация для записи бизнес-процессов и программа для рисования этой нотацией соответственно: ненавижу, ненаглядна и дурацка; все, что записывается ею, можно записать в Visio простыми квадратиками. Но некоторые считают знание этой системы большим плюсом. BpWin и ErWin - также специальные программы для нотирования бизнес-процессов: на собеседованиях всегда говорила, что знакома с ними и всегда все рисовала в Visio - но это, конечно, мои личные предпочтения. Бывает нужно знание систем управления версиями: ты взял документ, поменял его, записал обратно в хранилище, которое хранит все версии документов в нем, потом другой человек взял документ, снова внес изменения и записал в хранилище. Принцип работы у всех один и тот же - знаешь одну систему, знаешь все. Для людей, часто сталкивающихся с тестированием программ, бывают нужны системы баг-треккинга: запись и учет найденных ошибок.
Как становятся аналитиками?
Кто-то, как я, приходит после института. Любое заведение, в котором учат мыслить системно, годится: по моему мнению, учить на аналитиков ни в одном институте не учат: практический опыт не заменит никаких лекций. Кто-то приходит из предметной области: бухгалтер, хорошо знающий 1С, вполне может начать ее внедрять. Кто-то приходит из смежных профессий: технический писатель, тестировщик, сотрудник технической поддержки, хорошо знающие свою область, вполне могут стать аналитиками.
Увы, я не могу себе представить никаких курсов и программ обучения, после которых можно стать аналитиком. Если вы хотите, например, внедрять 1С, то вам нужно изучить эту программу; если хотите подвизаться в банковской сфере, то вам нужно знать учет в банке - но это все, по моему мнению, капля в море по сравнению с реальным опытом, который можно получить только в поле.
Как успеть все с детьми, будучи аналитиком?
Я буду рада, если кто-то меня опровергнет, но, по моему убеждению, это почти невозможно. На всех проектах, на которых я была аналитиком, а) было много овертаймов б) была невозможна удаленная работа. Это, само собой, не всегда так: если вы можете выстроить приоритеты так, чтобы быть дома вовремя, то, вполне возможно, у вас это получится. Проекты, которые ты можешь делать дома, у меня тоже были - почти 2 месяца я писала техническое задание на разработку, и в течение этого времени могла бы не появляться в офисе. Но в моей работе это было скорее исключением, нежели правилом.
Оговорюсь еще раз: под «аналитиком» я понимаю тут сразу две профессии: бизнес-аналитик и системный аналитик. В чем различие между ними, я объясню немного ниже.
Итак: кто такой аналитик? Ответ на этот вопрос я придумала, когда меня начали спрашивать о том, чем я занимаюсь, люди, далекие от этой области. Им я отвечала: «я говорю программистам, что им делать, а потом говорю пользователям, как им с этим жить». Так что если вы когда-нибудь объясняли программисту, что его программа неправильно посчитала сумму («нужно это и это сложить, потом умножить на курс, потом округлить - а у вас тут в другом порядке и сумма получается больше на копейку») или рассказывали новичку о работе в вашем отделе («делаешь счет-фактуру, Люда выдает ей номер, потом подписываешь у Ивана Ивановича и отдаешь кладовщику; если Иван Иванович сказал переделать, то новый номер брать не нужно») - то, поздравляю вас, вы уже работали аналитиком.
Системные аналитики как правило больше занимаются разработкой и внедрением программ, то есть их работа похожа на первую часть примера. Бизнес-аналитики больше занимаются бизнес-процессами: это такая штука, которая описывает, кто, как и в какой последовательности что делает («менеджер формирует счет-фактуру, ответственный менеджер присваивает ей номер, директор подписывает, и т.п.») - т.е. в чистом виде вторая часть примера. На мой субъективный взгляд, разница между этими двумя профессиями условна: если ты внедряешь программу, то тебе нужно знать, как и кто с ней работает; а если ты занят бизнес-процессами, то, скорее всего, одним или несколькими действующими лицами бизнес-процесса станут программы (счет-фактура формируется в Экселе, кладовщик выписывает товары по счет-фактуре в 1С и пр.). Но, тем не менее, я больше была системным аналитиком, больше знаю про особенности именно этой профессии и написанной в большей степени относится к этой профессии.
Как выглядит работа аналитика? В общем случае так: пользователи решают, что им нужна какая-то программа; аналитик выясняет, что конкретно им нужно сделать, «переводит» эти требования на язык, понятный программистам, те разрабатывают программу, аналитик помогает пользователям начать с ней работать (внедряет программу), все счастливы. Бывает, что нужно сделать только одну часть работы - только составить требования к новому программному продукту; только обучить пользователей; только написать документацию - но общий процесс «жизни» программы именно таков.
Часто пользователи не знают, что именно им нужно или даже не подозревают об этом, и тогда аналитик проводит обследование - выясняет реальное положение вещей в компании (как правило, результат обследования оказывается для людей, в ней работающих, большим сюрпризом). Такое обследование можно проводить с целью внедрить какую-то программу (или, например, выбрать программу для внедрения) - или с целью улучшить бизнес-процессы компании, и про эту работу я знаю совсем мало.
Работа аналитика, на мой взгляд, это ежедневный поиск компромисса. Компромисс нужен при разработке программы: можно сделать программу, которая будет делать абсолютно все, но ее будут делать очень долго (а за это время то, что нужно компании, успеет сто раз поменяться) - а если сделать программу, которая делает мало, то люди будут недовольны. Компромисс нужен при работе с людьми: пользователи не хотят работать с новой программой, т.к. привыкли к старой, их начальник требует, чтобы все уже было готово, тестеры через неделю уходят на другой проект и их нужно загружать работой сейчас, сисадмины выключают сервер для проведения своих профилактических работ ровно тогда, когда он нужен вам, и т.п. При идеальном положении вещей все эти заботы должны лечь на плечи менеджера проектов, но очень часто получается так, что их целиком или частично берет на себя аналитик.
Какова специфика рынка работы аналитиков?
В очень многих компаниях, особенно крупных, особенно иностранных, аналитики по умолчанию работают ненормированный рабочий день - с овертаймами, причем зачастую неоплачиваемыми. Увы, это грустная традиция, пришедшая к нам с Запада - если вам удается этого избежать, то вы счастливчик.
Очень большая текучка кадров - то есть вакансии есть почти всегда. Не знаю только, как обстоит дело с позициями для людей без опыта в этой сфере. В крупных компаниях, вроде больших 1С-франчайзи (БиТ и пр.), системных интергаторах типа Люксофта, такие позиции должны быть почти всегда, не знаю только, берут ли на них не студентов.
Большая разница существует между работой в компании, услуги которой покупают другие компании, и работой на внутренних проектах, т.е. в IT-подразделении компании, когда ты внедряешь что-то в соседнем отделе. В первом случае я постоянно чувствовала себя между молотом и наковальней: ты хочешь сделать для клиента все хорошо, а твой начальник торопит тебя, т.к. уже хочет занять тебя в новом проекте. При работе внутри компании, с другой стороны, тебя больше касаются внутренние интриги: начальник этого отдела хочет внедрять программу, начальник соседнего отдела этого совсем не хочет, вышестоящий начальник ни в чем не разбирается, и т.п.
Что нужно знать и уметь аналитику?
Аккуратность и дотошность: документировать свои действия, своевременно делать бэкапы, вычитывать большое количество документации. Умение писать документацию: ничего не забыть, писать на понятном пользователю - или программисту, языке.
Знание предметной области, в которой идет внедрение. Это знание, конечно, приходит с опытом, но когда, исходя из своего опыта, ты можешь подсказать пользователю, чего он хочет (а это, как правило, пользователю очень сложно сформулировать), знаешь, что он, вероятно, будет делать, понимаешь, какие ошибки он будет совершать в работе (а если пользователь может сделать ошибку, он ее гарантированно сделает), можешь аргументировано с ним спорить о том, как и что должно работать - это очень помогает.
Знание программ, внедрение которых идет на проекте. Это не значит, что вы должны уметь программировать: я последний раз писала программу еще в студенчестве. Но вам нужны знания программирования, которые помогут вам говорить с программистами на их языке, может дадут возможность ткнуть им пальцем в ошибку в коде (не всегда возможно, код часто бывает закрыт от аналитиков), смогут дать вам возможность составить запрос к базе, чтобы проанализировать данные (язык запросов, sql, очень полезное знание, на самом элементарном уровне).
Что касается специализированных программ для аналитика, то, по моему мнению, это лишнее. Само собой, программу, которую ты внедряешь, нужно знать лучше разработчика. Остальное же, что пишут в требованиях к соискателям, опционально: Word, Excel, Visio для диаграмм и процессов - универсальные инструменты. Некоторые требуют знание UML/Rational Rose: это нотация для записи бизнес-процессов и программа для рисования этой нотацией соответственно: ненавижу, ненаглядна и дурацка; все, что записывается ею, можно записать в Visio простыми квадратиками. Но некоторые считают знание этой системы большим плюсом. BpWin и ErWin - также специальные программы для нотирования бизнес-процессов: на собеседованиях всегда говорила, что знакома с ними и всегда все рисовала в Visio - но это, конечно, мои личные предпочтения. Бывает нужно знание систем управления версиями: ты взял документ, поменял его, записал обратно в хранилище, которое хранит все версии документов в нем, потом другой человек взял документ, снова внес изменения и записал в хранилище. Принцип работы у всех один и тот же - знаешь одну систему, знаешь все. Для людей, часто сталкивающихся с тестированием программ, бывают нужны системы баг-треккинга: запись и учет найденных ошибок.
Как становятся аналитиками?
Кто-то, как я, приходит после института. Любое заведение, в котором учат мыслить системно, годится: по моему мнению, учить на аналитиков ни в одном институте не учат: практический опыт не заменит никаких лекций. Кто-то приходит из предметной области: бухгалтер, хорошо знающий 1С, вполне может начать ее внедрять. Кто-то приходит из смежных профессий: технический писатель, тестировщик, сотрудник технической поддержки, хорошо знающие свою область, вполне могут стать аналитиками.
Увы, я не могу себе представить никаких курсов и программ обучения, после которых можно стать аналитиком. Если вы хотите, например, внедрять 1С, то вам нужно изучить эту программу; если хотите подвизаться в банковской сфере, то вам нужно знать учет в банке - но это все, по моему мнению, капля в море по сравнению с реальным опытом, который можно получить только в поле.
Как успеть все с детьми, будучи аналитиком?
Я буду рада, если кто-то меня опровергнет, но, по моему убеждению, это почти невозможно. На всех проектах, на которых я была аналитиком, а) было много овертаймов б) была невозможна удаленная работа. Это, само собой, не всегда так: если вы можете выстроить приоритеты так, чтобы быть дома вовремя, то, вполне возможно, у вас это получится. Проекты, которые ты можешь делать дома, у меня тоже были - почти 2 месяца я писала техническое задание на разработку, и в течение этого времени могла бы не появляться в офисе. Но в моей работе это было скорее исключением, нежели правилом.