Как мозг управляет проектами
Будучи аналитиком, начать эту статью я хотела бы с двух показателей: 2% и 20%. Поскольку тема статьи непосредственно связана с мозгом, эти показатели характеризуют именно этот удивительный орган. Дело в том, что человеческий мозг составляет 2% массы нашего тела, а потребляет при этом 20% всей энергии организма. Не совсем оптимально, правда? Природа решила так же.
Эволюционно возник механизм когнитивных искажений: мозг, оптимизируя собственную работу, принимает решения быстро. Нет времени думать, нападет на меня этот тигр или нет. Если бы мои предки об этом задумывались, меня бы сейчас, наверное, не существовало.
В этой статье мы попытаемся частично снять с себя груз ответственности и вины. Груз вины за сорванные дедлайны, нервные созвоны в два часа ночи и технический долг.
Виноваты не всегда только мы. В комнате есть еще один враг – наш собственный мозг, который просто решил оптимизировать свою работу. Мы разоблачим этого внутреннего саботажника и посмотрим, как эволюционные механизмы незримо, но на полставки управляют проектами. А также рассмотрим инструменты, которые мы внедрили в своих командах, чтобы наконец-то начать слышать друг друга.
Начнем с базы о когнитивных искажениях. Хотя нет: базовых знаний не будет. В своей работе я выделила девять когнитивных искажений, которые так или иначе повлияли на мои взаимоотношения с разработчиками и тестировщиками. На примере своего личного опыта я расскажу, как мы выявили эти когнитивные искажения и как с ними работали. А в конце будет гайд по работе с когнитивными искажениями и инструменты, которые можно внедрить в своих командах.
Эффект прожектора и эффект группового мышления
Первая ситуация связана с боязнью показать неидеальное ТЗ или код, задать неверный или глупый вопрос или, что хуже всего, неправильно ответить на заданный вопрос. Лично я сталкиваюсь с этим практически каждый день.
Сюда же относятся ситуации, когда человек не решается высказаться против принятого командой решения. В этом случае мы оказываемся в ловушке двух когнитивных искажений: эффекта прожектора и эффекта группового мышления.
Эффект прожектора
Начнем с эффекта прожектора. Как он проявляется в команде?
Мы долго пишем ТЗ или код, потому что все должно быть идеально. Нам кажется, что за нами наблюдают, на нас светит прожектор, обращая внимание всех коллег на то, как мы работаем. Как следствие, мы не успеваем в релиз и растет недовольство: аналитик слишком долго писал ТЗ, разработчик слишком медленно разрабатывал.
Или мы не задали важный вопрос. Реализация задачи не соответствует ожиданиям: все вроде бы работает, но не так, как должно было. Как следствие, снова растет недовольство в команде, потому что опять все переделывать.
Как это можно исправить?
Можно использовать памятки или стикеры на рабочем месте с общей мыслью о том, что коллеги тоже погружены в свои задачи и их внимание не направлено на нас 24/7.
Нужно сосредоточиться на решении проблемы, а не на том, как это выглядит со стороны.
Задача со звездочкой – принять ошибки и позволить себе их совершать. Но это не значит, что нужно бежать и на радостях ронять прод.
Эффект группового мышления
Перейдем к эффекту группового мышления. Как он проявляется в команде?
На синке по обсуждению будущих задач кто-то из коллег постеснялся сказать, что в выбранном решении есть подводные камни. Побоялся, что его посчитают глупым или просто осмеют, ведь у коллег больше экспертизы, да кого вообще волнует его мнение?
В итоге вся команда недоумевает, доверие падает: если он ничего не сказал сейчас, то и дальше это будет продолжаться.
Как это можно исправить?
Если в команде есть стеснительные коллеги, можно использовать анонимные методы сбора идей.
Если стеснительных коллег нет, можно учитывать мнение каждого или проводить голосование.
Мы в своих командах проводим синки по предварительной оценке задач с участием всех коллег. Это помогает еще до перехода задачи в стадию бэклога выявить подводные камни и нюансы благодаря коллегам, которые уже могут быть в курсе этой задачи. Они где-то о ней слышали, или это продолжение их проекта либо другой задачи, которую они уже реализовали.
Эффект сверхуверенности и эффект подтверждения
С первой ситуацией мы разобрались и даже стали чувствовать себя увереннее. Можно сказать: «Я и так чувствую себя уверенно, даже более чем». И это замечательно. Но здесь тоже могут поджидать ловушки мышления.
Рассмотрим вторую ситуацию. Аналитик считает, что по новой задаче или новому проекту он знает процесс лучше заказчика, поэтому не задает уточняющих вопросов. И как же здорово, что у него уже есть в копилке реализованный проект с красивым решением. Было бы замечательно применить его и здесь. Да, оно будет не очень оптимально с точки зрения работы системы, но зато как красиво!
Отсутствие здравого смысла, можно подумать. Возможно. Но здесь также сработали эффект сверхуверенности и эффект подтверждения.
Эффект сверхуверенности
Начнем с эффекта сверхуверенности. Как он проявляется в команде?
Аналитик провел неполный анализ требований, из-за чего реализация не соответствует ожидаемой. Как следствие, приседаем всей командой еще разок и раздуваем спринт у разработки.
Но не аналитиками едиными. Разработчик не учел подводные камни, протестировал свои доработки только по очевидному сценарию: «Я все хорошо сделал, все вроде и так работает как надо». И не учел обратную связь.
Как следствие, растет количество итераций разработки и тестирования как аналитиком, так и тестировщиком. Мы двигаем плановый релиз и сроки проекта.
Как это можно исправить?
Может помочь использование чек-листов для написания проектной документации. Нам также помогает использование шаблонов. Например, шаблон для разработки новых объектов системы очень полезен при работе над новыми документами. В частности, он помогает учесть все: основные свойства документа, реквизитный состав, движения, которые этот документ формирует в регистрах бухгалтерии, накопления и сведений, ролевую модель, дополнительную информацию об этом документе. Например, участие документа в механизмах восстановления последовательности, сверках, проверочных и контрольных отчетах и так далее.
А для любителей красивых картинок – а среди разработчиков точно есть эстеты – можно добавить макет интерфейса. Тогда каждая кнопочка точно не будет забыта.
Кроме того, важно рефлексировать на ретроспективах и честно обсуждать, какие проблемы возникли из-за излишней сверхуверенности.
Эффект подтверждения
Следующее искажение – эффект подтверждения. Однажды оно поймало меня в ловушку.
Мне пришла задача, в рамках которой нужно было реализовать интеграцию одного документа из внешней системы в 1С. Я начала перебирать варианты: интегрировать его в имеющийся документ системы или с нуля разрабатывать под него новый документ.
В таких случаях я веду матрицу всех возможных и невозможных решений с их плюсами и минусами. Я начала ее заполнять. Первым расположила вариант, который был мне максимально симпатичен. Красиво – и все. Я была на сто процентов уверена, что мы реализуем именно его.
Но все-таки решила на нем не останавливаться, провела некий мозговой штурм и продолжила расписывать варианты. Указала еще несколько, которые подходили по смыслу, но были не такими красивыми. Последним добавила вариант, на который вообще не ставила. Я назвала его «Сон при температуре 40 градусов» – настолько нелепым он мне казался.
При последующем обсуждении с разработчиками мы выбрали именно этот последний вариант, о котором я никогда бы не подумала. Просто мы посмотрели на него под другим углом.
Это искажение также может поймать нас, когда аналитик начинает продумывать функциональность за пользователей и подталкивать их к уже заранее принятому решению, которое может быть избыточным. Мы реализуем космолет, а потом всей командой сидим и смотрим: «Зачем мы потратили на это столько ресурсов?»
Как это можно исправить?
Как я уже говорила, можно использовать матрицу всех возможных и невозможных вариантов реализации с их плюсами и минусами.
Мы в своих командах также используем практику вынесения вариантов реализации на обсуждение с разработчиками. Как и в моем случае, это действительно помогает выявить слепые пятна, которые не всегда очевидны аналитикам, но достаточно понятны разработчикам.
Персонализация и чтение мыслей
Перейдем к третьей ситуации. Мы пропустили баг в релизе. Ко мне приходит заказчик и говорит: «Функционал не работает. Там критическая ошибка».
Я считаю себя виноватой, ведь это я не расписала сценарий тестирования подробно, до атома. Мало того что я считаю себя виноватой, я начинаю прокручивать в голове, что обо мне подумают коллеги. Например: «Я накосячила на проекте, меня все ненавидят, потому что сейчас мы будем приседать всей командой, чтобы экстренно выпустить хотфикс. Я не буду рассказывать своему лиду о проблемах на проекте, потому что он посчитает меня глупой или слабачкой».
У этой ситуации два виновника: персонализация и чтение мыслей.
Персонализация
Начнем с персонализации. Как она проявляется в команде?
Аналитик, как в уже рассмотренной ситуации, становится крайним за любые косяки, боится делегировать проверку тестировщику, берет на себя чужую работу и, как следствие, выгорает. Когда он выгорает, то становится раздражительным, и на фоне этой раздражительности возникают разногласия и недоверие к команде.
Посмотрим со стороны разработчика. Разработчик видит в ТЗ неоднозначное требование. Вместо того чтобы задать конкретный уточняющий вопрос, он тратит недели, пытаясь угадать, что аналитик все-таки имел в виду.
Как следствие, разработчик перестает предлагать улучшения, ведь аналитик лучше знает, что нужно. Команда считает разработчика медленным, а сам разработчик теряет мотивацию.
Как это можно исправить?
Разделять зоны ответственности аналитиков, разработчиков и тестировщиков. Аналитики должны отвечать за корректность требований, используя те же шаблоны для написания ТЗ. Разработчики – за качество реализации с использованием Code Review, а тестировщики – за проверку соответствия и работу автотестов для критического функционала.
Кроме того, нужно внедрять безвинные ретроспективы: без суждений о личности выяснять, какой процесс подвел и как исключить это в следующий раз.
Чтение мыслей
Мой личный топ среди всех когнитивных искажений, оно же сверхспособность, – чтение мыслей. Как оно проявляется в команде? Рассмотрим несколько примеров.
Аналитик получил грубый ответ от разработчика и додумал за него причину такого ответа: «Ему не нравится со мной работать». А на самом деле у разработчика до диалога с аналитиком просто был неприятный разговор с его лидом.
Или аналитик отказался взять предложенную тимлидом задачу, а тимлид уже час не отвечает на его сообщение. Скорее всего, аналитик подумает: «Наверное, он на меня обиделся». А на самом деле тимлид просто пошел искать, кому из других аналитиков сможет поручить эту задачу, отвлекся на созвон и забыл, что сообщение осталось без ответа.
Или тестировщик попросил созвониться по вопросам, возникшим при тестировании задачи, а аналитик не ответил ему за весь день. Скорее всего, тестировщик подумает: «Он специально хочет меня подставить. Он специально тянет время». А на самом деле у аналитика именно в этот день календарь был забит созвонами по проекту и другим задачам, поэтому он физически не смог переключиться на этот вопрос.
Таких примеров масса. Я уверена, что каждый из нас так или иначе использовал в жизни это искажение. Да, во всех этих примерах есть вероятность, что нами или нашим проектом будут недовольны, что на нас обидятся. Но, как правило, она сильно ниже, чем нам кажется.
Как это можно исправить?
Запрашивать обратную связь на ревью и встречах один на один по итогам реализации проекта или выполнения задачи. Важно не просто запрашивать обратную связь, но и принимать ее, работать с ней. Не просто получить обратную связь и положить ее на полочку, где она будет лежать красивая или некрасивая – в зависимости от ситуации.
Также нужно рассматривать альтернативные объяснения, как мы сделали в примерах, и задавать вопросы напрямую, если что-то беспокоит.
Проклятие знания и предвзятость консерватизма
Перейдем к четвертой ситуации. Я написала ТЗ на разработку с использованием аббревиатур и терминов из бизнес-процессов. Более того, оформила его в файле Word, несмотря на то что наша команда приняла решение вести ТЗ на странице в Confluence.
Я все красиво оформила, прикрепила к тикету разработчика и спустя некоторое время получила обратную связь. Разработчик задает мне вопрос: «А что это такое?» – и указывает на конкретные бизнес-термины.
Я не понимаю, почему он задает такой вопрос. Мы работаем в одной команде, в одной компании. Это база, которую должны знать все. Тем более если мы работаем там не первый год.
Мы действительно можем быть профессионалами в своем деле, но здесь коммуникации может помешать проклятие знания.
Вдогонку разработчик высказывает пожелание: ему все-таки было бы удобнее отслеживать изменения в ТЗ, которые наверняка будут появляться на странице в Confluence, а не выбирать из тридцати трех файлов Word в тикете, какой из них актуальный.
И здесь я тоже не понимаю: «Почему эти разработчики вечно недовольны?» А это во мне говорила предвзятость консерватизма.
Проклятие знания
Начнем с проклятия знания. Как оно проявляется в команде?
Аналитик использует аббревиатуры и термины из бизнес-процессов, а разработчик – технические термины, которые могут быть непонятны аналитику.
Или аналитик пишет ТЗ, опуская очевидные для себя шаги в логике: «Сокращу-ка я ТЗ. Зачем писать подробно? Это же и так очевидно. Разработчик и так поймет, что нужно включить в документ механизм восстановления последовательности. Чего тут непонятного?» Как следствие, увеличивается время на разработку.
Другой пример – просьба реализовать алгоритм «как было там». Не буду подробно описывать, что в том проекте было реализовано так красиво. Скажу разработчику: «Сходи, пожалуйста, посмотри, как там, и перенеси это к нам». В итоге разработчику непонятно, что именно нужно переносить, из-за чего растет недовольство в команде.
Как это можно исправить?
Нам помогает ведение глоссария и описание всех реализованных проектов.
Также у нас проводятся встречи по реализованным проектам для всей команды. Это помогает закрыть громадное количество вопросов как у разработчиков и тестировщиков, так и у самих аналитиков. На таких встречах становится понятно, что, зачем и почему мы сделали именно с точки зрения бизнеса. Для некоторых ребят действительно важно понимать, во что они внесли свой вклад и в каком проекте участвовали.
Есть простая, но почему-то малоиспользуемая техника «Объясни пятилетнему». Она подразумевает написание ТЗ и другой проектной документации, где это допустимо, простыми словами или глазами новичка. Можно даже использовать визуализацию.
И, конечно же, нужно регулярно уточнять у коллег, все ли понятно. Можно попросить разработчика перефразировать постановку и рассказать, как он понимает написанное в ТЗ.
Предвзятость консерватизма
Следующее искажение – предвзятость консерватизма. Как она проявляется в команде?
Она проявляется как отказ от использования современных инструментов, предназначенных для оптимизации рабочего процесса. То, что удобно конкретному аналитику, может быть неудобно абсолютно всем разработчикам.
Как это можно исправить?
В наших командах новые подходы и механизмы сначала внедряются в рамках небольших проектов. Либо находятся добровольцы, энтузиасты, которые решаются испытать их на своих задачах, а впоследствии предоставляют расширенную обратную связь: что можно докрутить и исправить для общего удобства.
Так постепенно новые подходы и механизмы входят в нашу рутину, действительно позволяя сделать рабочий процесс более удобным и тем самым снизить уровень напряженности.
Эффект авторитета
Перейдем к пятой ситуации. Когда необходимо реализовать проект, мы обращаемся к авторитетному мнению внутри компании или к внешним источникам, чтобы определиться с реализацией.
Мы принимаем совет авторитета или копируем описание из какого-нибудь блога или форума без учета контекста проекта. Вроде бы проект реализован, но что-то не так. Здесь мы попались на крючок эффекта авторитета.
Как он проявляется в команде?
Мы принимаем решение, предложенное авторитетом или описанное на форуме, без учета контекста проекта. Оно может не полностью соответствовать требованиям. Как следствие, переделываем реализацию, потому что вроде бы все работает, но не так, как нужно. Растут недовольство и напряжение в команде.
Или мы слепо скопировали решение из авторитетного блога, неоправданно усложнили систему, и начала падать производительность. Как следствие, к последующим предложениям разработчика что-то еще оптимизировать уже относятся с недоверием.
Как это можно исправить?
Рассматривать рекомендации авторитета как еще один вариант реализации.
Лично мне помогает уже упомянутое ведение таблицы с несколькими вариантами реализации и последующее обсуждение предпочтительного варианта с авторитетным специалистом с использованием аргументации. При таком подходе мнение авторитета может стать мощным инструментом в руках аналитика и разработчика.
Как работать с когнитивными искажениями
Мы прошли по лабиринту нашего мышления и рассмотрели, как когнитивные искажения незаметно управляют проектами.
Вывод здесь не в том, что мы все жертвы этих эволюционных механизмов. Вывод в другом: осознание – это 50% решения. Мы знаем врага в лицо, но знания без действий бесполезны.
Поэтому можно сделать три простых, но критически важных шага.
Первое – начать с малого. Выбрать одно когнитивное искажение, которое больше всего резонирует с внутренними болями, и внедрить один инструмент для борьбы с ним.
Второе – говорить вслух. На следующем обсуждении задачи с разработчиком попросить его перефразировать, как он понимает постановку задачи в ТЗ.
Третье – менять процессы, а не людей. Предлагать не «быть внимательнее», а, например, внедрить чек-лист для проверки ТЗ.
Мы не можем перепрошить наш мозг. И уж тем более не можем переложить всю ответственность за возникающие ошибки только на него. Но мы можем создать среду, в которой ошибки мышления будут заметны и исправимы.
Профессиональная зрелость команды определяется не отсутствием ошибок, а тем, насколько быстро и системно она их обнаруживает и исправляет.
В прикрепленном к статье гайде по когнитивным искажениям собраны инструменты для работы с ними, которые можно начать внедрять в своих командах уже с понедельника.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
