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