Большое спасибо за ваши рекомендации @tobiaseigen относительно Discourse for Teams. Также это отличные новости, @david! Управление незавершенной работой теперь станет еще проще. Я бы хотел использовать этот пост, чтобы рассказать, какие именно функции стали решающими факторами для нашего перехода на Discourse.
Предыстория
Мы — команда разработчиков программного обеспечения, функциональных аналитиков и системных администраторов, занимающаяся созданием решений для управления бизнесом для колумбийского рынка, хотя весь мир уже включен в наш дорожный план ;). Мы разрабатываем индивидуальное программное обеспечение для наших клиентов и имеем собственные оригинальные продукты, но в настоящее время основным направлением нашей деятельности является предоставление услуг и расширений на базе Odoo ERP. Среди всех приложений, входящих в состав Odoo, мы специализируемся на модулях бухгалтерского учета, управления запасами и кадров. Как вы можете догадаться, мы сами активно используем Odoo, и с момента нашего основания в 2015 году приложение управления проектами было нашим лучшим союзником. Благодаря интерфейсу Канбан (в стиле Trello) оно позволяет нашей команде управлять потоком согласованных задач в каждом проекте внедрения. Однако внедрение проекта — это лишь начало отношений с компанией-клиентом, и именно в период обслуживания дела могут запутаться, если не обеспечены эффективное управление и открытая коммуникация. Но в Odoo есть приложение «Служба поддержки» (Helpdesk), которое можно использовать для управления коммуникацией на основе тикетов с пользователями вашего программного обеспечения через электронную почту. И, конечно же, мы также использовали его для предоставления наших услуг поддержки. Быстрые ответы на функциональные вопросы легко управлялись с помощью этого инструмента, но при получении запутанного отчета об ошибке необходимо было создавать отдельный документ для помощи в процессе разработки. В таких случаях мы использовали Gitlab и Github Issues, а также собственные файлы restructuredtext с контролем версий (анализируемые с помощью разработанных внутри компании инструментов на Python), чтобы установить формат отчетности об ошибках, не зависящий от поставщика. В итоге мы оказались в ситуации, когда задачи, которые нужно выполнить, приходилось искать как минимум в трех разных местах, используя разные интерфейсы и разные рабочие процессы. И внешняя, и внутренняя коммуникация, необходимая для выполнения наших ежедневных задач, оказалась под угрозой, что вынудило нас искать альтернативные процессы и инструменты, даже если это означало отказ от нашей «центричности Odoo». Discourse уже много лет известен как программное обеспечение для форумов, но о его функциях управления работой мы узнали лишь совсем недавно после проведения исследований. Нас побудили попробовать его три вещи: асинхронная коммуникация, унификация определения работы и контроль объема незавершенной работы (WIP).
Асинхронная коммуникация
Посты в Discourse похожи на электронную почту, но лучше. В мире WhatsApp, Slack, Messenger, Mattermost, Odoo Chat и многих других мы привыкли постоянно находиться в режиме «тревоги». Поскольку всё кажется срочным, вас вынуждают отвечать короткими, быстрыми и поверхностными сообщениями. Нет времени подумать, нет времени на доработку. Просто пиши и отправляй. Написание этого поста, например, заняло у меня гораздо больше времени, чем я ожидал, но я делаю это после выполнения других более срочных обязанностей, поэтому могу сосредоточиться на том, чтобы дать свой самый искренний и продуманный отзыв (это самое меньшее, что я могу сделать для такого замечательного инструмента, как Discourse). Написать пост — это как отправить электронное письмо, но читать его — совсем другая история. Гораздо лучшая. Посты централизованы и доступны всем членам команды (или авторизованным лицам). Их можно искать по содержанию или местоположению (то есть по темам и категориям), и к ним могут иметь доступ внешние пользователи или сотрудники, которые не участвовали в исходном разговоре, что отлично подходит для хранения исторической записи о том, как принимались решения и каков был их контекст. Краткая заметка: то, что python.org выбрала Discourse в качестве приложения для управления сообществом вместо списков рассылки или других решений на базе Python, показывает, что то, что у нас есть, действительно выдающееся с точки зрения пригодности, производительности и доступности.
Унификация определения работы
Это главная причина, по которой мы переходим на Discourse. Из предыдущего описания вы, возможно, представили себе очень красочную и запутанную рабочую обстановку. Я, конечно, был немного слишком драматичен, так как у нас действительно были документированные процессы и цифровые инструменты для управления нашей деятельностью с момента основания. Но со временем произошло следующее: нам не удалось иметь единое представление о работе внутри компании. Да, у нас были задачи для консультационной деятельности и тикеты для поддержки. Разработка велась на основе документированных требований в виде простого текста или известных задач, связанных с Git. Это была не проблема недостатка, а, наоборот, избытка. Источников информации было слишком много, и даже внутри одного общего приложения (например, Odoo) существовало несколько форматов (например, Задача, Тикет, Проблема). Конечно, мы могли бы выбрать любой из вышеупомянутых инструментов в качестве единственного источника правды, но ни один из них не предоставлял нам одного crucial элемента: интегрированной внешней обратной связи. Всего за один месяц использования Discourse мы наконец чувствуем, что устанавливаем связь с пользователями наших продуктов. Нет разделения между ними и нами, так как мы все используем один и тот же интерфейс. Однако нам не нужно отказываться от контроля над тем, как мы управляем нашей работой, поскольку некоторые области и возможности могут быть ограничены. Но самое главное, что благодаря Темам в Discourse те же самые артефакты, похожие на комментарии в блоге или тикеты в службе поддержки, которые мы используем для понимания потребностей наших клиентов, могут использоваться нами в закрытых внутренних категориях для представления запланированных задач, проблем, требующих внимания, или операционных действий. Для нас тема имеет множество синонимов, все они верны в зависимости от контекста: Проблема, Задача, Тикет, Действие, Контрольный список — называйте как хотите. Однородная форма работы, которая открыта, доступна и централизованно управляется. Я читал, что с Discourse for Teams вы планируете выпустить отдельный продукт, отличный от форума Discourse, или, другими словами, что Discourse (Форум) и Discourse for Teams предназначены для развертывания как два разных экземпляра. Я бы рекомендовал вам внимательно обдумать это, потому что такой дизайн неизбежно разорвет текущую интеграцию между внешними и внутренними сторонами организации.
Контроль WIP (Объема незавершенной работы)
Наконец, одним из лучших сюрпризов, которые мы испытали при использовании Discourse, стала возможность наконец установить контроль над объемом незавершенной работы в организации. Поскольку работа, которую нужно выполнить, имеет одинаковую «форму», легко определить политики, ограничивающие количество работы, которое организация должна иметь в любой момент времени. С помощью плагина Assign задачи назначаются единственному ответственному лицу, которое должно искать помощь по мере необходимости (что обозначается символом ‘@’), а затем, используя единый интерфейс (доступный по адресу ‘/g/staff/assigned/everyone’), можно контролировать количество текущих действий (т.е. WIP) во всей системе. Прямо сейчас, например, мы работаем с лимитом WIP в 5 задач/тем/проблем на человека. Поскольку нас 14, это означает, что наша максимальная мощность как команды должна составлять 70. Это очень важно для нас, так как это помогает обеспечить стабильность в одной из самых сложных задач в жизни: оценке. Согласно закону Литтла (Little's law - Wikipedia), среднее долгосрочное количество элементов в очереди равно его средней скорости поступления или пропускной способности, умноженной на среднее время ожидания, которое каждый из этих элементов проводит в системе. Таким образом, при ограничении WIP в 70 элементов, если мы получаем 140 тикетов в неделю, они в среднем будут завершены за 0,5 недели, а если мы получим 210 тикетов, то в среднем это займет 0,33 недели. Это, конечно, предполагает, что система находится в стабильном состоянии и очередь не растет бесконечно, поэтому правильная калибровка WIP должна проводиться итеративно. У нас все еще (и всегда будут) меньшие объемы типов работы, которые не могут быть представлены в Discourse, такие как управление нашими электронными письмами или конвейером CRM, но поскольку большинство наших задач теперь имеет единую форму в виде Тем Discourse, внедрение практик Канбан и Agile, таких как ограничение WIP, станет гораздо проще. Вот почему я бы посоветовал, если Discourse for Teams планируется как отдельный экземпляр форума Discourse, было бы жаль не иметь федеративного способа поддерживать централизованный и составной вид WIP в обеих системах.
Надеюсь, этот пост поможет улучшить Discourse как платформу для коммуникации и построения сообщества. Еще раз большое спасибо за это и желаю вам всего наилучшего!
открывает поиск с флажком «Искать сообщения от @tobiaseigen». Было бы логичнее видеть «Искать назначенные @tobiaseigen».
