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

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

Отсутствие взаимодействия и процесса

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

Отсутствие единого стандарта

Стандарты бываю разными, в том числе и внутренними. Техдолг возникает при несоответствии стандартам (отраслевым, международным и другим). Также при отсутствии шаблонов для внутренней документации. Как пример, документа, описывающего стиль кодирования. А для документов с системными и бизнес-требованиями, пользовательской документации - единого словаря терминов. При этом получаем проблему связи, сложность или неоднозначность трактовок. Накапливается технический долг, чтобы привести все к единому виду. Чтобы продукт поддерживать и наращивать, придется его гасить.

Неправильная структура

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

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

Отсутствие опыта

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

Отсутствие владельца

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

Устаревание информации

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

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

Александр Кузовлев
Телеграм-канал @aheadofthepack

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

Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?

Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). Модель компетенций подробно описывает всевозможные hard-скилы - навыки, требующиеся для разработки ПО. Навыки разложены на 13 областей:

🔹 Software Requirements
🔹 Software Design
🔹 Software Construction
🔹 Software Testing
🔹 Software Sustainment
🔹 Software Process and Life Cycle
🔹 Software Systems Engineering
🔹 Software Quality
🔹 Software Security
🔹 Software Safety
🔹 Software Configuration Management
🔹 Software Measurement
🔹 Human-Computer Interaction

Основной «атомарный» элемент модели – это активность, определяющая какое-либо выполняемое действие. К примеру, Создание прототипов для выявления требований к ПО, или Проведение проверки и рецензирование кода. Активности разделены на 5 уровней повышения компетентности (Technician, Entry Level Practitioner, Practitioner, Technical Leader, Senior Software Engineer). Пользуясь этой пятиуровневой градацией, можно легко составить степени компетентности от техника до техлида и синьора по каждому из направлений - областей. Как правило техник лишь следует инструкциям, написанным другими. Синьор сам создает методы и инструкции для остальных. Чаще всего такая широкая градация даже избыточна. Вместе с тем по ней легко провести оценку текущего состояния персонала, найти слабые места команд, выявить риски и построить работающий план совершенствования и прокачки сотрудников. Для HR-менеджеров модель тоже окажется полезной для процессов найма и обучения.

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

Проекты и продукты сами не сделаются. Квалифицированная команда разработки - одна из основ и без ее развития никуда не денешься. Кто не развивает свою команду, будет платить чужой. 😊

Александр Кузовлев
Телеграм-канал @aheadofthepack