Постановка проблемы
Часто, принимая в работу новый проект как бизнес-аналитик, я вижу описание какого-то программного решения, но не получаю на вход информацию, какие проблемы оно призвано решать здесь и сейчас, почему оно построено именно так, и как планируется его развивать в дальнейшем. Как постоянный участник/организатор профессиональных конференций и тренер, я много общаюсь с коллегами, в том числе ведущими аналитиками и руководителями проектов, и вижу, что это не единичная проблема.
Многие тим-лиды и руководители всех мастей сетуют, что их коллеги ограничиваются проработкой одного решения, не рассматривают альтернативные варианты, а также часто фокусируются на внутренней реализации системы, не представляют контекст работы пользователя и текущую ситуацию бизнеса. Да и сами коллеги-аналитики, принимая эстафету в работе над системой, нередко ропщут на тех, кто не вложил в изучение контекста достаточно усилий до них или не задокументировал эту информацию. Для ведущих специалистов, отвечающих за работу команд, отсутствие общего понимания контекста и целей критично тем, что им приходится постоянно проводить глубокое ревью работы аналитиков, что отнимает время от более высокоуровневых обязанностей, и на это ревью не всегда хватает времени. Дальше в статье расскажу, справедливы ли такие сетования на мой взгляд, что можно с этим сделать, и всегда ли нужно что-то делать именно с аналитиками или можно улучшить ситуацию другими способами.
Почему недостаточно пристальное рассмотрение решаемой проблемы беспокоит коллег? Часто оно приводит к тому, что реализуется не самый лучший вариант для решения текущей задачи. Изменения в рабочих системах для бизнес-заказчика почти всегда приводят к трансформации его текущего стиля работы, и в случае неоптимального нового решения оно становится неоправданным, а время людей на переучивание и привыкание к новому потрачено. Для команды разработчиков это в огромном количестве случаев выливается в бесконечное дописывание и переписывание системы, и часто за свой счёт.
Кроме временных и финансовых потерь для обеих сторон это приводит не только к потере лояльности одного клиента, но и к репутационным потерям на рынке в целом. Даже если мы говорим не о заказной разработке, а о работающей внутри одной компании команде, это может повлиять на принятие её будущих предложений и выделение финансирования отдела в будущем.
Помимо того, что без всестороннего рассмотрения задачи решение получается логически и архитектурно неполное, что сулит излишние трудозатраты в поддержке, это также приводит к невыполнению требований отраслевых и государственных регулирующих документов/стандартов, а это влечёт невозможность использовать новое решение целиком. Нарушение уже навязших на зубах требований к хранению персональных данных может рассматриваться как административное правонарушение, и привести к штрафу. Государственные организации предъявляют достаточно серьёзные требования к безопасности ввода и хранения данных, также у них очень специфичные требования к интеграции, тут простым REST API не обойдёшься. Что уже говорить о требованиях к хранению, обеспечения доступа и деперсонализации медицинских данных, например, радиологических исследований.
Что нужно для удовлетворения запроса
Из всех проектных ролей миссия «видеть задачу целиком» ближе всего бизнес-аналитику, поэтому я хочу поговорить о деятельности, которая поможет приблизиться к широкому рассмотрению задачи с точки зрения именно этой роли. Я не отказываю в такой потребности руководителю проектов, например, но у него всё-таки фокус на том, чтобы найти баланс между временем, объёмом работ и удовлетворённостью заказчика, поэтому возможность рассматривать все варианты отсутствует. Итак, если вы решили всерьёз взяться за переосмысление и анализ текущей задачи, вам стоит:
рассматривать задачу с точек зрения разных заинтересованных сторон,
рассматривать весь жизненный цикл системы,
анализировать входную информацию на полноту, качество и актуальность,
проявлять риски и ограничения,
использовать широкий набор аналитических инструментов,
рассматривать несколько решений,
сначала рассматривать тривиальное решение.
Может это и неполный список, но и его достаточно, чтобы построить план саморазвития или развития своей команды на пару лет, поэтому ограничимся пока им.
Рассматривать ситуацию с точек зрения разных заинтересованных сторон. Точка зрения бизнес-заказчика и пользователя, руководителя проекта и архитектора, тим-лида и техподдержки – важные фокусы внимания. Это не значит, что аналитик должен подумать за всех, это значит, что аналитику должна быть доступна информация о принципах архитектурного проектирования текущей системы и управления этим проектом, о том, как планируется поддерживать проект, в идеале и о том, за что именно платит спонсор. Если эта информация нигде не задокументирована, должны быть доступны люди, которые могут ответить на эти вопросы, и не надо стесняться искать их и задавать вопросы о контексте разработки.
Рассматривать весь жизненный цикл системы. Также очень важно иметь в голове временную перспективу жизни разрабатываемых продуктов. Нужно помнить, что продукт не только разрабатывается вами, но и поддерживается – даже если это всего полгода-год, – вам придётся самим отвечать на вопросы и согласованно изменять то, что вы сейчас наработали, а потом передавать в поддержку другим людям. Ещё помните: вашу систему точно рано или поздно выкинут и заменят на другую. Об этом всегда говорилось в учебниках программной инженерии, но до некоторых пор этот постулат можно было игнорировать как абстрактный. Теперь, когда мы каждые 2-5 лет меняем телефоны и ноутбуки, абстракция превратилась в реальность, о которую ежедневно спотыкается бизнес. Главной ценностью для бизнеса является не ваша система, а информация, которая в ней хранится, и если у него не будет уверенности, что эта информация может быть безопасно сохранена или экспортирована, ваша система бизнесу не нужна. Поэтому думать насколько долгую и счастливую жизнь проживёт то, что вы сейчас делаете – должно ли оно быть прототипом, на котором мы моделируем решение задачи, либо ценным источником информации хотя бы на десятилетие, – очень важное упражнение.
Анализировать входную информацию на полноту, качество и актуальность, делать запросы дополнительной информации. Мы получаем информацию на вход самыми разными способами: иногда это техническое задание, расписанное до полей баз данных, иногда макет интерфейса, иногда просто несколько слов вроде «реализовать возможность отображения списка заказов в ЛК пользователя». В техническом задании, сотворённом неопытным заказчиком, часто не хватает информации о целях и ограничениях системы, по макетам интерфейсов нельзя однозначно восстановить пользовательские сценарии и жизненные циклы объектов, изображённых на нём, а по необходимости отображать список заказов мы никак не можем понять в каких условиях пользователи будут работать с продуктом, какие у них роли.
Запрашивать дополнительную информацию об ограничениях, задавать дополнительные вопросы там, где в информации видны пробелы, проверять, когда создан тот или иной артефакт, насколько он актуален и какое отношение к нему имеет тот, кто будет принимать результат работ – необходимые первые шаги при проработке задачи.
Проявлять риски и ограничения. Про риски и ограничения я уже начала говорить в первых пунктах. У нас всегда есть риски, связанные с изменением заинтересованных сторон либо их точек зрения и пожеланий. Есть ограничения, связанные со временем выполнения задач, текущей архитектурой, используемыми инструментами. Есть регулирующая документация на уровне государства, отрасли, компании заказчика. Есть сильные и слабые стороны команды и личные предпочтения заказчика. И, конечно, неполные данные, на основе которых должны быть приняты решения об архитектуре, выборе определённых элементов интерфейса, выборе глубины проработки решения: проектирование устойчивой архитектуры или внедрение костыля.
По моему глубокому убеждению, задачей аналитика здесь является видеть риски и явно описывать ограничения. Аналитик работает с огромным количеством информации на разных уровнях абстракции и видит пробелы и нестыковки, которые не могут увидеть другие. Поднять вопрос об этих нестыковках – хорошая идея. В идеале, конечно, ещё объяснить к каким проблемам они могут привести, но это не всегда в рамках компетенций одного человека, часто нужна проработка с тем, кто отвечает за предоставление информации - заказчиком, руководителем проекта, архитектором, UX/UI-специалистом. Может оказаться, что в этом месте кроется что-то очевидное для заказчика, но невидимое для вас, и это может повлиять на выполнение многих смежных задач. В любом случае не стоит пытаться читать мысли и достраивать логические цепочки, лучше проговорить несоответствие явно.
Что касается ограничений – их тоже нужно выявлять очень тщательно, прежде чем бросаться что-то делать или менять, дотошно исследовать контекст: «Как это работает сейчас? Почему так?», «Что в этом хорошо, а что лучше изменить?», «Что ни в коем случае нельзя менять?», «Что мы не можем поменять в рамках текущих договорённостей?», «А можем мы сделать так?». Все эти вопросы должны предшествовать описанию и реализации какого-бы то ни было программного продукта.
Использовать широкий набор аналитических инструментов. И я не имею ввиду Jira, Confluence, MS Visio, draw.io, Visual Paradigm или Enterprise Architect. Я имею ввиду умение представлять информацию для работы и документирования в разных видах: текстовом, графическом, объяснять устно. Умение моделировать и писать сценарии не только по определённому шаблону, но и выбирать представление, наиболее подходящее для работы в данном конкретном случае, в данной конкретной команде.
Конечно, умение заполнять шаблон, принятый в этой компании – навык, который нельзя недооценивать, – особенно если шаблон актуален и регулярно пересматривается. При этом стоит понимать, что работающий шаблон — это не только набор полей, но и правила заполнения этих полей, и информация об этапах процесса, которые обеспечивают информацию для их заполнения.
Владеть широким инструментарием – это также постоянно использовать существующие инструменты, понимать их ограничения и дополнять ими друг-друга. Нужно описать взаимодействие пользователя с системой? Что лучше подойдёт: User Story в свободном стиле, структурированный Use Case, диаграмма последовательности UML, диаграмма деятельности UML? Это зависит от того, насколько сложная логика стоит за взаимодействием, насколько глубоко нужно погружаться в детали реализации в данный момент, с кем нужно согласовывать описываемое представление. Каждый инструмент применим и у каждого есть свои ограничения. Use Case отлично структурирован, но очень трудоёмок в описании, диаграмма последовательности отлично показывает точки взаимодействия, но отвратительно обходится со сложной логикой.
Для меня идеальный подход к проработке каждой задачи – использовать 2-3 инструмента, обязательно включающие текстовое и графическое представление информации. Это заставляет мозг работать в разных режимах и рассматривать разные аспекты, не теряя общей картины.
Рассматривать несколько решений, в том числе решение, что ничего не нужно делать. Часто, когда бизнес-заказчик приходит к нам с запросом, он чаще всего просит нас реализовать какое-то конкретное программное решение. Учитывая первые три пункта этой статьи, мы вполне можем увидеть, что это решение не единственное, и возможно даже не самое лучшее. В таком случае можно сделать две вещи: начать проверять решение на устойчивость и продумать несколько альтернативных решений.
Проверка решения на устойчивость – это мысленное моделирование ситуации, как решение поведёт себя в том или ином случае. Здесь можно задавать человеку, предлагающему решение, вопросы «А что, если так?», «А если пользователь поведёт себя так?», «А если станет недоступным источник данных?», «А если законодательство изменится?», «А если придёт в один день гораздо больше пользователей, чем вы ожидаете?». Все эти вопросы позволят автору решения самому лучше его продумать и вызовут гораздо меньше сопротивления, чем прямое указание на недостатки, видимые со стороны.
Если у нас слишком мало времени, либо мы слишком погружены в контекст, мы становимся зашоренными и не видим альтернативных вариантов. В таком случае можно намеренно поставить себе задачу проработать и предложить минимум три решения. Если фантазия не включается просто так, то можно пользоваться разными принципами, например, придумать три решения по устойчивости и трудоёмкости: 1) самое дешёвое, но которое точно нужно будет переделывать, 2) среднее по трудоёмкости, но требующее доработок в дальнейшем, 3) архитектурно-продуманное, но требующее значительных изменений в системе. Есть другой вариант генерации решений, который часто используют продавцы и руководители проектов – продумать решение, которое наиболее выгодно и интересно вам, как исполнителю, например, с точки зрения удобства реализации, поддержки и продолжения сотрудничества с бизнес-заказчиком. В дополнение к нему кратко набросать пару решений, показывающих возможные риски. Обычно в этом случае также предлагают все три решения, но одно, нужное вам, преподносится как бриллиант среди пустой породы.
Сначала рассматривать тривиальное решение. В постсоветском ИТ, похоже, развит психологический комплекс, вызванный прошлым, жадностью и засилием государственных денег в экономике, которые нужно просто освоить и отчитаться. Он проявляется в том, что если пришёл запрос что-то сделать за деньги, то нужно обязательно это сделать. Даже если это повредит бизнесу заказчика, испортит наш программный продукт и в разы усложнит его поддержку. Часто коллегам кажется, что если мы не согласимся на всё и сразу прямо сейчас, то в следующий раз нам не предложат работу.
В то же время, ситуация абсолютно аналогична ситуациям во других сферах жизни: вы ведь сами, вероятно, с большей охотой второй раз пойдёте к врачу (автомеханику, косметологу, нужное вписать), который не заставит вас после первого же приёма проходить огромное количество диагностики и дорогостоящих процедур. Бизнес-заказчик тоже ценит, когда ему предлагают не просто руки, но экспертизу, которой нет у него. Обязательно рассматривайте вместе с заказчиком достоинства и недостатки нулевого решения – решения ничего не делать. Задайте вопрос: «А что будет, если ничего не поменяется?». Это также поможет выявить риски и ограничения.
Что мешает всеобъемлющему подходу
Бывает, что аналитик уже больше года работает в компании, вроде бы уже мог изучить отрасль и продукт, интервьюировали его хорошо, про существование разных инструментов он знает, но риски и ограничения до сих пор не подсвечивает, и решения до сих пор предлагает однобокие, не учитывающие точки зрения бизнеса, пользователей или архитектора. Возможно проблема здесь не в конкретном аналитике, а в сложившейся практике работы в вашей команде.
Вот факторы, не способствующие широте мышления:
когда аналитик задаёт руководителю проекта, тим-лиду, заказчику вопросы, которые кажутся неочевидными, или ответить на которые не так просто, он слышит в ответ «Зачем это тебе?» или «Тебе это не надо.»,
почти половина задач, которые ставятся специалисту, нужно было сделать вчера,
аналитик выполняет слишком много ролей: бизнес-аналитик, UX/UI-инженер, тим-лид, технический писатель, системный аналитик и ещё подрабатывает за архитектора.
На проработку задачи «вширь и вглубь», полноценное рассмотрение проблемы, нужно время и досуг, как для занятия творчеством и философией. Под «досугом» я подразумеваю время, в которое можно просто обрабатывать в голове накопленную информацию. На одной из наших конференций мы пришли к выводу, что аналитику нужно минимум два часа в день «на подумать» без прерываний на вопросы от команды, переговоры и другие задачи. Если же аналитик участвует больше чем в трёх встречах – живых или онлайн – в день с большим составом людей, всё время занят разруливаем текущих ситуаций и должен быстро, как на конвейере, поставлять задачи в разработку, у него никогда не будет времени и внутреннего ресурса, чтобы прорабатывать свои задачи качественно с точки зрения анализа и проектирования, он – хотя в нашей стране в большой степени «она» – будет естественным образом брать первое очевидное решение и прорабатывать его системно, но больше на уровне реализации. Ситуация, когда мы пытаемся «прокачать» сотрудников вместо того, чтобы делать процесс более эффективным, чаще всего приводит к тому, что сотрудники обучаются и уходят, так как при текущей организации работы новые интересные навыки неприменимы. Поэтому прежде чем сетовать, что аналитики недорабатывают, сначала решите, что вы самом деле хотите от коллег: чтобы они быстро работали по устоявшемуся процессу, или чтобы они отрабатывали широкую картину, что может привести к очень непредсказуемым поворотам событий. Когда вам платят за человеко-часы, всестороннее рассмотрение задачи и поиск подводных камней не всегда является первичным приоритетом, гораздо выгоднее первый вариант. Если же у вас есть ограничения по времени и ресурсам, видение целой картины с самого начала, а потом и отслеживание изменений относительно первичной картины становится критичным для обеих сторон контракта. В этом случае не только аналитику, но и остальной команде, включая заказчика, придётся перестраивать свою работу, и существенно. Поэтому вы и ваше бизнес-руководство должно чётко понимать зачем это нужно, и явным образом внедрять это изменение.
Итого
Помимо исторически сложившейся организации работ в ИТ-компаниях и экономической ситуации, на возможность рассмотреть задачу целиком действуют как желание, так и навыки отдельного аналитика:
выявлять и анализировать вовлечённые в проект заинтересованные стороны как со стороны заказчика, так и со стороны исполнителя, учитывать их интересы,
моделировать, хотя бы в голове, жизненный цикл разрабатываемых продуктов, как минимум помнить, что нужно также осуществлять техническую поддержку и поддержкупользователей,
выяснять срок жизни и назначение разрабатываемого решения,
работать с большим количеством источников данных и иметь смелость запрашивать дополнительную информацию и задавать дополнительные вопросы,
выявлять и обсуждать видимые риски,
явно описывать ограничения: не только что и почему нужно делать, но и что и почему делать нельзя,
изучать, анализировать и использовать инструменты анализа, которые помогают посмотреть на ситуацию с разных точек зрения, учитывать их пределы применения: непосредственно присущие инструменту, и налагаемые контекстом работы,
использовать 2-3 инструмента для решения любой задачи – минимально, написать пару строк и набросать схему от руки на бумажке (графическом планшете, в онлайн-моделлере, встроенном в Confluence плагине, нужное вписать),
рассматривать первое пришедшее в голову, или полученное от заказчика, решение в перспективе того, что может случиться в будущем,
разрабатывать вместе с командой и предлагать заказчику несколько альтернативных решений на выбор, даже если вы уже уверены, что знаете как лучше,
Рассматривать тривиальное решение – что будет, если ничего не делать?
Список получился большой, глаза разбегаются, и на первый взгляд непонятно с чего начинать, и когда всё это успевать. В то же время я уверена, что большинство людей, хотя бы год поработавшие аналитиками или в других ролях, требующих плотного взаимодействия с людьми, уже наработали значительную часть этих навыков. К тому же эти пункты не просто дополняют друг-друга, но в процессе решения одной из этих задач, автоматически получается информация для решения другой.
Даже если процесс в вашей команде не препятствует полноценной работе аналитика, не стоит пытаться внедрить все эти навыки одновременно. Как при любом формировании хороших привычек, нужно брать их по одному, и планомерно вводить в работу, начиная с одной, самой привлекательной и необременительной для вас. Если выбрать с чего начать всё ещё сложно, можно просто начать с конца списка – рассмотреть тривиальное решение, то есть продумать что будет, если вы не внедрите разрабатываемое сейчас решение.
И для того, чтобы начать нарабатывать у себя и коллег новый подход, не обязательно ждать какого-то нового большого проекта, можно применять их к любой текущей задаче: пришедшему запросу на изменение от заказчика, эпику или User Story в Jira, разработке нового макета интерфейса.