Стремясь к профессиональному росту, многие разработчики делают ставку на конкретные технологии, новые языки и другие аспекты, связанные с IT. При этом IT-решение – часть бизнес-процесса, которая делает его быстрее и эффективнее в том случае, если сам процесс выстроен правильно. Если он неверный, то хорошая IT-часть ускорит “проявление” ошибок, но не исправит их, не предотвратит возможные потери. Есть области, где цена ошибки может быть очень велика, например, в медицине.

Ценность IT-специалиста зачастую повышается по мере того, как он на своем проекте осваивает не только программирование, но и смежные области – аналитику, основы работы с большими данными, работу на саппорте, управление командами. Об этом погружении “в глубину IT” рассказывает Алексей – один из наших опытных программистов. После 7 лет разработки он возглавил саппорт на своем проекте и готов поделиться опытом, к чему это привело.

“Как говорится, если вы хотите быть лучшим, вам надо войти или в 1% лучших в определенной области, или в 15% лучших в двух смежных областях, или в 30% лучших в трех смежных областях. При этом усилия, затрачиваемые на то, чтобы стать лучшим в конкретной области, возрастают по экспоненте”, - отмечает наш коллега.

Предыстория

Уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей. Система обеспечивает ряд шагов бизнес-процесса. Общий программный комплекс состоит из 8 подпроектов. Автор статьи отвечает за 2 подпроекта и различные интеграции с другими. Эти 2 подпроекта тесно связаны и имеют следующие части:

  • десктопное приложение, которое работает со своей локальной БД SQLite (мы не можем терять данные, если есть проблемы сети между приложением и сервисом для него) на Windows Forms и WCF;

  • сервис для работы с десктопным приложением, которое работает с главной базой данных MS SQL;

  • веб-админка на ASP.NET;

  • веб-приложение для утверждения документов и других необходимых действий для докторов на ASP.NET MVC;

  • сервис для веб-приложения;

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

  • Reporting Service для отчетов;

  • сервис для выполнения логики бизнес-процессов;

  • сервис для интеграции с “внутренними” интеграционными системами из других подпроектов;

  • сервис для интеграции с “внешними” интеграционными системами.

На старте на разработку и саппорт накладывало свой отпечаток то, что мы “унаследовали” систему после нескольких предыдущих команд с разными подходами к организации работы. Кроме того, ряд своих особенностей был в различных госпиталях и в целом в сфере здравоохранения в государстве клиента. При этом саппорт состоял из трех линий:

  • Команда поддержки на телефоне/в чатах на стороне Великобритании: клиент создает задачу в Jira на доработку.

  • Технические специалисты на стороне клиента. Задача второй линии – провести исследование на боевом сервере, понять, что не так, суть ошибки и что надо сделать, чтобы улучшить ситуацию.

  • Наша команда. Задача третьей линии – реализовать кодовое изменение и сделать деплой улучшения на сервер.

На нашей стороне было несколько специалистов, которые работали на саппорте. Однажды глава третьей линии саппорта сообщил, что через несколько месяцев покидает свою должность. А через 3 недели ушел глава второй линии саппорта со стороны наших британских партнеров. После обсуждения было принято решение передать нашему коллеге – Алексею.

На тот момент он работал с системой уже 7 лет и хорошо знал её особенности: участвовал в разработке многих компонентов, познакомился с профилированием производительности, использования памяти, диска, работой с базами данных, технологиями LINQ (с учетом того, что проект очень “старый” в то время это была самая современная технология), Entity Framework, Dapper и многими другими вещами. 

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

Погружение в проект: первые шаги в улучшении процессов саппорта

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

В общей сложности за несколько месяцев ушли три человека из пяти: один сменил проект, второй перешел в управление и третий – в другую команду. Для замены были добавлены 2 новичка на саппорт и QA. Планировали взять еще одного человека, но поняли что это будет ошибкой – на нового сотрудника надо тратить время для ввода в проект, а именно время было строго ограничено. Нужно было срочно – за 6 недель – разобраться в подводных камнях, принимая проект от бывшего ведущего “саппортовца”.

Ситуация была критической, т.к. проект большой – более 100.000 строк C#. Это был сложный челлендж, фактически целью было выжить.

