Когда хочешь рассказать коллегам о своей работе, сталкиваешься с вопросом: что достойно рассказа, что заслуживает внимания соседей и что им интересно?

Рассказывать коллегам надо три вещи:

1. О том, что меняет что-то в компании и в жизни коллег.
2. О том, чем гордитесь.
3. О том, что может развлечь.

Первое и самое важное — изменения.

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

Второе — то, чем гордитесь.

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

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

Хоть родители и учили обратному, хвастаться результатами своей работы — хорошо и полезно.

Третье — байки.

Так или иначе байки про рабочую жизнь рассказывают все: чтобы разбавить рутинные будни, поделиться эмоцией, пережить ее вместе и стать ближе друг к другу. Передавать коллегам нужно не только данные, но и чувства, иначе вся работа будет такой, как на картине Васи Ложкина «Не время улыбаться».

Если рассказываете байки из собственной жизни клиентов или пользователей, убирайте персональные данные. Если это байки из рабочей жизни, не обижайте коллег и относитесь к ним с уважением.

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

Но что такое это самое «Слишком быстро растем»? Где тот предел скорости, когда рост наносит увечья и снижает общую производительность?

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

Новые сотрудники получают от опытных коллег знания об инфраструктуре компании и опыт решения задач в этой среде. Первое можно записать и передать с минимальными искажениями и максимальной скоростью. Вторые — неявные знания — формализуются плохо, и передавать их гораздо тяжелее. Ошибки при их передаче быстро накапливаются: за два-три «поколения» можно получить сотрудников, будто бы работающих в разных компаниях. В итоге под одной крышей собирается много людей, которые не умеют работать друг с другом, и времени на то, чтобы научиться, у них нет. И компания схлопывается.

У каждой компании своя собственная максимальная скорость. Если в компании плохо поставлено обучение сотрудников и адаптация новичков, то для такой компании и рост в 5% сотрудников за год— слишком быстро. Есть несколько способов повысить эту самую скорость:

— Записывать и публиковать больше знаний об устройстве компании. Это уменьшает искажения и снимает нагрузку с других каналов обучения. Пользу приносит даже самое банальное и очевидное: где какой сотрудник в офисе сидит и чем занимается, как к коллегам обращаться и как с ними знакомиться, как собрать встречу, как рассказать о проекте и как отпраздновать день рождения в рабочем кругу.

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

— Приставлять к новичку двоих наставников. Во-первых, это даст более широкий взгляд на задачи, во-вторых, позволит выявить разные точки зрения на организацию работы в коллективе.

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

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

Проект — конечная деятельность с целью, задачами и понятным результатом. Работа над ним строится проактивно: команда формирует план работ и определяет, что будет делать для достижения цели.

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

Это отличие и определяет подход к использованию инструмента: трекер для процесса — это конвейер по обработке бесконечного потока типовых задач.

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

Чтобы планировать работу, надо понимать собственную пропускную способность, отслеживать текущую нагрузку и прогнозировать ее рост (например, на основании планов запуска новых продуктов, или сезонности). В этом помогают метрики: время первой реакции на запрос и среднее время решения запроса.

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

Запросы типизируют. Типы запросов выделяются чаще всего либо по тому, о чем часто спрашивают (заказ книг в библиотеку или софта для сотрудников), либо по тому, что за специалисты решают такие задачи («Все, что про канцелярку и кофе-сахар — к секретарям»).

Типизировать запросы можно вручную — с помощью сотрудника-диспетчера, который передает его разным исполнителям. Работу диспетчера облегчат заявители, которые сами выбирают тему (тип) запроса: справки, заказ канцелярки, заказ офисного оборудования и так далее. Тогда диспетчер разбирается только с нетиповыми запросами.

