Аналитик с опытом может быть новичком!

Сегодня думаю про адаптацию в новой команде. Участвую в подготовке курса для онбординга аналитиков, отсюда и #мысливслух.

Прием в новой компании и команде может оставлять впечатления очень надолго. У меня в прихожей прячется от дождя зонтик-трость с логотипом одной прекрасной компании. Мне там хорошо работалось и этот бесполезный остаток welcome-pack меня радует как старое семейное фото. К чему это я? ))

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

"Адаптация" не равно "развитие". Помнится, пару лет назад коллега в новой команде встретила меня словами "Так я же тебя знаю, твои вебинары смотрела!" (Аня, привет! 👋) Это было приятно, что никому не нужно ничего доказывать насчет развития. Не всегда так везет. Переход в новую команду бывает похож на изучение нового языка, когда человека считают глупым, потому что он неправильно называет аббревиатуры названий отделов. И вот уже бадди дружелюбно и очень навязчиво объясняет, что "дейли – это каждый день, а диаграмма - она из квадратиков". Наверное, в таких случаях тоже может эмоционально выручать какой-нибудь зонтик с логотипом какой-то прекрасной компании )))

Какие у вас мысли об онбординге? Как вас встречали в вашей нынешней команде?

#мысливслух

Нужно ли команде тратить время на ревью требований? (peer-to-peer review)

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

📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать ☺️
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.

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

Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут

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

#инструменты #кейс #что_почитать

Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
М. Хаммер, Л. Хершман. Год издания: 2010

Когда вы читаете все, что еще год назад сохранили списком в Notion или еще где-то? Я вспоминаю о своем списке, когда оказываюсь где-то в ожидании или в пути, в остальное время всегда находится что-то ужасно срочное или интересное ☺️

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

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

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

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

Полезно обобщение семи принципов проектирования:
• какие операции будут выполняться;
• будут ли они выполняться и при каких условиях;
• кто будет их выполнять;
• когда это будет происходить;
• где они будут выполняться;
• насколько точно они будут выполняться;
• какая информация будет при этом использоваться.

Глава о показателях эффективности. Мне понравился прием, с перечислением "грехов", которые могут привести к ошибкам в выборе системы показателей. Оставлю их здесь, а вы сами читайте в книге или предполагайте, как они влияют на выбор метрик процессов:
• тщеславие;
• самолюбование;
• лень;
• нежелание масштабно мыслить;
• бессмысленность;
• легкомыслие.

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

#книжки

Цундоку и статьи про стейкхолдеров

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

Разобрала материалы про заинтересованные стороны, делюсь

🌱Эффективное управление отношениями со стейкхолдерами Рассказ от самых основ терминологии, описание основных инструментов RACI, карта заинтересованных сторон, матрица влияние-интерес. Все неплохо, но если вы уже в теме, то можно заскучать.

🌱Бизнес-аналитик — мастер переговоров или как не сойти с ума, работая с требованиями Это рассказ BI-аналитика о том, с чем приходится сталкиваться при проектировании дашбордов. Уверена, что многие из нас не думали о дашбордах с точки зрения переговоров с заказчиками

🌱Работа с заинтересованными лицами на проекте Эта статья состоит из рецептов по взаимодействию с заинтересованными сторонами, я насчитала их 29. Мне понравился совет побольше общаться один на один, даже если заинтересованных несколько. Тоже часто применяю такой подход, потому что проще уточнить мнение человека, когда он свободен от влияния группового мышления, имеет возможность высказаться и быть выслушанным. Только для этого вам нужно время и умение слушать и слышать.

🎥Что и как спросить у бизнеса, чтобы проработать ИТ-решение Давний стрим с весьма честными рассуждениями об отношениях между ИТ и бизнесом, а еще с шаблонами того, чем следует поинтересоваться для успеха будущего ИТ-продукта. Слушать сложно, но и назвать бесполезным тоже сложно

🌱Цена термина "заказчик" не удержалась и добавила в подборку свое небольшое рассуждение о неполном понимание термина "заинтересованная сторона" и как оно влияет на сроки разработки продукта

🌱Кто такие «заинтересованные стороны» и в каком случае для бизнеса от них больше пользы, чем проблем? (на основе кейса) Это о заинтересованных с точки зрения маркетинга. Интересно перечислены ожидания разных сторон

#что_почитать

