Жизнь — штука сложная, выкидывает порой такие забавные коленца, которые заставляют не то чтобы прыгать вперед с закрытыми глазами, скорее это похоже на попытку уехать на машине без ключей зажигания и с пустым баком. Но как показывает практика, многие веб-студии до сих пор толкают свои автомобили. Попробуем исправить это хотя бы частично.
Бывают такие проекты, когда нет возможности заниматься анализом и исследованиями так, как это принято в цивилизованном обществе. Это происходит по разным причинам: отпуска сотрудников, маленький бюджет, сжатые сроки, а иногда встречаются даже противники предварительного обследования. Практически как в известном анекдоте: «чего тут думать — трясти надо». Поэтому приходится собирать и формализовывать требования за очень короткий срок и одну-две встречи с заказчиком, который не всегда может рассказать о решаемых задачах в силу отсутствия опыта работы с сайтами.
Хлебнув несколько раз проблем с нехваткой данных для дальнейшей работы, я выработал для себя ряд мер, которые гордо назвал «виртуальной моделью» =)
Что я делаю. Сначала готовлюсь к встрече: изучаю предметную область, возможных конкурентов, их продукты, способы сбыта и любую другую информацию, которую можно найти. Выхожу развеяться и уложить полученные знания в голове, набрасывая при необходимости важные моменты в блокноте. Возвращаюсь с прочищенным мозгом и начинаю конструировать в голове виртуальную систему. Глубоко детализировать не обязательно, главное — не забыть ключевые функциональные части, характерные для компаний этой отрасли.
Например, у управляющих компаний такими атрибутами являются графики суточных колебаний индексов, котировки паев, инвестиционные портфели и другие. Далее накидываю возможный список сервисов — функциональных частей сайта: «новости», «личный кабинет», «импорт котировок с ММВБ» и так далее. После этого перехожу к структуре, и в самом примитивном виде расписываю разделы сайтов. Это все будет использоваться в качестве шпаргалки, при помощи которой я буду на встрече вести клиента по проекту.
Итак, приезжаем, знакомимся, просим кофе и фирменную ручку. Извиняемся за забытые в офисе визитки, собираемся с мыслями, ослепительно улыбаемся и вещаем:
— Я вам сейчас расскажу, как проект будет жить дальше.
Заказчик, поборов удивление (как же так, я этих людей вижу второй раз, а они мне уже что-то рассказывают), начинает слушать. Тут, главное, не выпускать инициативу. Чуть позже он и сам активно включится в процесс.
А дальше общение сводится к ролевым диалогам. Сначала я немного рассказываю о том, что мне удалось узнать про рынок, на котором он зарабатывает, и начинаю выдвигать кусочек за кусочком из «виртуальной модели» проекта:
— Продукты мы свяжем с отраслевыми решениями, чтобы была возможность выйти на страницу конкретного продукта из этой отрасли.
И так далее. Заказчик, в свою очередь, стремится его опровергнуть или дополнить:
— Хорошо, но некоторые наши клиенты подбирают решения не только по отраслям, а еще и по платформе, на которой реализовано решение.
О'кей, делаем пометку в блокноте и для себя понимаем, что у сущности «продукт» появляется дополнительный признак «платформа», который позволит в дальнейшем фильтровать продукты по платформе.
Проходит некоторое время и мы замечаем, что «виртуальная модель» обросла вполне реальными требованиями, антитребованиями, сценариями использования сервисов и данными — это замечательно и очень сильно пригодится нам в процессе проектирования.
Однако тут есть тонкий момент. Нужно донести до клиента, что это всего лишь беседа и мы не проектируем систему, а вырабатываем требования к ней. Чтобы потом не было удивленных лиц и вопросов: «ну мы же уже обсуждали это?!».
В конце беседы вырисовывается шаблон будущего проекта, который требует значительной переработки, однако имеющуюся информацию уже можно перекладывать в концепцию проекта в логических частях системы — сервисах и черновом прототипе интерфейсов.
Как правило, одной-двух встреч вполне достаточно, чтобы покрыть дефицит информации. Детали уже можно продумывать на следующих этапах.
Попутно было замечено, что в игры «я придумал, а ты сломай» заказчики играют с большей охотой, чем самостоятельно формулируют проблемы и описывают свои бизнес-процессы.
Важно понимать, что все сказанное выше — это не решение на каждый день, а способ добиться максимально хорошего результата с минимальными ресурсами, минуя фазу исследования предметной области и анализа требований. Кроме того, если вы приедете на первую встречу подготовленным и с мыслями по проекту, лояльность заказчика будет гораздо выше, чем если бы вы приехали обычным слушателем.
Конечно, большие проекты таким образом не вытянуть, лучше честно сообщить, что получится кака и увеличить сроки/бюджет, чем увлекаться «игрой», а потом поисками «слабого звена».
Успехов в разработке!
Бывают такие проекты, когда нет возможности заниматься анализом и исследованиями так, как это принято в цивилизованном обществе. Это происходит по разным причинам: отпуска сотрудников, маленький бюджет, сжатые сроки, а иногда встречаются даже противники предварительного обследования. Практически как в известном анекдоте: «чего тут думать — трясти надо». Поэтому приходится собирать и формализовывать требования за очень короткий срок и одну-две встречи с заказчиком, который не всегда может рассказать о решаемых задачах в силу отсутствия опыта работы с сайтами.
Хлебнув несколько раз проблем с нехваткой данных для дальнейшей работы, я выработал для себя ряд мер, которые гордо назвал «виртуальной моделью» =)
Что я делаю. Сначала готовлюсь к встрече: изучаю предметную область, возможных конкурентов, их продукты, способы сбыта и любую другую информацию, которую можно найти. Выхожу развеяться и уложить полученные знания в голове, набрасывая при необходимости важные моменты в блокноте. Возвращаюсь с прочищенным мозгом и начинаю конструировать в голове виртуальную систему. Глубоко детализировать не обязательно, главное — не забыть ключевые функциональные части, характерные для компаний этой отрасли.
Например, у управляющих компаний такими атрибутами являются графики суточных колебаний индексов, котировки паев, инвестиционные портфели и другие. Далее накидываю возможный список сервисов — функциональных частей сайта: «новости», «личный кабинет», «импорт котировок с ММВБ» и так далее. После этого перехожу к структуре, и в самом примитивном виде расписываю разделы сайтов. Это все будет использоваться в качестве шпаргалки, при помощи которой я буду на встрече вести клиента по проекту.
Итак, приезжаем, знакомимся, просим кофе и фирменную ручку. Извиняемся за забытые в офисе визитки, собираемся с мыслями, ослепительно улыбаемся и вещаем:
— Я вам сейчас расскажу, как проект будет жить дальше.
Заказчик, поборов удивление (как же так, я этих людей вижу второй раз, а они мне уже что-то рассказывают), начинает слушать. Тут, главное, не выпускать инициативу. Чуть позже он и сам активно включится в процесс.
А дальше общение сводится к ролевым диалогам. Сначала я немного рассказываю о том, что мне удалось узнать про рынок, на котором он зарабатывает, и начинаю выдвигать кусочек за кусочком из «виртуальной модели» проекта:
— Продукты мы свяжем с отраслевыми решениями, чтобы была возможность выйти на страницу конкретного продукта из этой отрасли.
И так далее. Заказчик, в свою очередь, стремится его опровергнуть или дополнить:
— Хорошо, но некоторые наши клиенты подбирают решения не только по отраслям, а еще и по платформе, на которой реализовано решение.
О'кей, делаем пометку в блокноте и для себя понимаем, что у сущности «продукт» появляется дополнительный признак «платформа», который позволит в дальнейшем фильтровать продукты по платформе.
Проходит некоторое время и мы замечаем, что «виртуальная модель» обросла вполне реальными требованиями, антитребованиями, сценариями использования сервисов и данными — это замечательно и очень сильно пригодится нам в процессе проектирования.
Однако тут есть тонкий момент. Нужно донести до клиента, что это всего лишь беседа и мы не проектируем систему, а вырабатываем требования к ней. Чтобы потом не было удивленных лиц и вопросов: «ну мы же уже обсуждали это?!».
В конце беседы вырисовывается шаблон будущего проекта, который требует значительной переработки, однако имеющуюся информацию уже можно перекладывать в концепцию проекта в логических частях системы — сервисах и черновом прототипе интерфейсов.
Как правило, одной-двух встреч вполне достаточно, чтобы покрыть дефицит информации. Детали уже можно продумывать на следующих этапах.
Попутно было замечено, что в игры «я придумал, а ты сломай» заказчики играют с большей охотой, чем самостоятельно формулируют проблемы и описывают свои бизнес-процессы.
Важно понимать, что все сказанное выше — это не решение на каждый день, а способ добиться максимально хорошего результата с минимальными ресурсами, минуя фазу исследования предметной области и анализа требований. Кроме того, если вы приедете на первую встречу подготовленным и с мыслями по проекту, лояльность заказчика будет гораздо выше, чем если бы вы приехали обычным слушателем.
Конечно, большие проекты таким образом не вытянуть, лучше честно сообщить, что получится кака и увеличить сроки/бюджет, чем увлекаться «игрой», а потом поисками «слабого звена».
Успехов в разработке!
