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
