2021-11-02 22:50:42
#синдром_самозванца
Сегодня смотрела в Laba занятие по управлению изменениями в проекте. Супер полезная тема, с которой я сталкиваюсь в работе ежедневно.
Неважно, что мы делаем: разрабатываем проект с нуля, ведем техподдержку или занимаемся SEO-продвижением, изменения — это то, что происходит с нашими проектами постоянно
Меня на работе можно представлять так: я сижу на фоне окна, за которым очень быстро сменяются времена года, и 24/7 записываю в To Do List (в CliсkUp, в блокнотики, на стикеры) задачи для развития проектов.
Иногда мне кажется, что 24/7 — это вовсе не шутка поэтому мне так важно держать руку на пульсе и управлять этими изменениями — чтобы ничего не упустить.
Собственно, обсудили откуда появляется необходимость этих изменений, кто может быть их инициатором (очевидный спойлер: это может быть не только заказчик, но и сама команда), как управлять изменениями, а также как работать с возражениями, которые могут возникать в процессе обсуждения всех предстоящих доработок.
В целом, алгоритм работы с изменениями весьма прост.
Когда они появляются:
— занесите изменение в журнал (Google Sheets, Backlog — куда вам там удобнее);
— выясните ожидания стейкхолдеров — чего они хотят добиться, предлагая такую доработку;
— оцените ее необходимость и полезность, попробуйте рассчитать бизнес-value (бывает, что 90% предложенных изменений являются всего лишь гипотезами и не имеют под собой основательной причины для реализации);
— совместно со всеми стейкхолдерами примите решение, касательно этого изменения: быть ему или не быть (вот в чем вопрос );
— дополните журнал новой информацией о доработке (например, опишите результат реализации или причину отказа от изменения, а также другую полезную информацию и выводы).
У меня таких файликов — завались, я называю их «реестрами доработок». По каким-то проектам они совсем маленькие, а по каким-то раздуваются до пугающих размеров. Иногда эти "раздутыши" здорово демотивируют, поэтому одна из полезных мыслей, которую я вынесла из сегодняшнего урока, была такая:
"На самом деле, возражения и изменения в проекте — это хорошо: значит, стейкхолдерам не наплевать на проект; значит, они в нем заинтересованы; значит, есть шанс создать реально классный продукт."
Да и как оказалось, в средних по размеру проектах без четкого технического задания (а таких у нас большинство — когда заказчик приходит и просто верхнеуровнего называет нам свои требования и пожелания) — 50-70 штук изменений — нормальное количество.
Но всегда стоит помнить, что наиболее удачной идеей развития проекта является запуск MVP и его дальнейшая доработка на основе обратной связи от реальных пользователей, а не раздувание первоначальных сроков запуска и ожиданий от проекта за счет тех самых спорных гипотез.
89 views19:50
С
