Comments 6
Опытному синьору совсем не интересно работать на поддержке продукта. В принципе можно завалить эту проблему деньгами, но это сработает только в краткосрочной перспективе, значит будет бешеная ротация персонала. И тут умный но испытывающий проблемы с социализацией и самооценкой кадр, который будет работать годами — выглядит вполне неплохим вложением.
Документация и код… Ну тут все сказано:
Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить.
Детали и особенности, да, которые в результате приводят к тому, что документация находится в состоянии от «не совсем соответствует» до «совсем не соответствует». Так что садимся и пишем.
Ну и вопрос — сколько времени прошло между отправкой документации и митингом и сколько времени занимал внутренний онбординг под руководством лида? Из моего опыта — даже принимая одну компоненту сложной системы от соседней команды можно потратить больше месяца на вхождение. Это имея доступ к коду, сидящим в соседнем кабинете разработчикам и заранее зная общие для системы принципы и решения.
Бизнес вполне логично делает долгосрочную инвестицию. Разработчик вполне логично начинает выяснять соответствие документации коду. И где тут эффект Даннинга-Крюгера?
Для нахождения общего языка между представителями бизнеса и разработки — заводят переводчика. Как правило это ПМ или лид. Если ПМ хочет реально управлять разработкой, а не водить руками в позиции «передаста» — он должен разбираться в разработке. В противном случае или все развалится как в примере с рефакторингом. Или найдется разработчик который станет договариваться за сроки и бюджеты с бизнесом с одной стороны и фактически управлять разработкой ставя цели и задачи разработчикам с другой стороны.
Нетехнические люди могут ожидать чего угодно, но получат ровно то, за что платят. И синьор с мидлом которые могут простыми словами донести смысл своей деятельности вполне доступны. Просто стоят значительно дороже синьора с мидлом которые умеют только программировать. Внезапно, правда?
Суммируя: Эффект Даннинга-Крюгера вообще никак не связан с примерами в статье. Разработчик с сильными техническими и софт скиллами стоит дороже разработчика только с сильными техническими скиллами. Диагностика тут вообще не причем. Менеджер водящий руками в позиции «передаста» и отсутствие разработчика с прокачанными софт скиллами — прямой путь угробить все.
Я слышал эффект Даннинга-Крюгера в более краткой формулировке: дебил не понимает, что он дебил, потому что дебил. А тот график, что у вас в статье, описывает процесс получения опыта выпускником института и к Эффекту имеет так себе отношение, т.к. игнорирует "неспособность индивида осознавать свои ошибки в силу низкого уровня своей квалификации" (что, в общем-то, и является базисом Эффекта).
Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от выбранных критериев оценки. "Свитер или потёртая рубашка, некая аутичность во взгляде и задумчивое молчание" — достаточно неплохой критерий отбора, если оценивать его по скорости применения и стоимости. Разумеется, можно нанять приличных сеньоров, если не отбирать людей по степени растянутости гардероба, а отбирать по… А по каким критериям отбирать "приличных сеньоров"? И дадут ли эти критерии результат лучший, чем по "свитеру и аутичности"? Кстати, у вас в статье опущен результат сотрудничества "растянутых свитеров" и бизнеса:
Уж и не знаю, как дальше продолжалось сотрудничество растянутых свитеров и бизнеса, но начало было так себе.
Вы бы узнали, может у них всё не так плохо.
Проблемы в IT с диагностикой способностей разрабов в том, что нет не то, что надёжного, нет даже сколь-нибудь приемлемого метода оценки этих способностей и прогнозирования результатов работы только что собранной команды над произвольной задачей для бизнеса. Более-менее приемлемый результат в оценке кандидатуры может быть в том случае, если кандидатура уже решала задачу, аналогичную требуемой. И чем больше раз решала, тем более точный результат получается. Это называется "типовые задачи" и это не то, что нужно крупному бизнесу. Как правило, такие кандидатуры делают "типовые решения" для класса задач и продают их по оптовой цене. Но если попытаться с этими же командами адаптировать их типовые решения под нетипичные задачи, то результат опять становится непредсказуемым.
В общем-то, бизнес, по-большому счёту, вынужден либо сам формировать свои IT-отделы из "котов-в-мешках", занимаясь селекцией сотрудников самостоятельно, либо отдавать разработку на аутсорс в крупные IT-компании (агрегаторы), и тогда уже эти агрегаторы ротируют имеющиеся у них кадры (и нанимают новые), распределяя их наилучшим образом между обратившимися к ним бизнесами. Первый путь дольше, но дешевле и с непредсказуемым результатом, второй путь быстрее, но дороже и тоже с непредсказуемым результатом. Сейчас бизнес может выбирать любой из этих двух вариантов, но не может повлиять на предсказуемость результата. Есть ещё вариант — (пере)купить готовую команду, которая уже решила (или почти решила) аналогичную задачу. Но это скорее исключение, чем правило.
Если у вас есть работающие методы диагностики, позволяющие определить потенциал команд разработчиков и их способность к решению конкретных задач, поставленных перед ними бизнесом, то вы сможете очень сильно изменить нынешнее лицо IT-индустрии.
Все так уверенно оценивают специалистов в области, в которой только думают, что разбираются, не говоря уже что для оценки сеньора надо быть уровнем не ниже.
Давайте оставим за бортом позицию «никто, даже заказчики этой же компании, не имеют права оценивать ИТ» как заведомо ведущую к очень тяжёлым последствиям на уровне всей организации от обособления ИТ специалистов в свой мир, максимально оторванный от реальности, в которой существует разрабатываемый ими продукт, до возведения техники в культ и вещь в себе, понятную лишь избранным.
Также стоит заметить, что здесь мы выводим за скобки те редкие на текущий день отрасли, где можно себе позволить работать по waterfall. Мы говорим в рамках продуктового подхода.
Давайте вместе посмотрим на аспекты деятельности сеньора, которого вы приводите в качестве примера, чтобы понять есть ли в ней элементы, которые мы — в данном случае консультанты, как правило, с опытом в менеджменте/управлении ИТ, — можем браться диагностировать:
— непосредственное написание кода в рамках бизнес-задачи поставленной заказчиком.
Сам код, как вы правильно отметили, мы открыть и оценить не можем — диагностика не код-ревью, мы — не разработчики. Но у нас есть косвенные признаки, собрав которые совместно с самой диагностируемой командой — тут важно отметить, что диагностика без сотрудничества самой команды смысла не имеет, — мы можем составить представление о качестве работы. К примеру, как часто возвращаются задачи конкретного разработчика с этапа ревью или этапа тестирования; насколько учитываются функциональные требования; можем ли мы судить по конечному результату и последующим задачам о том, что идёт закладка на будущее (под масштабирование и прочие штуки).
— приёмка требований от бизнеса. На исторических данных мы вполне можем проанализировать насколько эффективно происходит процесс передачи требований и какую роль в нём играет разработчик: это могут быть примеры конкретных бизнес задач, на которых мы можем увидеть было ли сделано всё для сохранения основной ценности или что-то потерялось; насколько приёмка в команду оформлена в процесс; проявила ли команда или конкретный разработчик критерии, на основании которых бизнес может понять, что вот — штука готова к занесению в команду и т.п.
— консультирование в рамках своей экспертизы. Если мы говорим о сеньоре, то с большой долей вероятности он либо обладает богатой экспертизой в продукте, либо непосредственно отвечает за какую-то часть ИТ ландшафта компании (что не исключает, а дополняет первую опцию). И тогда к такому специалисту по мере необходимости будут обращаться коллеги — возможно, из соседних продуктов / систем компании, либо других департаментов. Мы можем — да, косвенно, но всё же, — судить о ясности понимания своего продукта специалистом и готовности использовать это понимание на пользу компании в целом.
Есть и другие аспекты деятельности, вероятно не имеет смысла перечислять их все. Мне хотелось донести основную логику: мы оцениваем не непосредственные харды сеньора — как вы правильно заметили, это сделать сложно независимо от профессиональной области (не взялась бы оценивать HR, хоть вы и предлагаете :) ), — мы оцениваем скорее вклад в продукт, в команду, в компанию, эффективность взаимодействий, участие в процессах вокруг продукта и тому подобные вещи, которые интересуют руководство компании или руководителя команды, имеющих намерение выйти на качественно лучший уровень эффективности.
И здесь касание такой диагностикой эффекта Д-К при составлении многомерного изображения команды является интересным побочным, но приятным бонусом.
Такая интерпретация оригинальной работы Д-К это популярное общественное заблуждение. В оригинальной работе худшие студенты чуть завышали свои балы не более того никто ни ставил себя на уровень с хорошистами и отличниками. Наиболее разумное объяснение это просто статистическая ошибка в виде регрессии к среднему. Говоря коротко такого эффекта видимо нету.
Вопрос с существованием эффекта, имхо, куда более фундаментальный и требует детального научного исследования, а не формата статьи. То есть возможно это исследование надо повторить, углубив его и перенеся из лабораторий со студентами куда-то в реалии жизни вокруг нас. С этим соглашусь.
Сели и пишем, или что можно сделать с коварством эффекта Даннинга-Крюгера