Сегодня наша команда системных администраторов и операторов выполняет как разработку, так и обычные операции. Но задачи разработки всегда страдают, когда есть какие-то операционные задачи, которые необходимо выполнить. Чтобы исправить это, мы планируем разделить на две группы - разработки и эксплуатации.
Мы будем очень осторожны, чтобы не опустошить операционный отдел тех, кто умеет писать код, поскольку мы считаем очень важным, чтобы системные администраторы тоже были компетентными программистами. Но сначала нам нужно выделить несколько человек, а затем начать нанимать преданных делу программистов.
Но мне нужен совет, как нам это структурировать. Какие-нибудь советы / лучшие практики о том, как мы должны делать разделение, и особенно о том, каким должен быть интерфейс между операциями и разработкой?
БЫТЬ ОСТОРОЖЕН!
Ты должен быть очень ясно, чего вы пытаетесь достичь. Если речь идет о попытках выполнить больше работы по разработке с тем же количеством сотрудников, изменение названий не поможет. Для этого вам необходимо сократить объем операций и / или повысить производительность разработки.
На данном этапе я бы избегал реструктуризации или смены ролей. Вместо этого я бы внес изменения, связанные с сокращением оперативной работы и повышением производительности разработки.
Могу я предложить ...
1- Измерьте, куда идет время. Обычно в такой среде есть три «разновидности» работы: срочная поддержка, незначительная разработка (то есть небольшие улучшения) и чистая разработка. Вы должны знать, сколько времени тратится на это. Не верьте своим собственным оценкам ... они, вероятно, ошибаются.
2- Назначьте основную вспомогательную роль и попросите ее чередовать персонал. Текущему «первому» поручено выявлять проблемы поддержки и решать их, предоставляя остальным сотрудникам возможность работать над проектами. Идея состоит в том, чтобы дать персоналу больше времени на разработку, что должно повысить производительность.
3- Реализуйте билеты (т.е. отслеживание проблем), если у вас ее еще нет. Убедите пользователей и вашу команду использовать его, и пусть команда будет держать его в курсе.
4- Будьте открыты и ясно говорите с группами, которые вы поддерживаете, о том, что вы делаете и почему вы это делаете. Откажитесь от них из-за ненужных просьб и чрезмерной срочности.
Как только у вас будет больше данных и будут внесены некоторые изменения, вы сможете принимать более обоснованные решения о «структурных» изменениях. Если вы все же решите разделить свою команду, у вас, вероятно, будет больше данных о том, какой человек принадлежит с какой стороны стены.
Сделайте все возможное, чтобы синергия между этими командами продолжалась. Убедитесь, что вы планируете хорошие командные мероприятия вне работы. Следите за поведением, которое может привести к тому, что команды разойдутся по сторонам (например, «Эти застройщики плотин»).
Я бы создал хороший план коммуникации для команд, который определяет роли и обязанности для двух групп. Это также определило бы, как группы должны общаться (например, встречи команд, развертывание, документация, ...).
Попытайтесь определить все взаимодействия между этими командами и убедитесь, что существуют хорошие процессы.
Лучше всего разделить команды - реактивная операционная работа очень вредна для продуктивности разработки. Запасы разработчиков - это непрерывная концентрация, а смешанная рабочая нагрузка непропорционально мешает работе по разработке.
Некоторые способы поощрения сплоченности команды:
Сохраните некоторые ресурсы разработки, прикрепленные к команде операторов, ответственной за автоматизацию, работу по исправлению ошибок в системах, с которыми они знакомы, и, возможно, небольшие изменения или проекты разработки.
Держите команды в одной физической зоне, чтобы они могли общаться вместе.
Регулярно меняйте людей между командами - некоторые люди в каждой команде должны были проработать как минимум 1-2 года в другой команде. Например, попробуйте заставить разработчиков работать некоторое время в качестве администраторов баз данных (и платить им надбавку по вызову, если они дежурят по вызову - вас могут посчитать использующим младшего разработчика в качестве дешевого администратора базы данных!).
Создайте рабочую группу по архитектуре, в которой будут работать люди из обеих команд. Эта группа не обязательно работает на полную ставку, но занимается такими вещами, как создание и управление инфраструктурой конфигурации, архитектурой / разработкой БД, которая находится в серой зоне между разработкой и операционной работой администратора баз данных и конфигурацией веб-сервера / сервера приложений, особенно там, где это влияет на разработку.
Поощряйте (и выделяйте время для) людей на проведение семинаров или работу с докладами по интересующим их темам, например, приложениям, которые они создали, или аспектам сетевой инфраструктуры, имеющим отношение к разработке (например, как настроить сервер Weblogic с обратным прокси).
Постарайтесь вовлечь обе команды в процессы экспертной оценки.
Честность, порядочность, порядочность. Все, что угодно, лишь бы избежать культуры показания пальцем. Например, если есть серьезная проблема, проведите вскрытие или анализ первопричин. Если возможно, попросите кого-нибудь провести технический семинар по решению.