Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом.
Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но в чём именно заключается и что делать — неясно.
Интересно, что многие англоязычные статьи в поиске ответа на вопрос об основной проблеме ИТ дают достаточно простой и, возможно, не всеми ожидаемый ответ: мы. Да, мы, люди, а не вычислительные мощности, особенности виртуализации или же другие технические возможности, являемся основной проблемой ИТ.
Одна из причин, возможно, важнейшая – это эффект Даннинга-Крюгера. Если отразить его на графике, то несложно заметить точку, хорошо знакомую многим по анекдоту про Брежнева: я стар… я супер-стар.
Разберём на примерах.
Взаимодействие «бизнес — ИТ»
Некоторое время назад я работала в аутсорсинговой компании, специализирующейся на сложных технологических, нетиповых задачах (нет лэндингам – да автоматизации бизнеса и навороченным приложениям). Наши заказчики нуждались в новых информационных системах, и нашей задачей было создание таких систем, чтобы затем передать их клиенту. Как руководитель проекта я часто была задействована в процессе, состоящем из следующих стадий: бизнес принёс идею → мы её донесли до продуктива → мы помогли заказчику нанять себе внутреннюю команду → мы отдали продуктив этой внутренней команде, чтобы уже её руками продолжался основной цикл жизни продукта, заключающийся в его невзрывном развитии и эксплуатации. То есть совсем просто: запуск → передача.
И при найме таких внутренних команд, и при передаче им проектов возникали казусы, которые заставляли меня сильно грустить задуматься о компетенциях всех вовлечённых сторон и об истинных их устремлениях.
Ведь кто такой хороший разработчик, если смотреть с точки зрения бизнеса, имеющего дело с ИТ только в виде внешней команды? Как может бизнес судить о том, даёт ему рекрутер хороших кандидатов или нет? Когда нам пошёл поток соискателей на технические собеседования от одного из заказчиков, мы поняли, что критерии отбора до слёз просты: свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание. Все кандидаты были очень похожи по этим параметрам. При этом они просили неимоверные, на наш взгляд, зарплаты за достаточно посредственные навыки.
Будучи в изумлении, мы подсветили вопрос заказчику: знаете, вот за такие деньги, раз уж у вас есть на это бюджет (а можно было бы и опустить планку), можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба. Наше изумление возросло ещё больше, когда мы были поставлены на место: вы просто проверьте их навыки, нечего нам указывать, это – лучшие люди. Ясно, понятно.
Двоих-троих таких соискателей наняли, пришло время передавать внутрь достаточно сложный, с кучей особенностей проект. Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить. Мы привыкли при таких передачах доносить все детали, вся информацию, которая пригодится коллегам на старте или будет важной позже, к примеру, при принятии каких-то долгосрочных архитектурных решений.
Звонок начался. На том конце был парень в растянутом свитере, без коллег. Мы поинтересовались: возникли ли вопросы по тому, что мы отправили, чтобы мы начали с них, а затем уже рассказали то, что сочли нужным. В ответ мы услышали фразу, которой было суждено стать внутренним мемом: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там».
Сели и пишем…
Надо ли говорить, что с таким подходом к делу скорость внутренней разработки была существенно ниже, чем до этого. Уж и не знаю, как дальше продолжалось сотрудничество растянутых свитеров и бизнеса, но начало было так себе.
Обдумав ситуацию, мы для себя решили, что, вероятно, бизнес и свитеры, будучи в одной точке на графике эффекта Даннинга-Крюгера, нашли друг друга – и потому остались довольны.
И тут можно сказать: ну ладно, в описанном кейсе вроде все довольны, так что зачем что-либо менять? Соглашусь. А что, если на этом пике («собаку съел») находится лишь одна сторона, а именно – разработка? Как поступать? Заставлять каждого менеджера проекта учиться программировать? Самому, как руководителю от бизнеса, погружаться в технические премудрости?
Такое решение пусть и напрашивается, но на деле слишком дорого и не масштабируемо: если все убегут в «технику», то кто будет заниматься тем основным, ради чего всё затевается, а именно бизнес-ценностью, пониманием потребностей пользователей, позиционированием на рынке и монетизацией? Тут что-то про кухарок и государство, но наоборот получится; не дело.
Видится другое, более реалистичное рабочее решение: мы вполне вправе ожидать, что миддл и сеньор разработчик могут простыми словами донести нам, людям не техническим, смысл своей деятельности, трудности, с которыми они сталкиваются, обоснование дороговизны того или иного решения, да и сам выбор решения в конце концов. Тем более, что по мере того, как программирование становится всё более и более верхнеуровневым, то есть отдаляется от управления физическими процессами в железках и приближается к человекопонятному языку, кажется, делать это становится всё проще. А учитывая, что немалая часть технического долга закладывается из-за несостыковок в логической продуманности системы, так и вообще — the must.
Влияние на взаимодействие внутри ИТ
Если кажется, что проблема тут – только в коммуникации бизнес-ИТ, а внутри отдела ИТ всё гомогенно, и «если их оставить в покое», то само рассосётся, мне придётся вас разочаровать примером, достаточно типичным.
Техническая команда собралась по случаю необходимости рефакторинга одного из компонентов на фронтенде. Дальше так было жить нельзя: накладные расходы на выплату процентов по техническому долгу превышали все разумные пределы. Решено было делать рефакторинг. Обсудили план, описали в эпике (работа предстояла объёмная, модифицируемый компонент встречался по всей системе); затем разошлись. Предполагалось, что работа будет завершена через две недели.
Через месяц было инициировано совещание, на котором оказалось, что непосредственный исполнитель задачи занимается тем, что просто переносит проблему в ещё более глубокий слой React’а. После такого вступления глаза присутствующих округлились и грозили вылезти из орбит.
А ведь случай не какой-то из ряда вон выходящий: мы же прекрасно знаем, что каждый человек понимает «в меру своей испорченности», переоценивают свои умения, не понимая истинной глубины своей некомпетентности. И значит, что от того, что мы пошли в рефакторинг вместе и его проговорили, ещё не следует вывод, что все поняли план одинаково и будут делать по оговоренному. И ладно бы что-то небольшое, но полтора месяца фронтенд разработчика – дороговато для метакогнитивного искажения. А если не один разработчик, а целый отдел?
При чём тут диагностика
Тут мы выходим на необходимость каким-то образом понимать реальное положение дел у конкретной команды, конкретных сотрудников. Нам мало знать названия языков и аббревиатуры в их резюме, становится важным как-то оценить их положение на графике выше, чтобы скомпенсировать занижение или завышение способностей для нормальной командной работы.
По сути, нам надо сделать оценку «360» каждого члена команды не только в разрезе точек зрения, но и в разрезе навыков и умений специалиста. Нам надо понимать не только технический уровень сотрудника, но для определения реального положения дел и возможности конкретных действий по нивелированию эффекта Даннинга-Крюгера нам нужно оценить и коммуникации разработчика, понимание им своей работы, понимание им бизнеса.
Проведение такой диагностики сторонними силами позволяет как бизнесу, так и самим техническим командам по сути сделать слепок того, как дела обстоят на текущий момент, посмотреть на это со стороны и решить, что и какими средствами мы хотим исправить.
И коварство эффекта, о котором идёт речь, тут как раз можно обойти. Ведь в обычной, рутинной работе мы часто не успеваем или не имеем повода обсудить метафизику нашей деятельности:
одна ли и та же мотивация у бизнес-сотрудников и технических специалистов (нет и ещё раз нет),
одно ли и то же мы понимаем под одинаковыми словами (часто нет),
одинаково ли мы воспринимаем и участвуем в одних и тех же командных процессах (ох, нет),
достаточно ли бизнес-технических коммуникаций и подходящая ли у них форма, чтобы не возникало недоразумений с далеко идущими последствиями (если у вас достаточно, пожалуйста, пригласите посмотреть на такое счастье).
В диагностике мы смотрим на команду, её процессы работы, коммуникации внутри и с бизнесом, компетенции членов команды, типичные трудности. Рассматривая артефакты работы, анализируя рабочие процессы с разных сторон, мы стремимся создать наиболее беспристрастную картинку реальности. Чтобы потом обсудить её с командой, как рентгеновский снимок, и решить нужно ли что-то делать и, если да, то каков план этих действий.
Возможность выявить и нивелировать эффект Даннинга-Крюгера – это одна из причин, по которой мы любим услугу диагностики, не единственная, но очень важная и существенная для совместной продуктивной работы ИТ и бизнеса.
P.S. Если статья была интересна / полезна, поделитесь, пожалуйста, вашим опытом с этим эффектом. Как обнаруживали? Что делали?
