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

Метод скорее относится к инструментам Customer Development и затягивает в анализ всю команду разработки. Каждый тест с интересом смотрят и программисты, и дизайнеры. Мгновенно разгораются споры и обсуждения, как пофиксить баг или UX-проблему.


График роста числа активных пользователей системы в день

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

Есть такая проблема в компаниях — беспорядок в задачах. С ростом команды эта проблема приводит к параличу. Сроки срываются, работа по проекту тормозится, задачи теряются. И чем выше процент потерь, тем сильнее падает общая эффективность команды. А самое интересное то, что команды к этому привыкают.

Так, из-за потери 10% задач, компании теряют от 10% (если задачи не связаны между собой) до 100% (если связь сильная) эффективности и в конечном итоге выручки. Уберите один болт, и ракета не полетит.



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

Расскажу историю, которая «развернула» мое представление о том, в чем нуждаются реальные компании в области управления проектами и задачами.

Это была обычная встреча с компанией, в которой работают около 150 человек, разрабатывают немного секретные приборы видеонаблюдения…

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

Поделюсь личным опытом, как нанимать удаленных сотрудников, как формировать рабочие процессы и как обустроить уютный виртуальный «офис».

Сейчас в нашей команде YouGile работает 10 человек, и все – в удаленном формате. Мы не привлекаем инвестиций, получаем прибыль и растем в активных пользователях по 10% в месяц вот уже 2 года.

Ежедневная планерка

И я могу сказать, что сформировать суперкоманду на удаленке вполне реально – рынок удаленной работы год от года растет. Мне есть с чем сравнивать: наша первая IT-компания (RedHelper) снимала 250 м2 на Павелецкой в Москве.

В статье две части: «Часть 1. Как мы ищем людей» и «Часть 2. Как мы организуем работу». Ведь перед тем, как организовывать процессы, важно сформировать хорошую команду.

Приглашаю заглянуть в наше «закулисье».

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

Меня эти вопросы волнуют особенно. Я последние два года работаю над системой управления YouGile.

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

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

То, что мы в итоге сделали после изучения этого вопроса — ниже в коротком ролике. А под катом описание процесса, как к этому пришли.

Хабр, привет! Меня зовут Антон, я руководитель YouGile (система управления проектами). Самое полезное, что я делаю в компании — это общаюсь с клиентами на тему того, как вести проекты и как связывать отделы в системе управления.

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

Две хорошие практики планирования на год на Agile-доске в небольшой команде:

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

Сколько явно злых практик применяется у вас? Если только часть из перечисленных ниже, то можно подсунуть эту статейку своему начальнику и станет быстрее понятно куда всё движется.
Вредные советы очень полезны!



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

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

За последний месяц я провел 71 обучающий скайп-звонок с самыми разными компаниями. Задачей было внедрить разрабатываемую нами систему управления проектами. Запрос у всех согласившихся на такой формат примерно один и тот же — “Как втянуть команду в систему ведения проектом и в сам проект?”. Или проще говоря: “Как сделать так, чтобы все работали?”.

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



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

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

Есть исследования и великолепная инфографика о том, как Agile распространен в мире. Этим можно вдохновиться, но выводы очень далеки от нашей действительности. Там попросту очень мало респондентов с постсоветского пространства.

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

Мы регулярно делаем выводы из прямого общения с клиентами. Собираем все хотелки по системе от пользователей и строим картину обращений. Но самое большое количество прозрений появилось сейчас, после запуска опроса. Уже набралось 300 респондентов (цель 1500) и можно посмотреть и обсудить первые результаты.

Можно ли сказать, что что-то из Agile используется в вашей компании?

Под катом первые графики, выводы, рассуждения и призыв пройти опрос.

Мы провели опрос наших пользователей на тему “Нужна ли коробочная версия системы управления проектами?”. Для нас точный ответ на этот вопрос имеет большое значение. Определяет путь развития системы и приоритеты по новым функциям.



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

Под катом графики с результатами и наши выводы.

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или "Как рассказать дедушке" и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.


Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

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

«Можно обманывать некоторых людей все время, всех людей некоторое время, но невозможно обманывать всех людей все время». Авраам Линкольн

