Что действительно «достаточно хорошо» для позднего проекта?

Question

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

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

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

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

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

Answer 1

У каждого свои стандарты достаточно хорошие; на одном уровне «достаточно хорошо» - это «все, что вы можете убедить людей заплатить вам».

Однако, если вы хотите получать удовольствие от своей работы, я предлагаю, чтобы «достаточно хорошо» было «чем-то, чем вы гордитесь».

Answer 2

Клиенты управляют функциями. Они не так сильно управляют архитектурой, проектированием и тому подобным. Честно говоря, вашим пользователям может быть все равно, если вы используете строгий HTML 3.0, CSS 3.1 или XHTML. Они просто хотят, чтобы это сработало. Я обнаружил, что вам нужна команда, чтобы заботиться обо всех скрытых вещах, чтобы это было сделано правильно. Суть в том, что большинство приложений поставляются с «достаточно хорошим» кодом, потому что убедитесь, что у вас чистый код, и рефакторинг кода - это не то, что приносит деньги.

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

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