По результатам аппрайзала скорее происходила синхронизация оценки деятельности работника между работником и руководителем. Скорее всего это делалось для предотвращения состояний «я вджобываю, а меня не ценят» и «да этот бездельник нифига не делает, только формочки по шаблону клепает». На аппрайзале сразу такие вещи выявлялись — и работник видит что его активность в определенной области видят и ценят и в тоже время ожидают еще действий в других областях. И руководитель имеет последний шанс показать, что он ожидает и выяснить — почему работник этого не делает. Возможно не знает или не умеет — и можно выставлять цели на обучение, определяться с действиями. А может и не хочет — ну так пусть это HR зафиксирует и подыскивает более подходящий проект/команду. Заставить в этой области не работает, так что не хочешь делать — нафиг с пляжа.
Приколы и там были — ну типа новый менеджер где-то повыше хочет внедрить риск менеджмент и собирает со всех вплоть до джунов возможные риски. Думаю самый популярный вариант был попасть под автобус. Или хочет получать на почту ежедневные отчеты от каждого работника. В аутсорсере. Ему наверно через пару месяцев рассказали, как формируются счета для киентов и где можно посмотреть дейлики.
Сталкивался в крупном аутсорсере — впечаления сильно отличаются от приведенных в статье. Максимум «ужас», но никак не «ужас-ужас».
Формальная процедура, никакой ламповости и нейронной сети распределенной в мозгах менеджеров.
Участники: HR в роли секретаря/модератора, ПМ, лид, разработчик. Для лида — HR собирает фидбек от членов команды и анонимизирует его. Перед процедурой все участники заполняют таблицу оценок активностей. HR сводит все в один документ и во время процедуры обсуждаются оценки. Результирующая оценка идет в итоговую колонку. Так что обсуждаются в основном расходящиеся оценки. В колонку итоговых комментов вписываются договоренности достигнутые на митинге.
На выходе все участники получают копию заполненной таблицы. Так что сам по себе процесс — просто возможность привести оценки руководителя и подчиненного к общему знаменателю и зафиксировать при участии независимой третьей стороны.
Если я правильно помню, таблицы активностей для профилей не менялись много лет или менялись минимально. Активности были усредненные — типа кодинг, код ревью, участие в митингах с заказчиками и т.п. При повышении грейда добавлялись детали — джуну было достаточно сидеть на митинге пассив листенером, мидлу уже надо было активно участвовать, синьору неплохо было бы подготовить агенду, модерировать митинг и выслать митинг минетс вдобавок к активному участию для получения высшей оценки.
Насколько я понимаю, присутствие HR и создание в процессе артефакта — выступало сдерживающим фактором для всяких нехороших вещей.
Готовые таблицы для следующего грейда — позволяли подготовиться к промоушину, показывая, что надо будет делать на регулярной основе после повышения.
Performance review — это то же самое что и performance appraisal? Или нет? Со вторым однозначно сталкивался. А вот первого не припомню. Ну и впечаления сильно отличаются.
«Звезды» вообще то, для нормального руководителя, точно такие же инструменты как и «зануды-педанты» и «обычные середнячки». И при правильном использовании выступают в качестве преимущества. Но вот когда руководитель считает своей основной функцией погонять ленивых «гребцов», а главным инструментом — кнут. То при столкновении со «звездами» случаются казусы типа «из хлыста сделал погонщику хвост и удалился в закат чтобы поработать в гетеросексуальном коллективе». P.S. Текст усыпанный болдом выглядит вырвиглазно и глупо, хуже только раскрашивание в разные цвета.
Такс, ну давайте по порядку.
Опытному синьору совсем не интересно работать на поддержке продукта. В принципе можно завалить эту проблему деньгами, но это сработает только в краткосрочной перспективе, значит будет бешеная ротация персонала. И тут умный но испытывающий проблемы с социализацией и самооценкой кадр, который будет работать годами — выглядит вполне неплохим вложением.
Документация и код… Ну тут все сказано:
Для начала мы выслали документацию, дали все необходимые доступы чтобы уже на созвоне добавить необходимые детали и особенности. Встреча была назначена на час, и мы с техническим лидом проекта волновались, что его может не хватить.
Детали и особенности, да, которые в результате приводят к тому, что документация находится в состоянии от «не совсем соответствует» до «совсем не соответствует». Так что садимся и пишем.
Ну и вопрос — сколько времени прошло между отправкой документации и митингом и сколько времени занимал внутренний онбординг под руководством лида? Из моего опыта — даже принимая одну компоненту сложной системы от соседней команды можно потратить больше месяца на вхождение. Это имея доступ к коду, сидящим в соседнем кабинете разработчикам и заранее зная общие для системы принципы и решения.
Бизнес вполне логично делает долгосрочную инвестицию. Разработчик вполне логично начинает выяснять соответствие документации коду. И где тут эффект Даннинга-Крюгера?
Для нахождения общего языка между представителями бизнеса и разработки — заводят переводчика. Как правило это ПМ или лид. Если ПМ хочет реально управлять разработкой, а не водить руками в позиции «передаста» — он должен разбираться в разработке. В противном случае или все развалится как в примере с рефакторингом. Или найдется разработчик который станет договариваться за сроки и бюджеты с бизнесом с одной стороны и фактически управлять разработкой ставя цели и задачи разработчикам с другой стороны.
Нетехнические люди могут ожидать чего угодно, но получат ровно то, за что платят. И синьор с мидлом которые могут простыми словами донести смысл своей деятельности вполне доступны. Просто стоят значительно дороже синьора с мидлом которые умеют только программировать. Внезапно, правда?
Суммируя: Эффект Даннинга-Крюгера вообще никак не связан с примерами в статье. Разработчик с сильными техническими и софт скиллами стоит дороже разработчика только с сильными техническими скиллами. Диагностика тут вообще не причем. Менеджер водящий руками в позиции «передаста» и отсутствие разработчика с прокачанными софт скиллами — прямой путь угробить все.
Идеология — нафиг не нужна. Достаточно нормальной конкуренции. Тогда и опричники будут не нужны — конкуренты порвут совершившего ошибку без дополнительной помощи. Управлять стаей конкурирущих хищников-каннибалов (ничего личного, это просто бизнес...) на порядки сложнее, чем единственным гигантом-монополистом (партия сказала — надо, комсомол ответил — есть...). Зато зарастать жиром до полной недееспособности хищники не смогут в принципе — максимум до состояния «бежать, чтобы оставаться на месте» (привет КровавАму Ынтерпрайзу).
Лабораторная по информатике? Или как оно там сейчас в школе называется? Код выглядит как порт с Паскаля, да еще и сделанный влоб… Я не говорю про Лас-Вегас, азартные игры и женщин легкого поведения — ну там дополнительные состояния, третье и больше измерение, затейливая геометрия пространства. Я не говорю про то, что в Python массивы таки есть (и встроенный array и продвинутый в numpy), что можно использовать словарь с ключами-таплами или объекты. Но! Не нарезать код даже на функции… При этом оставить комментарии, по которым в первом приближении можно выделить блоки кода в отдельные функции…
До ручной проверки стиля, неплохо прогнать линтер для формальной проверки. И тесты тоже — ну чтобы убедиться, что код работает и вообще делает то, что нужно. Да и каверадж зачастую узнать тоже не лишне — нет ли кода который вообще не используется.
Так что я бы хотел видеть следующее. Ссылку на инструмент код-ревью в котором можно быстро и просто оставить комментарий к конкретной строке. Саммари тестов и ссылку на детальный отчет по выполнению тестов. Саммари кавераджа и ссылку на детальный отчет кавераджа. Саммари линтера и ссылку на детальный отчет линтера.
Не ПО, а исходники. А для работы с исходниками уже давным-давно существуют бесплатные инструменты, очень сильно упрощающие жизнь. VCS, CI, test automation tools — все вместе здорово экономит время, автоматизируя рутинные действия.
Эммм. Никого не смутило, что в 2020 году студенты присылают преподавателю код в архивах? И, как я могу предположить, преподаватель проверяет код вручную?
Бо мне аж как-то неудобно заглядывать в свой домашний инстанс гитлаба — он же ж не только тесты, но и линтер с кавераджем гоняет при изменении кода. А в ведущих столичных университетах вона оно как.
Что-то мне такое вспоминается, связанное с бревном и глазом…
Это все прикольно конечно, но пропиетарные игрища закончатся скорее всего когда китайцы на мини-экскаватор типа «самоходная табуретка с тентаклем» прикрутят удаленное управление.
Пример самоходной табуретки с тентаклем
Вот тут-то всем производителям роботов-манипуляторов и поплохеет. Зато будет хоть какой-то прогресс — и над софтом поработают и над эргономикой пульта подумают. Ну просто от балды — 6 степеней свободы это всего 3 джойстика — например палка, на ней грибок под большой палец и грибок под указательный — вот вам и три джойстика в одной руке. Мега сложный анализ однако.
Техническую книгу люди покупают в поисках информации. Но с приходом в нашу жизнь персональных компьютеров и интернета — появились более удобные и дешевые способы получения информации. Так что сейчас издательствам приходится адаптироваться и выбирать дальнейший путь — стать оператором информационного хаба с дополнительной функцией производства информационных артефактов или стать производителем премиальных артефактов с дополнительной функцией информационного оператора. Хотя первым, наверное, проще стать ресурсу типа Хабра, чем издательсту — подкрутить авторское соглашение да добавить отдел предпечатной подговки.
Прикольно, когда люди путают стоицизм и сужение поля восприятия в результате перегрузки мозга. Но вообще образ рассеянного ученого появился еще до возникновения IT. Причина одна — перегрузка мозга, в результате которой в широком спектре ситуаций человек действует по шаблону, не проводя анализ ситуации и последствий. Ну и соответственно никаких эмоций или жалоб, а зачастую произошедшее вообще не запоминается — мозг-то уже занят некоторой сложной задачей. Внешне человек выглядит как стоик, преодолевающий трудности без жалоб и эмоциональных проявлений. А по факту — зашоренная лошадь бегущая в стену пламени без страха просто потому, что не видит угрозы.
Управление надежностью — это нифига не специфика IT. Вообще, абстрактно, это подраздел управления рисками. Потому что надежность показывает вероятность наступления негативного события. Вложение денег в надежность (например увеличение запаса прочности балки моста) уменьшает вероятность наступления негативного события (разрушения моста при перегрузе). Но в тоже время увеличивает себестоимость. Бизнес получает возможность учитывать надежность как понятный ему параметр — доля в себестоимости (в случае моста). Ну а имея возможность учета — появляется возможность управления.
IT компании следуют по уже проложенному пути — по мере роста прибыли, растет и ущерб в результате неожиданных сбоев. В начале источником неожиданных сбоев были разработчики выкатывающие изменения прямо на продакшн. Их изолировали от продакшна с помощью кьюэев. По мере роста сложности продуктов — скорость внедрения изменений упала ниже плинтуса. Разработчики задолбались бодаться с опсами и придумали сервисную, а потом и микросервисную архитектуры — и теперь целостность продукта стала попаболью опсов. Потому что продукт появляется не после сборки, а только после деплоймента. Так что SRE это еще одно подмножесто OPSов.
Ну а история Лехи — свежо предание, да верится с трудом. Дев сообщает опсу про проблемы с сервисом в продакшне? Рилли? Типа опсы совсем мух не ловят, а девы их дублируют? Дальше. Компания внедряла SDLC задрачивая девов и кьюэев единственно правильным процессом, чтобы предотвратить деплоймент непроверенного кода. Но пришел опс Леха и зафигачил самописный патч прямо на продакшн. Судя по всему он был очень плохим девом, если за 3,5 года так и не смог запомнить SDLC. Да и способ решения выглядит не самым оптимальным — может все таки стоило добавить обработку ошибок? А если сервис третьестепенный — так может в первостепенных сервисах стоит ослабить зависимость от него? Ну чтобы все не ломалось при недоступности третьестепенного сервиса?
По поводу доступности — для многопользовательских систем имеет значение не сбой для одного конкретного пользователя, а количество пользователей страдающих от сбоя в произвольный момент времени. Потому что часть пользователей обратится в поддержку. А это прямые расходы. И с ростом пользовательской базы — растут и расходы на их поддержку. И иногда переход от 99,99% к 99,999% означает уменьшение колл центра с 1000 операторов до 100. Что дает обоснование с точки зрения ROI.
Голосовая связь — она медленная, последовательная, синхронная и не оставляет артефактов. Собственно, веб и стал таким популярным потому, что он всегда параллельный, асинхронный, легко создает артефакты и зачастую быстрый (даже если и медленный — все равно параллельный и асинхронный). Сейчас я пишу этот комментарий, но в то же время у меня открыты еще несколько статей с хабра и никто не стоит над головой ожидая этот комментарий.
Наиболее близкий аналог голосовой связи который я могу придумать с точки зрения UX — это однострочный дисплей с консолью без истории. При ее использовании ты знаешь только то, что успел прочитать и понять (для голоса — услышать и понять). А на ввод команд есть только ограниченное время — пока не пошла новая порция вывода данных, котрые перемешаются с твоим вводом, превращая команду в непонятную никому ересь. Для полноты ощущений — клавиатура для ввода команд использует затейливую раскладку типа «дворак для левой руки».
Вот с таким интерфейсом, да еще и с ботом инициирущим взаимодействие в любой момент — вполне логично ожидать массовый поджиг пуканов и волны говен. В принципе, потренировавшись, человек может и жонглировать катаясь на одноколесном велосипеде по слабо натянутому тросу. Но ожидать этого от произвольно взятого человека — наивно. Из своего опыта — недавно бот с опросом одного банка начал названивать когда одевался и ждал звонка от человека. Первый звонок я сбросил услышав представление бота, второй — пришелся когда натягивал штаны. И вот стоя в полусогнутой позе с одной ногой в штанине, я выставил наихудшие оценки на все вопросы даже не вслушиваясь — просто чтобы этот бот отцепился.
В качестве решения могу предложить следующее. При записи на урок явно предупреждать, что будет звонить бот. И сразу предлагать dry-run — зайти на платформу пообщаться с ботом в расширенном пошаговом режиме. С сопровождением звука сообщениями в чате — что произнес бот, что он распознал, что он вообще может понять, как он отреагирует (без выполнения самого действия). Пользователю можно дать поиграться с выбором голоса. И совершить звонок проигрывая сценарий и сопровождая его комментариями в чате. Таким образом реальный звонок не станет неожиданностью вызывающей стресс и панику. И заодно — периферия типа динамиков/наушников с микрофоном будет протестирована и донастроена заранее. Да и новый пользователь познакомится не только с ботом, но и с функционалом платформы.
Все это в результате можно будет расширить и на сущестующих пользователей — можно запускать встречу за 5-10 минут до урока (с ботом вместо учителя) для проверки/подстройки периферии и канала, знакомства с новыми фичами плаформы. Вот не знаю, есть ли у вас эхо-сервис, но он будет полезен и новым и существующим пользователям. А ожидание начала урока можно забить музыкой и предложить пользователю ответить на несколько вопросов (выбранных случайно из общего опросника на 100500 пунктов или из таргетированного на 5-10-20 вопросов).
Приколы и там были — ну типа новый менеджер где-то повыше хочет внедрить риск менеджмент и собирает со всех вплоть до джунов возможные риски. Думаю самый популярный вариант был попасть под автобус. Или хочет получать на почту ежедневные отчеты от каждого работника. В аутсорсере. Ему наверно через пару месяцев рассказали, как формируются счета для киентов и где можно посмотреть дейлики.
Аппрайзал — не был единственным фактором для повышения. Там еще были требования по уровню английского, knowledge evaluation и что-то там еще.
Формальная процедура, никакой ламповости и нейронной сети распределенной в мозгах менеджеров.
Участники: HR в роли секретаря/модератора, ПМ, лид, разработчик. Для лида — HR собирает фидбек от членов команды и анонимизирует его. Перед процедурой все участники заполняют таблицу оценок активностей. HR сводит все в один документ и во время процедуры обсуждаются оценки. Результирующая оценка идет в итоговую колонку. Так что обсуждаются в основном расходящиеся оценки. В колонку итоговых комментов вписываются договоренности достигнутые на митинге.
На выходе все участники получают копию заполненной таблицы. Так что сам по себе процесс — просто возможность привести оценки руководителя и подчиненного к общему знаменателю и зафиксировать при участии независимой третьей стороны.
Если я правильно помню, таблицы активностей для профилей не менялись много лет или менялись минимально. Активности были усредненные — типа кодинг, код ревью, участие в митингах с заказчиками и т.п. При повышении грейда добавлялись детали — джуну было достаточно сидеть на митинге пассив листенером, мидлу уже надо было активно участвовать, синьору неплохо было бы подготовить агенду, модерировать митинг и выслать митинг минетс вдобавок к активному участию для получения высшей оценки.
Насколько я понимаю, присутствие HR и создание в процессе артефакта — выступало сдерживающим фактором для всяких нехороших вещей.
Готовые таблицы для следующего грейда — позволяли подготовиться к промоушину, показывая, что надо будет делать на регулярной основе после повышения.
P.S. Текст усыпанный болдом выглядит вырвиглазно и глупо, хуже только раскрашивание в разные цвета.
Опытному синьору совсем не интересно работать на поддержке продукта. В принципе можно завалить эту проблему деньгами, но это сработает только в краткосрочной перспективе, значит будет бешеная ротация персонала. И тут умный но испытывающий проблемы с социализацией и самооценкой кадр, который будет работать годами — выглядит вполне неплохим вложением.
Документация и код… Ну тут все сказано:
Детали и особенности, да, которые в результате приводят к тому, что документация находится в состоянии от «не совсем соответствует» до «совсем не соответствует». Так что садимся и пишем.
Ну и вопрос — сколько времени прошло между отправкой документации и митингом и сколько времени занимал внутренний онбординг под руководством лида? Из моего опыта — даже принимая одну компоненту сложной системы от соседней команды можно потратить больше месяца на вхождение. Это имея доступ к коду, сидящим в соседнем кабинете разработчикам и заранее зная общие для системы принципы и решения.
Бизнес вполне логично делает долгосрочную инвестицию. Разработчик вполне логично начинает выяснять соответствие документации коду. И где тут эффект Даннинга-Крюгера?
Для нахождения общего языка между представителями бизнеса и разработки — заводят переводчика. Как правило это ПМ или лид. Если ПМ хочет реально управлять разработкой, а не водить руками в позиции «передаста» — он должен разбираться в разработке. В противном случае или все развалится как в примере с рефакторингом. Или найдется разработчик который станет договариваться за сроки и бюджеты с бизнесом с одной стороны и фактически управлять разработкой ставя цели и задачи разработчикам с другой стороны.
Нетехнические люди могут ожидать чего угодно, но получат ровно то, за что платят. И синьор с мидлом которые могут простыми словами донести смысл своей деятельности вполне доступны. Просто стоят значительно дороже синьора с мидлом которые умеют только программировать. Внезапно, правда?
Суммируя: Эффект Даннинга-Крюгера вообще никак не связан с примерами в статье. Разработчик с сильными техническими и софт скиллами стоит дороже разработчика только с сильными техническими скиллами. Диагностика тут вообще не причем. Менеджер водящий руками в позиции «передаста» и отсутствие разработчика с прокачанными софт скиллами — прямой путь угробить все.
Так что я бы хотел видеть следующее. Ссылку на инструмент код-ревью в котором можно быстро и просто оставить комментарий к конкретной строке. Саммари тестов и ссылку на детальный отчет по выполнению тестов. Саммари кавераджа и ссылку на детальный отчет кавераджа. Саммари линтера и ссылку на детальный отчет линтера.
Бо мне аж как-то неудобно заглядывать в свой домашний инстанс гитлаба — он же ж не только тесты, но и линтер с кавераджем гоняет при изменении кода. А в ведущих столичных университетах вона оно как.
Что-то мне такое вспоминается, связанное с бревном и глазом…
Вот тут-то всем производителям роботов-манипуляторов и поплохеет. Зато будет хоть какой-то прогресс — и над софтом поработают и над эргономикой пульта подумают. Ну просто от балды — 6 степеней свободы это всего 3 джойстика — например палка, на ней грибок под большой палец и грибок под указательный — вот вам и три джойстика в одной руке. Мега сложный анализ однако.
IT компании следуют по уже проложенному пути — по мере роста прибыли, растет и ущерб в результате неожиданных сбоев. В начале источником неожиданных сбоев были разработчики выкатывающие изменения прямо на продакшн. Их изолировали от продакшна с помощью кьюэев. По мере роста сложности продуктов — скорость внедрения изменений упала ниже плинтуса. Разработчики задолбались бодаться с опсами и придумали сервисную, а потом и микросервисную архитектуры — и теперь целостность продукта стала попаболью опсов. Потому что продукт появляется не после сборки, а только после деплоймента. Так что SRE это еще одно подмножесто OPSов.
Ну а история Лехи — свежо предание, да верится с трудом. Дев сообщает опсу про проблемы с сервисом в продакшне? Рилли? Типа опсы совсем мух не ловят, а девы их дублируют? Дальше. Компания внедряла SDLC задрачивая девов и кьюэев единственно правильным процессом, чтобы предотвратить деплоймент непроверенного кода. Но пришел опс Леха и зафигачил самописный патч прямо на продакшн. Судя по всему он был очень плохим девом, если за 3,5 года так и не смог запомнить SDLC. Да и способ решения выглядит не самым оптимальным — может все таки стоило добавить обработку ошибок? А если сервис третьестепенный — так может в первостепенных сервисах стоит ослабить зависимость от него? Ну чтобы все не ломалось при недоступности третьестепенного сервиса?
По поводу доступности — для многопользовательских систем имеет значение не сбой для одного конкретного пользователя, а количество пользователей страдающих от сбоя в произвольный момент времени. Потому что часть пользователей обратится в поддержку. А это прямые расходы. И с ростом пользовательской базы — растут и расходы на их поддержку. И иногда переход от 99,99% к 99,999% означает уменьшение колл центра с 1000 операторов до 100. Что дает обоснование с точки зрения ROI.
Наиболее близкий аналог голосовой связи который я могу придумать с точки зрения UX — это однострочный дисплей с консолью без истории. При ее использовании ты знаешь только то, что успел прочитать и понять (для голоса — услышать и понять). А на ввод команд есть только ограниченное время — пока не пошла новая порция вывода данных, котрые перемешаются с твоим вводом, превращая команду в непонятную никому ересь. Для полноты ощущений — клавиатура для ввода команд использует затейливую раскладку типа «дворак для левой руки».
Вот с таким интерфейсом, да еще и с ботом инициирущим взаимодействие в любой момент — вполне логично ожидать массовый поджиг пуканов и волны говен. В принципе, потренировавшись, человек может и жонглировать катаясь на одноколесном велосипеде по слабо натянутому тросу. Но ожидать этого от произвольно взятого человека — наивно. Из своего опыта — недавно бот с опросом одного банка начал названивать когда одевался и ждал звонка от человека. Первый звонок я сбросил услышав представление бота, второй — пришелся когда натягивал штаны. И вот стоя в полусогнутой позе с одной ногой в штанине, я выставил наихудшие оценки на все вопросы даже не вслушиваясь — просто чтобы этот бот отцепился.
В качестве решения могу предложить следующее. При записи на урок явно предупреждать, что будет звонить бот. И сразу предлагать dry-run — зайти на платформу пообщаться с ботом в расширенном пошаговом режиме. С сопровождением звука сообщениями в чате — что произнес бот, что он распознал, что он вообще может понять, как он отреагирует (без выполнения самого действия). Пользователю можно дать поиграться с выбором голоса. И совершить звонок проигрывая сценарий и сопровождая его комментариями в чате. Таким образом реальный звонок не станет неожиданностью вызывающей стресс и панику. И заодно — периферия типа динамиков/наушников с микрофоном будет протестирована и донастроена заранее. Да и новый пользователь познакомится не только с ботом, но и с функционалом платформы.
Все это в результате можно будет расширить и на сущестующих пользователей — можно запускать встречу за 5-10 минут до урока (с ботом вместо учителя) для проверки/подстройки периферии и канала, знакомства с новыми фичами плаформы. Вот не знаю, есть ли у вас эхо-сервис, но он будет полезен и новым и существующим пользователям. А ожидание начала урока можно забить музыкой и предложить пользователю ответить на несколько вопросов (выбранных случайно из общего опросника на 100500 пунктов или из таргетированного на 5-10-20 вопросов).
Договаривайтесь.