За последний месяц я провел 71 обучающий скайп-звонок с самыми разными компаниями. Задачей было внедрить разрабатываемую нами систему управления проектами. Запрос у всех согласившихся на такой формат примерно один и тот же — “Как втянуть команду в систему ведения проектом и в сам проект?”. Или проще говоря: “Как сделать так, чтобы все работали?”.

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



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

Важный факт — участники компаний после часового скайпа работали в нашей системе в 8.5 раз активнее в сравнении со средним пользователем. И в 2.3 раза активнее в сравнении с теми, кто согласился на скайп, но позднее отменил мероприятие.

Для общего понимания приведу несколько компаний и их сфер деятельности, на основе общения с которыми составлен список рекомендаций:

• Видео-производство. 36 человек. Съемка рекламы и короткого метра.
• Завод по добычи золота. 25 человек. Планируют реорганизацию компании.
• Web-студия / SMM-агентство. 12 человек. Реализация клиентских проектов.
• Проектно-строительная организация. 15 человек. Разрабатывают проекты для реконструкции жилых зданий.
• Строители бань. 28 человек. Реализация объектов.
• Аудиторская компания. 20 человек. Дочка крупного банка, ведение проектов по аудиту подразделений.
• Национальный исследовательский университет. Отдел поддержки из 10 человек. Ведение тикетов и реализация проектов по модернизации сети.
• IT разработка в банковской отрасли. 110-135 человек. Пишут внутренний софт.
• Строительство, аренда и обслуживание торгово-развлекательных комплексов. Около 100 человек. Проекты по строительству объектов, ремонт, сбор задолженностей.

10 рекомендаций по затягиванию команды в проект

1. Придумать структуру доски, соответствующую логике бизнес-процессов

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

Как правило, в компании отсутствуют какие-либо прописанные процессы. Если их не было до появления системы управления, они и не появятся после. Хаос сохраняется. Перед внедрением стоит сесть и прописать в виде алгоритма всё, что хочется организовать. А затем придумать как это реализовать в системе досок с колонками.

Часто ситуация выглядит примерно так. “Молодой” PM (проектный менеджер) делает три колонки — “Новые”, “В работе”, “Готово” — и говорит команде: “Начинаем работать”. И… Команда не работает, по крайней мере в системе. Реальный процесс всегда обладает множеством деталей и даже самые простые процессы из трёх колонок должны иметь приоритеты и ответственных.

Вот ещё один характерный пример того, как не надо.

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

• Руководитель добавляет к проекту двух человек — себя и менеджера Лену.
• Делает три колонки — “Новые”, “В работе”, “Готово”.
• И говорит: “Я буду в “Новые” добавлять задачи и тебе надо их делать. И да, если сама видишь, что что-то нужно, то добавляй задачу и приступай. Самое главное — чтобы у нас в офисе было очень хорошо и всём хотелось тут постоянно находиться. Короче, надо сделать как дома…”.

Так не работает! Это не бизнес-процесс!

Через неделю Лена скажет что всё сделала, просто что-то ещё не успела отметить. Через две — появятся задачи, которые вообще прошли мимо. Через три недели всё благополучно вернётся к тому, что ген.дир. регулярно будет приходить к Лене и говорить что делать. Если компания растет, он постарается “делегировать” эту обязанность — и теперь руководитель HR будет ходить к Лене и говорить что делать.

Чтобы работало, нужна конкретика, точность и итеративность.

Например:

• Каждый понедельник до 11:00 в колонке “В работе” должно появится ровно пять задач. Лене нужно самой выбрать задачи с расставленными приоритетами из большого списка возможных работ. Если останется время, можно решать другие задачи.
• Все срочные задачи должны быть помечены “Срочно” теми, кто ставит задачу.
• Все задачи, лежащие в работе больше одной недели должны быть с дедлайном.
• Каждую пятницу в 17:00 проходит планерка между руководителем и офис-менеджером, где обсуждается два вопроса: “Что сделано?” и “Что планируется сделать?”. По результатам планёрки составляется и обсуждается список возможных работ и расставляются приоритеты.

Конечно, это только возможный пример, всё сильно зависит от конкретной ситуации даже при таком простом процессе, как работа над офисом. Как обычно, дьявол в деталях: «Какой специалист Лена? Сколько человек в офисе? Чем вообще занимаются в офисе? Что является критерием хорошего офиса? Сколько этажей? Какой климат за окном?» И так далее.

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

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



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

2. Не усложнять. Простые правила для всех сотрудников

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

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

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

