Насколько плавно для вас обычно запускается веб-сайт?

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

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

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

Этот подход не только сработал для меня, он заставил клиента остановиться и подумать о том, чего он / она ДЕЙСТВИТЕЛЬНО хотел. К счастью для меня, многие из моих клиентов уже технически ориентированы, поэтому они понимают, что эти вещи могут потребовать времени, но те, кто не имеет ни малейшего представления о веб-разработке, ожидают, что все станет идеально в течение пары дней. Пока вы убедитесь, что все оговорено в контракте, клиент будет думать о том, чего он хочет, и после этого не будет приставать к вам с проблемами.

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

Да, видел это несколько раз на наших проектах (люди непостоянны).

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

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

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

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

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

Это был сайт ASP.NET/C#. Он не был таким уж большим или сложным, но и не тривиальным. Вероятно, наиболее примечательным является то, что он был на 100% спроектирован, реализован и протестирован мной, от схемы базы данных до CSS. Кроме того, я впервые использовал ASP.NET. В разработке было много препятствий, но к тому времени, когда я запустил его, я был с ними хорошо знаком и поэтому знал, чего ожидать.

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

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

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

Раньше у нас было много этой проблемы, но в последнее время ее стало намного меньше.

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

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

Кроме того, мы редко делаем громкие запуски - мягкий запуск делает вещи намного менее стрессовыми.

Мой опыт показывает, что запуск веб-сайтов почти всегда затруднен. У меня было только два исключения из этой общей истины. Первым был сайт, разработанный для малого бизнеса, которым руководил один человек. Все прошло гладко, потому что был только один человек, которому можно было угодить, поэтому было довольно легко отследить, чего они хотели. Другой был многомиллионным веб-сайтом, запущенным компанией с состоянием 500. Все прошло гладко, потому что там было 2 менеджера по PM и небольшая армия консультантов для управления потребностями клиента. Это вкупе с месяцем прямого нагрузочного тестирования приложения и запуском бета-версии для 1000 пользователей означало, что, когда сайт, наконец, заработал, я смог выспаться по ночам (что довольно редко). Однако ни одна из этих ситуаций не является нормой. Конечно, нет ничего лучше, чем несколько тысяч бета-тестеров, заходящих на ваш сайт, чтобы помочь найти те непредвиденные обстоятельства, о которых вы даже не догадывались.

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

В целях улучшения я предлагаю следующее:

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

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

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

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

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