Pull to refresh

3 в 1: Обсуждения, задачи, документация

Reading time 4 min
Views 4.9K

В нашей команде работает более 30 человек. Мы разрабатываем масштабируемые решения для web. Живем в Томске, Санкт-Петербурге и в Москве. Для организации совместной работы над задачами мы использовали task-трекер. Во время проектов создавались ценные наработки и нужно было организовать работу со знаниями. Мы пробовали различные wiki-системы. Оказалось, что большая часть наших знаний создается при решении текущих задач. Мы сталкивались с проблемами:
  • Заносить и вести все задачи в task-трекере неудобно, и поэтому сотрудники все время переходят на общение через мессенджеры.
  • Много знаний оседает в e-mail и месенджерах. Перенос знаний из переписки в task-трекер и wiki отнимает много сил и времени.
  • Если при планировании проекта в wiki была записана вся концепция проекта, то с каждым днем различий между информацией в wiki и реальным положением дел становится все больше, и поддержка базы знаний становится неоправданно трудоемкой.
Решая эти проблемы, мы разработали собственную методологию и среду совместной работы. Так родился новый проект. В этой статье хотим рассказать о нем. Для начала посмотрим на то, как организована совместная работа в команде.

Знания не на складе

Модель информационных потоков лучше рассмотреть на упрощенных бизнес-процессах. Рассмотрим небольшой магазин бытовой техники. В магазине работает 11 человек, есть павильон и склад.
Изобразим бизнес-процесс обработки заказа, который включает в себя процедуры: оформление заказа, комплектацию и доставку клиенту. В процессе участвуют 3 человека, действия процесса фиксируются в специализированной информационной системе и происходят регулярно.
Бизнес-процесс в упрощенном виде
Бизнес-процесс в упрощенном виде

Другими задачами в организации занимаются еще 8 человек, они общаются устно, в e-mail, месенджерах и в других специализированных информационных системах.Схема коммуникаций в магазине бытовой техники
Схема коммуникаций в магазине бытовой техники

Окружающая среда: конкуренты, поставщики, госорганы, погода и т.д. постоянно изменяется. Менеджерам магазина нужно эти изменения выявить и оперативно принять решения. Такие решения обсуждаются и принимаются устно, в e-mail и месендежрах. Именно эти решения позволяют магазину выжить, оставаться рентабельным в долгосрочной перспективе и по сути создают стоимость бизнеса. Большинство ценных знаний находится в голове у руководителя. В этом нет ничего страшного до тех пор, пока потребность компании в знаниях невелика, и пока сотрудник остается в компании.
Какие знания могут иметь ценность? В нашем примере после решения проблемы с появлением плохого запаха из подвала на складе, можно записать информацию о том, куда надо звонить, что спросить и т.д.

Налог на воздух

Рассмотрим другую ситуацию: распределенная IT-команда разрабатывает и внедряет ПО для бухгалтерского учета. Выходит новый закон «О налоге на воздух». Соответственно, нужно внести изменения в программное обеспечение. Решение может происходить в следующем порядке:
1. Менеджер проекта пишет программисту письмо с описанием ситуации.
2. Программист заводит задачу в task-трекере и пишет архитектору: «Заявка необычная, нужно уточнить детали».
3. Архитектор пишет менеджеру список вопросов, которые нужно уточнить.
4. Менеджер присылает письмо с подробным описание того, что нужно.
5. Архитектор добавляет письмо в task-трекер.
6. Программист записывает результат выполнения задачи в task-трекер.
7. Программист вносит изменения архитектуры в корпоративное wiki.
Изобразим коммуникации:информационные потоки при решении задачи в IT-команде
информационные потоки при решении задачи в IT-команде
В данном примере, рассмотрен идеальный случай, когда вся информация передалась без потерь и искажений, а результат сразу был принят менеджером проекта.
На практике часто необходимы уточнения, и, скорее всего, все трое будут общаться по задаче в месенджере. Эти уточнения содержат в себе знания. В результате большая их часть потеряна для компании, оставаясь в личных архивах сотрудников.
Мы предлагаем подход к совместной работе и решению задач, основанный на контекстном общении. В этом случае основные взаимодействия внутри компании будут жить в новой среде, в которой ведутся обсуждения, здесь же ставятся задачи. Эта модель объединяет в себе e-mail, task и wiki-системы.Volna заменяет базу знаний, почту и систему задач
Volna заменяет базу знаний, почту и систему задач

После выполнения задач часть переписки удаляется, а остаётся только важное. Разделы размечается заголовками и таким образом создаются разделы документации.
Команда, работающая в такой системе, получает:
  • возможность ставить задачи быстрее, потому что нужно делать меньше описаний;
  • знания, добытые в процессе решения задачи, не теряются, а оформляются в документацию;
Стоит еще отметить психологический аспект. Нет жесткой привязки каждой реплики к задаче или цели. Людям проще начать общаться и задавать вопросы в среде, похожей на мессенджер.

Как мы ставим задачи

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

сделали небольшое текстовое описание и поставили дизайнеру задачу: «сделай набросок (задача саша)». После этого продолжили работать.постановка задачи в контексте
интерфейс постановки задачи в контексте

Саша: «Когда я взялся за задачу, ребята уже определились с другими картинками, и я начал продумывать их общее оформление. Я нарисовал и вставил иллюстрацию в статью. Коллеги в это время продолжали писать и затем поставили задачу на доработку. В этот раз мы управились за 2 итерации:)».
Работу с задачами мы ведем в TaskGadget:
TaskGadget для контекстных задач
TaskGadget для контекстных задач

Каждая задача из списка содержит ссылку на переход в контекст.
Сейчас решение базируется на платформе Google Wave (GW), к которой мы написали расширение и роботов. В дальнейшем, планируем миграцию всех наших инструментов в WiaB — платформу, разрабатываемую консорциумом Apache, и будущего наследника GW.
Upd: Много задают вопросов про судьбу и дату закрытия GW. Представители гугла говорят что мы ставим на мертвую лошадь. Но не смотря на это обещают что GW будет работать до тех пор пока не появятся альтернативные площадки готовые принять пользователей.

Обсуждения и работа с документацией

В процессе работы над упаковкой у нас осталась вот такая документация,
которую, в дальнейшем, можно перечитывать с заголовков, и постепенно погружаться в нужный контекст.
Мы называем это Zoom-чтением.
zoom-чтение
zoom-чтение

Этот концепт мы попытались реализовать на базе расширения для Google Chrome. И в дальнейшем будем развивать его на других платформах.

Необходимо добавить что эта статья появилась во многом благодаря людям которые верят в наш проект и помогают нам:
список редакторов статьи
список редакторов статьи

Предлагаем попробовать нашу методологию.
Tags:
Hubs:
+33
Comments 35
Comments Comments 35

Articles