Какой объем управления проектами должен выполнять разработчик программного обеспечения?

Чтобы не быть слишком широким для начала, прямой вопрос будет:

Ожидается ли, что разработчик должен постоянно напоминать руководству проекта о функции, которая не реализована из-за нехватки ресурсов для ее реализации?

Правила такие: У нас есть доска с задачами в столбцах. Разработчик выбирает задачу в «OPEN» и начинает над ней работать. При этом он переводит задачу в состояние «В ПРОГРЕССЕ». Когда он закончит, задача переходит в «РАЗРАБОТКА ВЫПОЛНЕНА» (позже в тестирование). Но если что-то пойдет не так, задача должна быть переведена в «ОБРАТНУЮ СВЯЗЬ», где нужно что-то решить. Возможно дизайн отсутствует или какое-то описание неясно...

Довольно просто, если вы спросите меня.
По моему мнению, как разработчику, когда задача не может быть завершена, а ее тикет находится в «ОБРАТНОЙ СВЯЗИ», руководитель проекта обязан отслеживать функцию и прилагать усилия, чтобы найти человека, который может решить проблему с ней.

Но вот что произошло в нашей команде: Тикет был отправлен в "ОБРАТНУЮ СВЯЗЬ", так как не был реализован необходимый API. Тикет лежал там несколько месяцев (да, на самом деле около полугода), а затем в какой-то момент один из менеджеров проекта просто закрыл тикет, потому что другой менеджер проекта сообщил, что он передал проблему другой команде. Проходит еще месяц, и вдруг появляется эта незавершенная функция. Теперь один из менеджеров проекта в ярости и заявляет, что мы как разработчики обязаны отслеживать такие вещи и что он ожидает, что у нас есть какой-то список вещей, которые не сделаны.

Это правда? Должны ли мы как-то отслеживать какие-то дополнительные вещи рядом с уже имеющейся доской? Я ожидаю, что для таких вещей должно быть достаточно одной платы, и команда разработчиков сделала все возможное, чтобы предотвратить такой беспорядок. Если нет, есть ли у вас какие-либо рекомендации о том, как избежать таких проблем или как лучше отслеживать такие потенциальные проблемы?

Чтобы дать полную историю о том, как/что произошло:

Делаем мобильное приложение. Несколько месяцев назад мы получили запрос о том, что на определенном экране (редко видимом пользователем) может быть получена ошибка от API (из-за какой-то редкой ситуации). Теперь эта конкретная ошибка также будет сообщать о дополнительном коде ошибки. Поэтому, если возникает эта ошибка, будет добавлена ​​подошибка Aили подошибка . BИ в зависимости от этой подошибки приложение должно показывать screenAлибо screenB. Но API не предоставил Aни того, ни другого B, и выполненная задача не могла быть проверена или протестирована.

Так что тикет попал в "ОБРАТНУЮ СВЯЗЬ", объяснив это тем, что API просто не готов к этому. Но затем в заявке началось обсуждение о том, чтобы увидеть экран, просто чтобы проверить дизайн. Таким образом, разработчик добавил логику для случайного отображения screenAили screenBи сообщил об этом в заявке, которая все еще находилась в разделе «ОБРАТНАЯ СВЯЗЬ».

Прошли месяцы, и в какой-то момент один из менеджеров попытался справиться с этим. Поэтому он (я полагаю) сообщил об этом команде, отвечающей за API, и прокомментировал тикет, что-то вроде «Они сказали нам, что это ошибка на их стороне. Упомяните: theOtherPM, мы можем закрыть этот тикет сейчас?». И «ДругойПМ» закрыл тикет. Еще через месяц из-за этого разверзается ад, и я не понимаю, почему это вина нас, разработчиков.

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

