Чуть больше года мы делаем свою систему управления проектами. Не так давно база активных пользователей перевалила за 1000 и появилась крутая возможность — изучать статистику того, как компании подходят к организации процессов.
Что делают успешные команды и чего не делают разваливающиеся за неделю? Можно ответить на глупые вопросы: что важнее — назначить на каждую задачу исполнителя или проставлять дедлайны, а может самое важное ставить приоритеты? Есть ли действие, которое значительно увеличивает срок жизни проекта?
И оказалось, что есть простой ответ. Обнаружив его, мы резко приостановили работы над функциями и всей командой сфокусировались на мобильном приложении…
Эксперимент
Мы выделяли группы пользователей, которые после регистрации делали упор на той или иной функции в системе. Далее считали дневной показатель возвратов по сотрудникам этих компаний. (Daily Retention Rate — видео, которое вдохновило на эксперимент). Другими словами, мы смотрели, как конвертируется пользователь на ранних стадиях — воспринимает ли он систему как место для постановки задач или, например, хочет максимально контролировать процессы; пытались понять, насколько долго он задерживается в системе в зависимости от старта.
Казалось, что такой подход просто позволил бы узнать какой группе лучше всего подходит система. Однако правда такова, что и белая доска на стене подходит под любую схему организации, была бы только воля в команде постоянно пользоваться доской.
Таким образом, побочным, но гораздо более интересным результатом наших экспериментов оказалось то, что можно узнать, при каком подходе активность по проекту затухает за пару месяцев, а в каком он живет долго вне зависимости от результатов. Из статистики можно делать выводы о полезности действий при организации проекта.
По большинству выборок никаких интересных результатов обнаружить не удается. Как правило, действие, которое мы выбирали, ничего не говорит и никак не влияет на срок жизни начинающей команды. Например, назначение задач на исполнителей не несет никакой особенной важности; те компании, которые делают упор на это в начале использования, имеют такой же показатель возвратов как и в среднем по всей базе. Еще важно отметить, что все выборки были примерно одного размера. Ситуации, что мы просто отобрали компании, прошедшие более высокий барьер, нет.
Но две группы дали принципиальные отличия от среднего.
Результаты
Самый яркий отрицательный паттерн — это большое количество генерируемых задач. График активности таких компаний достаточно быстро падает и стремится к асимптоте около нуля.
Компании, которые генерируют много задач (более 20 в день на человека в первую неделю), через 100 дней будут существовать только с вероятностью 4%.
В реальности это выглядит так, что один очень энергичный руководитель бесконечно ставит задачи, разбивая проект так, как только ему понятно, практически ничего не обсуждает, требует выполнения, приходит в ярость, когда выполненные задачи не дают общего результата. Каким бы абсурдным не казался этот пример, встречается он часто.
Самый яркий положительный паттерн — это большое количество общения, вопросов.
Компании, которые в первые же дни набирают больше 10 сообщений на участника команды, через 100 дней выживают в системе с вероятностью 42%.
На практике это выглядит так, что задач генерируется немного, декомпозиция происходит в описании задачи, к большинству задач подключаются несколько человек и ведут обсуждения, нет одного самого активного участника, структура коллектива плоская, формулируется много вопросов. Как правило это команда равноправных участников или с грамотным руководителем.
Вобщем — задать вопрос в десять раз лучше, чем поставить задачу.
Разворот в приоритетах разработки
На проект YouGile эксперимент оказал сильное влияние. Нет, мы не стали задавать больше вопросов друг другу. Мы поменяли идеологию, сделали небольшой поворот в развитии продукта. Теперь делаем упор на организации взаимодействия команд вокруг задач.
В отличие от белой доски, система управления должна засасывать, как засасывает Facebook. Каждый день просматривать задачи по проекту, вовремя задавать вопросы, общаться — всё это должно быть нормой для всей команды. В идеальном мире такая система должна позволять организовать 100 человек с такой же легкостью, как стартап из 5.
Если общение настолько важно, то наличие мобильной версии должно заметно повысить шансы на успех в компаниях. Мы приостановили работу над функциями и всей командой стали допиливать мобильное приложение. Задача была сделать так, чтобы упор в системе управления проектами был именно на общении.
Получилось интересно, нам и нескольким близким компаниям из числа тестирующих нравится. Все общение окончательно перешло в систему и стало идеально структурировано по задачам.
Вот так выглядит список всех проектов. При клике на какой-то конкретный открывается доска и можно просмотреть все задачи.
Вторая кнопка в нижнем меню позволяет просмотреть все диалоги по задачам. Есть разделение диалогов, по которым вы были нотифицированы и диалогов, которые вам доступны для просмотра, но вас почему-то не добавили в уведомление.
Третья кнопка в нижнем меню открывает список участников всей компании и позволяет вести личную переписку. Никто кроме вас и собеседника не имеет к ней доступ.
От запуска мобильной версии ждем роста показателя возвратов на 10%, на практике это означает, что компании будут на 10% дольше упираться, прежде чем бросить проект. Может кто-то и потратит больше времени впустую, работая над заведомо мертвой идеей, но наша задача сделать так, чтобы при этом вся команда была вовлечена в процесс.
Как наберется статистика с использованием мобильной версии, добавлю сюда новый график.
Сайт системы — yougile.com
Комментарии (32)
kostus1974
06.06.2017 17:31+1можете объяснить, отчего вы решили, что компании именно разваливаются?
почему это не просто обычные любопытные пользователи, генерирующие задачи типа «задача1», «задача2» и т.д?
вы же не смотрите на тексты задач, я надеюсь?
почему это не могут быть команды, которые решили, что им больше нравится другой способ организации задач?
Superslon
06.06.2017 18:12Компании не разваливаются. скорее просто проект затухает. Много приходит стартапов и в таком случае это можно назвать разваливается.
Верно, могут быть и те, кто просто тестирует и те, кто решили поискать что-то еще. И на графиках видно — в начале есть резкий спад. Дальше процент людей, которые отваливаются по этим причинам одинаково распределен по всем выборкам.
Тут самое важное какое отличие от среднего по всем выборкам, а не значение по модулю.kostus1974
06.06.2017 18:35+4поймите правильно. вы пишете:
Первыми закрываются компании где ставится много задач
. между тем у вас просто нет и не может быть доказательств того, что компании закрываются или «затухают». вы не знаете, что делают компании, но делаете утверждения на базе всего лишь ваших предположений. так делают уфологи, и так делать нельзя ))
по приведённым графикам можно сказать что угодно. например, в начале проекта задач действительно много, но по мере завершения проекта количество задач уменьшается. остаются долгоиграющие (по разным причинам) задачи.
ps: на первый взгляд ваш продукт выглядит красиво. как вы соотносите себя с jira?Superslon
06.06.2017 18:42Понимаю вас. Название сделал поярче, может это и не совсем хорошо.
Мы сейчас достаточно далеки от jira. Переходов с нее на нас не так много. Решаются разные задачи.
Мы сейчас больше для веб-студий и коммуникаций вокруг общих задач в больших командах.
Замечаем переходы с Trello, BaseCamp Slack
FractalizeR
07.06.2017 11:56+3А не могу компании с большим количеством задач просто уходить от вас к конкурентам из-за того, например, что их не устраивает удобство работы YouGile на таком количестве? Вам кажется, что стартап умер, а они просто перешли на другой планировщик.
Superslon
07.06.2017 12:16-2Гипотеза справедливая и такие люди есть во всех выборках, но их не так много, как кажется на первый взгляд.
Стартап, начинающая компания, новый проект в большинстве случаев не так глубоко подходят к выбору инструмента. Они смотрят 2-3 варианта и начинают работать, по прошествии 3-4 месяцев у них больше шансов потерять энтузиазм к работе, чем сменить систему.
Предположение, что массово какую-то систему покидают из-за конкурентов вообще не правдиво. Есть очень внимательная аудитория (и ее много на Хабре), которая разбирается во всех деталях и выбирает грамотно, Остальные берут и работаю, руководствуясь мнениями вокруг, собственного анализа и выбора не происходит. Уходят как правило в никуда.
И примерно так со всеми софтверными продуктами, по моему опыту конечно.FractalizeR
07.06.2017 12:55+1Понимаю. Не пытались ли вы проверить эту гипотезу хотя бы статистически? Если ваша выборка строилась по результатам опроса 1000 пользователей, достаточно было бы взять 100 случайных компаний, которые по вашим расчетам перестали быть, и попробовать найти следы их жизнедеятельности (сайт в интернете, позвонить по старому контактному телефону). Во всяком случае, тогда можно было бы говорить о достоверности + оценить отток клиентов, если он был.
Superslon
07.06.2017 13:09-1Конечно, делали. Просто точных цифр нет и на мой взгляд это не может исказить эксперимент. Там нет сомнений, что кто-то может уходить к конкурентам, примерно 95% уходит по собственным причинам связанным с проектом.
Мы общаемся со всеми пользователями в поддержке напрямую, понимаем кто уходит и какова причина. Без этого сложно разрабатывать продукт.
В статье об этом не писал, хотя для понимания явно стоил сразу закрыть эти вопросы.FractalizeR
07.06.2017 13:28+1Просто точных цифр нет и на мой взгляд это не может исказить эксперимент.
Почему не может? Все зависит как раз от цифр.
Компании, которые генерируют много задач (более 20 в день на человека в первую неделю), через 100 дней будут существовать только с вероятностью 4%.
Что если компании, которые генерируют много задач уходят от вас с вероятностью 96%?
Я думаю, что при расчете статистики (в любой статье) нужно приводить методику расчета максимально подробно. Иначе ей трудно доверять.
fzn7
06.06.2017 17:40+9приходит в ярость, когда выполненные задачи не дают общего результата
— больше фантазий богу фантазий. Может они за 3 месяца успешно выполняют проект, покупают Jira и забывают про вашу систему как про страшный сон?Superslon
06.06.2017 18:18-1Может и так. но на эксперимент это не влияет. Те, кто решил что нужна Jira есть во всех выборках.
Рынок пользователей в своей массе не так искушен, что бы постоянно выбирать новые решения. Как правило (около 90%)пользователи отваливаются в никуда.
По нашему опыту всегда первое место занимает уход в никуда.
fillpackart
06.06.2017 18:21Заметил, что работаю продуктивнее, когда задачи задефайнены и разбиты на мелкие части. Это позволяет получать очень конкретный фидбэк от своей работы. Так что данная статистика видится мне довольно странной.
Superslon
06.06.2017 18:23+1Речь идет о командах. В группах оказывается взаимодействие важней, чем постановка и разбивка на подзадачи.
grumegargler
07.06.2017 05:19+1Это очень спорный вывод. Сам работаю в команде, частая коммуникация признак того, что что-то идет не так, или кто-то не выполнил качественно свою работу. На своей практике — безуспешность проекта часто связана с размазыванием полезной информации по чатам и отсутствию фокуса у разработчиков.
NightN
06.06.2017 18:24Поздравляю! Приятный интерфейс. В стиле Telegram.
Звуковые сообщения не планируются? В whatsapp удобно.
Настроек для self hosted в приложении не увидел. Не планируете для корпоративщиков приложение внедрять?
PS: feedback отписался в приложении.
Superslon
06.06.2017 18:31Сейчас соберем все хотелки по приложению и сделаем спринт по ним. Запрос понятен, спасибо.
Для корпоративщиков планируем и selfhosted — самый популярный запрос. Делать будем, пока срок назвать не могу.
OstaninKI
07.06.2017 06:41+2Знали бы Вы, как этого некоторые ждут! Особенно для снятия части нагрузки с Jira и «некорпоративного» Trello. А если еще и мобильное приложение под все это будет — просто сказка!
S_A
06.06.2017 18:50+2Интересные откровения. Много задач… общенье-печенье.
Проблема не в количестве, а в качестве задач, в которое их, задач, количество не переходит. Вот стартапы разваливаются, а waterfall-проекты с сотнями и тысячами задач вполне себе поддаются контролю с помощью диаграммы Гантта. Потому что их проектируют, в отличие от *gile-подходов (судя по графикам fragile:)).
«Instant Chat» — это прикольная фича, замена комментам к задаче фактически. Для небольших команд и небольших проектов, конечно лучше так, если компетенций в УП нет. Только вот фича != общение, увы и ох.
Насчет затягивания вовнутрь… тоже хорошо подмечено, ценно. Почему соцсеть затягивает? Потому что контент персонально релевантен (!). Равно как и чат — это персональный инструмент (в руках компании, а не как какой-нибудь портал по типу Б24 — инструмент компании в руках сотрудника).
Но всё равно пока визуализации прогресса не достаточно сейчас на мой взгляд, надо диаграммы, оценки рисков… Чтобы не обвинять сервис в том, что он причина всех причин, скажу что просто канбан не заточен под много задач.
Канбан штука такая, возвращаясь к началу — накидать задач можно, но лес-прогресс за ними не видно. Ходят туда-сюда эти карточки… и… никому их переделывать не хочется… Всю жизнь проектные менеджеры борются с рисками декомпозициями (1 рельс в 100 метров или 10 по 10, в каком случае общая ошибка будет ниже при ошибке на любой рельс в 10%?), а у вас противоположные почти что выводы.
sumanai
06.06.2017 21:22Интересно, а если сравнить не закрывшиеся проекты? Возможно, те 4% будут лучше, чем 50% унылых, ничем не примечательных проектов.
deemytch
06.06.2017 22:16Может быть скорее так: скорее закрываются те компании, в которых сотрудники пытаются излишне формализовать общение (и задокументировать все шаги), (и предохраниться от обвинений в несоответствии занимаемой должности), (ну и так далее)?
BoDRbI
07.06.2017 07:55+1Цена на selfhosted в 999$ в месяц прям очень много.
BoDRbI
08.06.2017 14:30У меня такое ощущение, что после моего комментария про 999$, цена была уменьшена до 900$ :) Но это всё равно больше чем стоит Jira.
grossws
09.06.2017 01:43JIRA стоит сильно по разному от количества пользователей. Там только первая доза
бесплатно^Wдешево. За 15 пользователей будет уже $900/year, 25 — $1800/y и т. п.BoDRbI
09.06.2017 07:46У нас команда из 10 человек. Нам стартовой версии за глаза.
grossws
09.06.2017 15:43Ну да, пока хватает можно радоваться. Боль обычно случается существенно позже, когда данных в JIRA уже много. Мы так болезненно слезаем с Crowd'а (там первая доза — 50 пользователей).
И да, я ошибся 15 пользователей есть только в cloud варианте. В self-hosted следующий term — 25 за $1800 и оно, соответственно, разовое, если не нужна поддержка.
igolkin
07.06.2017 17:04+2Методология исследования кое-где выдаёт желаемое за действительное. Здесь и в самом деле здесь причинно-следственные связи можно выстроить по другому. Ну а выглядит прикольно, конечно)
Tiendil
10.06.2017 15:33Может это не проекты «затухают», а ваш продукт не достаточно удобен для работы с большим количеством задач и сложными проектами?
roboter
Ем, а причину со следствием не перепутали? Проект умирает вот никто задачи и не ставит.
knstqq
Наоборот, если ставится по 20 задач в день на человека, то проект умрёт. Больше задач — больше вероятность умереть.
Superslon
Нет., мы старались проверять такие вещи, описывать подробно все детали выборок и проверок не стали.
Рассказали про самое яркое из того, что нашли.