Search
Write a publication
Pull to refresh

Comments 9

Не раскрыт заголовок статьи - почему это ошибки ХОРОШЕГО продакта? Или себя не похвалишь, никто не похвалит?

ну почему не раскрыт? Во всех трех описанных мной случаях я совершала ошибки из самых лучших побуждений. в 1 случае пыталась разгрузить команду, во 2 - защитить от заказчиков, в 3 - не нагрузить команду сложной работой, которую делал Х. Словосочетание "Хороший PO", в данной статье, имеет значение - Хороший парень, за все хорошее и против всего плохого.
*да и похвалить себя никогда не вредно если есть за что.

Ну первые две ошибки любому понятно.
1. Вы по сути начали делать чужую работу, причем наверняка с точки зрения большинства вы ее сделали не достаточно хорошо, так как ваша команда это набор спецов а не школьников.
Самое печальное что вы даже не поняли что скорей всего унизили своих же коллег те фактом, что думаете что вы сделали за них работу как надо

  1. Опять же по сути завязали на себе процессы, и выступили просто какимто передатчиком, вы думаете что вы были фильтром но на деле сломанный телефон.
    ДАже если это не так то команда это воспримет сразу так.

  2. Тут ситуация сложная, но сам факт что допустили что за вашей спиной меняли приоритеты, это означает что вы не знаете что в команде происходит, и скорей всего этот Х не совсем удовлетворен своим положением.
    Работали с командой но не с ним получается.

Понимаете в чем дело, ошибки на то и ошибки, что они становятся явными и "любому понятными" по факту. Нет правильных ошибок. Было бы здорово, чтобы такие словоохотливые и понимающие люди как вы делились своим опытом управления командами и не боялись делиться своими ошибками, чтобы помочь начинающим PO.

Справедливый комментарий.

Попробуйте работать прям вместе с командой. То есть ребята сидят чтото делают, а вы как бы их сапортите.

Вообще на западе менеджмент это обслуживание непосредственно исполнителей. Мои менеджеры из США, имеющие по многим вопросам опыт просто огромный, приходят ко мне и спрашивают а надо ли мне помочь, хотя в РФ тоже самое сделают в приказном тоне и порядке.

А что касается чела Х, думаю стоит прям рядом с ним сидеть, и тешить его самолюие иногда.
так и говорить: Х мне очень нужно ваше экспертное мнение.
Рассказываете например ему то что вам не особо важно, и он будет и делать это за вас, так и еще и вы сможете проталкивать спокойнее свои решения, так как он будет причастен к ним. (но это прям реально осторожно)

Наивно верить в то, что успешное управление сложной динамической структурой, содержащей сплав формальных и фактических правил, некое количество входной и выходной информации и группу интеллектуальных ее преобразователей, члены которой обладают к тому же собственным сознанием, преференциями, привычками и амбициями, сводится к трём элементарным правилам «если А то Б», которые по своей сложности годятся разве что для управления одноклеточными организмами.

Воистину - менеджеру нужно либо читать много книг (то есть быть философом и психологом), либо не читать ни одной [профильной]. Иначе менеджер превращается в Прокруста.

Нет никаких универсальных правил в управлении командой - в этом (если вы это имели ввиду) я с вами согласна. Есть много переменных, которые будут корректировать действия. Именно по этому, статья-мнение не про правила, а про мои ошибки. Они у всех случаются, я посчитала возможным поделиться этим с теми, кто только начинает свой путь.

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

Думаю, все проблемы возникли из за того, что у вас в компании не налажены процессы разработки и обмена информацией с менеджментом. По сути, те задачи, которые вы на себя взяли, должен выполнять тимлид разработчиков, но ни в коем случае не продакт.

Общение с командой, постановка задач контроль исполнения, разговоры 1:1 - это типичная работа тимлида. Общение с клиентом вместе с руководителем проекта тоже. Меня, честно говоря, немного удивляет, чем у вас занимались тимлиды и начальник разработки в это время?

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

Sign up to leave a comment.

Articles