Ответственность без полномочий бессмысленна - техническое решение?

Question

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

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

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

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

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

---

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

Answer 1

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

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

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

Вы можете найти дополнительные рекомендации по этому поводу в PSP и Чайная ЛОЖКА статьи википедии

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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

Итак, к сожалению, я ожидаю, что нам придется столкнуться с такого рода проблемами для многие грядущий год.

Answer 7

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

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

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

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

Извините, я снова отклонился от темы - не стесняйтесь понизить мод.

Answer 8

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