Vladimir ([info]xekc) wrote,
@ 2009-04-02 09:38:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
коммент про вебдев
Случайно написал развёрнутый (слишком) коммент кому-то. Коммент таких размеров неудобно даже отправлять, здесь оставлю. Нужно вспомнить ка жж кат работает..

Коммент про то как просто сделать сайт:

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

предлагаю подходить к делу с вот таких позиций:

1. Любой сайт будет продавать.

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

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

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

2. Вы можете контролировать только то, что можете измерить

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

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

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

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

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

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

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

4. Забудьте о слове "поддержка"

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

Каждый билд, каждая новая версия - это ваш шаг. Вы кросс бежите. Шевелите ногами!

Примите CPI за "норму всего". Улучшайте страницы, модули и элементы постоянно. Пусть совсем чуть-чуть, но каждый месяц два - по строке в тексте, если потребуется. Эталона не существует. Каменного цветка, серебрянной пули - нет. Если в прошлом месяце bounce rate этой страницы был 19,5% то в следующем нужно сделать 19%. Никто и никогда не создаст продукт идеальный сразу, хороший с первой версии. Даже выпуская по новому сайту в два года вы тоже идёте от версии к версии, только больно уж медленно.

5. Не думайте что это дорого

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

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

6. На что выкидывать деньги не стоит

На юзабилити тестирование и фокус группы. Оно идёт постоянно на вашем сайте.

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

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

На отдельную "раскрутку". Если реклама не вписана в процесс совершенствования сайта - она не работает.

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

На статистиков. Они маскируются под аналитиков выдавая гору цифр. Требуйте что бы букв было не больше страницы а цифр было в сто раз меньше чем букв. А графики вам вообще нафиг не сдались, пусть на пальцах покажет. Вообще visuals are overrated. Ему нарисовать график и потом просто вводить новые цифры гораздо легче, чем придумать как вам обьяснить что именно происходит. Не облегчайте ему работу. Пусть знает что происходит по-настоящему.

7. Пошаговое как-то.

1. Напишите бриф. Для кого вы делаете сайт и зачем он им нужен. И зачем он нужен вам.
1.1 На его основе выберите девелопера по вашим возможностям и его портфолио. Он должен быть быстрым и гордиться тем, что делает. Всё, от него больше ничего не требуется.
1.2 Откопайте аналитика. Не знаю где. Можно вырастить внутри, пригодится. Он должен говорить как можно меньше и думать как можно больше.
1.3 Договоритесь с аналитиком о KPI и согласуйте черновой список с девелопером. Не обязательно очень длинный, потом улучшите. Ну например: Количество запросов со страниц сервисов + Количество страниц на визит + Среднее время визита + Bounce rate морды. Но это за уши притянуто, слушайте чего аналитик скажет.
2. Сделайте вместе с девелопером первую версию. Тут расписывать нечего, книги и статьи написаны. Сделайте достаточно приличный но черновик - и запускайте его. Быстренько. Или как получится. Он не имеет значения. И вообще что значит "сделайте"? У вас же наверняка прямо сейчас есть сайт. Улучшайте его, не обязательно новый делать.
3. Получите от аналитика первый отчёт и ничего с ним не делайте.
4. Сделайте серию изменений, доведите сайт слегка. Нужно что бы девелопер это запустил в работу и публиковал на живой сайт быстро.
5. Получите от аналитика второй отчёт и посмотрите на динамику. Получите третий и по трём точкам уже должен быть план изменений. Ничего глобального. Занимайтесь тем что работает лучше всего и тем что работает хуже всего. Первое нужно усиливать и улучшать, второе нужно сделать иначе. Среднее вас не волнует.

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

8. Что делать если вы маленький и небогатый

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

Можно экономить на девелопменте. Особенно первой версии. Но тогда медленно работать нельзя и версии нужно делать часто.

Можно самому учиться аналитике, есть много хороших книжек. Будете лучше понимать откуда растут ноги у сороконожки. Ну как-то так.



(21 comments) - (Post a new comment)


[info]manaka
2009-04-02 09:03 am UTC (link)
твое мнение, по мне так, ближе к реальности.
А то что в оригинале напоминает книжку по маркетингу какую-то.

(Reply to this) (Thread)


[info]akry
2009-04-02 09:37 am UTC (link)
Написал развёрнутый ответ у себя, алаверды :)

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

(Reply to this) (Parent)


[info]dixi
2009-04-02 10:05 am UTC (link)
Навскидку пару хороших книжек по аналитике можешь назвать?

(Reply to this) (Thread)


[info]xekc
2009-04-02 10:59 am UTC (link)
уже классику web analytics an hour a day - хорошая, но немножко устарела и нацелена на корпорации а не бизнесы. но там уже всё верно про clickstream sucks, про insights, про гугль аналитикс итд.

и в landing page optimization некоторые интересные и правильные мысли есть.

а вообще web metrics скорее киворд чем analytics. по аналитике будет почти всегда про репорты, репорты, репорты. вот скоро свежее будет, планирую почитать тоже, может интересно будет.

(Reply to this) (Parent)(Thread)


[info]dixi
2009-04-02 11:01 am UTC (link)
спасибо!

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

вторую поищу.

и еще раз спасибо.

(Reply to this) (Parent)


[info]genie
2009-04-02 10:09 am UTC (link)
расскази про "CPI за норму всего", пожалуйста. это KPI?

и про аналитика в процессе разработки - какие функции он выполняет

(Reply to this) (Thread)


[info]xekc
2009-04-02 11:03 am UTC (link)
constant performance improvement, извини, должен был написать.

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

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

(Reply to this) (Parent)


