Читаю книжку Аренса “Как делать полезные заметки”1, наткнулся на интересную мысль о причинах недостаточного внимания к качеству выполняемых практик. Если коротко, то мы не задумываемся о качестве обыденных, повсеместных практик, а также практик без негативной обратной связи.
Одна из причин, по которой люди не задумываются о качестве процессов, это обыденность и повсеместность конкретных действий2. Мы все считаем, что умеем читать и писать, ведь мы делаем это ежедневно. Однако навык сложнее и глубже, чем его внешнее, формальное проявление - складывать из букв слова еще не означает “понимать смысл написанного”, а умение написать слово еще не означает “правильно передать смысл”. Одним и тем же словом мы обозначаем очень разные навыки, ну или по крайней мере “форму” и “содержание” навыка или процесса, практики. Происходит подмена понятий, “чтение-как-считывание-символов” - это не то же самое, что “чтение-как-считывание-смыслов”. Ровно то же и с дыханием - все люди умеют дышать, технически делать вдохи и выдохи, но не факт, что делают это наиболее эффективно с точки зрения здоровья легких или еще какой-нибудь заковыристой физиологии.
Еще одна причина - отсутствие быстрой негативной обратной связи3. У нас не возникает необходимости думать о качестве или правильности выполнения процесса или практики, если прямо сейчас все выглядит достойно. Отрицательные последствия от некачественного выполнения практик могут наступить много позже, и тогда мы не сможем явно связать их с некачественной практикой. В этом случае не возникает стимула искать пути улучшения. Более того, когда ситуация станет критической, отсуствие прямой связи между последствием и некачественным выполнением практики не даст обнаружить истинную причину кризиса. В этом случае мы скорее бросимся исправлять что-то лежащее на поверхности, как можно ближе к наблюдаемым симптомам, чем будем разбираться в глубинных причинах происходящего, и в результате не исправим положение.
Обе этих причины распространены в ИТ, часто команды разработки ПО не добиваются серьезных результатов. Участники команд считают, что умеют писать код, общаться, работать по Scrum и т.п., путая совершение действий с качественным выполнением практики. Первые релизы проходят быстро и гладко, поначалу система функционирует так, как ожидается, пользователей еще мало и негативной обратной связи как от клиентов, так и от разработчиков попросту нет. Но спустя какое-то время начинается боль.
Что делать? Учиться выполнять свои практики, понимая смысл и цель каждого действия, читать учебники и применять полученные знания, экспериментировать и брать на вооружение те идеи, которые прошли проверку экспериментом в реальном мире. Искусственно ускорять получение обратной связи (например, релизить каждый день), искать негативную обратную связь и уделять ей самое пристальное внимание (исследовательское тестирование может помочь, сбор мнения от независимых архитекторов - да все, что угодно, что может поставить под сомнение текущую реализацию). Ну и обсуждать все это, конечно же :)