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

Возможно, это наша последняя статья на данном ресурсе.

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

1 уровень – человек воспринимает только «палку»
2 уровень – воспринимает крики, унижение или воодушевление и подъем.
3 уровень – логические структуры
4 уровень – видит факты
5 уровень – делает выводы опираясь на факты

Существует продолжение этой модели, но пока, нам достаточно.

К чему, собственно дисклеймер. С момента как мы зашли на платформу, мы успели написать всего 3 статьи:
Управление через коммуникацию https://habr.com/ru/articles/824776/
А в чем твой вклад? https://habr.com/ru/articles/825588/
Ой не смог, не успел https://habr.com/ru/articles/827956/
всего более 47.2т просмотров, и более 80 закладок.

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

В итоге что мы имеем. Напряженная для нас читательская среда. Активные – минусуют. Те, кому заходит, добавляют в закладки, но молчат и не проявляются. Поэтому предлагаем соц. эксперимент. Если вам статьи заходят (а такие есть, судя по 80+ добавлениям в закладки), проявиться и поставить плюс, чтобы мы могли дальше писать для вас.

Вот и проверим или опровергнем слухи о том, что на хабре одни хейтеры ;))

Вернемся к статье.

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

Проблематика

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

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

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

Так вот ответственно заявляю, – нифига мы не команда, пока мы её не построили. Кто этим должен заниматься, и как? Этим должен заниматься руководитель, он же, по совместительству, лидер команды. Как конкретно этим заниматься, это тема для отдельной статьи, сегодня расскажем некоторые инструменты которые можно использовать и внедрять в рабочие процессы и правила команды, чтобы начать повышать эффективность коммуникации, и очерчивать границы командной работы.

Микроитог – до момента пока руководитель не сделал из пула своих подчиненных команду, это рабочая группа, которую подобрали совместно с HR отделом для решения поставленных перед группой задач. Корректно ли называть их «командной»? ;))

Некоторые шаги для создания команды мы в этой статье и рассмотрим.

Поехали.

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

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

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

Сюда же

– Опоздания на встречи и нарушение тайминга.

– Отсутствие вовлеченности на созвонах. Задаешь вопрос конкретному специалисту, а в ответ «Ой, извините, я отвлекся. Повторите вопрос».

– Отсутсвие подготовки к встречам. «А что по задаче Х?» В ответ хлопающие и удивленные глаза, бегающие по доске, в попытках найти таск который туда не занесен.

–Неисполнение мелких поручений, например что-то посмотреть, или узнать у коллеги.

Это перетекает в неисполнение DoR и DoD, например в точке старта спринта, задача, которую можно брать в работу не соответствует definition of ready, потому что разраб что-то не подготовил. Не посмотрел код, не прикинул возможные проблемы. А не подготовил, потому что в текущем спринте на доске её не было. Про подготовку была устная договоренность, или договоренность в чате. Получается что есть условные правила DoR и DoD, но на практике, из-за отсутствия правил и ответственности по исполнению мелких поручений, они не помогают.

Итого – сотрудники садятся на шею. Делают только задачи на доске. Иногда задачи перекладывают на коллег, в итоге – потери (времени, денег, репутации, человеческого ресурса).

Откуда это все, и почему так происходит

Первое и самое главное.

1. Отсутствие командной цели, с которой согласны все участники.

Команду объединяет единство цели. Логично что проблематика будет из-за её отсутствия (подробнее в статье управление через коммуникацию).

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

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

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

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

2. Руководители сами не умеют. Банальный пример, если руководитель вырос из middle+ или рядового инженера, и стал Тимлидом, или С-1\ С уровнем, без специального образования или наставничества, идя по карьерной лестнице. Откуда он знает как вести, например, высокоэффективные встречи, если нет референсов, опыта и алгоритма. Это можно отнести и к другим бизнес-процессам, а не только встречам. К постановке задач, контролю качества, и внедрению правил и процессов.

3. Боятся внедрять. Вот вы прочитали в книжке\статье или на тренинге, что есть в других компаниях эффективный процесс, и было бы здорово повторить этот прекрасный опыт. Но блин, я же не первый кто об этом прочитал или услышал. Скорее всего умные люди уже пробовали, или в нашей конторе это не применимо, или любая другая отговорка. Одни словом – страшно. Страшно быть первым. А если не получится? Коллеги засмеют. А подчиненные будут в курилках обсуждать. Ну нафиг, оставим как есть.

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

