Культуру часто игнорируют и неправильно понимают, однако она является ключевым фактором, влияющим на эффективность компании. Если мы не будем управлять своей культурой, мы в конечном итоге будем поступать неправильно, что в конечном итоге повлияет на наши бизнес-цели.
Понимание текущей культуры организации
Культура говорит нам о ценностях и нормах внутри группы или компании. Он определяет, что важно, а также то, как люди подходят и работают друг с другом.
КУЛЬТУРА = «Как сделать все с умом для достижения успеха»
Возьмем, к примеру, службу поддержки клиентов. Культура этой команды должна быть такой, чтобы они в конечном итоге обеспечивали 97-98% удовлетворенности клиентов.
Принимая во внимание восторг клиентов, они, прежде всего, должны быть вежливыми, даже в сложных ситуациях они должны быть хорошими слушателями, чтобы избежать путаницы, они должны расставить приоритеты в работе в соответствии с требованиями.
Давайте сделаем паузу и зададим себе несколько вопросов:
- Какова культура моей компании сейчас?
- Насколько хорошо эта культура соответствует моим бизнес-целям или KRA?
- Какие проблемы я могу ожидать из-за несоосности?
Для каждой организации 4C играет жизненно важную роль
Теперь давайте посмотрим на культуру организации, занимающейся разработкой программного обеспечения. Для создания и поддержки единого программного модуля задействовано множество команд. У всех этих команд разные цели и отдельная культура.
Этот процесс начинается после того, как требования были подтверждены клиентом.
Разработчики следуют руководящим принципам кодирования, определенным их организацией, и инструменты программирования, такие как компиляторы, интерпретаторы, отладчики и т. Д., Используются для генерации кода. Для кодирования используются различные языки программирования высокого уровня, такие как C, C ++, Pascal, Java и PHP.
Они делят весь пакет на небольшие папки, а затем соответственно разрабатывают небольшие коды.
Этап 1 : Эти маленькие единицы кода затем объединяются в одну большую единицу. При интеграции микросхем меньшего размера необходимо проводить тестирование на уровне проекта, известное как интеграционное тестирование.
в чем разница между javascript и jquery
2 этап : После успешной интеграции он развертывается в фиктивной системе. Эта фиктивная система имеет конфигурацию, аналогичную конфигурации клиентского компьютера или компьютера, на котором этот проект должен быть окончательно развернут.
3 этап : Наконец, после тестирования всех функций в фиктивной системе проект развертывается на производственном сервере или на клиентском компьютере.
Хотя на словах этот процесс кажется очень гладким и легким, с технической точки зрения его очень сложно осуществить.
Посмотрим, с какими проблемами мы можем столкнуться:
Этап 1 :
Клиент всегда находится в поиске изменений для улучшения качества продукта. В большинстве случаев, когда была сделана первая итерация, клиент предложит несколько изменений. Когда разработчики получают изменения, они начинают их включать, что влияет на интеграцию, что приводит к сбоям в сборках.
2 этап:
В большинстве случаев тестировщики или другие операторы не знают о новых изменениях, которые необходимо внести. Как только они получают код от разработчиков, они начинают его тестировать. Пока на бэкенде разработчики все еще вносят изменения.
Поскольку у них не хватает времени для внедрения новых изменений, они в конечном итоге разрабатывают неэффективные коды, с которыми сталкиваются с другими проблемами сети и баз данных, что снова задерживает время их доставки.
Когда они, наконец, доставляют коды операционной группе, у них остается очень мало времени на создание и внедрение новых тестовых примеров. Таким образом, они пропускают многие из тестовых примеров, которые позже понимают, что они имеют высокий приоритет.
3 этап:
Хотя практически сборка кажется готовой к запуску в производство, но результаты совершенно неожиданные. Сборка не выполняется, и возникает ряд ошибок.
Затем для каждой возникшей ошибки они должны отслеживать, почему она произошла, где она возникла, какие изменения необходимо внести, чтобы ее преодолеть, будут ли изменения в чужих кодах, чтобы сделать их совместимыми с предыдущими. Наконец, для всех этих ошибок должен быть создан отчет об ошибке.
как использовать tostring в Java
Сбой происходит из-за системных ошибок из-за незнания разработчиком базы данных эффективности кода, незнания тестировщиками количества тестовых примеров и т. Д.
Поскольку заказчик всегда придерживается сжатых сроков, сотрудники, участвующие в их выполнении, концентрируются только на окончательной версии, даже если им приходится ставить под угрозу общее качество.
Хотя это кажется проблемой в координации работы, на самом деле это провал принятой культуры.
Это происходит из-за большой зависимости от ручных процессов. Бегать туда-сюда в одной команде из-за незнания различных областей, отсутствия доступа или отсутствия интереса, увеличивает нашу ношу и боль.
Пришло время проявить универсальность. Может быть трудно быть мастером всех процессов, задействованных в системе, но мы можем быть мастером для всех, справившись с одним из них. Только тогда мы сможем автоматизировать нашу систему или сделать ее достаточно интеллектуальной для восстановления, а не откатов.
Теперь вы можете подумать, почему?
Потому что то, что вы осваиваете, сильно зависит от других. Итак, чтобы узнать о точке зависимости, нам нужно понимать всю систему.
Итак, давайте подумаем о процессе изменения культуры. Перед этим у вас есть ответ на следующие вопросы?
- Где ваша нынешняя культура терпит неудачу?
- Почему вы хотите изменить процесс?
- Вы четко определили все необходимые изменения?
- Получили ли вы обратную связь и поддержку от всех заинтересованных сторон?
- Проверили ли вы дисциплину процесса, данные и систему измерения для внесения изменений?
Итак, теперь, когда у нас есть ответ на все вопросы, мы думаем о революции в нашей системе. Как будет происходить эта революция? Это может быть достигнуто только тогда, когда мы убьем то, что мы есть сейчас. Много времени тратится на перенос кода между командами. Мы должны реализовать процесс, в котором мы можем осуществлять непрерывную интеграцию и непрерывное развертывание.
Этот процесс непрерывной интеграции и развертывания делает его более гибким. Такая гибкость считается культурой DevOps.
DevOps - это практика, когда инженеры-операторы и инженеры-разработчики участвуют вместе на протяжении всего жизненного цикла услуги, от проектирования до процесса разработки и поддержки производства.
Изменить рабочую систему со временем непросто. Успешный переход - это обновление системы, а не восстановление.
Теперь посмотрим, как этого добиться. Подойти можно двумя способами.
1) сверху вниз
2) снизу вверх
Погрузившись глубже в эти методы, мы поймем, какая из них лучше всего подходит для нашей организации.
При подходе сверху вниз мы можем обратиться к вышестоящему руководству и попросить его внести изменения во все команды. Если руководство будет убеждено, мы можем начать работу над этим.
Но вероятность получить ответ «НЕТ» достаточно высока. Это потому, что изменение системы может привести к нестабильности в организации.
Им необходимо изучить структуру организации, доходы, уровень интереса клиентов и т. Д. Но самый важный фактор, который удерживает их от отхода от старой системы, - это то, что они не видят общая картина того, чего можно достичь и насколько плавно это может быть достигнуто с помощью более новой версии.
В этом случае мы можем искать второй подход, чтобы получить эту общую картину.
Подход снизу вверх требует волонтеров. Здесь нам нужно взять небольшую команду и небольшую задачу и выполнить ее в модели DevOps.
Если заглянуть в техническую сторону этой модели, у нас есть широкий набор сложных инструментов, которые делают работу более эффективной и быстрой. Но одних инструментов недостаточно для создания совместной среды, называемой DevOps.
Создание такой среды требует от вас нестандартного мышления, например. оценка и изменение того, как люди думают о своих командах, бизнесе и клиентах.
Собрать новый набор инструментов проще, чем изменить организационную культуру. Продвигая антисоциальных главных разработчиков, позволяя интегрировать неэффективный код, развертывая коды, которые не были должным образом протестированы, возлагая вину друг на друга, считая операционную команду глупой, - это не лучшие практики, которым мы следуем, чтобы обеспечить бизнес и создавать ценность для наших клиентов.
Процесс усложняется не инструментами, а людьми, которые их используют. Говоря абстрактно, а не собирая идеи и модели поведения, открытость для них ведет нас на яркий путь.
Начнем с команды из 6 человек и рассказа из 3-х пунктов. Во-первых, мы должны разбить команду, которую мы называем разработчиками, операторами, тестировщиками и т. Д. Мы рассматриваем их всех как одно целое, скажем, «DevOps». Когда мы получаем требования, нам необходимо проанализировать зоны риска. Имея в виду более глубокие участки моря и хеллип ... Мы отправляемся в плавание.
Теперь вы, должно быть, думаете, «каков x-фактор непрерывной интеграции и непрерывного развертывания, который снижает вероятность сбоя».
def __init__ в Python
Благодаря улучшенному видению и процессу мы можем подойти к руководству, чтобы дать четкое представление о результатах, например, насколько плавным был процесс, как снизился риск сбоя, как задача была выполнена до срока и т. Д.
Теперь мы можем четко визуализировать, как весь процесс был оптимизирован с технической и культурной точек зрения, проводя ретроспективу после каждой итерации.
Edureka специально курировала который поможет вам освоить концепции Puppet, Jenkins, Ansible, SaltStack, Chef и других.
Есть вопрос к нам? Упомяните их в разделе комментариев, и мы свяжемся с вами.
Похожие сообщения: