На Какие Типы Организаций Нацелена Трансформация Devops?

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

Вероятно, существуют смешанные типы, но я полагаю, что мне нужно немного поляризоваться, чтобы понять суть. ТипОрг1:

«Организации, занимающиеся цифровыми продуктами», либо B2B, либо B2C, у них есть свои продукты, поскольку они становятся все более и более цифровыми, у них есть собственные команды по ИТ-продуктам и ИТ-операции. Совсем недавно они поняли, что нуждаются (больше, чем раньше) в диверсификации продукции. ТипОрг2:

«Организации, оказывающие цифровые консалтинговые услуги» (не обязательно только ИТ-консалтинг, но они являются здесь типичным примером) эти ребята работают только в сфере B2B, если у них есть устойчивые продукты и связанные с ними операции, то это скорее побочный эффект.

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

Хорошо, тогда OrgType1 — это, очевидно, то, что мы уже знаем, что DevOps оказывает большую помощь, потому что есть устоявшиеся процессы доставки, они нарушаются, их необходимо оптимизировать и так далее, и тому подобное. Что ж, более крупные организации состоят из множества частей, региональных бизнес-подразделений, бизнес-направлений, отделов, и у каждой из них есть своя комбинация операций и своего рода Devops. Хорошо, в любом случае может быть некоторая эволюция.

OrgType2 может заботиться о DevOps ровно настолько, насколько это важно для их клиента (или они даже продают консультации по DevOps;), но затем, если дело доходит до разработки программного обеспечения на месте, вы каким-то образом начинаете с нуля почти в каждом проекте, и это усиливается, как и в случае с OrgType1 через все отделы, бизнес-подразделения и т. д., но это того стоит, потому что каждая «организация DevOps» начинается всего с 1-2 человек, которым нужно понять, чем они занимаются. Похоже, что OrgType2 «задуманно изолирован» гораздо более плотным образом, что делает его в некотором роде масштабируемым и постоянным.

DevOps применяется к типу организации 2, организации «бизнес для бизнеса», в такой же, если не большей степени, как и к первому типу организации. Здесь возможны два сценария:

Сценарий 1

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

Сценарий 2

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

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

Фактически, чтобы проиллюстрировать этот момент, в «Проект ФениксЧлен правления Эрик Рид неоднократно тащит главного героя книги, Билла Палмера, на завод по производству деталей, чтобы проиллюстрировать и научить Билла вещам о технологиях и разработке программного обеспечения, извлекая бизнес-уроки из производственного сектора.

Это способ авторов Джина Кима, Кевина Бера и Джорджа Спаффорда донести мысль о том, что DevOps — это больше, чем просто способ ведения дел или конкретные технологии, это философия бизнеса, известная просто под разными псевдонимами.

Таким образом, чтобы обеспечить максимальную ценность компании, которую консультирует консультант, консультант обязан продемонстрировать и объяснить ценность DevOps, а также помочь компании в успешной реализации этой бизнес-философии и направить компанию к конкретным технологии и способы достижения этой цели. Короче говоря, работа консалтинговых компаний заключается в том, чтобы выступать в роли «Эрика Рида» по отношению к любому бизнесу, заключившему контракт с их консалтинговыми услугами.

Короче говоря, DevOps должен быть очень важен для организаций типа 2, потому что их работа как консультанта — объяснять своим клиентам, почему это важно. всегда будет продавать консалтинг по DevOps. Консультантам, работающим с компанией, которая отказывается рассматривать DevOps, следует вежливо предположить, что, возможно, они не подходят. их клиент может нанять стандартную кодовую обезьяну из любого места, если он хочет продолжать (безуспешно) выполнять проекты так, как они это делали всегда.

Я считаю, что разработка — это не просто разработка продукта, а процесс, который используется для перехода от идеи к реализации. Я думаю, что организация 2 могла бы использовать разработку для создания единообразного способа сбора требований, внедрения/обеспечения реализации стратегии ветвления, настройки/поддержки CI. Это всего лишь команда разработчиков.

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

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

Я думаю, что иногда вам нужно создать данные, которые вы хотите добыть. В этом году (2017) конференция Microsoft, кажется, посвятила целый день Dev ops. Я не смог поехать, но конференции можно найти на You Tube. Возможно, вас заинтересует (и я встал в очередь, чтобы посмотреть) Dev Ops для каждой команды. Еще один, на который я только что наткнулся при просмотре Основной доклад с Донованом Брауном: от 0 до DevOps (Я не смотрел ни один из них, но они кажутся применимыми)