Итак, что мы делали:

  • «Подтянули» новичка в предметной области, интенсивно его обучали в главном офисе.

  • Поняли, что решить все старые задачи невыполнимо, нужно что-то менять. Но при закрытии задач “в уме” собирали статистику по типам и частоте запросов.

  • Отсеяли устаревшие задачи, которые были созданы более 2 месяцев назад. Вместе с тем нашли 30-40 задач без метки саппорта: выбрали их из треда «без метки», добавили метку – иначе они не отображались в задачах саппорта. 

  • Нашли первое место для улучшения: сделали отдельный проект в Jira. До этого задачи саппорта создавались в том же проекте, что и задачи для разработки, но с пометкой Support. Это был первый шаг в улучшении процессов на саппорте.

  • При закрытии старых задач с главой саппорта обнаружили проблему: одна часть задач создана как баги, другая – как таски, а это разные воркфлоу в джире. При этом 2-4 задачи в неделю терялись. В результате решили составить для них общую карту «состояний» (см.рисунок). Это стало следующим шагом в улучшении процессов саппорта.

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

На основании собранной статистики поняли: нужно временно начать перерабатывать, чтобы впоследствии ускорить работу. Иногда для ускорения каких-либо действий саппорта в таких длительных проектах, как наш, нужно 3-4 часа программировать, чтобы потом сэкономит 5-7 минут исследования определенных типов запросов, в первую очередь повторяющихся.

  • Мы создали специальную страницу-саппорт с инструкциями и готовыми кнопками: “как фиксить различные классы проблем в админке”. В итоге время фикса некоторых классов проблем сократилось с 2-4 часов до 1 минуты. Причем за 3 месяца по этому алгоритму не удалось исправить только один-единственный (!) баг. Мы не гнались за идеальным решением, первой целью было сделать решение 95% случаев в каком-либо классе проблем быстрым, оставив только 5% для “ручного” исследования. Самый главный результат - снизилась нагрузка на саппорт.

Как выглядел процесс ранее: Завести баг в джире, слинковать с джирой заказчика, передать на обработку, подтвердить закрытие, спросить у пользователя, закрыть в джире заказчика.   

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

Это позволило 99% запросов исправлять за 1 минуту. А после обновлений до последних версий многие баги исчезли.

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

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

Наблюдения и выводы по итогам первых месяцев в саппорте

По итогам первых месяцев работы мы поняли:

  • Задачи нужно решать не в порядке очереди, а в порядке срочности, поскольку в саппорте важнее всего оперативность. 

  • Вопросам саппорта незаслуженно уделяют мало внимания, хотя работа с ними может серьезно улучшить процессы.

После того, как нам удалось обнаружить и устранить “слабые места” в процессах, на саппорт мы стали тратить всего 2 часа ежедневно вместо 12-16 часов, как было ранее. Все задачи разделяем по зона ответственности среди команд саппорта. С учетом этих изменений на саппорте работать специалистам стало комфортнее.

Также ежедневно отправляем автоматический отчет по всем задачам саппорта, которые находятся в реализации, в том числе просрочены более чем на 2 дня. Это позволяет понимать, какая задача “подвисла”, мотивирует на поиск и устранение причин.

К каким выводам мы пришли?

Во-первых, любой продукт для работы с людьми требует учета всей “цепочки” ценностей, связанных с бизнес-процессом. IT-часть – это только одно звено, которое отвечает лишь за техническую реализацию идеи. Поэтому если она не имеет бизнес-логики, даже самая безупречная система не поможет. 

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

В-третьих, вариантов развития программистов много, совершенствоваться можно и в смежных к программированию областях. Это можно увидеть на примере нашего коллеги, который более 9 лет работает на одном зарубежном проекте и пока не испытывает желания сменить его. Как поясняет Алексей, здесь он может самореализовываться, применять свои знания и практический опыт для улучшения работы системы и видеть результаты. К тому же за такой длительный срок можно глубоко изучить не только сам продукт, но и конечных пользователей, чтобы в итоге предотвращать потенциальные риски на проекте и работать в штатном режиме.  

Выбрав путь “расширения кругозора”, автор статьи успешно прошел 6 сертификаций в смежных с кодингом областях: 

  • PRINCE2® Foundation Certificate in Project Management

  • Foundation Certificate in Risk Management

  • ITIL® Foundation Certificate in IT Service Management

  • Test Engineer Certificate

  • Business Information Management Foundation

  • IT Service Management Foundation

Как мы уже упоминали, на саппорте часто встречаются такие кейсы, о которых не пишут в книгах. Они очень помогают развиваться, в том числе как программисту. Каждый из них привел к появлению тех или иных “татуировок IT-специалиста”, которые теперь всегда учитываются при постановке задач. В следующей статье мы рассмотрим 7 таких “татуировок” – про безопасность, бэкапы, взаимодействие с внешними системами, про документацию и бизнес-процессы. 

Спасибо за внимание! Надеемся, что эта серия материалов будет вам полезна.

Комментарии (0)