AJAX Planet

Задача без сроков не решается

Boris Bogdanov — Thu, 13 Oct 2011 13:00:55 +0000

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

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

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

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

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

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

Переворот интерфейса

Boris Bogdanov — Thu, 13 Oct 2011 12:58:54 +0000

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

Тенденция достаточно любопытная и всё более усиливающаяся: на днях ReadItLater, известный, прежде всего, за счет своих приложений для iPhone & Android, выкатил и онлайн-просмотр заметок для больших экранов. И я вполне осознанно говорю “больших экранов”, а не, скажем, ” браузеров настольных операционных систем”: дело в том, что создается отчетливое ощущение, что сделана эта версия для планшетов. Не для ноутбуков и, тем более, не для десктопов, а именно для планшетов — посмотрите на общий внешний вид, обратите внимание на элементы управления, ведь всё же рассчитано на тач-интерфейс.

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

Eating your own dog food

Boris Bogdanov — Thu, 29 Sep 2011 15:15:21 +0000

Есть один простой, но почему-то не так часто используемый в наших палестинах способ совершенствования качества сервиса. Он настолько банален, что и говорить как-то неудобно: Eating your own dog food, т.е. по простому — использование собственных сервисов сотрудниками компании. Чаще всего эта политика используется в софтверных или технологических компаниях, что и понятно. Если вы видите сервис, в котором есть огромное количество мелочей, которые облегчают жизнь и появляются ровно в тот момент, когда они нужны… что ж, команда любит свой сервис, а кто-то уже достаточно эволюционировал, чтобы думать не только на уровне кода, но и интерфейса. Правда, будем честны, есть и другая крайность: типично “программерский дизайн” — это как раз, если этот шаг сделан не был, и весь интерфейс представляет собой бешенную мешанину контролов, художественно разбросанную по экрану. Впрочем, не об этом сейчас речь.

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

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

Да, ссылка куда-нибудь в саппорт или бухгалтерию, чтобы “почувствовать чужую боль” — действие, которое надо проводить очень аккуратно, но есть и множество других вариантов. Самое простое — дайте своим сотрудником право бесплатного пользования своим сервисом. Так было на прошлой моей работой — был отдельный тариф Staff с нулевой стоимостью. Впрочем, лучше не просто давать пользоваться бесплатно, а компенсировать 100% затраченных средств. В чем разница?.. Разница очень проста — тогда люди будут полноценно взаимодействовать с сервисом, в том числе и с формами оплаты. И будут ходить и ныть, что так платить неудобно, а давайте подключим такие-то терминалы, у меня как раз возле дома такой стоит и т.д. И достаточно часто случается, что именно тут и наблюдаются большие проблемы: если клиент и доволен сервисом, но заплатить за него не может, врядли он будет его использовать.

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

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

Компания меняется, люди уходят

Boris Bogdanov — Thu, 25 Aug 2011 12:38:10 +0000

Наверняка все, кто интересовался менеджментом, хоть раз видели модель Такмана – forming-storming-performing. Проблема в том, что начинается после performing. А за границей performing есть только один вариант: evolving, вопрос в том, когда он начнется и как именно будет выглядеть.

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

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

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

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

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

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

Впрочем… можно посмотреть на ситуацию чуть по-другому: если человек ушел, а за ним всё развалилось, то он просто не сумел воспитать команду, которая может заменить его, пусть и не полностью, и продолжить его дело.

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

Осторожно, двери закрываются

Boris Bogdanov — Wed, 24 Aug 2011 18:19:03 +0000

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

То, что происходило последний год, выглядело достаточно печально: большие компании занимались попытками поглощения, продажей .рф-ных доменов, да и всё. Технологически гораздо быстрее менялись компании поменьше. Никто из первой пятерки так и не выкатил облако, не начал работать с SaaS… Стагнация. Понятно, что на данный момент шаред-хостинг является наиболее массовым, простым и понятным, но также понятно, что его ниша будет сужаться, и, если через 3-5 лет хочется иметь конкурентоспособное решение, то его уже надо активно делать. А было ощущение, что всех устраивает сложившаяся ситуация, и все изменения, если откинуть громкие слова, упираются в покупку конкурентов и политические игры.

Впрочем, покупками серьезно занимался разве что Хостинг Коммьюнити (читай РБК). При этом объединенные хостеры ощущают себя всё хуже: на графике 1stat Хостинг Центр стагнирует уже не первый год, с начала зимы падают темпы роста и качество обслуживания у SpaceWeb.

