Философия DevOps

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

Какая степень риска считается недопустимой?

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

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

Выводы

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

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

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

Глава 19. Заключение

Спасибо, что дочитали этот текст до конца! На страницах этой книги было рассмотрено много интересных вопросов и историй об отдельных людях и организациях. Вполне вероятно, что не всегда получится изменить все, что планировалось, и не все описанное здесь относительно devops-культуры подойдет для тех или иных условий. Не забывайте о том, что не существует универсального решения. Следует научиться правильно расставлять приоритеты. В первую очередь определить самые насущные проблемы, затем – изменения, которые можно реализовать позже, и в самую последнюю очередь – наименее важные на текущий момент вопросы.