Как известно, изменения в нашей жизни есть единственное постоянное явление. Этот принцип вы слышали не раз, не так ли? Даже в курсе по основам физики утверждается, что в замкнутых системах следует ожидать повышения энтропии. Так почему же тогда мы пишем книги, читаем код, занимаемся другими структурированными видами деятельности? Надо полагать, что-то (или кто-то) способствует упорядочению, которое противостоит естественной, присущей всей Вселенной тенденции к дезорганизации. «Что это он такое мелет? – спросите вы. – Уж не хочет ли он сказать, что мне предстоит стать "Богом управления процессами"?» Да, именно это я и имею в виду. Хотите более замысловатый титул – можете называть себя «владыкой изменений». Главное, как вы понимаете, – не наименование, а действие. В рамках общей, единой для вашей компании стратегии вы должны руководить процессом определения продуктов и проекта.

Изменения делятся на два основных типа: намеренные и случайные. Изменения, относящиеся к первому типу, обычно планируются; вторые же, как правило, непредсказуемы. Если вы ориентированы на успех, старайтесь тщательно управляться с намеренными изменениями – тогда вы сможете получить определенный контроль над случайными изменениями. Подумайте, какое воздействие модификация продукта окажет на сетевую инфраструктуру? А как насчет изменения механизма взаимодействия с пользователем во второй версии продукта? Учитываете ли вы все эти моменты? Кодирование не есть изолированный процесс. По словам Томаса Мертона (Thomas Merton), «нас согревает огонь, а не дым; через океан мы плаваем на кораблях, а не на волнах, которые они оставляют за собой»[51]. К сожалению, слишком часто программные продукты создаются без достаточного анализа воздействия технических решений на окружающую среду – «дым» и «волна» наших усилий в таких случаях приводят к дестабилизации деятельности компании.

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

Выражаясь более приземленно, деятельность по организации изменений нужно вести на всех этапах разработки – от зарождения замысла до завершения. Если никто не позаботился о том, чтобы построить хотя бы общий шаблон для получения информации о воздействии ожидаемого (или неожиданного) изменения, в процессе разработки вас ждут серьезные трудности. Чтобы выявить подводные камни изменений, достаточно задать ряд простых вопросов. Имейте в виду: задавать их следует применительно к любой предполагаемой модификации продукта.

• Каким представляется воздействие изменения на архитектуру системы и процесс сопровождения?

• Как предполагаемое изменение воздействует на сетевую инфраструктуру, в которой оно будет проводиться?

• Как предполагаемое изменение повлияет на способность пользователя эффективно и продуктивно взаимодействовать с данным программным продуктом?

• Какое влияние предполагаемое изменение окажет на действия сотрудников отделов, которым его придется испытать на собственной шкуре?

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

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

Если программист считает, что справился со своим кодом «неплохо», насторожитесь! Дело в том, что эпитет «неплохо» можно трактовать по-разному. В любом случае в деле выявления ошибок контрольный сценарий, написанный бизнес-экспертом, приносит большую пользу, чем программист, просматривающий функцию собственного сочинения. Ни один человек не способен в одиночку адекватно оценить последствия побочных изменений в программном продукте. Наличие группы тестирования, сотрудники которой также ответственны за развертывание, есть необходимое условие достижения успеха. Тестеры должны быть вашими лучшими друзьями. Именно они помогают выпускать качественные продукты; они же составляют первую линию защиты от некачественных графических пользовательских интерфейсов.

Многие считают, что физические условия, в которых ежедневно трудятся сотрудники компании, не слишком существенны. Если и вы придерживаетесь этого мнения, подумайте еще раз. В главе 3, рассуждая о том, как разбираться с внешними раздражителями, я мельком упомянул проблему рабочего пространства. Стандартные офисные клетушки не подходят для программистов. Совместное пользование одним компьютером – это тоже не про нас. Не менее разрушительной в контексте деятельности программистов представляется практика непрекращающихся боевых действий с системными инженерами с целью получения доступа к важным системным ресурсам. Все эти элементы физического окружения, которые совершенно необходимы для успешной деятельности группы программистов, стоят денег, и немалых. Задарма ничего не выйдет. С другой стороны, если сопоставить продуктивность (в категориях времени и стоимости) работы в плохих условиях с продуктивностью в нормальной рабочей среде, мы придем к выводу, что вложения в физическую инфраструктуру вполне оправданы.

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

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