Становление аналитика

image

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Сразу структурирую дальнейшее повествование:
  1. Короткое введение
  2. Аналитики — кто это? + техническое отступление
  3. Зачем нужны аналитики? (привет, кэп)
  4. Кто и как становится аналитиком?
  5. Что должен знать и уметь аналитик и как этому научиться?
  6. Заключение.

Некоторые из этих тем выглядят очевидными. Постараюсь капитанить по-минимуму.

Примечание из будущего:
Дописав до п. 5 я понял, что в задуманном вначале объеме материал получается слишком большой. Пятый пункт заслуживает отдельной статьи, или даже нескольких. Это дело будущего. В данном посте затрону эту тему лишь поверхностно.

Короткое введение


Сухих формальных определений и другого подобного рода материалов по системному и бизнес-анализу на просторах Интернет хватает, так что не стану повторяться. Так же ни в коем случае не собираюсь и пересказывать содержание книги «Путь аналитика. Практическое руководство IT-специалиста».
В последнее время описываемой области знаний уделяется весьма скромное внимание. Выражается это в самых разных вещах. Например, до сих пор нет стандарта де-факто на профессию «Системный аналитик». Конечно, есть Международным институт бизнес-анализа (International Institute of Business Analysis, IIBA) со своим BABOK и собственной системой сертификации. Но широкой полулярностью (как, например, PMI/PMBook в дисциплине управления проектами) они не пользуются, особенно в России.
К слову, в настоящее время создается российское отделение IIBA. Не буду рекламировать, но все желающие могут легко найти соответствующую группу в LinkedIn.

Так же число книг по IT-аналитике заметно меньше, чем по другим IT-дисциплинам (буду рад ошибиться по данному вопросу — возможно, какие-то важные книги в этой области прошли мимо меня). Даже на Хабре статьи непосредственно по аналитике за последние пару лет можно пересчитать чуть ли не по пальцам одной руки (1, 2, 3, 4). Ну да имеем что имеем. В конце концов, все в наших руках.

Аналитики — кто это?


По большому счету в сфере ИТ можно выделить два вида их специализации:
  • Системные аналитики
  • Бизнес-аналитики (данная роль относится не только к ИТ).

Несмотря на то, что решаемые задачи и требуемые навыки у них существенно различаются, на ИТ-проектах в большинстве случаев обе эти роли объединяет в себе один сотрудник (или группа сотрудников). Разделение иногда встречается (например, обычно на проектах для финансовых организаций), но такие случаи в меньшинстве.
Формальные определения без труда гуглятся, а по сути:
  • Главные задачи системного аналитика: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла. Основной, хотя обычно не единственный, документ на выходе – техническое задание или его аналог. На этом остановимся подробнее ниже.
  • Главные задачи бизнес-аналитика – изучение, описание, анализ и (при необходимости) реинжиниринг бизнес-процессов. Основной документ на выходе – описание бизнес-процессов As Is (обязательно) и To Be (при необходимости).

Первый в обязательном порядке должен иметь хороший ИТ-бэкграунд. Для второго он хоть и желателен, но не обязателен. Нередко бизнес-аналитиками становятся люди с экономическим образованием. Первый должен свободно говорить на одном языке с разработчиками и с бизнес-пользователями, для второго достаточно только бизнес-пользователей.
Другими словами, можно устроиться бизнес-аналитиком на крупный проект, не особо разбираясь тонкостях ИТ (я видел такое в одном из крупных российских ритейлеров), но практически невозможно устроиться системным аналитиком, будучи неспособным общаться с конечными заказчиками (неважно, в силу недостаточной коммуникабельности или нежелания разбираться в бизнесе клиента).

Краткое техническое отступление


Давайте сознательно прервем повествование и остановимся на самих требованиях. Что касается видов, атрибутов, характеристик, подходов к сбору и оформлению требований – пожалуй, большего «бардака» сложно найти. Состав и содержание документов с требованиями существенно различаются (взять, к примеру, наш ГОСТ и RUP, и имхо это не сравнение пушки и рогатки). Набор атрибутов требований так же в каждом подходе приводится свой, часто весьма неоднозначный (например, в BABOK). В довершение, часто путают результаты этапов анализа и проектирования, заставляя исполнителей включать в аналитические документы финальный вид диаграммы классов и полную схему БД (об этом ниже).
Не претендуя на истину в последней инстанции или какое-то ноу-хау (примерно то же написано в Википедии), сформулируем два ключевых способа классификации требований.

