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

Подразделение инжиниринга — краеугольный камень успешной технической компании, потому что каждый, от разработчика продуктов до продавца, на себе ощущает, что и как оно делает. Возможно, никакое другое подразделение не оказывает такого влияния на организацию. Чтобы ваша команда инжиниринга была нацелена на успех, обратитесь к основам или заповедям, к тому, что должно быть для нас главным, о чем мы, однако, нередко забываем.

Каждый должен знать, что он делает и почему. Это золотое правило. Главный технолог должен позаботиться, чтобы каждый разработчик знал, ради чего он работает и как его усилия позволят организации достичь поставленных целей. Для максимизации результатов можно применить систему вроде OKR (objective and key results) или подход 4DX (The 4 Disciplines of Execution).

Визуализируйте важнейшие метрики. Определите наиболее значимые метрики (качество релиза, результаты тестирования, масштабы автоматизации, предсказуемость сроков) и ознакомьте свою команду с соответствующими операционными данными. Тщательно выбирайте приборную панель, поскольку есть соблазн увлечься ее графическими возможностями.

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

Требуйте DevOps мирового класса. Успешные технические компании должны быть готовы гарантированно выпускать ПО с любой периодичностью. (Amazon развертывает новое производственное ПО каждые 11,6 с). Здесь главный технолог не может идти на уступки. Его цель — нулевое время простоя и полностью автоматизированное развертывание по нажатию кнопки при жестком контроле, который не позволит развернуть не протестированное ПО.

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

Создайте единую систему для разработчиков. Современный метод проблемно-ориентированного проектирования (Domain-Driven Design, DDD) или компонентная архитектура в качестве базы приложений позволят осуществить четкое разделение труда между командами разработчиков. Каждая из них создает не зависящие от других сервисов и самостоятельно развертываемые микросервисы. Иными словами, держитесь подальше от монолитного дизайна приложений и СУБД.

Обеспечьте автоматическое соблюдение стандартов программирования. Большинство программистов перегружены работой и уже испытывают большое давление. Поэтому имеет смысл использовать как можно больше способов автоматического соблюдения стандартов программирования. Сделайте автоматическую проверку правил частью ежедневного процесса создания ПО. Вам потребуются инструменты, которые не позволят загрузить в репозиторий какой-либо код, пока он не прошел все тесты, включая модульное тестирование и тестирование с целью выявления уязвимостей.

Отделите проверку качества от разработки. В последнее время наметился отказ от проверки качества ПО в пользу тестирования разработчиками. В защиту обоих вариантов имеются сильные доводы, но лучше разделить эти функции. Тестирование качества требует навыков, которыми разработчики не обладают, и наоборот. Тестировщики, как правило, заставляют приложения выполнять неочевидные функции и делают это, пока не будут исправлены ошибки. Тестировщики задают вопросы, которые программистам даже в голову не придут. Наконец, проверка качества помимо функционального тестирования должна включать тестирование производительности и безопасности.

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

Всегда помните, что вы — команда. Наконец, осознайте, что в высококонкурентном, очень быстро развивающемся и изменчивом деловом мире вы, как лидер, можете сохранить здравомыслие и повысить производительность своей команды (и своей компании), соглашаясь рисковать и терпеть неудачу. Развивайте культуру сотрудничества и готовности идти на разумный риск. Это самый надежный путь к успеху.