Есть асимметрия, которую постоянно наблюдаю в командах. Многим чужая работа часто кажется проще своей. Со стороны аналитик "написал запрос и нарисовал график", QA "прогнал кейсы и завёл баги", а ML-инженер "запустил обучение и посмотрел метрики", но спроси того же человека, почему его собственная задача едет уже третью неделю, и выяснится, что там легаси, зависимости, смежники, корнер кейсы и ещё десять подводных камней, которых снаружи не видно. Чужую работу мы видим по результату, свою - изнутри процесса. У аналитика снаружи остаётся график, а сырые данные не видно, регулярно ломающийся пайплайн скрыт от зрителя, о трёх неверных гипотезах и запросе, который пришлось переписать четыре раза, внешние признаки не говорят. В своей же работе именно из этого и состоит большая часть времени. Часто в этом винят actor-observer bias: своё поведение мы объясняем обстоятельствами, чужое - качествами человека. Популярная теория, которая не прошла проверку мета-анализами. Оказывается, это лучше обьясняется другими двумя эффектами. Первый - correspondence bias: по чужому видимому поведению мы слишком легко делаем вывод о самом человеке и недооцениваем ситуацию. "Задача простая, значит они просто медленные". Второй - self-serving bias: собственные неудачи мы гораздо охотнее объясняем внешними обстоятельствами. Достаточно удобная комбинация, где сложность своей работы мы знаем во всех деталях, а сложность чужой просто не наблюдаем. При этом собственные издержки кажутся следствием объективных проблем, а чужие следствием чужой неэффективности. Поэтому "да что там делать" - почти всегда плохой сигнал, говорящий нам о глубине собственного понимания этой задачи. Если работа других людей выглядит тривиальной, разумнее сначала предположить, что большая часть процесса тебе просто не видна. Лучшее лекарство - контекст, а за контекстом надо "на гембу". Несколько часов рядом с хорошим QA, аналитиком или инженером часто дают больше, чем лицезрение движения тикетов. Похожая история и со сроками. В одном эксперименте про planning fallacy студенты в среднем ожидали закончить диплом за 34 дня, хотя по факту тратили 55. Даже максимально драматичный и негативный сценарий оказался в оценках оптимистичнее реальности. Поэтому оценку чужой работы полезно дисконтировать так же, как реальность это регулярно делает с нашей.

Безопасная культура Чтобы нормально работать с ошибками, нужно создать культуру психологической безопасности в компании. Безопасная обстановка позволяет открыто обсуждать ошибки. В результате ошибки проще убрать, проще разобраться с тем, как сделать так, чтобы подобные ошибки не повторялись в будущем. В культуре где принято обсуждать ошибки, люди могут сосредоточится на работе, а не на том, что про них подумают другие люди или начальство. В свое время Эми Эмодсон изучала вопрос как командная работа влияет на количество ошибок. Первый этап работы показал очень интересную зависимость: более продуктивные команды в больницах ошибались чаще. Это противоречило логике. После некоторых раздумий, Эми решала проверить гипотезу, что в более продуктивных командах сотрудники будут рассказывать про большее количество ошибок. В результате они начали второй этап исследования, где, в том числе ошибки фиксировал независимый участник, а не сама команды. И в опросник для команды включили вопрос: «Если вы совершите ошибку в этом подразделении, это не будет воспринято против вас». Выяснилось, что так и есть. В командах была совершенно разная атмосфера. Где-то люди открыто объявляли об ошибках — медсестры говорили что «определенный уровень ошибок неизбежен», поэтому для хорошего ухода за пациентами необходима «система ненаказуемости».В других отделениях было практически невозможно открыто говорить об ошибках, медсестры объясняли, что совершить ошибку - значит «попасть в беду» или «оказаться на скамье подсудимых». Они рассказывали, что, если что-то шло не так, они чувствовали себя ничтожными, «как двухлетние дети». #ЧФ #ошибки #психбезопасность

Как мы набросали 3 новых продукт за 3 часа На прошлой неделе с командой работали оффлай и в последний день решили сделать хакатон. Было офигенно! Рассказываю что успели: 1. Задача была – повеселиться, выйти немножко за рамки текущего продукта и "дать себе волю". Не было надежды что что-то из этого можно будет использовать в проде Разбились на 3 команды и делали 3 новых версии для продукта: - Маймит для HRов - Маймит для Sales - Маймит для исследователей У нас давно есть идеи вертикализации, тк сейчас продукт слишком для "всех" Короче поверх текущего Маймита за 3 часа нужно было - закасдевить клиента из воронки - навайбкодить решение, - показать решение клиенту, получить от него фидбек На выходе получили три работающих прототипа, каждая команда провела всем демо Из интересного: В sales-сегменте два агента работали параллельно: Fable и GPT 5.5 xHigh. Фейбл по итогу оказался более консистентный текущему продукту, гпт чуть больше нейрослоп (промпт был одинаковый) Для команды это было прикольно двумя вещами: - посмотреть какие подходы в работе с coding agent эффективнее: кто-то потратил половину времени на план и огромный промпт-цель. Кто-то делал итерациями и 5 параллельными агентами (оказалось хуже) - познакомиться и повзаимодействовать глубже с ребятами из команды, тк были и разрабы и сейлзы условно Результаты хакатона будем развивать дальше в продукты (дай бог). То, что получилось нельзя вчистую использовать в проде, но теперь точно будет легче тк есть вижн, первые черновики и проработка мероприятие зашло команде, немножко напоминает подготовку вечернего мероприятия в лагере – все торопятся, азарт, идеи и вот это всё. В комментах покажу pdf в sales-сегменте для сравнения от Fable и GPT 5.5 xHigh