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

Пообщаемся на тему особенностей подобной ситуации — когда есть только потребности и ожидания стейкхолдеров, но непонятны ни план, ни явные и скрытые риски, ни критерии успеха… Как материализовать неизвестного слона и затем съесть его, и в каких случаях для этого нужны стандартные методы, для каких — гибрид, а когда — что-то свое, уникальное? Как убедить своё руководство, что нужно потратить на это 100500 человеко-часов, «отжав» эти часы у основных задач? И также, поскольку часто изменения случаются лишь ради изменений, — как понять, надо ли вообще что-то менять? Все ли в команде радостно поддержат изменения или будет сопротивляющаяся коалиция "староверов"? Какие проблемы окажутся на практике самыми сложными: технические или взаимодействие с людьми?

В своем докладе я расскажу про ту модель внедрения изменений, которую мы с коллегами путем проб и ошибок выстроили в нашем отделе разработки технической документации в ДИТ Лаборатории Касперского, чтобы переехать с одного инструмента (от связки MS Word + MS SharePoint) на другой (Atlassian Confluence), успешно внедрить данные изменения и вести эффективную коммуникацию со всеми (многочисленными!) заинтересованными сторонами. Сейчас, когда прошел год "полета" на новом решении, уже можно оглянуться назад и посмотреть, какие и где мы совершили ошибки, а где и почему мы справились на “отлично”.