Обложка канала

Analysis Paradisis

Канал про системный анализ и управление IT-проектами. Обзоры книг по тематике, истории про IT-компании и полезная информация для аналитиков и менеджеров.

Analysis Paradisis

8 лет назад
Открыть в
Еще раз про разграничение обязанностей

Пока собираю мнения по поводу ТЗ, хочу еще раз затронуть тему разграничения обязанностей. Я уже писала про это раньше (см. выше - должен ли аналитик принимать разработческие решения), но ситуации "принимаю решения вне своей компетенции" встречаются чаще и касаются не только ТЗ.

Пример: бывший разработчик перешел на должность менеджера, но никак не хочет снимать с себя принятие технических решений. Идет время, система меняется, он уже не кодит, но на совещаниях продолжает "представлять мнение разработчиков", предпочитая не звать тех, кто действительно сейчас занимается разработкой.

Принимаемые им решения часто опираются на то, "как было раньше" или "как я считаю". В итоге, если на совещании достигнута какая-то договоренность, в реальной жизни оказывается, что так нельзя, и чаще всего на этапе, где поменять что-либо означает большой сдвиг сроков. Теряются время, силы и терпение участников процесса, теряется доверие команды, а менеджер становится "тем козлом, который принимает решения за нас". Будут ли хорошие отношения в такой команде? Нет.

Правильный подход будет в том, что, даже если бывший разработчик разбирается в технических моментах лучше (или думает так), нужно спрашивать того, кто ответственен за разработку сейчас. В процессе обсуждения либо бывший разработчик докажет текущему, что так действительно лучше, либо текущий расскажет бывшему новые нюансы работы системы.

Что делать: переходя на новую должность, отпускайте от себя прошлые обязанности, учитесь делегировать и максимум - давать советы. Потому что, решая что-то за кого-то, вы и решения правильные рано или поздно перестанете принимать, и отношения с командой испортите.