Привет =) На связи снова Анастасия-аналитик из команды STM Labs со своей любимой темой «мягких» навыков. В статье про собеседования (первая часть тут, вторая тут) я сравнила аналитика с переводчиком с бизнесового языка на разработческий. Или наоборот.

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

И уже рассказывая вам предысторию, мне придется использовать весь свой переводческий талант, так как изложить вам задачу as is у меня нет шансов. Ну, вы понимаете, в чем дело:

Дисклеймер: если кто-то из читающих текст ниже вспомнит задачу и увидит в ней упоминание себя, то приветики!:D всё анонимно, имена изменены, любое совпадение событий с реальностью совершенно случайно.

Предыстория

Спойлер для тех, кому лень ее читать:

Замечено, что короткие статьи набирают больше лайков и просмотров. Поэтому если вам лень читать предысторию, держите супер-краткое summary.

Нам нужно было в объекты массива в JSON’е в базе данных просеттить определенный параметр. Но мы лопушнились и запульнули его не туда (в подобъект объекта, а не в корень). Делали задачу в силу многих причин долго и дотошно — и вот, после месяцев напряженной работы мне предстояло сообщить окружающим меня людям, что мы – хлебушки. Но у этих людей был абсолютно разный технический бэкграунд, а у некоторых его и вовсе не было…

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

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

За годы жизни система накопила информацию о более чем 26 миллиардах котиков. И теперь зоозащитники хотят с ее помощью проверять, что у котиков все хорошо.

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

При проектировании аналитического кластера его команда посчитала, что котик без цвета существовать не может. Но ведь котики без цвета у нас в базе есть…

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

Зоозащитники недовольны и хотят видеть весь объем информации.

Перед нами (командой разработки ядра бизнес-логики системы) встала задача проставить ~50 миллионам записей в базе уточнение, какого цвета был котик.

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

Проверяем 50 миллионов записей, отсеиваем часть, которой проставить ничего не можем, и у нас остается примерно 40 миллионов котиков.

Техническая вставка. История жизни животного представляет собой JSON, внутри которого есть массив с объектами — теми самыми событиями истории. В событии истории есть базовые атрибуты в корне JSON – это самые важные параметры, накапливающиеся по ходу истории, и объект «свойства», который по структуре идентичен у всех событий истории одинакового типа (пример типа события — рождение котика).

Итак, у нас есть котики с историей жизни, и нам надо в каждое событие истории вставить цвет ушастого. История имеет следующую структуру:

Не удержалась, простите. А теперь более серьезно:

{
	“id_котика”: “adb7a06d-8991-4221-8f54-11403600b412”,
	“история_жизни_котика”: [
		{
			“id_события”: “368f99e7-bb52-4ce3-91e0-2644c6a3064c”,
			“свойства”: {...},
			“вес”: 1500,
			“длина_хвоста”: 200,
			“дата_рождения”: “2020-01-07”,
    		...
        },
        {...},
        ...
      ]
}

В постановку задачи пишем буквально следующее: «в каждое событие истории жизни котика (каждый объект в массиве "история_жизни_котика") проставить атрибут "colour"» + добавляем, откуда же этот colour достать для каждого конкретного животного.

Выдыхаем и отдаем в разработку.

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

Девопс прогоняет миграцию, мы рапортуем в аналитический кластер, что все готово, можно переливать данные. Аналитик данных занимается переливкой и смотрит на результаты…

А результаты-то странные. Слишком большое количество котиков на стороне аналитического кластера осталось без цвета. При этом у нас самих тоже есть отдельная БД для целей аналитики, куда заодно шла переливка — и там цвет есть.

Мистика.

Забираю на анализ всех котов без цвета.

В процессе анализа понимаю, что… Что цвет стоит не в корне события истории, а в объекте «свойства». А этого аналитический кластер ну никак не ожидает. Да и как цвет встал в нужное место в нашей внутренней аналитической БД о – тоже та еще загадошная загадка.

