Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами

Руководство процессами

Руководство процессами

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

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

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

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

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

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

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

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

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

Оглавление книги