Самое недооцененное, на чем может заработать каждая компании — это Сервис. Раза в два можно увеличить оборот, но придется быть честным до конца. Хитрить со всеми все время все равно не получится.

Свежая история, где клиент чувствует, что остался в дураках:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки вместо трех ящиков.
Развели руками, увезли три бутылки, сказали, что на складе что-то пошло не так.
Никаких действий от магазина.
Позвонил, в поддержку. Удивились, посмеялись, сообщили, что составили запрос, специалист изучит и вынесет решение.
Через день пришло письмо с извинениями и скидкой 100 руб. на следующий заказ.
Написал в ответ “А может доставите мне мой заказ?”
Без реакций.

А экономика сервиса работает так:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки.
Извинились. И через два часа привезли четыре ящика. Один подарили.
Делать заказы тут стал чаще.
Рассказал в течении месяца историю еще пяти знакомым, трое попробовали, один стал клиентом.
Потратили на меня меньше 600 руб., за год заработали от 30 000 руб.

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

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

Что самое важное в организации команды? Может построить планы?

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

Что делают успешные команды и чего не делают разваливающиеся за неделю? Что важнее — назначить на каждую задачу исполнителя или проставлять дедлайны, а может самое важное ставить приоритеты? Есть ли действие, которое значительно увеличивает срок жизни проекта?



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

Первого апреля системе YouGile исполнился год. Нешуточный срок для проекта, который начался с мысли — «А давайте на выходных сделаем себе удобную систему управления проектами». Сейчас несколько тысяч пользователей, в основном переходят с BaseCamp и Trello, все открыто для тестирований и присылания нам обратной связи.

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

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

Работает просто — по комбинации клавиш Ctrl+~ вызывается встроенный редактор JavaScript.



Можно на JS писать или заливать любые скрипты и они будут менять работу отдельных досок или проектов в компании. Выделена библиотека — примерно 200 объектов и методов, которые позволяют менять параметры системы, выполнять свой код на различные события в системе и удобно создавать свои элементы интерфейса или изменять существующие.
В статье рассматриваются примеры и задается вопрос о необходимости такой функции в системах управления проектами.

Дело в том, что примерно через месяц в Y Combinator будет проходить очередной тур отбора компаний S2017. Это самый известный и раскрученный акселератор Кремниевой долины. Участие само по себе имеет смысл, даже если вы не думаете о себе, как о стартапе. Это также возможность съездить командой в Сан-Франциско на халяву.
В этой статье — наш опыт от прошлого конкурса W2016 и расшифровка аудиозаписи с очного отбора.



Все началось случайно. Подал заявку вечером в пятницу, на неделю позже сроков объявленных на сайте. Заявка простая, заполняется за пару часов, самое сложное для нас было записать ролик на 1 минуту с объяснением того, что мы делаем. Получилось так криво, что партнер попросил удалить ссылку из статьи. Но этого оказалось достаточно, чтобы пройти конкурс 500 из 10 000 заявок и быть приглашенным на очный тур.

После отправки заявки было еще собеседование по скайпу, очень короткое, 5-10 мин. Нас спросили что мы делаем, а после ответа сказали: “Но ведь этого и так полно и никому не нужна еще одна такая система!” На это мы 5 минут наперебой рассказывали, что нет, мы делаем все по другому и у нас будет лучше всех. Нам сказали: “Ок” и через 5 дней пришло приглашение: “Прилетайте”, а еще через день мы вылетели.

Последние 10 лет для ведения проектов мы пользовались такими системами как YouTrack, Jira, Asana, Slack, SmartSheet, BaseCamp, Trello и даже белой доской, а также постоянно тестировали что-то новое. По нашему мнению, главная проблема всех систем управления в том, что люди в компании попросту забивают на её использование. А было бы здорово, если информация на все отделы распространялась из одной системы и вся команда сама активно постоянно ей пользовалась.

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

Для начала хотели реализовать 2 вещи:

• Секундомеры на каждой задаче, потому что было ощущение, что это позволит точнее понимать как расходуется время в команде;
• Универсальность. Предполагали, что отдел разработки, поддержки и все остальные отделы могут работать в одной системе.

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