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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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