Стремясь к профессиональному росту, многие разработчики делают ставку на конкретные технологии, новые языки и другие аспекты, связанные с 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 таких “татуировок” – про безопасность, бэкапы, взаимодействие с внешними системами, про документацию и бизнес-процессы.
Спасибо за внимание! Надеемся, что эта серия материалов будет вам полезна.
Часть 2: https://habr.com/ru/company/simbirsoft/blog/657323/
Часть 3: https://habr.com/ru/company/simbirsoft/blog/658599/
