Monthly Archives: January 2011

Startup Crash Test 18. Going global


Был на Startup Crash Test 18. Going global.

Был только на первой половине, собственно которая и раскрывает суть названия ивента “Going global”
Были  представлены Prom.ua, ExpoPromo, Jooble и Бас Гоцка – русcкоговорящий голландец, которые одно время занимался маркетингом Озона, и раскручивал в Европе eBookers и еще много чего.
Jooble уже в 25 странах,
Promo.ua продают товары и услуги других компаний.
Российский рынок раз в 10 больше чем Украинский.
Jooble предпочитает офисы не снимать, а нанимать в Киеве говорящих на других языках людей, желательно хоть немного знающих культуру.
Офис нужен в связи с разницей во времени, необходимостью проведения платежей, язык.
ExpoPromo нужно чтобы бизнес присутствовал. ExpoPromo откроют в  Британии офис, когда он будет давать 100000 в год, иначе не выгодно. Это дороже чем в США.
eBookers-у нужны были локальные кол-центры, люди, умеющие и знающие как дешевле договариваться на месте. Бас часто летал, поскольку смотрел что успешного в одном из 9 офисов (всего 12) и переносил это в другие.
Тратили в ~2005 через гугл 76 млн, но гугл не делал никаких скидок.
Jooble не получилось развить в Чехии, потому что Гугл там занимал меньше 20% от поиска, а у них бизнес завязан на гугле. В австралии есть сильный лидер среди сайтов работ, поэтому Jooble не нужен, чтобы объединять там сайты работы.
Николай (Prom.ua): лучше делать то что уже работает, а не выдумывать. В Силиконовой долине на много больше придумывают и вероятнее всего там и выдумают новое. Но это в начале, дальше можно развиваться уже на своих идеях и запросах клиентов. Prom.ua сначала делался как copy-cut Alibaba.com, теперь они занимают разные ниши.
Для Пром было сложно искать переводчика с Португальского.  Их в Украине «четыре» J
Jooble – это торговый центр, у которого себя размещают сайты работ. Им платит например Monster.com, Jooble не конкурирует с сайтами поиска работы, на которых непосредственно размещены вакансии и резюме. C США заходов 250000 в месяц, больше в Европе, около 30000 в день с западно европейской страны. В восточной европе – около 80 000, 25% дохода с Украины, потому что начинали здесь.
Для ExpoPromo Китай – основной источник дохода, много выставок, развивается промышленность.
«Не нужно жить в дорогих отелях – вылазит боком» – ниасилил.

Если проект глобальный, то с Украины лучше не начинать, например лучше начать с Германии чем с Украины. В Украине только экспенсы технические, даже не нужно проверять глобальные модели. В той же германии все более развито, те же электронные платежи, например.
Prom.ua  не имеет глобального бренда – он им не нужен, они продают локальные  товары, у них сайты по разному кругом называются.
А Jooble– глобальный бренд, хотя не понятно нужен ли он им.
Если транзакции проходят из други хстран, то есть смысл в одном бренде, иначе –не понятно, зачем.
Неудобства предоставляют занятые домены в других зонах («Domain driven brand hell» © Eгор).

Бас переносил бизнес из Австралии в Британию. Американцы: «Если хочешь убедить Европу, убеди сначала Голландию»
В России, Белоруссии нужно юр.лицо, чтобы принимать платежи.
Развитие Jooble в новой стране занимает около месяца – менеджер обзванивает локальные сайты и около месяца занимает договориться с сайтами, чтобы получить xml-каналы и даже роботов не запускают сейчас, хотя иногда запускают. Около 2% отказываются – «закрытые клубы».


У Jooble-а есть большие таблицы с цифрами для того, чтобы понять пойдет ли бизнес в новой стране и на кого она похожа. Но чтобы узнать, запускают бизнес.
Prom.ua: “проблемы микроплатежей нет»
 Юридически компании существуют в той стране, где работают – налоги законы и т.д.
ExpoPromo начинали с Украины и сравнительно легко было развиваться в других странах, поскольку транзакции международные  В мире 10000-12000 клиентов.
В Jooble и ExpoPromo вирусности в приличении клиентов нет поскольку они конкуренты.
В Prom.ua отслеживают коэффициент вирусности, «как именно – не знают, сколько какого у них трафика – не знают, сколько стоит новый клиент – не знают, что такое Google-Analytics – не знают».
В  eBookers Бельгия давала столько же прибыли, сколько и большие европейские страны, посколько New Your times делали исследования и на Бельгийском сайте нашли что-то самое дешевое, и все как на «диковинку» туда ходили – «Это карма уравновесила предыдущие неудачи».
Для Jooble в Украине хорошой клиент за 0.20 грн, 2 грн в Европе и 6 грн в США.
В Prom.ua стоимость клиентов в разных странах отличается до 2.5 раз.

Больше инфо на http://twitter.com/#search?q=%23sctest

Спасибо Денису и Ко за организацию! 

Заказчик не отвечает на просьбы уточнить требования. Что с этим делать?

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

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

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

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

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

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

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

Конкретные слова каждый меняет под себя, но суть где-то такая 🙂 Можно еще там добавить что-то типа, что мы ж работаем для достижения общего результата или другие комсомольские лозунги – тоже повышает чувство ответственности заказчика.

А сразу после этого приступаем к имплементации.