Посредством n-го количества диалогов удалось восстановить цепочку событий, которая привела нас к итоговой ситуации. В ней был и miscommunication (простите, я не смогла подобрать удачный русский аналог), и подстановка в код внезапных костылей (т.к. подумалось, что передается все «ну как получилось сделать», и надо понять, простить и подстроиться), и еще много интересного. Полное описание причин и следствий приводить не буду по этическим соображениям.

Еще надо добавить, что задача была весьма долгоиграющей — один только этап сбора данных занял около месяца. Потом ещё разработка, тестирование, прогон в периоды наименьшей нагрузки на БД, переливка… На всё про всё ушло месяца 3-4. А в итоге мы – хлебушки.

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

Переходим к тому, ради чего все это писалось…

Из чего же, из чего же, из чего же сделана презентация информации

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

Что я имею в виду: раньше программист был и аналитиком, и тестировщиком, и девопсом, и UI/UX дизайнером в одном лице. А сейчас это абсолютно разные специальности. Хорош или плох путь повышения сегментации цепочки разработки, мы сейчас обсуждать не будем, это интересная тема для отдельной статьи. А пока просто признаем, что имеем то, что имеем. Разнообразные специальности появлялись не просто так, а под конкретные задачи.

Но так или иначе, все эти разношерстные специалисты должны как-то друг с другом договариваться. И я считаю, что связующим звеном в этом случае выступает аналитик. Он должен уметь поставить себя на место каждого специалиста (дизайнера, разработчика, тестировщика, etc) и объяснить ему задачу индивидуально, так, чтобы она была понятна. Хотя по идее задача одна, говорить про неё мы будем разными словами.

Задумалась я об этом, когда попала в разработку нового проекта с абсолютного нуля. То есть когда не было никакого контекста, и надо было создать его полностью из ничего. Здесь я и осознала, что для UI/UX-специалиста главное – ценность для пользователя, для Frontend-разработчика – реализуемость фантазий дизайнера в рамках выбранного фреймворка, для Backend’ера – совместимость стараний двух предыдущих специалистов с моделью данных. А для менеджера проекта – обоснованность принятой от заказчика фичи и оптимизация ее стоимости. И с каждым из этих людей мне надо обсуждать одну и ту же задачу, но с разных углов. Тут-то и понимаешь, что даже в рамках родного языка существует энное количество профессионально-деформационных диалектов :D

А еще дома вас могут ждать люди, далекие от IT. И им тоже интересно, что же аналитик за зверь такой, и что вы вообще на работе делаете.

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

А теперь по делу

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

1.       Зона ответственности

За что отвечает человек, с которым вы разговариваете? За процессы, за взаимодействие с внешним заказчиком, за команду разработки? И так далее. Чем лучше вы понимаете зону ответственности человека, тем проще вам будет представить, что ему важно в рамках задачи, а что не очень.

Если зона ответственности вам пока ясна смутно, то лучше, конечно же, напрямую спросить про нее. Если же по каким-то причинам такой вопрос задать невозможно, рекомендую подумать о следующих моментах:

• Какая роль у этого человека в команде?

• Этот человек/роль больше про бизнес или про технику?

• Этот человек/роль больше про процесс или про результат?

• Для урегулирования какого рода вопросов вы обычно обращаетесь к этому человеку?

• Что обычно он спрашивал вас о задачах, когда приходил к вам?

Ставлю «/роль» на случай, если вам прежде не доводилось взаимодействовать с этим коллегой. Выяснить роль обычно достаточно просто — например, можно подсмотреть на каком-нибудь корпоративном портале. После этого уже можно почитать/логически предположить, что может быть важно и интересно для человека с такой ролью.

2.       Насколько человек уже погружен в контекст задачи