По уровню:
Бизнес-требования
Самые высокоуровневые требования, которые определяют цели создания ПО. Примерами таких требований могут быть достижение 20%-го сокращения издержек или повышение качества управления (например, за счет возможности оперативного формирования отчетности).
Данные требования обычно описываются в отдельном документе — «Видении проекта» (Vision) или «Бизнес-требованиях», который так же включает определение основных ролей будущих пользователей Системы и перечисление ее основных сценариев использования. Если такого выделенного документа нет, то часто все это включается в техническое задание или его аналог.

Требования пользователей
Они определяют набор пользовательских задач, которые должна решать Система, с описанием сценариев решения данных задач. Требования пользователей обычно представляются в виде перечисления вариантов использования Системы и взаимосвязей между ними (как правило, в виде Use-case диаграммы языка UML).
Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна " Современные методы описания функциональных требований к системам ").

Функциональные требования
Детально описывают все элементы функционала, который должен быть непосредственно реализован в Системе, чтобы обеспечить возможность выполнения всех сценариев использования, описанных в Требованиях пользователей.
Функциональные требования являются наиболее детализированными. Они описывают, в том числе, входные/выходные данные и их проверки, алгоритмы обработки данных и элементы пользовательского интерфейса (без дизайна).
Как правило, данные требования оформляются в виде отдельного документа («Технического задания» и т.д.). В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования.
Пример функционального требования: «По клику на кнопке <Кнопка А> на форме <Форма Б> должно отображаться модальное диалоговое окно, содержащее <Содержание окна>».

По типу:
Функциональные требования
Описывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);

Нефункциональные требования
Описывают характеристики системы и ее окружения, а так же накладываемые ограничения.
Примерами нефункциональных требований могут служить ограничения на поддерживаемые разрабатываемой Системой аппаратные платформы и операционные системы, а так же требования к производительности, к безопасности и т.д.

Примечание:
Как видно из описания, приведенного выше, функциональные требования – это категория требований как по их уровню, так и по их типу. К сожалению, в настоящий момент сложилась именно такая неоднозначная терминология (по опыту многих проектов и нескольких работодателей). Если у вас есть другие подходы, пожалуйста, поделитесь.

Описывать характеристики (непротиворечивость, полноту и т.д.) качественных требований и все их атрибуты (статус, источник и т.д.) здесь не буду, чтобы не раздувать пост. Если эта тема будет интересна, с удовольствием освещу ее в отдельной статье, хотя все это без труда гуглится. По этой же причине не стану описывать здесь статусы/версии/срезы (baseline) требований.
Однако хотелось бы остановиться на некоторых базовых принципах работы с требованиями (этот список далеко не полон):

Последовательность работ и их результатов
Следует четко различать результаты этапов анализа и проектирования. На этапе анализа формируются требования к Системе.
Все детали реализации Системы определяются уже на следующем этапе – этапе проектирования. Таким образом, в случае необходимости включить в «Техническое задание» модель базы данных Системы или диаграммы классов нужно понимать, что в этом случае:
  1. Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором);
  2. Срок сдачи технического задания будет увеличен, т.к. для его завершения потребуются некоторые результаты этапа проектирования.
    Результаты этапа проектирования эффективнее оформлять в отдельном документе, описывающем архитектуру Системы.

Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.

Порядок сбора самих требований:
  1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
  2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
  3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.


Отсутствие дублирования в описании требований
Ключевым моментом управления требованиями является отсутствие дублирования, т.е. каждое требование должно быть зафиксировано только в одном документе и только в одном месте данного документа. Отступление от данного принципа приведет как к серьезному увеличению трудозатрат на поддержку данных документов, так и к неизбежному нарушению их целостности (т.к. для сложно программной системы учесть все нюансы всех новых требований параллельно во всех документах является сложной и ресурсоемкой задачей).
В случае необходимости, вместо дублирования описаний требований необходимо использовать ссылку на оригинал данного описания. Это позволит как учесть взаимосвязи между требованиями, так и избежать описанных выше проблем.

Управление изменениями
При разработке современных программных систем часто требуется внести изменения в требования уже по окончании этапа анализа. Здесь важно, чтобы стороны понимали и принимали следующие принципы:
  • Исполнитель понимает, что требования не всегда могут быть сформулированы Заказчиком полностью и корректно на начальных стадиях проекта. Соответственно, изменения в требованиях по ходу проекта допускаются.
  • Заказчик понимает, что изменение требований влечет за собой увеличение трудозатрат и сроков сдачи продукта.


Доступность информационных ресурсов, заинтересованных лиц, экспертов предметной области и технических специалистов
Для формирования полного и точного перечня требований к Системе специалисты Исполнителя должны иметь в достаточном объеме доступ:
  • ко всем относящимся к разработке ПО материалам;
  • ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями

