Кайдзен на наш лад или процесс улучшений в отдельно взятой ИТ-команде
Привет! QA Engineer Natlex Татьяна задалась вопросом можно ли применить кайдзен в ИТ-компании? И она смогла найти ответ на этот вопрос! В статье Татьяна рассказала о теории кайдзена, причинах выбора этой концепции, проблемах и результатах работы команды.
Немного теории
Кайдзен — одна из ключевых концепций менеджмента, в основе которой лежит непрерывное улучшение процессов производства. Это понятие возникло в Японии и означало постоянное и всестороннее развитие человека, его общественной и частной жизни, трудовых процессов.
Впервые на практике кайдзен применили японские компании, в том числе Toyota. Опыт оказался позитивным и сегодня японская философия применяется на предприятиях по всему миру. Существует даже институт по изучению кайдзен.
Каждый из этих элементов важен, так как философия кайдзен превратится в эффективный и работающий инструмент только при условии наличия всех критериев.
В России эта концепция не слишком распространена, но некоторые компании начали ее применять. Сотрудники этих компаний обучаются, создают кайдзен-команды, разрабатывают планы по внедрению улучшений и оптимизируют процессы.
Мне было интересно, можно ли применить данную концепцию в ИТ-компании. Ведь эта японская философия больше подходит для производства. В ИТ свои менталитет и культура, особенности рабочего процесса, часто применяется Agile.
Почему решили попробовать внедрить кайдзен?
Не все в команде знали о кайдзен и до этого мы осознанно не следовали его принципам и не пользовались инструментами.
Наша команда не первый день работала на проекте: мы планировали спринты, писали код, тестировали задачи. В то же время были видны недостатки, которые мешали работе, могли привести к нежелательным последствиям. Рабочий процесс не был статичным. Он периодически менялся, но больше точечно и вынуждено. И в какой‑то момент мы поняли, что нам нужны глобальные изменения.
Прежде всего мы решили, что работа над улучшением процессов — это работа всей команды. Попытка изменить процесс в одиночку не приносит результата, требуется вовлеченность, мнение и помощь каждого сотрудника.
Нами были обозначены болевые точки:
1. Труднодоступность и неактуальность документации. На тот момент требования описывались в задачах и регрессионных тестах. Функциональность менялась от версии к версии. Системы классификации задач не было. Только статьи на confluence, но без привязки к версии ПО. Поиск информации о том, как должна работать та или иная функциональность в конкретной версии, превращался в детективное расследование.
2. Многократные возвраты задач в разработку после тестирования. На момент анализа не было ясно в чем причина этой проблемы. Ко всему прочему постоянно возникали споры между тестировщиками и разработчиками о том, где будут исправления, в текущей задаче или в новой.
3. Частые ошибки в оформлении задач: незаполненные поля, отсутствие исправлений в нужной версии.
4. «Плавающий» онбординг нового сотрудника: полученная информация часто была неполной и зависела от того, кто адаптировал сотрудника.
Как мы действовали дальше?
Сначала провели работу по сбору и анализу информации для выявления болевых точек. Это была проверка полноты информации в задачах: не только требований, но и описаний результата разработки и тестирования, анализ жизненного цикла задач, причин и времени возникновения ошибок относительно спринта.
Также провели анкетирование каждого сотрудника и получили обратную связь о плюсах / минусах текущего процесса и о факторах, которые помогают или мешают работе. Мы хотели выстроить процесс так, чтобы при смене членов команды работа продолжалась и результат не страдал.
После выявления проблем разработали и внедрили меры по улучшению процесса:
1. Наш сотрудник (по совместительству автор статьи:) прошел обучение по работе с требованиями для решения проблем с документацией. Мы разработали новый процесс работы с требованиями конкретно для нашей команды. Сегодня у нас есть четкая система по «превращению задач в документацию» с поддержкой актуальности.
2. Мы проанализировали частоту и темы митингов, добавили еженедельный валидационный митинг, на котором выявляем, проверяем и обсуждаем невалидные задачи. Для валидационного митинга сделали специальные дашборды для проверки заполнения обязательных полей в задачах и поиска потерянных или зависших задач.
Предотвратить болезнь легче, чем лечить ее
3. Разработали стандарты по оформлению задач и рекомендации по описанию в задаче требований, результатов разработки и тестирования.
4. Доработали и описали процесс работы команды. Задокументированный процесс помогает уменьшить количество недочётов в работе команды и оптимизировать онбординг.
Заключение
Возвращаясь к вопросу о применимости кайдзена в ИТ, можно сказать, что у нас получился «кайдзен на наш лад». Мы не использовали все инструменты и методики этой концепции, но проделанная работа соответствует перечисленным пяти элементам кайдзен: командная работа в брейншторм-группах с личной заинтересованностью и ответственностью.
На этом наш процесс улучшений в отдельно взятой ИТ‑команде не закончился, ведь это непрерывный и цикличный процесс:)
_________________________________________________________________________
Если вас интересует ИТ-разработка, наш опыт работы и то, как мы помогаем клиентам превращать идеи в цифровые продукты, будем рады видеть в нашем ТГ-канале