Совет к конкурсу от Олега Гончарова
Приводим совет к конкурсу "Project - против шишек!" от нашего читателя, Олега Гончарова:
Обязательно формирую в проектах поле "результат". Сам заполняю, и требую от других формулировать результат в виде "вещественного доказательства". Т.е. если это не какой-то предмет, значит - документ. Например, не "работающая система", а "акт проверки/испытаний". Не "заполненные справочники", а "утверждённый перечень данных". Как показывает практика, это иногда достаточно трудно сделать (сходу сформулировать результат работ), зато в дальнейшем очень помогает. Как самим проводимым работам, так и согласованию результата работ (поскольку любой документ в идеале, д.б. согласован по форме представления).
Comments
- Anonymous
January 01, 2003
- Совершенно согласен с тем, что в идеале результат задаче д.б. сведён к "да/нет". Т.е. получен ли обозначенный результат. Однако, всё, что написано в комментарии не противоречит самому "совету". Для этого и придумали различные "индикаторы" и KPI. Так же согласен с тем, что "указать направление" - это работа руководителя любого уровня. Однако, прежде чем говорить "правильно" или "неправильно" формулировать результат с "открытым вопросом (без да/нет)", следует договориться о проектах какого уровня идёт речь. Под "уровнем" в данном случае, подразумеваю степень декомпозиции проекта/задачи, относительно тех целей, о которых говорите Вы (т.е. уровня ТОП-руководства). У меня, в итоге прочтения комментария, сложилось впечатление, что кроме руководства (контролировать исполнение) проекты не кому не нужны. Я так не думаю.
- Разумеется, стоило бы добавить, что "всё надо мерять в цифрах", и ещё много чего. В данном случае, мы всё-таки, говорим о "советах" по типовым ошибкам, а не написании руководства по проектному управлению. Стараюсь быть проще.
- Anonymous
January 01, 2003
Встречал ранее в нескольких компаниях подобные начинания руководства. Было время, как и вы, считал это полезным ровно по озвученным в совете причинам. Потом, благодарю провидение, я наконец-то понял, что такое WBS (en.wikipedia.org/.../Work_breakdown_structure): "A work breakdown structure (WBS), in project management and systems engineering, is a deliverable oriented decomposition of a project into smaller components" - ключевое слово "deliverable". Речь о том, что план работ по определению уже должен быть сформирован от измеримой создаваемой в рамках проекта ценности (артефактов), как следствие, исполнители получают задачу с описанием всем понятного измеримого на уровне "готово: да/нет" требуемого результата. В этой схеме руководители знают, чем занимаются их подчиненные, а исполнители понимают, что от них требуется. А предложенный совет часто используется на уровне лечения раковых метастаз: руководитель слабо понимает, чем по каждой конкретной низкоуровневой задаче делает исполнитель, но все-таки зачем-то хочет это понимать - и не долго думая, идет по пути наименьшего сопротивления. В этом случае он фактически свою собственную работу перекладывает на плечи исполнителей: те итак самостоятельно продираются через туман того, что от них требуется сделать, но и потом мучительно придумывают "артефакты" для отчетности начальству, чтобы его успокоить. В одной известной компании из самого верха топ-листа компании-разработчиков России было такое начинание. Через некоторое время все сошло на такие артефакты в отчетах: разработчики указывали "написал такой-то код", тестировщики "создал такие-то тестовые случаи" и т.п. То есть каждый завуалировано писал нечто вроде: "делаю свою работу, наделал вот столько-то, лежит там-то, если интересно, иди и смотри". В итоге, руководство поняло, что все равно не понимает: кто и куда из исполнителей движет компанию. Не знаю, задумался ли менеджер после этого: а может все-таки это моя работа "указать направление"?