Что, собственно за правила (Делать то что?) Из опыта можем предложить следующие инструменты, некоторые можно сразу начать внедрять:

Первый блок, это контролеры на встречах, планерках, совещаниях, страт. Сессиях и тд.

1. Назначение контролеров: Контролера времени, контролера поведения и контролера качества. В чем суть? Контроль это процесс, направленный на установление соответствия между образом результата и фактическим положением дел, и если контроль времени ещё хоть как-то внедрен Agile’ом, то про качество и поведение, говорить не приходится.

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

2. Работа над ошибками. Пример работы над ошибками это правило, если сотрудник что-то не успевают, делают ошибку в реализации задачи, что-то не получается. Они не приносят вам сухое –«я не сделал» или «я не сделал потому что…», вместе с этим они приносят «что я сделаю иначе, чтобы в следующий раз такое не повторилось», а также свои выводы, которые позволят на системном уровне в будущем избежать таких ошибок.

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

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

3. Три решения. Великолепный инструмент. Сотруднику нельзя прийти с вопросом к руководителю без трех вариантов решения проблемы. Сравните – Игорь Палыч, вот у нас ситуация Х, что нам делать? (подумайте за нас) или – Игорь Палыч, возникла ситуация Х, почесали репу, решить можно вот так, так и так.
   Первый вариант быстрее, но потом придется докручивать, второй и третий надежнее, но второй займет 2 недели, а в третьем ещё придется доплатить, но зато у нас вот такая фича будет внедрена, как поступим? (мы уже подумали, примите управленческое решение)
   Один мой знакомый Роман, руководитель аналитиков регулярно ругался что к нему приходят сотрудники с откровенно детскими вопросами, 80% вопросов просто гугляться. Вместо того чтобы найти ответ самому, сотрудники грузили своего руководителя и коллег, пока мы не внедрили это правило ;))

4. Своевременность. Самое близкое куда это можно прикрутить – не опаздывать на встречи. За опаздание – ужин для всех присутствующих коллег ;)) Регламентировать скорость ответа в чате, например, в течении 3 часов, или до конца дня, в зависимости от задачи.

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

Для этого есть инструменты, например ТОУТ, но их рассмотрим подробнее в другой статье.

5. Без прелюдий. Правило которое хорошо подходит для совещаний, отчетности по задачам итд. Говорить только по делу, отвечать конкретно на вопросы. Без рассказов на 15 минут, почему решили сделать именно так, если об этом не спрашивают. Проверено, экономит не просто минуты, а часы на переговорах.

6. Одна станция в эфире. Говорит только человек которому фасилитатор\руководитель\ведущий встречи дал слово, задал вопрос или предоставил время высказаться. Без перебиваний.

Как это все внедрять то?

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

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

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

Позитивные эффекты и плюсы после внедрения:

–Результаты команды будут расти. Это факт, если вы вводите, например правило без прелюдий, контролеров качества, времени и поведения, эффективность переговоров и точность становится выше. Вместо размусоливаний на 3 часа, встречу можно провести за 30 минут.

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

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

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

То есть я говорю команде: теперь у нас новое правило, мы пишем в таблицу все сложные ситуации с которыми сталкиваемся в бизнес-процессах, чтобы их обработать и в будущем не допускать. Всем понятно? Команда машет головой, что да.
Через месяц смотрим, 0 записей. Почему? –Так не было сложных ситуаций.
– Как это, а вот перенос задачи, а вот ошибка, а вот пятое десятое. А мы не договорились с командой что значит «сложная», оказалось для нас и для них это разные вещи.

Второе, разница уровней восприятия (разный внутренний возраст, см. введение в статью). Например программист на уровне 3 (логические структуры), а тимлид на уровне 4 (фактов). В конце спринта ТЛ видит факт – задача не сделана. Есть проблема. Нужно разработать бизнес-процесс, внедрить в команду, чтобы в будущем такое не повторялось. Программист смотрит на эту же ситуацию, и ему все равно на не сделанный такс, он начинает рассказывать последовательно почему не успеваем, что не так стоит эта задача итд

То есть сама коммуникация между инженером и например С левелом лежит в разных плоскостях. Как свести к параллельные линии в одну плоскость, понять друг-друга и сделать эффективную\результативную коммуникацию (а также про внутренний возраст), в следующей статье.

А пока, внедряйте и ставьте «+», чтобы мы писали ещё.