VictorSavyuk 14 мар в 17:15

Разница в мотивации ТОПов и сотрудников: как выстроить эффективную команду

Простой

6 мин

5.9K

Управление продуктом*Управление проектами*Развитие стартапа

Из песочницы

Комментарии 13

Dhwtj 14 мар в 17:28

Топы относятся к остальным сотрудникам как к ресурсам. Но обязательно расскажут про эффективную команду как одна семья.

VictorSavyuk 15 мар в 12:39

Это уж каких топов вы подберете. Все от основателя зависит

K0styan 14 мар в 22:51

За NSM будут хоть как-то переживать не тогда, когда она будет на мониторе везде крутиться, а тогда, когда каждый будет понимать а) каким образом его работа на эту метрику влияет; и б) какие именно плюшки он лично с преодоления очередного барьера будет иметь.

Без этого - да, знать будут. Отмечать тоже. Даже тотализатор могут устраивать. Считать эту метрику своей - не будут.

VictorSavyuk 15 мар в 12:42

Вы правы, но если говорить про идеальную ситуацию. Я пишу про то, что мне удавалось сделать. Да, не все понимают, как их работа влияет на NSM, но все равно фокусировка команды в десятки раз выше, чем когда NSM вообще нет.

Petrana 15 мар в 07:01

Есть и такой вариант от руководства: мои проблемы - это ваши проблемы

lnkiseleva 15 мар в 10:47

Те, кто хочет остаться на текущем месте или немного расти, будут решать проблемы непосредственного руководителя. Те, кто хочет занять его место или аналогичное, будут решать проблемы его руководителя, как бы странно это не звучало. Такое мнение сложилось пока из наблюдений, на истину не претендует, конечно.

VictorSavyuk 15 мар в 12:45

Так плохо. Давайте зарефреймим: мои задачи - это ваши задачи. Согласитесь, есть разница.
Оттуда один шаг до варианта: у нас общие задачи. Но понимаю, что это не часто бывает.

say_mokc_no 15 мар в 22:25

А как с помощью kpi измерять качество кода? Ну количество выполненных задач легко, или количество строк кода - но тогда всем понятно к чему это приведет.

maclaudstein 16 мар в 15:04

А давай зададим вместо твоего вопроса "правильный вопрос" - а зачем/нахрена вообще измерять метрикой качество кода? Ты измеряешь метрикой количество кислорода в воздухе, которым тебе надо дышать? Нет. Ты берешь и дышишь или просто не дышишь. Так и с кодом - нет смысла измерять метрикой то, что должно быть стандартом, который соблюдается. Для этого должны быть прописаны эти стандарты и внедрены механизмы контроля - код-ревью, перформансы, а так же принята за аксиому идея писать код, соответствующий этим требованиям. И тогда качество кода прямо влияет на скорость выполнения задачи командой или отдельным человеком.

Если условный Васян делает среднюю задачу, доходящую до тестирования (то есть уже прошедшую код-ревью), за 18чч, а Пашан за 8ч, то вот и показатель эффективности сотрудника. А качество кода - это не показатель, а критерий, который в принципе нельзя нарушить.

Если вернуться к первоначальному вопросу, то проблема *у нас выходит некачественный код" решается не метрикой, а стандартом "выпускать весь код качественно". Так зачем нужна метрика, отражающая 100 процентов по умолчанию? Нужна лишь метрика, за какой срок это выполняется.