Эта статья подходит для тимлидов и их подопечных, а также для всех, кто оценивает проекты и задачи. Я расскажу, как и почему мы делаем ошибки из-за когнитивных искажений. Попадаем в них мы почти все, просто потому что мы живые люди. И на примере одного дня из жизни тимлида я хочу показать, в какие искажения чаще всего влетают в IT, и — самое полезное — как из них можно выходить.
Замечу, что искать когнитивные искажения стоит, в первую очередь, у себя, а не у коллег. И что рассказывать про искажения намного проще, чем не влетать в их на практике, однако, если этому научиться, то в перспективе это изрядно окупается, потому что экономит и время, и деньги, помогая и нам, и команде.
В Википедии описано больше 175 когнитивных искажений. И все они по сути про обман нас нашим же мозгом. Однако, мозг делает это не со зла, а, зачастую, он ленится и не хочет тратить ресурсы. При этом, нельзя сказать, что мозг работает неправильно. В мозге нет никакой логики, он просто делает то, чему обучился — а обучается мозг закономерностям.
Например, если мы подкидываем монетку десять раз, и она все десять раз подряд падает вверх решкой, то мозг думает: «О, в следующий раз тоже будет решка!» Потому что для него это очевидно. Для мозга это проще, чем учить теорию вероятности и комбинаторику — он просто наблюдает и запоминает. Однако если вложить в мозг эти знания, то он научается иначе анализировать шансы в подбрасывании монетки, а заодно и осознавать когнитивные искажения. И даже выбираться из них.
Сегодня я расскажу про 5 популярных когнитивных искажений из той части большого колеса, что отвечает за влияние на оценки и мышление. В принципе, начинать изучение когнитивных искажений стоит с небольшого количества, осмысляя и анализируя их постепенно, чтобы не получился перегруз.
И давайте я поделюсь, почему это тема является для меня такой важной. Я в IT уже 14 лет. Начинала как единственный QA в компании, и ко мне постоянно приходили и спрашивали: «Ну как, в пятницу задеплоимся? Очень надо!» Потом я начала нанимать людей, и уже сама подходила к ним и говорила: «Ну как, протестируешь задачку за два дня? А за три?».
За 14 лет я много раз видела, как делают оценки хорошие, классные PM, видела всякое неполезное умножение на Пи. У меня был как опыт оценки проекта на три месяца за два дня, так и проекта на год за два часа (не пытайтесь это повторить, развлечение на любителя). Я смотрела на то, как делают оценки другие люди, как они при этом промахиваются, как это делаю я сама, и начала подозревать, что дело, видимо, не в людях, а в чем-то другом.
Например, в течение двух лет я наблюдала, как на каждом стендапе в 10 утра отличный бэкенд-разработчик Вася говорил: «Я сегодня эту задачу сдам до обеда!» Обед у него был в два часа, но каждый раз он сдавал задачу после четырех. Сейчас я понимаю, что он совершенно искренне верил, что именно в этот раз у него всё получится, и ничего ему не помешает. У него будут все макеты, не будет проблем с мержем или с миграциями, из команды никто не заболеет — сегодня он точно сдаст всё вовремя!
История первая. Positive bias
Итак, обещанные истории на примере одного дня из жизни тимлида. Жила-была тимлид Алиса. Давайте не будем обманываться ее хрупкостью — она очень крутой тимлид, легко может и голов в Бравный день нарубить. У нее несколько команд. А еще, в силу опыта, ее часто зовут консультантом. С чего же начинается день Алисы? Иногда - с прыжка в кроличью нору, все по классике.
Например, это может быть сразу планирование и ретроспектива.
Приходит Алиса к своей команде и предлагает провести ретро и оценить задачи на следующий месяц. Вообще, команда классная, Алисе нравится с ними работать. Однако с точки зрения бизнеса у команды не очень с метриками, потому что за год она успела сделать только один релиз вовремя, а все остальные сроки были сорваны. И бизнес предсказуемо волнуется по поводу следующего релиза.
Алиса предлагает своей команде проанализировать, почему же у них не получилось сделать вовремя прошлые релизы?
И команда начинает вспоминать, что в июле они не успели из-за обучения новеньких — тогда много народу набрали и не всё успели сделать. В августе болел Петя — тяжело болел, пневмония с осложнениями, а без него было сложно. В сентябре соседняя команда дизайны не отдала вовремя. А в октябре отдала вовремя, и релиз у них был прямо огонь!
В ноябре было много запросов из саппорта насчет октябрьского деплоя, и пришлось много отвечать. В декабре злобные соседние команды разломали их апишечку. В январе команда снова болела — был ковидный год, сама знаешь! В феврале делали миграции, и вместо трех месяцев сделали их всего за месяц, так что команда мега-крутая! В марте сделали A/B-тесты, но они оказались так себе. Их в итоге откатили, и весь месяц работы пришлось выкинуть. А в апреле подумали, что код уже не очень, год как-никак прошел, и решили сделать рефакторинг, поэтому тоже в срок не успели.
«Окей, тут понятно», — говорит Алиса, — «А успеете ли вы сделать новые задачи в мае?». Команда уверенно отвечает: «Да! Конечно, да! Мы же сделали вовремя задачи в октябре! Значит, и в мае успеем».
И Алиса понимает, что достучаться до команды сходу ей не удалось, потому что команда находится ни в чем ином, как в когнитивном искажении, которое называется Positive bias.
Positive bias состоит оно в том, что в будущем мы видим исключительно позитивный путь развития событий. Мы думаем, что нас ничто не отвлечет от выполнения задач. Что мы будем здоровыми, выспимся, у нас будет хорошее настроение, вся наша команда придет вовремя и будет активно работать. Что кругом будет мир, солнце и никакого ковида. Тот же бекэнд-разработчик Вася все два года находился в таком же когнитивном искажении.
Что с этим можно сделать?
Премортум
Первый вариант выхода из Positive bias — премортум. Суть его в том, что мы представляем с командой печальный вариант развития событий, и ищем, что нас к нему привело. Например, воображаем, что у нас есть месяц на проект, и мы будем делать всё, как запланировали. А через месяц оказывается, что мы всё зафейлили. И теперь пробуем понять, что нас к этому привело. Что такое случилось, что мы такое делали, что все запороли?
Именно такая постановка вопроса позволяет раскрыться даже тем интровертам, которые обычно отсиживаются в углу, ведь фейл уже случился, пусть и пока только в нашем воображении — нашему мозгу этого достаточно для анализа. Так команда начинает выдавать гипотезы, а вы внимательно слушаете и записываете всё, что они говорят, чтобы понять, как вам делать не надо.
Оценка с конца
Следующим вариантом выхода является оценка с конца. Как QA я ее очень люблю, однако ее недолюбливают некоторые разработчики.
Возьмем, например, двухнедельный спринт. Допустим, планирование этого спринта происходит в обед в понедельник. Команда разработки радостно говорит PM-у, что на разработку нужна всего неделя, и, конечно, через 2 недели в пятницу деплой будет на продакшене, ведь впереди времени вагон.
На что QA предлагают посмотреть на сроки с конца. Например, для деплоя через 2 недели (то есть утром в пятницу) на окружении всё должно быть готово и проверено в четверг вечером — это крайний срок. Чтобы у нас был такой результат в четверг вечером, нужно провести регрессию и багофикс. Допустим, в идеальном мире это займёт только четверг.
Перед этим надо протестировать саму фичу. Она большая, поэтому потребуется дня четыре. Вычитаем их, и получается, что хорошо бы на тест задачу получить в пятницу утром. То есть на разработку от всего спринта у нас остается три с половиной дня. А теперь вспоминаем, что на разработку нужна неделя. Выходит, мы уже не укладываемся. С помощью такой нехитрой математики легко находятся нестыковки по времени.
Смогу ли я сделать это «прямо завтра?
Еще один способ расскажу на примере из жизни. Недавно меня позвали выступить на конференции. Хорошие ребята позвали, и тематика мне близка. Конференция через 2 недели, у меня есть идея доклада — казалось бы, всё совпадает. Первый порыв был согласиться.
А потом я вспомнила про одну классную практику Если подумать, смогла бы я на этой конференции выступить прямо завтра (или на этой неделе)? И я поняла, что нет: у меня в календаре уже много занятых слотов, и, если добавить сюда подготовку к выступлению, то будет очень большой перегруз — и пришлось отказаться.
Итак, с первым когнитивным искажением мы разобрались.
Возвращаемся к нашей Алисе. А она, между тем, решила сделать перерыв, вышла за кофе и встретила Безумного Шляпника — коллегу из соседней команды. Они разговорились об оценках, сроках, когнитивных искажениях, и Шляпник рассказал Алисе свою историю.
История очень страшная. False consensus bias
— Некоторым проектам для разработки достаются всякие прикольные штуки: шлагбаумы, автоматы для мороженого, протезы для ног и рук, а то и вовсе обработка мультика или шутера.
А нам как-то достались технические девайсы с кучей дополнительных аксессуаров к ним. То есть нечто сложное, маленькое, и страшно секьюрное в чёрных коробочках, — вздохнул Шляпник.
— Мы основательно подготовились к проекту. Всю команду набрали в одном городе, чтобы весь набор этих девайсов привезти в одно место, а не рассылать по всему миру. Мы согласовали с заказчиком стратегию реализации, подписали документы. Команда даже собрала справки, что у них нет судимостей, чтобы работать на этом проекте. Все выглядело успешно. В конце мы договорились, что часть команды будет периодически приезжать к заказчику онсайт — и большая часть техники будет там, а часть техники пришлют к нам, вот буквально уже в понедельник.
И вот, наконец, настает понедельник. Мы ждем доставку девайсов, но что-то техника все не приезжает и не приезжает. Уточняем статус у заказчика, а он неожиданно говорит: «Ребята, простите! Техника очень секьюрная, не получилось отправить её посылкой, завернули обратно. Но я узнал, что можно её везти, если с ней поедет кто-то из ребят. Так что ничего, через пару недель кто-то их ваших же ребят поедет домой обратно и привезет комплект в ваш офис. Кстати, я так сильно увлекся пересылкой, что не узнал, как у вас дела. Как у вас? Какая-то накладка с самолетом? Мы тут всех ждем, у нас столы с техникой готовы. Где же все? »
То есть, заказчик думал, что вся команда приедет онсайт сразу — знакомиться перед началом проекта, а мы думали, что поедем к нему где-то через месяц, а пока ждали технику у себя. Такого старта проекта, конечно, никто не ожидал, и все были очень недовольны: заказчик не очень хорошо думал про нас, а мы — про него, — и Шляпник опять загрустил.
В этой ситуации обе стороны — и команда Шляпника, и их заказчик — попали в одно и то же когнитивное искажение, которое называется False consensus bias. Оно состоит в том, что мы думаем, что другие люди думают так же, как мы. Шляпник был уверен, что к ним приедет техника, а заказчик придумал, что к нему приедут люди.
Что с этим делать?
Проговаривать всё явно
Проговаривайте явно все основные моменты проекта, ничего не воспринимая на веру и немедленно все фиксируя. Записывать можно в документах, в чатах, в почте (сам инструмент не так важен), главное — фиксируйте.
Чек-лист, и ни шагу из него
Разработайте и используйте чек-лист для старта проекта, никогда не пропуская из него ни одного шага. Команда Шляпника накосячила с тем, что пробросила пару шагов в силу их очевидности, решив, что это само собой, что у них будет техника, и ребята когда-нибудь съездят онсайт. И не договорились о конкретных датах.
Для выхода из этого искажения можно все утверждения переводить в гипотезу и задаваться вопросом: «Как эту гипотезу можно проверить?» На основе этого также удобно формировать рекомендуемый выше чек-лист.
Второе когнитивное искажение мы рассмотрели, а Алиса тем временем возвращается к своей команде. Им надо оценить задачу по локализации сайта и переводу его на пять языков.
История непонятная. Expert's problem
Придя в команду, Алиса узнает, что у них был эксперт по локализации Дима. И ругался последними словами, что в их задаче по переводам работы вовсе не на месяц, как успела прикинуть команда, а минимум на три. Ничего не объяснил и убежал. Что не так с оценкой и почему — непонятно.
Алисе команда объяснила, почему у них выходит месяц работы. Они оценили испанскую локализацию примерно на неделю. Потом португальский язык — это тоже где-то неделя. Следующим идет немецкий — тоже ничего нового. Потом иврит — тоже плюс-минус неделя. Ну и чешский в заключении, так же. В сумме около пяти недель, но «мы же опытные будем после первого языка», и что-то где-то срежется, оптимизируется — на месяц работы как раз и получится. Что не так? Что эксперту не понравилось?
Алиса вздыхает, открывает сайт букинга и показывает команде, как сайт выглядит на английском — всё хорошо, знакомо. А потом Алиса выбирает в настройках иврит, и команда видит, что немного (а если точнее, совсем целиком) меняется расположение абсолютно всех элементов, плюс написание слов идет справа налево:
Тут-то команда наконец понимает, что имел в виду эксперт Дима. Однако он не смог привести пример и рассказать, в чем проблема. А все потому, что Дима находился в когнитивном искажений, которое называется Expert's problem. Оно состоит в том, что сам эксперт ясно видит, в чем проблема, и для него эта проблема слишком очевидна, чтобы хоть что-то пояснять.
Что с этим можно сделать?
Представьте, что обучаете джуниора
Эксперту можно представлять, что он обучает junior´а. Иногда вся команда может состоять из middle и senior разработчиков, однако, с чем-то они могли столкнуться впервые. Так как опыта у них еще в этом вопросе нет, то им нужно все рассказать как для новичков (кем они в новой сфере и являются).
А еще можно переиспользовать выход из предыдущего искажения — явно проговаривать все основные моменты проекта словами, и использовать чек-лист, никогда не пропуская ни одного шага. Очень удобно — искажения два, а выходы одинаковые. Два по цене одного, как я люблю!
А рабочий день между тем продолжается, и наша Алиса идет на обед со своим приятелем PM-ом. В ходе разговора выясняется, что PM в отчаянии, потому что не может сдать проект. Ситуация такая: прошло уже три месяца, все пашут как лошади, через месяц дедлайн, а команда при этом все еще находится в начале пути. И PM рассказывает страшную историю.
Просто страшная история. Self-serving attribution и Fundamental attribution error
— Начиналось всё довольно хорошо. Пришел к нам заказчик и говорит: «Я вообще отличный заказчик! Я всегда на связи, открыт к общению и пишу полное и подробное ТЗ».
А еще заказчик рассказал, что за два года с этим проектом не справились уже четыре команды. Они почему-то не сдавали всё вовремя, и приходилось сворачивать проект. И он пришел к нам, потому что слышал, что мы клевые, молодцы и вообще эксперты в своей области.
Мы подумали: «Конечно, мы эксперты! Мало ли, какие четыре команды у него были! Может, там очень неорганизованные или некомпетентные люди были. Может, он сэкономить пытался и ходил к каким-нибудь джунам. А мы-то молодцы». И на оптимизме сказали, что всё сделаем.
Проект стартовал. Через месяц мы провели заказчику демо и показали часть работы. Заказчик сказал, что всё классно, принял. А на следующий день переписал все принятые user story — потому что «так проект будет лучше».
Мы впряглись, выкинули кусок работы, переписали код и тесты. Еще через месяц мы провели второе демо. Заказчику все понравилось. Мы обрадовались. Заказчик же принял работу и... снова переписал все user story, потому что, конечно, «так проект будет только лучше». И сейчас, когда мы провели третье демо, он сделал то же самое.
Договориться по-хорошему, чтобы заказчик перестал так редактировать истории, у нас не получается (мы пробовали). Работать так невозможно — вся команда деморализована. Мы снова, считай, в начале проекта, куча кода и тестов в итоге выкинута, а заказчик ругается.
В качестве решения Алиса предложила убрать у заказчика права на редактирование завершенных user story и явно проговорить, что все доработки идут отдельными задачами — в другие сроки и за другой бюджет. А еще (и это самое главное) понять, что заказчик действительно действовал из благих побуждений, и при этом не получал со стороны команды фидбека, что переписанные истории влекут за собой очень много работы, что это вовсе не минорные правки. И про это важно говорить.
В этой ситуации в когнитивные искажения влетели обе стороны: и заказчик и команда. Здесь мы явно видим Self-serving attribution и Fundamental attribution error.
Self-serving attribution состоит в том, что позитивный outcome — это исключительно наша заслуга, а негативный — это какие-нибудь злые силы и враги.
Fundamental attribution error — его близкий родственник: это про то, что наши ошибки приписывается неким злым силам, а если я сам накосячил, то это случайно. Я опоздал на автобус — всякое случается, бывает. А вот если мой коллега опоздал на автобус, то это он разгильдяй, который не в состоянии следовать элементарному расписанию и выйти заранее.
В истории PM´a и команда неправильно выстроила отношения с заказчиком, и заказчик неправильно взаимодействовал с командой. Команда считала, что она молодец, а заказчик строит козни. А заказчик считал, что он делает проект только лучше, а команда что-то недовольна.
Что с этим можно сделать?
Деперсонализация задач
Мы гораздо точнее оцениваем задачи для кого-то другого, чем для самого себя, поэтому выходом будет деперсонализация задач. Мы можем поставить себя на место заказчика и попытаться понять, что важно для него. Скорее всего, у заказчика нет злого умысла. Он вовсе не хочет, чтобы мы работали сверхурочно, бесплатно и по выходным. У заказчика есть желание сделать действительно хороший продукт, который понравится пользователям.
У заказчика искажение в том, что он считает, что он всё делает правильно, и именно так и надо делать проект лучше — переписывая все истории. К заказчику можно прийти и, деперсонализировав задачи, попытаться понять, что можно предусмотреть заранее, какие изменения стоит внести в логику до разработки, какую проработать аналитику, чтобы сразу сделать хорошо.
В итоге это история с хорошим концом. PM мирно обсудил всё с заказчиком, сроки сместили, ТЗ обсудили. Проект сдали позже всего на месяц, но действительно сдали, и заказчик остался доволен.
И под конец дня Алису позвали в качестве консультанта.
История про выбор новой технологии
Консультировать Алиса пришла в команду, где мобильной разработкой еще вообще никто никогда не занимался, но все очень хотели попробовать, все были на энтузиазме. Целью было сделать с нуля кроссплатформенное мобильное приложение, где будет много динамических картинок и спецэффектов. А от Алисы ждали помощи с выбором подходящей для этого технологии.
Мышь Соня предложила: «Давайте проведем митинг и обсудим, что можно сделать». В ходе обсуждения выяснилось, что Соня знает про Xamarin и слышала про него хорошее. Мартовский Заяц сказал, что он читал, что для мобильной разработки еще хорош React Native, но и про Xamarin тоже неплохо пишут. Червонный Туз отметил, что он тоже знает хорошее про Xamarin, а еще он гуглил про Flutter.
Тут команда замечает, что у них есть общее пересечение — Xamarin: «Классно! Мы все слышали, что он хороший — давайте делать на нем!»
«Погодите минуточку», — говорит Алиса — «Хотите, я расскажу вам, что будет через полгода, если вы начнете писать на Xamarin? А будет примерно такая история: большая часть функционала не будет реализована, приложение будет тормозить и работать так себе. Проект развалится, а команду уволят. А все потому, что Xamarin просто не подходит для разработки сложных кросс-платформенных приложений такого типа ».
Алисе понятно, почему команда сделала такой выбор — они попали в когнитивное искажение Availability Heuristic или Эвристика доступности. Суть его — то, что мы слышали чаще всего, и является для нас правильным.
Но почему все трое разработчиков слышали именно про Xamarin? Потому что про него недавно вышло пять постов подряд на Хабре, и ребята их прочитали, потому что хотели заниматься мобильное разработкой и быть в тренде.
Как из этого можно выйти?
Правильно поставить эксперимент
Эксперимент состоит в том, что нам надо изначально правильно задать вопрос. В примере с мобильной разработкой это вопрос: «Что именно нам подходит для наших задач, чтобы сделать наше кроссплатформенное приложение? Какой именно фреймворк хорош под эти запросы?»
Для получения ответа можно, например, смотреть рейтинги, составлять запросы, изучать параметры применимости и изучать ответы на Stack Overflow. А собрав всю эту информацию, можно получить, что для нашего кроссплатформенного приложения, где будет много динамических элементов, подойдет, например, тот же самый Flutter, который тоже был на обсуждении — и тогда всё будет хорошо.
Заключение
Вот вам с собой в помощь табличка с тем, что мы сегодня разобрали:
А напоследок я хочу вас предупредить об еще одной важной особенности. Постарайтесь во время разговора не фокусироваться только на когнитивных искажениях, потому что за их распознаванием очень легко потерять нить того, о чем вам говорит собеседник.
Например, бекэндер Вася вам говорит, что он отдаст задачку в QA после обеда. Вы радостно замечаете, что Вася снова в когнитивном искажении, и думаете, как бы его из него сейчас вывести.
Однако если послушать Васю дальше, то выясняется, что суть Васиного рассказа в том, что в соседней команде взяли точно такую же задачу. И самое важное для вас сейчас, как лида — не то, что Вася попал в когнитивное искажение, а пойти и разрулить, кто же на самом деле выполняет задачу, чтобы не было дубля.
Поэтому оставайтесь в контакте с людьми, с которыми вы говорите. Постарайтесь их слушать и слышать.
С вами была Суходолова Татьяна, QA Lead, Evrone. Мой FB для связи. Видео моего выступления на TeamLead Conf 2021.
Профессиональная конференция только для тимлидов TeamLead Conf 2022 пройдет 28 февраля - 1 марта 2022 года в Москве.
Открыт прием докладов. Присоединяйтесь, будет интересно!