В статье Шесть HR-секретов из Кремниевой долины утверждается, что инновации важнее производительности. Вы хоть и пытаетесь уравновесить, все равно формальная наработка важнее всего остального.
На мой взгляд это зависит от целей компании. Иногда важнее получить какую-то функциональность быстрее, пусть даже эта функциональность будет переделываться позже.
И вопрос. У вас куча данных по людям, пытались ли вы их анализировать, проводить a/b тесты влияния различных факторов на производительность и т.д.?
Нет. Мы по результату все оцениваем. У нас есть цели, которые ставит компания, которых нужно достигнуть в определенные сроки и это является критерием того, хорошо работает группа или плохо.
Ну не я, наверное, а руководство мое. У меня тоже коэффициент обрезается. Я не думаю, что это нарушение правил, если это обговаривалось заранее (на берегу).
Классное видео. Этот же человек, по-моему, написал книгу «Drive — что реально нас мотивирует».
В целом согласен с ним, но мне кажется, что один подход не отменят другого. А видео классное, люблю TED.
Мне кажется, если такое делать, то анонимно только. У нас была идея ввести оценку, по которой сотрудники внутри отдела оценивают друг друга. Но решили не вводить, поскольку анонимности внутри IT-отдела достигнуть сложно.
Сказать и написать это зачастую разные вещи. Если жалоба написана, то на нее уже как-то придется реагировать, устная жалоба не всегда может вызвать действие. Я не призываю к тому, что бы по поводу и без повода писать жалобы. Просто этот механизм имеет преимущества перед устной жалобой.
Жалуются не все. Я например не очень люблю жаловаться, чаще хвалю. Но когда реально допекут и по другому проблему решить не могу, то жалуюсь.
Бывает, что и инженеры на инженеров жалуются, но редко. Чаще жалобы межотдельного характера случаются.
Причем не анонимно, а публично?
Почему публично? У нас как раз анонимно. Руководитель сотрудника на которого жалуются решает доводить до сотрудника сведения об источниках оценки или нет.
Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.
Соглашусь на 80% процентов. Большого количества таких задач быть конечно не должно. У нас для этого даже пункт в правилах есть:
Заголовки в сущностях (задачах, заявках и т.д.) должны отражать краткую суть проблемы, описанной в содержании сущности.
Заголовок должен быть кратким, но информативным. Например: “Проблема с расчетом ЗП. Фактические часы не соответствуют действительности в сводном отчете о ЗП”.
У нас некоторые задачи формируются из заявок сотрудников. Сотрудники скопом указывают кучку мелких доделок. Не всегда правильно с точки зрения экономии собственного времени бить хотелки сотрудников на задачи.
Граф переходов велик и страшен — если нужна скорость, то можно сделать автоматический переход по статусам (с соответствующей записью в историю), а вот ввод прямых переходов куда угодно — костыль.
Прямые переходы, есть в основном у руководителей подразделений. Это иногда спасает. Почему считаете что это костыль? К каким плохим последствиям это может привести?
Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.
На мой взгляд, это вопрос достаточно философский. У нас почти в каждом состоянии есть сотрудник ответственный за задачу. Когда задача уходит в запрос информации, например, то она меняет свой статус и значение поля «Назначено». В этот момент, ответственность за исполнение задачи лежит на сотруднике у которого информацию запрашивают. Выделение такого статуса помогает с фильтрацией и др.
Приоритеты в свое время переименовал вот так:
1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
2. Срочно — делается в указанной итерации в первую очередь
3. Обязательно — должно быть сделано в указанной итерации
4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую
У нас немного по другому, но тоже имеет право на жизнь, мне кажется:
Срок решения заявки зависит от приоритета. Автор заявки обязан максимально точно определить ее приоритет. Для определения приоритета необходимо пользоваться следующим набором правил:
Заявка со срочным приоритетом требует решения в течение суток.
Заявка с высоким приоритетом выполняются в течение текущего месяца.
Заявка с нормальным приоритетом выполняется в порядке очереди после высоких.
Заявка с низким приоритетом выполняется в порядке очереди после нормальных.
«Плановые часы напрямую влияют на ЗП программиста»
А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.
Про наши схемы денежной мотивации планирую написать в следующей статье. Это вопрос сложный и не однозначный, не имеющий правильного решения, на мой взгляд. Одно могу сказать, эффект от влияния плановых часов на работу программиста есть! Как положительный, так и отрицательны!
С логированием времени у нас ситуация следующая. Программист должен логировать время в задаче. К концу месяца руководитель проводит анализ соответствия плановых часов залогированным программиста и на свое усмотрение может изменить или нет плановые часы. Плановые часы напрямую влияют на ЗП программиста (вот такой вот flexible price).
Во время планирования задач мы проводим обсуждение и коллегиально решаем сколько в часах стоит та или иная задача. В последний раз проводили Planning pocker. Планируем делать это и в будущем.
Есть возможность указывать временные трудозатраты прям в коммит-сообщениях, но даже это программисты нифига не делают. Да, можно требовать принудительно проставления, но это тоже не всегда верно/нужно…
У нас кнопка настроена для быстрого логирования времени. Проблем с логированием нет поскольку это напрямую влияет на ЗП программиста.
А вот по количеству оценить просто. Введите метрику — среднее время исполнения задачи, от взятия в работу до выкладки на бой. Обычно это довольно хороший показатель забюрократизированности процесса, если отнормировать по трудоемкости. И потом проведите эксперимент с разными воркфлоу. С точки зрения теории, любые излишние элементы системы будут снижать ее КПД и повышать бюрократическое трение. С точки зрения моей практики это подтверждается (я добивался повышения скорости прохождения задач с месяца до недели исключительно с помощью оптимизации рабочего процесса).
Благодарю за совет. Планировали сделать метрики, но немного по другому. Сколько и в каком статусе и на ком проживает задача, что бы можно было отчеты строить: на ком скапливаются задачи и в каком статусе скапливаются задачи. Что бы в любом жизненном цикле (у нас их много) можно было анализировать узкие места.
У вас процесс-центричный подход. Переходы в очередной статус возможны только пройдя все предыдущие. В моей практике, было гораздо удобнее сделать роле-центричный, когда можно было за одно действие перевести задачу в любой доступный статус, если у тебя есть на это права.
Нет! У нас конечно можно прыгать между статусами. Просто я в статье описал общую картинку движения задачи. Если на схемку взглянете из статьи то увидите, что там переходов больше чем описано в статье. Это как раз и есть скачки между статусами. В основном они есть у руководителя, но и у тестеровщика тоже могут быть.
Если бы я все переходы показал, то картинка была бы такой :)
Про количество статусов, я частично разделяю ваше мнение. Но с другой стороны наши статусы появились не просто так. Думаю, конкретно для нашей среды, в них все таки есть смысл.
Как вы заставляете заказчика оценить работу и написать осмысленный отзыв? Он для каждой мелкой задачи должен это делать? А если не сделает?
С этим проблемы и тут опять же все зависит от адекватности заказчика, но не только.
Во-первых, у нас административно это закреплено. В правилах использования Redmine,
Во-вторых, технически, если заказчик вообще не поставит оценок, то он сам ЗП не получит и система проинформирует его руководителя в момент закрытия его ЗП о том, что подчиненный не выставил оценок исполнителям и его ЗП нельзя закрыть. Такая мера очень помогла в свое время.
Сложнее с адекватностью пояснений к оценке было. Народ просто ставил Плохо и пробел в пояснении. Это побороли административно, добавили такой пункт в правила:
Строго запрещено:
— проставлять оценки не вникая в суть и смысл показателей, по которым ставятся оценки;
— ставить оценки отличные от «хорошо», не давая подробного пояснения причин снижения или повышения оценки
Плюс, у нас действует сквозная система жалоб и похвалы. Каждый может пожаловаться на любого за несоблюдения правил использования Redmine, например, или других приказов. Руководитель, сотрудника на которого жалуются, получает эти сообщения в момент расчета ЗП и может принять их во внимание, снизить оценку.
Он для каждой мелкой задачи должен это делать?
Да. Для каждой в которой он заказчик. Но он может ставить оценку «Хорошо», не давая пояснений
Цель в задаче указывает не заказчик, а руководитель проекта. Заказчик у нас как правило пишет заявку в которой, как может, указывает свои хотелки. Потом руководитель на основе заявки создает задачу, при этом заявка связана с задачей и исполнитель всегда может посмотреть исходную заявку.
Как руководитель определяет цель? Это во многом от заказчика зависит. Есть адекватные активные заказчики, которые знают чего хотят и могут изложить это доступным языком. Есть неадекватные.
Во втором случае, я иду к заказчику лично и прошу его объяснить мне на пальцах чего ему не хватает. Прошу что бы он рассказывал мне не то, что нужно сделать в redmine, а то чего сделать сейчас не может и почему? Если это не помогает, то прошу его в Redmine начать что-либо делать и прошу сказать когда не удобно будет.
На этой стадии некоторые задачки самоликвидируются. Если нет, то я своими словами говорю как я его понял и спрашиваю правильно или нет? Пото сразу фиксирую все это в задаче.
С объемными задачами, в которых несколько ключевых заказчиков все сложнее.
Почти все можно настроить и в стандартном Redmine, но будет не так удобно настраивать и конечному пользователю тоже будет не очень удобно, не будет кнопок и многих других элементов интерфейса. Но суть статьи в принципах трекания задачки. Какие поля на какой стадии просить заполнять и т.д.
В Redmine для редактирования задачи есть одна ссылочка «обновить», после ее нажатия открывается форма редактирования задачи. Можно задать права на обновление определенных полей, но акцентированного действия настроить не получится.
На мой взгляд это зависит от целей компании. Иногда важнее получить какую-то функциональность быстрее, пусть даже эта функциональность будет переделываться позже.
Нет. Мы по результату все оцениваем. У нас есть цели, которые ставит компания, которых нужно достигнуть в определенные сроки и это является критерием того, хорошо работает группа или плохо.
Ну не я, наверное, а руководство мое. У меня тоже коэффициент обрезается. Я не думаю, что это нарушение правил, если это обговаривалось заранее (на берегу).
В целом согласен с ним, но мне кажется, что один подход не отменят другого. А видео классное, люблю TED.
А почему это система должна тратить время программистов? От них вроде никаких особых временных затрат не требуется.
Бывает, что и инженеры на инженеров жалуются, но редко. Чаще жалобы межотдельного характера случаются.
Почему публично? У нас как раз анонимно. Руководитель сотрудника на которого жалуются решает доводить до сотрудника сведения об источниках оценки или нет.
Соглашусь на 80% процентов. Большого количества таких задач быть конечно не должно. У нас для этого даже пункт в правилах есть:
У нас некоторые задачи формируются из заявок сотрудников. Сотрудники скопом указывают кучку мелких доделок. Не всегда правильно с точки зрения экономии собственного времени бить хотелки сотрудников на задачи.
Прямые переходы, есть в основном у руководителей подразделений. Это иногда спасает. Почему считаете что это костыль? К каким плохим последствиям это может привести?
На мой взгляд, это вопрос достаточно философский. У нас почти в каждом состоянии есть сотрудник ответственный за задачу. Когда задача уходит в запрос информации, например, то она меняет свой статус и значение поля «Назначено». В этот момент, ответственность за исполнение задачи лежит на сотруднике у которого информацию запрашивают. Выделение такого статуса помогает с фильтрацией и др.
У нас немного по другому, но тоже имеет право на жизнь, мне кажется:
Про наши схемы денежной мотивации планирую написать в следующей статье. Это вопрос сложный и не однозначный, не имеющий правильного решения, на мой взгляд. Одно могу сказать, эффект от влияния плановых часов на работу программиста есть! Как положительный, так и отрицательны!
В целом, спасибо за отзыв. Он был очень полезным.
Если для всей сети подымаете, то тогда на DNS-сервере сети.
Во время планирования задач мы проводим обсуждение и коллегиально решаем сколько в часах стоит та или иная задача. В последний раз проводили Planning pocker. Планируем делать это и в будущем.
У нас кнопка настроена для быстрого логирования времени. Проблем с логированием нет поскольку это напрямую влияет на ЗП программиста.
Благодарю за совет. Планировали сделать метрики, но немного по другому. Сколько и в каком статусе и на ком проживает задача, что бы можно было отчеты строить: на ком скапливаются задачи и в каком статусе скапливаются задачи. Что бы в любом жизненном цикле (у нас их много) можно было анализировать узкие места.
Нет! У нас конечно можно прыгать между статусами. Просто я в статье описал общую картинку движения задачи. Если на схемку взглянете из статьи то увидите, что там переходов больше чем описано в статье. Это как раз и есть скачки между статусами. В основном они есть у руководителя, но и у тестеровщика тоже могут быть.
Если бы я все переходы показал, то картинка была бы такой :)
Про количество статусов, я частично разделяю ваше мнение. Но с другой стороны наши статусы появились не просто так. Думаю, конкретно для нашей среды, в них все таки есть смысл.
С этим проблемы и тут опять же все зависит от адекватности заказчика, но не только.
Во-первых, у нас административно это закреплено. В правилах использования Redmine,
Во-вторых, технически, если заказчик вообще не поставит оценок, то он сам ЗП не получит и система проинформирует его руководителя в момент закрытия его ЗП о том, что подчиненный не выставил оценок исполнителям и его ЗП нельзя закрыть. Такая мера очень помогла в свое время.
Сложнее с адекватностью пояснений к оценке было. Народ просто ставил Плохо и пробел в пояснении. Это побороли административно, добавили такой пункт в правила:
Плюс, у нас действует сквозная система жалоб и похвалы. Каждый может пожаловаться на любого за несоблюдения правил использования Redmine, например, или других приказов. Руководитель, сотрудника на которого жалуются, получает эти сообщения в момент расчета ЗП и может принять их во внимание, снизить оценку.
Да. Для каждой в которой он заказчик. Но он может ставить оценку «Хорошо», не давая пояснений
Как руководитель определяет цель? Это во многом от заказчика зависит. Есть адекватные активные заказчики, которые знают чего хотят и могут изложить это доступным языком. Есть неадекватные.
Во втором случае, я иду к заказчику лично и прошу его объяснить мне на пальцах чего ему не хватает. Прошу что бы он рассказывал мне не то, что нужно сделать в redmine, а то чего сделать сейчас не может и почему? Если это не помогает, то прошу его в Redmine начать что-либо делать и прошу сказать когда не удобно будет.
На этой стадии некоторые задачки самоликвидируются. Если нет, то я своими словами говорю как я его понял и спрашиваю правильно или нет? Пото сразу фиксирую все это в задаче.
С объемными задачами, в которых несколько ключевых заказчиков все сложнее.
В Redmine для редактирования задачи есть одна ссылочка «обновить», после ее нажатия открывается форма редактирования задачи. Можно задать права на обновление определенных полей, но акцентированного действия настроить не получится.