Тип запроса можно определять автоматически, если создавать отдельные точки входа для разных запросов. Если трекер умеет превращать письма в запросы, можно для каждого типа заявок настроить свои адреса электронной почты и просить сотрудников писать на них: «Напишите письмо на office-supplies@companyname.ru, и оно станет заявкой на покупку всякого офисного барахла». Можно предлагать сотрудникам заполнять разные формы на интранет-портале, которые будут добавлять в трекер заявки соответствующего типа.

Сколько бы запросов ни было, их типизировать полезно в любом случае. Если запросов много, разные запросы попадут к разным сотрудникам — так возникает специализация. Если запросов мало, и ими занимается один человек, все однотипные запросы можно выполнить в один присест: сесть после обеда и всем, запросившим справку, её подготовить.

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

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

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

Также у разных задач — разное критичное время выполнения. Одни запросы можно спокойно выполнять два дня, на другие надо уметь реагировать в течение пятнадцати минут. И если в «конвейере» накапливаются такие пятнадцатиминутные, то надо перераспределять силы в их пользу — чтобы оставаться в рамках ожидаемых сроков обслуживания.

Если в компании уже есть трекер задач, попробуйте использовать его для организации процессов: один инструмент проще в поддержке. Также есть специализированные продукты, которые интегрируются с CRM-системами (как Zendesk), или автоматически приоритизуют запросы в зависимости от их типа и срочности (как Jira Service Desk).

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

Трекер эффективен тогда, когда он единственный источник информации о задачах, и когда ответственность за задачи четко разделена.

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

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

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

Трекер публичен. У команды должен быть доступ ко всем задачам проекта. Если в нем есть «секретные» задачи, то нельзя составить сколь-либо достоверный план работ, нельзя оценить сроки.

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

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

Нет тикета — нет задачи. Тикет — это записанная в трекер задача, багрепорт, запрос на изменение, жалоба, просьба. Все то, что позволяет реализовать проект или сделать его лучше.

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

Есть соблазн не записывать в трекер всякую мелочь (например, исправление орфографических ошибок в интерфейсе или в тексте на сайте), а работать только с крупными задачами. Но тогда будет непонятно, на что уходит заметная часть рабочего времени, и не будет пользы от параллельной работы над задачами: пока один фиксирует проблемы, второй может спокойно брать записанное и исправлять.

Одна задача — один тикет. Не стоит записывать в один тикет много работ сразу: разные задачи в проекте могут находиться в разных состояниях, у задач разные сроки, разный состав участников обсуждения и разные ответственные. Если большую задачу (решение которой займет больше одного дня работы) разбить на подзадачи, с ними можно будет работать параллельно.

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

Одна задача — один исполнитель. Как не могут несколько человек управлять одним автомобилем, так не могут несколько человек выполнять одну задачу. Автомобиль с несколькими водителями обязательно врежется, а за задачу с несколькими исполнителями в итоге не будет отвечать никто.

Желание сделать исполнителями у одной задачи несколько человек — это отличный индикатор того, что задачу можно и нужно разбивать на несколько.

Читайте также о том, от чего зависит выбор багтрекера: «Интранет для компаний разного калибра»

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

Опыт софтверных компаний можно применить практически в любой организации вне зависимости от того, в какой отрасли она работает.

Внедрение трекера в повседневную работу ведет к нескольким эффектам.

Процесс нормализуется. Внедрение трекера как правило начинается с осознания процесса, его описания и перепроектирования. После фиксируется последовательность шагов по обработке задач. Эти шаги могут быть внедрены организационно — например, в виде инструкции для сотрудников, — а могут быть внедрены технически: через поддержку в трекере определенного жизненного цикла задач.

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

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

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

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

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

Единственный нефальсифицируемый показатель — количество выпущенного продукта, или оказанных услуг.

Диагностика становится проще. Когда перед глазами есть описанный и измеримый процесс, быстрее можно понять, где в процессе проблемы и узкие места.

На каком этапе скапливается больше всего задач? Какое время первой содержательной реакции на сообщение об ошибке? Какие задачи в работе дольше других? Что между ними общего?

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

