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
