Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.
…
Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.
Как же всегда было интересно видеть, когда принимают решения за других людей.
Откуда такие однобокие предположения?
Как же всегда было интересно видеть, когда принимают решения за других людей.
За каких других людей?
Тимлиды принимают решения о формировании команды.
И Вы выделили целый абзац. С чем именно Вы не согласны?
За каких других людей?
На чем базируется утверждение «У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.»? Почему не рассматривается сценарий, когда dev1 и dev5 работают в кооперации и скажут, что ни одна из БД не подходит?
Сложно представить активный обмен знаниями между dev1 и остальной командой.
На чем базируется такое утверждение? Формально, принято решение 'изолировать' dev1 от остальной команды.
Почему не предполагается сценарий, что dev1 будет перенимать знания у прочей команды?
Почему-то рассматриваются только конфликтные сценарии?
Почему не сценарии дополнения отсутсвующий знаний?
На чем базируется утверждение «У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.»?
MongoDB vs MySQL
NoSQL vs SQL
Вечные холивары. Зачем это создавать?
Формально, принято решение 'изолировать' dev1 от остальной команды.
А разве где-то сказано, что в компании только 5 разработчиков и для девелопера №1 нет другого проекта и другой команды?
Сценариев может быть много и я показываю только один из возможных.
Вечные холивары. Зачем это создавать?
Это работа не программиста, а специально обученного человека. Выбирается не на «ринге», а по набору объективных критериев. Если у вас не умеют так делать, значит, наверное, надо учиться.
А разве где-то сказано, что в компании только 5 разработчиков и для девелопера №1 нет другого проекта и другой команды?
Вообще-то утверждение «Сложно представить активный обмен знаниями между dev1 и остальной командой.» — именно об том и говорит.
Почему-то кто-то «представляет», проецируя свою логику и поведение на Того Парня, не допуская что оно напрочь ошибочное и не укладывается в мотивацию dev1?
Почему-то кто-то «представляет», проецируя свою логику и поведение на Того Парня, не допуская что оно напрочь ошибочное и не укладывается в мотивацию dev1?
Почему-то кто-то считает, что прочитал мысли автора статьи. Но это не так.
У меня десяток команд на разных проектах. Я формирую новую. Такого не бывает?
Предположения взялись из анализа предпосылок для передачи/получения каждого из навыков. Например, предположения однозначно оправданы, если задача для dev1 стоит как «обучи dev2 основам unit-тестирования». Для этого надо, как минимум, иметь общий язык, и (для обучающего) знать «правильный» фреймворк для Unit-тестирования на этом языке.
Еще в матрицу компетенций неплохо бы добавить преподавательские способности.
Еще в матрицу компетенций неплохо бы добавить преподавательские способности.
"намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде."
Профессор намного превышает студентов по уровню знаний. Следуя этой логике, ему будет сложно передавать им знания.
Не совсем так. Профессор нацелен на обучение. Программист в среднем на обучение не нацелен. Этот вывод из моих личных наблюдений. Чтобы это выяснить наверняка нужно провести исследование.
Ну и конечно тимлид должен знать сильно больше чем записано в матрице.
Ну и конечно тимлид должен знать сильно больше чем записано в матрице.
Программист в среднем на обучение не нацелен.
А платить за обучение пробовали?
Пробовали.
Хороший программист не факт, что хороший преподаватель.
Хороший программист не факт, что хороший преподаватель.
См. комментарий ниже (про доцента). Если продолжать аналогию, то надо сравнивать программиста, нацеленного обучать других, с профессором, а программиста того же ранга, но не нацеленного обучать других, с ведущим научным сотрудником.
Профессор тратит свое время не только на научную деятельность, но и на разработку методики преподавания и в том числе на создание учебных материалов. И ему платят в том числе за эту невидимую для студентов работу.
Профессор тратит свое время не только на научную деятельность, но и на разработку методики преподавания и в том числе на создание учебных материалов. И ему платят в том числе за эту невидимую для студентов работу.
Вы это ближе к реальности. В реальности система мотивации привязана к достижению каких то целей к точке во времени. Т.е. если тратить время на обучение, то количество сделанных задач будет меньше.
И именно поэтому возлагать задачи обучения на сеньора… Далеко не всегда самое правильное решение.
Моей задачей было наладить гармоничный обмен знаниями внутри команды. А для этого уровень знаний должен быть сопоставим. Как и области знаний. Это мое личное мнение.
Это конечно не касается политики и футбола. Там все профессионалы одинаково высокого уровня.
Моей задачей было наладить гармоничный обмен знаниями внутри команды. А для этого уровень знаний должен быть сопоставим. Как и области знаний. Это мое личное мнение.
Это конечно не касается политики и футбола. Там все профессионалы одинаково высокого уровня.
Как ни странно, это верно. Доценты часто объясняют понятнее, чем профессора. Доценты помнят, что им самим давалось тяжело, и стараются разъяснить именно этот материал подробнее. Т.е. профессора считают неочевидное очевидным, и оставляют пробелы в понимании у студентов.
То же самое явление имеет место и в спортивных тренировках.
То же самое явление имеет место и в спортивных тренировках.
Зарплаты будут выравнивать с компетенциями? Насколько компания заинтересована в нахождении несоответствия зп и компетенции в обе стороны (плюс и минус)?
Еще где-то со времен Ф. Брукса известно, что хорошие программисты отличаются от плохих обычно не на проценты, а на порядки. Т.е. скажем в 10 раз, или даже в 100. Поэтому шкала оценки компетенций от 1 до 5 сразу вызывает вопросы.
>Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
Самоуверенный джуниор напишет, что владеет в совершенстве, а скромный синьор — оценит себя на балл ниже, потому что знает — совершенства вообще не бывает в природе. Да еще и циферки эти ничего не значат, потому что правила расстановки оценок не сформулированы. Ну еще и шкала вероятно логарифмическая (см. выше).
>Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
Самоуверенный джуниор напишет, что владеет в совершенстве, а скромный синьор — оценит себя на балл ниже, потому что знает — совершенства вообще не бывает в природе. Да еще и циферки эти ничего не значат, потому что правила расстановки оценок не сформулированы. Ну еще и шкала вероятно логарифмическая (см. выше).
Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников.
Вы только что потеряли хорошего сотрудника и свою репутацию. Работать с таким «начальником”? Да никогда!
На месте специалиста, которому не дают развернуться нахожусь я.
Только я сам сознательно ограничиваю применение техник, которые известны только мне. Потому что интересы команды должны быть выше личных. Или может быть наоборот я эгоист и не хочу сопровождать всю жизнь свой код.
Если же программист сознательно пишет свой код непонятно для большинства своих коллег, то он не такой уж хороший специалист.
Только я сам сознательно ограничиваю применение техник, которые известны только мне. Потому что интересы команды должны быть выше личных. Или может быть наоборот я эгоист и не хочу сопровождать всю жизнь свой код.
Если же программист сознательно пишет свой код непонятно для большинства своих коллег, то он не такой уж хороший специалист.
Можно ли привести ссылки на первоисточники по «Классическому подходу» с матрицами и диаграммами компетенций?
Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований.
При этом давая субъективные оценки компетенциям от 1 до 5…
Почему не от 1 до 10? И где грань между 4 и 5?
да хоть от одного до ста
это сути не меняет вообще
это сути не меняет вообще
Соглашусь, что лучше использовать шкалу оценки 0-10. Это позволит сделать более точек оценку. Причём перед тем как оценивать, необходимо зафиксировать что в идеале означает каждая цифра. Как минимум нужно описать 0,10 и ещё несколько реперных значений.
Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.
Если вы работаете в крупной компании, и основным «поставщиком» проектов для вас законодательство, то вы не сможете учитывать интересы сотрудника к технологиям/проектам, только если вы не R&D. Либо вы будите его «продавать команде», найти что-то что их заинтересует и на чем они смогут прокачать свою экспертизу. Но тут есть обратная сторона, что будет если они не купят?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение матрицы и диаграммы компетенций