Архив рубрики ‘передача знаний’

Когда онбординг длится 2 месяца — День 1: Убрать хаос

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

Как мы за 3 месяца обучили 15 человек поддержке и сэкономили бизнесу десятки миллионов рублей

Работа в крупной ИТ-компании — это здорово. Особенно когда проекты есть. И они были. Но один из крупнейших заказчиков, испытав трудности из-за надвигающегося кризиса, решил оптимизировать расходы и отказаться от поддержки, взяв всё в свои руки. Годами компания не вникала в проект. У них и так хватало сложностей с другими его частями — поддержку разных […]

Когда команда уходит, а экспертиза остается: практика использования ведомости передачи

Скрытый текст Если в вашей практике налажен процесс передачи знаний от команды другой команде, от коллеги команде и т.д. То прошу бегло пробежаться по статье. В противном случае — если ваша команда испытывает трудности в передаче/получении знаний, то прошу уделить 5 минут вашего внимания публикации. Введение

Секреты передачи знания: переход границ опыта при уходе ключевых инженеров и документирование архива проектов

Каждый разработчик рано или поздно сталкивается с ситуацией: из команды уходит «тот самый» человек, который держал в голове половину архитектуры. Вместе с ним уходит не только опыт, но и часть будущего проекта. В статье делюсь мыслями и подходами, как минимизировать потери при передаче знаний, какие форматы работают, а какие — нет, и почему документация должна […]

Передача знаний: инструкция на случай ухода эксперта

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