Теория ведения IT проекта

Материал из AOW

Перейти к: навигация, поиск
Внимание! Эта статья требует доработки.

Содержание

Что такое «хорошее» ТЗ на сайт?

File:Teoria_vedenia_IT_proecta.gif

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

Вводная

Зачем составлять техническое задание (ТЗ) на сайт? Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: "А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?" В разработке как ПО, так и любого сайта частая проблема - никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?

   Следствие закона Паркинсона "девяносто-девяносто":
   Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.
   Из книги А.Купера "Психбольница в руках пациентов".

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

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

Добавлю ограничения. Всегда когда я говорю о написании ТЗ, то имею в виду, конечно же, каскадную методику разработки. В случае других вариантов (например, экстремальное программирование) составляются другие документы и часто по другим принципам. Это - раз.

Стоит разделять ТЗ для малых и больших сайтов. Это - два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько "отделов", а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

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

Мы будем следовать самому сложному пути.

ТЗ отвечает на вопросы

ТЗ изначально создается для нескольких участников разработки:

  1. Разработчики проекта (дизайнеры и программисты).
  2. Проект-менеджер.
  3. Клиент.
  4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

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

Итак, на какие вопросы отвечает ТЗ.

Для кого создается сайт и для чего?

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

Как будут решены задачи заказчика и пользователей?

Собственно если не ответить на этот вопрос, то написание ТЗ можно признать бумагомарательством. Это основной и значимый вопрос. Ему может быть посвящена отдельная статья, поэтому останавливаться на нем подробном пока не будем.

Как будет проходить создание проекта?

Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику? По ГОСТу предусмотрен отдельный раздел "Этапы разработки системы". В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

Что будет приниматься на выходе?

ТЗ начинает разработку и ставит в ней точку. В идеале вы должны пройтись по всем пунктам ТЗ вместе с заказчиком, свериться с полученной системой и спустя неделю сказать: "Уф-ф. Вроде все сделали". "ТЗ является средством верификации выполненных работ." ­­- такая фраза записана во введении многих моих ТЗ.

Что требуется для дальнейшего запуска проекта?

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

Из чего состоит ТЗ

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

Общая информация

Первая часть ТЗ содержит введение и общую информацию о документе и проекте в целом. Введение надо написать один раз и на всю жизнь. Как правило, там пишутся на столько абстрактные фразы, что в каждом новом проекте надо лишь подправить пару слов.

Общая информация включает в себя:

  • Информацию о заказчике и исполнителе.

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

  • Назначение проекта.

Указывается: для чего будет использоваться полученный продукт.

  • Цели создания и задачи, которые должен решить ресурс.

С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены не четко и неизмеримо, то может быть довольно сложно им следовать.

  • Описание аудитории проекта.

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

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

  • Термины и определения.

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


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

Рамки проекта

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

Информационная архитектура и интерфейс

Раздел посвященный информационной архитектуре (ИА) сайтов не стандартизируется ни одним известным стандартом (автору такие пока не знакомы). Но любой, кто разрабатывал сайты, понимает, что ИА это чуть ли не главное, что нужно знать для разработки сайта. ИА определяет как будет выглядеть и работать сайт с пользователями. Для описания ИА потребуется описывать сверху вниз:

  1. Структуру сайта. Это так называемые высокоуровневые прототипы.
  2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
  3. Опись контента. Табличное описание содержания каждой страницы сайта.


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

Не забывайте присваивать номер каждой отдельной странице карты сайта. Это потребуется на этапе описания контента.

Полезные советы при рисовании карты сайта:

  • Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг то друга. Это поможет читабельности карты.
  • Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
  • Выравнивайте "квадратики" страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
  • Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны "перескакивать" одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
  • Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
  • Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.


Пример карты сайта http://yuri.shilyaev.com/files/articles/map.gif

Карту сайта я обычно помещаю в раздел "Приложения". Как правило, она на столько большая, что поместить ее посреди ТЗ становится не реально.


Шаблоны страниц
На уровне карты сайта каждая страница представляет для нас только "квадратик" на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне не дешево. Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта. Описание шаблонов состоит из 3х частей:

  1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
  2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
  3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.


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

