[Высокая производительность, Управление разработкой, Управление персоналом] Сели и пишем, или что можно сделать с коварством эффекта Даннинга-Крюгера
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом.Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но в чём именно заключается и что делать — неясно.Интересно, что многие англоязычные статьи в поиске ответа на вопрос об основной проблеме ИТ дают достаточно простой и, возможно, не всеми ожидаемый ответ: мы. Да, мы, люди, а не вычислительные мощности, особенности виртуализации или же другие технические возможности, являемся основной проблемой ИТ.Одна из причин, возможно, важнейшая – это эффект Даннинга-Крюгера. Если отразить его на графике, то несложно заметить точку, хорошо знакомую многим по анекдоту про Брежнева: я стар… я супер-стар.
Влияние эффекта Даннинга-Крюгера на восприятие собственного профессионализма; искомая точка находится слева вверхуРазберём на примерах.Взаимодействие «бизнес — ИТ»Некоторое время назад я работала в аутсорсинговой компании, специализирующейся на сложных технологических, нетиповых задачах (нет лэндингам – да автоматизации бизнеса и навороченным приложениям). Наши заказчики нуждались в новых информационных системах, и нашей задачей было создание таких систем, чтобы затем передать их клиенту. Как руководитель проекта я часто была задействована в процессе, состоящем из следующих стадий: бизнес принёс идею → мы её донесли до продуктива → мы помогли заказчику нанять себе внутреннюю команду → мы отдали продуктив этой внутренней команде, чтобы уже её руками продолжался основной цикл жизни продукта, заключающийся в его невзрывном развитии и эксплуатации. То есть совсем просто: запуск → передача.И при найме таких внутренних команд, и при передаче им проектов возникали казусы, которые заставляли меня сильно грустить задуматься о компетенциях всех вовлечённых сторон и об истинных их устремлениях.Ведь кто такой хороший разработчик, если смотреть с точки зрения бизнеса, имеющего дело с ИТ только в виде внешней команды? Как может бизнес судить о том, даёт ему рекрутер хороших кандидатов или нет? Когда нам пошёл поток соискателей на технические собеседования от одного из заказчиков, мы поняли, что критерии отбора до слёз просты: свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание. Все кандидаты были очень похожи по этим параметрам. При этом они просили неимоверные, на наш взгляд, зарплаты за достаточно посредственные навыки.
Утрированный образ «типичного» разработчика глазами бизнесаБудучи в изумлении, мы подсветили вопрос заказчику: знаете, вот за такие деньги, раз уж у вас есть на это бюджет (а можно было бы и опустить планку), можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба. Наше изумление возросло ещё больше, когда мы были поставлены на место: вы просто проверьте их навыки, нечего нам указывать, это – лучшие люди. Ясно, понятно.Двоих-троих таких соискателей наняли, пришло время передавать внутрь достаточно сложный, с кучей особенностей проект. Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить. Мы привыкли при таких передачах доносить все детали, вся информацию, которая пригодится коллегам на старте или будет важной позже, к примеру, при принятии каких-то долгосрочных архитектурных решений.Звонок начался. На том конце был парень в растянутом свитере, без коллег. Мы поинтересовались: возникли ли вопросы по тому, что мы отправили, чтобы мы начали с них, а затем уже рассказали то, что сочли нужным. В ответ мы услышали фразу, которой было суждено стать внутренним мемом: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там».Сели и пишем…Надо ли говорить, что с таким подходом к делу скорость внутренней разработки была существенно ниже, чем до этого. Уж и не знаю, как дальше продолжалось сотрудничество растянутых свитеров и бизнеса, но начало было так себе.Обдумав ситуацию, мы для себя решили, что, вероятно, бизнес и свитеры, будучи в одной точке на графике эффекта Даннинга-Крюгера, нашли друг друга – и потому остались довольны.И тут можно сказать: ну ладно, в описанном кейсе вроде все довольны, так что зачем что-либо менять? Соглашусь. А что, если на этом пике («собаку съел») находится лишь одна сторона, а именно – разработка? Как поступать? Заставлять каждого менеджера проекта учиться программировать? Самому, как руководителю от бизнеса, погружаться в технические премудрости?Такое решение пусть и напрашивается, но на деле слишком дорого и не масштабируемо: если все убегут в «технику», то кто будет заниматься тем основным, ради чего всё затевается, а именно бизнес-ценностью, пониманием потребностей пользователей, позиционированием на рынке и монетизацией? Тут что-то про кухарок и государство, но наоборот получится; не дело.Видится другое, более реалистичное рабочее решение: мы вполне вправе ожидать, что миддл и сеньор разработчик могут простыми словами донести нам, людям не техническим, смысл своей деятельности, трудности, с которыми они сталкиваются, обоснование дороговизны того или иного решения, да и сам выбор решения в конце концов. Тем более, что по мере того, как программирование становится всё более и более верхнеуровневым, то есть отдаляется от управления физическими процессами в железках и приближается к человекопонятному языку, кажется, делать это становится всё проще. А учитывая, что немалая часть технического долга закладывается из-за несостыковок в логической продуманности системы, так и вообще — the must.Влияние на взаимодействие внутри ИТЕсли кажется, что проблема тут – только в коммуникации бизнес-ИТ, а внутри отдела ИТ всё гомогенно, и «если их оставить в покое», то само рассосётся, мне придётся вас разочаровать примером, достаточно типичным.Техническая команда собралась по случаю необходимости рефакторинга одного из компонентов на фронтенде. Дальше так было жить нельзя: накладные расходы на выплату процентов по техническому долгу превышали все разумные пределы. Решено было делать рефакторинг. Обсудили план, описали в эпике (работа предстояла объёмная, модифицируемый компонент встречался по всей системе); затем разошлись. Предполагалось, что работа будет завершена через две недели.Через месяц было инициировано совещание, на котором оказалось, что непосредственный исполнитель задачи занимается тем, что просто переносит проблему в ещё более глубокий слой React’а. После такого вступления глаза присутствующих округлились и грозили вылезти из орбит.
Не уверен: то ли рефакторинг сделал мой код более читаемым, то ли я понимаю код лучше, потому что убил на него кучу времениА ведь случай не какой-то из ряда вон выходящий: мы же прекрасно знаем, что каждый человек понимает «в меру своей испорченности», переоценивают свои умения, не понимая истинной глубины своей некомпетентности. И значит, что от того, что мы пошли в рефакторинг вместе и его проговорили, ещё не следует вывод, что все поняли план одинаково и будут делать по оговоренному. И ладно бы что-то небольшое, но полтора месяца фронтенд разработчика – дороговато для метакогнитивного искажения. А если не один разработчик, а целый отдел?При чём тут диагностикаТут мы выходим на необходимость каким-то образом понимать реальное положение дел у конкретной команды, конкретных сотрудников. Нам мало знать названия языков и аббревиатуры в их резюме, становится важным как-то оценить их положение на графике выше, чтобы скомпенсировать занижение или завышение способностей для нормальной командной работы.По сути, нам надо сделать оценку «360» каждого члена команды не только в разрезе точек зрения, но и в разрезе навыков и умений специалиста. Нам надо понимать не только технический уровень сотрудника, но для определения реального положения дел и возможности конкретных действий по нивелированию эффекта Даннинга-Крюгера нам нужно оценить и коммуникации разработчика, понимание им своей работы, понимание им бизнеса.Проведение такой диагностики сторонними силами позволяет как бизнесу, так и самим техническим командам по сути сделать слепок того, как дела обстоят на текущий момент, посмотреть на это со стороны и решить, что и какими средствами мы хотим исправить.
И коварство эффекта, о котором идёт речь, тут как раз можно обойти. Ведь в обычной, рутинной работе мы часто не успеваем или не имеем повода обсудить метафизику нашей деятельности:
- одна ли и та же мотивация у бизнес-сотрудников и технических специалистов (нет и ещё раз нет),
- одно ли и то же мы понимаем под одинаковыми словами (часто нет),
- одинаково ли мы воспринимаем и участвуем в одних и тех же командных процессах (ох, нет),
- достаточно ли бизнес-технических коммуникаций и подходящая ли у них форма, чтобы не возникало недоразумений с далеко идущими последствиями (если у вас достаточно, пожалуйста, пригласите посмотреть на такое счастье).
В диагностике мы смотрим на команду, её процессы работы, коммуникации внутри и с бизнесом, компетенции членов команды, типичные трудности. Рассматривая артефакты работы, анализируя рабочие процессы с разных сторон, мы стремимся создать наиболее беспристрастную картинку реальности. Чтобы потом обсудить её с командой, как рентгеновский снимок, и решить нужно ли что-то делать и, если да, то каков план этих действий.Возможность выявить и нивелировать эффект Даннинга-Крюгера – это одна из причин, по которой мы любим услугу диагностики, не единственная, но очень важная и существенная для совместной продуктивной работы ИТ и бизнеса.P.S. Если статья была интересна / полезна, поделитесь, пожалуйста, вашим опытом с этим эффектом. Как обнаруживали? Что делали?
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Управление проектами, Управление персоналом, Карьера в IT-индустрии] Почему большинство программистов оказываются посредственными техлидами (перевод)
- [Управление разработкой, Управление персоналом, Конференции, Интервью] TeamLead Conf 2021: последствия коронавируса, удаленка и доклады не только про IT
- [IT-инфраструктура, Управление продуктом, Микросервисы] Как быстро и легко интегрироваться с Active Directory
- [Управление разработкой, Управление проектами, Agile, Управление персоналом] Эмпирические законы человеческого поведения в Scrum
- [Управление проектами, Карьера в IT-индустрии, Офисы IT-компаний] Меня запомните весёлым, а завтра я начну проект. 10 вредных советов для РМ
- [Управление разработкой, Управление проектами, Карьера в IT-индустрии, Бизнес-модели] Бережливый стартап или как мы используем концепцию Lean Startup в своих проектах
- [Управление персоналом, Карьера в IT-индустрии] Комплимент всем разработчикам (четыре СПАСИБО)
- [Управление проектами, Управление персоналом, Облачные сервисы, IT-компании] Сервис Yandex Tracker стал частью облачной платформы «Яндекса»
- [Высокая производительность, Смартфоны, Ноутбуки, Процессоры] Qualcomm Snapdragon 888 лучше A14 Bionic и M1: Объясняем
- [Управление разработкой, Управление продуктом] Масштабируем продакт-менеджмент, часть 2: продукт
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_effekt_danningakrjugera (эффект даннинга-крюгера), #_diagnostika (диагностика), #_konsultirovanie (консультирование), #_upravlenie (управление), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 14-Май 18:27
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом.Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но в чём именно заключается и что делать — неясно.Интересно, что многие англоязычные статьи в поиске ответа на вопрос об основной проблеме ИТ дают достаточно простой и, возможно, не всеми ожидаемый ответ: мы. Да, мы, люди, а не вычислительные мощности, особенности виртуализации или же другие технические возможности, являемся основной проблемой ИТ.Одна из причин, возможно, важнейшая – это эффект Даннинга-Крюгера. Если отразить его на графике, то несложно заметить точку, хорошо знакомую многим по анекдоту про Брежнева: я стар… я супер-стар.  Влияние эффекта Даннинга-Крюгера на восприятие собственного профессионализма; искомая точка находится слева вверхуРазберём на примерах.Взаимодействие «бизнес — ИТ»Некоторое время назад я работала в аутсорсинговой компании, специализирующейся на сложных технологических, нетиповых задачах (нет лэндингам – да автоматизации бизнеса и навороченным приложениям). Наши заказчики нуждались в новых информационных системах, и нашей задачей было создание таких систем, чтобы затем передать их клиенту. Как руководитель проекта я часто была задействована в процессе, состоящем из следующих стадий: бизнес принёс идею → мы её донесли до продуктива → мы помогли заказчику нанять себе внутреннюю команду → мы отдали продуктив этой внутренней команде, чтобы уже её руками продолжался основной цикл жизни продукта, заключающийся в его невзрывном развитии и эксплуатации. То есть совсем просто: запуск → передача.И при найме таких внутренних команд, и при передаче им проектов возникали казусы, которые заставляли меня сильно грустить задуматься о компетенциях всех вовлечённых сторон и об истинных их устремлениях.Ведь кто такой хороший разработчик, если смотреть с точки зрения бизнеса, имеющего дело с ИТ только в виде внешней команды? Как может бизнес судить о том, даёт ему рекрутер хороших кандидатов или нет? Когда нам пошёл поток соискателей на технические собеседования от одного из заказчиков, мы поняли, что критерии отбора до слёз просты: свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание. Все кандидаты были очень похожи по этим параметрам. При этом они просили неимоверные, на наш взгляд, зарплаты за достаточно посредственные навыки.  Утрированный образ «типичного» разработчика глазами бизнесаБудучи в изумлении, мы подсветили вопрос заказчику: знаете, вот за такие деньги, раз уж у вас есть на это бюджет (а можно было бы и опустить планку), можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба. Наше изумление возросло ещё больше, когда мы были поставлены на место: вы просто проверьте их навыки, нечего нам указывать, это – лучшие люди. Ясно, понятно.Двоих-троих таких соискателей наняли, пришло время передавать внутрь достаточно сложный, с кучей особенностей проект. Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить. Мы привыкли при таких передачах доносить все детали, вся информацию, которая пригодится коллегам на старте или будет важной позже, к примеру, при принятии каких-то долгосрочных архитектурных решений.Звонок начался. На том конце был парень в растянутом свитере, без коллег. Мы поинтересовались: возникли ли вопросы по тому, что мы отправили, чтобы мы начали с них, а затем уже рассказали то, что сочли нужным. В ответ мы услышали фразу, которой было суждено стать внутренним мемом: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там».Сели и пишем…Надо ли говорить, что с таким подходом к делу скорость внутренней разработки была существенно ниже, чем до этого. Уж и не знаю, как дальше продолжалось сотрудничество растянутых свитеров и бизнеса, но начало было так себе.Обдумав ситуацию, мы для себя решили, что, вероятно, бизнес и свитеры, будучи в одной точке на графике эффекта Даннинга-Крюгера, нашли друг друга – и потому остались довольны.И тут можно сказать: ну ладно, в описанном кейсе вроде все довольны, так что зачем что-либо менять? Соглашусь. А что, если на этом пике («собаку съел») находится лишь одна сторона, а именно – разработка? Как поступать? Заставлять каждого менеджера проекта учиться программировать? Самому, как руководителю от бизнеса, погружаться в технические премудрости?Такое решение пусть и напрашивается, но на деле слишком дорого и не масштабируемо: если все убегут в «технику», то кто будет заниматься тем основным, ради чего всё затевается, а именно бизнес-ценностью, пониманием потребностей пользователей, позиционированием на рынке и монетизацией? Тут что-то про кухарок и государство, но наоборот получится; не дело.Видится другое, более реалистичное рабочее решение: мы вполне вправе ожидать, что миддл и сеньор разработчик могут простыми словами донести нам, людям не техническим, смысл своей деятельности, трудности, с которыми они сталкиваются, обоснование дороговизны того или иного решения, да и сам выбор решения в конце концов. Тем более, что по мере того, как программирование становится всё более и более верхнеуровневым, то есть отдаляется от управления физическими процессами в железках и приближается к человекопонятному языку, кажется, делать это становится всё проще. А учитывая, что немалая часть технического долга закладывается из-за несостыковок в логической продуманности системы, так и вообще — the must.Влияние на взаимодействие внутри ИТЕсли кажется, что проблема тут – только в коммуникации бизнес-ИТ, а внутри отдела ИТ всё гомогенно, и «если их оставить в покое», то само рассосётся, мне придётся вас разочаровать примером, достаточно типичным.Техническая команда собралась по случаю необходимости рефакторинга одного из компонентов на фронтенде. Дальше так было жить нельзя: накладные расходы на выплату процентов по техническому долгу превышали все разумные пределы. Решено было делать рефакторинг. Обсудили план, описали в эпике (работа предстояла объёмная, модифицируемый компонент встречался по всей системе); затем разошлись. Предполагалось, что работа будет завершена через две недели.Через месяц было инициировано совещание, на котором оказалось, что непосредственный исполнитель задачи занимается тем, что просто переносит проблему в ещё более глубокий слой React’а. После такого вступления глаза присутствующих округлились и грозили вылезти из орбит.  Не уверен: то ли рефакторинг сделал мой код более читаемым, то ли я понимаю код лучше, потому что убил на него кучу времениА ведь случай не какой-то из ряда вон выходящий: мы же прекрасно знаем, что каждый человек понимает «в меру своей испорченности», переоценивают свои умения, не понимая истинной глубины своей некомпетентности. И значит, что от того, что мы пошли в рефакторинг вместе и его проговорили, ещё не следует вывод, что все поняли план одинаково и будут делать по оговоренному. И ладно бы что-то небольшое, но полтора месяца фронтенд разработчика – дороговато для метакогнитивного искажения. А если не один разработчик, а целый отдел?При чём тут диагностикаТут мы выходим на необходимость каким-то образом понимать реальное положение дел у конкретной команды, конкретных сотрудников. Нам мало знать названия языков и аббревиатуры в их резюме, становится важным как-то оценить их положение на графике выше, чтобы скомпенсировать занижение или завышение способностей для нормальной командной работы.По сути, нам надо сделать оценку «360» каждого члена команды не только в разрезе точек зрения, но и в разрезе навыков и умений специалиста. Нам надо понимать не только технический уровень сотрудника, но для определения реального положения дел и возможности конкретных действий по нивелированию эффекта Даннинга-Крюгера нам нужно оценить и коммуникации разработчика, понимание им своей работы, понимание им бизнеса.Проведение такой диагностики сторонними силами позволяет как бизнесу, так и самим техническим командам по сути сделать слепок того, как дела обстоят на текущий момент, посмотреть на это со стороны и решить, что и какими средствами мы хотим исправить. И коварство эффекта, о котором идёт речь, тут как раз можно обойти. Ведь в обычной, рутинной работе мы часто не успеваем или не имеем повода обсудить метафизику нашей деятельности:
=========== Источник: habr.com =========== Похожие новости:
Высокая производительность ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 14-Май 18:27
Часовой пояс: UTC + 5