Во втором случае имеются в виду:
  1. заинтересованные лица
  2. эксперты предметной области
  3. лица, участвующим в согласовании и утверждении требований
  4. технические специалисты со стороны заказчика либо других подрядчиков/субподрядчиков.

На этом, пожалуй, закончим это небольшое отступление. Язык повествования получился сухой, каюсь. Но тема достаточно формализованная.

Зачем нужны аналитики? (привет, кэп)


До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).
Излишняя бюрократизация конечно зло, но реализовать большой проект «на коленке», да еще усилиями специалистов лишь одного профиля в современном мире нереально. Никто не оспаривает важную роль разработчиков, но будут ли они продавать, оформлять кучу сопутствующей документации, пытаться понять своеобразный язык заказчиков и т.д.? Позволю себе предположить, что вряд ли многих из них это заинтересует.

К слову, если бы все вышеназванные товарищи (аналитики, менеджеры и т.д.) были бы обычными дармоедами, их бы в нашем мире жесткой конкуренции не нанимали в таких количествах и не платили бы им таких денег. Оговорюсь только, что речь идет об Enterprise-проектах. Создать успешное мобильное приложение и заработать на нем понятные деньги сейчас (пока еще?) под силу одному человеку.
Возвращаясь, собственно, к роли аналитиков. Чтобы не растекаться мыслью по древу, просто перечислю основные моменты, с которыми им приходится сталкиваться в реальных проектах:
  • Выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания.
  • Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.
  • В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
  • Проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора.
  • Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.
  • Завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик.
  • Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям.
  • Управлять изменениями требований.
  • Осуществлять все взаимодействие с заказчиками по вопросам требований.
  • Часто – участвовать в сдаче продукта заказчику.

Так же аналитиков частенько «припахивают» к не совсем профильным для них задачам, вроде участия в тестировании, внедрении и разработке пользовательской документации. Бороться с этим или смириться – по большому счету личное дело каждого. Более интересной, хоть и тоже не совсем профильной активностью является участие в пресейлах. Кстати, часто эта деятельность бывает весьма увлекательной и развивающей (хотя и чрезвычайно затратной по времени).

Кто и как становится аналитиком (по трудовой)?


Чистых бизнес-аналитиков, вовлеченных в ИТ-проекты, не так много. В большинстве случаев их задачи выполняют системные аналитики. И признаюсь, у меня нет репрезентативной выборки, чтобы судить, откуда они берутся.
Что же касается системщиков, просто по опыту: стать аналитиком «сразу» (без опыта предыдущей работы в сфере ИТ) обычно нельзя. По крайней мере, за все время моей работы мне не удалось встретить ни одного такого человека. Видимо это из-за того, что как требования к кандидату, так и ответственность, изначально велики.

На практике, в аналитиков часто вырастают успешные тестировщики и, иногда, технические писатели. Так же нередко аналитиками становятся разработчики: кто-то из-за того, что понял, что разработка – это не его, кто-то действительно хочет быть аналитиком, для кого-то это лишь более короткий путь в ПМ-ы.
Всего один раз встречал аналитика, выросшего из системного администратора. Здесь не возьмусь делать выводы – опять же слишком маленькая выборка. Так же знаю одного ПМ-а, перешедшего в аналитики, но это скорее исключение.

Что должен знать/уметь аналитик и как этому научиться?


Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка прифигели несколько удивились тому объему знаний и умений, которые автор предлагает освоить несчастному читателю. Если вкратце, то следуя данной книге, аналитик должен освоить весь накопленный человечеством опыт в данной области со всеми методологиями, техниками и инструментами, а заодно и в максимальной степени обладать всеми положительными личными качествами, присущими человеческим существам.

На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.
Не говорю, что предложенные там навыки не важны, просто надо уметь расставлять приоритеты. К слову, для аналитика это ключевое качество. И, что бы я тут не писал, книгу эту несомненно стоит прочитать.

Однако, как я уже упоминалось во вступлении, знания и навыки аналитика и способы их приобретения – тема очень большая. И чтобы не раздувать этот пост, не буду пытаться осветить ее здесь подробно.
А в если в двух словах, то конечно стоит иметь представление:
  • о жизненном цикле ПО;
  • о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
  • об основах системного анализа (Вигерс отлично подойдет);
  • о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
  • о теории реляционных БД;
  • и т.д.

