Но я тоже вас поправлю. Не все будут архитекторами. Это всегда будет небольшая группа отличных инженеров программных технологий. Такая группа не может быть большой. Тем не менее, всегда будут нужны звеньевые специалисты, реализующие архитектуру.
Возьмем, к примеру авиапром советских времен. КБ Туполева было небольшое. Но ведь для создания самолета нужны не только «туполевы». Нужны инженера, технологи, инженера-технологи, токари, нормоконтролеры и т.д.
В общем, работы-то хватает, работать надо, но… пятница. :)
А кодеры ещё долго будут востребованы, наравне с дизайнерами, потому что оба звена работают над пользовательским интерфейсом. Front-end разработчики сейчас даже более актуалены, чем раньше.
«Вначале было Слово. Потом — бюджет». :)
Самый действенный способ, как я считаю — выходить на ЛПР (Лицо Принимающее Решения), т.е. с тем, кто больше других заинтересован в сайте. Чаще всего это ТОПы. И говорить с ними на их языке. Попробуйте при удобном случае задавать контр-вопросы, типа: «На сколько, по-вашему, это поможет повысить доход компании?»
это требует от заказчика дополнительных инвестиций в раскрутку и поддержку сайта
Абсолютно верное замечание. И вывод уже озвучен автором. Перед разработкой нужно понять цели заказчика и на их основе выстроить цепочку задач. Если приоритет заказчика — привлечение клиентов через сайт на первый контакт (звонок в компанию, ориентация по ценам и последующий звонок), значит, задача менеджера — перераспределить бюджет проекта.
Если мы говорим о корпоративных сайтах, то в их большинстве (проверено не раз) есть вещи, которые можно сильно упростить. Без потери качества. Это важно. Ну не будет супер-красочных картинок, будет необходимый минимум. Не будет 2-3 страниц с корпоративной фигней (обращение директора, миссия компании), зато будет выверенный контент коммерческой информации.
Т.е. работа строится по принципу: «лучше меньше да лучше». Высвободившийся бюджет направляется на продвижение. И будут результаты, поверьте. Сайт из 4-5 выверенных страниц (без всяких платных CMS, обычной статикой) будет решать свои задачи.
Статья интересная. Но было бы лучше, если бы автор вначале явно сформулировал само определение интерфейса. Оно достаточно простое. Интерфейс — это способ взаимодействия двух сред.
В статье рассматриваются 2 среды: человек в роли субъекта и дверь в роли объекта взаимодействия. Подразумевается, что Ключ — это интерфейс между двумя субъектами. Я считаю, что это не совсем корректно. Ключ — это просто условное обозначение инструмента взаимодействия.
В роли ключа (инструмента) может быть вообще что угодно: голос, например. Интерфейс же нам определяет способ взаимодействия через инструмент. Для поворотного ключа интерфейс один (механический: вставить ключ, повернуть, вынуть), для карты - второй (считывающий: вставить карту, провести, вынуть, дождаться разрешения), для звукового ключа - третий (назвать кодовое слово, дождаться разрешения).
Т.е. интерфейс — это сочетание "чем" и "как" выполнять действие.
Для каждого экранного прототипа можно добавить описание. Модуль занимается тем, что формирует структурированный doc-файл со скриншотами экранов и добавляет им указанное описание. На самом интерактивном прототипе описание тоже видно, это достаточно удобно для разработчиков: открыл конкретную страницу и тут же видишь пояснения.
А я не согласинг с вами :) У меня на практике часто случаи, когда клиенты особо не понимают, что им на сайте нужно. Они предполагают, что сайт им полезен, но как к этому правильно подойти? Поэтому у нас "проектирование" относится к виду работ "Аналитика и консалтинг".
hoglet, у меня призрачное ощущение, что вы больше работаете с заокеанскими заказчиками. Is it?
Извиняюсь, не понял. Как это выглядит-то? Приходите в контору, раздаете всем дистрибутивы и говорите - начинаем писать на джанго? Что у вас за профессия такая интересная? :)
"Маша, новый клевый (банановый) Фейсбук, переходим все туда! Размести это сообщение на своей стене или разошли своим друзьям!" На месте Фейсбука я бы сам инициировал такой флешмоб.
Пользователям Firefox: можете поставить поисковые плагины (OpenSearch) для Tagoo и WorryAboutYou. Ссылки на XML-файлы тут, но проще сделать автоустановку с моего хомяка.
Сам считаю, что с приходом RSS должны умереть классические email-рассылки. Не сразу, но должны.
Возьмем, к примеру авиапром советских времен. КБ Туполева было небольшое. Но ведь для создания самолета нужны не только «туполевы». Нужны инженера, технологи, инженера-технологи, токари, нормоконтролеры и т.д.
В общем, работы-то хватает, работать надо, но… пятница. :)
А кодеры ещё долго будут востребованы, наравне с дизайнерами, потому что оба звена работают над пользовательским интерфейсом. Front-end разработчики сейчас даже более актуалены, чем раньше.
Спасибо.
«Вначале было Слово. Потом — бюджет». :)
Самый действенный способ, как я считаю — выходить на ЛПР (Лицо Принимающее Решения), т.е. с тем, кто больше других заинтересован в сайте. Чаще всего это ТОПы. И говорить с ними на их языке. Попробуйте при удобном случае задавать контр-вопросы, типа: «На сколько, по-вашему, это поможет повысить доход компании?»
Абсолютно верное замечание. И вывод уже озвучен автором. Перед разработкой нужно понять цели заказчика и на их основе выстроить цепочку задач. Если приоритет заказчика — привлечение клиентов через сайт на первый контакт (звонок в компанию, ориентация по ценам и последующий звонок), значит, задача менеджера — перераспределить бюджет проекта.
Если мы говорим о корпоративных сайтах, то в их большинстве (проверено не раз) есть вещи, которые можно сильно упростить. Без потери качества. Это важно. Ну не будет супер-красочных картинок, будет необходимый минимум. Не будет 2-3 страниц с корпоративной фигней (обращение директора, миссия компании), зато будет выверенный контент коммерческой информации.
Т.е. работа строится по принципу: «лучше меньше да лучше». Высвободившийся бюджет направляется на продвижение. И будут результаты, поверьте. Сайт из 4-5 выверенных страниц (без всяких платных CMS, обычной статикой) будет решать свои задачи.
В статье рассматриваются 2 среды: человек в роли субъекта и дверь в роли объекта взаимодействия. Подразумевается, что Ключ — это интерфейс между двумя субъектами. Я считаю, что это не совсем корректно. Ключ — это просто условное обозначение инструмента взаимодействия.
В роли ключа (инструмента) может быть вообще что угодно: голос, например. Интерфейс же нам определяет способ взаимодействия через инструмент. Для поворотного ключа интерфейс один (механический: вставить ключ, повернуть, вынуть), для карты - второй (считывающий: вставить карту, провести, вынуть, дождаться разрешения), для звукового ключа - третий (назвать кодовое слово, дождаться разрешения).
Т.е. интерфейс — это сочетание "чем" и "как" выполнять действие.
Но я уже давно перешел на Axure RP. И там помимо инструментария для прототипирования есть модуль подготовки спецификации, что достаточно удобно.
hoglet, у меня призрачное ощущение, что вы больше работаете с заокеанскими заказчиками. Is it?