Сели и пишем, или что можно сделать с коварством эффекта Даннинга-Крюгера

    Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом.

    Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но в чём именно заключается и что делать — неясно.

    Интересно, что многие англоязычные статьи в поиске ответа на вопрос об основной проблеме ИТ дают достаточно простой и, возможно, не всеми ожидаемый ответ: мы. Да, мы, люди, а не вычислительные мощности, особенности виртуализации или же другие технические возможности, являемся основной проблемой ИТ.

    Одна из причин, возможно, важнейшая – это эффект Даннинга-Крюгера. Если отразить его на графике, то несложно заметить точку, хорошо знакомую многим по анекдоту про Брежнева: я стар… я супер-стар.

    Влияние эффекта Даннинга-Крюгера на восприятие собственного профессионализма; искомая точка находится слева вверху
    Влияние эффекта Даннинга-Крюгера на восприятие собственного профессионализма; искомая точка находится слева вверху

    Разберём на примерах.

    Взаимодействие «бизнес — ИТ»

    Некоторое время назад я работала в аутсорсинговой компании, специализирующейся на сложных технологических, нетиповых задачах (нет лэндингам – да автоматизации бизнеса и навороченным приложениям). Наши заказчики нуждались в новых информационных системах, и нашей задачей было создание таких систем, чтобы затем передать их клиенту. Как руководитель проекта я часто была задействована в процессе, состоящем из следующих стадий: бизнес принёс идею → мы её донесли до продуктива → мы помогли заказчику нанять себе внутреннюю команду → мы отдали продуктив этой внутренней команде, чтобы уже её руками продолжался основной цикл жизни продукта, заключающийся в его невзрывном развитии и эксплуатации. То есть совсем просто: запуск → передача.

    И при найме таких внутренних команд, и при передаче им проектов возникали казусы, которые заставляли меня сильно грустить задуматься о компетенциях всех вовлечённых сторон и об истинных их устремлениях.

    Ведь кто такой хороший разработчик, если смотреть с точки зрения бизнеса, имеющего дело с ИТ только в виде внешней команды? Как может бизнес судить о том, даёт ему рекрутер хороших кандидатов или нет? Когда нам пошёл поток соискателей на технические собеседования от одного из заказчиков, мы поняли, что критерии отбора до слёз просты: свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание. Все кандидаты были очень похожи по этим параметрам. При этом они просили неимоверные, на наш взгляд, зарплаты за достаточно посредственные навыки.

    Утрированный образ «типичного» разработчика глазами бизнеса
    Утрированный образ «типичного» разработчика глазами бизнеса

    Будучи в изумлении, мы подсветили вопрос заказчику: знаете, вот за такие деньги, раз уж у вас есть на это бюджет (а можно было бы и опустить планку), можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба. Наше изумление возросло ещё больше, когда мы были поставлены на место: вы просто проверьте их навыки, нечего нам указывать, это – лучшие люди. Ясно, понятно.

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

    Звонок начался. На том конце был парень в растянутом свитере, без коллег. Мы поинтересовались: возникли ли вопросы по тому, что мы отправили, чтобы мы начали с них, а затем уже рассказали то, что сочли нужным. В ответ мы услышали фразу, которой было суждено стать внутренним мемом: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там».

    Сели и пишем…

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

    Обдумав ситуацию, мы для себя решили, что, вероятно, бизнес и свитеры, будучи в одной точке на графике эффекта Даннинга-Крюгера, нашли друг друга – и потому остались довольны.

    И тут можно сказать: ну ладно, в описанном кейсе вроде все довольны, так что зачем что-либо менять? Соглашусь. А что, если на этом пике («собаку съел») находится лишь одна сторона, а именно – разработка? Как поступать? Заставлять каждого менеджера проекта учиться программировать? Самому, как руководителю от бизнеса, погружаться в технические премудрости?

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

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

    Влияние на взаимодействие внутри ИТ

    Если кажется, что проблема тут – только в коммуникации бизнес-ИТ, а внутри отдела ИТ всё гомогенно, и «если их оставить в покое», то само рассосётся, мне придётся вас разочаровать примером, достаточно типичным.

    Техническая команда собралась по случаю необходимости рефакторинга одного из компонентов на фронтенде. Дальше так было жить нельзя: накладные расходы на выплату процентов по техническому долгу превышали все разумные пределы. Решено было делать рефакторинг. Обсудили план, описали в эпике (работа предстояла объёмная, модифицируемый компонент встречался по всей системе); затем разошлись. Предполагалось, что работа будет завершена через две недели.

    Через месяц было инициировано совещание, на котором оказалось, что непосредственный исполнитель задачи занимается тем, что просто переносит проблему в ещё более глубокий слой React’а. После такого вступления глаза присутствующих округлились и грозили вылезти из орбит.

    Не уверен: то ли рефакторинг сделал мой код более читаемым, то ли я понимаю код лучше, потому что убил на него кучу времени
    Не уверен: то ли рефакторинг сделал мой код более читаемым, то ли я понимаю код лучше, потому что убил на него кучу времени

    А ведь случай не какой-то из ряда вон выходящий: мы же прекрасно знаем, что каждый человек понимает «в меру своей испорченности», переоценивают свои умения, не понимая истинной глубины своей некомпетентности. И значит, что от того, что мы пошли в рефакторинг вместе и его проговорили, ещё не следует вывод, что все поняли план одинаково и будут делать по оговоренному. И ладно бы что-то небольшое, но полтора месяца фронтенд разработчика – дороговато для метакогнитивного искажения. А если не один разработчик, а целый отдел?

    При чём тут диагностика

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

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

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

    • одна ли и та же мотивация у бизнес-сотрудников и технических специалистов (нет и ещё раз нет),

    • одно ли и то же мы понимаем под одинаковыми словами (часто нет),

    • одинаково ли мы воспринимаем и участвуем в одних и тех же командных процессах (ох, нет),

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

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

    Возможность выявить и нивелировать эффект Даннинга-Крюгера – это одна из причин, по которой мы любим услугу диагностики, не единственная, но очень важная и существенная для совместной продуктивной работы ИТ и бизнеса.

    P.S. Если статья была интересна / полезна, поделитесь, пожалуйста, вашим опытом с этим эффектом. Как обнаруживали? Что делали?

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

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

      Документация и код… Ну тут все сказано:
      Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить.

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

      Бизнес вполне логично делает долгосрочную инвестицию. Разработчик вполне логично начинает выяснять соответствие документации коду. И где тут эффект Даннинга-Крюгера?

      Для нахождения общего языка между представителями бизнеса и разработки — заводят переводчика. Как правило это ПМ или лид. Если ПМ хочет реально управлять разработкой, а не водить руками в позиции «передаста» — он должен разбираться в разработке. В противном случае или все развалится как в примере с рефакторингом. Или найдется разработчик который станет договариваться за сроки и бюджеты с бизнесом с одной стороны и фактически управлять разработкой ставя цели и задачи разработчикам с другой стороны.
      Нетехнические люди могут ожидать чего угодно, но получат ровно то, за что платят. И синьор с мидлом которые могут простыми словами донести смысл своей деятельности вполне доступны. Просто стоят значительно дороже синьора с мидлом которые умеют только программировать. Внезапно, правда?

      Суммируя: Эффект Даннинга-Крюгера вообще никак не связан с примерами в статье. Разработчик с сильными техническими и софт скиллами стоит дороже разработчика только с сильными техническими скиллами. Диагностика тут вообще не причем. Менеджер водящий руками в позиции «передаста» и отсутствие разработчика с прокачанными софт скиллами — прямой путь угробить все.
        0

        Я слышал эффект Даннинга-Крюгера в более краткой формулировке: дебил не понимает, что он дебил, потому что дебил. А тот график, что у вас в статье, описывает процесс получения опыта выпускником института и к Эффекту имеет так себе отношение, т.к. игнорирует "неспособность индивида осознавать свои ошибки в силу низкого уровня своей квалификации" (что, в общем-то, и является базисом Эффекта).


        Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от выбранных критериев оценки. "Свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание" — достаточно неплохой критерий отбора, если оценивать его по скорости применения и стоимости. Разумеется, можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба, а отбирать по… А по каким критериям отбирать "приличных сеньоров"? И дадут ли эти критерии результат лучший, чем по "свитеру и аутичности"? Кстати, у вас в статье опущен результат сотрудничества "растянутых свитеров" и бизнеса:


        Уж и не знаю, как дальше продолжалось сотрудничество растянутых свитеров и бизнеса, но начало было так себе.

        Вы бы узнали, может у них всё не так плохо.


        Проблемы в IT с диагностикой способностей разрабов в том, что нет не то, что надёжного, нет даже сколь-нибудь приемлемого метода оценки этих способностей и прогнозирования результатов работы только что собранной команды над произвольной задачей для бизнеса. Более-менее приемлемый результат в оценке кандидатуры может быть в том случае, если кандидатура уже решала задачу, аналогичную требуемой. И чем больше раз решала, тем более точный результат получается. Это называется "типовые задачи" и это не то, что нужно крупному бизнесу. Как правило, такие кандидатуры делают "типовые решения" для класса задач и продают их по оптовой цене. Но если попытаться с этими же командами адаптировать их типовые решения под нетипичные задачи, то результат опять становится непредсказуемым.


        В общем-то, бизнес, по-большому счёту, вынужден либо сам формировать свои IT-отделы из "котов-в-мешках", занимаясь селекцией сотрудников самостоятельно, либо отдавать разработку на аутсорс в крупные IT-компании (агрегаторы), и тогда уже эти агрегаторы ротируют имеющиеся у них кадры (и нанимают новые), распределяя их наилучшим образом между обратившимися к ним бизнесами. Первый путь дольше, но дешевле и с непредсказуемым результатом, второй путь быстрее, но дороже и тоже с непредсказуемым результатом. Сейчас бизнес может выбирать любой из этих двух вариантов, но не может повлиять на предсказуемость результата. Есть ещё вариант — (пере)купить готовую команду, которая уже решила (или почти решила) аналогичную задачу. Но это скорее исключение, чем правило.


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

          +3
          Напишите еще, пожалуйста, о эффекте Даннинга-Крюгера у HR-специалистов.
          Все так уверенно оценивают специалистов в области, в которой только думают, что разбираются, не говоря уже что для оценки сеньора надо быть уровнем не ниже.
            0
            Спасибо за ваш комментарий — он поднимает важный момент с представлением о принципиальном качественном отличии технической деятельности от «что там у всех этих гуманитариев» (потому что иначе объяснить себе присутствие HR-специалистов в первом предложении вашего замечания я не могу: ведь HR — так же не моя область, как консультанта, как и непосредственное написание кода; и потом почему мы исходим из предположения, что HR — в его качественном, профессиональном исполнении — это раз плюнуть? неясно).

            Давайте оставим за бортом позицию «никто, даже заказчики этой же компании, не имеют права оценивать ИТ» как заведомо ведущую к очень тяжёлым последствиям на уровне всей организации от обособления ИТ специалистов в свой мир, максимально оторванный от реальности, в которой существует разрабатываемый ими продукт, до возведения техники в культ и вещь в себе, понятную лишь избранным.
            Также стоит заметить, что здесь мы выводим за скобки те редкие на текущий день отрасли, где можно себе позволить работать по waterfall. Мы говорим в рамках продуктового подхода.

            Давайте вместе посмотрим на аспекты деятельности сеньора, которого вы приводите в качестве примера, чтобы понять есть ли в ней элементы, которые мы — в данном случае консультанты, как правило, с опытом в менеджменте/управлении ИТ, — можем браться диагностировать:

            — непосредственное написание кода в рамках бизнес-задачи поставленной заказчиком.
            Сам код, как вы правильно отметили, мы открыть и оценить не можем — диагностика не код-ревью, мы — не разработчики. Но у нас есть косвенные признаки, собрав которые совместно с самой диагностируемой командой — тут важно отметить, что диагностика без сотрудничества самой команды смысла не имеет, — мы можем составить представление о качестве работы. К примеру, как часто возвращаются задачи конкретного разработчика с этапа ревью или этапа тестирования; насколько учитываются функциональные требования; можем ли мы судить по конечному результату и последующим задачам о том, что идёт закладка на будущее (под масштабирование и прочие штуки).

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

            — консультирование в рамках своей экспертизы. Если мы говорим о сеньоре, то с большой долей вероятности он либо обладает богатой экспертизой в продукте, либо непосредственно отвечает за какую-то часть ИТ ландшафта компании (что не исключает, а дополняет первую опцию). И тогда к такому специалисту по мере необходимости будут обращаться коллеги — возможно, из соседних продуктов / систем компании, либо других департаментов. Мы можем — да, косвенно, но всё же, — судить о ясности понимания своего продукта специалистом и готовности использовать это понимание на пользу компании в целом.

            Есть и другие аспекты деятельности, вероятно не имеет смысла перечислять их все. Мне хотелось донести основную логику: мы оцениваем не непосредственные харды сеньора — как вы правильно заметили, это сделать сложно независимо от профессиональной области (не взялась бы оценивать HR, хоть вы и предлагаете :) ), — мы оцениваем скорее вклад в продукт, в команду, в компанию, эффективность взаимодействий, участие в процессах вокруг продукта и тому подобные вещи, которые интересуют руководство компании или руководителя команды, имеющих намерение выйти на качественно лучший уровень эффективности.

            И здесь касание такой диагностикой эффекта Д-К при составлении многомерного изображения команды является интересным побочным, но приятным бонусом.
            +1

            Такая интерпретация оригинальной работы Д-К это популярное общественное заблуждение. В оригинальной работе худшие студенты чуть завышали свои балы не более того никто ни ставил себя на уровень с хорошистами и отличниками. Наиболее разумное объяснение это просто статистическая ошибка в виде регрессии к среднему. Говоря коротко такого эффекта видимо нету.

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

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое