Последние 10 лет для ведения проектов мы пользовались такими системами как YouTrack, Jira, Asana, Slack, SmartSheet, BaseCamp, Trello и даже белой доской, а также постоянно тестировали что-то новое. По нашему мнению, главная проблема всех систем управления в том, что люди в компании попросту забивают на её использование. А было бы здорово, если информация на все отделы распространялась из одной системы и вся команда сама активно постоянно ей пользовалась.
И настал момент, когда на выходных решили сделать свой инструмент для планирования и управления. Мы были уверены, что на эффективность команды из 30 человек действительно сильно влияет система ведения задач.
Для начала хотели реализовать 2 вещи:
Мы с головой ушли в это ответвление компании, разработка идёт уже 10 месяцев, а с нового года взяли ещё человека на мобильные версии. Сейчас открыто бета-тестирование, более 50 команд активно пользуется нашей системой. Под катом хотим поделиться тем, что у нас получилось и рассказать о том, какие кастомные подходы к управлению проектами оказались провальными.
Мы сделали простые Agile доски, где каждая задача может гибко модифицироваться под специфику отдела. На первый взгляд это чем-то напоминает Trello или YouTrack. Главное отличие — это стикеры, которые создаются и гибко настраиваются пользователем. Можно задавать карточкам задач любой дополнительный смысл и строить процессы в разных отделах.
До стикеров у нас была идея сделать что-то вроде тегов из Slack:
Казалось, что задача с тегами, являющаяся каналом общения — отличная идея, можно гибко задавать любые дополнительные параметры карточке. Например, проставлять тег #Minor маловажным задачам и т.п.
Проблемы начались, когда мы открыли доступ к доске разработки в отделе продаж (хотелось чтобы информация о развитии продукта приходила автоматически). При первом знакомстве 100% сотрудников из отдела продаж решили, что теги — это некоторые технические закладки, несущие смысл только для программистов. Конечно же мы рассказали, что по тегу можно узнать о приоритетности задачи или о том, в каком спринте (к какому сроку) планируется выпуск. Но никто из не-технарей не стал этим пользоваться. Визуально теги слишком одинаковы, чтобы легко ассоциироваться с разными смыслами. Чтобы в них разобраться, приходится постоянно задумываться и на всю команду система не распространяется.
В процессе решения этой проблемы мы пришли к стикерам, которые пользователь может сам конструировать.
Создавать стикеры сложнее чем теги, несколько сложнее догадаться до всех вариаций, которые можно сконструировать. Зато абсолютно всем понятно что они означают, когда применены на доске к задачам. Скажем, кто-то из команды один раз делает стикер приоритета с тремя текстовыми значениями Minor/Normal/Major и вся команда отлично с этим работает. Визуально стикер приоритета сильно отличается от стикера ответственного за задачу (причем степень отличия легко настроить) и в результате даже в бухгалтерии понятно, как работает отдел разработки.
В дальнейшем мы планируем открывать API к стикерам (по сути API к произвольной модификации задач) и разрабатывать шаблоны для специфических процессов. Например, можно будет сделать стикер, который из стандартной карточки делает карточку клиента и Agile Board становится CRM-системой. Или стикер, который выводит график по указанным событиям — будет легко получить Burn Rate или график закрытия тикетов в поддержке.
Простая идея, но почему-то нигде не реализованная до конца. На самом деле есть огромная разница между комментариями в карточке у Jira или YouTrack и чатом по задаче. Полноценный чат толкает людей общаться просто и непринужденно, не приходится строить сложные фразы как в комментариях, а решать любые мелкие вопросы в системе планирования становится привычном делом. В итоге получаются очень простые взаимодействия в команде, которые ещё и структурированы по задачам. С выходом мобильной версии просмотр задач будет похож на просмотр чатов в WhatsApp или Telegram.
В ходе реализации мы думали о двух проблемах:
Для решения первой проблемы мы внедрили возможность отключить все нотификации на указанный промежуток времени. И после тестирования в реальных условиях оказалось, что когда человеку приходит нотификация с автоматически указанной темой вопроса (название задачи) это его не напрягает, в отличие от входящего сообщения, например, в скайпе. Мелкий вопрос с заголовком оказывается практически всегда достаточно дельным. В итоге функция тихого режима практически не используется. Болтовня случается только в личных сообщениях.
Для предотвращения бардака в карточках разработали возможности ставить закладки (пины) на сообщение в шапке чата. При нажатии на них чат автоматически скроллируется на помеченное сообщение.
На деле оказалось, что задачи живут не так долго как каналы в Slack и не успевают превратиться в помойку. Открытая задача рано или поздно стремится быть закрытой в отличии от любого группового чата. По статистике, среднее кол-во сообщений в задаче — около 10 и только 3% задач содержат больше 100 сообщений. Функция “закладок” осталась востребованной, но не для порядка, а для запоминания и простоты дальнейшего поиска. Например, кидаешь в чат PDF-файл с технической документацией и ставишь закладку на него. Потом, просто нажав на эту закладку, легко сразу перейти к файлу.
Мы довольно долго думали, как обеспечить непрерывное самоинформирование всей команды о том, что происходит внутри компании. Потенциально можно сэкономить кучу времени на обсуждениях происходящего и работа становится существенно интересней, когда есть понимание общей картины. Целиком проблему не решили, но в какой-то степени в этом продвинулись.
Мы дали возможность сделать зеркало с любого столбика на доске и разместить его на доске другого проекта. Любой, у кого есть доступ, может сделать доску для наблюдения (подсматривания) за происходящим в остальных отделах.
Полностью это не решает проблемы информирования в компании — большинству всё равно лень регулярно просматривать изменения в зеркальных столбиках. Доску, на которую выведены все столбики с актуальными задачами со всех отделов, каждый просматривает примерно раз в неделю и со временем частота просмотров падает.
Активно используют функцию те, у кого на этом построен процесс. Например, зеркало столбика с багами из отдела поддержки размещено на досках отдела разработки и регулярно просматривается всеми разработчиками, особенно тестировщиком, который их пропустил.
Вовлечение всей команды в использование одной системы
Есть еще много трудностей с этим вопросом. Сейчас делаем упор на то, чтобы было круто для отделов разработки. Остальным отделам оказалось достаточно самых простых стикеров и красивого интерфейса, в вот разработка требует большого количества деталей.
Вовлечение участников команды в постоянное использование
Очень важно сделать так, чтобы команда со временем не забивала на использование системы управления проектам. Затягиванием через чаты, ленты с событиями в компании, дизайном. Сейчас мы выводим параметр, показывающий вовлеченного пользователя и смотрим, как он меняется с выпуском обновлений.
Коммуникации и мобильные версии
Второй по популярности запрос от наших пользователей — мобильное приложение. В течении месяца планируем его выпуск, упор делаем на общение.
Карта (граф) распространения информации внутри компании
Если предположить, что мы затянем более 50% всех коммуникаций в компании и будем обладать информацией о том, кто просматривает задачи, то можно построить реальную картину, как распределено внимание в проекте, на какие задачи действительно сделан упор, а какие остались в стороне.
Сейчас все в открытом тесте можно смотреть, пользоваться, предлагать идеи.
Указали на сайте тарифы — это был самый частый вопрос от регистрирующихся. Но деньги пока собирать не торопимся, оплатить ничего не удастся :)
И настал момент, когда на выходных решили сделать свой инструмент для планирования и управления. Мы были уверены, что на эффективность команды из 30 человек действительно сильно влияет система ведения задач.
Для начала хотели реализовать 2 вещи:
- Секундомеры на каждой задаче, потому что было ощущение, что это позволит точнее понимать как расходуется время в команде;
- Универсальность. Предполагали, что отдел разработки, поддержки и все остальные отделы могут работать в одной системе.
Мы с головой ушли в это ответвление компании, разработка идёт уже 10 месяцев, а с нового года взяли ещё человека на мобильные версии. Сейчас открыто бета-тестирование, более 50 команд активно пользуется нашей системой. Под катом хотим поделиться тем, что у нас получилось и рассказать о том, какие кастомные подходы к управлению проектами оказались провальными.
1. Концепция универсальных Agile досок
Мы сделали простые Agile доски, где каждая задача может гибко модифицироваться под специфику отдела. На первый взгляд это чем-то напоминает Trello или YouTrack. Главное отличие — это стикеры, которые создаются и гибко настраиваются пользователем. Можно задавать карточкам задач любой дополнительный смысл и строить процессы в разных отделах.
До стикеров у нас была идея сделать что-то вроде тегов из Slack:
Казалось, что задача с тегами, являющаяся каналом общения — отличная идея, можно гибко задавать любые дополнительные параметры карточке. Например, проставлять тег #Minor маловажным задачам и т.п.
Проблемы начались, когда мы открыли доступ к доске разработки в отделе продаж (хотелось чтобы информация о развитии продукта приходила автоматически). При первом знакомстве 100% сотрудников из отдела продаж решили, что теги — это некоторые технические закладки, несущие смысл только для программистов. Конечно же мы рассказали, что по тегу можно узнать о приоритетности задачи или о том, в каком спринте (к какому сроку) планируется выпуск. Но никто из не-технарей не стал этим пользоваться. Визуально теги слишком одинаковы, чтобы легко ассоциироваться с разными смыслами. Чтобы в них разобраться, приходится постоянно задумываться и на всю команду система не распространяется.
В процессе решения этой проблемы мы пришли к стикерам, которые пользователь может сам конструировать.
Создавать стикеры сложнее чем теги, несколько сложнее догадаться до всех вариаций, которые можно сконструировать. Зато абсолютно всем понятно что они означают, когда применены на доске к задачам. Скажем, кто-то из команды один раз делает стикер приоритета с тремя текстовыми значениями Minor/Normal/Major и вся команда отлично с этим работает. Визуально стикер приоритета сильно отличается от стикера ответственного за задачу (причем степень отличия легко настроить) и в результате даже в бухгалтерии понятно, как работает отдел разработки.
В дальнейшем мы планируем открывать API к стикерам (по сути API к произвольной модификации задач) и разрабатывать шаблоны для специфических процессов. Например, можно будет сделать стикер, который из стандартной карточки делает карточку клиента и Agile Board становится CRM-системой. Или стикер, который выводит график по указанным событиям — будет легко получить Burn Rate или график закрытия тикетов в поддержке.
2. Каждая задача — это чат
Простая идея, но почему-то нигде не реализованная до конца. На самом деле есть огромная разница между комментариями в карточке у Jira или YouTrack и чатом по задаче. Полноценный чат толкает людей общаться просто и непринужденно, не приходится строить сложные фразы как в комментариях, а решать любые мелкие вопросы в системе планирования становится привычном делом. В итоге получаются очень простые взаимодействия в команде, которые ещё и структурированы по задачам. С выходом мобильной версии просмотр задач будет похож на просмотр чатов в WhatsApp или Telegram.
В ходе реализации мы думали о двух проблемах:
- Не будет ли надоедать, когда отвлекают по всяким мелочам? Сильнее всего опасения высказывал отдел разработки, ибо перспектива увеличения количества мелких отвлечений вызывала агрессию.
- Не превратится ли карточка задачи в помойку с обсуждением заказа пиццы? У нас так постоянно происходит со Slack или Telegram — каналы засоряются и приходится периодически наводить порядок.
Для решения первой проблемы мы внедрили возможность отключить все нотификации на указанный промежуток времени. И после тестирования в реальных условиях оказалось, что когда человеку приходит нотификация с автоматически указанной темой вопроса (название задачи) это его не напрягает, в отличие от входящего сообщения, например, в скайпе. Мелкий вопрос с заголовком оказывается практически всегда достаточно дельным. В итоге функция тихого режима практически не используется. Болтовня случается только в личных сообщениях.
Для предотвращения бардака в карточках разработали возможности ставить закладки (пины) на сообщение в шапке чата. При нажатии на них чат автоматически скроллируется на помеченное сообщение.
На деле оказалось, что задачи живут не так долго как каналы в Slack и не успевают превратиться в помойку. Открытая задача рано или поздно стремится быть закрытой в отличии от любого группового чата. По статистике, среднее кол-во сообщений в задаче — около 10 и только 3% задач содержат больше 100 сообщений. Функция “закладок” осталась востребованной, но не для порядка, а для запоминания и простоты дальнейшего поиска. Например, кидаешь в чат PDF-файл с технической документацией и ставишь закладку на него. Потом, просто нажав на эту закладку, легко сразу перейти к файлу.
3. Зеркалирование столбиков в соседнюю доску
Мы довольно долго думали, как обеспечить непрерывное самоинформирование всей команды о том, что происходит внутри компании. Потенциально можно сэкономить кучу времени на обсуждениях происходящего и работа становится существенно интересней, когда есть понимание общей картины. Целиком проблему не решили, но в какой-то степени в этом продвинулись.
Мы дали возможность сделать зеркало с любого столбика на доске и разместить его на доске другого проекта. Любой, у кого есть доступ, может сделать доску для наблюдения (подсматривания) за происходящим в остальных отделах.
Полностью это не решает проблемы информирования в компании — большинству всё равно лень регулярно просматривать изменения в зеркальных столбиках. Доску, на которую выведены все столбики с актуальными задачами со всех отделов, каждый просматривает примерно раз в неделю и со временем частота просмотров падает.
Активно используют функцию те, у кого на этом построен процесс. Например, зеркало столбика с багами из отдела поддержки размещено на досках отдела разработки и регулярно просматривается всеми разработчиками, особенно тестировщиком, который их пропустил.
Куда думаем развивать проект:
Вовлечение всей команды в использование одной системы
Есть еще много трудностей с этим вопросом. Сейчас делаем упор на то, чтобы было круто для отделов разработки. Остальным отделам оказалось достаточно самых простых стикеров и красивого интерфейса, в вот разработка требует большого количества деталей.
Вовлечение участников команды в постоянное использование
Очень важно сделать так, чтобы команда со временем не забивала на использование системы управления проектам. Затягиванием через чаты, ленты с событиями в компании, дизайном. Сейчас мы выводим параметр, показывающий вовлеченного пользователя и смотрим, как он меняется с выпуском обновлений.
Коммуникации и мобильные версии
Второй по популярности запрос от наших пользователей — мобильное приложение. В течении месяца планируем его выпуск, упор делаем на общение.
Карта (граф) распространения информации внутри компании
Если предположить, что мы затянем более 50% всех коммуникаций в компании и будем обладать информацией о том, кто просматривает задачи, то можно построить реальную картину, как распределено внимание в проекте, на какие задачи действительно сделан упор, а какие остались в стороне.
Сейчас все в открытом тесте можно смотреть, пользоваться, предлагать идеи.
Указали на сайте тарифы — это был самый частый вопрос от регистрирующихся. Но деньги пока собирать не торопимся, оплатить ничего не удастся :)
