AJAX Planet » Boris Bogdanov

Себестоимость, говорите?..

Boris Bogdanov — Wed, 21 Jul 2010 10:42:28 +0000

“Дни бухгалтера” у нас четко определены, и их даты традиционно совпадают с датами сдачи отчетности. Реализация, НДС, налоговая… всё как обычно. И, слава богу, это далеко не главная моя головная боль. Есть только один интересный пункт, который меня сильно беспокоит — поток работы, который генерируется необходимостью поддерживать все эти формальности. Простой пример: есть у нас какая-нибудь услуга, положим, мой любимый хостинг. Общение с физ.лицами предельно просто — вы нам деньги, мы вам услугу. В общении с юр.лицами появляется необходимость поддерживать четко описываемый формальный документооборот: счета-фактуры, акты выполненных работ, акты сверок и т.д. Все эти документы надо подготовить, распечатать, отправить. Формирование актов, понятно, автоматизировано, но затем каждый акт надо напечатать, подписать, проштамповать, в конверт положить и на почту отправить. И каждая из этих операций имеет свою цену. И вот смотрю я на тариф по 50 рублей в год и понимаю, что при работе с юр. лицами мы по нему гарантированно в минусе. Без вопросов. Да и на прочих дешевых массовых услугах затраты на поддержание всего этого бумажного потока составляют заметную часть цены, которую оплачивает клиент.

Интересна эта тема? Посмотрите архив сообщений по теме Без рубрики.

Хостеры на перепутье

Boris Bogdanov — Fri, 25 Jun 2010 18:55:08 +0000

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

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

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

Гм… так к чему я это, и при чем тут хостеры? Хостеры имеют готовую базу клиентов, которым нужны такие решения (пусть и в достаточно узкой нише),. Более того, хостинг-провайдеры располагают обширным опытом работы в режиме сервиса, с регулярными небольшими платежами, обеспечивающими приличный поток финансов за счет количества клиентов. Какую модель нам это подсказывает? Простите за банальность, но SaaS.

Впрочем, SaaS в чистом виде не оптимален: клиенты, строящие решения, являющиеся основой их бизнеса, хотят иметь возможность забрать свои данные и, более того, работающее решение с этими данными. Во что это превращается на каком-нибудь классическом сайт-билдере в духе народа или более навороченного ucoz-а, догадаться не сложно: к необходимости делать новый сайт. Соответственно, решения должны обладать не только малой начальной ценой и возможностью быстрого старта, но и давать клиенту всё, чтобы потом “выехать из комуналки” и развивать свой проект “по-взрослому”, с индивидуальной разработкой, выделенными серверами и т.д.

Для того, чтобы подобное развитие было возможно не только теоретически, необходимо, чтобы с этой выделенной системой могли работать разработчики, при этом не слишком специфичные. Т.е., грубо говоря, чтобы CMS-ка была известная и доступная. Что нам это подсказывает в наших российских условиях? Правильно, UMI и Битрикс. При всех оговорках, это основные системы, с которыми работает огромное число партнеров. Радует то, что компании двигаются в этом направлении — посмотрите на UMI.Host, внезапно переименовавшийся в UMI.Cloud (пусть пока и сырой) и арендную версию битриксовского Корпоративного Портала и устремления к развитию тиражируемых решений.

Интересна эта тема? Посмотрите архив сообщений по теме Без рубрики.

Походы на конференции

Boris Bogdanov — Sat, 29 May 2010 18:36:05 +0000

Ребята из моего отдела регулярно ездят на конференции. Зачастую, подписывая очередную служебку и счет на участие в конференции, я думаю, какого результата я ожидаю от этого. Да и вообще, в чем смысл этих поездок? Давайте подумаем — в принципе, подавляющая масса информации, которая излагается на конференциях, и так свободно доступна. Более того, в последнее время для основных конференций появилась возможность просматривать видео выступлений либо в живую, либо в записи. Скажем, на прошлой неделе я просматривал записи выступлений с Software People. Так тогда в чем смысл? Мне кажется, что смысл даже не в самих докладах. Важно то, что и лектор, и другие участники рядом. В таких условиях главное то, что происходит в кулуарах. Вопросы, обсуждения, знакомства. И вот это никакие видео-записи не заменят. И если вы просто слушаете выступление, а потом уходите, теряется весь смысл присутствия на конференциях.

