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
