День 2647. #ProjectManagement
Как Проваливаются Разработчики ПО. Начало
«Разработчики ПО терпят неудачу двумя способами: они либо делают продукт не так, либо делают не тот продукт».

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

1. Неправильная разработка продукта
Техническое исполнение неверное. Требования могли быть поняты правильно, но реализация была ошибочной. Например:
- Ошибки, вызывающие некорректное поведение;
- Низкая производительность, делающая ПО непригодным;
- Уязвимости безопасности, подвергающие пользователей риску;
- Хрупкая архитектура, которая затрудняет обслуживание или расширение системы;
- Код настолько сложный или запутанный, что никто не может безопасно его изменить.
Про эти неудачи мы чаще всего говорим. Проверки кода, автоматизированное тестирование, статический анализ и конвейеры CI/CD, существуют в первую очередь для того, чтобы выявлять и предотвращать подобные неудачи.

2. Создание неправильного продукта
Техническое исполнение может быть безупречным, но ПО не решает нужную проблему. Продукт компилируется, запускается и может работать без проблем. Но есть признаки того, что вы создали не то, что нужно:
- Решает проблему, с которой на самом деле никто не сталкивается;
- Решает проблему, которая никому на самом деле не важна;
- Решает вчерашнюю проблему, а не сегодняшнюю;
- Предоставляет функции, которые запрашивали пользователи, но не то, что им действительно было нужно;
- Делает неверные предположения о том, как должно быть реализовано решение.
Это более тонкий и часто более дорогостоящий случай. Прекрасно разработанное, безошибочное и производительное приложение может не приносить никакой пользы, потому что оно изначально решает не ту проблему. Все усилия потрачены впустую.

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

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

Более опасная ошибка — успешный выпуск чего-то, что не нужно. А иногда и нежелательно. Это может создать у команды разработчиков ложное чувство успеха, которое затем приводит к ещё большему разочарованию, когда им приходится откатывать изменения или вносить серьёзные обновления. Почти всегда это ошибка в коммуникации, а не в навыках программистов, и усилия, необходимые для её исправления, обычно более масштабны, постоянны (нельзя просто добавить ещё один этап сборки) и, вероятно, затронут несколько команд внутри организации. И Scrum, и XP предполагают наличие в команде разработчиков эксперта в предметной области, представляющего заказчика, но организации редко нанимают такого специалиста. Чаще это делается кем-то не связанным с командой разработчиков, кому отводится дополнительная роль «владельца продукта» или «эксперта в предметной области», чтобы разработчики могли обращаться к нему с вопросами и, возможно, периодически встречаться, и его вряд ли можно считать полноценным членом команды.

Продолжение следует…

Источник: https://ardalis.com/how-software-developers-fail/