Интересна эта тема? Посмотрите архив сообщений по теме Конференции.

По следам СПИКа

Boris Bogdanov — Sun, 23 May 2010 09:27:33 +0000

СПИК в этом году был масштабнее, чем когда либо, и при этом — бессмысленнее, чем когда-либо. Если честно, сейчас я слабо понимаю, зачем профессионалу ехать на СПИК, если он не собирается выступать или просто пить пиво у фонтана в приятной компании. За 2 дня действительно порадовали только 3 доклада. 3! При нескольких залах и огромном количестве выступающих.

При этом возникает ощущение, что это неизбежно: СПИК — конференция для всех, а не для профессионалов. Это не HighLoad и не DefConf, и доклады направлены на некоторого усредненного посетителя, который знает мало, читает совсем мало, да и в принципе “не в теме”. На профессионалов был нацелен разве что закрытый партнерский саммит UMI.CMS. Там выступали, зачастую выступали хорошо, просто для меня не слишком интересна тематика — свой последний большой проект на Юми я собрал полтора года назад и не очень хочу к этому возвращаться.

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

Интересна эта тема? Посмотрите архив сообщений по теме Конференции.

О разговорах с заказчиками, клиентской оптимизации и оценке результата

Boris Bogdanov — Wed, 19 May 2010 18:06:47 +0000

Так сложилось, что в этом году, как это ни печально, не состоится Barcamp.lv. А жаль… Во многом жаль из-за того, что на этом баркампе я собирался выступить. Если вы читали недавние мои посты, то содержание доклада вряд ли будет неожиданным, но презентацию, как мне кажется, всё же стоит посмотреть:

О разговорах с заказчиками, клиентской оптимизации и оценке результата

View more presentations from celarent.

Интересна эта тема? Посмотрите архив сообщений по теме Конференции, Управление проектами.

Маркетинг на основе баз данных

Boris Bogdanov — Wed, 12 May 2010 14:40:37 +0000

У меня в сумке лежит толстая пачка различных членских и скидочных карт. Большой и пёстрый набор — всё от карты ближайшего гипермаркета до карты постоянного клиента любимой авиакомпании. При получении практически каждой я заполнял большую и пространную анкету — фио, возраст, адрес, интересы, да мало ли… При этом в большинстве случаев, если я не приходил еще раз в магазин, выдавший карту, больше я о нём не слышал. Либо в немногих случаях меня начинали заваливать бессмысленным и беспорядочным спамом, на который очень скоро настраивался фильтр. Но, черт возьми, почему? У вас же есть море информации обо мне — кто я, что покупаю, с какой периодичностью, что и когда покупал в последний раз и т. д. Так почему, если я покупаю ролики, не прислать мне сообщение о том, что начались продажи новой коллекции роликов той фирмы, которой я пользуюсь, или по ним действует какая-то акция? Почему практически никто не делает точных и адресных предложений, которые неизбежно будут давать высокий уровень конверсии?

Не знаю… думаю, что как обычно — не умеют, не хотят думать, не видят смысла… Для тех, кто не безнадежен и хочет выстраивать долгосрочные отношения со своими клиентами, “Маркетинг на основе баз данных” А. Хьюза может оказать хорошим подспорьем. Книга, будем честны, не идеально. По ней иногда чувствуется, что написана она не год и не два назад, но общие принципы не меняются. Еще из предупреждений — не смотрите на слова “базы данных”. Это прежде всего книга по маркетингу. Хорошее толковое изложение того, что можно делать со всей той массой клиентской информации, которая сейчас лежит мертвым грузом.

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

