Данный вариант не для финансовой отчетности, а для понимания сколько сделано и как мы движемся. в частности SPI и CPI. Отстаем мы по времени и деньгам или нет. Задаем базу, и от нее считаем. Главное использовать одни правила. Можно работников по рублю, руководителей по 2, а бетон с коэффициентом. Можно все с коэффициентом. Вам другой пример — полет до Луны можно измерять километрами, а можно прослушанными песнями. И ответ «прослушали 100 песен из 500», лучше чем «мы находимся в пути».
Отклонения по времени от контрольных точек дает только отклонение по времени. А по содержанию? Хорошо если много мелких контрольных точек, а если всего 2, и что делать в промежутке?
Интересно, кто — нибудь проводил, не зависимое, по всем правилам, исследование — как растет результативность сотрудников от применения подобных средств. Интересует настоящее исследование по всем правилам с опытной и контрольной группами и было/стало, а не реклама от разработчиков данного ПО в стиле «а вот у Васи их Урюпинска теперь 300%, спросите у кого угодно».
Люди постоянно спрашивают оценки на первоначальную разработку, но мало кто интересуется оценками на последующую поддержку решения. И это большая проблема, поддержка — это очень серьезно. Поддержка может занимать до 60-80% всех затрат на проект.
Еще задолго до появления PMBOK, SCRUM и ХР, в книгах В.В.Липаева приводилась такая разбивка — первоначальная разработка занимает — 25%, а последующая отладка (тогда это так называлось) еще 75%.
Почему бы, как метод повышения точности оценки не использовать увеличение декомпозиции, например — разработка структуры классов, разработка интерфейсов, разработка GUI, модульное тестирование. Пусть будет чуть побольше оценок, но мы получим следующие результаты:
— уже в ходе оценки разработчик будет думать над реализацией, а не давать прогноз на основе исторических данных;
— получим дополнительные точки контроля, например если первая оценка будет просрочена, это заставит усомниться и в следующих и перепланировать всю работу заново, не дожидаясь провала сроков по итогу;
— получим, то что Вы описывали, как возможность поработать над задачей а потом планировать сроки ее завершения;
Полностью согласен, что для внедрения хорошей системы управления, в том числе, оценок, приближенных к действительности, нужно, для начала понимать, что такое система управления и как она, организуется и работает.
Одна из основных проблем при оценке, когда руководитель давит на разработчиков или берет на слабо, в стиле "а вот ХХХ сделает это в 2 раза быстрее". В итоге разработчик соглашается, чтобы не потерять лицо, а в итоге не успевает. И на словах получается виноват разработчик, а на деле руководитель, который не использует адекватную систему оценки, например на основе исторических данных, по трем точкам или с дополнительной оценкой рисков. Проще говоря, проблема в не совсем корректной организации процесса оценки.
Прекрасная модель. Думаю с углублением кризиса она будет развиваться и побеждать. Так как вся работа станет удаленной, будет много людей на рынке труда и люди из регионов смогут напрямую работать, как и люди из МСК.
Спасибо!
Прекрасная система. Особенно мне понравилось про рейтинги.
(Еще пара вопросов/комментариев по тексту в скобках.)
Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
Для этого предусмотрена связь через ревью задачи снизу вверх, вышестоящая роль даёт сроки завершения усредняя время похожих типовых задач. В дальнейшем эти сроки могут входить в статистику для расчётов других задач в автоматизированном режиме.
(Ревью снизу вверх делается до начала работы над задачей или после завершения задачи? Проще говоря, может ли исполнитель оспорить срок до начала работы, чтобы потом не оказаться причиной превышения сроков?)
В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
Если в подчинении 2 — 3 исполнителя, то можно и в рукопашную. Если их от 10 и более, вы утоните в рутине которая будет отнимать большую часть времени. Регулировка мотивации на задачи производится через назначение соответствующей стоимости задачи или директивно штатным сотрудникам.
(В моем понимании, руководитель, все равно, должен определять приоритеты — что надо сделать обязательно и в первую очередь, а что можно потом. Например, вначале делаем базовый функционал а потом экранные формы и отчеты. В противном случае, мы получаем один из трех вариантов — сделано все, кроме того что нужно или мы вынуждены переплачивать за базовый функционал, чтобы его хотя бы кто — то взялся делать или его специально не делают, чтобы поднять цену, а потом сделать.)
Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Вопрос не в руководителях, а в самой возможности вести бизнес в регионах с острым кадровым голодом.
(Я имел в виду, когда повышение сотрудников ведется на основе личных отношений, а не объективных факторов. Или когда субъективные факторы используются для отказа в повышении. При наличии и использовании рейтингов такая история затруднительна.)
Хотелось бы увидеть его подход к оценке производительности и результаты этой оценки.
Пока мнения разделяются — кто — то резко против удаленной работы, кто — то исключительно за. При чем, доводы у двух лагерей одни и те же — производительность и время.
О каком недостатке общения при удаленной работе можно говорить, если уже лет 20 как большая часть коммуникаций между людьми проходит виртуально — в социальных сетях и мессенджерах. При удаленной работе эти инструменты сохраняются и добавляются еще видеоконференции.
Спасибо! У Вас больше техника описана, а у меня про трансформацию подхода к управлению. Видимо, у Вас большой опыт реализации подобных систем.
Мои комментарии/вопросы по пунктам:
1. Руководитель группы, в любом случае должен быть. Его можно назвать ведущим, можно ответственным. Это человек, который знает работу лучше всех исполнителей, разрабатывает архитектуру и отвечает за качество.
2. Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
3. ++
4. В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
5. С рейтингами исполнителей на практике не работал. Обычно фиксируются только отклонения в плюс или минус и дальнейшее изменение роли по результатам аттестации. Дайте, если возможно, ссылку, или описание инструмента, в двух словах. Возможно, это то чего в моей системе не хватает, так как я работаю в рамках стандартных ролей и грейдов.
5. ++
6. Как быть если возможна только пост — оплата?
7. До какого уровня мы делали декомпозицию в пункте 2? Что если дальнейшая декомпозиция повлечет изменение стоимости?
Как я себе понял, описывается некая самоорганизующаяся команда, даже не SCRUM, а что то еще дальше, у которой на входе есть бек — лог задач, а на выходе результат в сроки, которые определяет команда. Типа биржы или круад — сорсинга. Кто в данном случае отвечает и определяет объем, сроки и приоритеты? На сколько такой подход применим в случае заказной разработки?
Инициатива с рейтингами очень интересная. Каждой атомарной задаче присваивается рейтинг. Фиксируется уровень исполнения задачи сотрудником. Ведутся правила присвоения следующей роли, на основании суммарного рейтинга (сумма нарастающим итогом, максимальное, минимальное, среднее). Такая система делает рост сотрудника максимально прозрачным и все повышения обоснованными. Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Вот именно в этом и есть проблема не профессиональных руководителей. Вместо выстраивания системы, попытка выехать только на коммуникациях. Если работа в офисе это ретушировала, то удаленная работа показала на 100%.
Мое мнение по пунктам, (мои комментарии в скобках курсивом):
Что дает мне офис?
1) Быстродействие и стабильность внутренних сервисов и информационных систем компании
(С этим разобраться просто. Инфраструктура меняется проще процессов.)
2) Визуальный контакт и понимание, когда лучше обратиться к коллеге/руководителю.
(Это надо зашивать в процесс. Либо делать проще процесс, либо чаще ставить точки контроля.)
3) Режим, изоляцию от домашних дел, смену обстановки
(С этим в наших условиях ничего ни поделаешь. Если дисциплиной можно заставить себя не ходить на кухню 4 часа в сутки, то изолировать рабочее место от жены и детей в условиях 20 метров жилой площади вряд ли получится.)
4) Возможность конфиденциального общения
(Не очень понимаю. Куда уж более скрыто, когда оба в наушниках и гарнитурах и у себя дома.)
5) Возможность прямого взаимодействия в группе
(Прямое взаимодействие переходит в режим ВКС. И здесь сложностей нет.)
6) Реализацию социальных потребностей
(Человек реально ломается, когда не знает, есть ли люди рядом или нет. Например Робинзон Крузо, в реальности стал бы больным через месяц. Когда же есть понимание, что ты часть живого социума, просто далеко от него, ничего ни происходит. Вспомните, космонавтов, они далеко, но на связи.)
7) Слухи
(Для таких вещей можно завести общий чат, и как бывает 2 — «чат с руководителем», «чат без руководителя».)
medium.com/@ezelby/remote-work-market-map-58591966b0c2
Отклонения по времени от контрольных точек дает только отклонение по времени. А по содержанию? Хорошо если много мелких контрольных точек, а если всего 2, и что делать в промежутке?
Еще задолго до появления PMBOK, SCRUM и ХР, в книгах В.В.Липаева приводилась такая разбивка — первоначальная разработка занимает — 25%, а последующая отладка (тогда это так называлось) еще 75%.
Почему бы, как метод повышения точности оценки не использовать увеличение декомпозиции, например — разработка структуры классов, разработка интерфейсов, разработка GUI, модульное тестирование. Пусть будет чуть побольше оценок, но мы получим следующие результаты:
— уже в ходе оценки разработчик будет думать над реализацией, а не давать прогноз на основе исторических данных;
— получим дополнительные точки контроля, например если первая оценка будет просрочена, это заставит усомниться и в следующих и перепланировать всю работу заново, не дожидаясь провала сроков по итогу;
— получим, то что Вы описывали, как возможность поработать над задачей а потом планировать сроки ее завершения;
Полностью согласен, что для внедрения хорошей системы управления, в том числе, оценок, приближенных к действительности, нужно, для начала понимать, что такое система управления и как она, организуется и работает.
Одна из основных проблем при оценке, когда руководитель давит на разработчиков или берет на слабо, в стиле "а вот ХХХ сделает это в 2 раза быстрее". В итоге разработчик соглашается, чтобы не потерять лицо, а в итоге не успевает. И на словах получается виноват разработчик, а на деле руководитель, который не использует адекватную систему оценки, например на основе исторических данных, по трем точкам или с дополнительной оценкой рисков. Проще говоря, проблема в не совсем корректной организации процесса оценки.
Прекрасная модель. Думаю с углублением кризиса она будет развиваться и побеждать. Так как вся работа станет удаленной, будет много людей на рынке труда и люди из регионов смогут напрямую работать, как и люди из МСК.
Спасибо!
Прекрасная система. Особенно мне понравилось про рейтинги.
(Еще пара вопросов/комментариев по тексту в скобках.)
Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
Для этого предусмотрена связь через ревью задачи снизу вверх, вышестоящая роль даёт сроки завершения усредняя время похожих типовых задач. В дальнейшем эти сроки могут входить в статистику для расчётов других задач в автоматизированном режиме.
(Ревью снизу вверх делается до начала работы над задачей или после завершения задачи? Проще говоря, может ли исполнитель оспорить срок до начала работы, чтобы потом не оказаться причиной превышения сроков?)
В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
Если в подчинении 2 — 3 исполнителя, то можно и в рукопашную. Если их от 10 и более, вы утоните в рутине которая будет отнимать большую часть времени. Регулировка мотивации на задачи производится через назначение соответствующей стоимости задачи или директивно штатным сотрудникам.
(В моем понимании, руководитель, все равно, должен определять приоритеты — что надо сделать обязательно и в первую очередь, а что можно потом. Например, вначале делаем базовый функционал а потом экранные формы и отчеты. В противном случае, мы получаем один из трех вариантов — сделано все, кроме того что нужно или мы вынуждены переплачивать за базовый функционал, чтобы его хотя бы кто — то взялся делать или его специально не делают, чтобы поднять цену, а потом сделать.)
Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Вопрос не в руководителях, а в самой возможности вести бизнес в регионах с острым кадровым голодом.
(Я имел в виду, когда повышение сотрудников ведется на основе личных отношений, а не объективных факторов. Или когда субъективные факторы используются для отказа в повышении. При наличии и использовании рейтингов такая история затруднительна.)
Пока мнения разделяются — кто — то резко против удаленной работы, кто — то исключительно за. При чем, доводы у двух лагерей одни и те же — производительность и время.
О каком недостатке общения при удаленной работе можно говорить, если уже лет 20 как большая часть коммуникаций между людьми проходит виртуально — в социальных сетях и мессенджерах. При удаленной работе эти инструменты сохраняются и добавляются еще видеоконференции.
Мои комментарии/вопросы по пунктам:
1. Руководитель группы, в любом случае должен быть. Его можно назвать ведущим, можно ответственным. Это человек, который знает работу лучше всех исполнителей, разрабатывает архитектуру и отвечает за качество.
2. Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
3. ++
4. В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
5. С рейтингами исполнителей на практике не работал. Обычно фиксируются только отклонения в плюс или минус и дальнейшее изменение роли по результатам аттестации. Дайте, если возможно, ссылку, или описание инструмента, в двух словах. Возможно, это то чего в моей системе не хватает, так как я работаю в рамках стандартных ролей и грейдов.
5. ++
6. Как быть если возможна только пост — оплата?
7. До какого уровня мы делали декомпозицию в пункте 2? Что если дальнейшая декомпозиция повлечет изменение стоимости?
Как я себе понял, описывается некая самоорганизующаяся команда, даже не SCRUM, а что то еще дальше, у которой на входе есть бек — лог задач, а на выходе результат в сроки, которые определяет команда. Типа биржы или круад — сорсинга. Кто в данном случае отвечает и определяет объем, сроки и приоритеты? На сколько такой подход применим в случае заказной разработки?
Инициатива с рейтингами очень интересная. Каждой атомарной задаче присваивается рейтинг. Фиксируется уровень исполнения задачи сотрудником. Ведутся правила присвоения следующей роли, на основании суммарного рейтинга (сумма нарастающим итогом, максимальное, минимальное, среднее). Такая система делает рост сотрудника максимально прозрачным и все повышения обоснованными. Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Что дает мне офис?
1) Быстродействие и стабильность внутренних сервисов и информационных систем компании
(С этим разобраться просто. Инфраструктура меняется проще процессов.)
2) Визуальный контакт и понимание, когда лучше обратиться к коллеге/руководителю.
(Это надо зашивать в процесс. Либо делать проще процесс, либо чаще ставить точки контроля.)
3) Режим, изоляцию от домашних дел, смену обстановки
(С этим в наших условиях ничего ни поделаешь. Если дисциплиной можно заставить себя не ходить на кухню 4 часа в сутки, то изолировать рабочее место от жены и детей в условиях 20 метров жилой площади вряд ли получится.)
4) Возможность конфиденциального общения
(Не очень понимаю. Куда уж более скрыто, когда оба в наушниках и гарнитурах и у себя дома.)
5) Возможность прямого взаимодействия в группе
(Прямое взаимодействие переходит в режим ВКС. И здесь сложностей нет.)
6) Реализацию социальных потребностей
(Человек реально ломается, когда не знает, есть ли люди рядом или нет. Например Робинзон Крузо, в реальности стал бы больным через месяц. Когда же есть понимание, что ты часть живого социума, просто далеко от него, ничего ни происходит. Вспомните, космонавтов, они далеко, но на связи.)
7) Слухи
(Для таких вещей можно завести общий чат, и как бывает 2 — «чат с руководителем», «чат без руководителя».)