Работа будет документироваться. Задачу, записанную в трекере, можно прокомментировать, задать вопросы, предложить варианты решения. Трекер фиксирует переход задачи между исполнителями, смену статуса и сроков, собирает историю изменения задачи и ее обсуждения.

Почему принято именно такое решение? Кто принял? Какие в ходе решения задачи были выявлены проблемы?

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

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

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

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

Читайте также: «Пять принципов работы с таск-трекером».

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

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

Велорама предлагает выбирать велосипед по двум параметрам: области применения («для пересеченной местности», «для туризма») и цене.

Есть подходы, которые можно использовать в интранете, и которые позволяют ускорить принятие решений.

1. Показывать только нужную информацию.

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

Хотите в отпуск? Хорошо, накопилось ли нужное количество дней? Нет ли пересечений в графике с коллегами? Отлично, подтверждаю.

Другие решения принимаются на основании каких-то метрик.

Нужно дать премию? Хорошо, на основании каких критериев мы договорились премировать? Ошиблись в сроках проекта всего на 30%? Отлично, это ж в два раза меньше обычного.

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

2. Собирать однотипные решения вместе.

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

10 сотрудников хотят пойти на конференцию. Да. Нет. Да. Да. Да. Нет. Да. Да. Нет. Да.

3. Сводить решение к закрытому вопросу.

На закрытый вопрос можно односложно ответить «Да» или «Нет». Многие решения можно свести к такому вопросу.

Цели проекта достигнуты? Да.

Встреча в 10 утра? Нет.

Выбрали вот такой телевизор в опенспейс. Берем? Да.

Такие решения принимаются быстро. Выбор («Самсунг или Панасоник?») усложняет всё.

4. Предлагать готовые ответы для открытых вопросов.

Иногда решение это не только согласие или отклонение, но и ввод дополнительной информации.

«В каком размере премия?».

В таком случае помогает «ответ по умолчанию», автоматически предложенный на основании имеющихся данных и ранее достигнутых договоренностей.

«Проект шел три месяца» + «Все заказчики подтвердили результаты проекта» = 50% оклада. Подтвердить.

5. Отказываться от принятия некоторых решений вовсе.

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

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

Первая часть — профили сотрудников

Мы проводим на работе 8—10 часов ежедневно. Работе посвящено времени больше, чем уходит на сон, развлечения, семью. И неудивительно, что хочется знать людей, с которыми работаешь. Профили сотрудников решают несколько задач сразу.

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

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

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

В-четвертых, это сбор различных действий сотрудника. В конце 2011 года Facebook показал новый формат представления профиля человека — таймлайн. И начал собирать действия пользователя: в Facebook’е и за его окрестностями.

Эта модель отлично походит для рабочего информационного потока: в подобном формате можно собрать то, что коллега сделал по работе.

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

В-пятых, профили коллег — это поиск экспертов. В профилях сети LinkedIn есть навыки и экспертиза. Их пользователь может указать сам, их могут добавить (или подтвердить добавленные ранее) его знакомые.

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

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

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

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

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

Четвертая — это компания в 4 тысячи человек. Она работает в нескольких офисах, скорее всего — и в нескольких странах. Сотрудники разговаривают на разных языках, действуют в рамках разного законодательства, разных культурных норм и коммуникационных традиций. Про такую компанию можно сказать, что там вообще никто ничего не знает :-)

Если брать самую маленькую компанию — рабочую группу в четыре человека, то для представления участников этой группы подходит та же внутренняя вики. Поддерживать в актуальном состоянии несколько страниц с контактной информацией, фотографией и ссылками на другие сервисы — вполне посильная задача. Можно собрать людей, которые занимаются проектом, с помощью Facebook’а. Фотография есть, интересы есть, агрегация активностей (пусть и нерабочих) есть. Завести приватную группу и выложить в ней ссылки на те или иные — вопрос нескольких минут. К тому же сервис знакомый и привычный.

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

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