Ощущение главенства и контроля лишь усилилось после начала покупки Ру-Центра. Похоже, что большая доля рынка сыграла дурную шутку… Теперь же может появиться конкурент, который по размерам не меньше Хосткомма и, возможно, будет развиваться динамичнее. И, дай бог, начнется нормальная конкурентная война, с развитием технологий и улучшением качества сервиса, а то и снижением цен. Только это и может спасти компании.

Пока от прихода “больших дядей” отечественный рынок хостинга спасала его крошечность: за прошлый год весь оборот отечественного хостинга составил всего порядка 120-140 миллионов долларов. Одновременно местных потребителей от работы с западными хостерами напрямую традиционно сдерживают отсутствие русскоязычной поддержки и необходимость предоставлять налоговой отчетные документы по РСБУ.

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

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

Стоимость найма

Boris Bogdanov — Sun, 07 Aug 2011 17:50:35 +0000

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

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

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

Кроме того почему-то практически никто и никогда не считает стоимость найма и обучения. Нанимая программистов к себе в команду, я проводил минимум 6-8 собеседований с кандидатами. При этом на собеседовании присутствую не только я, но и hr, а на «втором круге» еще и руководитель группы, куда должен попасть человек (да, у нас была странная ситуация, когда фактически второе и первое собеседование были поменяны местами). Учтите при этом, что собеседования с хорошим кандидатом получаются долгими и выматывающими, каждое это минимум 3-4 человеко-часа далеко не самых низкооплачиваемых сотрудников. Добавьте к этому время на работу с резюме, переговоры с кандидатами, внутренние согласования, и получится, что найм одного кандидата стоит в среднем 2 человеко-недели вовлеченных в этот процесс. В рубли, думается, каждый пересчитает сам.

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

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

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

Невидимая рука рынка

Boris Bogdanov — Sun, 03 Jul 2011 16:14:29 +0000

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

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

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

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

Конкуренция со своими же потребителями

Boris Bogdanov — Sun, 24 Apr 2011 12:27:47 +0000

Одно из первейших требований к любому продукту и построению механизмов по его продаже — понимать, кто является целевой аудиторией. Если непосредственными покупателями являются распространители, то открытие прямых каналов продаж будет фактически означать, что вы начинаете конкурировать с ними, при этом появляется естественное желание “подыграть” себе: т.е. по прямым каналам продавать дешевле, а дилерам — подороже. И не факт, что после этого дилеры не переключатся на других поставщиков. Если не ошибаюсь, у Траута был описан подобный случай с Oriflame или Avon. Впрочем, ближе к делу.

Есть компания UMI.CMS. Компания появилась как развитие внутренних разработок UMI Studio. Вспоминая начальный период развития этого ПО как коробочной системы управления, не могу не сказать про опасения веб-студий: когда клиент приходит за CMS к её производителю и просит комплексное решение (а это частый случай), естественным является желание отправить клиента не просто к какому-то партнеру, а к себе же, в компанию аффилированную, близкую, родственную. Этап такого недоверия был достаточно долгим, и спасло UMI.CMS, пожалуй, то, что одноименная студия работала прежде всего в Питере и имела ограниченные мощности, так что для компании откуда-нибудь Нижнего Новгорода или Екатеринбурга её наличие не было критичным.

Вслед за выпуском CMS вполне логичным для UMI шагом стало сотрудничество с хостинговыми компаниями. Здесь тоже всё понятно: для хостеров это был способ продавать не лицензии, а, по факту, свои же услуги с большей прибылью, чем обычно: UMI.CMS достаточно нетребовательна, настройка под неё серверов не является каким-то подвигом, при этом партнерские отчисления за лицензию заметно превосходят прибыль от обычных клиентов, да и без продажи лицензий маржа на специализированных тарифных планах больше. Плюс, и это не надо забывать, UMI.CMS в данном случае выступает не только в качестве товара, но и канала продаж. Для Юми, в свою очередь, это доступ к большому количеству потенциальных покупателей: число клиентов у ведущих хостеров измеряется десятками тысяч, и это всё целевая аудитория.

