Ответственность без полномочий бессмысленна - это техническое решение? - PullRequest
4 голосов
/ 25 сентября 2008

Мой папа всегда говорит: «Ответственность без власти бессмысленна».

Однако я нахожу, что как разработчики мы все время застреваем в ситуациях, в которых мы находимся:

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

Конечно, есть множество вещей, которые вы можете сказать, чтобы обойти это - найти новую работу, сразиться с боссом и т. Д. ...

Но как насчет технического решения этой проблемы? То есть, что за кодирование вы можете делать самостоятельно без необходимости убеждать команду исправить некоторые из этих проблем - или какие инструменты вы можете использовать, чтобы продемонстрировать, почему неотслеживаемые ошибки причиняют вам вред что сроки пропускаются из-за проблем с качеством, и как вы можете использовать эти инструменты, чтобы получить больше «авторитета», не будучи боссом?


*** Пример - к вам подходит босс и говорит: «Почему так много ошибок !!?!?» - большинство из нас сказали бы: «У нас нет хорошей системы для их отслеживания!», но в моем опыте это обычно рассматривается как оправдание. Так что, если бы вы могли указать на какой-нибудь отчет (менеджеры любят отчеты) и сказать: «Видите, вот почему»?

Ответы [ 8 ]

4 голосов
/ 25 сентября 2008

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

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

Работая как самостоятельная команда, которая показывает вашему боссу ваши планы и сообщает о вашем прогрессе, запрашивает дополнительные ресурсы, когда вам это нужно, и показывает ему, как ваши планы влияют, когда он их вам даёт или нет.

Вы можете найти более подробную информацию об этом в статьях PSP и TSP в Википедии

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

3 голосов
/ 25 сентября 2008

Простой ответ - вы можете начать использовать инструменты самостоятельно.

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

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

И, самое главное, при применении этого давления со стороны сверстников, будет приятно об этом . Мухи и мёд и всё.

Если они не получат его, вы можете оставаться единственным профессиональным разработчиком в вашей компании или группе. Или, по крайней мере, это поможет дополнить ваше резюме: 'опытом настройки и инструктирования других в CVS и FogBugs для улучшения качества продукта' и т. П.

3 голосов
/ 25 сентября 2008

Вам не нужна система отслеживания ошибок, вам нужны автоматические тесты: модульные тесты или другие. Вы можете настроить автоматические тесты с Makefile. Вы всегда можете найти пути, которые заблокированы руководством, но это не значит, что вы не можете делать что-либо в рамках вашей работы. Конечно, ответом может быть «найти другую работу». Если вы не можете найти другую работу сейчас, изучите некоторые навыки, чтобы вы могли.

2 голосов
/ 25 сентября 2008

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

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

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

Для более полного взгляда на то, как вести из середины или низа организации, ознакомьтесь с «Джоном Максвеллом» «Лидер на 360 градусов» .

1 голос
/ 26 января 2010

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

Однако двойная запись использовалась бухгалтерами с 13-го века.

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

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

1 голос
/ 31 декабря 2008

Если вам нужен отчет о качестве и его влиянии на производительность - вот лучшее: http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html У Кейпер Джонс есть несколько книг, и они все еще появляются на конференциях. Вне хорошей IDE разработчик / ИТ-группа нуждается в контроле исходного кода (VSS, SubVersion и т. Д.) И отслеживании проблем

0 голосов
/ 25 сентября 2008

Кодируя только вы, вы можете сохранять свои собственные исходные файлы аккуратными, хорошо прокомментированными, уменьшать количество ошибок с помощью тестов. Но вам понадобятся внешние инструменты для отслеживания прогресса и ошибок (bugzilla, yoxel, trac, инструменты диаграмм Ганта, Mylyn для Eclipse, блог, что угодно). В этих случаях люди, дисциплина, хорошие привычки и лидерство - это подавляющая сила, никакие программные инструменты и никакие предложения от человека не могут победить в одиночку.

0 голосов
/ 25 сентября 2008

Извините, что не ответил на ваш вопрос напрямую, но ...

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

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

Во всяком случае, технология вызвала истощение прямого общения лицом к лицу.

Извините, я снова сошел с ума - не стесняйтесь понижать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...