Об этой части: иногда, когда мы берем в работу задачу, мы еще не в курсе, что за ней стоит. Даже не скажу, что мы видим только вершину айсберга, — мы видим только его очертания вдали. А нам нужно подплыть к нему по соленой воде, не быть унесенными морскими течениями и не напоровшись на его части, скрытые под водой. В этой статье попробую сконструировать эхолот, который в этом помогает.
В предыдущей статье я рассказывала, почему важно уметь и хотеть задавать вопросы тому, кто попросил вас что-то сделать, надеюсь мне удалось показать на примерах, что уточнение ожиданий заказчика — так я буду называть любого, кто ставит задачу или обращается к вам с просьбой — не необязательное занудство, а необходимый инструмент, который сможет значительно сохранить нам всем время и нервы. Того, кто берет задачу в работу для выработки комплексного решения, позволяющего принести ценность заказчику — т. е. нас с вами — я буду называть экспертом.
Я считаю что в ИТ две определяющих сущности - это информация и люди. Я очень люблю и хорошо умею работать с информацией и чуть меньше люблю и чуть хуже умею работать с людьми. Информация - плоть и кровь нашей работы, но только люди придают ей настоящее значение, и превращают в применимое знание. А значимость знания я даже не готова обсуждать, настолько для меня это непреходящая ценность.
Я часто слышала от руководителей в DataArt, что мы сразу должны предложить заказчику решение или набор решений, чтобы показать что он пришел к настоящим экспертам, способным выстроить любое технологическое решение. Не могу сказать что я с этим абсолютно согласна. Да, показать заказчику несколько способов решения его задачи — обязательный шаг выстраивания работы, но первый ли? Если вы сразу говорите и ведете себя так, как будто точно знаете что делать, это, с одной стороны вызывает уважение к вашему профессионализму и умению решить практически любую задачу, с другой — не показывает ваше желание помочь именно этому человеку с именно его проблемой. Слыша, что есть готовые решения, человек чувствует что его задача стандартна, контролируемо решаема, и у него возникает желание сбросить инициативу на вас — исполнителя. И, с одной стороны, это прекрасно, заказчик не будет мешать нам делать нашу любимую работу, с другой — огромный риск: он не понимает необходимость своей вовлеченности, и, скорее всего, не примет результат вашей совместной работы как свой, не будет готов выступать его адвокатом. Так как мы занимаемся разработкой программных решений на заказ, невовлеченность заказчика в процесс создания ПО становится одной из самых больших проблем.
4 вопроса для бизнес-аналитика перед началом работ
Итак, возвращаемся к нашему айсбергу и попробуем соорудить эхолот. Я предлагаю сконструировать его из четырех блоков вопросов, касающихся:
- Текущего состояния работы.
- Удовлетворенности текущим состоянием.
- Согласованностью используемого словаря.
- Выяснением, кто еще вовлечен в процесс.
Допустим, пришел к вам приятель с просьбой помочь в переезде, родственник с просьбой помочь устроиться на работу, руководитель с поручением подготовить информацию для отчета, HR-специалист с просьбой проинтервьюировать кандидата. Представьте себе, что вы находитесь в первом диалоге с человеком, который пришел к вам за помощью.
Первыми вопросами чаще всего будет «когда?» и «где?», хотя про это, скорее всего, расскажут и так, а важный вопрос, который я бы рекомендовала задавать, — «откуда мы движемся?».
Вопрос 1. Текущее состояние
У того, кто обратился к вам с просьбой, есть свой опыт и ожидания от процесса и результата выполнения задачи, о которых вы часто не знаете. Если вас попросили помочь с переездом, это может быть просьба предоставить вашу машину, а может, машина есть, но нужно носить вещи на четвертый этаж. Интервью может быть в ваш проект, а может быть по вашей специальности, но для людей, чьих ожиданий вы не знаете.
Как это делается сейчас?
В новой для вас команде, скорее всего, есть правила выполнения работы, аналогичной той, которую вам предстоит выполнять, в командах часто есть стандартные подходы к проектированию интерфейса или API, привычные форматы описания требований, а заказчик привыкает получать отчетность в конкретном формате.
Когда мы приходим на новое место работы, чаще всего ждем, что нам расскажут, как здесь все устроено и по каким правилам получать пропуск в офис или как согласовывать отпуск. Приходя в гости и желая помыть руки, кажется вполне логичным спросить где это можно сделать и каким полотенцем можно вытереть руки. И в том, и в другом случае вам даже расскажут об этом до того, как у вас этот вопрос возникнет: у хозяина ситуации есть интерес, чтобы на его территории сохранялся выстроенный им порядок. В то же время, когда вы приходите в конкретную команду, ее привычки могут оказаться неожиданными: где-то принято договариваться об отпуске за несколько месяцев, а где-то достаточно закинуть запрос на отпуск в PM, где-то принято договариваться о встречах за день-два, а где-то достаточно закинуть созвон на любой свободный в календаре слот в течение дня. И об этом не то чтобы не хотят рассказывать, просто в повседневной жизни команды этот так естественно, что вы узнаете об этом, только когда вас не смогут вызвонить на очередной созвон, потому что вы отошли попить кофе.
Также и в работе с заказчиком: мы приходим чтобы дописывать существующую систему, которая поддерживает рабочий процесс. И этот процесс сейчас работает! Да, пусть он иногда выглядит неказисто, но тому есть свои причины: он завязан на смежные процессы и на конкретных людей, которые в нем участвуют.
С одной стороны, поручая работу (беря в проект) опытному специалисту, заказчик ждет, что в работе что-то качественно поменяется — не всегда осознавая, что именно — но при этом какое-то рабочее ядро должно остаться неизменным. И при том оно кажется ему очевидным и не требующим озвучивания. Поэтому вопрос «а как вы делаете это сейчас?» далеко не лишний, чтобы своими действиями не нанести вреда заказчику, вместо того чтобы помочь решать его задачи.
Что уже сделано и кем?
Работая в большой компании, мы часто всего лишь одно из звеньев цепи создания ценности, причем, как я уже упоминала в предыдущей статье, мы зачастую плохо понимаем, как работают предыдущий и следующий этап: на них работают люди с принципиально другими компетенциями. Еще больше ситуацию усложняет, что при этом наши компетенции и сферы ответственности пересекаются. Прежде чем передать презентацию на оформление дизайнеру, заказчик уже взял какой-то шаблон слайдов и создал структуру в соответствии со своей идеей будущего рассказа. Руководитель проекта может спонтанно сформулировать кусок бизнес-требований, а проектировщик интерфейса без помощи аналитика описать пользовательские сценарии. Тимлид может в отсутствие опытного девопса сам спроектировать и настроить всю необходимую среду для разработки и тестирования.
Причем, так как все описанные задачи многофакторные, это не значит, что теперь дизайнеру, аналитику или девопсу, которые перенимают эстафету, нечего делать, или даже что его задача становится гораздо легче. Это лишь значит, что нужно уже учитывать существующий бэкграунд чтобы двигаться дальше. Дизайнеру нужно не только «поиграть шрифтами», но и понять, подходящий ли шаблон слайдов использован, и насколько может поменяться структура и количество контента, чтобы дизайн не пополз при масштабировании.
Руководитель проекта говорит что бизнес-требования такие и заказчик с ним согласен? Аналитику теперь нужно удостовериться, что формат, в котором эти требования написаны, понятен команде, и обеспечить трассировку с того, что написано для заказчика, на задачи команды.
Проектировщик интерфейсов уже подготовил набор пользовательских сценариев — аналитику нужно проверить их полноту, согласованность с бизнес-требованиями и организовать их согласование с представителями заказчика и командой.
Тим-лид выдал девопсу задание на построение рабочей инфраструктуры при наличии уже работающих стендов, но позже появились дополнительные требования к тестированию, например к нагрузочному, и среду нужно модифицировать и поддерживать.
Каждый эксперт на своем месте отвечает за комплексное решение своей задачи, и в то же время понимая, что он не первый человек в мире, которому поручили эту задачу, должен в первую очередь узнать, что уже сделано и кем. Это позволит не только не дублировать уже сделанную работу, но и избежать конфликтов при пересечении зон ответственности.
Когда приходишь в новую команду, перенимая работу ушедшего коллеги, потребность в этом вопросе еще более очевидно. С какой точки я начинаю работу? Кто делал это до меня? Доступен ли этот человек для передачи экспертизы по решению и выстроенному процессу? Ведь часто бывает, что человек уже не только ушел из проекта, но и уволился из компании, это тоже кратно увеличивает время онбординга и риски проекта.
Вопрос 2. Удовлетворенность текущим состоянием
Я дочь постсоветской инженерной семьи, а значит, мое отношение к науке и технике скорее позитивистское: я считаю что они призваны избавить нас от рутины, позволить нам заниматься более творческими задачами и вообще улучшить наше качество жизни. Хотя сейчас я понимаю, что мир гораздо сложнее, и далеко не всем нравится заниматься творческим абстрактным проектированием, в моей голове намертво засели цитаты из мультфильмов и фильмов моего детства: «Счастье — дело техники!» и «Вкалывают роботы — счастлив человек!» Напишите в комментариях, если понимаете, о чём я говорю.
Поэтому, встречаясь со случаем, когда интерфейс публичной системы настолько сложен, что для вноса в нее данных наняли аж двух человек, это заставляет волосы на моей голове шевелиться. Нанимать людей, чтобы компенсировать недостатки системы? Немыслимо! Это пример, как мой личный опыт и убеждения влияют на то, что я считаю важной проблемой, когда встречаюсь с конкретной ситуацией. Но является ли то же самое проблемой для заказчика, или ему нужна моя помощь в решении совсем других задач?
Что именно вы хотите изменить?
Любой эксперт, тем более эксперт в области IT, склонный к структурному мышлению, выстраиванию систем и оперированию фактами, поняв текущее состояние задачи, готов с места в карьер выдать пару-тройку критичных проблем в текущем положении дела и еще насыпать дюжину мелких рекомендаций, что можно улучшить. И это чаще всего ясно написано на наших лицах и вызывает проблемы в выстраивании отношений с заказчиками. В одном из проектов через день собирались созвоны по 10+ человек, включая представителей заказчика, чтобы обсудить пару не связанных между собой вопросов. Невероятная, безумная трата времени! О чем я не преминула сказать сразу после входа в проект. Но позже оказалось, что только так можно было дать понять владельцам перестраиваемой системы со стороны заказчика, что их команда контролируют ситуацию, и обеспечить передачу ими знаний из безопасной позиции. И вопрос становится, не как избавиться от этих созвонов, а как сделать их организацию как можно более эффективной с учетом растущей команды.
Я видела проблему в том, что оказалось несущей конструкцией проекта. Могла ли я знать об этом изначально? Нет. Могла ли я разобраться в ситуации, прежде чем начать высказывать суждения? Да.
Вот другой пример: ты смотришь на систему и видишь, что здесь должны вводиться данные очень строгого формата, но никаких ограничений с точки зрения вноса данных нет. А еще не предусмотрена связь между данными в разных полях одной формы, хотя по бизнес-логике она явно присутствует. Консистентность данных под угрозой! Но заказчик объясняет, что эту форму заполняет ровно один человек, который же и разрабатывал эту систему, поэтому за вводимые данные можно не волноваться, а вот дизайн формы надо переделать срочно в соответствии с новыми правилами разработки веб-интерфейса, принятыми в компании.
Чтобы сходу не бросаться решать проблемы, которые для заказчика не проблема (читай, он не готов тратить силы и деньги на изменение ситуации в этих областях), я научилась. прежде чем высказывать суждения и рекомендации, задавать вопросы, насколько заказчик доволен текущим состоянием дел. Что хотелось бы улучшить? Почему заказчик считает что здесь нужны изменения? И часто оказывается что видимая со стороны неэффективность процесса или костыль в решении оправданы объективными факторами и сделать с ними ничего нельзя, а решать нужно совсем другую задачу, влияющую совсем на другие процессы.
Задавая вопросы, что не устраивает в текущей ситуации, можно не просто понять, что для заказчика значимая проблема, а что — просто факт с которым он успешно сосуществует, но и выстроить приоритеты решения выявленных проблем.
Что сейчас работает хорошо?
Однако задать вопрос только о том, что не устраивает и нужно поменять, недостаточно, нужно также выяснить, что сейчас работает хорошо, и удостовериться что наше новое решение этого не испортит. Ответ на вопрос «а что сейчас работает хорошо и не хотелось бы менять?» позволяет узнать о часто повторяющихся процессах, привычках пользователей и критичных функциях, с которыми возможно раньше были проблемы, но теперь всё хорошо, все рады и — не дышите!
Например, сейчас, когда все работают с одним excel-файлом, любой руководитель может открыть файл в реальном времени и посмотреть отчет об актуальном состоянии дел, и есть страх, что при переходе на другую, пусть даже более продвинутую систему с гибким управлением правами доступа, такое формирование отчетов будет недоступно из коробки.
Такой вопрос позволит не только выполнить принцип «работает — не трогай», но и позволит заказчику слегка похвастаться тем, чем он гордится в своей работе. Заказчик очень ценит, когда вы проявляете искреннюю заинтересованность и желание понять ситуацию, в которой он находится.
Вопрос 3. Что означают те или иные термины?
Недавно один из коллег проводил вебинар про то, как справляться с синдромом самозванца. Одним из рецептов было «знать и использовать профессиональную терминологию». Знать и использовать профессиональную терминологию необходимо для эффективной работы в команде и профессионального развития, но при общении с заказчиком сначала хорошо бы удостовериться, что ваш vis-a-vis понимает эти термины и понимает их ровно также, как вы.
Простой пример из нашей повседневности: каждый, кто проработал в IT хотя бы полгода, слышал термин User Story, и 80 % из этих людей знают. что у User Story есть каноническая форма “As a <Role>...” В то же время, команды разработки, которые пользуются Jira для управления потоком задач, знают, что в Jira есть стандартный рабочий элемент (Work Item) с названием User Story, и то, что там пишется и в каком виде, может чуть более чем полностью отличаться от общепринятого понимания термина User Story, ибо никаких ограничений на формат заполнения нет, и используют этот элемент разные команды для очень разных целей.
Еще один пример разного понимания одного и того же термина: коллега, с которым я была знакома до этого уже более 5 лет и считала что наши понятия о терминах бизнес-анализа более или менее синхронизированы, попросил меня описать блок бизнес-процессов, обеспечиваемых системой, над которой он работал. Когда я принесла ему первый черновик BPMN-диаграммы, он оказался очень удивлен результатом, оказалось, он ожидал чего-то совсем другого. После еще пары итераций переговоров мы составили список функциональности системы, которая на тот момент не соответствовала потребностям ее владельцев, и этот результат удовлетворил всех. Какое отношение это имело к описанию бизнес-процессов? Практически никакого.
На что я сразу обращаю внимание и стараюсь прояснить в интерактивном режиме:
- Когда заказчик использует один и тот же термин или словосочетание несколько раз, наверняка это что-то важное, и доскональное понимание этого имеет ключевое значение в дальнейшей совместной работе.
- Когда используется совсем уж затертый термин, типи того же User Story, или SCRUM, или stakeholder.
Составлять словарь в первый же момент нет необходимости. Что именно многие люди понимают по-разному, а значит, какие термины требуют толкования именно для вашей команды, станет понятно позднее, после месяца-двух совместной работы.
Но, как минимум, стоит насторожиться, если такие термины используются собственно в постановке задачи, и переформулировать ее более конкретным образом.
Теперь, когда вы уже более-менее говорите на одном языке и заказчик уже достаточно рассказал о ситуации и своем отношении к ней, можно поспрашивать и про остальных потенциальных участников процесса.
Вопрос 4. Стейкхолдеры
Позвольте мне привести еще один пример из реальной жизни. Мне пришло в голову, что я могу написать книгу про то, как работает IT-отрасль и что ее отделяет в плане повседневных привычек от остального мира, моя подруга тоже в это время писала книгу и познакомила меня с маркетологом, которая помогает ей с выстраиванием стратегии написания и продвижения ее книги. Это оказалась достаточно приятная женщина, которая сначала поинтересовалась чем я занимаюсь, а потом огорошила меня вопросом: «Кто твоя целевая аудитория?» Этот вопрос меня смутил. Я подозреваю, что у маркетологов термин «целевая аудитория» считается таким же самоописывающимся, как «стейкхолдеры» в ИТ-проектах. Я надеялась, что она как маркетолог поможет сформулировать понятие об это самой целевой аудитории, а не мне придется подавать на вход информацию, на работе с которой она специализируется. Почувствовала ли я силу ее профессионализма и серьезность подхода? Безусловно. Захотелось ли мне заказать у нее платную консультацию? Нет, я почувствовала, что всю работу при сотрудничестве с этим специалистом мне все равно придется выполнять самой.
С другой стороны, не задать мне этот вопрос она тоже не могла, ведь ей же нужно иметь ориентиры, о ком вообще речь. Как я упомянула чуть выше, такие общие термины, как «стейкхолдер», требуют расшифровки в самом начале общения с заказчиком. Задавать вопросы о стейкхолдерах надо, и чем раньше, тем лучше, но привычную форму «а кто у нас стейкхолдеры» («а кто у нас тут такой хорошенький?») лучше заменить на набор более конкретных вопросов, на которые гораздо легче ответить:
Кто будет принимать решения о бюджете и составе работ?
Вместе с кем я буду работать над этой задачей?
С кем можно проконсультироваться по требованиям безопасности?
Кто будет пользоваться результатом работы?
Кто будет оценивать результат работы?
И только этого стоит блеснуть вопросом «а какие еще стейкхолдеры могут быть?».
Вероятность быстро получить ответы на такие сфокусированные вопросы гораздо выше, чем на вопрос с использованием максимально общего термина, который скорее вызовет у человека облако ассоциаций, чем заставить его выдавать вам нужную информацию.
Конечно, заказчик, будь то руководитель проекта, менеджер со стороны клиента, аналитик или тимлид, редко приходит на первую встречу, чтобы вы взяли у них интервью, планомерно задав все вопросы. Если заказчик захочет сначала поговорить, что, по его мнению вы должны сделать (а это бывает чаще, чем хотелось бы), нужно внимательно его выслушать, но все-таки улучить минуту и задать необходимые вопросы о контексте. Лучше всего, конечно, включить эту тему в план первой встречи. Но если не получилось в первый раз, обязательно задайте эти вопросы позже — лично или письменно.
Возможно, вам и не придется задавать все эти вопросы явно: когда задаешь один вопрос, это запускает в голове заказчика цепочку реакций, которая заставляет вспоминать все больше подробностей и деталей, и человек обычно начинает рассказывать их уже самостоятельно.
Резюме
Первый диалог — еще не время включать экспертизу на полную мощность, надо приготовиться перед прыжком и понаблюдать за движением косули: изучить как заказчик ориентируется в текущей ситуации. Тут нужно немного притормозить себя и понимать, что вопросы должны быть предельно конкретным и не повергать человека во фрустрацию, поэтому они должны быть открытыми, но не слишком широкими и без применения специализированной терминологии. Если вы вмешаетесь в процесс на этапе прояснения контекста, наводки вашего личного опыта и убеждений помешают вам по-настоящему помочь человеку. Если не вмешаетесь, вам откроются неожиданные драгоценности в личном и в профессиональном плане.
С одной стороны, в процессе знакомства нужно сотворить некую магию, но эта магия должна быть простой и открытой, как повседневный карточные фокусы или «левитирующие» на многих пешеходных улицах столиц маги. Мы просто задаем открытые и конкретные вопросы, которые помогают прояснить ситуацию и отношение человека к ней, с другой — выстраивать доверие и делать основные риски очевидными.
Поэтому стоит подходить к первому диалогу не с четким намерением найти решения сразу всех проблем, а с желанием понять как можно больше о ситуации до того, как вы нырнете в ее изменение, и намерением выстроить среду для совместного решения этой задачи.
Итак, ответы на какие вопросы нужно получить в том или ином виде:
- Как заказчик видит текущую ситуацию,
- Как это делается сейчас?
- Что уже сделано и кем?
- Как он относится к этой ситуации,
- Что именно вы хотите изменить?
- А что сейчас работает хорошо и не хотелось бы менять?
- Какие специфичные слова он для этого использует.
- Что именно вы имеете в виду, когда говорите «наша система»?
- Кто еще вовлечен в решение этой задачи.
- Кто будет принимать решения на о бюджете и составе работ?
- С кем можно проконсультироваться по требованиям безопасности?
- Кто будет пользоваться результатом работы?
- Кто будет оценивать результат работы?
Понятно, что это только примерные формулировки вопросов, и вы не только можете, но и должны модифицировать их под свою задачу, чтобы сделать еще более конкретными. Например, при просьбе подготовить отчет вопрос будет звучать не «что уже сделано и кем?», а «есть ли уже данные для отчета и у кого их можно взять?». Иногда удобнее не задать вопрос, а проверить самому: порой в систему просят добавить новую функциональность, а фактически можно найти уже написанный и закоментированный код, делающий примерно то же самое, но это потребует времени. А при запросе заказчика автоматизировать какой-то процесс вопрос «что не хотелось бы менять?» будет звучать скорее «какие области деятельности не должна затронуть новая автоматизация.
Иногда человек приходит по адресу, иногда вообще непонятно, какое отношение его проблема имеет к вам. В любом случае, не помешает задать такой набор вопросов. В лучшем случае, человек сам поймет, что обратился не к тому, в большинстве случаев вы сможете лучше понять, как решить задачу, в худшем — обзовет вас занудой, что будет для вас флажком: человек сам не знает, что ему нужно. Как разбираться, вы ли лучший кандидат для выполнения поставленной задачи, и говорить об этом с заказчиком, будет следующая статья.