Подавляйте в себе первое желание показывать пальцами на виноватых. Чрезвычайно соблазнительно после стресса от сбоя указать на кого-то и спросить: почему они не смогли предвидеть последствия своих действий? Почему отправили эту команду на этот блок? Почему взялись за тестирование этого куска программы? Почему проигнорировали предупреждение? К сожалению, раздача обвинений приводит только к тому, что люди боятся совершить ошибку.
Изучите обстоятельства вокруг инцидента и попробуйте разобраться в контексте событий. Вы должны идентифицировать и понять факторы, способствовавшие возникновению инцидента. Ваши действия могут включать в себя тестирование, обнаруживающее проблему, или применение методов, делающих исправление сбоя более гладким. Продуманный список таких факторов поможет обнаружить задействованные схемы и целые области, нуждающиеся в улучшении. Это способствует формированию «учебной» части «обучающего анализа».
Будьте реалистами в отношении уроков: какие-то надо сохранить, какие-то — необязательно. Постарайтесь не заставлять людей думать, что при разборе полетов они должны решить каждую обнаруженную проблему. Обучающий анализ содержит весьма тривиальные вещи — от необходимости более внимательно относиться к предупредительным сигналам до необходимости ограничивать ролевые функции или привлекать поставщика программного интерфейса API, чтобы он помог лучше в нем разобраться. Вряд ли вы займетесь реализацией этих пунктов. Более того, если даже займетесь, то не сможете сделать ничего толкового. Из полученных уроков выбирайте одну-две проблемы, действительно чреватых рисками или с большой вероятностью создающих трудности для будущего. И не зацикливайтесь на других, менее срочных.
Ревизия архитектуры систем
Я предложила бы по желанию команды в рамки ревизии архитектуры включить изменения во всех главных системах и в инструментальном обеспечении. Цель ревизии архитектуры состоит в том, чтобы сделать достоянием соответствующей группы большие изменения и ясно довести до всех риски, связанные с ними. Вот на какие вопросы должны быть готовы ответить коллеги.
Сколько людей в команде удовлетворены использованием данной системы или данного языка программирования?
Есть ли у нас стандарты разработки для новой системы?
Каков процесс ввода ее в действие и подготовки людей к работе?
Необходимы ли новые операционные условия для использования новой системы?
А вот некоторые рекомендации.
Конкретизируйте изменения, необходимые архитектуре. Обычно это касается новых языков программирования, новых платформ, новых систем хранения данных и новых элементов инструментального обеспечения разработки ПО. Иногда необходимость ревизии архитектуры объясняют желанием предотвратить создание некачественных программ. Однако зачастую трудно сразу же начать после ревизии разработку нового ПО даже в больших компаниях, не говоря уж о малых. Такие ревизии существенно замедляют общий процесс разработки ПО, а как отмечалось раньше, не следует ставить трудные процессы выше соображений разработки продукта.
Ценность ревизии архитектуры состоит в процессе подготовки к ревизии. Если люди просят осуществить серьезные изменения в системах или дополнения к ним, то необходимо задуматься, почему именно они хотят изменений. Один из позитивных моментов подготовки к ревизии архитектуры — помочь людям представить себе возможные риски. Вы можете попросить команду ответить, почему необходимы желаемые ею изменения, а можете и не делать этого. Я открыла для себя, что если люди хотят и способны соответствовать требованиям перемен, вопрос «зачем» отпадает сам собой.
С умом выбирайте команду по осуществлению изменений в архитектуре. В команду или совет по осуществлению ревизии архитектуры следует подбирать представителей тех групп, которых возможные изменения затронут больше всего, а не просто статическую группу «гуру» (самых опытных специалистов в коллективе). Частично цель такой тактики в том, чтобы вам самому не оказаться ответственным за все решения. А частично она в том, чтобы привлечь к оценке возможных последствий перемен тех, кто будет иметь с ними дело. Такая команда или совет должны быть достаточно широки по составу, чтобы убедить в своих выводах и оценках весь коллектив. Не обязательно этот процесс должен охватывать всю компанию. Принимающая решение группа должна главным образом состоять из тех, на кого решение повлияет в наибольшей степени. Коллектив не может быть деморализован более, чем когда кто-то из совершенно не связанной с его деятельностью сферы вдруг наложит вето на проект ревизии.
Обратимся к оценке вашего собственного опыта
Какова политика вашей компании? Какова существующая в ней практика? Положены ли они на бумагу? Когда в последний раз вы просматривали их?
Есть в вашей компании признанные ценности? Что они собой представляют? Как вы в команде относитесь к ним?
Есть в вашей компании должностное расписание? Считаете ли вы, что оно точно отображает сегодняшнее состояние организации? Отображает ли оно компанию, желаемую в будущем? Если нет, можете ли вы что-то улучшить?
Какие риски наиболее актуальны для вашей команды? Для компании? Как могли бы вы снизить риски, не обременяя компанию ненужными процессами и бюрократическими процедурами?
10
Заключение
Итак, мы приехали. Вместе со мной вы прошли путь от наставника до менеджера и руководителя старшего звена. Надеюсь, что на этом пути вы усвоили немало хитростей, узнали о немалом количестве ловушек, куда вам лучше не попадать, и испытали воодушевление перед встречей с трудностями, поджидающими вас в любой роли.
Самый важный усвоенный мною урок в том, что нужно уметь хорошо управлять собой, если хочешь хорошо управлять другими людьми. Чем больше времени вы будете уделять самопознанию, пониманию своих реакций, осознанию того, что вас воодушевляет, а что мешает, тем лучше для вас.
Хорошие менеджеры — мастера преодоления конфликтов. Умение преодолевать конфликты подразумевает умение подавлять свое эго в разговорах с людьми. Чтобы иметь ясный взгляд на сложную ситуацию, вы должны уметь видеть дальше собственных интерпретаций и тех историй, которые вы рассказываете себе. Если вы хотите говорить людям трудные для восприятия вещи и заставлять их слышать себя, вы должны быть в состоянии не приукрашивать эти вещи пустыми словами. Люди, стремящиеся к роли менеджера, обычно имеют твердые взгляды на то, как должны обстоять дела. Такая решительность — хорошее качество. Но она может помешать в тех случаях, когда вы не видите, что ваша интерпретация ситуации так и остается вашей интерпретацией.
Умение распознать голос своего «я» — один из важных плюсов медитации. Когда я писала первый вариант книги, он включал в себя определенные медитации для каждого должностного уровня. Лично для меня медитационные практики стали очень важным инструментом развития навыков самоуправления и самоосознания. Разумеется, медитация не панацея, но она может стать полезным упражнением для развития осознанности и понимания ваших реакций. Именно поэтому рекомендую ее вам, если вы заинтересовались. Моими излюбленными источниками по этой теме являются некоторые материалы на tarabrach.com, а также книги Пемы Чодрон25.
