Team Development Framework I

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

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

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

Кто мы и почему мы пишем этот гайд?
Мы – это Kite:Project, который был создан осенью 2016 года в Санкт-Петербурге для того, чтобы применить наработки кандидатской диссертации Дениса Сильверса в бизнесе, а именно в том, чтобы разработать и внедрять подход для эффективного управления бизнес-командами. Сейчас он называется Team Development Framework (TDF).

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

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

Нашими клиентами были IT-компании, телеком, ТЭК, фармакология, исследовательские команды, благотворительность и HoReCa.

Это не Базовое Руководство.
Для начинающих тимлидов лучше не выбирать между многими альтернативами – для этого еще нет опыта, – а желательно использовать то решение, которое тимлид прочитал в книге или которое посоветовал Agile-коуч.

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

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

У тимлида есть ментальная модель, когда он понимает, что если у сотрудника задача на неделю, то его нужно контролировать каждые два часа – иначе он ничего не сделает. Такая ментальная модель может вызвать сегодня возмущение: сотрудникам нужно доверять, давать проявлять инициативу и вмешиваться только если сотрудник сам просит помочь.

Давать сотруднику делать так, как он считает нужным или контролировать его – это две разные ментальные модели и нельзя сказать, что одна лучше или хуже. Это зависит от ситуации. Понимание того, что управленческие инструменты нужно выбирать, исходя из условий – это, в свою очередь, ментальная модель There is no Silver Bullet.
'M There is no Silver Bullet. Люди часто ожидают какого-нибудь простого маркетингового инструмента, который резко повысит продажи, или простого приема для менеджера, который тут же исправит если не все, то большинство проблем. Этот гайд вряд ли будет содержать что-то подобное. Успешный лидер отличается от неуспешного не какой-то одной техникой, а умелым применением десяти тысяч мелких техник, каждая из которых является простой, очевидной и при этом достаточно бесполезной, если ее не применять в системе с другими.
Основополагающие Принципы. Несмотря на то, что написано в Agile манифесте, по нашему мнению, основные принципы Agile – это Value Delivery, Focus и Continuous Improvements. Социократия очень точно выделяет свои основополагающие семь принципов. Среди них есть Эмпиризм – проверка гипотез в реальных условиях. Этот принцип не является основным для Agile, но Agile-практик его быстро поймет и с ним согласится. Есть и принцип Ответственности – это слепое пятно у Agile. В Agile если и используется понятие ответственности, то только в том смысле, что самоорганизованная команда несет ответственность за все.

Так как это явное слепое пятно, то ответственность мы будем рассматривать в этом гайде, но нашим основополагающим принципом это все же не будет. Мы не хотели бы повторять то, что уже хорошо сказали другие, поэтому сфокусировались на том, что другие теории покрывают плохо: Баланс, Системность, и Развитие.
Баланс – это одна из центральных ментальных моделей. Хорошие решения – это сбалансированные решения. Если вы будете контролировать сотрудников, то они не будут развиваться; если вы предоставите им полную свободу, то они тоже не будут развиваться. Мы не знаем полного списка условий, необходимых для развития, но мы знаем, что необходимым условием для развития является давление: конкурентов, бюджетов, сроков… Сбалансировано стоит строить работу так, чтобы у сотрудников была свобода, но при этом они достигали необходимого результата.
В своей работе с командами мы заметили три явные фазы: от следования простым правилам (Фаза I) и до разработки своих оригинальных подходов к решению проблем (Фаза III).

Фаза I во многом опирается на ментальную модель баланса. На этой фазе люди учатся простым вещам: писать эпики, приходить на встречи вовремя, работать спринтами. Люди радуются малым победам, защищают свою область ответственности, сопротивляются изменениям. Для первой фазы можно составить план внедрения, так как внедряются простые вещи. Баланс помогает понять, какие конкретно вещи необходимо внедрить.

Развитие. Если необходимо сделать так, чтобы люди начали вести себя по-другому, то страх и принуждение – это действенные инструменты. В некоторых случаях такие инструменты сработают быстро и надежно. Тем не менее, наши ценности таковы, что мы хотим, чтобы сотрудник менялся добровольно и осознанно. Именно такое изменение мы будем называть развитием.
Фаза I связана с рутинной работой. Команда часто сталкивается с уникальными проблемами. Уникальными потому, что ни в этом гайде, ни в других не описана та уникальная ситуация, в которой команда оказалась. Какие-то проблемы команда преодолевает легко просто за счет командной работы, а какие-то отрицает, обесценивает и игнорирует. Эффективность работы на этой фазе повышается медленно, но стабильно, и команда приближается к своему "стеклянному потолку". Именно на этой фазе происходит естественное развитие, когда люди может и сопротивляются изменениям, но не саботируют их.

Системность. Внедрение управленческого инструмента в одном месте может вызвать проблемы в другом. Ликвидация одного негативного фактора может сделать ситуацию еще хуже. Поэтому мы рассчитываем, что написанное в гайде не будет применяться строго по инструкции с надеждой на то, что оно будет работать безукоризненно. There is no Silver Bullet.
Фаза III. Второй фазой можно и ограничиться: далеко не всем командам нужны сверхдостижения. Зачастую стабильная работа дает такое конкурентное преимущество, что для победы над конкурентами другого и не надо. Тем не менее, те команды, которые хотят развиваться дальше, вынуждены пробивать "стеклянный потолок". Здесь команда доходит до того, что все десять тысяч мелочей она знает, но не понимает, как сложить из них результат.

Есть ли четвертая фаза после пробития этого стеклянного потолка – мы не знаем.

Вы – Взрослые Люди.
Мы не обладаем ультимативным опытом. Какие-то наши решения не очень хорошие – вы могли бы сделать лучше. В каких-то вопросам мы понимаем меньше – человек, который проработал в индустрии 20 лет, мог бы нас поправить. Мы за такие рекомендации будем благодарны и открыты к сотрудничеству.