В результате заказчик часто просыпается и дело идет на поправку.
А если не просыпается, то вы реализуете фичу так, как описали в документе.
Если ваше понимание верно – ну и замечательно.

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

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

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

Шаблонизаторы в шаблонизирующих языках для создания web-страниц

… тавтологичность в названии статьи достаточно точно и отражается в сути дела. Так что звучит не красиво, но уж как есть. Из песни слов не выкинешь.
 
В разработке веб приложений часто используют шаблонизаторы html-страниц – в шаблон вписывают переменные (код, предположительно написан веб-дизайнером), значения которым перед этим присваиваются в бизнес логике (код, предположительно разработчиком). Преимущества такого подхода в том, что логика приложения максимально отделена от отображения. Это, к примеру, дает возможность совместной работы над одним проектом разработчиков и веб-дизайнеров, особо “не мешая” друг другу.

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

Возьмем, к примеру, PHP. Для него один из самых популярных шаблонизаторов – Smarty.
Но при попытке его использовать на тестовом приложении от разработчиков пакета сразу полезли неприятные сюрпризы. Нужно было отлаживать и менять код. С одной стороны это сразу говорит о несерьйозном подходе в плане поддержки. С другой все таки дает возможность реально отладить код с первых секунд – и сразу становится ясным, что тебя еще поджидает.
При попытке выяснить у Software Development Community, зачем они используют Smarty, ничего внятного услышать не удалось. С другой стороны внятными были только аргументы против использования еще одного пакета. 

Также была путаница шаблонизации с концепцией MVC, хотя, безусловно, они связаны. Были аргументы в пользу простоты синтаксиса, как будто бы веб-дизайнеры не намного далеко ушли в своем развитии от приматов, хотя при приведении аргументов было очевидно, что люди PHP толком-то и не знают. Был также аргумент касательно кеширования – хотя это в общем то не функция темплетизаторов, а скорее довесок, и возможно, если поискать, то будут более эффективные решения, которые целенаправленно занимаются вопросом кеширования, а не так, “между прочим”.
А статья про сравнение синтасиса от разработчиков Smarty превзошла все мои ожидания маразма – сравнение идет путем подсчитывания символов, которое, в прочем, не особо отличается.

Также встречалось книжное «разделить логику и представление» – хотя PHP собственно сам представляет эту возможность. Так нет – вопрос о том, что если посадить идиота и сказать где писать логику, а где генерировать страницу и он не поймет, то Smarty решит эту проблему – заставит идиота правильно писать! И в очередной раз проблемы, связанные с человеческим  фактором хотят решить технологиями, в общем то иногда это получается, но не часто. Но проблема, видимо, где-то есть, возможно это связано с низким порогом входа в PHP. С одной стороны высококлассные девелоперы ни за что не хотят работать с некомпетентыми людьми, вплоть до высказываний: «дураков надо либо переучать, а если не получается – то отстреливать». С другой стороны, не смотря на низкое качество, но благодаря и низкой цене, услугами индусов все еще продолжают активно пользоваться.

Ну и заканчивая с PHP и Smarty, поскольку ничего внятного узнать не удалось, то собственно есть смысл использовать pure PHP. Для старта может быть полезна статья Нативный шаблонизатор, хотя уже то появляются готовые решения, так называемые native template engines, например STemp (какое жуткое название, можно случайно удалить, если срочно понадобится и прийдется искать свободное место на диске) или Savant. Проблема, скорее в модном сочетании “template engine”, а не в базовом языке программировани.
А как дела обстоят в других языках?
Рассмотрим Java. Вроде бы там есть JavaServer Pages. А почему же все таки появились другие шаблонизаторы? Причина опять же очевидна – закотели впутать JSP в Java2EE и чтобы на JSP что-то написать, то больше геморроя, чем пользы при генерации страниц – все конечно заведется, но сильно накладно. Поскольку native-технология по шаблонизации оставляет желать лучшего, вот и появился целый букет шаблонизаторов, выбор среди которых кроме головной боли ничего не приносит.
Что касается .NET, то не смотря на наличие ASP «и Ко», что-то там тоже не в порядке, если появилось множество third party Template Engines.
Картина какая-то непонятная вырисовывается. Много всего, кому надо – выбирай. Неправильно выбрал – потом дорого «слезать» с технологии – как повезет.
Резюмируя, в IT сообщество цирк продолжается. Каждый пишет что-то такое универсальное, что решает все задачи. Но поскольку пишет каждый, то не кому это все использовать 🙂

А знаете ли вы, что в США очень популярны internet-сервисы Клубов по интересам?

В США уже давно пользуется популярностью сервисы клубов по интересам.

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

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

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

Собственно так и появился достаточо challenging проект MyLogic.
У тех, кто обладает достаточной компетенцией, есть возможность поучаствовать в проекте, физически не перемещаясь в Ядро развития информационных технологий Силиконовую Долину, а так же ощучить, как там все происходит.

Итак, открыты следующие позиции:

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

Встреча КУЛ-IT – 20 января «Карьера в IT-инжиниринге и успешный поиск работы»

В Киеве, 20 января (четверг) в 19.00 состоится очередная встреча клуба управляющих ЛЮДЬМИ в IT компаниях.

Особо обратил внимание на вторую тему “Выступление №2: “Как найти работу своей мечты?”. У меня есть основания полагать, что этого сделать нельзя 🙂
Однако докладчик очень опытен и ему, видимо, есть что ответить на мою точку зрения.

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