Повод больше общаться или ужас?

Как вы реагируете, когда видите реализацию сильно мимо вашей постановки или ТЗ? Я со временем прошла разные стадии: 1. ужас, я что-то неправильно сделала; 2. ужас, какие все ленивые, я-то все четко написала; 3. ужас, как люди разучились читать... Сейчас прихожу к точке зрения без слова "ужас"

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

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

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

Кроме вопросов мотивации, у читателей документа срабатывают те же механизмы когнитивных искажений, что свойственны всем нам. Отсекается то, что кажется неважным для задачи, теряется непонятное, насмотренность подсказывает какую-то интерпретацию "между строк"... Вот тут на Хабре еще одно мнение о том как получается результат не по ТЗ. Если коротко, то просто люди устают читать для них неважное и забивают на детали 🤷‍♀️

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

#мысливслух

Не будет второго шанса произвести первое впечатление

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

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

Кто участвует в найме, наверное, начинает сочувствовать своему учителю литературы. Учителю приходилось десятки раз в день читать про "луч света в темном царстве" или что мы там еще списывали друг у друга и у Добролюбова? Проверьте, на всякий случай нет ли у вас в резюме фразы "аналитический склад ума, ответственность и внимание к деталям"? Это клише содержится в таком количестве резюме, что ни одно из них уже не украсит. Особенно в сочетании с опечатками. Даже если у кандидата и правда аналитический склад ума 😎

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

📍кандидат сообщает, что три года работает в индустрии и знает Githab (Видимо, это Github)

📍работал с гибридной распределенной базой данных (Кafka) (Kafka меньше всего можно назвать базой данных)

📍интересуюсь Phyton (Лучше интересоваться Python)

📍Gif (система контроля версий) (Видимо, это про Git)

📍нотация описания процессов UML (UML- это универсальный язык моделирования, а не нотация для описания процессов)

📍BPMN-система (Системы управления процессами – это BPMS, BPMN – это обозначение нотации)

#мысливслух #карьера

Вкрученный гвоздь или вбитый шуруп?

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

🔅Встретила на днях мнение "бизнес-требование – это старо и не модно". При таком подходе получается, что выбор инструмента или классификации требований зависит не от решаемой проблемы, а от предвзятой установки. Скажем, теорема Пифагора сформулирована более двух тысяч лет назад. Станет ли сумма квадратов катетов равняться чему-то новому, если мы назовем теорему старой или наоборот начнем цитировать на древнегреческом?

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

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

🔅Встречаю мнения и в другую сторону. В чате одной уважаемой конференции недавно наблюдала дискуссию: "Детальное ТЗ гораздо лучше пользовательских историй". Тут уместен вопрос: "Для чего лучше?" Речь идет о разных инструментах, которые применяются для разных задач. Попытки подменить одно другим порождает примеры вида "Вкрученный гвоздь держался хуже, чем вбитый шуруп".

ТЗ может быть необходимо, если задача требует предварительного детального проектирования, а в основе лежат правила, которые редко меняются. Сложно представить себе историю: "Я, как пассажир самолета, хочу, чтобы он летел" 🤷‍♀️

Пользовательская история пригодится, если нужно верхнеуровнево зафиксировать ожидания от бизнес-приложения. В моем опыте была когда-то такая задача. Требовалась информация для предварительной оценки затрат на разработку нового приложения. Решение о разработке нужно было принять за 2-3 дня. В итоге за две большие встречи с заказчиками собрали карту историй. По этой карте была дана предварительная оценка. Для разработки приложения такой подход не годится, а для первых оценок этого оказалось вполне достаточно. Причем я не возьмусь утверждать, что это был единственно возможный вариант решения такой задачи.


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


В дополнение делюсь списком книг, которые помогут развить критическое мышление. Некоторые принесла с тренинга по решению проблем (problem solving) и сама еще не читала ☺️
📍"Шум. Несовершенство человеческих суждений", Даниэль Канеман, Оливье Сибони, Касс Р. Санстейн, 2021
📍"Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач", Итан Расиел, 2012 (есть обзор)
📍"Думай медленно...Решай быстро", Даниэль Канеман, 2011
📍"Решение проблем по методикам спецслужб. 14 мощных инструментов", Джонс Морган, 1998
📍"Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем", Джозеф О'Коннор, Иан Макдермотт, 1997

#мысливслух