Технический директор ID Finance (среди активов проекты MoneyMan и AmmoPay) Павел Шарейко рассказывает, как организовать работу IT-департамента так, чтобы оптимизировать бюджет компании.
Сегодня под брендом MoneyMan финтех-компания ID Finance развивает онлайн-кредитование не только в России, но и еще в 6 странах по всему миру. Безусловно, сердцем любой онлайн-компании является департамент информационных технологий. Целью организации IT в компании является не только обеспечение комфортной работы всего коллектива, но и обеспечение условий для получения максимально эффективного результата.
В век современных технологий даже самая современная IT-инфраструктура уже завтра может не справиться со всеми возложенными на неё задачами, что может привезти к коллапсу.
Для получения максимального результата и эффективной работы в MoneyMan внедряются особые инструменты, делающие организацию труда более продуктивной.
Эффективная система оценки качества разработки
Одним из таких средств является система оценки качества работы всех членов команды по ключевым показателям (KPI). Исходя из определенных оценок, формируется представление о том, как сотрудник работает с задачей и как много совершается ошибок.
Таким образом, выявляются проблемные проекты, на которых стоит остановиться подробней, а также складывается общая картина эффективности работы как всех сотрудников, так и каждого по отдельности.
Рис. 1. диаграмма качества работы одного из отделов (соотношение потраченного времени на дефекты ко времени потраченного на задачи). Own – время разработчика реализующего задачу, Dev – время, потраченное всей командой (дефекты одного человека часто помогают закрывать коллеги), All – время, потраченное на дефекты всего IT (DEV, BA, QA).
Рис. 2. Усредненное затраченное время разработчика по типам работ в одном из отделов разработки.
Agile
Еще один инструмент по обеспечению эффективной работы IT — методология Agile с применением технологии двухнедельных спринтов. Весь процесс разработки распределяется на 2 недели, в течение которых исполнители трудятся над задачами. В процесс включаются этапы оценки и разработки, также отдельная и значимая роль отводится контролю.
Без применения технологий контроля разработчику трудно ориентироваться в задачах: их неравномерное поступление и отсутствие контрольных точек приводят к беспорядку. Как итог, сотрудник не успевает выполнить заданный план и нерационально распределяет свои ресурсы. Для оптимизации этого процесса добавляется ряд метрик, по которым изображается график.
Диаграмма «сгорания» задач (Burn down)
Для растущих финтех-компаний существует проблема, когда из-за большого количества объема задач разработчики начинаются теряться в сроках их выполнения и не имеют четкого представления об отставании или опережении графика выполнения задач.
В системе оценки и мониторинга разработки мы применяем диаграмму Burndown, отражающую количество сделанной и оставшейся работы по соотношению к запланированной.
- Чтобы сориентировать сотрудника, задачи делятся на более мелкие, и в дальнейшем распределяются, в какой день и сколько времени нужно потратить на конкретную задачу.
- Параллельно с выполнением разработчик указывает в BugTracking системе различные статусы готовности.
- Все эти данные вводятся, отслеживаются и в итоге представляются в цифровом и графическом формате.
Практикуя такой способ работы в команде, добиться максимальной эффективности удалось не сразу. Изначально графики были слишком усреднены и не представляли реального положения дел.
90% разработчиков укладывались в срок, а остальные 10% настолько не успевали, что приходилось значительно смещать даты и задачи, хотя в среднем ситуация оставалась в норме.
Постепенно был осуществлен переход с таких графиков на индивидуальные метрики, а также по отделам. То есть, мы пришли к тому, что у каждого разработчика имеется личный график с запланированным на него временем для выполнения задач.
Рис. 3. Диаграмма сгорания задач одного из спринтов.
Плюсом этой системы является и то, что в процессе работы возможна переоценка задачи в случае изменения ситуации. При этом в зависимости от обстоятельств разработчик может продолжить работу с определенным уровнем риска или же, наоборот, если его ресурса физически недостаточно, — подключаются дополнительные ресурсы, или задачи исключаются вовсе.
Вся система работает автоматически, и любые изменения учитываются программой. Таким образом, появляется возможность не только рационально распределять задачи и следить за объемом работ, но и мобильно реагировать на любые колебания.
Диаграмма Ганта
Рис 4. Частичная диаграмма Ганта для одной из команд разработки.
Часто можно столкнуться с тем, что при получении пакета задач разработчик в первую очередь берется за те, которые ему кажутся более простыми или интересными.
Сложные задачи, несущие большое количество рисков, как правило, откладываются на «потом» и могут остаться незакрытыми из-за позднего исполнения.
Второй момент — отдел QA физически не может все самые сложные задачи протестировать в сжатые сроки, поэтому требуется их равномерное поступление. Здесь встает вопрос распределения приоритетности задач, и решается он с помощью диаграммы Ганта.
- Изначально приоритет формируется аналитиками и заказчиками на стороне бизнеса с учетом важности каждой из задач.
- Затем он может быть скорректирован другими отделами, учитывая новые факторы, возникшие во время разработки.
- Согласно учтенным приоритетам задачи выстраиваются по порядку для каждого разработчика. Дополнительно учитываются рабочие и нерабочие часы, и столбец, показывающий какую-либо задачу, сокращается на графике по мере ее выполнения.
- Теперь разработчик работает строго над той задачей, которая, согласно системе приоритетов, представлена на графике.
Для команды QA график показывает ориентировочное время завершения работы по каждой задаче, что позволяет спланировать время на тестирование или заметить проблемные участки, например, концентрацию сложных задач в конце спринта.
Анализ дефектов
Рис. 5. Таблица для анализа задач и дефектов, разбитых по группам, с возможностью просмотра детальных фильтров.
В нашей команде применяется ряд систем по анализу дефектов.
Для работы с ними изначально определяется, сколько было дефектов в задачах и какое количество времени разработчиками или всем штатом было на них потрачено. В зависимости от этого можно обнаружить проблемные задачи. Сюда прибавляется система анализа задач поддержки (обращения пользователей).
В начале нашей практики пришлось столкнуться с тем, что это отнимает около 20% всех временных затрат. Были найдены точки оптимизации.
Например, когда компания только начинала свою деятельность и штат был минимальным, то система обращения пользователя работала исключительно через разработчика, то после обнаружения проблемы со временем разработчики были исключены из этого процесса, и поддержка уже напрямую работала с клиентом.
Такой ход освободил 10% времени разработчиков. Отметим, что временной ресурс также отслеживается в программе, есть возможность проводить его мониторинг и анализ.
Ретроспективный анализ
Система оценки помогает определить, сколько времени было затрачено на выполнение определенной задачи, например, исправления дефектов, с которыми могут справиться и другие подразделения без помощи разработчиков.
Это позволяет освободить их время для выполнения функциональных задач. В ID Finance есть основные метрики, которые мы собираем и на их основе можем принимать решения. Мы выбираем гипотезу и смотрим, как она реализовывается.
Рефакторинг (Обновление кода)
Фиксирование метрик дает возможность анализировать влияние новых подходов в разработке, управлении, в том числе и рефакторинге.
Рефакторинг – это избавление от «спагетти кода». В связи с тем, что постоянно пишутся новые массивы кода, внедряются новые продукты, сервисы и возможности, рефакторинг должен быть перманентным.
Если рефакторинг не проводится, то в будущем любой код, при большом количестве изменений, превращается в «спагетти». Это связано с тем, что разработчик не может анализировать все и сразу, при выполнении своей конкретной задачи. Поэтому в компании есть люди, которые выполняют задачи и те, кто анализирует ситуацию в целом, осуществляя рефакторинг.
Мы видим, что после рефакторинга дефектов в работе становится меньше или задачи выполняются быстрее, это означает, что мы двигаемся в верном направлении.
Важно отметить, что решение, которое было принято раньше в какой-то момент может начать не соответствовать высоконагруженной системе и его нужно рефакторить. Так как код будет тормозить и работать не эффективно.
Идея дороже денег
Каждый раз, когда речь заходит о внедрении того или иного ИТ-решения, то первым возникает вопрос о необходимом для внедрения процесса времени, а вторым – о стоимости решения.
Первоначальная версия системы была написана за неделю и устанавливалась один день, но главное здесь — не реализация программы, а потребности именно нашей команды и внесение доработок для их удовлетворения.
Перечисленные мной инструменты по отдельности внедряются на многих предприятиях, круг их применения широк, но среднестатистическая программа не учитывает нюансов отдельной организации. Именно поэтому такие продукты должны постоянно изменяться под индивидуальные потребности конкретных компаний в зависимости от сферы их деятельности.
Если бы мы заказали такую систему у вендоров, ее цена превысила бы $50 тысяч. Самое дорогое в такой работе – идея.
Материалы по теме:
«Талантами могут быть все» – вице-президент по персоналу Mail.Ru Group о том, как управлять IT-специалистами
«Потенциал роста неприлично высок, а суперигроки стагнируют» – что происходит в телекоме
«Потенциал роста неприлично высок, а суперигроки стагнируют» – что происходит в телекоме
5 причин перейти на IT-аутсорс
7 главных IТ-трендов текущего года: от директора по интернету вещей до 8K-мониторов
«Компетентность не имеет пола». Истории девушек, которые пишут код
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
- 1 Могут ли боты заменить HR-специалистов? Мнения экспертов
- 2 Как перестать совещаться ни о чем, но быть в курсе всего
- 3 Бирюзовый автопилот: три ошибки самоуправления
- 4 Десятки умерших бабушек и температура под 40 — как работать с фрилансером, чтобы потом не было мучительно больно
- 5 Пять доказательств того, что клиент не всегда прав
ВОЗМОЖНОСТИ
29 апреля 2024
30 апреля 2024