http://yuri.shilyaev.com/files/articles/wireframe.gif | Пример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).


Описание контента Самая долгая и нудная часть работы. Описание контента должно включать в себя перечень всех страниц сайта с точным указанием размещаемого на каждой странице текста, картинок и т.п. Также там указывается какой шаблон используется для данной страницы (см. выше). Я рекомендую использовать для этого таблицу. Далеко не всегда на момент написания ТЗ можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его основе сможет составить план поставки контента и оценить объем внесения этой информации на сайт. У клиента же всегда перед глазами будет перечень того, что ему потребуется подготовить и отредактировать. Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

Функционал

Описание функционала сайта в техническом задании один из ключевых разделов. В особенности это касается сайтов с большим процентом программных работ: электронная коммерция, онлайн-сервисы и т.п. Хороший пример описания функционала дает ГОСТ. Рекомендую держаться стандарта при описании функционала разрабатываемого в рамках сайта программ. Должны быть описаны: общая система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей между собой и, наконец, перечисление всех функций модулей с более или менее подробным описанием их работы. Для каждого модуля должны быть расписаны объекты, которые создаются или используются в работе программы. Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты. Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы "клиенту было понятно". Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему надо.

Требования

Отдельный раздел должен быть посвящен требованиям к проекту или проекта к окружению. Требования, которые могут быть описаны в техническом задании на сайт:

  • Функциональные требования к системе;
  • Требования к персоналу;
  • Требования к надежности;
  • Требования к эргономике и технической эстетике;
  • Требования к защите информации от НСД;
  • Требования по сохранности информации при авариях;
  • Требования к видам обеспечения;
  • Требования к программным средствам;
  • Требования к информационному обеспечению;
  • Требования к техническим средствам;

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

Прочее

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

Что дальше?

ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет. Проект далеко не всегда идет по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования заказчика. Техническое задание это документ, а не скрижали. С изменением требований к проекту должно меняться и техническое задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае если это действительно необходимо, на практике встречается редко. Также вы должны быть готовы, что в процессе глубокого изучения ТЗ всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его объему и обратно пропорционально времени затраченному на его написание. Т.к. времени постоянно не хватает, следует ожидать, что ошибки в ТЗ будут возникать.

В сухом остатке.

Эту статью я написал больше года назад. Прошло довольно много времени, а я за это время не написал ни одного большого ТЗ. Но, перечитав представленную информацию, согласился со всем, что здесь написано. Итак хорошее ТЗ на сайт должно содержать в себе:

  • Общую информацию о документе и его составителях;
  • Цели и задачи сайта;
  • Описание пользователей сайта, их цели и задачи;
  • Рамки проекта;
  • Информационная архитектура (ИА) сайта: карта сайта, шаблоны, описание интерфейса;
  • Описание контента сайта;
  • Описание функционала сайта;
  • Описание процесса и майлстоунов, если требуется;
  • Перечень всевозможных требований при разработке сайта и верификации полученной работы.

Надеюсь, что информация будет полезна широкому кругу читателей.

Рекомендации по написанию писем клиентам

Что должен уметь менеджер проектов? Ничего особенного, все то же что и все менеджеры, русским языком говоря, управляющие. Уметь планировать свою и чужую деятельность, расставлять приоритеты, предвидеть и учитывать риски… Это все, так или иначе, оговаривается в различных стандартах по управлению проектами.

А еще он должен уметь писать. А еще лучше — любить писать. Статьи, презентации, инструкции и много еще чего… И письма! Если вас «повысили» до PM из программистов, смотрите на писанину, как на данное вам Богом утешение за то, что вы надолго, может быть и на всю оставшуюся жизнь, расстались с исходным кодом и языками програмирования. Отнесемся к этой работе творчески, полюбить ее в наших интересах. Воздастся, уверяю.

Итак, напишем письмо заказчику.

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

Сообщаю, что в соответствии с утвержденным ранее планом работ 10 июня 2008 г. была выпущена и установлена на демонстрационной площадке новая версия СИСТЕМЫ. Прошу ознакомиться с новой функциональностью и дать отзыв. Прошу оказать содействие в уточнении требований и допущений, изложенных в приложении № 1 к данному письму. Прошу назначить дату следующего обучающего семинара пользователей. Прошу сообщить о планах дальнейшего построения информационных сетей в рамках ваших офисов. Такое объединение офисов будет мощным стимулом использования СИСТЕМЫ на местах.


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