В компании в четыре тысячи таких специфик становится столько, что без собственной разработки уже практически не обойтись.

Вторая часть — трекер, место, где живут задачи

Трекер нужен любой компании. Если компания большая, ее сотрудники выполняют очень много задач. Если компания маленькая, у каждого ее сотрудника есть собственный «туду-лист», рабочий или личный, в бумажном блокноте или в виде электронного списка.

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

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

В-третьих, трекер задач помогает обсудить отдельные вопросы в рамках проекта. Сформулированная и записанная задача не всегда делается точно так, как была сформулирована и записана: выявляются проблемы и ранее неизвестные аспекты, влияющие на решение. И вокруг такой задачи в трекере можно собрать группу людей, которая что-то про проблему знает и готова помочь ее эффективно решить. Задача обрастает комментариями, обсуждением решения, сопутствующими планами и многим другим.

Правило «Чем меньше компания, тем более простые и общие инструменты ей подходят», работает и с трекером. В группе из четырех участников спокойно можно обходиться простыми и легкими трекерами, где у задачи бывает два состояния: нерешенная и решенная. В этой весовой категории у нас выступают, например, Trac, трекер из GitHub и Basecamp.

В компании в сорок человек процессы еще более-менее простые, но уже есть отдельные команды и отдельные проекты. Работа становится плохо обозримой. Еще как-то можно справляться с Basecamp’ом, но могут подойти уже специализированные трекеры: Asana, Mantis, Redmine, YouTrack.

При четырехстах сотрудниках в компании появляются сложные процессы, и важно эти процессы трекером поддержать. Поэтому на одну сцену с такими легкими трекерами, как YouTrack, выходит, пожалуй, самое популярное и универсальное решение для трекинга задач — Atlassian Jira.

На масштабе в четыре тысячи человек такие универсальные решения, как Jira, перестают справляться с возросшими требованиями по безопасности, по поддержке разных процессов, а также по вместимости хранилища и скорости ответа. И большая компания позволяет командам ставить мелкие трекеры под свои локальные нужды, или разделяет условную Jir’у на несколько отдельных. В обоих случаях получает фрагментированное поле задач, невалидную статистику, сложности с переключением сотрудников между командами, вкусовщину и сепаратизм.

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

Третья часть — общее место

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

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

В качестве примера могут выступить сайты опенсорс-проектов: Redmine, Ubuntu, Open Transport Tycoon Deluxe и многие другие.

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

Пока команда маленькая и помещается в комнату, группа может использовать в качестве общего места само пространство, где работает: отмечать текущее состояние проекта на маркерной доске, развешивать на стенах распечатки интерфейсов и упоминания в блогах своего продукта. И на этом масштабе еще неплохо работают электронные документы типа тех, что есть в Google Docs.

На масштабе в сорок человек Google Docs уже не спасают. Поскольку дают делиться документами, но не позволяют строить из них общую структуру. И в большой группе отсутствие общей структуры материалов смертельно.

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

Четвертый компонент — пуш-канал

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

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

Чем более асинхронная, распределенная и самостоятельная команда, тем важнее хороший пуш-канал. Если его нет, то у команда не может оперативно координировать работу.

На четырех человеках пуш-каналом выступает даже самый простой общий чат. Skype, Campfire или чат в Facebook’е сыграют такую роль. Небольшой размер команды позволяет «пушить» новости и обсуждать вопросы в рамках общей встречи. Неплохо с этим справляются блог или лента новостей в Basecamp’е, если настроить отправку уведомлений о новых сообщениях в электронную почту.

На сорока сотрудниках общий чат уже неподъемен и неуправляем, и его место занимают почтовые рассылки: одна или несколько. И сорок человек еще можно собрать на встречу и сообщить им какую-то новость. Но принимать такой группой уже не получится.

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

