Рано или поздно сложную систему приходится объяснять человеку со стороны: новому разработчику, техлиду, архитектору или ревьюеру. И тут часто начинается боль: репозитории уже показали, основные сущности вроде бы объяснили, но всё ещё непонятно, как данные проходят через систему.

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

Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

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

Добро пожаловать в 50% IT-компаний во вторую статью цикла про онбординг в сложную систему!

В этой статье превратим плоский список репозиториев в рабочую onboarding-map: сначала определить роли, потом соберем dependency matrix, а затем получим relationship diagram.

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

Наверное, я не открою Америку, если скажу, что это довольно тревожный сигнал.

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

Почему?

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

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

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

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

35 вопросов для быстрой оценки качества IT проекта

Привет, дорогие читатели! Хочу поделиться с вами моим чек-листом для проверки состояния IT проекта (преимущественно web, но адаптируется и под другие). Особенно пригодится предпринимателям и управленцам, которые попали на новый проект. После проверки вы получите результат по 100-балльной системе!

В сентябре 2017 года в компании, где я работала, пошли разговоры о том, что планируется создание Доменного регистратора. Как очень молодой специалист (20 лет и начало 3 курса бакалавриата), я быстро распознала в нём проект, который может дать мне проявить себя. И к моему счастью, то ли в меня настолько поверили, то ли проект не посчитали перспективным, но он достался именно мне, почти целиком и полностью. На момент начала работы я предполагала, что материала будет мало даже для бакалаврского диплома. Я никогда так не ошибалась. Всё, начиная от понимания схемы работы системы, до её проектирования и написания, заняло очень много времени. Было переосмыслено много теории по Сетям, паттернам проектирования и вообще о работе.