В интервью с директором по разработке IT-компании «Философт» Алексеем Щебелевым мы обсудили ключевые изменения в процессах разработки, произошедшие с внедрением методологии SCRUM. Алексей рассказал, как новый подход повысил эффективность работы команды, улучшил коммуникацию и качество продуктов. В условиях быстроменяющегося рынка такие изменения становятся не просто желательными, а необходимыми для достижения успеха.
Опишите старый процесс разработки: как всё работало раньше и что принципиально изменилось сейчас?
Ранее в нашей организации, существующей с 2022 года, процессы разработки были не настолько структурированными – задачи поступали от различных источников: руководителей, стейкхолдеров и других участников, что приводило к недостатку контекста у исполнителей. Это вызывало проблемы с соблюдением сроков и изменением приоритетов. Сейчас, после внедрения SCRUM, в планировании спринтов участвует вся команда, и каждый разработчик четко осведомлен о своих задачах на ближайший спринт. Мы проводим короткие итерации и каждые две недели предоставляем результаты пользователям, что значительно повысило качество работы и вовлеченность всех участников.
Какие главные преимущества нового подхода перед старым?
Работа стала более эффективной, а сроки выполнения задач можно прогнозировать более точно. Прозрачность процессов, которая достигается благодаря такому подходу, упрощает коммуникацию и снижает количество недоразумений.
Были ли скептики в команде? Как вы аргументировали необходимость изменений?
Да, в команде были скептики, но мы объясняли, что когда все поймут процессы, работа станет эффективнее. Если вы разработчик, вам будут приходить более качественные технические задания. Если вы аналитик, у вас появится конкретная и понятная работа. Если вы тестировщик, вы будете знать, что тестировать, имея подготовленные тест-кейсы. Мы демонстрировали, как внедрение SCRUM улучшает процессы и делает работу более понятной и качественной.
Что для вас означает «профессиональный подход»? Какие принципы обязательны в разработке?
Профессиональный подход для меня означает наличие четких принципов, таких как качественная коммуникация между участниками, прозрачность задач, внимание к деталям и, конечно, ответственность за результат.
Продукт, который мы выдаем, должен быть продуманным.
Продукт, который мы выдаем, должен быть продуманным.
Есть ли в вашем подходе что-то, что другие компании часто игнорируют, а вы считаете критически важным?
Мы считаем критически важным вовлечение всех участников процесса, включая разработчиков, тестировщиков, дизайнеров и аналитиков. Также мы акцентируем внимание на обучении сотрудников и их профессиональном росте. Более того, мы сами мотивируем их к регулярным посещениям конференций, способствующих развитию профессиональных навыков. Компания не просто поощряет выезды сотрудников на подобные мероприятия, но и полностью оплачивает их. Нам важно, чтобы команда получала самую свежую информацию и новые знания оперативно.
Замечает ли клиент (застройщик/УК) изменения в процессе? Например, скорость, качество, количество и скорость исправления багов?
Да, клиенты обращают на это внимание. Мы проводим регулярные встречи со стейкхолдерами, на которых обсуждаем новые функции и получаем обратную связь. Это позволяет нам гораздо эффективнее работать, быть более адаптивными, а клиенту оперативнее получать необходимый результат.
Можете привести кейс, где новый подход прямо повлиял на результат для клиента?
Примером успешного внедрения SCRUM является наш корпоративный портал, который мы разрабатываем с нуля. Так вышло, что его разработка как раз совпала с внедрением нового подхода. Пользователи отмечают, как много интересных обновлений и новых фич выходят каждые две недели – они каждый раз ждут, это уже успело войти в привычку. Такие результаты стали возможны только благодаря новому подходу.
Какой самый неочевидный плюс нового подхода, который вы обнаружили уже после внедрения?
Самым неочевидным плюсом стало то, что мы начали тратить меньше времени на лишние коммуникации – встреч раньше было очень много, но большинство из них были неэффективными. Теперь же это время освободилось для более продуктивной работы и креатива и дало возможность разработчикам сосредоточиться на своих задачах, уделяя им больше времени для более качественного и неординарного результата.
Что оказалось сложнее, чем вы ожидали? Что сделали бы иначе?
Довольно трудным оказался процесс планирования. Первые итерации были сложными, и нам потребовалось время, чтобы научиться правильно декомпозировать задачи и оценивать их по трудоемкости. После рефлексиии и полученного опыта, думаю, мы бы провели этот процесс иначе. Да и в целом начали бы обучение и внедрение SCRUM раньше – вот что можно было бы изменить. Но нам трудно дался именно первый шаг – предстояло разделить большую команду одного из проектов на две. Много условий мешало это сделать. Теперь мне кажется, что мы могли бы это сделать и раньше, если бы откинули лишние переживания.
Что бы вы посоветовали компаниям, которые только планируют подобные изменения?
Я рекомендую не проводить реформы ради самой реформы.
Не стоит вносить изменения только потому, что это модно и потому, что все так делают. Если у вас небольшая компания, например, с тремя сотрудниками, и вы успешно работаете по модели "водопада", где задачи просто распределяются между разработчиками без каких-либо спринтов, это может быть вполне подходящей практикой.
Однако, если вы видите, что текущие процессы неэффективны, и, например, возникают задержки среди стейкхолдеров, это может быть сигналом о необходимости изменений. В таком случае имеет смысл задуматься о переходе на методологию SCRUM. Можно либо нанять коуча, либо попробовать реализовать изменения своими силами – в зависимости от ваших возможностей.
Важно понимать, что для внедрения новой системы потребуется время, и в начале производительность может заметно упасть, прежде чем вернется на прежние уровни, а затем начнет расти. Готовьтесь к тому, что этот процесс может занять время, но в удачном случае он приведет к значительным улучшениям в работе вашей команды.
Не стоит вносить изменения только потому, что это модно и потому, что все так делают. Если у вас небольшая компания, например, с тремя сотрудниками, и вы успешно работаете по модели "водопада", где задачи просто распределяются между разработчиками без каких-либо спринтов, это может быть вполне подходящей практикой.
Однако, если вы видите, что текущие процессы неэффективны, и, например, возникают задержки среди стейкхолдеров, это может быть сигналом о необходимости изменений. В таком случае имеет смысл задуматься о переходе на методологию SCRUM. Можно либо нанять коуча, либо попробовать реализовать изменения своими силами – в зависимости от ваших возможностей.
Важно понимать, что для внедрения новой системы потребуется время, и в начале производительность может заметно упасть, прежде чем вернется на прежние уровни, а затем начнет расти. Готовьтесь к тому, что этот процесс может занять время, но в удачном случае он приведет к значительным улучшениям в работе вашей команды.
