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

Question

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

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

Если вы уже сталкивались с этой проблемой раньше, нашли ли вы способ улучшить ситуацию? Или это всегда что-то вроде проблемы?

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Для улучшения я предлагаю что-то из следующего:

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

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