Хаос или порядок: внедряем культуру разработки для лучших результатов

Нужна ли культура разработки?

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

Культура разработки представляет собой комплекс правил, стандартов, процессов, инструментов и практик, которым следуют разработчики, QA и другие сотрудники ИТ-компании. Она помогает:

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

Код крайне редко является продуктом одного разработчика, с ним работает вся команда: читают, проводят ревью, рефакторят.

Если код слишком связный, больше вероятность все сломать при незначительном изменении, что может демотивировать любого специалиста. 

Когда соблюден стандарт оформления кода (он достаточно задокументирован, покрыт unit-тестами на необходимом уровне), с ним проще работать и разработчикам, и QA, и аналитикам, и продакт-менеджерам. Если появится баг, все поймут, что делать и где его искать.

В компаниях с развитой культурой разработки четко обозначены роли внутри проекта, понятно, кто и какими вопросами занимается.

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

Соблюдение правил, стандартов и шагов помогает делать все быстро и качественно, планировать и структурировать работу на проекте.

Например, дает команде возможность понять, где они находятся в настоящий момент и что будет дальше.

Но культуру разработки нельзя купить или ввести распоряжением. Формируется она в течение длительного времени: в нашей компании этот процесс начался более 20 лет назад, с момента ее создания.

Программисты-основатели внедряли ее через личный пример и написание стандартов, гайдов. Далее подключились руководители подразделений и менторы. 

Разумеется, на формирование стандартов, закупку программных продуктов, workflow проекта, на договоренности и развитие сотрудников компании потребуются ресурсы (экспертиза, время, финансовые вложения).

Но эти инвестиции окупятся, так как позволят эффективнее работать на коммерческих проектах.

Развитая культура разработки помогает не тратиться на разбор хаоса, конфликтов, на изменения после code review и многое другое.

Не все сразу: внедряем и развиваем

Передача культуры разработки в ИТ-компании в 90% случаев происходит от человека к человеку во время совместной работы.

Она проходит через весь «жизненный цикл» человека в компании.

Ее нельзя насадить, просто заставляя сотрудников читать описания (стандарты, гайды, шаблоны и правила) в самом начале их работы.

Нужен личный пример и опыт – по-другому не получится.

Транслируют культуру люди: руководители, тимлиды, менторы и эксперты компании, ключевые разработчики.

И здесь критически важны именно первые проекты и менторы.

Наблюдая за опытными коллегами, как они организовывают работу на проекте, новички наследуют культуру и придерживаются ее в дальнейшем. 

Для передачи культуры разработки новым сотрудникам потребуются ресурсы на:

• Объяснение правил: стандартов ведения проектов, управления ветками и создания стендов в git, ведения тестовой документации, документации к коду, к API и прочего.

Стандартизация работы и процессов помогает не допустить ошибок. 

• Обратную связь: здесь срабатывает контур управления. Когда человек пришел на проект, ментор поставил задачу, рассказал, как ее делать. После того, как тот ее сделал, наставник оценил: если сотрудник где-то допустил ошибку, ментор дал ему обратную связь, объяснил, подсказал, что подкорректировать и где посмотреть информацию на эту тему. Так развиваются не только новички, но и сами менторы. 

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

Помимо правил и обратной связи, развитию культуры разработки способствуют:

• Обмен опытом и экспертизой

Для развития культуры разработки важно поощрять идею распространения экспертизы, обмен опытом и лучшими практиками на интенсивах и практикумах внутри компании и за ее пределами.

Это также позволяет прокачивать хард и софт скилы сотрудников и находить качественные решения конкретных задач на проектах. 

• Обучение

Компании с развитой культурой разработки выстраивают вектор обучения и план повышения квалификации всех специалистов.

Сотрудникам не приходится тратить свое время на то, чтобы разобраться в современных трендах, выбирая тему для изучения, чтобы им это помогло в работе. 

В компании обычно ведется подборка актуальных для развития направлений по конкретной специализации. 

• Управление

Развивать культуру разработки помогает система управления и контроля.

Проверить соблюдение гайдов и соответствие процессов стандартам компании можно во время аудита (team review, performance review, оценка 360 и другие системы обратной связи) и других точек проверки исполнения процессов (инструменты – code review, таск-трекеры, метрики и пр.).

Один из инструментов управления культурой разработки – оценка ее соблюдения сотрудниками с помощью чек-листа.

Чтобы сосредоточиться на оценке именно культуры кода, важно обеспечить сотрудникам максимально комфортные условия работы, выстроить процессы так, чтобы исключить разные факторы и сделать эту оценку более объективной.

Чек-листы для сотрудников

Чек-лист можно использовать разово или периодически для анализа развития специалиста. В нем обычно отражены следующие блоки для оценки:

• Соблюдение workflow, документации.
• Знание жизненного цикла задач, приоритетов, требований к ведению задач и сроков.
• Соблюдение стандартов и принципов написания кода, требований к его безопасности, отказ от антипаттернов.
• Своевременное оповещение о проблемах.
• Покрытие unit-тестами основной части бизнес-функций, тестирование и запуск кода до передачи QA-специалисту.

Примеры вопросов:

• Следует ли специалист стандартам оформления кода языка разработки? Использует ли эффективные структуры данных и алгоритмы? Документирует ли свой код, не оставляя лишних комментариев? Готов ли писать код без посторонней помощи? 
• Знает ли он критерии готовности задачи к тому, чтобы взять ее в работу, и критерии полной готовности задачи/проекта?
• Предупреждает ли о том, что в задаче есть противоречия?
• Способен ли он самостоятельно оценить задачу? Как часто попадает в свою оценку?

Если команда большая, оценка по чек-листу проводится в формате кросс-ревью, когда к этому процессу привлекается не только тимлид, но и внешние консультанты.

Но, как правило, в опросе участвуют двое: специалист и эксперт. В роли последнего может выступать тимлид, техлид или любой опытный сотрудник. 

Сначала сам специалист определяет соответствие требованиям чек-листа.

Далее тимлид на основании практической деятельности в команде проводит оценку соблюдения сотрудником культуры разработки.

Для этого он использует разные инструменты, в том числе таск-трекер.

Моменты, связанные с чистотой кода, эксперт может отметить для себя во время проведения code review. 

После оцифровки результата определяется, соответствует ли он стандартам компании. Отклонение от «идеала» – повод для реакции:

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

Универсального решения, которое поможет в любом проекте, нет, ведь на результат могут оказать влияние разные факторы.

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

Фото на обложке: Photomery/Shutterstock