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

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

Ответ на этот вопрос сильно зависит от бизнес-целей, а также от клиента.

Предприятие :

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

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

Стартапы :

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

Это также может сделать вас лидером рынка, помогая вам получить ценную долю рынка в новой вертикали, прежде чем она станет насыщенной конкуренцией.

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

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

или ... 3. Вырезать ненужную функциональность

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

Цитируя из этой книги «Переработка», сущность / ядро ​​/ эпицентр вашего программного обеспечения - это то, что нужно бизнесу для функционирования, так же, как подставка для хот-дога может быть подставкой для хот-дога без каких-либо добавок, что вы не можете вырезать, это: хот-доги.

перезаключать

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

Иногда сроки требуют программного обеспечения, работающего на тяжелом уровне производства с первого дня. Менеджеры / клиенты не всегда знают (что чаще всего), что им на самом деле нужно для программного обеспечения. Поэтому постарайтесь сократить ненужную функциональность и сохранить качество. В конце концов, это зависит от того, насколько критичной будет производственная среда, но постарайтесь исключить дополнительные функции и обеспечить качество. Цитирую еще раз из "Переработка":

Делать позже - значит делать лучше

... а также соблюдение сроков с меньшим количеством ошибок

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

Уложиться в срок и представить список известных проблем.

Люди НЕНАВИЖУ, когда находят ошибки, но если им об этом сообщают заранее, они, как правило, более снисходительны.

Это полностью зависит от ситуации ....

Есть много факторов, которые следует учитывать:

1. Насколько легко выкатывать патчи?
2. Можно ли выпустить базовую урезанную версию, а затем со временем исправить новые функциональные возможности (крайний случай)?
3. Какова общая культура индустрии клиентов для такого продукта? Ожидают ли они одноразовых совершенных релизов или они привыкли к идее развивающейся системы, которая может содержать ошибки при первом выпуске?
4. Какой риск для бизнеса представляет ошибочная первоначальная версия, а не сроки?

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

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

ПРИМЕЧАНИЕ: как программист, конечно, я предпочитаю идею как можно лучше отшлифовать продукт до его выпуска (черт возьми, я бы вообще не имел никаких сроков вообще;)). Но на самом деле это невозможно в реальной жизни. Часто урезанный начальный выпуск является хорошим промежуточным решением.

Я видел много менеджеров, которые боялись сказать клиенту, что мы не можем выполнить график, и настаивать на том, чтобы мы отправляли с известными ошибками. Я могу сказать вам, что каждый раз, когда они говорят клиенту, его обычно гораздо больше интересует меньше ошибок и сдвинутые сроки. Я гарантирую, что они будут помнить ошибки больше, чем пропущенный крайний срок, если только крайний срок не будет абсолютно неподвижен (например, начало сезона подачи налоговых деклараций, когда вы работаете с налоговым программным обеспечением) или не повлияет на некоторые другие вещи, которые будут очень дорогостоящими для перемещения (ИМХО 98% всех сроков не соответствуют этим критериям).

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

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

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

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

Ни. Почему бы не испечь качество с вашим кодом? Уметь соблюдать сроки с помощью качественного кода? Вы можете вытолкнуть меньше функций, но если качество будет включено в процесс, вы сможете достичь и того, и другого.

Что происходит сейчас, так это то, что вам понадобится уполномоченный руководитель группы или менеджер по разработке, который может дать толчок бизнесу и обсудить две вещи:

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

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

Что касается тестирования, оно никогда не заканчивается. это закончено, но никогда не закончено.

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

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

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

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

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

Это вопрос, на который только вы можете ответить. Это зависит от типа продукта, кто является клиентом, чего требует клиент и т. Д. Мы не можем дать простой ответ «а» или «б». Это полностью зависит от ситуации.

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