Сообщаю, что 10 июня 2008 г. в соответствии с Приложением к Техническому заданию была выпущена и установлена на демонстрационной площадке новая версия СИСТЕМЫ. Прошу ознакомиться с новой функциональностью и дать заключение. Так как требования Приложения к Техническому Заданию учтены, в связи с выходом новой версии целесообразно проинформировать пользователей о новых возможностях СИСТЕМЫ. Прошу назначить дату следующего обучающего семинара. Работа по поддержке СИСТЕМЫ продолжается. Прошу оказать содействие в уточнении требований и допущений, изложенных в приложении № 1 к данному письму. Реализованная СИСТЕМА предусматривает удаленную работу клиентов. В рамках внедрения была установлена локальная версия ввиду отсутствия каналов связи. Прошу проинформировать о планах объединения офисов заказчика в информационные сети.


Уже получше, не правда ли? Обратите внимание, в первом абзаце мы просим дать не отзыв, а заключение. Заключение пишется по каждому пункту, по которому есть изменения, отзыв же вещь необязательная. Правда, все еще не ясно, о чем должно быть заключение. Третий и четвертый абзац остались «притянутыми за уши». Непонятно, зачем «продолжается работа над СИСТЕМОЙ» и можно только догадываться, для чего нам нужна информация «о планах объединения офисов заказчика в информационные сети». Перепишем в третий раз.


Сообщаю, что 10 июня 2008 г. в соответствии с Приложением к Техническому заданию была выпущена и установлена на демонстрационной площадке новая версия СИСТЕМЫ. Прошу ознакомиться с новой функциональностью СИСТЕМЫ и дать заключение о возможности ее тиражирования на рабочих местах пользователей. Обращаю Ваше внимание, что в Приложении 2 к настоящему письму представлен ряд дополнительных предложений и вопросов, требующих Вашего уточнения. В связи с выходом новой версии прошу определить дату обучающего семинара и проинформировать пользователей о запланированном мероприятии. Обращаю Ваше внимание, что СИСТЕМА предусматривает удаленную работу пользователей. В рамках внедрения была установлена локальная версия по причине отсутствия каналов связи. По мере подключения рабочих мест пользователей к сети Интернет необходимо будет:
1. Установить выделенный сервер СИСТЕМЫ.
2. Провести репликацию данных с локальных рабочих мест пользователей в единую базу данных.
3. Настроить права доступа пользователей СИСТЕМЫ.

В связи с этим прошу заранее проинформировать о планах объединения офисов заказчика в информационные сети для оперативного выполнения перечисленных работ.
Приложения:
1. Перечень требований реализованных в СИСТЕМЕ на 1 листе
2. Перечень предложений для реализации в СИСТЕМЕ на 1 листе

Такое письмо уже можно отправить нашему заказчику. В нем соблюдаются причинно следственные связи, обоснованы все запросы, конкретно указаны нужды. В тексте нет ничего лишнего. Это письмо позволить его получателю приступить к работе немедленно, без переспрашивания. Умение писать письма не следует недооценивать. Хороший текст бережет время, становится отправной точкой для совместной работы. Письмо, а особенно письмо на бумаге, — важный свидетель вашей деятельности. Может статься, что со многими вашими партнерами вы будете общаться только письменно, и по вашим текстам они будут судить о вашей компетенции. Если вы не умеете писать – вас просто не будут уважать, несмотря ни на какие прочие заслуги. В конце концов, хорошо составленный текст приносит его автору то же удовлетворение как хорошо составленный исходный код программы. Потому, господа менеджеры проектов, постарайтесь полюбить работу над документами. Только удержите себя от графоманства.

10 шагов к созданию сайта (для клиента)

Когда вы принимаете решение создать сайт, перед вами возникает ряд проблем, связанных обычно с вопросом — а что именно нужно делать, как и в каком порядке?

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