Интересна эта тема? Посмотрите архив сообщений по теме Книги.

Снес яйцо — кудахтай! Или не забудьте рассказать о сделанном

Boris Bogdanov — Sun, 09 May 2010 08:02:10 +0000

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

У нас была очевидная цель — получить быстрый результат, чтобы иметь карт-бланш на дальнейшие изменения. Что ж, мы взяли свободно распространяем минифаер, написанный на php, малость обработали его напильником, изменили способ показа баннеров у нас на сайте, внесли еще пару быстрых изменений. По дороге выяснилось, что как минимум в нашем случае minify падает, если ему разом скормить jQuery, jQuery UI и свои скрипты. Что ж, разнесли на 2 блока. Оценка сайта по Yslow выросла с 53 до 68. Не идеал, но для начала — достаточно. Что же теперь? Как говорит Саша Орлов, “снес яйцо — кудахтай”. Итак, надо было показать, что внесены правильные изменения, что мы не зря потратили время, да и вообще молодцы.

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

Итак, следом мы сделали простейший сплит-тест. Т.е. половина пользователей получала оптимизированную страницу, половина — прежнюю, неизменную версию. Следом мы считали лишь один, но самый важный для нас показатель — количество заказов.

Как показала статистика за следующие 2 недели, “сжатая” версия давала почти на 2% больше заказов. Т.е., потратив 4 рабочих дня, мы стабильно увеличили количество заказов почти на 2% без привлечения доп. средств. В моём понимании это отличный показатель, за такое надо орден давать, а еще лучше — премию.

Да, сплит-тесты позволили нам быть уверенными, что именно наши изменения привели к этим результатам. К сожалению, мы собирали только очень однобокую статистику, но это издержки производства — готового решения мы не нашли (сразу обмолвлюсь — Google Website Optimizer по рядку причин использовать не хотелось), писать что-то сложное своё не было времени. Так что, если кто-то сможет подсказать хороший инструментарий, буду рад.

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами.

“Крошка сын к отцу пришел”… или правильная формулировка задачи

Boris Bogdanov — Fri, 16 Apr 2010 14:52:05 +0000

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

Неспособность объяснить необходимость той или иной штуки так, чтобы это было очевидно не гику — большая беда для разработчиков. Не так давно я смотрел на презентации стартапов в рамках РИТ++, и лишний раз увидел, что люди просто не способны взглянуть на проблему со стороны и рассказать о ней так, чтобы заинтересовать другого человека.

Итак, давайте рассмотрим простую ситуацию — мы в отделе решили заняться клиентской оптимизацией. Нам очевидно, зачем это необходимо. Осталось убедить в этом руководство. А теперь представьте — прихожу я к генеральному директору и говорю: “Дорогой директор, мы решили в нашем перегруженном графике выделить месяц на переверстку сайта и панелей управления, переработку процедуры выкладки материалов на боевой сервер и изменить настройки сервера”. Вопрос будет только один — “зачем?!” И вот тут, если я отвечу что-нибудь в духе “Ну, это уменьшит количество http-запросов, ускорит рендеринг на стороне клиента, плюс файлы будут нормально кешироваться”, то задачу можно считать похороненой — генеральному наплевать на количество запросов к серверу и, отмечу, тут он совершенно прав.

Итак… зачем же мы всё это делаем? Снижение числа запросов? Гм… и что? Ускорение загрузки и рендеринга страниц? Уже ближе, но, если быть кристально честными, нам-то какое дело? Так зачем же?.. Ответ прост и банален — деньги. Мы рассчитываем, что клиентская оптимизация с одной стороны увеличит уровень конверсии, т.е. количество заказов, а с другой стороны — снизит отток клиентов. И вот это уже — довод. Простой вопрос — а чем подтверждается этот довод? Ну что ж… тут вопрос… Те, данные, которые нам доступны, не слишком новы. Но всё же:

Amazon: 100 ms of extra load time caused a 1% drop in sales. (Source:Greg Linden, Amazon)
Google: 500 ms of extra load time caused 20% fewer searches. (Source:Marrissa Mayer, Google)
Google: trimming page size by 30% resulted in 30% more map requests. (Source: Marrissa Mayer, Google)
Yahoo!: 400 ms of extra load time caused a 5 to 9% increase in the number of people that clicked “back” before the page even loaded. (Source: Nicole Sullivan, Yahoo!)

Итого — “большие мальчики” достаточно давно заметили связь между скоростью загрузки страниц и удовлетворенностью клиентов и своими доходами. В итоге, скажем, Google использует скорость загрузки в качестве доп. фактора при ранжировании. Тот же Гугл вместе с Яху достаточно давно ведет пропагандисткую работу и предоставляет инструментарий для оценки скорости работы сайта и оптимизации.

Итого, делаем простое предложение: давайте мы потратим неделю на первичную оптимизацию, посмотрим эффективность. Я уверен, что затраты на эту работу оправдаются. Чтобы расходы “отбились”, положим, за 6 месяцев, мы должны увеличить количество заказов хотя бы на 0,3%. Что ж, это я точно смогу обеспечить, тут я уверен.

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

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами.

Роман об управлении проектами

Boris Bogdanov — Sun, 21 Feb 2010 07:31:35 +0000

Недавно заказывал очередную порцию книг для отдела. Про пришедшие книги стоит рассказать отдельно (скажем, справочник по MySQL оказался очень приличным), но в ходе розысков, я увидел, что переиздали “Deadline. Роман об управлении проектами“.

Книга очень и очень достойная. Это действительно роман, более того, роман с налётом детектива, настоящий easy reading. О художественных достоинствах можно долго спорить, но в легкой, едва ли не игровой форме обсуждаются основные вопросы, с которыми сталкивается каждый проджект — формирование команды, планирование, взаимодействие с руководством и заказчиками.

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

Интересна эта тема? Посмотрите архив сообщений по теме Книги, Управление проектами.

Корпоративные приложения

Boris Bogdanov — Wed, 02 Sep 2009 20:33:17 +0000

4 года я занимался проектированием и разработкой сайтов в качестве ведущего разработчика, менеджера проекта и т.д. Проекты по большей части крупные, для серьезных компаний, но… но где-то через года полтора-два сценарии идут на автомате. “Так, интернет магазин, фишки такие и такие, а еще недавно вот там видел вот такое, взаимосвязи вот такие, тут лучше чуть упростить, чтобы снизить сроки и бюджеты, а тут вот так, я давно такую штуку придумал, тут будет очень здорово, да и затрат практически никаких”. Когда проекты идут на потоке, по несколько в параллели, появляются автоматизм и отстраненность, основное внимание уходит не на сам проект, а на заказчика. А вот с прошлого ноября… сперва пол года в стартапе, а последние несколько месяцев – хостинг: сервера, панели управления и т.д. И вот тут начинается интересное:

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

“Внешние” проекты, точнее, проекты для внешних пользователей достаточно просты. Да, там тоже хватает интересных моментов, туда вкладывается огромный объем труда (в конце концов, именно с этими интерфейсами работают клиенты), но самое сложное для меня – внутренние сервисы. Тут и на порядок больше данных, и среднее время работы с приложением больше в разы и т.д. Давайте вспомним давнюю карикатуру:

И вот выясняется, что ничего анекдотического в этой картинке нет. Скажем, карточка с информацией о пользователе… нет, это что-то нечеловеческое: информация об аккаунте, основные операции с аккаунтом, “привязанные” к аккаунту домены, море финансовых показателей, документы, комментарии админов, логи операций и т.д. и т.п. Плюс толпа всплывающих форм с подробной информацией, редактированием. Добавьте к этому то, что в системе огромный объем унаследованного кода, приложения развивались многие годы, сложный путь эволюции. Так что попытки сведения всего в единую стройную систему, мягко говоря, требуют такта, внимания и тщательного обдумывания.

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

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

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами.