Типы аналитиков
Большинство проектных команд, работающих в разработке или внедрении ПО, включают аналитика.
Однако, задачи в них аналитик имеет разные. Для других членов проектной команды, наименование роли явно указывает на результат работы: менеджер обеспечивает управляемость проекта (кстати, иногда управление проектом и членами проектной команды - разные функции), разработчик поставляет код, тестировщик обеспечивает тестирование.
Для каждой из ролей можно сразу указать желаемый результат. Аналитик, очевидно, анализирует. А что должно получиться в итоге? Ну, хороший продукт. А в чем конкретно вклад аналитика? Вот тут ответы бывают разные.
Ниже я опишу несколько типов аналитиков, с которыми мне доводилось сталкиваться в работе, а потом дам свое видение функций аналитика.
Подчеркну, что каждый из приведенных типов может найти место в проекте, в зависимости от его организации. Каждый может приносить пользу, и обеспечить успех проекта.
Нужно лишь, чтобы видение аналитика на его задачи и видение менеджера совпадали.
В конце я напишу немного о своем видении аналитики.
1. Недоменеджер
Часто встречается в проектах с подрядчиками. У подрядчика есть свои аналитики, которые более тесно сотрудничают с разработчиками (а часто даже один человек совмещает функции разрабтчика или менеджера и аналитика).
Поэтому, если у менеджера есть свободный ресурс в виде аналитика, у него велик соблазн отстранить его от работы с требованиями, и, собственно, анализа, но возложить на него функции управления и контроля аналитиков внешних команд.
Распределение ресурсов, контроль исполнения, элементы мотивации. Врядли менеджер полностью отдаст какие-либо свои обязанности аналитику, даже если последний желает "вырасти" в менеджера.
В результате, аналитик отдаляется от потребностей бизнеса и возможностей разработки, превращаясь в секретаря при менеджере. Потенциально, это ведет к следующим проблемам:
- Конфликт интересов в трактовке требований бизнеса, остается без контроля со стороны заказчика/генподрядчика. Часто это выясняется в момент поставки продукта на пром (или даже после подписания актов о приемке).
Почему требования реализованы как удобнее подрядчику, а не как надо заказчику? Потому что так решили аналитики подрядчика. Где был аналитик заказчика? Обеспечивал реализацию требований полностью и в срок, не заботясь об их, собственно, анализе.
- Профессиональная деградация аналитика. Маловероятен его рост в сторону управления. Зато, из него может получиться классный секретарь. Труд секретаря также почетен, и может хорошо оплачиваться. Но немногие из технических специалистов всерьез мечтают о такой карьере.
Недоменеджеру следует либо требовать работы аналитика, либо уж профессионально расти, как менеджеру (не забывая, что работу аналитика кто-то, все же, должен делать).
2. Технарь
Его еще иногда называют "системный аналитик". Он редко работает с требованиями бизнеса и предметной областью внедрения (чаще не работает никогда). Но он хорошо разбирается в информационной инфраструктуре. Такой аналитик очень ценен для проектов с разветвленной инфраструктурой, в которых сталкивается много разных информационных систем и ландшафтов.
У менеджера часто появляется соблазн удалить технаря из проектного офиса, посадив его с кодировщиками или администраторами, поскольку с ними он лучше находит общий язык и добивается больших результатов.
Такие действия вызывают профессиональную "слепоту": аналитик полностью погружается в хитросплетения кода и проводов и не задумывается, зачем они нужны (то есть, за что платят деньги проектной команде в целом, и ему в частности).
Возможна та же ситуация, что и в пункте 1, когда заказчик осознает, что получил не то, чего хотел, в последний момент.
Технари (не только аналитики) - ненормальные. В том смысле, что их образ жизни и поведение почти всегда отличаются от таковых у "обычного" человека. Если технарь может умело маскировать свою ненормальность, а лучше - осознавать, чем и почему он отличается от других, из него может получиться прекрасный аналитик. Но, это потребует дополнительных усилий от менеджера, на которые он редко бывает готов.
Технарю стоит расширять свой кругозор и оглядываться по сторонам. Для интроверта это может быть непросто, но это единственный путь в аналитики.
3. Козел отпущения
Посмотрим на проект: программисты программируют в поте лица. Вот Jira: много тикетов, но все оперативно закрываются. От релиза к релизу, растет список внедренных фич. Вот Git: змеятся бранчи, стабильнее от релиза к релизу. Результат на лицо.
Вот менеджер бюджет проекта защищен, в MS Project дерево работ, к каждой указаны ресурсы. Все учтено: стимул персонала, обучение, отпуска. Команда работает как часы. Заказчик общается с менеджером каждый четверг, получает подробный отчет и очень доволен. Релиз поставлен в срок.
Только вот почему проект провален? Почему, не смотря на список фич и поставленный релиз, заказчик не подписывает акты? Отчего он сменил радость от резвого хода проекта злобой, когда он подошел к концу?
А что сделал аналитик? Даже документы писал прилежный (и с более низкой зарплатой) технический писатель. Требования, спецификации, архитектура? Да мы все равно в релиз отправили другое!
Вот и нашли виновного. В лучшем случае, без премии оставят, в худшем - показательно уволят. Нечего проекты гробить!
На самом деле, довольно редко нанимают аналитика, чтобы повесить на него провал проекта (чаще такое бывает с менеджерами). Но, бывает. Чаще, аналитик становится виновным в процессе проекта. Я наблюдал такое у талантливых, но не опытных менеджеров.
Когда менеджер боится упустить что-то из своего видения, он начинает оттеснять других от любых важных вопросов проекта, первыми оттесняются аналитик и тимлид разработки. Вы не лезьте в мою работу, я не лезу в вашу. А к заказчику я вас не пущу, только напортите.
Для простых проектов, этот подход часто срабатывает. Но в простом проекте и роль менеджера и аналитика вполне могут ужиться в одном человеке. Если же есть выделенный аналитик, ему остается либо смириться с одной из прочих 5, описанных мною ипостасей, либо вести свою работу "партизанскими" методами.
В случае успеха проекта, об аналитике никто не вспомнит, но в случае провала, вспомнят обязательно.
Козлу отпущения не стоит покорно брести на убой. Работу свою делать добросовестно. Если вас перестали приглашать на встречи и поручать срочную работу - это не передышка, а дурной знак. Надо требовать работу самому.
4. Эникейщик
Аналитик обычно обладает широким кругозором. Может код написать, посчитать сложность алгоритма по О-большое, спаять радиоприемник, поднять сервер LAMP, обжать витую пару... А может и написать экономическое обоснование, заявку на кункурс, вести календарно-сетевой график, чертить UML-диаграммы. Поэтому, велик бывает соблазн привлекать его именно к этим работам: мелочам, не требующим высокой квалификации.
По природе своей работы, аналитику следует быть в курсе всех аспектов проекта. Но, превращаться в обслугу тоже не стоит, платят аналитику не за это. С другой стороны, нельзя и отвергать с негодованием мелкие поручения, со ссылкой на собственную крутость и оклад.
В общем случае, задачи на проекте распределяет менеджер, он и отслеживает загрузку персонала. Опытный аналитик сам организует свою работу для максимальной отдачи. Опытный менеджер сможет это сделать для не опытного аналитика. А вот если на проекте встретились специалисты без большого опыта в этих ролях, могут получиться проблемы.
Эникейщику можно посоветовать, в первую очередь, решать на работе задачи, связанные с аналитикой проекта. Потом - все прочие. А не наоборот!
5. Технический писатель
Когда заходит речь о продукте работы аналитика, обычно сразу вспоминают документацию. Документации на проекте нужно много: требования, технические задания, руководства. Есть весьма устаревшая группа стандартов ЕСПД (Единая Система Программной Документации, ГОСТ 19), на сегодняшний день она, сама по себе, мало применима, но представление о масштабах бедствия дает.
Писать документы неприятно (лично мне, но я не встречал еще никого, кому это доставляло бы удовольствие). Это отнимает много сил. Каждая строчка должна быть четко выверена. Когда документ надо согласовать, его никто не читает, а когда ты считаешь, что все с ним согласились (и подписали), начинают сыпаться замечания.
Наибольшие плоды приносит "гибкое" согласование документов (по аналогии с AGILE-методиками, много маленьких итераций). Но это отнимает много сил, итераций могут быть десятки (лично у меня до сотен дело не доходило). Нужно постоянно переписывать документ, учитывая сотни замечаний. И все ради пары десятков страниц.
Труд технического писателя часто бывает недооценен. Классных технических писателей единицы, и на сложном проекте хороший техпис заслуживает не меньшего оклада, чем руководитель проекта. Жалко, что мало кто это осознает.
Конечно, документы приходится писать всем: и руководителям, и аналитикам, и тестировщикам, и даже программистам (последние при этом, обычно, страшно матерятся). Но все же, технический писатель - отдельная проектная роль, со своими инструментами, стандартами и квалификацией.
На небольшом проекте один человек может совмещать роли писателя и аналитика. Но это не значит, что основная задача аналитика писать и только писать!
Если вы являетесь аналитиком, но выполняете работу технического писателя, задумайтесь, какие аналитические задачи решает каждый из создаваемых вами документов. В разговоре с менеджером, говорите об этих задачах, а не документах. Решение аналитических задач должно иметь приоритет над созданием вспомогательной документации (например, руководств пользователя). Но и отказываться без повода от такой работы не нужно (см. п. 4).
6. Витринный аналитик
Популярный персонаж в консалтинговых компаниях. В стандартную комплектацию проектной команды входит аналитик? Нет вопросов! Берется студент-старшекурсник, одевается в костюм. В одну руку ему дается томик Вигерса, в другую - корпоративный гайдлайн по сбору требований. Все.
Днем молодой аналитик едет к заказчику, и собирает все по чеклисту: юз-кейсы - есть, эскизы экранных форм - есть, блок-схема переходов - есть. Все. Бумажки отвозятся тимлиду и выбрасываются из головы. Вечером - девушка, кафе, диплом.
А где аналитика? Вот же! Ворох бумаг.
Начавшие карьеру таким образом, редко остаются в аналитиках. Хлопотно, бесперспективно. Получив достаточный опыт, такие люди или уходят в узкую специализацию, используя корпоративные программы обучения, или строят карьеру менеджера.
А что же такое "настоящий аналитик" в моем понимании? Все вышеперечисленное, и немного еще. Да, на каком-то отдельном проекте может быть востребован аналитик одного из перечисленных выше подвидов. К тому же, идеально уметь все - выше человеческих сил. Но есть кое-что, что определяет все подвиды: анализ и его результаты, применительно к достижению успеха проекта.
Под анализом обычно понимают анализ требований. А в категорию "требования" можно загнать что угодно. Заказчик что-то хочет - это требования. В проектной команде кто-то заболел - возникли дополнительные требования. В сервере что-то сломалось - требуется починить. Опять требования! Не все требования должен удовлетворять аналитик, но он должен их учитывать, так или иначе.
Менеджер дает проекту импульс, разработчик - результат, а аналитик - смысл.
Кстати, выше я упомянул, в основном, технические компетенции проектного аналитика. Просто мне они ближе. На самом деле, аналитик может и не быть технарем, даже на ИТ-проекте.
Разделение аналитиков на бизнес и системных, я полагаю надуманным. Не понятно, кого понимать под системным аналитиком. Того, кто пользуется методом познания "системный анализ"? Так этот метод универсален, и применим любым человеком. Того, кто анализирует системы (или их связи)? Но в этом случае не уйти от бизнес-смысла.
Мне удалось найти только один документ (2007 года, и до сих пор находящийся в статусе проекта), регламентирующий деятельность именно системного аналитика. Вот он: http://www.apkit.ru/files/analitik.doc.
Документ любопытный. Хорошо подойдет для шаблона должностной инструкции, и может дать общее представление о работе аналитика. Но многие требования в нем спорны и не применимы во всех случаях. Исключений будет больше, чем правил.
А вот для бизнес-аналитиков хороший и универсальный документ есть, это BABOK - Business Analysis Body of Knowledge. Этот документ описывает цели, методы и подходы любого аналитика, не только в ИТ-проекте. И системного аналитика тоже. Как и других аналитиков, например, аналитика банковских продуктов.
Конечно, BABOK во многом завязан на более "раскрученный" PMBOK. Если вы используете не совместимые с ним практики проектного управления, вам он может не подойти.
Впрочем, о стандартах, имеющих отношение к анализу в ИТ-проектах, я напишу подробно в другой раз. А пока, напоследок, короткий дайджест.
Что должен уметь аналитик? - Все понемногу.
Что является основным предметом работы аналитика? - Требования.
Какими особыми техническими навыками должен владеть аналитик? - В общем случае, никакими.
Где почитать о работе аналитика? - BABOK.
Что является критерием успеха работы аналитика на проекте? - Концепция продукта, максимально полно учитывающая ограничения разработчиков и менеджмента с одной стороны, и потребности заказчика с другой (озвученные или скрытые, осознанные и нет).
Однако, задачи в них аналитик имеет разные. Для других членов проектной команды, наименование роли явно указывает на результат работы: менеджер обеспечивает управляемость проекта (кстати, иногда управление проектом и членами проектной команды - разные функции), разработчик поставляет код, тестировщик обеспечивает тестирование.
Для каждой из ролей можно сразу указать желаемый результат. Аналитик, очевидно, анализирует. А что должно получиться в итоге? Ну, хороший продукт. А в чем конкретно вклад аналитика? Вот тут ответы бывают разные.
Ниже я опишу несколько типов аналитиков, с которыми мне доводилось сталкиваться в работе, а потом дам свое видение функций аналитика.
Подчеркну, что каждый из приведенных типов может найти место в проекте, в зависимости от его организации. Каждый может приносить пользу, и обеспечить успех проекта.
Нужно лишь, чтобы видение аналитика на его задачи и видение менеджера совпадали.
В конце я напишу немного о своем видении аналитики.
1. Недоменеджер
Часто встречается в проектах с подрядчиками. У подрядчика есть свои аналитики, которые более тесно сотрудничают с разработчиками (а часто даже один человек совмещает функции разрабтчика или менеджера и аналитика).
Поэтому, если у менеджера есть свободный ресурс в виде аналитика, у него велик соблазн отстранить его от работы с требованиями, и, собственно, анализа, но возложить на него функции управления и контроля аналитиков внешних команд.
Распределение ресурсов, контроль исполнения, элементы мотивации. Врядли менеджер полностью отдаст какие-либо свои обязанности аналитику, даже если последний желает "вырасти" в менеджера.
В результате, аналитик отдаляется от потребностей бизнеса и возможностей разработки, превращаясь в секретаря при менеджере. Потенциально, это ведет к следующим проблемам:
- Конфликт интересов в трактовке требований бизнеса, остается без контроля со стороны заказчика/генподрядчика. Часто это выясняется в момент поставки продукта на пром (или даже после подписания актов о приемке).
Почему требования реализованы как удобнее подрядчику, а не как надо заказчику? Потому что так решили аналитики подрядчика. Где был аналитик заказчика? Обеспечивал реализацию требований полностью и в срок, не заботясь об их, собственно, анализе.
- Профессиональная деградация аналитика. Маловероятен его рост в сторону управления. Зато, из него может получиться классный секретарь. Труд секретаря также почетен, и может хорошо оплачиваться. Но немногие из технических специалистов всерьез мечтают о такой карьере.
Недоменеджеру следует либо требовать работы аналитика, либо уж профессионально расти, как менеджеру (не забывая, что работу аналитика кто-то, все же, должен делать).
2. Технарь
Его еще иногда называют "системный аналитик". Он редко работает с требованиями бизнеса и предметной областью внедрения (чаще не работает никогда). Но он хорошо разбирается в информационной инфраструктуре. Такой аналитик очень ценен для проектов с разветвленной инфраструктурой, в которых сталкивается много разных информационных систем и ландшафтов.
У менеджера часто появляется соблазн удалить технаря из проектного офиса, посадив его с кодировщиками или администраторами, поскольку с ними он лучше находит общий язык и добивается больших результатов.
Такие действия вызывают профессиональную "слепоту": аналитик полностью погружается в хитросплетения кода и проводов и не задумывается, зачем они нужны (то есть, за что платят деньги проектной команде в целом, и ему в частности).
Возможна та же ситуация, что и в пункте 1, когда заказчик осознает, что получил не то, чего хотел, в последний момент.
Технари (не только аналитики) - ненормальные. В том смысле, что их образ жизни и поведение почти всегда отличаются от таковых у "обычного" человека. Если технарь может умело маскировать свою ненормальность, а лучше - осознавать, чем и почему он отличается от других, из него может получиться прекрасный аналитик. Но, это потребует дополнительных усилий от менеджера, на которые он редко бывает готов.
Технарю стоит расширять свой кругозор и оглядываться по сторонам. Для интроверта это может быть непросто, но это единственный путь в аналитики.
3. Козел отпущения
Посмотрим на проект: программисты программируют в поте лица. Вот Jira: много тикетов, но все оперативно закрываются. От релиза к релизу, растет список внедренных фич. Вот Git: змеятся бранчи, стабильнее от релиза к релизу. Результат на лицо.
Вот менеджер бюджет проекта защищен, в MS Project дерево работ, к каждой указаны ресурсы. Все учтено: стимул персонала, обучение, отпуска. Команда работает как часы. Заказчик общается с менеджером каждый четверг, получает подробный отчет и очень доволен. Релиз поставлен в срок.
Только вот почему проект провален? Почему, не смотря на список фич и поставленный релиз, заказчик не подписывает акты? Отчего он сменил радость от резвого хода проекта злобой, когда он подошел к концу?
А что сделал аналитик? Даже документы писал прилежный (и с более низкой зарплатой) технический писатель. Требования, спецификации, архитектура? Да мы все равно в релиз отправили другое!
Вот и нашли виновного. В лучшем случае, без премии оставят, в худшем - показательно уволят. Нечего проекты гробить!
На самом деле, довольно редко нанимают аналитика, чтобы повесить на него провал проекта (чаще такое бывает с менеджерами). Но, бывает. Чаще, аналитик становится виновным в процессе проекта. Я наблюдал такое у талантливых, но не опытных менеджеров.
Когда менеджер боится упустить что-то из своего видения, он начинает оттеснять других от любых важных вопросов проекта, первыми оттесняются аналитик и тимлид разработки. Вы не лезьте в мою работу, я не лезу в вашу. А к заказчику я вас не пущу, только напортите.
Для простых проектов, этот подход часто срабатывает. Но в простом проекте и роль менеджера и аналитика вполне могут ужиться в одном человеке. Если же есть выделенный аналитик, ему остается либо смириться с одной из прочих 5, описанных мною ипостасей, либо вести свою работу "партизанскими" методами.
В случае успеха проекта, об аналитике никто не вспомнит, но в случае провала, вспомнят обязательно.
Козлу отпущения не стоит покорно брести на убой. Работу свою делать добросовестно. Если вас перестали приглашать на встречи и поручать срочную работу - это не передышка, а дурной знак. Надо требовать работу самому.
4. Эникейщик
Аналитик обычно обладает широким кругозором. Может код написать, посчитать сложность алгоритма по О-большое, спаять радиоприемник, поднять сервер LAMP, обжать витую пару... А может и написать экономическое обоснование, заявку на кункурс, вести календарно-сетевой график, чертить UML-диаграммы. Поэтому, велик бывает соблазн привлекать его именно к этим работам: мелочам, не требующим высокой квалификации.
По природе своей работы, аналитику следует быть в курсе всех аспектов проекта. Но, превращаться в обслугу тоже не стоит, платят аналитику не за это. С другой стороны, нельзя и отвергать с негодованием мелкие поручения, со ссылкой на собственную крутость и оклад.
В общем случае, задачи на проекте распределяет менеджер, он и отслеживает загрузку персонала. Опытный аналитик сам организует свою работу для максимальной отдачи. Опытный менеджер сможет это сделать для не опытного аналитика. А вот если на проекте встретились специалисты без большого опыта в этих ролях, могут получиться проблемы.
Эникейщику можно посоветовать, в первую очередь, решать на работе задачи, связанные с аналитикой проекта. Потом - все прочие. А не наоборот!
5. Технический писатель
Когда заходит речь о продукте работы аналитика, обычно сразу вспоминают документацию. Документации на проекте нужно много: требования, технические задания, руководства. Есть весьма устаревшая группа стандартов ЕСПД (Единая Система Программной Документации, ГОСТ 19), на сегодняшний день она, сама по себе, мало применима, но представление о масштабах бедствия дает.
Писать документы неприятно (лично мне, но я не встречал еще никого, кому это доставляло бы удовольствие). Это отнимает много сил. Каждая строчка должна быть четко выверена. Когда документ надо согласовать, его никто не читает, а когда ты считаешь, что все с ним согласились (и подписали), начинают сыпаться замечания.
Наибольшие плоды приносит "гибкое" согласование документов (по аналогии с AGILE-методиками, много маленьких итераций). Но это отнимает много сил, итераций могут быть десятки (лично у меня до сотен дело не доходило). Нужно постоянно переписывать документ, учитывая сотни замечаний. И все ради пары десятков страниц.
Труд технического писателя часто бывает недооценен. Классных технических писателей единицы, и на сложном проекте хороший техпис заслуживает не меньшего оклада, чем руководитель проекта. Жалко, что мало кто это осознает.
Конечно, документы приходится писать всем: и руководителям, и аналитикам, и тестировщикам, и даже программистам (последние при этом, обычно, страшно матерятся). Но все же, технический писатель - отдельная проектная роль, со своими инструментами, стандартами и квалификацией.
На небольшом проекте один человек может совмещать роли писателя и аналитика. Но это не значит, что основная задача аналитика писать и только писать!
Если вы являетесь аналитиком, но выполняете работу технического писателя, задумайтесь, какие аналитические задачи решает каждый из создаваемых вами документов. В разговоре с менеджером, говорите об этих задачах, а не документах. Решение аналитических задач должно иметь приоритет над созданием вспомогательной документации (например, руководств пользователя). Но и отказываться без повода от такой работы не нужно (см. п. 4).
6. Витринный аналитик
Популярный персонаж в консалтинговых компаниях. В стандартную комплектацию проектной команды входит аналитик? Нет вопросов! Берется студент-старшекурсник, одевается в костюм. В одну руку ему дается томик Вигерса, в другую - корпоративный гайдлайн по сбору требований. Все.
Днем молодой аналитик едет к заказчику, и собирает все по чеклисту: юз-кейсы - есть, эскизы экранных форм - есть, блок-схема переходов - есть. Все. Бумажки отвозятся тимлиду и выбрасываются из головы. Вечером - девушка, кафе, диплом.
А где аналитика? Вот же! Ворох бумаг.
Начавшие карьеру таким образом, редко остаются в аналитиках. Хлопотно, бесперспективно. Получив достаточный опыт, такие люди или уходят в узкую специализацию, используя корпоративные программы обучения, или строят карьеру менеджера.
А что же такое "настоящий аналитик" в моем понимании? Все вышеперечисленное, и немного еще. Да, на каком-то отдельном проекте может быть востребован аналитик одного из перечисленных выше подвидов. К тому же, идеально уметь все - выше человеческих сил. Но есть кое-что, что определяет все подвиды: анализ и его результаты, применительно к достижению успеха проекта.
Под анализом обычно понимают анализ требований. А в категорию "требования" можно загнать что угодно. Заказчик что-то хочет - это требования. В проектной команде кто-то заболел - возникли дополнительные требования. В сервере что-то сломалось - требуется починить. Опять требования! Не все требования должен удовлетворять аналитик, но он должен их учитывать, так или иначе.
Менеджер дает проекту импульс, разработчик - результат, а аналитик - смысл.
Кстати, выше я упомянул, в основном, технические компетенции проектного аналитика. Просто мне они ближе. На самом деле, аналитик может и не быть технарем, даже на ИТ-проекте.
Разделение аналитиков на бизнес и системных, я полагаю надуманным. Не понятно, кого понимать под системным аналитиком. Того, кто пользуется методом познания "системный анализ"? Так этот метод универсален, и применим любым человеком. Того, кто анализирует системы (или их связи)? Но в этом случае не уйти от бизнес-смысла.
Мне удалось найти только один документ (2007 года, и до сих пор находящийся в статусе проекта), регламентирующий деятельность именно системного аналитика. Вот он: http://www.apkit.ru/files/analitik.doc.
Документ любопытный. Хорошо подойдет для шаблона должностной инструкции, и может дать общее представление о работе аналитика. Но многие требования в нем спорны и не применимы во всех случаях. Исключений будет больше, чем правил.
А вот для бизнес-аналитиков хороший и универсальный документ есть, это BABOK - Business Analysis Body of Knowledge. Этот документ описывает цели, методы и подходы любого аналитика, не только в ИТ-проекте. И системного аналитика тоже. Как и других аналитиков, например, аналитика банковских продуктов.
Конечно, BABOK во многом завязан на более "раскрученный" PMBOK. Если вы используете не совместимые с ним практики проектного управления, вам он может не подойти.
Впрочем, о стандартах, имеющих отношение к анализу в ИТ-проектах, я напишу подробно в другой раз. А пока, напоследок, короткий дайджест.
Что должен уметь аналитик? - Все понемногу.
Что является основным предметом работы аналитика? - Требования.
Какими особыми техническими навыками должен владеть аналитик? - В общем случае, никакими.
Где почитать о работе аналитика? - BABOK.
Что является критерием успеха работы аналитика на проекте? - Концепция продукта, максимально полно учитывающая ограничения разработчиков и менеджмента с одной стороны, и потребности заказчика с другой (озвученные или скрытые, осознанные и нет).