Каковы основные вопросы, которые задают человеку, который хочет, чтобы его сайт среднего размера был выполнен?

Ответ 1

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

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

Какова цель веб-сайта, который вы просите меня построить? Это, как ни удивительно, часто упускается из виду. Предприятия малого и среднего бизнеса часто используют подход 1) сделать сайт, 2)????, 3) прибыль! Удостоверьтесь, что у них есть план интеграции веб-сайта в их бизнес. Статический, устаревший сайт, полный бесполезной информации, почти хуже, чем ни один веб-сайт вообще.

Насколько техничны ваши пользователи?. Это имеет широкие последствия. Например, менее технические пользователи будут вызывать более высокую долю рынка IE6, поэтому вам придется разрабатывать их соответствующим образом. Старшим пользователям может потребоваться больший размер шрифта. Список можно продолжить. Знать своих пользователей очень, очень важно. Например, Qaru использует синтаксис "markdown", потому что его пользователи являются техническими и могут его проверить.

Будет ли ваш сайт нуждаться в интернационализации?. Это полностью зависит от компании, но на рынках, где есть большое количество динамиков <insert non-English language>, интернационализация может быть ключом к вождению бизнеса на сайт.

Готовы ли вы полагаться на свои знания? Это важно, потому что чаще всего владельцы бизнеса считают, что <blink> просто uber cool. Убедитесь, что вы находитесь на сиденье водителя. Слушайте их предложения и приспосабливайте их, но только там, где это имеет смысл. Не ставьте под угрозу свой смысл дизайна в их интересах, потому что этот сайт будет в вашем портфолио и, следовательно, будет размышлять о вас.

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

Узнайте свой продукт внутри и снаружи. Не вопрос, но отличный совет. Это повысит качество всего продукта, который вы поставляете (веб-сайт).

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

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

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

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

Ответ 2

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

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

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

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

Масштаб также будет таким, как в том, что мы называем "средним" с точки зрения его производственной среды? Средний веб-сайт среднего размера от Amazon, Microsoft или Google, вероятно, будет содержать тысячи машин, учитывая размер компании, в то время как другие могут считать более чем небольшим, чтобы быть средним.

И последнее, но не менее важное: отбросьте требования. Это относится к юридическим требованиям в некотором смысле, когда вы создаете его для $x, и он хочет приложение, которое выполняет a, b и c.

Ответ 3

Некоторые из них похожи на г-на Бренделя, но, надеюсь, я добавил ценность. В определенном порядке:

• Почему вы создаете это приложение? (Опишите, как выглядит "счастливая конечная точка" для этого веб-приложения.)
• Реализуем ли мы новые процессы/модули/функции или просто автоматизируем существующие процессы/модули/функции? (Последнее легче, чем первое.)
• Каковы процессы/модули/функции в области применения этого приложения? Кто их определяет?
• Какова общая бизнес-модель клиента? Где сенсорные точки между приложением и этой моделью? На сколько это влияет?
• Какое значение предоставляется? Как это будет измеряться? (Тесно связанный с первым вопросом...)
• Кто собирается использовать веб-приложение? (Веб-приложение должно быть спроектировано с учетом конечных пользователей.)
• Кто такие "заинтересованные стороны"? (IOW, кто собирается извлечь выгоду или проиграть прямо из проекта? Конечно, это не так, но что, если партнер должен проскользнуть? Кто этот человек (-ы), на что это будет отражать?)
• Какой у вас бюджет, если он есть?
• Какая дата смерти от "мертвого" или "живого", если таковая имеется?
• Есть ли у вас какие-либо правила/процессы для взаимодействия с внешними/внутренними разработчиками? (Например: требования к отчетности, стандарты кодирования и т.д.)
• Технически ли он интегрирован с чем-либо еще или автономным?
• Визуально ли он интегрирован с чем-либо еще или автономным? Какие характеристики/атрибуты/отношение должны передать сайту пользователям?
• Заменяет ли что-нибудь? Если да, то что и почему?
• Какой "серверный стек" будет развернут? Какие технологии должны использоваться, если они есть?
• Каковы "жесткие показатели", которые должны выполняться, если они есть? (Ех: Должна иметь возможность вводить 1000 запросов/мин.)
• Каковы требования безопасности проекта?
• Кто будет тестировать/проверять прототип? Каковы их потребности/ожидания для проведения тестирования/проверки?
• Кто будет поддерживать веб-приложение? Каковы их потребности/ожидания для обслуживания?
• Кто будет поддерживать какой-либо статический контент? Каковы их потребности/ожидания для обслуживания?
• Кто будет обучать пользователей? Каковы их потребности/ожидания для проведения обучения?

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

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

Надеюсь, это поможет. Сбор требований - это в значительной степени искусство, а не наука...

Ответ 4

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

Это самый простой способ установить начальный набор требований.