Привет, меня зовут Денис, и я работаю руководителем отдела проектирования в компании SSP SOFT.
Недавно я в очередной раз столкнулся с вопросом о том, чем должен заниматься системный аналитик. В этой статье я хочу поделиться своим опытом и рассказать, почему системный аналитик не должен заниматься проектированием.
Начну с того, что я сам числюсь системным аналитиком всего два года. Я сразу попал в «ведущие системные аналитики», пропустил стадии junior, middle. Спустя год работы ведущим системным аналитиком, меня назначили руководителем отдела проектирования, доверили развитие аналитиков в компании. С этого момента я стал обращать внимание на то, как работают аналитики в разных проектах, чем они занимаются. В компании работает около 30 аналитиков, они заняты в проектах, связанных с разработкой программного обеспечения для бизнеса. Продукты и рабочие процессы в проектах сильно отличаются, это позволяет увидеть всё разнообразие типовых задач, которые выполняет аналитик в команде.
Хотя я не получал специализированного образования в области системного анализа, я знаком с понятиями «требование» и «техническое задание» с самого начала своей карьеры. За плечами 18 лет опыта в ИТ, разнообразные проекты и продукты, есть и успешные, которыми я очень горжусь.
Мой опыт и позиция в компании позволяют увидеть, с какими проблемами чаще всего сталкиваются аналитики, чему они уделяют больше внимания, а что часто упускают.
Прежде чем перейти к проблематике, зафиксируем несколько вводных:
Я не различаю системных аналитиков и бизнес аналитиков, поэтому далее буду использовать просто «аналитик». Мнение спорное, в защиту которого у меня есть аргументы, достойные отдельной истории. В контексте темы этой заметки я имею в виду системных аналитиков.
Под «проектированием» я подразумеваю технический дизайн — отображение верхне-уровневой модели и требований на конкретные технические решения: программные компоненты, интерфейсы, сервисы, схемы данных, типы. Проектирование носит обязывающий характер для реализации, это чертеж по которому будет выполняться разработка.
Я разделяю «моделирование» и «проектирование». Под моделированием я понимаю иллюстрацию идеи, попытку выразить ее суть в компактной и понятной форме. Модель выделяет ключевые свойства и скрывает неважные, при этом не навязывает реализацию, так как находится на высоком уровне абстракции.
В чем вообще проблема?
Почему я так зацепился за тезис «системный аналитик не должен заниматься проектированием»? Кажется, что большинство людей не разделяет эту точку зрения.
На собеседованиях и интервью аналитиков я часто слышу про умения «проектирование микросервисов», «проектирование баз данных» и «проектирование интеграций». Менеджеры и заказчики также часто используют обороты типа «аналитики не учли при проектировании» или «аналитик должен спроектировать». В действительности, среднестатистический аналитик не обладает достаточными знаниями для проектирования микросервисов, интеграций или баз данных на уровне глубже чем концепция. Ему не хватает опыта в программировании и инженерной практики. Ирония заключается в том, что он и не должен этого делать. Аналитик должен понимать технический дизайн, уметь моделировать, но не должен заниматься проектированием.
Для примера рассмотрим случай с базой данных. Обычно аналитик предоставляет логическую модель в форме концептуальной диаграммы классов или ER-диаграммы. Но можно ли сказать, что база данных уже спроектирована? Нет, это около 40% всего процесса проектирования. Оставшиеся 60% (включая индексы, типы данных, репликацию, границы транзакций, секционирование данных, использование расширений сервера) будет проектировать кто-то другой, вероятнее всего, кто-то из разработки.
Если декларируется, что аналитик спроектировал базу данных, то возникает опасный момент, когда менеджер или заказчик считают, что большая часть работы по проектированию БД уже сделана. Ситуация усугубляется, если в команде не налажен процесс проектирования, и такая задача передается разработчику, который транслирует логическую модель в физическую без проектирования, так как считает, что аналитик уже выполнил проектирование. В этом примере много «если», но, к сожалению, такое встречается часто, даже в проектах систем уровня Business Critical.
Если не выполняется техническое проектирование, то в случае проблем часто возникает история с итальянской забастовкой, когда разработчики дословно руководствуются моделью от аналитика. Модель, которая представляет из себя абстракцию, не может отвечать за полноту, она оставляет слишком много открытых вопросов и свободы для реализации. Из-за этого модель уязвима для критики.
В чем решение?
По моему мнению, аналитик не должен заниматься проектированием, так как это является обязанностью техлида со стороны разработки и/или архитектора (software, solution). Важно явно разделить ответственность и выделить «проектирование» в отдельный этап рабочего процесса, за который отвечает отдельный человек. Важно, в случае если некому выполнять проектирование, не перекладывать эту ответственность на аналитика.
Вроде бы ничего нового, прописные истины, но как же часто они нарушаются. Я не настаиваю на том, что в каждом проекте должно быть «проектирование», должен быть свой техлид и архитектор. Во-первых, это не всегда нужно, во-вторых, не всегда возможно найти достаточное количество людей с нужными компетенциями. Однако, мне не нравится история, когда при наличии в команде системного аналитика, есть люди, которые считают что этого достаточно для выполнения проектирования.
Для такой ситуации, когда компетенций не хватает, а проект делать нужно, я использую следующий алгоритм:
Не переставать эскалировать проблему нехватки компетенций для проектирования.
Снизить требования к качеству или ограничить функционал продукта.
Принять факт, что проектирование не будет выполнено. Принять реализацию по умолчанию.
Определить с какими требованиями конфликтует реализация по умолчанию.
Оформить технический долг.
Когда появятся ресурсы на погашение технического долга, восстановить первоначальные требования.
Основная сложность заключается в том, чтобы не переставать, и не забыть, и сделать все 6 пунктов. Часто ограничиваются только пунктом №3, остальное упускается.
Чем же должен заниматься аналитик, если не проектированием?
Я уже упоминал про «моделирование», поэтому остановлюсь на главной задаче аналитика — «управление требованиями».
Я придерживаюсь концепции, что аналитик должен управлять требованиями, но не являться их владельцем. Каждое требование должно иметь своего истинного владельца, который заинтересован в его выполнении и может «спросить», если что. Если требование не имеет владельца (то есть никто из бизнеса, архитекторов, ИБ или служб эксплуатации явно не заинтересован в его выполнении), то оно не имеет смысла. Задача аналитика заключается в том, чтобы найти владельца для каждого требования, предоставить ему информацию о требовании, проверить актуальность и важность требования для владельца. Аналитик должен уметь выявлять избыточные требования и устранять их.
В ходе реализации проекта требования будут меняться, устаревать, конфликтовать. Аналитик должен следить за ними и своевременно реагировать на изменения. Именно эта работа позволяет всей команде не делать лишнего, фокусироваться на том, что нужно.
Ответственность за управление требованиями влечет за собой обязанность аналитика ставить задачи для разработки. Постановка задач в разработку — искусство, достойное отдельной статьи. Не все задачи требуют постановки от аналитика, но есть задачи которые без аналитика поставить нельзя.
Важно также упомянуть о подготовке проектной документации, без этого не обходится ни один проект и ни один аналитик.
Мой ответ на вопрос, чем должен заниматься аналитик — управлять требованиями, моделировать, ставить задачи и разрабатывать техническую документацию. Проектирование в этот список не входит.
