Как сократить потери на длительных проектах

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

Далее расскажем, какие трудности и особенности можно встретить при поддержке длительных проектов, где и как искать источники потерь, в частности, о методе контрольных точек. Материал может быть полезен техническим директорам, владельцам продукта, руководителям службы поддержки, особенно тем, кому приходится работать в интеграции с несколькими командами.

Учитываем особенности проектов старше 5 лет

Подходы при работе с такими проектами имеют свои особенности и затрагивают два основных аспекта:: 

• Обновления команды, оборудования и компонентов систем

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

За 10 лет работы на проекте в сфере медицины мы встречали разные ситуации — от случайной блокировки доступа к базе из-за обновлений прав доступов до смены поколений специалистов и обрыва коммуникаций между ними. К счастью, системы, которые работают много лет, имеют «историю» — через отклонение в статистике мы своевременно выявили проблемы и отработали их с минимальными потерями для бизнеса клиента.

• Взаимодействия с внешними системами

В старых проектах довольно большое количество интеграционных систем и их надо поддерживать. И у них бывают проблемы на их стороне.

Определяем источники потерь

За годы использования системы накапливается немало проблем, которые становятся причиной ограничений и простоев в работе, а значит — потери времени и денег. Источники у них могут быть разные:

• Код: например, когда пропущено бизнес-правило или есть ошибка в обработке команды.
• Оборудование: когда железо не справляется с нагрузкой или физически отказывается работать.
• Люди: незнание новыми пользователями возможностей системы, неверное конфигурирование системы администраторами на стороне заказчика, ошибки в данных и т.п.
• Внутренние и внешние системы, которые управляются и поддерживаются другими подрядчиками. Например, система Docmail, отвечающая за доставку писем до адресатов примерно 2 раза в год имеет серьезные проблемы. Они будут отражаться и на вас, при этом вы ничего не можете сделать.

Как показывает наш опыт, решить проблемы с кодом проще всего. Поэтому мы задались вопросом, что можно сделать с другими источниками потерь и можно ли их детектировать? Для решения этой задачи внедрили статистические методы контроля качества, выбрав в качестве основного метод контрольных точек.

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

Главное при выборе контрольных точек — понимать, что они касаются результатов. Для  пользователей или владельца компании важно, чтобы весь процесс работал. Если пользователь сделал запрос в саппорт, на который получил неверный ответ, ему неважно, какая команда допустила ошибку.

В каких случаях можно использовать методику

Метод контрольных точек актуален, когда требуется:

• замена компонента системы на новый, например, какого-то одного сервиса, типа базы данных, или при смене поставщика оборудования; 
• контроль эффективности всего процесса.

Если мы говорим о контроле при замене компонента системы, необходимо поставить контрольные точки на входные данные и выходные результаты и затем его менять. Потом нужно следить, чтобы контрольные точки не выходили за рамки нормы. При таком подходе контрольная точка становится вечным «сотрудником» службы контроля качества и расходы на эти цели не изменятся. 

Если мы говорим о контроле результатов всего процесса, сначала нужно выделить «явных» бенефициаров — тех, кто получает пользу от системы, а также всех, кто участвует в создании результата. Далее определяем контрольные точки для соответствующих бенефициаров и добавляем их в систему мониторинга. Покажем это на примере. 

Выстраиваем процесс: разбираем на конкретном кейсе

• Описываем бизнес-процесс и выявляем бенефициаров

В продукте для поликлиник, который мы разрабатываем и поддерживаем уже 10 лет, бизнес-процесс имеет следующие шаги:

1. Из внешней системы мы получаем информацию о запланированном визите пациента.
2. Больной может отменить визит.
3. Пациент приходит к доктору, тот его обследует и создает аудиозапись с результатами осмотра, диагнозом и назначениями..
4. Аудиозапись преобразуется в текст с заданным SLA (service level agreement). В случае нарушения SLA клиент может потребовать объяснение причин и скидку при оплате.
5. Полученный текст загружается в шаблон диагноза и попадает к врачу или к секретарю.
6. Доктор ставит цифровую подпись на документе.
7. Подписанный экземпляр отправляется в систему хранения и обработки документов госпиталя, различные интеграционные системы и пациенту, если необходимо. 

Из этого описания видно, что на проекте есть ряд бенефициаров системы: врач, пациент, интеграционные системы.

• Определяем контрольные точки 

Прежде чем создавать контрольные точки, важно понять, что не все результаты визита пациента доходят до конца. Например, больному назначили исследование, но он не прошел его. Тогда диагноз поставить нельзя и «работа отменяется». Если пациент отменил визит, результата тоже не будет.

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

Логично, что следующий отчет должен быть связан с количеством рабочих дней, прошедших от визита пациента до окончания работы. При серьезных заболеваниях этот показатель может быть значительно выше (исследования могут занять до 2-х недель). 

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

Примерный алгоритм понятен, поэтому не будем далее расписывать остальные отчеты.

• Добавляем контрольные точки в систему мониторинга

Отметим, что мы добавляли контрольные точки в уже работающую систему, и поэтому всплыла еще одна проблема — надо было разобрать зависшие дела. Поэтому мы создали ряд отчетов, которые работали на основании интервала времени и далее небольшими периодами проработали все «наследство» проблем бизнес-процессов.

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

Например, при работе с документом, туда должна добавляться информация, которая берется из внешней базы данных госпиталя. Алгоритм формирования документа не простой и надо было разделять возможные наши ошибки и не наши ошибки. Мы добавили 2 контрольных точки — количество вызовов базы данных и количество безошибочных запросов в результате вызова. Систему контроля настроили так, что число успешных вызовов должно быть не ниже 99,8%. Когда мы возникла проблема, мы поняли что она не у нас — в БД запросы шли, но все они были безуспешными. После этого мы проинформировали больницу о наличии проблем с их стороны.

Серьезных потерь или последствий для бизнеса заказчика уже нет. К тому же клиент получил еще несколько приятных бонусов. При расширении системы мы смогли: 

• уменьшить затраты на саппорт на 27%
• сократить текучесть кадров на саппорте и, как следствие, затраты на обучение новых сотрудников
• убрать нарушения SLA из-за различных факторов — клиент на этом перестал терять не менее 150 тысяч рублей ежемесячно.

Резюме: как сделать работу на длительных проектах эффективной

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

В сложных системах при быстром детектировании проблем и их исправлении они не дойдут до других частей, а значит можно предотвратить большие потери. Но даже отсутствие жалоб не может быть доказательством того, что все работает хорошо. Как правило, на одного пользователя системы, который сообщил о проблеме, приходится 10 тех, кто промолчал. 

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

Напомним, что контрольные точки выбираются на основании:

• результатов для бенефициаров системы и критически важных бизнес-результатов 
• решения о замене целого компонента системы. 

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