Ответственность без полномочий бессмысленна - это техническое решение?
Мой папа всегда говорит: "Ответственность без власти бессмысленна".
Тем не менее, я считаю, что, как разработчики, мы все время застреваем в ситуациях, когда мы находимся:
- Отвечает за обеспечение отсутствия ошибок в программном обеспечении, но не имеет полномочий для внедрения системы отслеживания ошибок.
- Отвечает за соблюдение сроков проекта, но не может влиять на требования, качество или командные ресурсы (три части управления проектом)
- и т.п.
Конечно, есть множество вещей, которые вы можете сказать, чтобы обойти это - найти новую работу, бороться с боссом и т. Д....
Но как насчет технического решения этой проблемы? То есть, какие виды кодирования вы можете делать самостоятельно, без необходимости убеждать команду исправить некоторые из этих проблем - или какие инструменты вы можете использовать, чтобы продемонстрировать, почему неотслеживаемые ошибки наносят вам вред, что сроки пропускаются, потому что проблем с качеством, и как вы можете использовать эти инструменты, чтобы получить больше "авторитета", не будучи боссом?
*** Пример - к вам подходит босс и говорит: "Почему так много ошибок!!?!?" - большинство из нас сказали бы: "У нас нет хорошей системы для их отслеживания!", но в моем опыте это обычно рассматривается как оправдание. Так что, если бы вы могли указать на какой-нибудь отчет (менеджеры любят отчеты) и сказать: "Видите, вот почему"?
8 ответов
Все, что вы можете сделать, это сделать все возможное, не думайте, что ключ к успешному программному обеспечению находится только в ваших руках, вашей части команды и не должен нести ответственность за все.
Очевидно, что вы находитесь в среде, которая негативно влияет на ваше программное обеспечение, но не может изменить все его поведение, поэтому я рекомендую вам начать с вашего, начать работать как единая команда со своими собственными ошибками, сроками, требованиями, качеством и ресурсами, которые не беспокоиться об остальной части беспорядка, но постарайтесь быть лучшими в своей работе.
Работая как самостоятельная команда из одного человека, показывающего вашему боссу ваши планы и сообщающего о вашем прогрессе, запрашивающего дополнительные ресурсы, когда вам это нужно, и показывающего ему, как ваши планы влияют, когда он их вам даёт или нет.
Вы можете найти больше советов об этом в статьях Википедии о PSP и TSP
После того, как ваш начальник продемонстрировал хорошую работу и соблюдает собственные сроки, он наверняка будет доверять вам больше и позволять некоторым вашим идеям распространяться на всю команду.
Вам не нужна система отслеживания ошибок, вам нужны автоматизированные тесты: модульные тесты или другие. Вы можете настроить автоматические тесты с Makefile. Вы всегда можете найти пути, которые заблокированы руководством, но это не значит, что вы не можете делать что-либо в рамках вашей работы. Конечно, ответом может быть "найти другую работу". Если вы не можете найти другую работу сейчас, изучите некоторые навыки, чтобы вы могли.
Ответ прост - вы можете начать использовать инструменты самостоятельно.
Улучшите свою собственную работу. Если люди хотят, чтобы вы исправили код, попросите их сообщить об ошибке. Покажите им, как. Убедитесь, что они могут сделать это без установки чего-либо. Они хотят обновить статус? Скажите им, чтобы проверить ошибку. Они спрашивают вас об изменении кода, которое вы сделали? Покажите им, как сделать запрос истории управления исходным кодом. или просто показать их на своем ящике. Начните показывать им, что это работает.
И когда вам нужны такие же результаты, требуйте, чтобы они выполняли работу. Если вы не можете найти изменения в исходном элементе управления, попросите их начать вносить изменения в свои версии вручную с лент резервного копирования. Не делайте за них свою работу или работу по контролю за источниками и отслеживанию ошибок.
И самое главное, применяя это давление со стороны сверстников, будьте добры к этому. Мухи и мёд и всё.
Если они этого не получат, вы можете оставаться единственным профессиональным разработчиком в вашей компании или группе. Или, по крайней мере, это поможет дополнить ваше резюме: "опыт настройки и инструктирования других в CVS и FogBugs для улучшения качества продукта" и тому подобное.
Что касается конкретных инструментов для демонстрации того, что неотслеживаемые ошибки наносят ущерб способности команды создавать качественный код, то здесь у вас есть ловушка-22, так как вам нужно что-то для отслеживания ошибок, прежде чем вы сможете показать их эффект. Вы не можете измерить то, что вы не можете отследить. Так что делать?
В качестве аналогичного примера, недавно к нам присоединился парень, который чувствовал, что способ, которым мы делали обзоры кода по электронной почте, был нелепым. Таким образом, он нашел инструмент с открытым исходным кодом, установил его на своем боксе, попросил некоторых из наших непредубежденных членов команды попробовать его на некоторое время, а затем продемонстрировал руководству нашей команды. В течение нескольких недель у него была возможность продемонстрировать его всем нашим командам. Новый парень влиял на всю компанию. Я слышал много историй об усыновлении этого партизанского стиля.
Хитрость заключается в том, чтобы определить, кто имеет полномочия принимать решение, выяснить, что они ценят, и собрать достаточно доказательств того, что то, что вы хотите реализовать, даст им то, что они ценят.
Для более полного взгляда на то, как вести из середины или снизу организации, посмотрите "Макс 360 градусов" руководителя Джона Максвелла.
Если бухгалтера попросят создать набор учетных записей без использования двойной записи и не балансировать, никто не будет ожидать, что бухгалтер сделает это.
Однако двойная запись была в стандартном использовании бухгалтеров примерно с 13-го века.
Пройдет много времени, прежде чем мы как профессия получим стандартную практику, настолько укоренившуюся, что один будет работать без них.
Итак, извините, я ожидаю, что нам придется столкнуться с этим типом проблемы на долгие годы.
Если вам нужен отчет о качестве и его влиянии на производительность - вот лучшее: http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html Caper Jones выпустил несколько книг и все еще появляется на конференциях. Вне хорошей IDE разработчик / ИТ-группа нуждается в контроле исходного кода (VSS, SubVersion и т. Д.) И отслеживании проблем.
Извините, что не ответил на ваш вопрос напрямую, но...
Я твердо убежден, что неудача, о которой вы говорите, связана с коммуникацией, и мы, профессионалы, обязаны развивать наши навыки общения до такой степени, чтобы мы были достаточно уважаемы и достаточно доверяли, чтобы использовать авторитет, необходимый для улучшения нашей рабочей среды и процессов. как вы предлагаете.
Короче говоря, я не думаю, что есть техническое решение, которое может решить все проблемы, возникающие из-за плохого общения на рабочем месте.
Во всяком случае, технология вызвала истощение прямого общения лицом к лицу.
Извините, я снова на кассе - не стесняйтесь понижать.
При кодировании только вы можете сохранять свои собственные исходные файлы аккуратными, хорошо прокомментированными, уменьшать количество ошибок с помощью тестов. Но вам понадобятся внешние инструменты для отслеживания прогресса и ошибок (bugzilla, yoxel, trac, инструменты диаграмм Ганта, Mylyn для Eclipse, блог, что угодно). В этих случаях люди и дисциплина, а также хорошие привычки и лидерство являются подавляющей силой, никакие программные инструменты и никакие предложения от человека не могут победить в одиночку.