Избегайте накопления знаний в командах разработчиков программного обеспечения

Знакомый персонаж в неблагополучной команде разработчиков — хранитель знаний.

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

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

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

Выявить хранителя знаний легко

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

Опасности накопления знаний

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

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

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

Причины

Накопление знаний чаще всего вызвано одним из следующих факторов или их комбинацией;

1. Слишком сложное программное обеспечение.

1. Отсутствие автоматизации, рабочего процесса и процесса.

1. Отсутствие прозрачности.
   

Чтобы предотвратить накопление знаний. Вы должны решить эти проблемы.

Лечение

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

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

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

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

Слишком сложное программное обеспечение, как правило, очень сложно автоматизировать.

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

Уменьшите сложность и автоматизируйте процессы сборки и развертывания.

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

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

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