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

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

У нас также есть менеджер программного обеспечения, который мой начальник. Он заставляет меня писать и поддерживать расписание программного обеспечения, проектную документацию (проектирование высокого и низкого уровня), SRS, управление изменениями, планы проверки и отчеты, управление выпусками, обзоры и, конечно, программное обеспечение.

У нас только один инженер по тестированию для всей команды разработчиков (10 человек), и в любой момент времени выполняется несколько проектов.

Я трачу 80% своего времени на создание этих документов. Мой начальник имеет опыт работы с процессами и считает, что нам нужна лучшая документация для улучшения программного обеспечения:

1. Он считает, что дизайн имеет первостепенное значение, кодирование «просто записывает дизайн», это не должно занимать слишком много времени, и «весь код должен быть написан до того, как оборудование будет готово».
2. Не понимает разницы между централизованным и распределенным управлением версиями, даже после того, как мы сказали ему, что легче работать с распределенной моделью.
3. Не понимает код и хочет понять каждую ошибку и предложенное решение.
4. Считает, что проверка должна выполняться разработчиком, а проверка - тестером. Дело в том, что наша проверка только проверяет правильность реализации (мы не пишем модульные тесты, она никогда не учитывается в расписании), а проверка - это тестирование черного ящика, поэтому модульные тесты отсутствуют.

Я действительно смущен.

1. Я несу ответственность за ведение всех этих документов? По сути, это заставляет меня чувствовать, что я занимаюсь программным управлением проектами. Я в порядке с технической документацией, но я считаю, что планирование / планирование не должно выполняться разработчиком.
2. Я не очень люблю создавать документы, я хочу решать проблемы и писать код. По моему опыту, создание проектных документов помогает только до такой степени, что никогда не является решением для лучшего или более быстрого кода.
3. Я чувствую, что начальник на самом деле не заботится о создании более качественных продуктов, а только о том, чтобы быть хорошим менеджером в глазах руководства.

Что я могу сделать? Весь этот год я провёл 3 месяца фактического кодирования, остальное просто потратил на создание документов и ожидание отчетов об ошибках от клиентов.

Вы говорите как инженер-программист.

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

Написание и ведение проектной и технической документации является важной частью работы инженера-программиста и подходит для вашей роли. Хотя слишком много хорошего может быть плохим (см. « Анализ паралича» ).

Он считает, что дизайн имеет первостепенное значение, кодирование «просто записывает дизайн»

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

это не должно занять слишком много времени, и «весь код должен быть написан до того, как оборудование будет готово».

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

Управление проектами невероятно легко в идеальном мире. Однако мир не идеален, как бы вы этого не хотели, что делает управление проектами невероятно трудным. Вот почему им платят большие деньги.

(2) Не понимает разницу между центральным и распределенным управлением версиями.

Почему он должен заботиться? Как это влияет на вехи? Это не так.

3) Не понимает код и хочет понять каждую ошибку и предлагаемое решение

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

(4) Считает, что проверка должна выполняться разработчиком, а проверка - тестером.

Что не так с этим настроением? Тестировщики в роли обеспечения качества должны заниматься проверкой функций и требований. Разработчики должны приложить все усилия, чтобы проверить и протестировать свою работу, прежде чем она перейдет к тестированию.

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

Если вы предпочитаете быть простым программистом, то, возможно, вам следует поговорить об этом со своим боссом и посмотреть, есть ли для вас лучшая роль в проекте. Кто-то должен написать и поддерживать техническую документацию, так что, возможно, один из других разработчиков может помочь вам с некоторыми из этих задач, чтобы вы не тратили 80% своего времени на написание документации.

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

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

В том-то и дело, что лучшей технической документацией является сам код.

Я чувствую, что начальник на самом деле не заботится о создании более качественных продуктов, а только о том, чтобы быть хорошим менеджером в глазах руководства

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

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

Мы все хотим хорошо выглядеть для нашего начальника. В этом нет ничего плохого, такова человеческая природа - служить себе. Это факт жизни.

В какой-то степени я согласен с вашим руководителем проекта. Разработка программного обеспечения выходит далеко за рамки возможностей кодирования. :-)

Учитывая вашу ситуацию, я пойду к нему и объясню, что его запросы занимают 80% вашего времени, и постараюсь понять, почему для него важно, чтобы вы тратили это время на поддержку документации, а не разработку (что выходит за рамки кодирования).

К сведению, Atlassion , компания-разработчик программного обеспечения, имеет соотношение 13 разработчиков на одного сотрудника , отвечающего за контроль качества, и большая часть тестирования (планирование и выполнение) выполняется разработчиками. Я узнал об этом во время одной из их презентаций на Agile 2012, и наши команды в настоящее время пытаются подражать этой практике.

Тем не менее, я бы также обсудил с вашим руководителем проекта, будет ли он готов опробовать Scrum как методологию, которая поможет продвинуть всю команду вперед. Учитывая ваше описание, я не думаю, что вы используете Scrum.

Как и вы, я был крайне разочарован поддержанием планов, которые постоянно менялись, и легкий подход Scrum помог мне преодолеть это разочарование.

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

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

Кроме того, со строгой точки зрения бизнеса найм QA дешевле, чем найм разработчиков. Вы сможете покрыть больше денег за потраченные деньги, если команды будут иметь хорошее соотношение QA / DEV.

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

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

Вы говорите о медицинских системах ... поэтому безопасность имеет первостепенное значение - и поэтому документация (в частности, отслеживаемость) имеет важное значение.

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

Мой опыт работы в медицинской сфере ограничен, но в аэрокосмическом / оборонном мире у нас есть Do-178B (теперь C), который предписывает модель жизненного цикла, которая определяет документацию и необходимый уровень тестирования (в зависимости от критичности безопасности [более конкретно, уровень обеспечения проектирования] программного обеспечения), и в автомобильном мире у нас есть ISO26262, который делает то же самое.

Если документация отсутствует, продукт не сертифицируется.

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