Есть ли вообще возможность авторитетного ответа на это? Разве это не будет варьироваться от сайта к сайту/от команды к команде?
@MarkC.Wallace Надеюсь, что нет. Я бы полагал, что есть какие-то общие договоренности об обязанностях той или иной должности, которые должны объективно указывать в ту или иную сторону. Если нет, то «Это должно быть определено конкретно в вашей команде» также является допустимым ответом при условии, что у вас могут быть хотя бы некоторые аргументы для обеих сторон.
Как менеджер проекта, который также является опытным разработчиком, я бы ответил, что ваша команда несет ответственность за отслеживание задач, которые вы либо создаете для себя, либо которые назначаются вам извне. Именно вы фактически разрабатываете исходный код и, конечно же, хорошо знакомы с внутренними сложностями базовой реализации программного обеспечения. Руководители проектов обычно сосредотачиваются на более высоком и широком уровне: «сам проект». Они рассчитывают на то, что вы выполните эти биты и байты... правильно и наглядно.
Далее: представьте себя «экспертами в предметной области» (SMEs) того , как именно создается и отлаживается это приложение, чтобы оно точно и полностью соответствовало спецификации. Это ваша забота. Между тем, менеджеры проектов смотрят, например, на эту спецификацию... на среду, в которой будет функционировать приложение... на все другие проекты и рабочие группы, которые могут повлиять на вашу работу или на которые может повлиять ваша работа. на «что, а не как». Две параллельные, но разные точки зрения и обязанности, обе существенные!
@MikeRobinson Интересно. Звучит разумно. Но я с трудом мог реализовать это в нашем случае. Возможно, важно отметить, что «другая команда», которая обрабатывает API, не является командой, к которой у нас есть доступ. Что еще хуже, они даже не одна и та же компания. Таким образом, нет никакого способа обойти наших менеджеров проектов, чтобы получить необходимый нам ресурс. Поэтому мы, как команда разработчиков, уведомили их. На самом деле мы даже обсуждали это несколько раз с менеджерами проектов. И вроде бы все было под контролем, но в какой-то момент наш тикет закрыли и информация пропала. И ПМ закрыл его так...
Это во многом зависит от корпоративной культуры. Каждый делает это немного по-своему, по необходимости.
@MaticOblak Этот пункт о том, что команда API является третьей стороной, окажет довольно большое влияние на ответы (например, они, предположительно, не видят вашу доску Канбан, и от них нельзя ожидать, что они будут работать с билетами, о которых они даже не знают существует!), и я бы порекомендовал убедиться, что у вас есть список владельцев отношений для всех ваших Третьих сторон в будущем, и убедитесь, что они посещают по крайней мере одну встречу в неделю, чтобы получать и предоставлять отзывы и обновления.
Риторический вопрос: кто закрыл тикет?
Не то чтобы вы когда-либо должны «обходить менеджеров проектов, чтобы получить ресурсы!» Если есть проблема с удаленной командой, они должны знать об этом прямо сейчас. Нет, им не нужно знать подробности о битах и ​​байтах, но это то , что мешает проекту. // Очевидно, все дело в сбое связи. «Закрытие заявки» могло быть случайным или дезинформированным. Чтобы понять, нужно выяснить причину.

Ответы (2)

Ответственные и подотчетные роли в системе Pull-Queue

Вопрос, который вы задаете, на самом деле является проблемой X/Y. У вас есть пара других проблем, которые вы на самом деле не назвали в своем вопросе:

  1. Канбан — это система очереди вытягивания , а не система проталкивания. Таким образом, если команда API не знает, что нужно извлечь из вашего столбца «обратная связь», или если у них нет собственного журнала невыполненных работ, в который вы можете поместить рабочие элементы, неясно, почему они должны будут вытягивать работу (или даже знать об этом). ).
  2. Agile-фреймворки сильно зависят от межфункциональных коммуникаций. Если вы просто регистрируете статус заявок, а не сотрудничаете с заинтересованными сторонами, такими как команда API, тогда ваш процесс нарушен.
  3. Рабочие элементы, которые четко не связаны с вехой или результатом, не отслеживаются. Невозможно определить только по вашему вопросу, кто владеет этим в рамках текущего процесса вашей компании.
  4. Различия между ответственными и подотчетными ролями для вашего процесса либо не определены, либо недостаточно доведены до сведения.