Разумеется, на этих четырех системах интранет не заканчивается. Но это самые важные компоненты эффективной коммуникационной площадки.

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

Текст написан по мотивам выступления «Интранет vs. Здравый смысл» на конференции Codefest в марте 2012 года. К сожалению, сейчас страница доклада недоступна, но есть отдельно слайды и видеозапись.

Во-первых, на письмо отвечают с помощью Reply To All.

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

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

Во-вторых, авторы писем явно указывают добавляемых в дискуссию.

Примерно в формате «+kolomeetz@» или «+Костя Коломеец». И «-kolomeetz@», соответственно, когда кто-то покидает тред. Или «-все», если ответ направлен лично автору изначального письма (исключительный reply вместо привычного reply to all).

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

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

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

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

Например, письмо может начинаться такими строками: «+kolomeetz@ — Костя отвечает за наши внутренние сервисы» или «+tools@ — вопросы про работу внутренних сервисов эффективнее задавать не в личную почту, а в рассылку tools@, тогда мы быстрее вам ответим».

Это дает возможность рассказывать о «точках входа», о зонах ответственности коллег, знакомить их друг с другом. Ну и это просто вежливо :-)

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

— The social Intranet in Russia

Тоби Уорд, приехавший в Москву для участия в конференции Enterprise 2.0, первый день которой прошел вчера, пишет о первых впечатлениях от российской интранетов и вторит мне: мол, внутрикорпоративные сервисы заметно отстают от интернетов. Но отмечает и другое, не менее важное: текущие корпоративные показатели (доля компаний с запретом соцсетей, доля компаний, знакомых с социальными интранетами) повторяют зарубежные но — трехлетней давности.

— Google’s KeyChain API makes Android more attractive for the enterprise

Если за гонкой вооружений между iOS и Android на потребительском рынке индустрия следит с замиранием сердца, то битвы корпоративные проходят практически незамеченными. Тем временем практически беспроблемный iOS наконец-то обретает конкурента: новая версия операционной системы Android 4.0 (коллеги подсказывают, что до 4.0.3 глючит безбожно) позволяет наладить нормальную жизнь с сертификатами, обеспечивающими доступ в корпоративную сеть.

В остальном разница между ними незначительна.

— Россияне на майские праздники будут отдыхать четыре дня

Не успела закончиться эта странная неделя с двумя понедельниками и двумя пятницами, как премьер заявил, что первая майская декада будет еще более судорожной и рваной. Мотивируется это решение желанием предоставить возможность больше дней посвятить [сельхоз] участку, огороду. Ура, товарищи, мы теперь не только сырьевой придаток, но еще и снова страна аграрная: сельское хозяйство побеждает рабочий ритм и здравый смысл!

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

Ну и старый диагноз все еще остается в силе: интранеты от интернетов все еще отстают лет на 8—10.

— Битрикс открыл свой блог про социальный интранет

Вслед за анонсированием скорого запуска «Битрикс24» — арендуемого интранет-решения с кучей социальных функций, Битрикс начал активно обсуждать тему социального интранета: сначала несколькими публикациями в корпоративном блоге, а теперь и отдельным потоком материалов на эту тему.

— Google+ позволил работать над документами в видеочате

Google добавил в Google Docs видео-чат: можно редактировать табличку или документ, обсуждать, смотреть друг другу в честные глаза или деланно хвататься за голову в ситуации, когда коллеги пишут совсем уж глупости. Видеоконференции доступны только для пользователей социальной сети Google+.

Посмотрим, что ответит на это Skype: видеоконференция с более чем 2 участниками доступна только пользователем premium-аккаунтов.

— Дела в Яндекс.Почте

Яндекс подключил к Яндекс.Почте списки задач — те же, что в Календаре. Задачи также стали доступны и в мобильной Яндекс.Почте. Живут задачи на серверах Яндекса, синхронизируются между мобильными устройствами и веб-интерфейсом почты, список задач можно выслать знакомому.