Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Насчет микроменеджмента очень ярко — значит когда команду занесет в «создание фреймворка» ПМР должен сидеть и утираться званием «хорошего» ПМ :)
Хороший ПМ это человек который разбирается во всех вопросах и умеет принимать быстрые решения. Поэтому для программистов хорошего ПМ не существует :)
Хороший ПМ это человек который разбирается во всех вопросах и умеет принимать быстрые решения. Поэтому для программистов хорошего ПМ не существует :)
Согласен — очень сложно назвать объективно хорошим специалистом человека, который вместо того, чтобы позволить мне (программисту) увлеченно работать над интерессной задачей, говорит что эта задача (новый уникальный супер-фреймворк, например) продукту не нужна и вообще я еще на прошлой неделе должен был доработать класс для решения какой-то задачи, которая вообще никогда решаться не будет (с точки зрения опять же программиста).
А как на вашем уникальном супер-фреймворке можно заработать в ближайшей перспективе?
Или вы там .NET Framework пилите?
Или вы там .NET Framework пилите?
ну пример подверждает мое утверждение. я о том же :)
Рассмотрим два варианта:
(идеальный для программиста) 1. ПМ приходит к программисту и говорит — мне нужны четыре фичи, хочу попробовать поднять доход с клиента, когда будут? Ответ мммм тут очень интересный фреймворк, через полгодика подойди и я твои фичи сделаю с помощью фреймворка за 5 минут (а мог бы сделать за час без него)… ПМ тихо курит в углу, он хороший, конкуренты давно выпустили фичи и они не нужны уже а под них делается УДОБНАЯ система. Контора вылетела с рынка, фремворк вянет в углу склада.
(идеальный для ПМ) 2. ПМ приходит к программисту и говорит — мне нужны четыре фичи, хочу попробовать поднять доход с клиента, когда будут? Ответ: делаю, в течении часа будут в тестах через день можно будет в продакшн выдать, но… у нас накапливается технический долг. я бы хотел выделить день раз в две недели просто на рефакторинг, не возражаете? (ответ понятен я думаю)
(реальный из жизни) 3. ПМ приходит к программисту и говорит — мне нужны четыре фичи, жду через пол-часа, возражения не принимаются. ПМ плохой но кто мешал программеру пойти по пути 2?
Рассмотрим два варианта:
(идеальный для программиста) 1. ПМ приходит к программисту и говорит — мне нужны четыре фичи, хочу попробовать поднять доход с клиента, когда будут? Ответ мммм тут очень интересный фреймворк, через полгодика подойди и я твои фичи сделаю с помощью фреймворка за 5 минут (а мог бы сделать за час без него)… ПМ тихо курит в углу, он хороший, конкуренты давно выпустили фичи и они не нужны уже а под них делается УДОБНАЯ система. Контора вылетела с рынка, фремворк вянет в углу склада.
(идеальный для ПМ) 2. ПМ приходит к программисту и говорит — мне нужны четыре фичи, хочу попробовать поднять доход с клиента, когда будут? Ответ: делаю, в течении часа будут в тестах через день можно будет в продакшн выдать, но… у нас накапливается технический долг. я бы хотел выделить день раз в две недели просто на рефакторинг, не возражаете? (ответ понятен я думаю)
(реальный из жизни) 3. ПМ приходит к программисту и говорит — мне нужны четыре фичи, жду через пол-часа, возражения не принимаются. ПМ плохой но кто мешал программеру пойти по пути 2?
Это похоже на два диаметрально противоположных подхода в управлении.
В мотивированной на результат и самоорганизованной комманде никто не будет срывать сроки разрабатывая сначала фреймворк.
Будет первое приближение в виде быстро реализованной фиче, решающей задачу пользователя. Либо наипростейшая(за несколько дней) версия фреймворка, создающая именно эту фичу. Если подобных фич будет еще множество в будущем, то параллельно с основной функциональностью, будет создаваться полноценный фреймворк.
Хороший PM в этом случае постарается так сместить приоритеты, чтобы подобные фичи реализовывались тогда, когда будет частично готов инструментарий
В мотивированной на результат и самоорганизованной комманде никто не будет срывать сроки разрабатывая сначала фреймворк.
Будет первое приближение в виде быстро реализованной фиче, решающей задачу пользователя. Либо наипростейшая(за несколько дней) версия фреймворка, создающая именно эту фичу. Если подобных фич будет еще множество в будущем, то параллельно с основной функциональностью, будет создаваться полноценный фреймворк.
Хороший PM в этом случае постарается так сместить приоритеты, чтобы подобные фичи реализовывались тогда, когда будет частично готов инструментарий
> доказывать дизайнеру, что кнопка должна быть зеленой и справа
Пусть лучше она будет красной и слева?
ПМу затем и нужно в целевой области разбираться, чтобы явную чушь не пропускать.
Пусть лучше она будет красной и слева?
ПМу затем и нужно в целевой области разбираться, чтобы явную чушь не пропускать.
Разбираться нужно. В дизайне вообще любой человек разбирается, как футболе и политике. Просто дизайнеров это бесит. Не пропускать это одно, а влезать работу и говорить где, как и что переделать — это другое.
Одно дело сказать:
И совсем другое
Это никуда не годится. Кнопка должна быть не красная, а зеленая. Не слева, а справа
И совсем другое
Супер! Мне очень нравится. А что если попробовать перекрасить кнопку, допустим, в зеленый, и переместить влево? Возможно будет еще лучше!
Большая часть статей и книг о Product Owner/Product ManagerВам не приходило в голову, что это абсолютно разные роли по сравнению с project manager?
да, и у меня складывается в последнее время стойкое ощущение из моего личного опыта, что это очень не есть хорошо, когда эти две роли выполняет один человек
Это все уже проходили, когда это были две разные роли. Потом появился Product Owner и agile. Если продукт не общается с командой лично, вероятность получить на выходе что они хотел резко уменьшается.
С вашим аргументом я полностью согласен. Но общаться лично с командой — это не значит выполнять функции ПМ
Вы правы, есть и такая модель.
Из того что я видел. Разбивка Product + Project встречается часто, например, Касперский или Яндекс. В Google или MS скорее это вункции engineering менеджера.
По сути Project в Яндексе или младший Product, например, в MS это одно и тоже. Оба сосредоточены на в первую очередь исполнении, могут принимать мелкие решения по доработке продукта и т.д.
Из того что я видел. Разбивка Product + Project встречается часто, например, Касперский или Яндекс. В Google или MS скорее это вункции engineering менеджера.
По сути Project в Яндексе или младший Product, например, в MS это одно и тоже. Оба сосредоточены на в первую очередь исполнении, могут принимать мелкие решения по доработке продукта и т.д.
Есть два типа программистов (как и любых сотрудников):
1. которые умеют сами создавать и решать. Им не нужно мешать и навязывать сроки.
2. которые умеют поддерживать и закрывать дыры. Это производство. Где вы видели, чтобы на производстве спрашивали «Петров, сколько тапочек ты сможешь сделать?».
Нужно уметь разделять умных и красивых.
1. которые умеют сами создавать и решать. Им не нужно мешать и навязывать сроки.
2. которые умеют поддерживать и закрывать дыры. Это производство. Где вы видели, чтобы на производстве спрашивали «Петров, сколько тапочек ты сможешь сделать?».
Нужно уметь разделять умных и красивых.
ПМ во время оно блестяще развалили одну из дочек ГК «Оптима» :)
Одна из их и наших бед — это незнание нормативов трудоемкости тех или иных работ, выполняемых подразделениями под оперативным подчинением РП. РП ради собственного бонуса расписывают совершенно нереальные план-графики, к примеру, под разработку техзадания на систему электронного документооборота крупной газодобывающей компании был определен срок примерно в неделю. Полный абсурд, конечно.
С РП можно очень продуктивно бороться. На совещании в присутствии генерального мы как-то открыли замечательный, но, к сожалению, отмененный документ «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости. — Отраслевой стандарт ОСТ 4.071.030», в котором на разработку ТЗ средней сложности отводится чуть ли не год времени. Естественно, были возражения, что документ давно отменен, на что мы заявили, что даже если за 20 лет мы научились работать во много раз быстрее, то все равно на ТЗ должно отводиться не менее 3-х месяцев. В итоге компромисс был достигнут, больше РП безумные сроки нам не ставили.
Еще был прикол от начальника техписовского отдела. Он нарыл ГОСТ Р, полностью цельнотянутый с какого-то австралийского стандарта, в котором прописано было четко, что техпис должен писать не более 20 страниц нового текста в месяц, т.е. примерно по странице в день, и носился с этим стандартом по начальственным кабинетам. В итоге, разумеется, он победил всех :)
Слава богу, что уже лет восемь как не работаю наймитом, а веду собственный бизнес. Но впечатления от РП остались как об очень нехороших и тупо-упертых индивидах…
Одна из их и наших бед — это незнание нормативов трудоемкости тех или иных работ, выполняемых подразделениями под оперативным подчинением РП. РП ради собственного бонуса расписывают совершенно нереальные план-графики, к примеру, под разработку техзадания на систему электронного документооборота крупной газодобывающей компании был определен срок примерно в неделю. Полный абсурд, конечно.
С РП можно очень продуктивно бороться. На совещании в присутствии генерального мы как-то открыли замечательный, но, к сожалению, отмененный документ «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости. — Отраслевой стандарт ОСТ 4.071.030», в котором на разработку ТЗ средней сложности отводится чуть ли не год времени. Естественно, были возражения, что документ давно отменен, на что мы заявили, что даже если за 20 лет мы научились работать во много раз быстрее, то все равно на ТЗ должно отводиться не менее 3-х месяцев. В итоге компромисс был достигнут, больше РП безумные сроки нам не ставили.
Еще был прикол от начальника техписовского отдела. Он нарыл ГОСТ Р, полностью цельнотянутый с какого-то австралийского стандарта, в котором прописано было четко, что техпис должен писать не более 20 страниц нового текста в месяц, т.е. примерно по странице в день, и носился с этим стандартом по начальственным кабинетам. В итоге, разумеется, он победил всех :)
Слава богу, что уже лет восемь как не работаю наймитом, а веду собственный бизнес. Но впечатления от РП остались как об очень нехороших и тупо-упертых индивидах…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководитель продукта глазами разработчиков