[info]golub
2009-04-02 10:24 am UTC (link)
Отлично! Слышу голос практика, а не теоретика.

(Reply to this) (Thread)


[info]xekc
2009-04-02 11:11 am UTC (link)
спасибо.

(Reply to this) (Parent)


[info]egorfine
2009-04-02 10:39 am UTC (link)
Со всем согласен, но кое-что может быть истолковано неверно.

"вы доверяете его опыту и портфолио. Это можно делать, но работает далеко не всегда."

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

(Reply to this) (Thread)


[info]xekc
2009-04-02 11:11 am UTC (link)
да, конечно.

(Reply to this) (Parent)


[info]zaza
2009-04-02 01:33 pm UTC (link)
Читаю и сказать нечего. Мне очень очень понравилось! Особенно про "Он должен быть быстрым и гордиться тем, что делает."

Хочется распечатать и повесить в офисе.

(Reply to this)


[info]tepexob
2009-04-02 06:21 pm UTC (link)
То есть вы предлагаете использовать ТДД для разработки сайта, рассматривая при этом ROI как единственный тестируемый параметр?

Звучит заманчиво гибко.
А это только идея, или отработанная практика?

(Reply to this) (Thread)


[info]xekc
2009-04-02 07:57 pm UTC (link)
это давно используемая практика и писал я об этом как о чём-то широко распространённом для больших проектов. амазон и подобные екомерсы уже скоро десять лет как только так и живут, и в книжках понаписано всего. гугл со своими оттенками цветов тоже недавно прожужжал, ютуб вообще постоянно меняется тем же образом.

названия единого помоему нет пока что, не ТДД это в чистом виде, это и customer driven innovation и split tests рядом, иногда и crowdsourcing и participatory production и даже co-authoring тоже. много техник смешано и я в них по-настоящему не разбираюсь.

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

по поводу ROI.. нет, мне привод к одной цифре Return On Investment кажется слегка притянутым за уши, есть внешние факторы, общие рыночные тенденции.. очень много смешений мягкого с тёплым будет. тестировать одну цифру не получится, маленькие шаги будут давать слишком малое влияние на конечную цифру прибыли / roi.

работать с набором KPI, пересматривать его, искать bottlenecks, и становиться лучше, постоянно - да. тестировать KPI для страницы или элемента дизайна. вот кнопка "add to cart" и количество её нажатий на визит - это чистый нормальный KPI. сделали зелёного цвета - упал ctr на пол процента. сделали красного - повысился. делаем больше, меняем шрифт на более заметный. В идеале - никогда не перестаём.

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

(Reply to this) (Parent)(Thread)


[info]tepexob
2009-04-03 06:37 am UTC (link)
Спасибо за систематизацию мыслей.
Очень интересно, правда.

(Reply to this) (Parent)(Thread)


[info]tepexob
2009-04-03 06:42 am UTC (link)
Кстати, за ГТД, про которое я от вас же и узнал - года три, ведь три уже, да? назад, тоже спасибо.

(Reply to this) (Parent)


[info]genie
2009-04-07 10:17 am UTC (link)
как решать проблему статистической погрешности? у меня вот не миллион пользователей, а всего 300 в день. с такой выборкой нужно А/B-тестировать минимум неделю, чтобы результаты были релевантными.

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

(Reply to this) (Parent)(Thread)


[info]xekc
2009-04-07 12:56 pm UTC (link)
300 минус bounce это минимум неделя, да. но неделя это не так ужасно много, не вижу большой проблемы. я даже не думаю что чаще нужно делать на самом деле.

дорогая практика - учите google website optimizer, на 3-4 раз кодер справиться с подготовкой более менее сложного эксперимента за час. нормально. сложные эксперименты крутите две-три недели. на них и пару дней можно потратить. основная ценность сплит тестов приходит через пять-десять прокруток, когда посетители выбирают уже не между банановым и малиновым вкусами - а между пивом и кефиром. когда они через тесты начнут показывать что вам бы продвинуться вот в ту область рынка - вот тогда это особенно полезно.

(Reply to this) (Parent)


[info]katja_i
2009-04-03 09:47 pm UTC (link)
Очень хорошее описание. Американцы вот давно додумались до построения систем согласно этим принципам (я 3 года строила такую "agile" систему, буквально по шажочкам, самотестировать она себя при этом умела на всём, вплоть до цветов). В последнее время вижу также в UK шевеление подобного рода. Наши заказчики ещё не добежали до этого, но думаю что кризис таки окажет свою положительную роль.

(Reply to this)


[info]teplorod
2009-04-19 07:23 am UTC (link)
Пункт 7, подпункт один - это то, чего многие клиенты себе не представляют. Вернее, эти представления сводятся к тому, что сайт должен повышать известность компании и повышать продажи.

(Reply to this)

отслеживание изменений
[info]hvostarik
2009-04-29 08:56 am UTC (link)
сразу оговорюсь, я не занимаюсь веб-девом, но описанные вами принципы, похоже, довольно универсальны(непрерывные изменения на основании вычислимых показателей). Хотелось бы узнать как вы решаете проблему зависимости показателей от внешней среды. Например, я выберу одним из контролируемых показателей "количество посетителей в день". Допустим в этом месяце их было 100, я изменяю тексты нескольких страниц и получаю 60. Вопрос - что повлияло на результат
* мои изменения
* изменения работы поисковиков
* возникновения нескольких сайтов конкурентов
* ...
Чтобы ответить на этот вопрос по хорошему надо было бы получить значение показателей без каких либо изменений сайта.
Как вы поступаете в подобных случаях?
Ведь, как я понимаю, не всегда возможно выбрать относительный показатель, не зависящий от внешней среды.

(Reply to this)


(21 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…