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
