Ошибка выжившего в ИТ
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.