2) Общие цели следует формулировать так, чтобы у исполнителя было четкое ощущение причастности к чему-то глобальному и важному, при этом, зависимость общей цели от обсуждаемой задачи должна быть прямой, а не косвенной. Если члены команды не готовы слышать, что от стоящей перед ними задачи может зависеть, например, премия для целого филиала вашей корпорации, лучше подчеркнуть, что это очень важно для вас лично и поможет им обрести/закрепить/развить знания и умения, которые помогут в дальнейшем карьерном росте. Иными словами, цель должна мотивировать, а не бросать исполнителей в бездну экзистенциального ужаса, предварительно придавив их грузом непосильной ответственности.
Любопытно, на самом деле...
По крайней мере про сроки вещь рабочая. Одна дата действительно воспринимается как "день +", но никак не "день -". При ориентации на период исполнитель к первой должен быть готов показать какой-то результат.
Кстати, как в этом случае делать правки? К примеру, дизайнер отправил макет, клиент дал пару правок. Укладываемся в оговоренные сроки (априори должны, иначе это ошибка в постановке) или ставим новую задачу?
Есть некоторая вероятность, что исполнитель таки просечёт "схему" с периодами и будет всё равно метить в самый край. По идее, должен быть запрос результата на левой границе периода.
Второй момент, который меня интересует, как это визуализировать? Гантом, к примеру.
Благодарю за классный вопрос.
У нас специфика такова, что результат задачи либо подразумевает одну итерацию, после чего могут быть правки и соответственно новая задача, либо промежуточные варианты для согласования и корректировок должны предоставляться задолго до временного интервала, который мы указываем как окончание. Пример: Я ставлю задачу на разработку раздела проектной документации, пусть это будет дизайн проект. На проект в целом отводится 6 месяцев. Для исполнителя я ставлю крайний срок - первая неделя шестого месяца. Но само собой, дизайнер не сидит 5 месяцев просто так, чтобы потом за неделю склепать какой-то черновик, который придется проверять и переделывать или дополнять. Поэтому в течение этих 5 месяцев у нас точно будут отдельные задачи на выдачу первичного и промежуточных вариантов, а также отдельно согласования и утверждения.
В части того, что исполнитель просечёт схему - вообще никаких проблем. Это же не скрытая манипуляция, у нас в команде все знают почему срок ставится именно так. Но это работает на таком уровне человеческого поведения, где понимание никак не меняет внутреннего желания человека уложится где-то в середине, а не в крайних числах установленного интервала. Это можно сравнить с тем, как мы расходимся с человеком в узком коридоре, мы автоматически пытаемся повернуться боком и проскользнуть в имеющемся пространстве не задевая ни стену ни человека. Конечно, это не дает 100% гарантии, что у специалиста не будет какой-то повышенной нагрузки или личных обстоятельств, из-за которых он дотянет до последнего, но ему самому будет от этого не очень комфортно и чаще он будет таки стремиться закончить работу между этими датами. К слову, в методике мы предлагаем использовать именно нечетное количество дней для обозначения интервалов, так середина более очевидна.
В части визуализации тут все просто, мы работаем по спринтам длительностью в неделю, т.е. 5 рабочих дней. А поскольку мы все таки из строительной отрасли, мы не используем "чистый" скрам, или как говорил Сазерленд, то что мы используем это что угодно, но не скрам) У нас состав работ, он же бэклог готовится сразу на весь цикл разработки проекта и для меня визуализация сводится к тому, что задача должна будет быть готова, например, в 7 спринте. Если говорить про использование именно диаграмм ганта, то тут вообще элементарно, просто "сдачу проекта" мы не помечаем как веху, а задаем на нее нужную нам длительность.