Этапы создания веб-проекта - Путь веб-проекта и ямы на этом пути

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

На данной стадии пока ничего нет, кроме идеи. Вы начинаете прорабатывать концепт будущего проекта.

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

Идея практически имеет нулевую стоимость без ресурсов под ее реализацию.

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

Похожий вариант - графоманство. Т.е. это неструктурированный поток мыслей по проекту без какой-либо особой цели и структуры.

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

Кастдев - это предварительные беседы с потенциальными клиентами до/во время создания продукта.

Чем ближе к рынку находится владелец продукта, тем выше шансы, что он делает что-то нужное для рынка.

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

Концепт должен быть понятен бизнес-пользователям.

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

Как минимум, вы сами должны верить в ПОЛЕЗНОСТЬ и ЦЕННОСТЬ продукта для клиента и иметь перечень реальных аргументов в пользу этого.

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

Для реализации проекта необходимо выбрать исполнителей - команду, которая выполнит техническую работу по созданию веб-проекта.

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

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

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

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

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

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

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

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

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

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

Ищите человека/команду с конкретными компетенциями. Не нужно пытаться взвалить на него все-все вопросы, в которых вы некомпетентны (как руководитель проекта).

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

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

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

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

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

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

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

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

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

Это стадия создания продукта - по этапам создается функционал будущего сайта.

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

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

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

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

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

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

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

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

Бывает так, что разработка длится бесконечно. Постоянно возникают какие-то новые идеи, и все это внедряется в проект. И так идет до того момента, пока владелец проекта не потеряет интерес к проекту или не кончится бюджет.

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

После технической разработки происходит внедрение проекта в эксплуатацию. И здесь есть свои подводные камни. Обозначим основные.

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

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

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

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

Обратная связь от пользователей дает ценный материал для изменений и адаптации программы. Именно пользователи определяют успех или неуспех программы.

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

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

Не во всех проектах нужно привлечение трафика. Если ваш проект подразумевает продвижение, то учитывайте следующие ямы.

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

Выбрать специалиста по продвижению - очень непросто. Продвижение характеризуется очень долгой обратной связью. Затраты вы несете сейчас, а реальный профит от продвижения можете увидеть через 1-2-3 месяца. И то не факт. Всегда могут найтись отговорки вроде "изменились алгоритмы поиска", "у вас на сайте такая-то настройка помешала" и т.д.

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

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

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

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

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

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

Доступность требует постоянного контроля, оперативного реагирования, а также профилактических мер, снижающих риски останова.

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

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

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

Когда система только создается, очень просто все кардинально поменять.

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

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

Если в начале весь проект может делать один человек, то в зрелом проекте может быть очень глубокая специализация (к примеру, 1 человек на SEO продвижение, 1 на веб-аналитику, 1 на директ и т.д.).

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

Работа сайта стабильно, процессы текут стабильно и хочется постепенного расширения системы.

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

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

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

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

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

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

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

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

Источник: