Web-automation.ru

Введение

Успех каждого проекта уникален и опирается на уникальные преимущества команды во главе со своим руководителем.

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

 

1. Не проверять исполнителей

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

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

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

Чтобы вы могли это делать, обязательно надо базово разбираться в сфере веб-проектов. Спорные вопросы изучать в сети и привлекать независимых экспертов, которые будут не “пороть отсебятину”, а обоснованно давать свое мнение, основанное на здравом смысле, а не уникальном внутреннем мире специалиста.

Главное при взаимодействии с исполнителями – постепенное доверие.

Сначала мелкие задачи и плотная проверка результата. Потом постепенно доверять все больше и больше по мере достижения результата.

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

Исходя из своего опыта собеседований программистов, более 80% не имеют даже базовых понятий по технологиям, которые указаны у них в резюме.

 

2. Не вести метрики роста проекта

Если вы не измеряете результат, то вы полагаетесь на мнения людей. “Все хорошо?” – “Да. Все в норме”. Только норма у каждого своя.

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

Самые простые метрики:

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

Определите 1-2 главные метрики и начинайте жить по ним. Ежедневно смотрите эти метрики и думайте как их можно улучшить. Вносите изменения и заново анализируйте метрику.

 

3. Делать все одним большим этапом

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

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

Особенность веб-проекта в том, что вы не знаете в точности, что вам нужно. Это понимание придет позже – по мере получения обратной связи от потребителей.

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

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

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

Дополнительный важный момент – постепенное прояснение ожиданий при взаимодействии с исполнителем. Может случиться, что стандарты работы исполнителя вас совсем не устраивают. Лучше будет если цена вопроса будет 20 тыс. руб. за мелкую работу, нежели 500 тыс. руб. за весь проект (где была предоплата 50%). Проще будет закончить проект, меньше рисков, быстрее можно понять, что исполнитель не подходит.

 

4. Работа без ТЗ

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

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

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

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

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

Кратко плюсы от технического задания:

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

 

5. Думать о продвижении на поздней стадии

О продвижении надо думать сразу, как возникла идея сайта.

• Кто потребитель на сайте?
• Кто будет платить?
• Как они придут на сайт?
• Через какие каналы?
• Хватит ли у меня средств привести достаточное количество людей?
• За счет чего я буду удерживать их на площадке?

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

Это похоже на разработку большого самолета без понимания, как он может взлететь.

Мы начинаем проекты всегда с Концепции проекта. Некоторые заказчики воспринимают это как Бриф, как необходимое зло для того, чтобы передать информацию программистам. Концепт проекта – это глубинная проработка своего проекта и его узких мест, а не заполнение анкеты для получения бюджета на разработку.

 

6. Делать полный набор функций в продукте

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

“Не могу же я показывать рынку сырой продукт. Увидят сырое и разбегутся”.

При этом “не сырой продукт” в понимании человека – это фарш-монстр-комбайн с кучей всевозможных функций.

Лучше идти от проблемы пользователя.

• В чем его проблема?
• В чем наше решение?
• Как сделать это минимальное решение?
• Что еще можно убрать, что не решает задачу пользователя?

Успех некоторых программ – в их простоте. Чем проще программа, тем легче освоить ее. А зачем мне уходить от простой хорошей программе к программе-монстру, который изучать надо не меньше часа.

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

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

 

7. Делать без обратной связи от  целевой аудитории по предложению

Пункт связан с предыдущим. Продукт должен быть ориентирован на определенную целевую аудиторию и их проблемы.

Альтернативная негативная ориентация – ориентация на возможности программы.

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

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

 

8. Затягивать запуск с добавлением функций

Чего боится каждый владелец продукта? Что рынок не примет его продукт.

Как этого избежать? Просто откладывать вывод продукта!

Можно еще 3 месяца шлифовать дизайн, добавлять мелкие функции. Проблемы создания сайтов от этого не исчезнут.

При этом проект не получает “кислорода” – реальной обратной связи от рынка.

Чем раньше вы поймете никчемность своего продукта – тем лучше! Это хорошо, а не плохо. Это шанс сделать хороший продукт.

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

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

 

9. Сильная концентрация на стилистике и дизайне

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

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

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

Дизайн – это больше про процесс использования, а не стилистику.

 

Заключение

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

 

https://falconspace.ru/ – платформа создания бизнес-приложений в виде личных кабинетов