#management Формальное управление vs Реальность Когда в обсуждении проектов появляются термины «риск», «стратегия минимизации», «ответственность», запал от интересной задачи угасает. Если мы ещё и реестры по шаблону составляем и ответственных за риски назначаем, то совсем 🤢 Причина не в отсутствии желания заниматься управлением. Просто такие разговоры кажутся чем-то искусственным, оторванным от реальности. Мы не говорим в обычной жизни «займёмся планированием» или «надо минимизировать риск». В итоге качество планирования страдает, потому что этим не интересно заниматься всем кроме рук.проекта. Может и ему неинтересно, но так надо. А ещё формальные рассуждения и применение шаблонов из теории могут легко увести планы от реалистичности. Шаблон заполнили — всё правильно 🫣 Представим проект с несдвигаемым сроком запуска. Где-то в середине разработчикам нужно передать макеты. Обычно из этого получается веха «дизайн согласован». А мы знаем, что с ней бывает. Даже после прохождения вехи комментарии не заканчиваются. В плане появляется риск, что дизайн не будет согласован полностью и вовремя (рядовой риск из шаблонов реестров рисков). И мы пытаемся договориться о его минимизации и ответственности за влияние. Есть искушение заявить, что клиент отвечает за появление изменений в требованиях после вехи. Если такое произойдёт, может сдвинуться дедлайн. Но в реальности заказчик не может заранее согласиться утвердить то, чего пока не видит. У него резонный вопрос, а мы то, разработчики, за что тогда отвечаем? 🤔 Получится разговор об ответственности, рисках и маловероятных последствиях, в общем об управлении в отрыве от цели. Перекладывать ответственность за результат, который производим мы, — в принципе плохой подход. Поэтому конструктива будет минимум 👎 В лучшем случае нам молча кивнут. Но мы в любом случае не сможем поставить точку где-то в середине проекта. Изменения неизбежны, и это в принципе не риск. Поэтому вместо нравоучений о персональной ответственности лучше проговорить, как будет на самом деле: «Начинаем согласование дизайна за неделю, а 14 ноября запускаем разработку по имеющимся макетам. Все последующие изменения добавляем в общий бэклог до запуска, согласуем приоритеты и двигаемся дальше. Иначе мы можем не успеть гораздо больше» 👍 С таким планом адекватные люди спорить не будут. Они не скажут: «Нет, не запускаете без согласования». Всем нужен результат в срок. Это целеориентированный подход с разделением ответственности за получение результата, а не перекладыванием её за каждый отдельно взятый риск 🤝 Веху правильнее назвать «старт разработки». План выстраиваем так, чтобы недостаток «согласованности» дизайна не стопорил работу, и непредвиденные изменения не мешали релизить качественный результат в срок. Риски же нужно искать в других местах: интеграциях с внешними сервисами, кардинальных изменениях концепции проекта и пр. Лучшее управление, когда мы просто говорим, что именно собираемся сделать и почему это поможет нам вместе с заказчиком оптимальнее достичь цели в условиях ограничений. Для этого нужно использовать личный реальный опыт и прислушиваться к опыту членов команды. Ну или быть одарённым и обладать предвидением будущего на основе прошлого, как у Герберта в Дюне. Как вам такой подход?