Как видеть задачу целиком
Обновлено: 29 июн. 2021 г.
Постановка проблемы
Часто, принимая в работу новый проект как бизнес-аналитик, я вижу описание какого-то программного решения, но не получаю на вход информацию, какие проблемы оно призвано решать здесь и сейчас, почему оно построено именно так, и как планируется его развивать в дальнейшем. Как постоянный участник/организатор профессиональных конференций и тренер, я много общаюсь с коллегами, в том числе ведущими аналитиками и руководителями проектов, и вижу, что это не единичная проблема.
Многие тим-лиды и руководители всех мастей сетуют, что их коллеги ограничиваются проработкой одного решения, не рассматривают альтернативные варианты, а также часто фокусируются на внутренней реализации системы, не представляют контекст работы пользователя и текущую ситуацию бизнеса. Да и сами коллеги-аналитики, принимая эстафету в работе над системой, нередко ропщут на тех, кто не вложил в изучение контекста достаточно усилий до них или не задокументировал эту информацию. Для ведущих специалистов, отвечающих за работу команд, отсутствие общего понимания контекста и целей критично тем, что им приходится постоянно проводить глубокое ревью работы аналитиков, что отнимает время от более высокоуровневых обязанностей, и на это ревью не всегда хватает времени. Дальше в статье расскажу, справедливы ли такие сетования на мой взгляд, что можно с этим сделать, и всегда ли нужно что-то делать именно с аналитиками или можно улучшить ситуацию другими способами.
Почему недостаточно пристальное рассмотрение решаемой проблемы беспокоит коллег? Часто оно приводит к тому, что реализуется не самый лучший вариант для решения текущей задачи. Изменения в рабочих системах для бизнес-заказчика почти всегда приводят к трансформации его текущего стиля работы, и в случае неоптимального нового решения оно становится неоправданным, а время людей на переучивание и привыкание к новому потрачено. Для команды разработчиков это в огромном количестве случаев выливается в бесконечное дописывание и переписывание системы, и часто за свой счёт.
Кроме временных и финансовых потерь для обеих сторон это приводит не только к потере лояльности одного клиента, но и к репутационным потерям на рынке в целом. Даже если мы говорим не о заказной разработке, а о работающей внутри одной компании команде, это может повлиять на принятие её будущих предложений и выделение финансирования отдела в будущем.
Помимо того, что без всестороннего рассмотрения задачи решение получается логически и архитектурно неполное, что сулит излишние трудозатраты в поддержке, это также приводит к невыполнению требований отраслевых и государственных регулирующих документов/стандартов, а это влечёт невозможность использовать новое решение целиком. Нарушение уже навязших на зубах требований к хранению персональных данных может рассматриваться как административное правонарушение, и привести к штрафу. Государственные организации предъявляют достаточно серьёзные требования к безопасности ввода и хранения данных, также у них очень специфичные требования к интеграции, тут простым REST API не обойдёшься. Что уже говорить о требованиях к хранению, обеспечения доступа и деперсонализации медицинских данных, например, радиологических исследований.
Что нужно для удовлетворения запроса
Из всех проектных ролей миссия «видеть задачу целиком» ближе всего бизнес-аналитику, поэтому я хочу поговорить о деятельности, которая поможет приблизиться к широкому рассмотрению задачи с точки зрения именно этой роли. Я не отказываю в такой потребности руководителю проектов, например, но у него всё-таки фокус на том, чтобы найти баланс между временем, объёмом работ и удовлетворённостью заказчика, поэтому возможность рассматривать все варианты отсутствует. Итак, если вы решили всерьёз взяться за переосмысление и анализ текущей задачи, вам стоит:
рассматривать задачу с точек зрения разных заинтересованных сторон,
рассматривать весь жизненный цикл системы,
анализировать входную информацию на полноту, качество и актуальность,
проявлять риски и ограничения,
использовать широкий набор аналитических инструментов,
рассматривать несколько решений,
сначала рассматривать тривиальное решение.
Может это и неполный список, но и его достаточно, чтобы построить план саморазвития или развития своей команды на пару лет, поэтому ограничимся пока им.
Рассматривать ситуацию с точек зрения разных заинтересованных сторон. Точка зрения бизнес-заказчика и пользователя, руководителя проекта и архитектора, тим-лида и техподдержки – важные фокусы внимания. Это не значит, что аналитик должен подумать за всех, это значит, что аналитику должна быть доступна информация о принципах архитектурного проектирования текущей системы и управления этим проектом, о том, как планируется поддерживать проект, в идеале и о том, за что именно платит спонсор. Если эта информация нигде не задокументирована, должны быть доступны люди, которые могут ответить на эти вопросы, и не надо стесняться искать их и задавать вопросы о контексте разработки.
Рассматривать весь жизненный цикл системы. Также очень важно иметь в голове временную перспективу жизни разрабатываемых продуктов. Нужно помнить, что продукт не только разрабатывается вами, но и поддерживается – даже если это всего полгода-год, – вам придётся самим отвечать на вопросы и согласованно изменять то, что вы сейчас наработали, а потом передавать в поддержку другим людям. Ещё помните: вашу систему точно рано или поздно выкинут и заменят на другую. Об этом всегда говорилось в учебниках программной инженерии, но до некоторых пор этот постулат можно было игнорировать как абстрактный. Теперь, когда мы каждые 2-5 лет меняем телефоны и ноутбуки, абстракция превратилась в реальность, о которую ежедневно спотыкается бизнес. Главной ценностью для бизнеса является не ваша система, а информация, которая в ней хранится, и если у него не будет уверенности, что эта информация может быть безопасно сохранена или экспортирована, ваша система бизнесу не нужна. Поэтому думать насколько долгую и счастливую жизнь проживёт то, что вы сейчас делаете – должно ли оно быть прототипом, на котором мы моделируем решение задачи, либо ценным источником информации хотя бы на десятилетие, – очень важное упражнение.
Анализировать входную информацию на полноту, качество и актуальность, делать запросы дополнительной информации. Мы получаем информацию на вход самыми разными способами: иногда это техническое задание, расписанное до полей баз данных, иногда макет интерфейса, иногда просто несколько слов вроде «реализовать возможность отображения списка заказов в ЛК пользователя». В техническом задании, сотворённом неопытным заказчиком, часто не хватает информации о целях и ограничениях системы, по макетам интерфейсов нельзя однозначно восстановить пользовательские сценарии и жизненные циклы объектов, изображённых на нём, а по необх