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?"
Мне кажется, у начинающего руководителя проекта есть довольно неприятная ловушка.
Ты сидишь на встрече с разработчиками. Обсуждают технический вопрос.
Все кивают.
А ты в какой-то момент понимаешь, что примерно половину не поняла :)
И вот здесь очень хочется тоже кивнуть.
Потому что неудобно остановить разговор и сказать: «Подождите, а можете объяснить еще раз?»
Особенно если объясняли уже дважды.
Кажется, что руководитель проекта должен разбираться во всем. Иначе зачем он вообще здесь?
Но проблема начинается немного позже.
После встречи нужно объяснить заказчику, почему решение займет больше времени. Или от чего зависит следующий этап. Или какое решение сейчас требуется от бизнеса.
И тут выясняется, что технические слова ты запомнила, а смысл — не совсем.
Мне кажется, в такой ситуации гораздо профессиональнее переспросить.
Причем не обязательно пытаться разобраться в технической части на уровне разработчика.
Можно сказать совсем просто:
«Правильно ли я поняла: без этого изменения мы не сможем начать следующий этап?»
Или:
«Если объяснить это человеку без технического опыта, в чем сейчас основная проблема?»
Еще мне нравится вопрос:
«Что из этого мне важно понимать для управления проектом, а что уже относится к вашей технической работе?»
Потому что руководителю проекта действительно не нужно знать все.
Но ему нужно понимать достаточно, чтобы видеть последствия, зависимости и решения, которые требуются от других участников.
И здесь, мне кажется, есть довольно важная разница.
Не знать — нормально.
Опаснее сделать вид, что понял, а потом на основании этого принять решение или передать другим совсем не тот смысл.
Поэтому если после объяснения я все еще не могу своими словами сказать, что произошло, на что это влияет и что теперь нужно сделать, я бы спросила еще раз.
Даже если это уже третий раз :)
Пять минут неловкости на встрече обычно обходятся проекту дешевле, чем очень уверенно понятая неправильно информация.
Share