Он слышал про задачу только то, что она в принципе существует? А может быть, вы с ним каждую неделю обсуждаете промежуточные результаты? От этого напрямую зависит, как быстро человек сможет понять, о чем вы говорите, и насколько связным может быть ваш рассказ. К примеру, разработчик, который писал код по вашей задаче, скорее всего сможет понять вас с полуслова. 

3.       Насколько человек загружен

Конечно, вы никогда не догадаетесь, сколько открытых задач у человека в настоящий момент. Но здесь тоже можно попробовать идти от роли: логично, что менеджер высшего звена, у которого по 15 встреч в 8-часовом рабочем дне, имеет меньше времени на одного конкретного человека, чем кто-то, у кого зона ответственности поменьше. А еще можно подсмотреть в календарь, чтобы оценить загруженность коллеги :) От загруженности зависит, сколько времени у вас будет на общение. Зная, сколько у вас времени и какую информацию надо уложить в эти минуты, вы сможете корректнее расставить ударения по всей презентации.

4.       Тип мышления

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

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

Возвращаемся к котикам

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

Руководитель департамента разработки

Не могу не пошутить про его время:

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

Мой вариант презентации:

«Ваня, мы прое... капитально лопушнулись! Цвет котиков в рамках JSON’а проставили не в корень, а в "свойства", аналитический кластер не ожидает этот параметр на уровне "свойств". Наша же аналитическая БД все записала корректно, потому что в коде поставили специальный костыль. Есть два варианта решения, оба предполагают прогон миграции заново. В первом варианте удаляем цвет оттуда, где его быть не должно, и проставляем везде в корень JSON’а. Во втором – оставляем цвет в "свойствах" и добавляем в корне. Первый вариант чище с точки зрения данных, но есть опасения, как бы чего лишнего не сотворить. По срокам оба варианта примерно одинаковы».

Почему именно так:

1.  Кратко суммирую в одном предложении итог анализа, почему все пошло не так. Да, немного эмоционально, зато максимально доходчиво с первой же минуты разговора.

2. С некоторой долей техничности добавляю детали. Поскольку Ваня в курсе и про пресловутые «свойства», и про структуру истории жизни котика, имею право. Плюс можно заметить, что я сразу перехожу к проблеме, потому что человек погружен в контекст и явно ждет от меня рассказ по конкретной задаче.

3. Поскольку человеку важен результат, сразу предлагаю пути решения и свои опасения насчет возможных рисков. Не размусоливаю, что, как, почему и кто виноват, потому что конкретно Ване важно достижение результата. Обозначаю сроки, т.к. они максимально важны для роли Ивана.

P.S. Про правых и виноватых все-таки тоже поговорили, как раз потому что Ивана в числе прочего касаются процессы между людьми.

Архитектор команды разработки бизнес-логики

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

Моя презентация:

«Алексей, у нас проблема с задачей про цвет котиков. Цвет проставили в "свойства", а аналитический кластер ждет его в корне JSON’а. Мы с Костей (встретите его ниже) всё проверили, сделали то-то и то-то, в аналитический кластер цвет действительно не доходит. Вышло это *перечисляю, что, как и почему*. Есть два варианта решения: *рассказываю решения аналогично написанному выше*. Ваня (тот самый руководитель департамента разработки) предпочел бы первый вариант, но если ты полагаешь, что лучше второй, он тоже согласен».

Очень похоже на первую презентацию, но все же акценты несколько смещены:

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

2. Даю те же технические подробности. Человек максимально погружен в контекст, поэтому их достаточно.

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

4. Сразу рассказываю, где поехал процесс, потому что человек отвечает за команду.

5. Предлагаю решение, т.к. собеседнику тоже важен результат + даю вводные, полученные сверху, которые на это решение могут повлиять.

Девопс

