Путь аналитика. Analyst's journey

Всем привет!

Есть промокод со скидкой 10% на посещение Winter Analytical Weekend (Химки, Московская область)
Даты: 22 и 23 февраля (выходные)
Детали и программа
Место: отель GoPark

Основные темы конференции - это будущее профессии с учетом AI и управленческие топики в области анализа.

Мне самой интересно все что касается перспектив AI. Среди спикеров лидеры мнений ИТ. Ожидаю, чтобы будут интересные беседы и новые мысли. Пойду послушать.

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

Чтобы воспользоваться скидкой, свяжитесь с организаторами конференции (в будни 9:00-18:00, мск):
- 8-800-6000-868,
- [email protected]
- @lafestru

======
I decided not to translate the post into English, as it is dedicated to the conference in Russia. The conference does not have an online format. Let me know, if you are interested in.

Выжимка по книге Кови"7 навыков высокоэффективных людей"

Нашла тут на днях роудмап по книге Кови "7 навыков высокоэффективных людей". Кто сколько насчитал у себя? У меня - 4, остальные so-so.


A roadmap of Covey's book "7 Habits of Highly Effective People"

I found a roadmap on Covey's book "The 7 Habits of Highly Effective People" the other day. Who counted how many of them? I have 4, the others are so-so.

#probooks

Фраза недели:
В мире есть 10 категорий людей – те, кто знают про двоичное счисление и те кто нет.

Phrase of the week:
There are 10 categories of people in the world - those who know about binary numbering and those who don't.

"Про переговорную позицию"

Участвуя в переговорах или разбирая ситуации в формате менторства, я отмечаю, что часто народ выходит на переговоры в лучшем случае имея лучшее для себя решение. Чаще - без переговорной позиции.

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

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

Хорошая практикая готовить переговорную позицию по следующим пунктам:
- мой лучший исход диалога (BATNA)
- худший возможный исход диалога (WATNA)
- зона возможных для меня соглашений (ZOPA)
- аргументы: от сильных до слабых

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


"About Negotiating Position"

I often notice during negotiations and mentor meetings that people come to the table without a negotiation position. Less often they have their best solution. The absence of a negotiation position equals a weak position. If there is only the best solution, it may be broken during discussions, or it may lead negotiations into a dead end.

At the same time, negotiations are a routine of an analyst's life. It is discussing project boundaries with the customer, dividing features with other team, negotiating conditions with the manager, and etc.

It is good practice to prepare a negotiating position on the following points:
- my best alternative to the negotiated agreement (BATNA)
- my worst alternative to the negotiated agreement (WATNA)
- zone of possible agreements (ZOPA)
- arguments (strong to weak)

I prefer using spreadsheets. So I usually keep an Excel file with this outline. By adding meeting summaries to the table, it also helps accumulate material for retrospectives.

Шпаргалка по нормализации

Народ, кто хорошо помнит хотя бы первые 3 нормальные формы?

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

Ловите!

Не стесняйтесь писать в комментарии вопросы, замечания.


Normalization Cheat Sheet

Hey everyone, do you remember at least the first 3 normal forms well?

If you, like me, and always have to recall them, when modeling databases, here's a cheat sheet for you. I've written down the essence of each form. Also there is a bonus. I noticed when it's good to use each form and when it's not suitable.

Check it out! 👋

Feel free to write questions or comments in the comments section

#database

"Что делать, если смежная команда нарушает договоренности?"

Как-то с одним лидом обсуждали этот вопрос.

Ситуация: Две команды работают над задачей. Одна делает сервис-продюсер. Другая делает сервис-консьюмер. Они согласовывают интеграционный контракт и на этапе тестирования QA радостно понимают, что консьюмер не умеет передавать часть обязательных параметров. Если это происходит в условиях горячих дедлайнов, то грустно всем очень.

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

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

Первая выясняется довольно легко в любом формате: на проектном ретро, статусной встрече, 121. Пример причины: при разработке выяснились ограничения легаси или сделали оптимизацию. А вот почему сказать забыли надо обсуждать на 121. Вопрос тонкий, требует доверительной безопасной среды.

Алгоритм простой:
- Мое видение ситуации
- Видение ситуации собеседником
- Что мы можем сделать, чтобы так не повторялось в будущем
- Cанкции в случае нарушений

Например:
- Слушай, я точно помню, что мы с тобой все проговорили и записали в confluence. Изменения не появлялись, я не триггерилась.

