От разработчика до руководителя

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

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

Будьте реалистами в отношении уроков: какие-то надо сохранить, какие-то — необязательно. Постарайтесь не заставлять людей думать, что при разборе полетов они должны решить каждую обнаруженную проблему. Обучающий анализ содержит весьма тривиальные вещи — от необходимости более внимательно относиться к предупредительным сигналам до необходимости ограничивать ролевые функции или привлекать поставщика программного интерфейса API, чтобы он помог лучше в нем разобраться. Вряд ли вы займетесь реализацией этих пунктов. Более того, если даже займетесь, то не сможете сделать ничего толкового. Из полученных уроков выбирайте одну-две проблемы, действительно чреватых рисками или с большой вероятностью создающих трудности для будущего. И не зацикливайтесь на других, менее срочных.

Ревизия архитектуры систем

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

Сколько людей в команде удовлетворены использованием данной системы или данного языка программирования?

Есть ли у нас стандарты разработки для новой системы?

Каков процесс ввода ее в действие и подготовки людей к работе?

Необходимы ли новые операционные условия для использования новой системы?

А вот некоторые рекомендации.

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

Ценность ревизии архитектуры состоит в процессе подготовки к ревизии. Если люди просят осуществить серьезные изменения в системах или дополнения к ним, то необходимо задуматься, почему именно они хотят изменений. Один из позитивных моментов подготовки к ревизии архитектуры — помочь людям представить себе возможные риски. Вы можете попросить команду ответить, почему необходимы желаемые ею изменения, а можете и не делать этого. Я открыла для себя, что если люди хотят и способны соответствовать требованиям перемен, вопрос «зачем» отпадает сам собой.

С умом выбирайте команду по осуществлению изменений в архитектуре. В команду или совет по осуществлению ревизии архитектуры следует подбирать представителей тех групп, которых возможные изменения затронут больше всего, а не просто статическую группу «гуру» (самых опытных специалистов в коллективе). Частично цель такой тактики в том, чтобы вам самому не оказаться ответственным за все решения. А частично она в том, чтобы привлечь к оценке возможных последствий перемен тех, кто будет иметь с ними дело. Такая команда или совет должны быть достаточно широки по составу, чтобы убедить в своих выводах и оценках весь коллектив. Не обязательно этот процесс должен охватывать всю компанию. Принимающая решение группа должна главным образом состоять из тех, на кого решение повлияет в наибольшей степени. Коллектив не может быть деморализован более, чем когда кто-то из совершенно не связанной с его деятельностью сферы вдруг наложит вето на проект ревизии.