👨💻 Почему ПМ игнорирует мнение разработчика и спрашивает других?
Знакомая ситуация. Вы работаете над задачей, разобрались в контексте, изучили все нюансы. Приходит ПМ, задает вопросы, вы подробно объясняете свое видение. А потом оказывается, что решение принято на основе мнения других разработчиков, которые в контекст вообще не погружены.
Это одна из самых раздражающих ситуаций в разработке. И она возникает не от злого умысла, а от того, как устроены процессы в команде.
В чем суть проблемы:
Разработчик, который работает над задачей, видит ее целиком. Он знает нюансы, проблемы, ограничения, потенциальные риски. Его мнение основано на реальном опыте работы с кодом и контекстом.
Когда ПМ спрашивает других разработчиков, не погруженных в задачу, он получает мнения, основанные на догадках или поверхностном анализе. Это не делает их плохими разработчиками, они просто не видят всей картины.
Когда подключается лид команды или всего проекта:
Бывает еще хуже. ПМ идет не к разработчикам, а к лиду команды или всего проекта. Тоже не погруженным в детали конкретной задачи, но имеющим авторитет. И решение принимается на основе их мнения.
Лид команды или всего проекта часто дают ответ в духе «ну, наверное, так можно сделать». Они не видели код, не знают всех ограничений, но их слово оказывается решающим. Потому что у них есть статус.
При этом вы, потративший время на анализ, остаетесь в стороне. Ваше экспертное мнение не учитывается. А решение принимается на основе предположений того, кто просто не успел вникнуть в задачу за счет высокой загруженности.
Почему ПМ так поступает:
Причин несколько. И почти все они плохие.
🔹Первая: недоверие. ПМ может не доверять вам. Не потому, что вы плохой специалист, а потому, что не сложилось доверия, или он не понимает, насколько глубоко вы погружены в задачу. Возможно, вы уже допускали ошибки в прошлом. Или просто стиль общения не совпадает.
🔹Вторая: желание ускорить процесс. ПМ считает, что не хочет тратить время на обсуждение с вами, а хочет быстро получить ответ от того, кто, по его мнению, скажет быстрее. Но это иллюзия. Быстрое решение без контекста почти всегда хуже, чем правильное решение с небольшим обсуждением.
🔹Третья: попытка выслужиться перед руководством. ПМ хочет показать, что он быстро решает вопросы. Он не хочет выглядеть нерешительным или тратить время на уточнения. Ему нужно закрыть вопрос и он выбирает способ, который кажется ему более оперативным. Даже если это приводит к ошибке.
🔹Четвертая: обычная некомпетентность. ПМ не понимает, почему погруженный в задачу разработчик важен. Он не отличает мнение от экспертизы.
🔗 Читать подробнее
💡 Вывод:
Когда ПМ игнорирует мнение разработчика, погруженного в задачу и обращается к лиду или другим разработчикам, не владеющим контекстом, страдает не только сам разработчик. Страдает качество решений и вся команда. Доверие падает, вовлеченность снижается, а процессы становятся менее эффективными.
Важно, чтобы ПМ понимал: эксперт, работающий над задачей, видит ее иначе, чем кто-то со стороны. И его мнение должно иметь больший вес. А разработчикам стоит не молчать, а аргументированно отстаивать свою позицию. Потому что, если не доносить свою экспертизу, ее никто не увидит.
Подписаться на канал:
➡️ Кот Денисова
Знакомая ситуация. Вы работаете над задачей, разобрались в контексте, изучили все нюансы. Приходит ПМ, задает вопросы, вы подробно объясняете свое видение. А потом оказывается, что решение принято на основе мнения других разработчиков, которые в контекст вообще не погружены.
Это одна из самых раздражающих ситуаций в разработке. И она возникает не от злого умысла, а от того, как устроены процессы в команде.
В чем суть проблемы:
Разработчик, который работает над задачей, видит ее целиком. Он знает нюансы, проблемы, ограничения, потенциальные риски. Его мнение основано на реальном опыте работы с кодом и контекстом.
Когда ПМ спрашивает других разработчиков, не погруженных в задачу, он получает мнения, основанные на догадках или поверхностном анализе. Это не делает их плохими разработчиками, они просто не видят всей картины.
Когда подключается лид команды или всего проекта:
Бывает еще хуже. ПМ идет не к разработчикам, а к лиду команды или всего проекта. Тоже не погруженным в детали конкретной задачи, но имеющим авторитет. И решение принимается на основе их мнения.
Лид команды или всего проекта часто дают ответ в духе «ну, наверное, так можно сделать». Они не видели код, не знают всех ограничений, но их слово оказывается решающим. Потому что у них есть статус.
При этом вы, потративший время на анализ, остаетесь в стороне. Ваше экспертное мнение не учитывается. А решение принимается на основе предположений того, кто просто не успел вникнуть в задачу за счет высокой загруженности.
Почему ПМ так поступает:
Причин несколько. И почти все они плохие.
🔹Первая: недоверие. ПМ может не доверять вам. Не потому, что вы плохой специалист, а потому, что не сложилось доверия, или он не понимает, насколько глубоко вы погружены в задачу. Возможно, вы уже допускали ошибки в прошлом. Или просто стиль общения не совпадает.
🔹Вторая: желание ускорить процесс. ПМ считает, что не хочет тратить время на обсуждение с вами, а хочет быстро получить ответ от того, кто, по его мнению, скажет быстрее. Но это иллюзия. Быстрое решение без контекста почти всегда хуже, чем правильное решение с небольшим обсуждением.
🔹Третья: попытка выслужиться перед руководством. ПМ хочет показать, что он быстро решает вопросы. Он не хочет выглядеть нерешительным или тратить время на уточнения. Ему нужно закрыть вопрос и он выбирает способ, который кажется ему более оперативным. Даже если это приводит к ошибке.
🔹Четвертая: обычная некомпетентность. ПМ не понимает, почему погруженный в задачу разработчик важен. Он не отличает мнение от экспертизы.
🔗 Читать подробнее
💡 Вывод:
Когда ПМ игнорирует мнение разработчика, погруженного в задачу и обращается к лиду или другим разработчикам, не владеющим контекстом, страдает не только сам разработчик. Страдает качество решений и вся команда. Доверие падает, вовлеченность снижается, а процессы становятся менее эффективными.
Важно, чтобы ПМ понимал: эксперт, работающий над задачей, видит ее иначе, чем кто-то со стороны. И его мнение должно иметь больший вес. А разработчикам стоит не молчать, а аргументированно отстаивать свою позицию. Потому что, если не доносить свою экспертизу, ее никто не увидит.
Подписаться на канал:
➡️ Кот Денисова