На что похож жизненный цикл заявки?
Кто создает заявки, когда соответствующая работа должна быть выполнена? Каким образом назначаются заявки? Выбирает ли кого-то для назначения заявки создатель этой заявки? Либо участники данной команды или проекта вытягивают заявки из некоей очереди получения? Или же для каждого проекта назначен человек, который рассматривает и назначает заявки? Либо используется комбинация вышеупомянутых способов? Каким образом назначаются приоритеты заявкам и сохраняются ли эти приоритеты в случае выбора других людей и проектов? Как часто заявки исполняются в срок? Отслеживайте заявки с высокой срочностью или заявки с одним сроком на всех. Это облегчает идентификацию проблем, связанных с неправильной расстановкой приоритетов для выполняемых работ.
Какая степень риска считается недопустимой?
Как и в случае с рассмотрением процесса принятия решений, довольно много можно сказать об организации или команде, наблюдая за тем, как они реагируют на риск. В каких областях проявляются риски? Связаны ли риски с использованием новых инструментов или технологий либо с пожеланиями заказчика продукта или реализацией новой возможности продукта? Разрешено ли одним сотрудникам рисковать больше других? Позволено ли техническому директору (CEO) стартапа переписывать большие фрагменты программы, являющейся частью его любимого проекта, только на том основании, что никто не может возразить ему? В то же время остальные сотрудники организации должны следовать имеющимся правилам и использовать существующие процессы? «Разработчики-ковбои», которые не обязаны играть по правилам остальных сотрудников организации, могут создавать проблемы на уровне команды или организации.
В процессе оценки предлагаемых вакансий или принятия решения об увольнении важно оценить, насколько здорова или нездорова данная организация. При прочих равных условиях проще выбрать более здоровую среду, но, во-первых, условия редко бывают равными, а во-вторых, довольно трудно сказать, насколько здоровой является культура организации. Сложно дать оценку здоровью культуры, не работая в этой организации либо во время проведения интервью. Чтобы облегчить эту задачу, попробуйте поговорить с людьми, которые работают в этой организации или недавно уволились. Это позволит вам сформировать картину происходящего в данной организации.
ВыводыЗначительную часть процесса создания и поддержки организационной культуры составляет взаимодействие сотрудников между собой и с организацией в целом. Истории и рассказы, посвященные нашей собственной работе, могут помочь нам воспринять такие же рассказы других людей, будут способствовать росту эмпатии и укреплению взаимосвязей.
Мы обсудили идеи технического и культурного долга, а также последствия ранее принятых решений, относящихся к технической и культурной области. Эти решения довольно легко принять, но гораздо труднее избавиться от последствий. Также довольно сложно отказаться от плохих традиций, например от отношения к любым событиям как к кризису, либо к привычке по ночам вести переписку по электронной почте. В то время как отдельные сотрудники и рассказываемые ими истории могут оказать существенное влияние на организации, частью которых они являются, имейте в виду, что в первую очередь следует заботиться о здоровье каждого сотрудника, а не о здоровье всей организации.
По мере продолжения путешествия в мир devops важно помнить, насколько ценным может быть обмен историями. Обращайте внимание на содержание ваших историй. Узнайте о том, что говорится о культуре и ценностях организации (в явной и неявной форме). Оцените, насколько эффективно вы можете взаимодействовать и учиться у других людей, команд и организаций. Подумайте о том, каким образом технические и культурные долги могут влиять на здоровье организации и ее сотрудников.
Глава 19. Заключение
Спасибо, что дочитали этот текст до конца! На страницах этой книги было рассмотрено много интересных вопросов и историй об отдельных людях и организациях. Вполне вероятно, что не всегда получится изменить все, что планировалось, и не все описанное здесь относительно devops-культуры подойдет для тех или иных условий. Не забывайте о том, что не существует универсального решения. Следует научиться правильно расставлять приоритеты. В первую очередь определить самые насущные проблемы, затем – изменения, которые можно реализовать позже, и в самую последнюю очередь – наименее важные на текущий момент вопросы.
Как неоднократно подчеркивалось на протяжении всей книги, нет универсального рецепта внедрения devops, «devops в упаковке» или devops-услуги. Авторы делятся с читателями идеями и методиками улучшения сотрудничества между отдельными сотрудниками и группами, укрепления организационного единства и использования различных инструментов. Читатель узнал, каким образом эти понятия позволяют организации изменяться, адаптироваться и при необходимости выбирать другие бизнес-стратегии. Мы рассказали о возможности применения этих принципов в тех организациях, которые стремятся усовершенствовать качество своих продуктов, эффективность и благополучие сотрудников.
Описанные в книге принципы применяются независимо от языка программирования, от инструментов, используемых для управления инфраструктурой, или от наиболее современных контейнерных технологий. Читатель узнал о том, как работают вместе четыре столпа эффективного devops, направленные на выработку общих целей и общего понимания и создание здоровых и прочных ценностей и практик, относящихся к рабочим местам. Усвоив эти принципы, вы сможете создать культуру, которая будет существовать намного дольше, чем любой инструмент или тенденция. Благодаря devops достигается понимание принципов совместной работы и способов поддержания и восстановления рабочих отношений.
Ошибочно полагать, что devops связан исключительно с веб-компаниями, небольшими стартапами, а также группами разработчиков и эксплуатации. В дополнение к кардинальным изменениям в практиках разработки программного обеспечения идеи, заключенные в четырех столпах devops, затрагивают все составляющие организации и могут использоваться крупными корпорациями и государственными учреждениями. Существует множество способов практического применения этих теорий, при этом важно не акцентировать много внимания на историях других людей, чтобы не отвлекаться от своих собственных историй.
Независимо от специфики культуры или истории организации не стоит забывать, что конечная цель заключается не в определенном количестве ежедневных развертываний кода, использовании инструментальных средств с открытым исходным кодом или простом подражании успеху других организаций. Конечной целью является создание и поддержание успешной организации, которая будет решать проблемы своих клиентов. Не поленитесь заранее сформулировать цели, ценности и идеи, которые будут работать независимо от сферы деятельности и размера компании. Не ждите, пока это сделает кто-то вместо вас. Потом что-либо менять будет слишком поздно.
Ваши следующие действияСкорее всего, вы начали читать эту книгу в надежде получить руководство по внедрению успешных культурных и технических перемен в организации. Что же делать далее?
Прочитайте главу 20. В этой главе содержится перечень полезных и интересных книг, статей, видеосюжетов и справочный материал, цитируемый на протяжении всей книги. Вниманию читателя предлагаются также ссылки на ресурсы, которые, по мнению авторов, будут полезны для организаций, заинтересованных во внедрении devops и других культурных изменениях.
Научитесь расставлять приоритеты. Начните с самых важных вопросов, в которых хотите достичь максимального прогресса
