Прочитать позже

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

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

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

Введение

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

Стадия 1. Идея, концепт

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

Яма 1. Прятать идею ее от всех, боясь, что ее скопируют

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

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

Яма 2. Держать идею в голове, а не письменно. Или слишком обобщенно описывать

Чем точнее и конкретнее прописаны значимые детали проекта, тем проще выявить узкие места на ранних этапах.

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

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

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

Яма 3. Не делать минимальный кастдев с клиентами и пользователями

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

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

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

Яма 4. Писать слишком детально (в форме ТЗ)

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

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

Яма 5. Думать, что ваш клиент дурак, и купится на это

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

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

Яма 6. Сделаем как у конкурентов (например, Битрикс24), только удобнее

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

Стадия 2. Выбор исполнителя

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

Яма 1. Выбор чисто по отзывам

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

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

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

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

Яма 2. Выбор по внешней обложке

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

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

Яма 3. Выбор по цене

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

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

Яма 4. Искать исполнителя "Все в одном": и продвиженец, и разработчик, и сисадмин, и дизайнер

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

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

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

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

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

Стадия 3. Создание ТЗ

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

Яма 1. Слишком большое желание впихнуть побольше в проект

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

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

Яма 2. Упор на несущественные детали (а ключевой процесс практически не проговаривается)

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

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

Яма 3. Неверный выбор начальной системы (негибкость, без учета будущего масштабирования и т.д.)

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

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

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

Стадия 4. Реализация проекта

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

Яма 1. Нет промежуточного контроля состояния

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

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

Яма 2. Нет коммуникации

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

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

Яма 3. Конфликтные люди на проекте

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

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

Яма 4. Нет альтернативного мнения специалиста

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

Яма 5. Если сайт для продвижения - то учет seo на ранних порах

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

Яма 6. Нет конечной точки

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

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

Стадия 5. Внедрение в работу

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

Яма 1. Этап шлифовки и работы над багами

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

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

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

Яма 2. Контроль работоспособности базовых функций           

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

Яма 3. Первая обратная связь от пользователей

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

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

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

Стадия 6. Опционально - привлечение трафика

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

Яма 1. Нет понимания по продвижению (что это вообще нужно)

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

Яма 2. Сложности выбора продвиженца - долгая обратная связь по результатам

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

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

Яма 3. Нет веб аналитики

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

Стадия 7. Операционная работа

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

Яма 1. Много данных и пользователей

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

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

Яма 2. Обеспечение доступности

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

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

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

Яма 3. Рост стоимости ошибок     

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

Яма 4. Сложности с экспериментами

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

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

Чем старше система, тем более консервативной она становится. 

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

Яма 5. Расширение команды

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

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

Яма 6. Аналитика метрик системы

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

Стадия 8. Расширение системы

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

Яма 1. Важна гибкость на базовом уровне

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

Яма 2. Документация

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

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

Яма 3. Продуманные изменения

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

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

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

Заключение

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

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

Насколько полезной была статья?
Falcon Space, автор блога

Автор статьи - Руслан Раянов

Cоздатель платформы Falcon Space

Смотреть демо

F-CRM + Site
Сайт для компании в виде лендингов + встроенная CRM для обработки заказов на услуги.
Falcon Auction Площадка услуг
Заказ услуг исполнителей через площадку.
Falcon Service Кабинеты для клиентов
Обслуживание заказов клиентов через личный кабинет на сайте
Акция

20% скидка на создание ТЗ для учетных систем

Для учетных систем действует скидка 20% на создание технического задания на проект.

Действует до 1 сентября 2024

Подать заявку

Как узнать бюджет/сроки своего проекта?

1. Создать концепцию проекта в личном кабинете

Шаблон концепции

2. Отправить нам документ концепции

Отправка идет через личный кабинет менеджеру.

3. Мы подготовим первичное КП с детализацией

Пример КП

Выгода от использования Falcon Space

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

Если вам нравятся наши статьи, то пожалуйста подпишитесь на наш канал в Telegram - Falcon Space.
В нем мы будем публиковать обновления по статьям и другие материалы касательно нашей платформы.

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