Если у вас есть традиционные менеджеры проектов, отвечающие за проект, то они в конечном счете несут ответственность за отслеживание статуса рабочих элементов и предоставление соответствующих отчетов. Это верно независимо от того, делегируют ли они часть этой ответственности членам команды.

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

Проблема с вашим первым пунктом в том, что команда API не является частью нашей компании и является для нас скорее ресурсом. Команды разработчиков не имеют с ними прямой связи, поэтому наши продакт-менеджеры должны перенаправлять эту «ошибку» любыми средствами, которые у них есть (насколько я понимаю, у них открытое общение, даже еженедельные встречи, с другой компанией). Итак, этот тикет вытащил ПМ, процесс запустился, но тикет потерялся. Тогда это звучит так, как будто команда разработчиков должна иметь еще один Канбан, который будет отслеживать что-то еще не реализованное. Для меня это звучит странно.
Второй пункт также имеет аналогичную проблему, чем первый. Я должен согласиться, что в большинстве проектов, над которыми я работал, у нас было прямое сотрудничество и общение с другими командами в рамках проекта. Но так было не всегда и я не уверен, что это что-то ломает. Например, несколько лет назад я работал над пультом дистанционного управления iOS для дрона. Кроме всего прочего, мне нужно было интегрировать фреймворк, который делала другая компания на другом конце света. Фреймворк все еще находился в разработке, как и API в этом случае. Но я никогда не встречал команду, которая делала фреймворк. Это нет-нет?
Вывод интересный и как бы подводит к тому, что меня больше всего беспокоит: валы не четко обозначены, но в то же время, как только возникает проблема, на них указывают пальцем. Причина, по которой меня это беспокоит, заключается в том, что сама проблема не анализируется и не предпринимается никаких усилий для того, чтобы это больше не повторилось. И, к сожалению, это уже произошло дважды, и я до сих пор понятия не имею, как к этому подступиться. Вот почему я обратился к вам, ребята, за помощью. Спасибо.
Я согласен — пальцы указывают, и процесс совместной работы нарушен. Я думаю, что команды разработчиков и менеджеры по развитию , а не менеджеры проектов более высокого уровня , будут нести ответственность за общение с удаленными подрядчиками из-за уровня чисто технического контекста, необходимого для эффективного общения. "Кайбан" или нет, кто-то ни с кем не разговаривает, и прямо сейчас это стоит вам больших денег.

Я думаю, что у этого есть канонический ответ, по крайней мере, с традиционной точки зрения PM, если не с Agile, Kanban или чем-то еще.

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

Если в этом процессе что-то ломается и предмет теряется, ответственность за эту потерю лежит на PM или средствах контроля PM.

В таком высокотехнологичном сценарии, как этот, я бы предпочел сказать, что менеджер проекта несет ответственность за то, чтобы знать о существовании проблемы и знать, что она была своевременно решена. Я ожидаю, что менеджеры по развитию , работающие напрямую с «домашней командой», будут теми, кто общается с подрядчиками, постоянно предоставляя информацию PM, но не прося их быть посредниками. (У меня такое ощущение, что в организации ОП их просят сыграть эти роли...)
Роли могут быть определены многими способами. Однако некоторые определения ролей просто не будут иметь смысла. Я знаю, что большинство тем на этой бирже посвящено программному обеспечению, но я часто рассматриваю другие типы проектов, чтобы ответить на эти вопросы. Я думаю о сантехнике, выполнявшем жилищные работы, который столкнулся с блокировщиком из-за своей работы. Сантехник сообщает о проблеме, а затем уходит или уходит в другую часть дома. Я не могу представить, чтобы сантехник отвечал за перемещение блокиратора. Может потребоваться изменение контракта, изменение архитектуры, инженерное изменение. Недоступно для сантехника.
Какой объем управления проектами должен выполнять разработчик программного обеспечения?
СпросиСетьПолитика конфиденциальности1y, 0v