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