Задайте себе первый вопрос — что я хочу получить? Нередко встречается формулировка результата «я хочу вообще сайт». В этом случае можно рассчитывать и на «результат вообще», который невозможно измерить ни по деньгам, ни по срокам, ни по оценке достигнутых целей. Поэтому первым шагом вашем плане будет:

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

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

Например: Сайт должен вызывать у посетителей ощущение солидности, стабильности, возможно некоторой консервативности. Основная информация — краткое описание нашей позиции на рынке, ценовая политика, контактная информация и заметный раздел с каталогом продукции. При попадании на сайт посетитель должен быстро и легко найти ссылку на форму заказа и, заполнив минимум необходимых полей, отправить заявку.

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

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

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

3. Целевая аудитория. Следущим шагом определите потенциальных посетителей, на которых будет рассчитан ваш сайт. Очень важно понимать, для кого всё это делается. Если вы хорошо представляете целевую аудиторию вашего сайта, опишите ее вкратце и простыми словами, эта информация понадобится в дальнейшем при заполнении брифа веб-студии. Мужчины это или женщины, какого возраста, каков их социальный статус? Где они работают и как отдыхают? Какие темы их волнуют скорее всего?

Представьте самого типичного представителя своей целевой аудитории и расскажите о нем. Предположим, это молодой человек 23-26 лет с высшим образованием, который интересуется вопросами карьеры, не имеет проблем со здоровьем, в качестве отдыха выбирает ночные клубы, а отдыхать предпочитает в Европе. Или же это работающая женщина 30-40 лет с 1-2 детьми, живущая в небольшом городе и уделяющая большое внимание вопросам благоустройства своего дома.

Итак, результат описан, цели поставлены, аудитория определена. Что же нужно сделать, чтобы всего этого добиться?

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

Для того, чтобы ваш сайт начал работать, необходимы три условия:
1) должен быть готов собственно сайт как набор определенных файлов и функций,
2) он должен быть размещен на хостинге, чтобы из любой точки мира к нему был постоянный доступ и
3) у него должно быть доменное имя, по которому пользователи будут к нему обращаться.
Чаще всего та фирма, в которой вы заказываете сайт, может помочь вам в регистрации доменного имени и размещении сайта на хостинге, поэтому вторые два пункта оставим на этап взаимодействия с вебстудией, а на этом шаге рассмотрим именно создание сайта.

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

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

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

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

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

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

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

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

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

7. Выбор инструментов контроля. Главный и практически единственный инструмент контроля над процессом — проверка всех его этапов на соответствие поставленной задаче. Убедитесь, что вы с подрядчиком говорите на одном языке, то есть одинаково понимаете используемые термины и понятия.

Постарайтесь абстрагироваться от своего субъективного восприятия проекта. Это непросто, но в 99% случаях вы не являетесь той целевой аудиторией, для которой делается сайт, об этом нужно помнить.

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

8. Что еще сделать для максимальной эффективности. Соблюдайте правильную последовательность действий. Создавать окончательный дизайн, когда не готов контент (содержание сайта), писать проектную документацию, когда вы не сформулировали основные цели и задачи сайта — значит потратить в итоге в 2-3 раза больше времени на переделку сделанного либо получить не тот сайт, который вам нужен, то есть выбросить деньги на ветер.

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

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

Соблюдайте договоренности и следите за их соблюдением со стороны веб-студии.

9. Как проверить, что вы добились цели. Это легко, ведь на втором шаге нашего плана вы уже сформулировали конкретные измеряемые цели, поставленные перед сайтом. После запуска проекта самостоятельно или с помощью специалистов вы можете отслеживать количество посещений, анализировать поведение посетителей сайта, просчитать финансовый эффект. Главное — не забудьте это проконтролировать и убедиться, что всё работает правильно.

10. Что дальше? Чтобы сайт развивался и был эффективным, на нем нужно размещать интересную и актуальную для посетителей информацию. Решите, кто будет поддерживать и обновлять ваш сайт, следить за его работоспособностью, назначьте ответственное лицо и контролируйте те прекрасные результаты, которые не заставят себя ждать.

Ссылки

Личные инструменты

Разработка веб-сайтов, автоматизация.
По всем вопросам обращайтесь по телефонам:

+7 495 640 29 90
http://artofweb.ru