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


12

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

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

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

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

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

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

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

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


16
Если он ваш начальник и говорит, что вы несете ответственность за эти документы, вы несете ответственность.
Рог

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

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

1
@hdman Теперь это немного по-другому. Премьер-министр должен делать диаграммы Ганта, распределение ресурсов и матрицу прослеживаемости. Что тогда делает PM?
maple_shaft

1
@maple_shaft Я молодой парень, и я хочу создавать вещи, кодировать и пробовать новые вещи. Я не очень заинтересован в том, чтобы рассматривать управление проектами как выбор карьеры. Я думаю, это может быть время для перемен.

Ответы:


19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


1
Спасибо за ответ, я согласен с некоторыми моментами. Но какова роль диспетчера программного обеспечения?

6

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

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

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

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

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


2
Спасибо за ответ. Я пытался предложить Agile, но они хотят следовать CMMI. Кроме того, я упоминал, что у меня также есть Менеджер программного обеспечения?

@hdman Хорошо, давайте будем реалистами здесь. Вам нужно поговорить с ними обоими и выразить, что вы заботитесь об общей картине: убедитесь, что команда максимально продуктивна, чтобы компания могла увеличить доход. Эти разговоры могут проходить хорошо, а могут и нет, но вы, как профессионал, несете ответственность за то, чтобы донести это до стола, и решать, действовать им или нет. Удостоверьтесь, что это позитивно, не «ныть» о ситуации, а желая улучшить ситуацию для всех.
Дэвид Сегондс

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

4

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

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

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


QA can be replaced by automated testing depending on your domain-1 Я категорически не согласен с этим. Никакое количество автоматизированного тестирования не является жизнеспособной заменой QA, особенно когда задействовано специальное оборудование.
maple_shaft

1
@maple_shaft Исправлено. Я имел в виду QA может быть заменен в зависимости от вашего домена. Например, если это устройство контроллера для некоторого оборудования, вы знаете, что при определенных входах вы ожидаете определенных выходов - это может быть автоматически проверено. Однако, если это приложение с графическим интерфейсом, то нет никаких способов обойти настоящих людей, которые сидят и ковыряются в этом.
MrFox

Потрясающие! это имеет больше смысла сейчас. Я изменил свое пониженное голосование, +1
maple_shaft

У нас нет отдела контроля качества. У нас есть один тестер, и есть отдел QE. что делает общий контроль качества для механических, MFG, надежность и т. д.

2

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

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


Точно. Он полностью о CMMI. Теперь мы на уровне 3, он хочет перейти на уровень 5. «Ведущий» выполняет большую часть работы по планированию / планированию, которую я сейчас делаю. Но наша организационная структура делает все SE одинаковыми, поэтому один человек выбран в качестве лидера, и, учитывая всю эту работу, нет постоянного лидера как такового.

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

@hdman В этом нет ничего плохого, и это не обязательно ваша или их вина. Иногда люди просто не вписываются в окружающую среду.
maple_shaft

Да, я думаю, это может быть культурной проблемой.

На 5 уровне бремя бумажной работы будет огромным; Похоже, пришло время бежать.
Дэн возится с Firelight

2

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.