Как ни странно, именно исчерпывающая документация чаще всего становится преградой на пути управления изменениями. Мечтать о совершенной документации и отслеживании изменений в ней – значит иметь такую систему, в которой команда может автоматически фиксировать все производимые в продукте изменения, поэтому команда может точно определить, что должно быть исправлено.
Для большинства команд, к сожалению, реальность управления изменениями при помощи исчерпывающей документации не столь привлекательна. Им придется потратить огромное количество времени в начале проекта, пытаясь предсказать будущее и безупречно записать его. В ходе проекта они должны сохранять документы, которые написали, и отслеживать любые новые события. Если есть изменения в понимании сути продукта, который они создают, то им придется вернуться и внести изменения во все документы, имеющие к этому отношение. Со временем это может привести к беспорядку в устаревших документах, а также потребует значительных усилий для их создания и поддержания.
Из-за того, что исчерпывающая документация неидеальна, это приводит к ненужным изменениям и затраченным впустую усилиям. Любой фрагмент документации написан с точки зрения человека, имеющего определенную роль: бизнес-аналитики делают это с одних позиций, архитекторы, создающие дизайн, – с других, а тестировщики (QA-инженеры), строящие планы тестирования, – с третьих. Когда нужно связать это воедино с матрицей отслеживания, они обнаруживают точно такие же несоответствия, которые вы ожидаете от внедрения раздробленного видения. Создание документации становится самоцелью и требует все нарастающих предварительных усилий. И наконец, когда понадобится изменение, всю работу по согласованию их точек зрения и объединению документов в обширный комплекс придется переделывать. Это ведет к переписыванию командой документации, формированию заново матрицы трассируемости и улаживанию конфликтов. Хотя на самом деле требуется написать код, протестировать ПО и внедрить изменения.
Должен быть более эффективный способ разработки программного обеспечения.
Agile-практики признают, что документация – это просто одна из форм общения[21]. Когда я пишу документ и передаю его вам, цель не в написании документации. Моя задача состоит в том, чтобы убедиться: мои мысли почти полностью соответствуют вашим. Во многих случаях документирование – отличное средство для достижения этой цели, но не единственное из имеющихся у нас.
Рис. 3.3. Когда члены команды не общаются, они могут о чем-то договариваться, но все-таки цели их работы разные. Исчерпывающая документация может ухудшить ситуацию и легко привести к ее неоднозначному пониманию
Непосредственное общение – это почти всегда более предпочтительное средство для обмена идеями внутри команды разработчиков, чем документация. Известно, что совместное обсуждение проблемы – самый эффективный способ понять новую идею. У нас гораздо больше шансов запомнить идеи, высказанные во время разговора, чем почерпнутые из книги или электронного носителя. Вот почему практики agile-общения в основном сосредоточены на людях, непосредственно общающихся друг с другом и использующих документацию только в тех случаях, когда позднее необходимо детализировать сложную информацию.
К счастью, это несложно для команд, которые используют исчерпывающую документацию для более эффективной личной коммуникации своих членов. Потому что большинство из них не стремятся достичь «идеала» в детализации информации и трассируемости. Разработчики программного обеспечения, как известно, практичны. Когда они видят весь объем работ, необходимых для создания исчерпывающей информации, они идут по пути разговоров друг с другом. Это единственный надежный способ эффективного построения ПО. Признав, что исчерпывающая документация не всегда уместна, они перестанут чувствовать вину за то, что не совершили невозможного – не создали идеальной, подробной документации. Ведь если бы они это сделали, польза для их проектов была бы невелика!
21
Традиционные руководители проектов также признают, что документация – это просто одна из форм общения. Типичные менеджеры изучают разницу между формальным и неформальным способами общения, а также разницу между письменной и устной коммуникацией. Они также изучают невербальные сигналы в общении и узнают, что общение – наиболее эффективное средство генерации идей. Все эти знания фактически проверяются на экзамене по PMP!