• Community

Программировал машинное зрение, делал разный маркетинг, управлял проектами и продуктами. Запустил ИТ-мероприятия: SnowOne – Content-First Java-конференцию из Сибири; "Инженер заходит в бар" – онлайн-митап для ИТ-инженеров на профессиональные неинженерные темы. Основал деврел-бюро "Долгушев и Сторожилов". Стремлюсь сделать деврел индустриальным стандартом.

Когда пытаешься развивать инженерную у себя в компании, внезапные асинхронные успехи всегда вызывают подозрения.

"Подождите, с этими командами мы ещё не работали, общая культура организации ещё пока что, кхм, не максимально развитая – тогда почему ребята из этих команд так ускорились по сбору обратной связи, постоянно просят фидбэка и потом делают улучшения по мотивам? Перестали говорить про "соответствие ТЗ", говорят про цепочку поставки ценности? Переиспользуют лучшие практики из соседних команд и из индустрии? WTF?"

Некоторое время назад я столкнулся с такими "спонтанными" всходами инженерной культуры и тоже насторожился. Стал разбираться: выяснилось, что, да, влияние внешней среды; да, ребята молодцы; но было кое-что ещё.

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

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

Как деврел влияет на инженерной культуры и как провернуть нечто подобное у себя в компании – расскажу в докладе.

менеджеры проектов, руководители, скрам-мастера, рефлексирующие инженеры