Помогал тестированию, проводил миграцию, по сути – один из исполнителей по задаче, провел с ней ОЧЕНЬ много времени. Знает структуру данных и почему она так устроена. Доступен, как мне иногда кажется, 24/7, искренне ему сочувствую :(

К нему я пришла, чтобы подтвердить свои гипотезы о том, что данные не доедут. Для этого мне надо было пошалить с данными на продакшене, с чем и нужна была его помощь. Ну и еще поорать чаечкой — я знала, что он включится в обсуждение про «кто виноват», потому что задача выпила у него много крови в части тестирования.

Моя презентация (проходила примерно в 21 по московскому времени):

«Кость (вот вы его и встретили), прикинь чего: смотрю я на эти цвета котиков, а они не в корне, а в "свойствах"! Ну понятно, что не доехали они до аналитического кластера, но как, КАК они там оказались? Цепочка из кучи человек же вокруг задачи была! Слушай, а помоги, пожалуйста, вот это проверить, чтобы я точно была уверена, что не ошиблась».

Самоанализ:

1. Я – живой человек, и мне жизненно необходима была поддержка в моем разочаровании после факапа на 4х-месячной задаче. И наш девопс мог меня понять как никто другой. Поэтому в первом же предложении много эмоций.

2. При фразе «цвета котиков», мне кажется, у Кости к тому моменту начинал дергаться глаз :) Поэтому уточнять, что это за задача, было излишне.

3. Знает структуру данных, могу не детализировать, что там за корень и «свойства». Знает, почему это не доедет до кластера, поэтому детали также не нужны.

4. Побугуртить, конечно, хочется подольше, но на часах уже ночь, поэтому максимально быстро перехожу к тому, зачем же я человека тревожу.

P.S. После того как я выяснила всю цепочку событий, которые привели к факапу, мы еще совместно побухтели и на эту тему :)

Лид аналитики

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

Моя презентация:

«Есть новости по задаче с цветом котиков. В общем, в таком виде, как сделано сейчас, данные до аналитического кластера не доедут. Если помнишь, в истории жизни котика в каждом событии есть "свойства" и базовые параметры в корне JSON. Вот, цвет сложили в "свойства". А аналитический кластер берет его из корня. При обогащении событий истории не предусмотрено взятие параметра из "свойств". Наша аналитическая БД параметр восприняла, т.к. там сделали костыль "нет в корне — возьми из свойств". Я посмотрела в свою постановку, там ни слова про "свойства", но и написано, как выходит, двояко: "проставить параметр в каждое событие истории". Видимо, стоит писать более ясно, я исправлюсь. Решение, как все поправить, приняли, поступим так-то и так-то. До Вани дошла, рассказала. Команде разработки корректировки по задаче описала».

Разбираем:

1. Конкретизирую, о какой задаче буду говорить. Во втором предложении обозначаю подытог на текущий момент.

2. Рассказываю, почему все работает именно так, чуть более детально, чем лидам, перечисленным выше. Потому что есть время и потому что это для Ани более актуально — ей важно быть в курсе технических процессов и нюансов по всей системе. 3. Так как я – аналитик, я рассказываю, что в моей постановке было не так и какие выводы я из этого сделала. Чтобы Аня поняла, где потенциально может быть пробел в процессах аналитики.

3. Уточняю, что задача не на стопе, всем понятно, что делать дальше, и что ответственные лица в курсе. Чтобы Аня понимала, что процесс идет, и в ее подключении нет необходимости.

Разработчик

Исполнитель по задаче, помнит, что делал по ней и как называются всякие параметры. Был на митинге с архитектором, новости слышал. Времени достаточно :)

Моя презентация:

«Исправляем косяк. Из "свойств" по всем событиям истории цвет удаляем, проставляем его в корень JSON’а. Нужна корректировка твоих скриптов, отдашь потом в тест, я предупрежу. Затем – на новую миграцию, Костя уже знает. Задача с более детальным описанием тут: *ссылка*. Все хорошо: главное, проблема понятна, работаем :) Если что, приходи с вопросами».

Что, как и почему:

1. Разработчик уже на утреннем митинге с архитектором слышал о проблеме. Поэтому сразу перехожу к делу.