О необходимости владеть в совершенстве Word-ом или его аналогом даже не пишу (смайл). А вот о необходимости владеть хотя бы одним инструментом для проектирования макетов интерфейсов, стоит упомянуть. Выделенные интерфейс-дизайнеры – редкость, так что эта работа часто «падает» на аналитиков. Здесь кроме очевидного Visio могу посоветовать простой и удобный Evolus Pencil.
Плюс, некоторые личные качества, такие как ответственность, коммуникабельность и внимание к деталям, действительно стоит «прокачивать». Для этого есть специальные техники.

Заключение


Уважаемые коллеги, я буду искренне рад, если данный пост был полезен. Готов обсудить любые возникшие вопросы, или подробнее осветить, насколько смогу, заинтересовавшие темы. Если Вы с чем-то не согласны, пожалуйста, пишите. Давайте учиться. И да здравствует Lifelong learning!
Share post

Similar posts

Comments 50

    –4
    >> будут ли они продавать…

    Продавать нужно какашку, годную вещь сами купят.
      +6
      Эх, тяжело вам наверное в реальном мире живется :)
        +2
        Это же не антивирус в коробке. Такие вещи продаются и внедряются годами.
          +1
          Ага, не надо писать резюме и отвечать на вопросы на собеседовании. Просто будет умным и вас везде возьмут и дадут много денег.

          Звучит как-то странно, не так ли?
            0
            Вы свое резюме печатаете в газете, расклеиваете на заборах, его зачитывают по радио и демонстрируют по телевизору в перерывах футбольных матчей? «Красивый, умный, в меру упитанный мужчина в самом расцвете сил решит все ваши проблемы, стучите в аську, и пусть весь мир подождет, ведь вы достойны лучшего специалиста, только здесь, только сейчас и только в честь дня рождения канадской компании скидки при приеме на работу!».
              0
              Если бы такое окупалось, то люди бы обязательно это делали.
              Но обычно все гораздо проще — вы просто вывешиваете резюме на HH. Он кстати предлагает за деньги (небольшие) его продвинуть ваше резюме.

              Кстати это вы про маркетинг, а не про продажу. Продажа по большей части происходит на собеседовании.
            0
            Если бы всё было так на самом деле, то в течение 20 лет 40-50% европейских женщин не умирало бы при родах. Потому что умный врач придумал годную вещь. Но вот врачи не «покупали» её 20 лет. И их пациентки дохли как мухи.
            +1
            Коллеги, это мой первый пост на Хабре, и я был бы очень признателен минусующим за фитбэк. Хотелось бы понять, где накосячил. Заранее спасибо.
              0
              Я плюсанул (как минимум за старания), но может минусуют за излишне официальный стиль речи? Все эти «сбор требований к системе» и «реинжиниринг бизнес-процессов» звучат достаточно скучно.

              Может стоит описать это более неформальным языком, представьте, будто вы рассказываете о том, чем вы занимаетесь, своим друзьям или девушке, а не какой-нибудь строгой комиссии.

              Или хотя бы добавьте к скучным сухим определениям больше примеров из жизни.
                0
                Да, есть такой грех. Просто требования и пишутся сухим формальным языком. Я думал он будем уместен и в статье по аналитике. Похоже я ошибся — буду исправляться. Спасибо!
                А вот девушке своей я объяснял чем занимаюсь чуть ли ни на примерах персонажей из русских народных сказок :) Вряд ли здесь такое будет уместно
                  0
                  >Просто требования и пишутся сухим формальным языком.

                  А вот и зря. Вы пишите требования чтобы донести мысли до окружающих, а мысль гораздо лучше доносится с подкреплением эмоциями. Я давно отказался от сухости в описаниях и результаты стали намного лучше. Это конечно может на понравиться начальству, зацикленному на формалистике, но это уже ваша воля выбирать, где работать.
                    +1
                    «Пишутся» это скорее уже фиксация. Едва ли в ТЗ для крупного гос. заказчика будут уместны эмоции. Доносятся же мысли обычно раньше — на совещаниях и конф. колах. Там, конечно, язык куда боле живой. Иногда даже слишком живой :)
                    Но что я, судя по всему, точно сделал зря, так это выбрал сухой стиль изложения для этой статьи на Хабре. Не стоило насиловать Ваше восприятие формализованным текстом. Исправлюсь.
                0
                >До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).

                Возможно, многие хабралюди действительно так думают :). Тут уже ничего не поделаешь.
                  +1
                  Печаль если так
                0
                Коллеги, добавляющие пост в избранное, отпишитесь, пожалуйста, какие еще темы были бы Вам интересны.
                  +1
                  Таким образом, в случае необходимости включить в «Техническое задание» модель базы данных Системы или диаграммы классов нужно понимать, что в этом случае:
                  Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором).

                  и
                  Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.

                  А почему архитекторов нельзя смешивать, а проектировщиков интерфейса можно? Точнее, мне непонятно почему архитектор не входит в команду разработчиков ТЗ, а проектировщик входит?
                    +1
                    Я имел ввиду, что не стоит включать в ТЗ результаты «тяжелых» работ этапа проектирования, выполняемых архитектором. Макеты интерфейса — тоже проектирование, но трудозатраты на него как правило меньше, и выполняется оно тем же аналитиком, который пишет ТЗ. Поэтому, хотя логически это не правильно, в ТЗ все-таки можно включать макеты UI, т.к. это дается малой кровью.
                      0
                      Вы молодец, потому что защищаете подход, где каждый этап разработки должен выполнять отдельный специалист.
                      Что касается терминов, то в моем понимании, макет интерфейса — неработающая модель, выполненная в натуральную величину и выглядящая так, как будет выглядеть работающий экземпляр (тут есть терминология с которой я согласен), а это большой отдельный труд. В общем, не буду цепляться к словам, вопросов больше нет.
                      Написал же я потому (я не проектировщик интерфейсов), что надоело видеть системы без проработанного интерфейса и, зачастую, это формулируется как раз в виде «проходная» — не «тяжелая» работа. Допускаю, что когда стоишь перед горой всяких деталей от нового, большого проекта, то думаешь больше о том как собрать из них летающую конструкцию, а не об удобстве пассажиров… пока сам не окажешься на месте пассажира :) в общем, уважайте труд юзабилистов, они экономят наши нервы :)
                  • UFO just landed and posted this here
                    0
                    сбор, анализ, формализация и согласование требований к системе.

                    Другими словами, управление требованиями на протяжении всего их жизненного цикла.


                    У вас тут классическая путаница. То, что описано в первой строчке — это разработка требований.

                    То, что во второй — управление требвоаниями — совсем другая работа, ей занимается менеджер.
                      0
                      По поводу lifelong learning — где вы взяли слова «PMbook» и «фитбэк» ?)
                        0
                        в PMBoK описался, каюсь. А насчет фитбэк/фидбэк, то на заимствованные слова вроде устоявшегося написания еще нет ) Или я не так понял вопрос?
                        0
                        То, что во второй — управление требованиями — совсем другая работа, ей занимается менеджер.

                        Признаться, на практике ни разу не сталкивался с ситуацией, когда менеджер участвует в процессе управления требованиями более, чем на уровне отслеживания статусов ключевых из них. Даже на довольно крупных проектах не попадалось подобного разделения. Весь жизненный цикл требований всегда контролируется аналитиком, иначе будет бедлам.
                        Если Вы имеете ввиду менеджера продукта, то в нашей действительности это обычно на 80% тот же аналитик с некоторыми дополнительными обязанностями/полномочиями, вроде участия в маркетинговых активностях.
                          0
                          Управление требованиями — это принятие управленческий решений о:
                          1. Приоритетах требований
                          2. Рамках продукта (какие требования включать, какие — нет), оно же — scope management из того же PMBOK, включая сортировку входящих внешних требований — какие требования из других проектов включать, а какие — нет.
                          3. Рамках итерации
                          4. Чего проект требует от других проектов — исходящие требования

                          Эти решения принимает менеджер, и даже если выдвигает часть из них аналитик — всё равно несёт ответственность за них он.

                          То, что физически в учётной системе атрибуты «Приоритет, Релиз, Итерация, Источник, Потребитель» проставляет, например, аналитик, ещё не делает его «управленцем требований», он тут просто учётчик, оператор БД.

                          Также, технически, под гриф «управления требованиями» попадают:
                          5. Управление статусом требований и
                          5. Управление внутренними трассировками требований
                          7. Управление трассировками требований на другие артефакты проекта

                          С этими атрибутами действительно менеджеру возиться не интересно и он может доверять всю эту работу аналитику.

                          Но если посмотреть на жизненный цикл требований и на трассировки, то станет понятно, что аналитик отвечает только за часть переходов и за внутренние трассировки, а за переходы типа «разработано — протестировано» и за трассировки требований на тесты, например, отвечает уже тестировщик.
                            0
                            Приоритезация требований — задача заказчика с помощью аналитика(-ов) исполнителя. Но никак не менеджера исполнителя. Следующие 2 пункта РП так же может только курировать. Он сам не определяет ни рамки (а лишь согласовывает с заказчиком то, что предварительно оговорено с аналитиком… а еще перед этим — с аккаунтом) и сам не определяет границы итераций, т.к. для этого надо как минимум четко понимать взаимосвязи между требованиями. Он может лишь согласовывать и утверждать их.
                            Я не хочу спорить о смысле формальных терминов, я просто имел ввиду что по сути управление требованиями — задача аналитика. А то что РП в ней организационно участвует — так он так же участвует в большинстве проектных активностей.
                            Извиняюсь, если некорректно сформулировал. Я просто хотел донести суть.

                            Кстати, переход «разработано — протестировано» тоже бывает организован по-разному. Часто реализацию ключевых требований полезно «пропускать» через аналитика, чтобы обеспечить высокоуровневую проверку (чтобы исключить ситуацию, когда тестеры убьют неделю на тестирование того, что в принципе должно работать по другому… причем такая ситуация может быть не только из-за нечетко сформулированных требований, но и еще из-за ряда причин, таких, например, как квалификация самих тестировщиков… ничего плохого не хочу про них сказать, но бывают ситуации когда на проекте временно работают только тест-джуниоры).
                              0
                              А я имею в виду, что управление требованиями — это не задача аналитика. Прежде всего потому, что управление — это управление, а разработка — это разработка: www.analystdays.com/talk.sdf/analystdays/analystdays1/talks/7518

                              И я могу это утверждать с позиции опыта руководителя отдела в 30 аналитиков с попытками отвечать за управление требованиями.
                                0
                                Я согласен. В рамках задачи аналитика дальше может идти консультирование по собранным требованиям, но управления этим скопом — отдельная задача.

                                Но в рамках некоторых «небольших» проектов, ее вполне может покрывать один человек.
                        0
                        По поводу классификации требований — и как же вы интересно в работе отличаете функциональные функциональные требования от функциональных нефункциональных? )
                          0
                            0
                            и как же вы интересно в работе отличаете функциональные функциональные требования от функциональных нефункциональных?

                            получается, что так, как предложено во второй Вашей ссылке — зовем их системными (в классификации по уровню)

                            Какие ещё есть подходы, делюсь

                            Было бы интересно почитать про опыт практического применения первого подхода. На первый взгляд, он выглядит перегруженным. А второй по сути совпадает с описанным в статье.

                            Кстати, хотел поблагодарить за интересные видео (В чём заключается работа системного аналитика (видео)), и узнать, планируете ли Вы продолжать активности по летней школе системного анализа?
                              0
                              А что вы понимаете под «практическим применением»?

                              Задача классификации в таком виде — показать картину понятий и взаимоотношений между ними. Чтобы, например, когда специалист слышит слово use case и использует их в работе, он понимал, что это такое в терминах видов требований — а именно, трассировка пользовательских требований на технические.

                              Наличие такой классификации не обязывает использовать все их виды и форматы представления в работе — они определяются опытом участников и контекстом проекта.
                                0
                                Летнюю школу пока продолжать/повторять не планируем.

                                Своих целей мы 1-й школой добились, а как формат — марафон — она тяжеловата и для ведущих и для участников.

                                Будем делать короткие модули (1-4 недели), но скорее только в онлайне, за деньги, но не очень дорого.
                                  0
                                  А на кого будут рассчитаны модули? Только на начинающих или на всех?
                                    0
                                    Я сейчас уже вижу как минимум 3 уровня.
                                    0
                                    .
                                    0
                                    И ещё по школе — мы прямо сейчас ведём «весеннюю школу», которую спонсирует Джет: habrahabr.ru/post/178475/#comment_6195579
                                0
                                Enterprise это какой-то другой мир в IT, чего там только не придумали. Обычному честному быдлокодеру читать страшно.
                                  +1
                                  Привет

                                  Я работаю аналитиком, но подход, описанный вами, в сборе требований расстраивает меня чуть боле чем полностью. У меня есть несколько вопросов к вам:
                                  — насколько часто складывается ситуация, когда требования, описанные в ТЗ, устаревают прежде чем вы закончили писать этот самый ТЗ? В моей практике это каждый первый проект.
                                  — Кто потребитель ваших документов? Это практически непосильная работа для разработчиков прочитать талмуд в 100 страниц со всякими UML диаграммами и прочей ересью. Если учесть п. 1, то становится понятно, что девелоперы на это смотрят, как на пустую трату времени.
                                  — Ну и пожалуй самый важный вопрос. Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика.
                                    0
                                    Я не автор статьи, но попробую ответить на ваши вопросы (имею опыт работы системного/бизнес-аналитика):

                                    — проблема, когда требования устаревают до окончания описания ТЗ — реальная проблема и в BABOK версии 3 над этим активно работают. В рассылке для волонтеров на его написание указывалось, что они хотят сосредоточиться на Agile подходе. Следует учесть, что полностью писать ТЗ заранее нужно далеко не везде и не всегда.
                                    — потребителей документов может быть много – от руководства до программистов. Созданное ТЗ – это документ, имеющий ценность для бизнеса, ценность для разработчиков и т.д. Часто ожидается что с ТЗ будет работать некий менеджер проектов, который распределит работу между разработчиками. Из опыта работы разработчика – общаясь с заказчиком напрямую разработчики пишут код и много раз его переделывают, в то время как написанное качественно ТЗ значительно снижает кол-во переписываний кода (в чем согласно BABOK одна из основных задач бизнес-аналитика).
                                    — для этого есть отдельный knowledge area в BABOK, как «Solution assessment and validation».

                                    С удовольствием отвечу на вопросы, если у вас они есть :-)
                                      0
                                      К сожалению или к счастью, в современном мире под ТЗ понимается всё, что угодно — от действительно постановки задачи на проектирование с переченем функций до детальных спецификаций с макетами экранов, алгоритмами, детальными вариантами использования (что, например, по ГОСТУ уже скорее соответствует техническому проекту — ТП).

                                      Эффективное ТЗ — это документ на 10 страниц, который разработчик прочитать может. Но если есть возможность, то лучше даже такое ТЗ представлять команде разработки, как и концепцию, на специальной встрече, чтобы убедиться, что они услышали, поняли, задали вопросы, получили ответы, сняли неопределённость и риски, и приняли то, что там описано.

                                      А если засовывать в ТЗ все решения, то немудрено, что они устаревают к вечеру.

                                      Как удостовериться — организовать:
                                      1. Разработку приёмочных тестов и их исполнение — это в каскадном режиме, в общем случае не рекомендую.
                                      2. Регулярную демонстрацию с приёмкой — в итерационном режиме, раз в 1-4 недели.
                                        0
                                        Спасибо за ответ, у меня не было желания столкнуться с вами лбами. Просто в вашей статье я увидел те проблемы, через которые я прошел раньше. То, что не работало во многоих моих проектах, вот меня и задело :)

                                        Я выработал немного другой подход, более гибкий, спасибо за это книге Specification by Example. Если есть желание могу поделится опытом
                                          0
                                          Это не моя статья.

                                          Более гибкий, чем что?

                                          Поделитесь конечно!
                                        0
                                        Очень интересный вопрос Вы подняли. Действительно, требования стремительно устаревают. Но при этом ТЗ всё равно нужно: как правило, ТЗ — Приложение №1 к договору между исполнителем и заказчиком, и это единственный способ установить критерии успешного выполнения работы.

                                        Один из вариантов — включать в ТЗ только ключевые требования (без детализации), и только бизнес-требования (никакого проектирования). Но и он не без недостатков. Во-первых, тогда ТЗ получается не по ГОСТ. Во-вторых, бывают ключевые требования низкого уровня, и непонятно, что с ними делать — например, когда жестко заданы платформа разработки, СУБД и/или язык программирования. В-третьих, даже ключевые бизнес-требования могут устареть, хотя это случается, к счастью, намного реже.

                                        Другой вариант — работать полностью на устной договоренности, то есть в договоре что-то условно (рамочно) зафиксировали, а дальше каждое изменение согласовываем. Вариант работает до первого конфликта мировоззрений. Всё, что не зафиксировано письменно, оказывается в момент конфликта никогда не существовавшим.

                                        Третий вариант — работать по Time&Materials. Не получается, когда у заказчика бюджет жестко фиксирован, и в нашей сфере это почти всегда так. Кроме того, вариант оправдан только в случае добросовестного и дисциплинированного разработчика, который не будет тупо проедать деньги заказчика.

                                        В реальности получается что-то среднее между этими тремя вариантами. То есть, составляем договор и ТЗ, в которое стараемся вписывать только самое важное, что вроде бы не должно меняться в ходе проекта. В договор закладываем заранее избыточные трудозатраты на непредвиденные доработки. В ходе работы договариваемся, какие требования будем принимать формально, а какие — придирчиво. Например, если какое-то требование в ТЗ есть, но уже не актуально — значит, пусть будет, но для галочки.

                                        Всё равно, конечно, получается плохо формализовано и далеко от идеала, но как по-другому — непонятно.
                                          0
                                          Почему ключевые требования — не по ГОСТ?

                                          Почему важно, чтобы было по ГОСТ?

                                          Почему вы называете ограничения на технологическую платформу низким уровнем?
                                            0
                                            Почему вы называете ограничения на технологическую платформу низким уровнем?


                                            Под низким уровнем я подразумеваю глубину проработки в иерархии цели -> требования -> проектирование -> реализация. По моему мнению, когда бизнес-требования работают только в терминах бизнеса, а оптимальная технологическая платформа определяется при проектировании, можно добиться большей эффективности автоматизации. Но это не всегда возможно.

                                            Почему ключевые требования — не по ГОСТ?
                                            Почему важно, чтобы было по ГОСТ?


                                            Работать по ГОСТ важно, например, когда работаешь с госзаказчиком. Или отчитываешься по государственной субсидии. Кому-то это, действительно, не нужно, но для многих это серьезный фактор.

                                            Структура ТЗ по ГОСТ 34 задает определенный ракурс для описания требований, и не всегда этот ракурс хорошо подходит для проектируемой системы. Хотя формально ГОСТ позволяет выкинуть половину разделов и добавить десяток своих, такое обращение со стандартом воспринимается экспертами очень настороженно, независимо от того, насколько это оправданно.

                                            Здесь можно развить большой холивар на тему того, насколько хорош ГОСТ и как его «правильно готовить». Я не очень хочу на эту тему спорить, и готов согласиться с тем, что он вполне позволяет включить в себя все необходимые требования независимо от специфики проекта. Но последовательность разделов, группировка требований и терминология, принятые в стандартах 34-й серии лично мне иногда кажутся не вполне подходящими в ряде случаев. Например, при описании требований к веб-сайтам эта структура и терминология не является оптимальной.
                                              0
                                              Если выбор технологии обусловлен стоимостью интеграции с другими системами и стоимостью поддержи и разработки — то это бизнес-решение.

                                              В продуктовой разработке ГОСТЫ не нужны.
                                              Во внутренней разработке ГОСТЫ не нужны.
                                              В заказной разработке ГОСТЫ нужны только для большинства госпроектов.

                                              Итого, «не по ГОСТ» не является проблемой как минимум для 2-х контекстов из 3-х, а для заказной актуально для меньшей доли рынка (Доля B2G-проектов меньше B2B).
                                                0
                                                Доля B2G-проектов меньше B2B


                                                С точки зрения количества проектов — может быть. С точки зрения объема рынка в рублях — уже не факт. И сведения, которые имеются у меня, говорят о том, что сложных масштабных внедрений больше именно в госсекторе.

                                                Кроме того, госсектор чаще заказывает решения, отличные от типовых. Простой пример — бухгалтерия нужна каждой компании, а СМЭВ или ГАС «Выборы» — по штуке на всю страну.
                                          0
                                          Устаревание требований — действительно ключевая проблема. Согласен с коллегами — она отчасти решается использованием гибких методологий разработки, а отчасти — прописанием в уставе проекта, что все понимают, что требования не могут быть сформулированы сразу полностью и безошибочно, да еще и на длительный срок. Т.е. заказчик имеет право менять требования по ходу проекта, но при этом адекватно относится к соответствующему увеличению сроков и стоимости.

                                          Что касается «недетализированных ТЗ», то это скорее Бизнес-требования. Если по вашим формулировкам программист не может начать работать, то это не ТЗ и не его аналог. ТЗ на 10 страниц — отличная идея, но не всегда реализуемая (например многие гос. заказчики требуют полное ТЗ до начала разработки). Но даже если мы напишем «монстра» на 250 стр, то его совсем не нужно читать полностью всем разработчикам. Куда удобнее использовать системы таск-трекинга, в талоны которых можно писать номера конкретных разделов ТЗ, где детализирован именно текущий таск.

                                          Пример:
                                          1. Аналитик Вася заводит фичу, что нужно добавить в админку новый справочник и указывает номер раздела ТЗ, где он описан
                                          2. Dev lead Дима создает дочерние таски (доработать БД, создать новую вкладку на UI, реализовать импорт их XLSX и т.д.)
                                          3. И когда дело доходит до разработчиков Саши, Маши и Вольдемара — то им либо не нужно смотреть в спеку вообще, либо — только в указанный раздел

                                          Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика

                                          Формальные способ (если резюмировать) — использование agile-овых методик. Косвенный — не скупиться на опытных аналитиков :)
                                            0
                                            По ТЗ программист и не должен мочь начать работать, по ТЗ должен мочь начать работать архитектор :)

                                        Only users with full accounts can post comments. Log in, please.