The post has been translated automatically. Original language: Russian
The project team has been creating something for several months.
Developed, tested, and launched. All the main tasks are closed.
You can disperse :)
It's not until the next day that the project result begins to lead a normal life.
The user's access is not working.
Something needs to change.
An error has been found.
There is a new employee who needs to be connected.
A month later, a question arose that no one expected at all during development.
And then suddenly it turns out that the project is over, and it's unclear who should go with all this now.
It seems to me that the transfer of the result should not be considered on the last day.
Even before the project is completed, it is useful to determine:
Who is responsible for what we have created?
To whom do we send the instructions and necessary materials?
Have all the necessary access rights been granted?
Are there any other issues that the project team did not manage to resolve?
Who will deal with them after completion?
And most importantly, does the receiving party understand what exactly has become its responsibility now?
Because technically, it's possible to send someone a folder with documents and write "everything has been transferred" pretty quickly.
But this does not mean that a person will be able to work with it normally tomorrow.
I would generally separate the two points.
First, we have finished working on the project.
The second is that the result of the project has actually been transferred to those who will continue to use, support and develop it.
And sometimes there is still a decent chunk of work between the first and second point.
Therefore, the closure of the project for me is not only the last check mark in the plan.
Probably, it is really finished when there is no question after the departure of the project team.:
"And now whose is it anyway?"
Есть отчеты по проекту, на которые приятно смотреть.
90% задач выполнено.
Сроки в норме.
Количество ошибок снизилось.
Команда закрыла почти все, что запланировала.
Везде зеленый цвет.
Кажется, можно спокойно жить дальше :)
А потом выясняется, что запуск все равно переносится.
Потому что среди оставшихся 10% была одна задача, без которой продукт нельзя выпустить.
И вот здесь мне кажется интересным сам вопрос:
Что на самом деле показывает наша метрика?
Например, команда запланировала двадцать задач и закрыла восемнадцать.
90% — отличный результат.
Но если восемнадцать были небольшими, а две оставшиеся определяют весь результат этапа, процент выполненных задач уже не очень хорошо описывает состояние проекта.
То же самое может происходить со сроками.
Можно вовремя завершить почти все этапы, но задержать именно тот, от которого зависит следующий.
Можно уменьшить количество ошибок, но оставить одну критичную.
Можно провести десять встреч с заказчиком, но так и не получить одно решение, которое нужно команде.
Сами показатели при этом не неправильные.
Проблема появляется, когда мы начинаем принимать хорошее значение показателя за хороший результат проекта.
Мне кажется, руководителю проекта полезно иногда смотреть на свой отчет и задавать себе довольно простой вопрос:
Если убрать цифры и цвета, что я могу сказать о проекте прямо сейчас?
Что уже действительно готово?
Что мешает получить следующий результат?
Есть ли одна задача, от которой зависит намного больше, чем от остальных?
Что произойдет, если мы ничего не изменим до следующей недели?
Иногда после этих вопросов зеленый отчет начинает выглядеть немного иначе :)
Я бы поэтому не отказывалась от показателей. Без них легко перейти к ощущениям: «вроде идем нормально» или «кажется, команда не успевает».
Но и самим цифрам я бы не отдавала право решать, хорошо идет проект или плохо.
Потому что измерить можно очень многое.
Гораздо сложнее выбрать то, что действительно показывает движение к нужному результату.
Share
