Перед тем, как приступить к чтению, подумайте, какую эмоцию вызывает у вас упоминание о крупных компаниях? Это драйв, инновации, движуха, или, скорее, бюрократия, консерватизм? Поговорим как раз о том, откуда берутся такие представления и что с этим делать.
Под катом — полный драматизма рассказ о попытке внедрения гибкой методологии управления в крупной enterprise-компании.
В основе этой статьи доклад Дмитрия Смолярова на Web-scale IT Conference 2017. Дмитрий более пятнадцати лет работает в крупных холдингах, в частности возглавлял ИТ-департамент в РусГидро, и не понаслышке знает устройство корпоративной машины. Его рассказ поможет лучше понять протокол взаимодействия с enterprise-заказчиком и позволит узнать, как этот протокол можно нарушать. Поехали!
Сначала хочу рассказать одну историю. Когда-то давно, будучи молодым инженером, я приехал на одну из гидростанций нашей необъятной страны с амбициозной задачей: за 3 дня включить ее в общее корпоративное пространство.
Я встретил там замечательного человека, которого звали Николай Иванович. Это был крепкий хозяйственник, который отреагировал на мое появление примерно так:
Действительно, у него все хорошо: всё налажено, всё стабильно работает, ИТ-системы подробно задокументированы (что особенно удивило), всё стабильно. И вдруг кто-то вторгается и предлагает быстро, непривычным для этого опытного хозяйственника способом все изменить. Я встретил мощное сопротивление. Это был урок, который дал толчок к моему пониманию того, что же нужно крупным компаниям.
Почему там часто не бывает драйва, движухи и так далее? — Потому что в крупных компаниях другие приоритеты и другие ценности.
Всегда есть много факторов риска и желающих присоединиться к компании и «подкормиться» за ее счет.
Зачастую нужны не самые передовые инновации и революционные решения, а гарантированный результат. Революции большие компании как раз не очень любят.
Лица принимающие решения управляют чужим капиталом и наступает момент, когда нужно объяснить свои действия и держать ответ за свои решения перед собственниками и контролирующим органами.
Это вызывает ряд последствий при внедрении ИТ-систем, в том числе:
Принятие решений и прохождение точек контроля всегда сопровождается подготовкой отчетных документов. Это та самая отчетность и те самые документы, которые чаще всего ассоциируются с бюрократией в крупных компаниях.
Я вас пойму, если на этом месте вы начнете зевать. Но я еще раз специально обращаю ваше внимание на то, что повседневная жизнь в крупных компаниях всегда связана с этой самой «бюрократией», это естественная ее составляющая, и она всегда есть.
Традиционно договор строится таким образом, чтобы на каждом этапе получался законченный результат, который можно использовать в дальнейшей деятельности компании, этот результат документируется. Примеры таких документов — это концептуальный и технический проекты, частные технические задания, протоколы испытаний и прочее.
Наличие таких документов особенно важно для ИТ-проектов, которые, как правило, рождают нематериальный актив. И если не документировать результаты, то может даже не остаться следов: есть некий сервер, на котором стоит некая система, и эта система что-то делает. Что было проделано, за что подписали акт и заплатили — не понятно. Поэтому традиционная реализация ИТ-проектов в крупных компаниях — это последовательное достижение результатов, описанных в документах. Каждый из которых проходит внутренне согласование и утверждение, принимается, как законченное решение, и оплачивается.
Это в чем-то похоже на Agile, но имеет другой смысл. Разбиение ИТ-проекта на этапы делается с целью повышения управляемости и защиты компании-заказчика. В отличие от Agile, направленного на получение результата, максимально подходящего заказчику.
Другая сторона реализации проектов — это поведение руководителей-заказчиков. Среди их приоритетов — стремление подтвердить собственную состоятельность и значимость, сохранить свое место и сделать карьеру. А потому заказчики очень часто стараются снизить риски и гарантировать получение результата. Это накладывает определенные особенности на их поведение, и как на людей, и как на сотрудников компании.
Как правило, заказчики стремятся ограничить количество участников в проекте. Конечно, коллеги — это уважаемые люди, но включение их в состав проектной группы означает увеличение числа согласований отчетных документов. Что на практике приводит к увеличению сроков проекта. Чем меньше людей, участвующих в принятии решений, тем проще вести проект внутри компании.
Вполне понятно, что компания стремится удешевить проект любым способом, в том числе за счет пользователей, которые в больших компаниях являются субъектом. И рассматриваются как ресурс. Поэтому их обычно исключают из цикла внедрения — пользователь должен просто работать. Мнение пользователей не важно. Кроме того, обучение — это существенная статья затрат и, чем меньше обучаем, тем дешевле проект.
Еще одним фактором является, неготовность заказчика исполнить свою роль заказчика. Часто сформулировать, что они хотят с точки зрения автоматизации, дл руководителя в крупной компании проблема. Они просто не умеют это делать, даже имея понимание того, что автоматизация нужна.
Описываемый здесь проект — это проект по замене системы электронного документооборота (СЭД). Ничего уникального в самой системе не было, интересно то, как мы этот проект реализовывали.
Компания, в которой происходила реализация проекта, находилась в процессе существенной трансформации. Происходили значительные кадровые изменения, менялись бизнес-процессы, произошел даже перенос офиса компании в другой город. В то же время компания вела несколько важных проектов для своих заказчиков и её деятельность сопровождало около 8000 документов и 34 тысяч поручений. Несмотря на происходящие изменения требовалось обеспечить бесперебойную деятельность.
Для того, чтобы наладить деятельность компании с точки зрения процессов и установить контроль исполнительской дисциплины, было принято решение заменить систему электронного документооборота.
Со всеми описанными выше особенностями больших компаний и в контексте изменений мы приступили к проекту.
Как водится, долго выбирали платформу и команду подрядчика. Сформировали внутреннюю команду, в которую вошло минимум людей. Подписали договор, который включал такие обязательные вехи, как разработка проекта и частные технические задания на каждую функциональную область. Тем временем до момента, когда система должна заработать, оставалось 30 дней. Последствия такого подхода простые — если мы не поменяем то, как мы работали до этого момента, совершенно ясен исход: системы не будет.
К этому моменту, когда был запас в 30 дней, формально были готовы проекты всех отчетных документов, в том числе:
Ни один из документов не был утвержден функциональным заказчиком. Движение дальше невозможно.
Кто-то из великих сказал:
Поэтому мы решили обратиться к другому опыту.
Многое было не понятно, практических знаний не было, но был драйв и желание попробовать что-то сделать по-другому. Опыта внедрения тоже не было и было непонятно, как это ложится на корпоративную культуру. Мы понимали одно: если не попробуем — не узнаем. И мы начали узнавать.
Мы отошли от привычной корпоративной культуры и начали диалог с заказчиком в другой логике. Ранее мы искали способ выполнить план, подготовленный в привычной логике, а теперь задали себе вопрос: в чем корневая причина того, что заказчик не подписывает документы. Нам повезло, функциональный заказчик оказался открыт для общения, и мы получили достаточно информации для того, чтобы понять его боли и стремления. Основных факторов, определяющих действия заказчика, оказалось три.
Первое — простая нехватка времени на проект. Даже имея желание выполнить проекта в срок, заказчик просто не имел возможности уделять проекту столько времени, сколько нужно. Это было связано с выполнением функциональных обязанностей.
Второе. Оказалось, что у проекта есть три главных приоритета, определённых требованиями Генерального директора:
Третье. У функционального заказчика есть негативный опыт реализации подобного проекта, когда, несмотря на наличие подробнейшего ТЗ, готовая система не соответствовала ожиданиям, поэтому он опасается повторения истории.
Осмыслив данные факторы, мы решили отложить подготовку окончательных версий отчетных документов и визирование на конец проекта, и сконцентрироваться на достижении ключевых результатов: ввода системы в эксплуатацию с 09.01.2017 и обеспечения подготовки отчета по исполнительской дисциплине.
То есть первое, что мы нарушили, это традиционный способ последовательной реализации проекта через прохождение контрольных точек и точек перехода ответственности от подрядчика к заказчику. Мы не стали требовать от нашего функционального заказчика визирования документов и перехода этой ответственности. Она пока осталась за проектной командой.
В этом смысле это было достаточно смело, потому что в этом случае риски берет на себя все ИТ-департамент и подрядчик. В том числе риск невозможности закрыть вовремя этапы по проекту.
Как я сказал, у нас к этому моменту уже были проведены интервью, в целом было понятно, что должна делать система. Можно было подготовить начало работы системы к сроку, чтобы собирать ту статистику, которая позволит в конце квартала сформировать отчет.
Мы совершенно осознанно понимали, что не имеем системы, которая устроит заказчика, компанию, пользователей — всех! То есть это будет что-то похожее, но не то. Тем не менее, приступили к старту эксплуатации того, что получилось.
Следующий шаг — как сделать так, чтобы система была доведена до результата, близкого к тому, которое ожидает заказчик. Мы создали систему непрерывного улучшения с обратной связью.
В ней есть следующие субъекты: заказчик; выделенный человек заказчика (за что тоже ему спасибо!), который описывает процессы и является аккумулятором требований — администратор процессов; проектная команда.
Началась эксплуатация, которую мы назвали опытно-промышленной, и закрепили приказом. Наш заказчик получил возможность по мере использования системы формировать требования по её доработке, указывая, что нужно поправить и изменить. Возникший поток задач на проектную команду, трудно назвать спринтами. У нас был длинный список предложений по доработке системы, которые приоритезировались нашим администратором процессов и отдавались на исполнение. Пошел процесс непрерывного улучшения системы.
На следующем шаге мы осознанно включили пользователей в состав тех, кто помогал отстраивать систему. Фактически мы расширили состав проектной команды и перевели пользователей из роли субъекта в роль объекта.
Изначально предполагалось, что мы обучим ограниченное количество пользователей, которые находятся в прямом административном подчинении функционального заказчика, и они будут давать обратную связь. Дойдя до этой точки перегиба, мы решили расширить это количество и дать возможность всем пользователям писать, что не так с системой.
Возникло еще 3 информационных потока:
Важный момент — последний поток шел на администратора процесса, который принимал решение, какие предложения стоит пускать в работу, какие нет. К нам поступали отфильтрованные предложения.
Это действие позволило не только выявить и устранить ошибки, но и продуктивно формировать требования по доработке системы со стороны пользователей.
Следующее, что мы сделали — отдельно занялись вовлечением руководителей структурных подразделений одного уровеня с функциональным заказчиком.
Сначала было проведено групповое обучение, которое завершалось двумя предложениями к руководителям среднего звена: дать обратную связь в виде предложений по улучшению системы и пройти при необходимости индивидуальное обучение. Потенциально это могло привести к финансовому взрыву, то есть могло потребовать слишком много денег на проведение изменений и индивидуальное обучение. По факту была только одна служебная записка с предложением по доработке и только 1 человек захотел обучаться индивидуально. Но остальным наше предложение запомнилось. Люди увидели наше внимание, и эмоциональный накал спал.
Вы, наверное, представляете: сырая система находится в опытно-промышленной эксплуатации, компания близка к революции — искры сверкают по коридорам! Естественно, для людей, формирующих мнение руководства компанией, такой знак оказался очень действенным. Мы показали свою готовность получать от них обратную связь и готовность работать с ними индивидуально. Сам функциональный заказчик тоже присутствовал на обучении и был открыт для контакта.
Следующим шагом было придание публичности. Для этого мы написали и опубликовали статью на корпоративном портале о том, почему мы выбрали именно такой путь внедрения. Статья позволила объяснить то, что происходит, и снизить накал, возникший в связи с жестким режимом внедрения. Кроме того, при входе в систему любой пользователь мог перейти в анкету и высказать свое мнение. Это простой шаг, который тоже принес пользу.
Приведу небольшую статисту по обращениям:
Первый всплеск был в декабре, когда мы сделали только прототип и получили обратную связь от функционального заказчика. Дальше по мере подключения пользователей видны скачки, которые длились до февраля. Убывающий тренд демонстрирует, как система совершенствовалась и снижалось количество предложений по ее изменению.
Сводные результаты по внедрению в цифрах получились такими:
Последний факт я расцениваю, как иллюстрацию эмоционального состояния компании, когда человеку хочется приобщиться к проекту. Наш оператор сам предложил отвечать на вопросы о том, как пользоваться системой, хотя в его функциональные обязанности это не входит.
Не все было хорошо, были и сложности. С одной стороны, нас радовало, что наш подход дает возможность заказчику по мере осознания потребностей формировать требования по изменению системы. С другой стороны, заказчик очень быстро привык к этому, и когда надо было выходить из проекта, мы получали «ошибки». Реально это были не ошибки, а скорее вопросы, связанные с тем, как использовать систему, или результаты того, что заказчик не до конца осознал свои же требования и неправильно читал отчеты. Из всего, что было доработано в последнем месяце проекта, только одно событие действительно было ошибкой разработчиков.
Но заказчик привык к такому способу работы, и в итоге, мы (ИТ) приложили немало сил для получения виз под отчетными документами, пришлось писать программу и методику испытаний, назначать испытания, то есть включать формализм, свойственный всем большим компаниям.
Кроме этого, надо признать, что некоторые действия были выполнены с запозданием. Например, статья на портале была бы более действенной, если бы ее опубликовали до начала опытно-промышленной эксплуатации.
Подводя итог, расскажу, в чем для меня ключевое отличие этого проекта от обычных. Я давно работаю в крупных компаниях, я — продукт этих компаний, и я привык к тому, что сначала — процедура. Это дает ту самую стабильность, понятность взаимоотношений, снимает риски. В данном случае, мы отошли от процедуры и посмотрели на нашего заказчика, как на человека со своими страхами, особенностями, приоритетами и так далее.
Такой взгляд позволил прийти к тем идеям, которые родились и были реализованы. То есть Agile здесь, скорее, не инструмент, а флаг, катализатор, идея! Но эта идея как раз привела к изменению в головах, которое позволило увидеть заказчика-человека и сориентироваться на него.
На следующих этапах хотелось бы сохранить ценность, которую мы получили, поменять типовой ход проекта и типовой договор.
Тем не менее, есть правила, которые мы пока не знаем, как обойти, и даже не уверены, что нужно их обходить. В первую очередь это точка перехода ответственности в виде подписи под отчетными документами, и ограничение по сумме и по времени. Наследование в виде отчетных документов, которые позволяют передать систему другим командам доработки, также сохранится.
Завершая статью, хочется сказать, что нужно, с одной стороны, знать правила, по которым живут крупные компании, понимая и принимая их забюрократизированность, но не бояться их нарушать.
Будьте смелей, и действуйте!
Экспертов и профессионалов мы приглашаем поделиться интересным опытом разработки или внедрения выступив на майском фестивале конференций РИТ++. В программе разные узкотематические направления, конференция по сегодняшней теме называется Web-scale IT Conference 2017, а полный список на сайте.
Под катом — полный драматизма рассказ о попытке внедрения гибкой методологии управления в крупной enterprise-компании.
В основе этой статьи доклад Дмитрия Смолярова на Web-scale IT Conference 2017. Дмитрий более пятнадцати лет работает в крупных холдингах, в частности возглавлял ИТ-департамент в РусГидро, и не понаслышке знает устройство корпоративной машины. Его рассказ поможет лучше понять протокол взаимодействия с enterprise-заказчиком и позволит узнать, как этот протокол можно нарушать. Поехали!
Чё приехал?
Сначала хочу рассказать одну историю. Когда-то давно, будучи молодым инженером, я приехал на одну из гидростанций нашей необъятной страны с амбициозной задачей: за 3 дня включить ее в общее корпоративное пространство.
Я встретил там замечательного человека, которого звали Николай Иванович. Это был крепкий хозяйственник, который отреагировал на мое появление примерно так:
Действительно, у него все хорошо: всё налажено, всё стабильно работает, ИТ-системы подробно задокументированы (что особенно удивило), всё стабильно. И вдруг кто-то вторгается и предлагает быстро, непривычным для этого опытного хозяйственника способом все изменить. Я встретил мощное сопротивление. Это был урок, который дал толчок к моему пониманию того, что же нужно крупным компаниям.
Почему там часто не бывает драйва, движухи и так далее? — Потому что в крупных компаниях другие приоритеты и другие ценности.
Основные риски и мотиваторы большой компании
- Защита — крупные компании всегда защищают себя, свои активы и инвестиции.
Всегда есть много факторов риска и желающих присоединиться к компании и «подкормиться» за ее счет.
- Стабильность и предсказуемость.
Зачастую нужны не самые передовые инновации и революционные решения, а гарантированный результат. Революции большие компании как раз не очень любят.
- Кроме того, это все-таки всегда чужие деньги.
Лица принимающие решения управляют чужим капиталом и наступает момент, когда нужно объяснить свои действия и держать ответ за свои решения перед собственниками и контролирующим органами.
Это вызывает ряд последствий при внедрении ИТ-систем, в том числе:
- Тщательный выбор подрядчика;
- Продуманный договор — система ворот (точек принятия решений о возможности продолжать проект, возможности защитить инвестиции);
- Определенные точки контроля;
- Обеспечение преемственности с имеющимися решениями;
- Отчетность и документы!
Принятие решений и прохождение точек контроля всегда сопровождается подготовкой отчетных документов. Это та самая отчетность и те самые документы, которые чаще всего ассоциируются с бюрократией в крупных компаниях.
Я вас пойму, если на этом месте вы начнете зевать. Но я еще раз специально обращаю ваше внимание на то, что повседневная жизнь в крупных компаниях всегда связана с этой самой «бюрократией», это естественная ее составляющая, и она всегда есть.
«Ворота» — инструмент контроля
Традиционно договор строится таким образом, чтобы на каждом этапе получался законченный результат, который можно использовать в дальнейшей деятельности компании, этот результат документируется. Примеры таких документов — это концептуальный и технический проекты, частные технические задания, протоколы испытаний и прочее.
Наличие таких документов особенно важно для ИТ-проектов, которые, как правило, рождают нематериальный актив. И если не документировать результаты, то может даже не остаться следов: есть некий сервер, на котором стоит некая система, и эта система что-то делает. Что было проделано, за что подписали акт и заплатили — не понятно. Поэтому традиционная реализация ИТ-проектов в крупных компаниях — это последовательное достижение результатов, описанных в документах. Каждый из которых проходит внутренне согласование и утверждение, принимается, как законченное решение, и оплачивается.
Это в чем-то похоже на Agile, но имеет другой смысл. Разбиение ИТ-проекта на этапы делается с целью повышения управляемости и защиты компании-заказчика. В отличие от Agile, направленного на получение результата, максимально подходящего заказчику.
Особенности реализации
Другая сторона реализации проектов — это поведение руководителей-заказчиков. Среди их приоритетов — стремление подтвердить собственную состоятельность и значимость, сохранить свое место и сделать карьеру. А потому заказчики очень часто стараются снизить риски и гарантировать получение результата. Это накладывает определенные особенности на их поведение, и как на людей, и как на сотрудников компании.
Как правило, заказчики стремятся ограничить количество участников в проекте. Конечно, коллеги — это уважаемые люди, но включение их в состав проектной группы означает увеличение числа согласований отчетных документов. Что на практике приводит к увеличению сроков проекта. Чем меньше людей, участвующих в принятии решений, тем проще вести проект внутри компании.
Вполне понятно, что компания стремится удешевить проект любым способом, в том числе за счет пользователей, которые в больших компаниях являются субъектом. И рассматриваются как ресурс. Поэтому их обычно исключают из цикла внедрения — пользователь должен просто работать. Мнение пользователей не важно. Кроме того, обучение — это существенная статья затрат и, чем меньше обучаем, тем дешевле проект.
Еще одним фактором является, неготовность заказчика исполнить свою роль заказчика. Часто сформулировать, что они хотят с точки зрения автоматизации, дл руководителя в крупной компании проблема. Они просто не умеют это делать, даже имея понимание того, что автоматизация нужна.
Контекст проекта
Описываемый здесь проект — это проект по замене системы электронного документооборота (СЭД). Ничего уникального в самой системе не было, интересно то, как мы этот проект реализовывали.
Компания, в которой происходила реализация проекта, находилась в процессе существенной трансформации. Происходили значительные кадровые изменения, менялись бизнес-процессы, произошел даже перенос офиса компании в другой город. В то же время компания вела несколько важных проектов для своих заказчиков и её деятельность сопровождало около 8000 документов и 34 тысяч поручений. Несмотря на происходящие изменения требовалось обеспечить бесперебойную деятельность.
Для того, чтобы наладить деятельность компании с точки зрения процессов и установить контроль исполнительской дисциплины, было принято решение заменить систему электронного документооборота.
Все нормально — падаем!
Со всеми описанными выше особенностями больших компаний и в контексте изменений мы приступили к проекту.
Как водится, долго выбирали платформу и команду подрядчика. Сформировали внутреннюю команду, в которую вошло минимум людей. Подписали договор, который включал такие обязательные вехи, как разработка проекта и частные технические задания на каждую функциональную область. Тем временем до момента, когда система должна заработать, оставалось 30 дней. Последствия такого подхода простые — если мы не поменяем то, как мы работали до этого момента, совершенно ясен исход: системы не будет.
Нужен другой способ…
К этому моменту, когда был запас в 30 дней, формально были готовы проекты всех отчетных документов, в том числе:
- Эскиз технического проекта;
- Эскиз концептуального проекта;
- Черновики всех частных технических заданий.
Ни один из документов не был утвержден функциональным заказчиком. Движение дальше невозможно.
Кто-то из великих сказал:
«…если дело делать таким же способом, каким ты делал до этого, трудно ожидать другой результат»
Поэтому мы решили обратиться к другому опыту.
Многое было не понятно, практических знаний не было, но был драйв и желание попробовать что-то сделать по-другому. Опыта внедрения тоже не было и было непонятно, как это ложится на корпоративную культуру. Мы понимали одно: если не попробуем — не узнаем. И мы начали узнавать.
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
«Боли» функционального заказчика
Мы отошли от привычной корпоративной культуры и начали диалог с заказчиком в другой логике. Ранее мы искали способ выполнить план, подготовленный в привычной логике, а теперь задали себе вопрос: в чем корневая причина того, что заказчик не подписывает документы. Нам повезло, функциональный заказчик оказался открыт для общения, и мы получили достаточно информации для того, чтобы понять его боли и стремления. Основных факторов, определяющих действия заказчика, оказалось три.
Первое — простая нехватка времени на проект. Даже имея желание выполнить проекта в срок, заказчик просто не имел возможности уделять проекту столько времени, сколько нужно. Это было связано с выполнением функциональных обязанностей.
Второе. Оказалось, что у проекта есть три главных приоритета, определённых требованиями Генерального директора:
- с начала года компания должна начать работать в новой СЭД;
- по итогам квартала должны быть сформированы отчеты об исполнительской дисциплине для расчета премии в соответствии с новой, только что утвержденной системой мотивации персонала;
- отчет об исполнительской дисциплине должен быть на столе у ГД.
Третье. У функционального заказчика есть негативный опыт реализации подобного проекта, когда, несмотря на наличие подробнейшего ТЗ, готовая система не соответствовала ожиданиям, поэтому он опасается повторения истории.
Реализация
Осмыслив данные факторы, мы решили отложить подготовку окончательных версий отчетных документов и визирование на конец проекта, и сконцентрироваться на достижении ключевых результатов: ввода системы в эксплуатацию с 09.01.2017 и обеспечения подготовки отчета по исполнительской дисциплине.
То есть первое, что мы нарушили, это традиционный способ последовательной реализации проекта через прохождение контрольных точек и точек перехода ответственности от подрядчика к заказчику. Мы не стали требовать от нашего функционального заказчика визирования документов и перехода этой ответственности. Она пока осталась за проектной командой.
В этом смысле это было достаточно смело, потому что в этом случае риски берет на себя все ИТ-департамент и подрядчик. В том числе риск невозможности закрыть вовремя этапы по проекту.
Шаг 1. Меняем приоритеты в работах и схему контроля проекта
Как я сказал, у нас к этому моменту уже были проведены интервью, в целом было понятно, что должна делать система. Можно было подготовить начало работы системы к сроку, чтобы собирать ту статистику, которая позволит в конце квартала сформировать отчет.
Вопрос из зала: Нельзя ли было вышестоящему руководству сказать, что проект горит, а вы не можете получить подпись?
Это решение в духе крупных компаний — 5 баллов! Я бы раньше, наверное, так и сделал. Но как я уже сказал, способ с подготовкой ЧТЗ уже не сработал. Такой подход привел нас к тому, к чему привел: времени нет, система должна работать. Кроме того, я считаю, что не очень хорошо давить на коллег, хотя иногда и делаю это. Но мы осознанно решили пойти другими путем. Главный ответ в этом.
Мы совершенно осознанно понимали, что не имеем системы, которая устроит заказчика, компанию, пользователей — всех! То есть это будет что-то похожее, но не то. Тем не менее, приступили к старту эксплуатации того, что получилось.
Шаг 2. Создаем систему непрерывного улучшения с обратной связью
Следующий шаг — как сделать так, чтобы система была доведена до результата, близкого к тому, которое ожидает заказчик. Мы создали систему непрерывного улучшения с обратной связью.
В ней есть следующие субъекты: заказчик; выделенный человек заказчика (за что тоже ему спасибо!), который описывает процессы и является аккумулятором требований — администратор процессов; проектная команда.
Началась эксплуатация, которую мы назвали опытно-промышленной, и закрепили приказом. Наш заказчик получил возможность по мере использования системы формировать требования по её доработке, указывая, что нужно поправить и изменить. Возникший поток задач на проектную команду, трудно назвать спринтами. У нас был длинный список предложений по доработке системы, которые приоритезировались нашим администратором процессов и отдавались на исполнение. Пошел процесс непрерывного улучшения системы.
Шаг 3. Вовлекаем пользователей в систему улучшения
На следующем шаге мы осознанно включили пользователей в состав тех, кто помогал отстраивать систему. Фактически мы расширили состав проектной команды и перевели пользователей из роли субъекта в роль объекта.
Изначально предполагалось, что мы обучим ограниченное количество пользователей, которые находятся в прямом административном подчинении функционального заказчика, и они будут давать обратную связь. Дойдя до этой точки перегиба, мы решили расширить это количество и дать возможность всем пользователям писать, что не так с системой.
Возникло еще 3 информационных потока:
- Вопросы «Как этим пользоваться?» по итогам короткого обучения.
- Сообщения об ошибках: «Система не работает, как должна — мы видим ошибку и способны четко ее описать».
- Предложения по изменению системы.
Важный момент — последний поток шел на администратора процесса, который принимал решение, какие предложения стоит пускать в работу, какие нет. К нам поступали отфильтрованные предложения.
Это действие позволило не только выявить и устранить ошибки, но и продуктивно формировать требования по доработке системы со стороны пользователей.
Шаг 4. Вовлекаем средний уровень управления
Следующее, что мы сделали — отдельно занялись вовлечением руководителей структурных подразделений одного уровеня с функциональным заказчиком.
Сначала было проведено групповое обучение, которое завершалось двумя предложениями к руководителям среднего звена: дать обратную связь в виде предложений по улучшению системы и пройти при необходимости индивидуальное обучение. Потенциально это могло привести к финансовому взрыву, то есть могло потребовать слишком много денег на проведение изменений и индивидуальное обучение. По факту была только одна служебная записка с предложением по доработке и только 1 человек захотел обучаться индивидуально. Но остальным наше предложение запомнилось. Люди увидели наше внимание, и эмоциональный накал спал.
Вы, наверное, представляете: сырая система находится в опытно-промышленной эксплуатации, компания близка к революции — искры сверкают по коридорам! Естественно, для людей, формирующих мнение руководства компанией, такой знак оказался очень действенным. Мы показали свою готовность получать от них обратную связь и готовность работать с ними индивидуально. Сам функциональный заказчик тоже присутствовал на обучении и был открыт для контакта.
Шаг 5. Придание публичности
Следующим шагом было придание публичности. Для этого мы написали и опубликовали статью на корпоративном портале о том, почему мы выбрали именно такой путь внедрения. Статья позволила объяснить то, что происходит, и снизить накал, возникший в связи с жестким режимом внедрения. Кроме того, при входе в систему любой пользователь мог перейти в анкету и высказать свое мнение. Это простой шаг, который тоже принес пользу.
Динамика снижения обращений
Приведу небольшую статисту по обращениям:
- Всего за 5 месяцев поступивших и реализованных изменений около 250;
- Из них 200 за первые 3 месяца.
Первый всплеск был в декабре, когда мы сделали только прототип и получили обратную связь от функционального заказчика. Дальше по мере подключения пользователей видны скачки, которые длились до февраля. Убывающий тренд демонстрирует, как система совершенствовалась и снижалось количество предложений по ее изменению.
Несколько фактов
Сводные результаты по внедрению в цифрах получились такими:
- Для внедрения системы было задействовано всего 3 (на пике в январе 10) специалистов подрядчика, внутренние службы для обучения и поддержки пользователей.
- В среднем внедрение прошло на 20% быстрее, по сравнению с другими аналогичными проектами.
- Стоимость увеличилась примерно на 5% за счет увеличения объема обучения.
- Уже на старте самостоятельно подключилось 400 пользователей (в конечном итоге более 800) вместо запланированных 120.
- Только одна (официальная) служебная записка с предложениями по доработке.
- Оператор СПП высказал пожелание взять на себя первую линию поддержки целиком.
Последний факт я расцениваю, как иллюстрацию эмоционального состояния компании, когда человеку хочется приобщиться к проекту. Наш оператор сам предложил отвечать на вопросы о том, как пользоваться системой, хотя в его функциональные обязанности это не входит.
Капли дёгтя в бочке меда
Не все было хорошо, были и сложности. С одной стороны, нас радовало, что наш подход дает возможность заказчику по мере осознания потребностей формировать требования по изменению системы. С другой стороны, заказчик очень быстро привык к этому, и когда надо было выходить из проекта, мы получали «ошибки». Реально это были не ошибки, а скорее вопросы, связанные с тем, как использовать систему, или результаты того, что заказчик не до конца осознал свои же требования и неправильно читал отчеты. Из всего, что было доработано в последнем месяце проекта, только одно событие действительно было ошибкой разработчиков.
Но заказчик привык к такому способу работы, и в итоге, мы (ИТ) приложили немало сил для получения виз под отчетными документами, пришлось писать программу и методику испытаний, назначать испытания, то есть включать формализм, свойственный всем большим компаниям.
Кроме этого, надо признать, что некоторые действия были выполнены с запозданием. Например, статья на портале была бы более действенной, если бы ее опубликовали до начала опытно-промышленной эксплуатации.
Процедура или человек?
Подводя итог, расскажу, в чем для меня ключевое отличие этого проекта от обычных. Я давно работаю в крупных компаниях, я — продукт этих компаний, и я привык к тому, что сначала — процедура. Это дает ту самую стабильность, понятность взаимоотношений, снимает риски. В данном случае, мы отошли от процедуры и посмотрели на нашего заказчика, как на человека со своими страхами, особенностями, приоритетами и так далее.
Такой взгляд позволил прийти к тем идеям, которые родились и были реализованы. То есть Agile здесь, скорее, не инструмент, а флаг, катализатор, идея! Но эта идея как раз привела к изменению в головах, которое позволило увидеть заказчика-человека и сориентироваться на него.
На следующих этапах хотелось бы сохранить ценность, которую мы получили, поменять типовой ход проекта и типовой договор.
Тем не менее, есть правила, которые мы пока не знаем, как обойти, и даже не уверены, что нужно их обходить. В первую очередь это точка перехода ответственности в виде подписи под отчетными документами, и ограничение по сумме и по времени. Наследование в виде отчетных документов, которые позволяют передать систему другим командам доработки, также сохранится.
Полет продолжается!
Завершая статью, хочется сказать, что нужно, с одной стороны, знать правила, по которым живут крупные компании, понимая и принимая их забюрократизированность, но не бояться их нарушать.
Будьте смелей, и действуйте!
Вопросы и ответы
— С каким количеством функционала стартовал проект на пользователей?
СЭД стартовал с основы, как обычно: входящие, исходящие, внутренние. Но руководству нужны были всего 2 вещи: как обычно, приказы/распоряжения и протоколы. Особенность деятельности компании связана с тем, что к нам прилетает много решений от заказчиков компании. Там колоссальные цифры, по-моему, 8 000 внутренних документов и 32 000 поручений, каждое из которых обладает своим жизненным циклом, и его надо отслеживать.
— Но в целом у вас же было ТЗ, какой процент был готов при начальном запуске?
Почти все, что было в ТЗ, мы запустили сразу. Не было отчетности. Далее выполнялась доработка системы и настройка бизнес-процессов под требования заказчика. Предполагалось, что будет автоматизированы определенные функции: входящие/исходящие, протоколы, приказы, отчетность и так далее. Их перечень относительно ТЗ мы не меняли.
Подрядчик настроил этот функционал системы, как считал нужным, по итогам интервью. Но видение подрядчика и видение заказчика отличались. Обратная связь позволила сблизить понимание и настроить систему так, как это хотел заказчик. В этом был смысл непрерывного улучшения и обратной связи.
— То есть функционал был один, а вы меняли немножко логику плюс интерфейс — я так понимаю?
Грубо говоря, да.
— Тогда второй вопрос. А как вы управляли входящими требованиями? Как вы регулировали, что брать, что не брать?
Было 3 информационных потока. Была написана памятка для пользователей, описывающая все эти 3 информационных потока. С каждым потоком ассоциировался некий документ. Основной поток — это запросы на изменения — шли через представителя заказчика. Это был просто расшаренный файл Exel, который вели 2 стороны — подрядчик и администратор процессов под контролем со стороны ИТ.
Для остального у нас есть система Service Desk, в которой фиксировали обращения обычным способом. Но 3 потока были заданы, описаны — памятки, документ, рассылка — все, как положено.
— У меня вопрос не столько с технической точки зрения, а с точки зрения, как вы понимали, какой функционал включать, какой нет, и сравнивали ли вы это с бюджетом, который оставался на тот или иной функционал. Как вы это регулировали?
Функционал, который должен был получиться на старте, был в договоре. Изменения, как я сказал, шли через администратора процесса функционального заказчика. Он экспертно принимал решения о том, что включать, а что не включать. Он внешний человек по отношениям к деньгам, совершенно верно. Я же получал обратную связь от подрядчика и выступал неким регулятором, тоже экспертным.
К счастью, это взаимодействие было очень эффективным. Может быть, нам повезло — все адекватные, все были в рамках курса к цели. Не было проблем. Проблемы наступили, когда нужно было закрыть договор и принять решение о прекращении дальнейших улучшений, о готовности системы.
— Можете дать пару советов небольшим компаниям, кто начинает работать с крупными игроками. Допустим, я приду в Газпром и предложу такой вариант работы. На меня посмотрят странным взглядом и скажут, что они привыкли работать не так. Как найти слова для крупных компаний, чтобы они согласились попробовать?
Как найти слова, наверное, я не подскажу. Я тот еще продавец. Но я еще раз повторюсь — у больших компаний есть правила, процедуры, как способ защиты и снятие рисков для конкретных людей. То, что здесь происходило — это не совет, но больше некоторая детализация.
В этом проекте была подготовлена визуальная схема снятия рисков, которые нам озвучил функциональный заказчик, в виде временной линии и нанесении на неё ключевых событий проекта, в том числе точек перехода ответственности и точек улучшения системы. Я сам нарисовал схему проекта, временную линию, показал, как это раньше было, и как мы будем делать теперь, указал точку перехода, когда заказчик будет визировать документы. Это был способ убедить заказчика в том, что он сохраняет контроль.
Советы на самом деле все те же самые. Надо знать заказчика, его страхи и риски, и знать системные правила компании. Тогда можно найти вариант, как, не нарушая основные правила, понимая, что же ждет заказчик, предложить вариант, который позволит реализовать проект.
— Вопрос аналогичный. Получается, в первую очередь вы были на стороне интегратора, победили прокрастинацию со стороны самого заказчика, а затем уже, находясь внутри заказчика, сделали все возможное, чтобы сам заказчик захотел это сделать. Вы в дальнейшем планируете это, как некую консультационную услугу предлагать? Тут многие думают, как он это сделал?
В формате тренинга рассказать, как устроены большие компании — было бы интересно, коллеги? ОК. Мы, наверное, победили сами себя, в первую очередь. Это победа в голове была. Нужно было отойти от желания сохранить статус-кво и найти способ добиться цели.
— Вопрос по бюджету. Как я понял, проект начался еще заранее, вы сделали ЧТЗ, все формальные документы, и поняли, что срока, который был установлен, не хватает на нормальное внедрение.
Как вы сказали, вы убедили функционального заказчика, начертив точку, когда он подпишет документы. До этого вы обязались все сделать.
Вопрос такой — как вы смогли эту точку определить, что это будет, например, в конце мая? Ведь при такой гибкой разработке — это долго и дорого на самом деле, это не быстро и дешево — пока деньги есть, вроде все работает, деньги кончились, все завершилось — в классике, да?
Мы так не можем работать. Надо заранее бюджет согласовать с директорами, со всеми учредителями компании. Мы не можем сказать, что, знаете, у нас в июне деньги кончились, а требований еще 120 лежит, надо делать. Как вы регулировали бюджет?
Это были какие-то доп. соглашения, или как? Я так понял, что с подрядчиком вы были в одной лодке, но ак это решали внутри самой компании?
Ценный вопрос. Этому предшествовало несколько обстоятельств. Первое — компания Scrum Trek в прошлом году дала статистику, что использование Scrum/Agile статистически не приводит к сокращению бюджета и сроков проекта. Я просто знал, что будет примерно то же самое.
Кроме того, я люблю читать теоретические вещи, а в теории, Scrum позволяет добиться большего качества при тех же сроках и бюджете.
У меня было представление, что представляет собой компания-подрядчик, я знал, какой результат от них ожидать. Это было волевое решение, риск. Я предполагал, что мы справимся.
Что касается управления деньгами, мы заключили только одно доп. соглашение на увеличение объема обучаемых, за счет которого немного увеличилась сумма проекта.
Складываю все 3 составляющие:
1. Я понимал, на какие риски мы идем.
2. Мы были все ограничены договором, который никто не менял.
3. Понимая, что статистически мы уложимся в этот бюджет и в сроки, мы просто эти составляющие не меняли, мы только поменяли способ реализации проекта.
Это другой подход, чем вы озвучиваете. Договор был и остается фиксированным, с четко оговоренной ценой и сроками.
— Как я понял, вы на этапе внедрения предоставили какой-то функционал, который был еще не закончен. В дальнейшем вам надо было дорабатывать тот функционал, который вы предоставляли, делать новый функционал. Но помимо этого, так как пользователи начали пользоваться продуктом, стали появляться горячие задачи. Как вы справлялись с этим потоком и как его регулировали?
И сразу второй вопрос — была ли у вас фильтрация этих ошибок. Процесс-менеджер, который вам передавал все ошибки, по сути, мог и не внедряться в суть проблемы, а просто все их складывать и вам отправлять.
Аккумулировали все запросы в одном файле. Просто организовали таким образом, чтобы происходила фиксация, фильтрация и приоритезация. В проектную команду поступал уже перечень задач, предварительно обработанный на нашей стороне. Приоритезация и фильтрация осуществлялась экспертно на основе понимания потребностей компании и содержания предложения.
Что происходило в команде подрядчика, я не знаю. Потому что я по классике сокращал число точек управления и общался только с одним человеком, который мне регулярно приносил отчетность. Я, как представитель заказчика, отслеживал неуклонное снижение количества открытых обращений.
Если обобщить ответ, то он звучит так:
1. Был четкий понятный механизм поступления запросов в проектную команду.
2. Был четкий, понятный инструмент выполнения этих запросов.
Единственное, что я регулировал — это был всплеск, когда нам надо было больше ресурсов. Было визуально видно количество задач, которые сейчас существуют, и мы обсуждали, сколько и каких людей нужно, чтобы этот объём переварить.
— А вы использовали каких-то консалтеров, тех же Scrum Trek? Или все делали сами?
Да, все самостоятельно. Чтобы использовать Scrum Trek, нужно сначала продать идею внутри компании: чтобы она нашла много приверженцев, и компания поменяла культуру.
— Извините, если не секрет, какова рентабельность проекта на выходе?
Не знаю. Это вопрос к подрядчику. Для заказчика — давайте так отвечу — этот проект вполне укладывается в среднестатистический. То есть он не идет с завышенной ценой. У нас очень жесткий контроль за этим внутри компании.
СЭД стартовал с основы, как обычно: входящие, исходящие, внутренние. Но руководству нужны были всего 2 вещи: как обычно, приказы/распоряжения и протоколы. Особенность деятельности компании связана с тем, что к нам прилетает много решений от заказчиков компании. Там колоссальные цифры, по-моему, 8 000 внутренних документов и 32 000 поручений, каждое из которых обладает своим жизненным циклом, и его надо отслеживать.
— Но в целом у вас же было ТЗ, какой процент был готов при начальном запуске?
Почти все, что было в ТЗ, мы запустили сразу. Не было отчетности. Далее выполнялась доработка системы и настройка бизнес-процессов под требования заказчика. Предполагалось, что будет автоматизированы определенные функции: входящие/исходящие, протоколы, приказы, отчетность и так далее. Их перечень относительно ТЗ мы не меняли.
Подрядчик настроил этот функционал системы, как считал нужным, по итогам интервью. Но видение подрядчика и видение заказчика отличались. Обратная связь позволила сблизить понимание и настроить систему так, как это хотел заказчик. В этом был смысл непрерывного улучшения и обратной связи.
— То есть функционал был один, а вы меняли немножко логику плюс интерфейс — я так понимаю?
Грубо говоря, да.
— Тогда второй вопрос. А как вы управляли входящими требованиями? Как вы регулировали, что брать, что не брать?
Было 3 информационных потока. Была написана памятка для пользователей, описывающая все эти 3 информационных потока. С каждым потоком ассоциировался некий документ. Основной поток — это запросы на изменения — шли через представителя заказчика. Это был просто расшаренный файл Exel, который вели 2 стороны — подрядчик и администратор процессов под контролем со стороны ИТ.
Для остального у нас есть система Service Desk, в которой фиксировали обращения обычным способом. Но 3 потока были заданы, описаны — памятки, документ, рассылка — все, как положено.
— У меня вопрос не столько с технической точки зрения, а с точки зрения, как вы понимали, какой функционал включать, какой нет, и сравнивали ли вы это с бюджетом, который оставался на тот или иной функционал. Как вы это регулировали?
Функционал, который должен был получиться на старте, был в договоре. Изменения, как я сказал, шли через администратора процесса функционального заказчика. Он экспертно принимал решения о том, что включать, а что не включать. Он внешний человек по отношениям к деньгам, совершенно верно. Я же получал обратную связь от подрядчика и выступал неким регулятором, тоже экспертным.
К счастью, это взаимодействие было очень эффективным. Может быть, нам повезло — все адекватные, все были в рамках курса к цели. Не было проблем. Проблемы наступили, когда нужно было закрыть договор и принять решение о прекращении дальнейших улучшений, о готовности системы.
— Можете дать пару советов небольшим компаниям, кто начинает работать с крупными игроками. Допустим, я приду в Газпром и предложу такой вариант работы. На меня посмотрят странным взглядом и скажут, что они привыкли работать не так. Как найти слова для крупных компаний, чтобы они согласились попробовать?
Как найти слова, наверное, я не подскажу. Я тот еще продавец. Но я еще раз повторюсь — у больших компаний есть правила, процедуры, как способ защиты и снятие рисков для конкретных людей. То, что здесь происходило — это не совет, но больше некоторая детализация.
В этом проекте была подготовлена визуальная схема снятия рисков, которые нам озвучил функциональный заказчик, в виде временной линии и нанесении на неё ключевых событий проекта, в том числе точек перехода ответственности и точек улучшения системы. Я сам нарисовал схему проекта, временную линию, показал, как это раньше было, и как мы будем делать теперь, указал точку перехода, когда заказчик будет визировать документы. Это был способ убедить заказчика в том, что он сохраняет контроль.
Советы на самом деле все те же самые. Надо знать заказчика, его страхи и риски, и знать системные правила компании. Тогда можно найти вариант, как, не нарушая основные правила, понимая, что же ждет заказчик, предложить вариант, который позволит реализовать проект.
— Вопрос аналогичный. Получается, в первую очередь вы были на стороне интегратора, победили прокрастинацию со стороны самого заказчика, а затем уже, находясь внутри заказчика, сделали все возможное, чтобы сам заказчик захотел это сделать. Вы в дальнейшем планируете это, как некую консультационную услугу предлагать? Тут многие думают, как он это сделал?
В формате тренинга рассказать, как устроены большие компании — было бы интересно, коллеги? ОК. Мы, наверное, победили сами себя, в первую очередь. Это победа в голове была. Нужно было отойти от желания сохранить статус-кво и найти способ добиться цели.
— Вопрос по бюджету. Как я понял, проект начался еще заранее, вы сделали ЧТЗ, все формальные документы, и поняли, что срока, который был установлен, не хватает на нормальное внедрение.
Как вы сказали, вы убедили функционального заказчика, начертив точку, когда он подпишет документы. До этого вы обязались все сделать.
Вопрос такой — как вы смогли эту точку определить, что это будет, например, в конце мая? Ведь при такой гибкой разработке — это долго и дорого на самом деле, это не быстро и дешево — пока деньги есть, вроде все работает, деньги кончились, все завершилось — в классике, да?
Мы так не можем работать. Надо заранее бюджет согласовать с директорами, со всеми учредителями компании. Мы не можем сказать, что, знаете, у нас в июне деньги кончились, а требований еще 120 лежит, надо делать. Как вы регулировали бюджет?
Это были какие-то доп. соглашения, или как? Я так понял, что с подрядчиком вы были в одной лодке, но ак это решали внутри самой компании?
Ценный вопрос. Этому предшествовало несколько обстоятельств. Первое — компания Scrum Trek в прошлом году дала статистику, что использование Scrum/Agile статистически не приводит к сокращению бюджета и сроков проекта. Я просто знал, что будет примерно то же самое.
Кроме того, я люблю читать теоретические вещи, а в теории, Scrum позволяет добиться большего качества при тех же сроках и бюджете.
У меня было представление, что представляет собой компания-подрядчик, я знал, какой результат от них ожидать. Это было волевое решение, риск. Я предполагал, что мы справимся.
Что касается управления деньгами, мы заключили только одно доп. соглашение на увеличение объема обучаемых, за счет которого немного увеличилась сумма проекта.
Складываю все 3 составляющие:
1. Я понимал, на какие риски мы идем.
2. Мы были все ограничены договором, который никто не менял.
3. Понимая, что статистически мы уложимся в этот бюджет и в сроки, мы просто эти составляющие не меняли, мы только поменяли способ реализации проекта.
Это другой подход, чем вы озвучиваете. Договор был и остается фиксированным, с четко оговоренной ценой и сроками.
— Как я понял, вы на этапе внедрения предоставили какой-то функционал, который был еще не закончен. В дальнейшем вам надо было дорабатывать тот функционал, который вы предоставляли, делать новый функционал. Но помимо этого, так как пользователи начали пользоваться продуктом, стали появляться горячие задачи. Как вы справлялись с этим потоком и как его регулировали?
И сразу второй вопрос — была ли у вас фильтрация этих ошибок. Процесс-менеджер, который вам передавал все ошибки, по сути, мог и не внедряться в суть проблемы, а просто все их складывать и вам отправлять.
Аккумулировали все запросы в одном файле. Просто организовали таким образом, чтобы происходила фиксация, фильтрация и приоритезация. В проектную команду поступал уже перечень задач, предварительно обработанный на нашей стороне. Приоритезация и фильтрация осуществлялась экспертно на основе понимания потребностей компании и содержания предложения.
Что происходило в команде подрядчика, я не знаю. Потому что я по классике сокращал число точек управления и общался только с одним человеком, который мне регулярно приносил отчетность. Я, как представитель заказчика, отслеживал неуклонное снижение количества открытых обращений.
Если обобщить ответ, то он звучит так:
1. Был четкий понятный механизм поступления запросов в проектную команду.
2. Был четкий, понятный инструмент выполнения этих запросов.
Единственное, что я регулировал — это был всплеск, когда нам надо было больше ресурсов. Было визуально видно количество задач, которые сейчас существуют, и мы обсуждали, сколько и каких людей нужно, чтобы этот объём переварить.
— А вы использовали каких-то консалтеров, тех же Scrum Trek? Или все делали сами?
Да, все самостоятельно. Чтобы использовать Scrum Trek, нужно сначала продать идею внутри компании: чтобы она нашла много приверженцев, и компания поменяла культуру.
— Извините, если не секрет, какова рентабельность проекта на выходе?
Не знаю. Это вопрос к подрядчику. Для заказчика — давайте так отвечу — этот проект вполне укладывается в среднестатистический. То есть он не идет с завышенной ценой. У нас очень жесткий контроль за этим внутри компании.
Экспертов и профессионалов мы приглашаем поделиться интересным опытом разработки или внедрения выступив на майском фестивале конференций РИТ++. В программе разные узкотематические направления, конференция по сегодняшней теме называется Web-scale IT Conference 2017, а полный список на сайте.
