Записи

look-com-ua-5115

Время охерительных историй. Езда по граблям или как (не)похерить отличное начинание

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

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

Взялись за сайт, и снова беда: для кого он нужен – понятно, модели поведения просчитаны, алгоритмы взаимодействия проработаны. Вот только кнопочки не той формы. И картинки не те. И шрифты грустные. А если ночью, в полнолуние, девственница посмотрит на сайт из 69 позы йоги, то четко прослеживается пентаграмма в оформлении страницы контактов. Короче, переделывать все нафиг, не задумываясь.

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

Время — деньги

Любой проект стоит денег. И чем больше времени тратится на его реализацию, тем дороже он обходится. Однако людям почему-то свойственно забывать, или не считать, сколько же на самом деле стоит та или иная задача. Для того чтобы получить наипростейший баннер нужно привлечь дизайнера. Которому нужно сформулировать задачу. И чем четче стоит задача – тем ближе к «идеалу» будет результат. Для формулировки задачи необходим человек, руководитель, менеджер, хоть кто-нибудь. И он потратит время на эту самую формулировку. А еще ему придется контролировать выполнение и корректировать конечный результат.

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

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

Засомневался – застрелись

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

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

Дедлайн, мать его

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

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

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

Цели и средства

Будет ли продавать функционирующий но некрасивый сайт? Обратят ли пользователи внимание на отсутствие ряда второстепенных опций ресурса? Будут ли потребители покупать высококачественный продукт по низкой цене, но с не самым удачным оформлением?

Ответ на все вопросы положительный. Конечно, продажи будут не такими, как хотелось бы. Но они будут.

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

Об упырях и самописных CMS

Об упырях и самописных CMS

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

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

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

  1. Порезанную версию бесплатной CMS, в которой отпилили все «ручки-ножки» какие смогли, оставив пару администрирующих опций. Этот кастрат и позиционируется как «новая разработка».
  2. Более честный вариант – говнокодерная реально самописная кракозябрла, интерфейс которой напоминает полуразложившийся труп, а технических возможностей работы с разным контентом – кот наплакал.

Единственный плюс таких предложений – стоимость, равная трем копейкам в базарный день. Редко какие жадные упыри догадываются просить больше 500 долларов за свое творение.

Проблем с такими выкидышами вагон, но самая важная — отсутствие гибкости. Любая, даже незначительная доработка выливается в большие расходы. Ведь допилить сайт без костылей и мата сможет только его создатель, ибо разбираться в чужом коде – редкое извращение, с которым немногие захотят связываться. А если и найдется кодер, который решиться на такую работу, то озвучит такую сумму «за все», что руководителю придется продать запасную почку.

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

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

web-site

Хотим создать сайт, с чего начать?

Сегодня на почту пришел актуальный, на мой взгляд, вопрос: «Хотим создать сайт, с чего начать?».

А действительно, с чего?

Вопрос создания бизнес-модели, описания ЦА, УТП и прочего уберем за скобки. Это доступно описано в книге Александра Остервальдера и Ива Пенье «Построение бизнес-моделей». Будем считать, что все эти задачи хоть как-нибудь выполнены.

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

1. Время. Раскачиваться им некогда, они и так зарабатывают мало.

2. Деньги.

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

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

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

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

Модели поведения должны описывать:

1. Цели, к которым необходимо привести пользователя.

2. «Хлебные крошки», ведущие к цели.

3. Пути перемещения пользователя по сайту.

4. Варианты перемещений.

5. Манипуляции пользователя на протяжении пути.

6. Результаты манипуляций.

Далее, этот документ должен стать основой максимально детализированного ТЗ, которое лучше разделить на несколько блоков.

Блок 1: Дизайн

1. Детально опишите главную страницу, страницу продукта, страницу покупки и страницы личного кабинета.

2. Приведите примеры понравившихся сайтов или красивого дизайна.

3. Укажите, какие элементы должны быть кликабельны.

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

Блок 2: Пользовательский интерфейс и триггеры (при наличии пользовательского кабинета и процесса покупки)

1. Укажите, что должно происходить при нажатии на определенные кнопки.

2. Не забудьте о шаблонах писем.

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

Перечитайте и упростите все, что можно.

Сложные системы менее надежны.

Меньше свободы – короче путь к цели.

Простота дешевле.

И главное – минимализм в тренде.

Блок 3: Интерфейс администратора

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

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

В дальнейшем, я обязательно опубликую несколько примеров технических заданий для сайта, а пока вы можете отправлять свои вопросы на почту grigoriev.dmitriy85@gmail.com