Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
позвольте теперь мне крик души))
не всякий случай показывает, что плох именно РМ. Иногда разрабы просто слишком звёздные и гениальные — им как ни переводи, всё равно будут делать по-своему...«потому что он вот такой герой и лучше знает, чё рынку надо». Хотя сам даже стакан семечек в метро не сможет продать. наверное, всё-таки должен присутствовать баланс интересов и разумная дистанция с чётко очерченным кругом обязанностей.
ПС. Говорю с позиции РМ, извините)))
не всякий случай показывает, что плох именно РМ. Иногда разрабы просто слишком звёздные и гениальные — им как ни переводи, всё равно будут делать по-своему...«потому что он вот такой герой и лучше знает, чё рынку надо». Хотя сам даже стакан семечек в метро не сможет продать. наверное, всё-таки должен присутствовать баланс интересов и разумная дистанция с чётко очерченным кругом обязанностей.
ПС. Говорю с позиции РМ, извините)))
слишком звёздные
Извините, это не оскорбление?
Хотя сам даже стакан семечек в метро не сможет продать
Извините, это не оскорбление?
Вы тролль?
> всё равно будут делать по-своему
За вот это очень цепляется глаз. Продакт — принимает решение о направлении развития и формирует бизнес-требования. Разработчик — реализует их (а хороший разработчик еще и предлагает технические оптимизации, не видные продакту). Если разработчик что-то кодит самовольно, это явный косяк процессов. Можно задуматься, почему так происходит и кто в этом виноват (явно не разработчик, если продакт позволяет ему делать то, что описано выше; тут либо что-то не так с авторитетом продакта, либо нежелание экскалировать ситуацию и привлечь людей выше по должности). В любом случае, такое надо исправлять.
> стакан семечек в метро не сможет продать
Звучит правда немного обидно. Все вроде бы понимают, что продавать семки в метро — не задача разработчика. Как и продакта — разбираться во внутренностях линукса.
За вот это очень цепляется глаз. Продакт — принимает решение о направлении развития и формирует бизнес-требования. Разработчик — реализует их (а хороший разработчик еще и предлагает технические оптимизации, не видные продакту). Если разработчик что-то кодит самовольно, это явный косяк процессов. Можно задуматься, почему так происходит и кто в этом виноват (явно не разработчик, если продакт позволяет ему делать то, что описано выше; тут либо что-то не так с авторитетом продакта, либо нежелание экскалировать ситуацию и привлечь людей выше по должности). В любом случае, такое надо исправлять.
> стакан семечек в метро не сможет продать
Звучит правда немного обидно. Все вроде бы понимают, что продавать семки в метро — не задача разработчика. Как и продакта — разбираться во внутренностях линукса.
PM — Project Manager?
Канонический проджект менеджер должен шарить «в переводе с языка бизнес-задач в язык разработчиков и обратно»?
Канонический проджект менеджер должен шарить «в переводе с языка бизнес-задач в язык разработчиков и обратно»?
PM — Project Manager?
Да.
silent_jeronimo
Я, возможно, немного отстал от жизни, и все уже переменилось…
Можете дать ссылку на гайд, фреймворк, или еще что-нибудь, чем руководствуются современные проджект менеджеры, в котором явным образом упоминается обязанность PM про перевод бизнес-требований на технический язык?
Всегда думал, что единственная обязанность PM — завершить успешно проект. А переводит на технический он сам, или отдельный специально-обученный человек, в общем случае не важно.
Я, возможно, немного отстал от жизни, и все уже переменилось…
Можете дать ссылку на гайд, фреймворк, или еще что-нибудь, чем руководствуются современные проджект менеджеры, в котором явным образом упоминается обязанность PM про перевод бизнес-требований на технический язык?
Всегда думал, что единственная обязанность PM — завершить успешно проект. А переводит на технический он сам, или отдельный специально-обученный человек, в общем случае не важно.
это крик души или что?
или просто констатация общеизвестных фактов?
что-то не увидел пользы от статьи.
или просто констатация общеизвестных фактов?
что-то не увидел пользы от статьи.
Как раз пропущенный раздел «Решения» и было бы интересно почитать.
Моё скромное имхо: если разработчик две недели работал над кодом и получил в результате «не мышонка, не лягушку, а неведому зверушку» — то тут надо дать по шапке тимлиду. В именно его задачи входит мониторинг, кто какую проблему решает и осмысленные ли ресурсы туда вкладываются. Такое должно вылезти на ежедневных митапах, если они внедрены в процесс, т.е. масимум через два дня. А две недели — это полный фейспалм и бесконтрольность.
Еще достаточно полезно, если разделены «технические» и «бизнесовые» задачи и люди, ответственные за их постановку. Технические («перед новой фичей надо бы код такого-то сервиса порефакторить, а то там полный трэш», «оу, тут на днях новый лтс дотнета вышел, надо бы потихоньку обновиться») ставит тимлид, а бизнесовые — продакт.
Моё скромное имхо: если разработчик две недели работал над кодом и получил в результате «не мышонка, не лягушку, а неведому зверушку» — то тут надо дать по шапке тимлиду. В именно его задачи входит мониторинг, кто какую проблему решает и осмысленные ли ресурсы туда вкладываются. Такое должно вылезти на ежедневных митапах, если они внедрены в процесс, т.е. масимум через два дня. А две недели — это полный фейспалм и бесконтрольность.
Еще достаточно полезно, если разделены «технические» и «бизнесовые» задачи и люди, ответственные за их постановку. Технические («перед новой фичей надо бы код такого-то сервиса порефакторить, а то там полный трэш», «оу, тут на днях новый лтс дотнета вышел, надо бы потихоньку обновиться») ставит тимлид, а бизнесовые — продакт.
В именно его задачи входит мониторинг, кто какую проблему решает и осмысленные ли ресурсы туда вкладываются.
Да, в том числе, проблема: наблюдаемость процесса разработки. Вы правы.
Еще достаточно полезно, если разделены «технические» и «бизнесовые» задачи и люди, ответственные за их постановку.
Спасибо за идею
Как раз пропущенный раздел «Решения» и было бы интересно почитать.
Исходил из того, что в формулировке проблемы есть часть решения. В то же время, конкретные проектные решения могут быть очень разные. Поэтому, этот шаг за читателем.
Agile? Погрузить в тему команду разработки, модерировать артефактами, показывать цели?
Похоже у вас в команде не хватает исполнителей как минимум следующих ролей:
1. Продакт (это если вы делаете продукт) — будет говорить зачем пользователю ваш продукт.
2. Аналитик — он как раз и будет переводчиком с русского языка бизнеса на русский язык разработчика.
3. Архитектор — будет проектировать то как должен быть устроен ваш продукт.
4. Тимлид (выше уже говорили про него) — будет управлять командой разработчиков.
А вы пытаетесь все эти роли + ваши назывные ПМ и Разработчик уложить в двух людей и удивляетесь почему же вы не можете найти общий язык. Если вы оба не многорукие гуру и не являетесь гениями в коммуникации (что уже очевидно не так), то и не сможете.
1. Продакт (это если вы делаете продукт) — будет говорить зачем пользователю ваш продукт.
2. Аналитик — он как раз и будет переводчиком с русского языка бизнеса на русский язык разработчика.
3. Архитектор — будет проектировать то как должен быть устроен ваш продукт.
4. Тимлид (выше уже говорили про него) — будет управлять командой разработчиков.
А вы пытаетесь все эти роли + ваши назывные ПМ и Разработчик уложить в двух людей и удивляетесь почему же вы не можете найти общий язык. Если вы оба не многорукие гуру и не являетесь гениями в коммуникации (что уже очевидно не так), то и не сможете.
Если РП работает, то диалог есть постоянно. Если РП хорошо работает, то такая ситуация «внезапно» через 2 недели не может случиться.
Перечисление симптомов. Было бы круто построить причинно-следственные связи и найти ключевую проблему, решив которую общие проблемы отваливаются пачками.
На вопрос: «Сколько тебе надо времени на решение этой задачи?», ответ программиста: «От 20 минут до двух недель» — это вполне нормально.
Ненормально, когда программист, а если он хороший, то у него мозги многопоточные, сидит и тупит над одной задачей.
В этом кстати проблема скрама. На короткой иттерации мало задач, а часто одна, приходится сидеть и тупить, вместо того, чтобы заняться тем, что идет.
Бывает так. Программист сидит тупит, сроки, обещания, все сорвано, а решения нет. Занялся другой задачей, отвлекся, и вдуг пришло озарение, вернулся на эту задачу и за 20 минут все закрыл.
Я — РП, никогда не программировал, но программистов строить обычными методами типа жесткие сроки, особенно, если разработка сложная, это крайне неэффективно.
Мне нравится тема в ТОС (теория ограничений) по управлению проектами. Там важно построить Критическую цепь проекта и контроль и управление сводится к критическим нескольким точкам, а не срокам по каждой задаче.
На вопрос: «Сколько тебе надо времени на решение этой задачи?», ответ программиста: «От 20 минут до двух недель» — это вполне нормально.
Ненормально, когда программист, а если он хороший, то у него мозги многопоточные, сидит и тупит над одной задачей.
В этом кстати проблема скрама. На короткой иттерации мало задач, а часто одна, приходится сидеть и тупить, вместо того, чтобы заняться тем, что идет.
Бывает так. Программист сидит тупит, сроки, обещания, все сорвано, а решения нет. Занялся другой задачей, отвлекся, и вдуг пришло озарение, вернулся на эту задачу и за 20 минут все закрыл.
Я — РП, никогда не программировал, но программистов строить обычными методами типа жесткие сроки, особенно, если разработка сложная, это крайне неэффективно.
Мне нравится тема в ТОС (теория ограничений) по управлению проектами. Там важно построить Критическую цепь проекта и контроль и управление сводится к критическим нескольким точкам, а не срокам по каждой задаче.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Важность диалога между PM-ом и разработчиком