Примеры простых работающих правил, со временем становящихся негласными:

• Сотрудник отвечает за то, чтобы колонка была пустой как можно быстрее.
• Сотрудник отвечает за переход всех задач с приоритетом “Важно!” в последний столбец к концу недели.
• Во всех задачах поставлен комментарий “Со всем разобрался” (например, на доске обучения).
• Сотрудник отвечает за максимальное кол-во взятых на себя тикетов из первой колонки.
• Сотрудник отвечает за заполнение колонки карточками с точно описанными проблемами на объекте. И к концу неделе отвечает за то, что других проблем нет.
• Сотрудник отвечает за прикрепление фото в день окончания работ.

Конечно, не по всем сотрудникам возможно так сделать. Отлично, если это получилось с 30% команды и со временем стало очевидными правилами.

И для контраста несколько примеров правил, которые не работают:

• Сотрудник отвечает за ведение доски.
• Сотрудник отвечает за своевременное выполнение задач
• Сотрудник отвечает за качественно написание текстов описания
• Сотрудник отвечает за продажи и фиксацию этого в системе

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

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

Даже если в команде больше 5 человек, то уже оправдано назначение человека, который по совместительству следит за договоренностями ведения проекта в системе, тратя на это не больше 30 минут в день. И главное, чтобы это был не руководитель и не проектный менеджер! Если руководитель будет надзирать за прикреплением приоритетов, дедлайнов, своевременной приборкой на доске и другими формальностями, он быстро теряет возможность обсуждать качество выполняемых работ. При этом если в небольшой веб-студии это, например, делает молодая бухгалтерша, то всё будет аккуратно и процесс обсуждения задач по существу не пострадает.

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

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

4. Ввести итеративное планирование

Тут ничего нового для знакомых со Scrum, Kanban и любым другим Agile-подходом. Согласно опросу от VersionOne подход с итеративным планированием используется в 90% команд. В том числе и в тех, которые не считают что работают с гибким подходом.



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

Главная польза с точки зрения втягивания команды — будет актуализирована картина общего дела у всех участников команды и всем будет ясно, что проект жив и задачи делать нужно. Про “жив” — это совсем не шутка. Одна из главных причин бездействия в большой команде — неизвестность: “А эта задача ещё актуальна или уже нет?”. Например, маркетинг услышал, что с продуктом есть проблемы. Внутри возникает резонное сомнение: “А стоит ли его добросовестно продвигать на рынок?”

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

Есть работающий прием — случайный модератор. Каждый раз через жеребьевку назначается случайный человек из команды, который задает вопросы “Что делалось?” и “Что запланировано?”. И дальше старается устроить обсуждение деталей по каждому из направлений деятельности команды. При постоянной смене ролей привыкнуть и сформировать формальное отношение невозможно. Все планерки будут разными и даже эмоциональными. Самое крутое, если модератор “тупит”, но, пользуясь своей временной должностью, задает вопросы. Тогда придется очень понятно рассказывать что и зачем ты собираешься делать.

5. Добавить всех в наблюдатели за другими

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

Доступ для чтения будет использоваться время от времени. Кем-то чаще, кем-то реже, но в компании начнут появляться такие разговоры: “Я видел вы там выпустили новый макет...” или “Я прочитал, там была исправлена проблема…”. Всякий раз, когда кто-то так сказал, можно считать, что сэкономлено несколько часов команды на разъяснение кто и что сделал.

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

6. Наблюдать за параметрами вовлеченности

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

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

Вот как выглядит активность по действиям нашей удаленной группы разработки за последние 2 недели:



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

Когда команда только начинает работать в проекте график выглядит вот так:



Больше всего новых задач. Через некоторое время картина должна измениться.

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



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

7. Проставить всем десктоп-версию с автозапуском

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

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

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

8. Задавать много вопросов

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

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

— «Лена, макет сделан плохо, без души, переделай.»
— «Лена, сколько можно делать такт? Переделывай всё!»
— «Лена, а может макет стоит переделать? Это вариант вроде не идет?»
— «Лена, как тебе результата? Стоит ли переделывать?»
— «Как тебе результат? Будем так сдавать клиенту?»
— «Не могу понять почему мне не нравится. Можно ли что-то улучшить?»
— «Если потратить ещё два часа, станет ли лучше?»

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

9. Публично в системе выделять результаты и хвалить

Есть хорошая поговорка: “Негатив — устно, позитив — письменно, негатив — лично, позитив — публично”.

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

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

10. Закладывать время на привыкание

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

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

Наберитесь терпения на пару недель!

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