2. Кратко сообщаю решение. Более детальную инфу отдаем в задаче, которую я уже сформировала и которая доступна по ссылке.

3. Сообщаю, что все процессы по организации доработки уже запущены, сигнализируя, что разработчик может сконцентрироваться на задаче.

4. Говорю хорошести на случай, если есть переживания из-за косяка :)

Тестировщик

Еще один исполнитель по задаче, так же, как и разработчик, все про нее помнит. К моменту моего прихода новостей еще не слышал. Времени достаточно.

Моя презентация:

«Привет, мы тут переделываем скрипты по задаче с цветом котиков. Надо будет перетестить. Суть в чем: параметр проставили не туда, куда ожидалось. Нужно было не в "свойства", а в корень JSON, аналитическому кластеру нужен параметр в корне. Все причины и следствия уже выяснили, произошло то-то и то-то. Решение: удаляем везде параметр из "свойств", проставляем в корень, задача на разработку вот тут. Все ответственные в курсе, всё в порядке, работаем-исправляем :)»

Разбор:

1. Собственно, сама новость и ради чего я пришла.

2. Суть проблемы, т.к. человек про нее еще совсем не знает.

3. Что же произошло, так как тут точно будет простой человеческий интерес.

4. Краткая презентация решения, ссылка на подробности.

5. И тоже немного хорошестей :)

Аналитический кластер

Находятся вне команды разработки нашей котиковой системы. Просто ждут от нас корректных данных и итогов моего разбора.

Моя презентация:

«Ребят, не туда цвет проставили. Как исправить понятно, как все будет готово – предупредим и снова перельем. Примерная дата готовности – неделя, но еще раз приду, когда закончим. И если будет перенос сроков, тоже приду».

Почему так:

1. Ребятам не особо интересны наши причинно-следственные связи, они ждут корректных данных. Пришла к ним, обозначила, что ошиблись в простановке (без деталей), уже чиним, ориентировочный срок такой-то.

2. Оговорюсь также, что тут не нужны были какие-то извинения и пояснения по виноватым. Коллегам это совсем не интересно.

Мама (внезапно, да?:) )

Как она вообще тут оказалась: я проводила анализ ситуации, когда была у нее в гостях. А мама всегда остается мамой — она моментально заметила, что я напряглась и резко перешла в режим «тотально занята», да еще и ругаюсь, аки сапожник. Не знаю, как ваши мамы, а моя пугается немного, когда у дочери что-то идет не так))

Моя презентация:

«Ну, ты же помнишь, что у нас там это, котики, истории их жизни и прочее. В общем, надо было нам цвет котиков сохранить, а мы ошиблись и сохранили не туда. Пришлось так резко проверять, поскольку задача важная, на нее ушло много времени разных специалистов. А я напряглась, что мы все, как лопушки, пропустили такую ерунду. В общем, теперь надо переделать, но все уже понятно, надо просто поработать».

Последний разбор:

1. На всякий напоминание, что же мы там такое у себя в системе творим.

2. Мама моя вообще не про IT. Поэтому никаких терминов типа «JSON». Про схемы данных она тоже не в курсе. Так что объясняю максимально человеческими словами: «цвет котиков» и «сохранили не туда».

3. Мама переживает за меня, а не за какие-то там задачи. Поэтому объясняю, чего это я подорвалась и побухтела. В конце успокаиваю маму, говорю, что все хорошо, мир не рухнул, никого не уволили)

Вот и все :)

Выводы

На самом деле, думаю, что выводы достаточно просты:

1. Рассказывая про задачу, встаньте на место того, кому вы про нее рассказываете. Что ему важнее всего знать, сколько у него времени и так далее. Это поможет быстрее достичь понимания. Эффективная коммуникация, все дела :)

2. Не будьте как я, и, если параметр должен быть в корне JSON, так и пишите: «в корне» :D

Спасибо, что дочитали, надеюсь, было интересно :)