- Да, блин, у меня параллельно было 3 проекта и пока писал тебе сообщение, отвлекли, потом вылетело из головы.

Давай попробуем включать в реестр рисков перегруз. Плюс раз в 3 дня статус по задаче в чат. Если новостей нет - пишем, что их нет. Кто пропустил - 2 недели фиксирует минутки встреч.


"What do you do if an adjacent team breaks agreements?"

Once I discussed this question with a lead.

Case: Two teams are working on a task. One team is developing the service producer, the other team is developing the service consumer. They agree on an integration contract. During testing, a QA realizes that the consumer cannot pass certain mandatory parameters. If this happens under tight deadlines, it becomes very frustrating for everyone involved.

The lead's position is to quickly fix it to make it work and take the following task. As for my opinion, this is just treating the symptom. Based on my experience, if an agreement is broken once, there is a 99.9% chance it will happen again. The root problem needs to be addressed.

The most important thing is to understand the real reasons behind it. There are always multiple reasons: one may be superficial, which leads to contract changes, and the other may be fundamental, indicating the lack of dialogue to discuss changes timely.

The superficial reason can be easily discussed in any format, such as a project retrospective, status meeting, or 121 discussion. Example reason: during development, legacy limitations were discovered or optimizations were made. However, why it was not communicated needs to be discussed in a safe and trusting environment.

The algorithm is simple:
- My view of the situation.
- The other person's view of the situation.
- A solution to prevent this from happening again
- Sanctions for failures

For example:
- I remember that we discussed and documented everything in Confluence. There haven't been any changes, so I wasn't triggered.
- I was juggling three projects at the same time, and while I was writing you that message, I got distracted, and then I completely forgot about it.

Let's try including overload risks in the risk register. Additionally, we can provide an update on the task in the chat every three days. If there are no updates, we will mention that there are none. Whoever misses it will have to record meeting minutes for two weeks.


#imho #negotiation

"Айти ли не айти, вот в чем вопрос"

На днях получила вопрос от подписчика: "Стоит ли переходить в ИТ?"

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

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

Увы, пока я не встретила человека, который бы сменил профессию после курсов а-ля "в ИТ за 3 месяца с трудоустройством" (не имея блата). При этом знаю людей, которые обращались к другим айтишникам и с помощью советов за несколько месяцев доходили до офферов.


"To IT or not to IT, that is the question."

One day, I received a question from a follower: "Is it worth moving to IT job?"

Imho, there is no right answer here. It's a task for personal decision-making. Generaly, I know people who changed their profession, moved to IT, and were satisfied. Often, these are graduates of technical universities and self-taught individuals. Usually, these are people who enjoyed programming or wanted more interesting tasks and opportunities.

For understandable reasons, there is a trend to retrain as an IT specialist in pursuit of relatively high salaries and remote work. I also know examples of successful employment motivated by these factors. Some people felt energized by the process, which fueled continuous learning and growth. Others stopped at the middle level, as they lost interest in regular training.

Unfortunately, I have not yet encountered someone who changed their profession after completing a 3-month IT course and found employment (without connections). However, I know people who have been trained by friends who are It specialists. They received job offers after 2-4 months of intensive training.

#imho

С Наступающим Новым годом, друзья!

Итоги этого года: несмотря на то, что канал молчал с 2021 года, вы остались с нами. Нас даже стало в 2 раза больше! Это круто!

А значит, надо нам снова встретиться, в Новом году!

С праздником! Пусть Новый год будет плодотворным, серых зон меньше, а логичного больше! 🥳🎉🎊


Happy New Year, folks!

Looking back at this year, even though our channel has been quiet since 2021, you've stuck with us. And wow, our community has even doubled in size! That's amazing!

So, it's time for us to get together again in the New Year!

Happy holidays! May your New Year be fruitful, with fewer gray areas and more clarity! 🥳🎉🎊

Channel name was changed to «Путь аналитика. Analyst's journey»

Опыт релокации в Лондон

Предисловие

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


Если посмотреть на карту мира, то главный центр ИТ - это однозначно Штаты и Долина, но мне никогда туда не хотелось. Я рассматривала Европу. Я знала там три города с ИТ-движухой: Берлин, Амстердам, Лондон. Лондон из них самый развитый. Плюс это английский. Конечно, и в Берлине, и в Амстердаме, можно работать на английском, но важно же еще на каком языке разговаривают люди вокруг. Методом вычитания остался один Лондон.

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

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

