Как стать автором
Обновить

Топ-5 когнитивных искажений при планировании в IT

Время на прочтение13 мин
Количество просмотров37K
Всего голосов 97: ↑96 и ↓1+95
Комментарии44

Комментарии 44

Текст очень замусорен английскими словами. Походит на некачественный перевод.

Зачем все эти "False consensus bias"? Почему не "Эффект ложного консенсуса"

А уж "позитивный outcome" - это вообще полнейший trash и cringe.

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

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

PS: После прочтения текста пришла мысль, что в итоге просто умножить сроки на Пи - не такой уж плохой вариант ;) Предусмотреть все проблемы (кто-то заболел, поменялось API, подвела 3я сторона и пр) все равно невозможно.

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

Можно один раз в скобках дать термин на английском (если уж, на английском терминология устоявшаяся, а на русском, еще нет)

В начале статьи дана ссылка на "большое колесо", там все искажения названы на русском. Почему их не использовать?

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

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

Добрый день, спасибо за фидбек. Мы хотели передать ключевые моменты из презентации, поэтому картинок здесь действительно много. Учту, спасибо!

Я думаю что картинки, напротив, оживили статью, очень приятно читать прерываясь на иллюстрации. Что за книжки без картинок

Спасибо большое, это приятно)

Спасибо, мне, как автору, это очень приятно)

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

Спасибо большое! Эффект якоря не забыли, а с сожалением убрали, как и еще пятерку других искажений, чтобы не вызывать перегруз. И да, в этой теме еще много интересного)

Зря убрали, пишите ещё )

Хорошо, тем более, что тема моя любимая, продолжу)

(извините за долгий ответ, написала статью и приболела, сейчас возвращаюсь)

Любопытно, спасибо.
Но что такое «премортум» непонятно от слова совсем. Про «прямо завтра» тоже непонятно: очевидно, что две недели != одному вечеру.

"премортум": если я правильно уловил, это как postmortem, только pre-

Непонятно что с этим делать. Ну представили мы, что сорвали сроки из-за того, что Петя заболел, а Вася не смог разобраться в новом фреймворке. Ну обсудили. Но какое отношение это будет иметь к реальности?

Примерно следующее:
Первый случай: "Наступает осень, период простуд и в нашей команде в это время стабильно один из сотрудников сидит на больничном ( потом другой, третий). Значит, в план надо закладывать меньшую загрузку".
Второй случай: "Этот проект на фреймворке X, Вася с этим фреймворком не работал, освоение нового у него всегда идёт со скрипом. Значит, нужно либо исключить из проекта Васю, либо заложить время Пети ( опытного коллеги) на Васино обучение".

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

Это скорее "предсмертие", т.е. сразу наступает худший и неизбежный исход.

История первая. Positive bias

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

При этом цифры о том, что спринты выполняются на 40-50%, что как бы говорит о том, что с планированием что-то не то - вообще не аргумент для таких менеджеров. Местами складывается впечатление, что это не ошибка, а специально делается - ставят программистов в условия, когда они всегда не успевают.

Я для себя сделал вывод, что если менеджер не наблюдал в своей практике смерть ИТ-проекта (под грузом багов, которые являются следствием разработки в спешке), то переубеждать его бесполезно. В команде также найдется неопытный программист (а чаще всего не один), которые мыслят «да что там сложного», на чье мнение они и опираются.

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

Видимо руководство этого менеджера не далеко ушло.

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

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

Классная статья! Лично я частенько нахожусь в Positive bias. Особенно при планировании ежедневных дел

Спасибо! Да, это самое популярное искажение) Я себя тоже в нем периодически нахожу)

>> При этом, нельзя сказать, что мозг работает неправильно. В мозге нет никакой логики, он просто делает то, чему обучился — а обучается мозг закономерностям.

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

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

Далее по тексту также есть множество проблем с логикой, а именно когда из каких-либо предпосылок делаются неочевидные и необоснованные выводы, это если не вдаваться что большая половина предикатов весьма спорна (пр. заказчик не хочет переработок и т.п., учитывая, что автор повествует в основном про аутсорсовых заказчиков - ну да не хочет, особенно на стадии MVP в маленьком проекте, только о команде и качестве продукта и думает).

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

Например, в течение двух лет я наблюдала, как на каждом стендапе в 10 утра отличный бэкенд-разработчик Вася говорил: «Я сегодня эту задачу сдам до обеда!» Обед у него был в два часа, но каждый раз он сдавал задачу после четырех. Сейчас я понимаю, что он совершенно искренне верил, что именно в этот раз у него всё получится, и ничего ему не помешает. У него будут все макеты, не будет проблем с мержем или с миграциями, из команды никто не заболеет — сегодня он точно сдаст всё вовремя!

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

Так что согласен, анализ выполненных проектов важен для будущих

Отличная подборка когнитивных искажений! Хотя с последним пунктом я рискну не согласиться: вместо того, чтобы выбирать технологии методом тыка пальцем в небо, в команду желательно добавить синьора, который на этом стеке уже выпустил пару проектов в прод.

Спасибо! Согласна, позвать Senior в помощь здесь является отличным решением. Как раз - определились со стеком, и можно такого спеца искать и звать)

Приходит Алиса к своей команде и предлагает провести ретро и оценить задачи на следующий месяц.

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

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

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

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

Читаю и с ужасом вспоминаю время когда я работал в команде, как же хорошо работать в одиночку

Если в команде хорошо выстроены процессы, то и в команде работать - золото) Здесь я специально подобрала показательные страшные истории

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

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

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

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

Большое спасибо за статью!
Применение техник «Премортум» и «Планирование с конца» помогло вовремя выйти в релиз. Применили конечно и кое-какие свои инструменты (визуализация в Miro), но информация пришла очень вовремя )

Пожалуйста) Я рада, что техники вам уже пригодились) Приятно про такое читать)

Думаю выражу не очень популярное мнение. Когнитивная ошибка номер 0:

«Я сегодня эту задачу сдам до обеда!»

Мнение о том, что некоторые когнитивные ошибки стоит исправлять.

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

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

P.s: "Планирование с конца" — благодарю, только прочтя эту строчку я в голове чётко оформил то, что делал рефлекторно, "инстинктивно", теперь я могу это задействовать более осознанно и эффективно.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий