Pull to refresh

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

Reading time 6 min
Views 11K

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сели и пишем…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags:
Hubs:
+5
Comments 6
Comments Comments 6

Articles