Или ментальные «ловушки», которые мешают аналитикам использовать нотации.

От системного аналитика требуют знание нотации BPMN (Business Process Model and Notation). Недавно среди своих коллег — системных аналитиков — я провела опрос о BPMN. Мне было интересно узнать используют ли мои коллеги нотацию, как именно и в чём сложности. В результате я нашла парадокс: большинство коллег считают, что нотации необходимы в работе, но на практике используют меньше половины. Почему возник такой парадокс и как его решить?

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

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

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

Не все тилиды не знают, как можно сообща с эйчаром проводить собеседования, чтобы было интересно кандидату и полезно команде. Я хочу рассказать, как можно им вместе провести действительно классное собеседование. Моя статья основана на опыте 200+ собеседований, которые я провел, чтобы отдел из 40 с лишним человек в ЦФТ.

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

Тезис 1. Чтобы стать сеньором надо иметь интересные проекты, на которых ты можешь вырасти и уметь внимательно читать документацию. 

Тезис 2. Гарантировано отличить джуна от мидла и сеньора может ваш тимлид, отправьте специалиста к нему на собеседование. 

Ничего нового в этом смысле в данной статье не будет. Собственно всё :)

Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.

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

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

Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.