1. неСЭДы
Идея проекта qFlow пришла спонтанно, не было долгого анализа рынка на предмет потребностей и спроса, маркетинговых исследований и т.д. Просто возникло понимание, что большинство систем — CRM, ERP, трекеры и т.д. являются просто помощниками по сбору данных от пользователей, в которые зашиты свои, особенные бизнес процессы обработки и движения данных + свой инструментарий. Конечно, больше всего идея сервиса напоминала так называемые системы электронного документооборота и с самого начала аббревиатура СЭД ассоциировалась со словами ВНЕДРЕНИЕ, СОФТ, БЮРОКРАТИЯ и т.д.
Ну, как говорится, попытка не пытка. Набрал в поисковике СЭД, чередуя возможные ключевые слова, и обнаружил, что не ошибся. Наряду с определениями из словарей сразу появилась реклама с предложениями внедрить, приехать на семинар, статьи посвященные делопроизводству в России, консалтинг и отраслевые предложения. Я, как руководитель отдела компании, которую можно отнести к малому бизнесу (малым рабочим группам) сразу почувствовал себя чужеродным телом в этом сплоченном коллективе делопроизводственников.

Наверняка к вам на улице когда-нибудь приставали девушки или юноши с предложением ответить на самые разные вопросы — от «Что вы курите?» до «За кого вы собираетесь голосовать?».

Случалось ли так, что вы не сразу могли найти форму регистрации или опроса на сайте? Наверняка бывало, хотя бы раз.

Неоднократное посещение сайтов с «невидимыми» формами опроса или регистрации (иногда вообще непонятно сразу, что это опрос) вдохновила нас на доработку нашего сервиса для создания форм — qFlow. Суть его в том, что в сервисе пользователь может сам создавать веб-форму для сбора нужных данных, настраивать процесс обработки полученных результатов, а затем с помощью скрипта размещать эту форму на своём сайте.

С самого начала мы ориентировали qFlow больше на обычных, непродвинутых пользователей, поэтому делали акцент на простоте в использовании. Но если создавать веб-формы можно действительно легко и быстро, то их внешний вид был, мягко говоря, «никакой» — они были серыми…

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

Я утверждал, что производство сайтов в классическом виде – жанр вымирающий, который останется востребованным только в сегменте среднего и крупного бизнеса. Я говорил, что сегмент персональных сайтов и страниц уже изменился до неузнаваемости. Людям больше не нужны свои персональные сайты и площадки, вроде, народ.ру. Пользователь хочет получать законченные сервисы. Он выкладывает свои фотографии на фликр, ведет блог в твиттере, общается с друзьями в вконтакте и т.д. Кому нужно делать на своем свой сайт и плеер на нем, если есть youtube?

Я предполагал, что похожая история должна произойти и в сегменте сайтов для малого и среднего бизнеса. Фантазируя про будущее, я предположил, что для небольшой компании не будет смысла заказывать полностью эксклюзивную разработку собственного сайта. Достаточно, будет сделать основу (шаблон), а для всех остальных задач использовать сторонние сервисы. Нет смысла делать свою ленту новостей, когда можно поставить ленту из ЖЖ или твиттера. Нет смысла делать свою регистрацию, если есть профили из соц.сетей. Глупо делать свой аудио или видео-плеер. Зачем заказывать собственную разработку интернет-магазина, если можно получить готовое решение, настроить его и просто поставить себе соответствующий скрипт, так же, как мы делаем это с youtube’ом?

На днях мы открыли qFlow.ru – новый SaaS-проект (пока в beta-версии) для легкого создания web-форм и настройки бизнес-процессов обработки полученных результатов.

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

Идея сервиса для создания web-форм не нова и в интернете можно найти много вариантов, но найти удобный и достаточно функциональный сервис не так уж и просто. Например, в документах гугл есть конструктор web-форм, но он на английском, а работа с результатами все же не так проста, как хотелось бы. Недавно открылся сервис wufoo.com – очень симпатичный и простой, но как у в гугле нет процессов и он на английском.

Редактирование результата

История команды интернет-магазина путешествий Gate-32, которая использует наш сервис qTrack для управления проектом.

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

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

Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.

Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.

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

Предлагаем посмотреть наш to-do лист и обсудить каким должен быть идеальный список дел. Из интересных возможностей — иерархическое представление, драг-н-дроп, цветовая раскраска и самое интересное — возможность обсуждать задачи из списка дел. Цель тестирования — логические и эргономические решения (а не только поиск багов верстки и кода, хотя они конечно же принимаются). Нам очень интересно мнение хабралюдей, как искушенных пользователей.



Кстати, базовый функционал, который включает to-do лист, предоставляется бесплатно.
У нашего списка дел есть не все возможные функции, потому что мы хотим, чтобы наш сервис был не слишком сложным (совсем простым его вряд ли можно назвать). Поэтому, самые ценные предложения — про упрощение и улучшение эргономики.

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

Наблюдая за разными старт-апами, я стал замечать, что каждый новый проект проходит 3 фазы развития: «эйфорический», «депрессивный» и «реалистичный»

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

Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.

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