По всей видимости, подобный симбиоз действительно дал толчок для бизнеса, и в какое-то время компания решила заняться SaaS: т.е. дать хостерам сайт-билдер, легко интегрируемый с их биллингом и клиентскими панелями управления. Более того, Сергей Котырев активно рекламировал UMI.Cloud на Хостобзоре. Тем не менее, бизнес не пошел. Я могу попробовать изложить свою точку зрения на вопрос “почему”, но это не входит в рамки этой заметки. Просто констатируем факт: не пошло…

На сегодня ребята из юми качнулись в другую сторону: открыли дочерний хостинг (umihost), а затем и свой сервис сайтов-конструкторов (umi.ru). Идея ясна, более того, я догадываюсь, кто стоял во главе проекта и рулил запуском. Более того, у меня нет каких-то сомнений, что качество услуг будет достойным. Остается одно “но”: юми начинает конкурировать с собственными продавцами. Особенно странно это выглядит на партнерских семинарах, когда в рамках первой же презентации старательно упоминают решения, являющиеся едва ли не прямыми конкурентами услуг партнеров. И, есть подозрение, что, если собственные хостинговые проекты UMI не станут просто образцово-показательной платформой, предназначенной прежде всего для того, чтобы демонстрировать хостинговым компаниям возможности ПО, то это может в долгосрочной перспективе привести к тому, что этот канал продаж практически перестанет существовать, а UMI.Cloud так и не станет тиражным решением.

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

Как показать пользователю возможности приложения?

Boris Bogdanov — Sun, 20 Feb 2011 20:13:03 +0000

Последние несколько лет у меня более-менее регулярно всплывает одна и та же проблема: веб становится всё более и более функциональным, к ajax все давно присмотрелись, да и какой-нибудь drag’n'drop уже не является чем-то удивительным, но при этом у пользователей нет привычки к такому использованию веб-интерфейсов. Проблема, пожалуй, в том, что шаблоны обращения с десктопными приложениями не транслируются в веб.

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

Когда делали новую клиентскую панель SpaceWeb, такого тяжелого и тотального использования JavaScript не было, но и тут появилась аналогичная проблема. На прошлой неделе мы запустили небольшое изменение в панели, сделали панель быстрого запуска, аналогичную тому, что пользователи уже очень и очень давно используют в операционных системах. Функция маленькая, ролик в этот раз получился всего 18 секунд, но вот будут ли пользоваться этой фичей клиенты… И у меня огромный вопрос — как, как сделать эти функции очевидными для клиентов? Как показать, что всё это возможно? Особенно, когда пользователи уже достаточно давно работают с сервисом и имеют наработанные шаблоны использования.

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

PS Радует одно: люди уже достаточно часто просто не различают веб и нативные приложения. На каком-нибудь iPhone веб-сайты можно добавить в меню, выглядеть и работать они будут аналогично обычным программам. В ChromeOS не веб-приложений просто не существует. Да и браузер Chrome от Google и проект Chromeless от Mozilla позволяют работать с любым сайтом подобно приложению: иконки, пункты в меню…

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

Семинар-междусобойчик

Boris Bogdanov — Fri, 11 Feb 2011 10:05:28 +0000

Меня всё больше раздражают it-конференции: ок, я готов понять, почему ездят и выступают практически одни и те же люди (скажем, костяк тех, кто будет выступать на ближайшем WhaleRider я готов назвать сходу, подозреваю, что ошибок будет мало). Я даже более-менее смирился с тем, что доклады зачастую повторяются, а заметная часть докладов “продуктовые” и “продающие”. Печальнее другое: даже если доклад хорош, даже если докладчик действительно интересен, шансов спокойно и с толком поговорить с ним на конференции очень и очень мало: слишком много людей, слишком мало времени. Да, никто не мешает взять визитку и потом задать вопросы по email, но… качество общения другое, скорость другая.

К чему это я?.. А… В прошлую субботу мы провели небольшой семинар. Крошечный. Для себя, знакомых и знакомых знакомых, никакой обязаловщины, своеобразный BarCamp для узкого круга. Никаких обязательных тем докладов, каждый сперва написал, что может рассказать и какие темы хотел бы послушать, потом тихо сели в офисе одной из компаний и отлично провели день. И как-то выяснилось, что без каких-либо финансовых затрат (ок, деньги на пиво не считаем), можно организовать семинар, где будут интересные люди, делающие интересные проекты, и, что особенно важно, с этими людьми можно спокойно поговорить, позадавать вопросы, поспрашивать о своих проблемах, в свою очередь чем-то помочь.

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

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