Я пытаюсь внедрить протокол технических запросов в своей очень большой и разнообразной компании. Проблема в том, что этот протокол существует уже много лет, но он так и не был реализован эффективно, так как многие запрашивающие обращаются к разработчикам с неофициальными, личными запросами и/или запрашивают по электронной почте/телефонному звонку/лично, не заполняя форму. Это приводит к недопониманию и неясности. Каковы некоторые эффективные стратегии для реализации этого протокола?
«Никогда не вводите управленческие изменения без предварительного введения управленческих изменений». Марк Хорстман, http://www.manager-tools.com
Поскольку протокол никогда не применялся эффективно, начните сначала. У вас сейчас фактически нет протокола, поэтому начните реализацию заново.
Начните с пересмотра того, почему вам нужен такой протокол, преимущества для организации и для отдельных лиц в организации. (У других респондентов есть некоторые указания в этом направлении.) Рассмотрите возможность изменения протокола — если вы проконсультируетесь с заинтересованными сторонами на обоих концах запроса, вы можете обнаружить другие подходы к решению тех же проблем.
Затем внести в протокол как изменение. Не обращайте внимания на то, что его нужно было использовать все время. Следуйте передовым методам управления организационными изменениями — просмотрите изменение индивидуально, по крайней мере, с репрезентативной подгруппой затронутых лиц, объявите об этом в организации, представьте изменение организационным подразделениям, которые будут затронуты, предоставьте материалы задолго до даты внедрения изменения и т. д. на. Поиск в Интернете по запросу «управление изменениями» откроет много ресурсов, если вы еще не обладаете этим навыком.
После того, как изменение было реализовано, следование протоколу теперь является управленческим упражнением. А как это делается — это другой вопрос, выходящий далеко за рамки личной продуктивности.
Вопрос, который вам нужно задать, заключается в том, почему эти люди не используют форму. Не проще ли просто связаться с человеком напрямую? Если это так, то нет причин для их изменения. Они сочтут ваш план раздражающим и неэффективным.
Если для них нет прямой выгоды, вам, возможно, придется посмотреть в противоположном направлении - официальное заявление сверху, в котором говорится, что если они не следуют процедуре, их проект не будет реализован, их изменение не будет одобрено или они будут наказаны. каким-либо образом (более низкая оценка при ежегодном обзоре и т. д.)
Звучит жестко, но если процесс не принесет им пользы, этого не произойдет.
Разработчиков никогда не должны беспокоить разные люди с запросами функций. Вместо этого владелец продукта обязан действовать как привратник, принимая к сведению все запросы и расставляя приоритеты для элементов невыполненной работы. Если в вашей организации нет этих ролей, вы должны ввести их, прежде чем решать проблему с формой.
джморт253