Непростой опыт для самооценки. На тот момент работала в Яндекс и это то чувство, когда на тебя все смотрят: "ах, ты работаешь в Яндексе". От этого казалось, что я классная. А потом не проходила скрининг в компании Лондона, про которые никто в жизни не слышал. Это возвращало в реальность. Со временем пришло осознание, что дело не во мне. Просто я разговариваю на другом языке и мне нужно научится разговаривать так, чтобы по звукам быть понятной другим людям. Плюс другая культура собеседований. Мы в России так не умеем. Нам кажется, что нужно быть скромными. Там много и других культурных особенностей, чтобы это понять и поменяться нужно время. При этом в требованиях к hard skills не заметила большой разницы.

Сейчас, спустя несколько лет работы в Лондоне, если говорить про разницу в формате работы в UK и России, то, думаю, так смогу обобщить свой опыт:

1. Работа очень дозирована. В России порой мне приходилось включаться в решение вопросов 24/7. Это значит, что мне могли написать в любое время и ожидать некоторой реакции. Когда я переехала и стала работать в своей первой английской компании, была шокирована: здесь люди работают реально с 10 до 17. В 17:00 они уходят и до следующего дня все останавливается. Тут нет систем формального контроля прихода и ухода. Это исключительно культурная особенность. Они так привыкли.

2. При этом в Лондоне люди намного быстрее стартуют. В России (я говорю только про свой опыт) все приходят на работу, раскачиваются, общаются, идут пить чай. В Англии этого нет. Все приходят, наливают чай и садятся фигачить. Я до сих пор к этому привыкаю.

3. В UK люди намного более эффективны, очень быстро принимают решения. Я никогда не видела, если честно, чтобы так быстро выдавался результат.

В завершение могу дать совет из своего опыта: “Однозначно, если вы один раз куда-то не прошли собеседование, но очень хотите, то готовьтесь, собирайте информацию и пробуйте еще раз. 100 интервью - это нормально."

#путьаналитика #интервью

"Я не по этой части". Как аналитику проходить техническое интервью

Ранее был анонс доклада про прохождение технического интервью. Как обещала, даю ссылку на презентацию.

В докладе подробно рассказывала:
- какие бывали ситуации на собеседованиях,
- что технические интервьюеры ожидают в cv, от самопрезентации, в ответах на вопросы (без разбора технический деталей а-ля как рисовать диаграмму в BPMN).

Если хочется посмотреть доклад целиком, то есть видео выступления. Оно выложено на отдельный хостинг конференции. Пока доступно только участникам или можно приобрести на сайте Analyst Days (2.50 $ за доклад). Если нужно - тут условия как приобрести.

===
Выжимка ИТОГО из доклада:

1. Подготовка cv:
- указывать только те навыки, которые можешь подтвердить
- делать структуру и детально указывать информацию об опыте, в том числе предметных областях и видах систем, с которыми работал(а)
- объединение в одном cv навыков из разных ролей дает преимущество

2. Самопрезентация на интервью:
- стоит делать заготовку и говорить о своем опыте, навыках, интересах и профессиональных активностях
- стоит уточнять у интервьюера время на самопрезентацию и какие вопросы важно осветить

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

#собеседования #путьаналитика

​​"Я не по этой части". Как аналитику проходить техническое интервью

Уже сегодня буду представлять на Analyst Days наш совместный доклад с Илоной Кулинич.

За прошлый год мы провели огромное количество технических собеседований на разные позиции БА и СА. И у нас сложилась нерадостная статистика. По данным за 5 месяцев у нас из 500 входящих cv после всех отборов до оффера дошли 18 кандидатов. И это мы еще не самые жесткие интервьюеры.

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

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

Приходите послушать, кто на конференции. Потом выложу ссылку на презу.

Красиво сказано
#минуткаюмора

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

Канал "Путь аналитика" уходит на каникулы. До встречи в новом году! 🎉🎄

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

Рубрика "Путь аналитика"

1. Герой интервью: Антон Казаков
2. Город: г. Москва
4. Профиль: UX/UI дизайн, дизайн-мышление, цифровая трансформация бизнеса
5. Профессия: дизайнер, ментор
6. Контакты: https://www.facebook.com/smartroll

#нетворкинг #путьаналитика #интервью

Рубрика "Путь аналитика"

1. Герой интервью: Денис Бесков
2. Город: г. Москва
4. Профиль: управление продуктами, предпринимательство, системная инженерия, организация обучения
5. Контакты: @beskov, https://www.facebook.com/beskov/

#нетворкинг #путьаналитика #интервью