Pull to refresh

Самоорганизация в web-разработке

Reading time 9 min
Views 7.9K
Самое сложное в ведении бизнеса, каковым является разработка веб-сайтов – начальная организация и формализация всего процесса работы. Необходимо распланировать свое время, бюджет и, самое главное, порядок общения с заказчиком, т.к. последнее напрямую влияет и на время и бюджет.

Я лично для себя никогда не ставил целью стать менеджером. Однако, будучи разработчиком-фрилансером столкнулся с необходимостью правильно распределять свое время и уметь продавать свою работу.
Далее...

0 Этап


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

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

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

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

В результате предварительного разговора определяется дата/время первой встречи с заказчиком. Дата определяется загодя и подготовиться к встречи должны и вы и заказчик.

С вашей стороны нужно подготовить примеры и все необходимые документы (для составления договора) + технику для демонстрации и работы (ноутбук).
Не знаю как обстоит ситуация в больших городах, но на «периферии» нужно таскать «ноутбук с интернетом» собой. Для таких целей новомодные eeePC и клоны являются идеальным вариантом, т.к. их не напрягает таскать с собой.

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

К сожалению, часто возникают ситуации, когда предварительные встречи повторяются. Этого нужно старательно избегать, т.к. часто «пред-игра» заводит в тупик.

1 Этап


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

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

В идеале, менеджер должен быть в курсе работы программистов и быть «в теме». В таком случае, легче будет вести диалог. Если вы работаете один — это как раз тот самый вариант.

Диалог начинать нужно будет опять с выяснения задач сайта, т.к. часто бывает, что у клиента появляется «что-то новое» или он о чем-то умолчал. На основании задач определяется характер сайта (портал, магазин, промо-сайт...) и структура его разделов. Последнее необходимо определять максимально четко.

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

Задачи сайта и его структура «забиваются» в Техническое задание.

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

Реальность такова, что большинство заказчиков считает, что за обозначенную вами сумму он покупает вас, а не конечный продукт. Задача ТЗ – помочь вам исправить это ошибочное мнение.

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

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

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

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

На этом же этапе, после определения ТЗ желательно обсудить пожелания заказчика насчет дизайна. К сожалению «заказ на дизайн» сложно формализовать (да и не имеет смысла), поэтому все придется записать в свободной форме и виде эскизов-набросков. Желательно сразу пресекать пожелания вроде «фона из логотипов» и т.д. (естественно, объясняя почему).

2 Этап


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

Программная часть сайта

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

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

Планирование архитектуры лучше всего начинать с TODO на модуль: какими данными он должен оперировать и что должен уметь делать. Например, в настоящий момент я пишу модуль блога и чтобы самому не запутаться расписал в виде плана что нужно сделать. На основе TODO разрабатывается схема базы данных (точнее, совокупности таблиц модуля) и как она интегрируется в общую базу CMS, а также интерфейсы управления и взаимодействия с модулем. Последнее является очень важной частью разработки модуля, т.к., в отличии от кода и структуры БД она не «скрыта от пользователя». Поэтому интерфейсы управления должны быть понятны конечному пользователю, а не программисту.

Для набросков интерфейсов достаточно хорошо подходит расширение <a
href=«addons.mozilla.org/sq/firefox/addon/8487?lang=ru»>Pencil
.
К сожалению, при первичном планировании TODO учесть все аспекты не всегда удается, поэтому TODO, структура таблиц и GUI (функциональные элементы интерфейсов) могут меняться по ходу разработки.

При разработке модулей и вей системы в целом нужно учесть еще два момента: bug-report и наличие документации. У мня все ошибки системы на основном сайте тщательно журналируються и отсылаются на мой почтовый ящик. Если что-то слетает журнал всегда поможет найти ошибку.
Вполне логично, что работать на «живой» системе не очень правильно. Для разработки прототипа, как правило, используется локальная (на вашем рабочем компьютере или корпоративном веб-сервере) версия сайта. Ее же (или копию) можно показывать заказчику. Только после приемки работы (рабочей версии сайта) его имеет смысл переносить на основной сервер.

С документацией все немного сложнее. Как уже неоднократно отмечалось (ссылка) многие программисты не любят писать документации. Тем более это касается документации для простых пользователей а не манов для других программистов. К сожалению от этого никуда не деться. Даже если вы используете готовую стороннюю систему («Битрикс» и других) документацию скорее всего придется переписывать и адаптировать ее для нормальных людей. Документация позволит значительно сэкономить ваше время в будущем, когда пойдут звонки от клиентов с вопросами. Если у пользователя что-то не получается всегда можно будет отправит его к нужной странице, к нужному пункту и выяснить что не так.
Конечно, нужно учитывать, что в большинстве своем пользователям самим лень читать документацию и делать все в соответствии с ней. Я регулярно тестирую пользователей (у меня есть такая возможность, т.к. преподаю на курсах переподготовки учителей) на предмет того, как они используют документацию и результаты, как правило, весьма забавные: пользователь доходит до 3-го, 4-го пункта, а дальше поступает по своему, считая, что остальные пункты не важны и написаны «до кучи».


Дизайн

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

1. Если заказчику нужно сделать все по быстрому

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

2. Утверждение дизайна заказчиком

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

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

3 Этап


Показываем прототип заказчику. Желательно сразу «прикрутить» к нему дизайн, т.к. иначе заказчику будет сложно понять (и утвердить), что и как будет работать на его сайте.
На этом этапе, как правило, вносятся коррективы в дизайн, функциональность и в структуру в целом. Главное, при этом, четко следить, чтобы коррективы не привели к разработке нового сайта, совершенно отличного от того, что был обозначен на первом этапе (и прописан в ТЗ). Если заказчик стоит на своем и требует внести новую «фичу» — оформляем работу новым договором или приложением к текущему. Главное ни в коем случае не идти на поводу, т.к. однажды согласившись потом будет уже сложно сказать «нет».

4 Этап


Вносим последние коррективы и готовим документацию. При этом, документация фактически получится из трех частей:

1.Как пользоваться админкой CMS

Руководство должно быть максимально «человечным» и быть выстроено в виде структурированных вопросов/ответов с подробным, пошаговым описанием всех необходимых действий (желательно, еще и со скриншотами).

2.Руководство по подготовке и оформлению материалов для сайта

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

3.Техническое руководство для администратора

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

5 Этап


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

Не забываем напомнить заказчику об оплате ваших услуг.

6 Этап


Прописываем сайт в поисковиках и проводим его начальную поисковую оптимизацию. На этом этапе не редко возникает новые проблемы с заказчиком, а именно, требования с его стороны о размещении сайта на первых строчках Google и Яндекс. Претензии в основном звучат как «Сайт, который сразу не находиться в Яндесе нам не нужен». Здесь нужно набираться терпения и спокойно объяснять заказчику каким образом сайты туда попадают и что очень многое зависит от его (заказчика) контента и частоты его обновления.
Tags:
Hubs:
+10
Comments 16
Comments Comments 16

Articles