Готовитесь к постоянным изменениям в корпоративной среде?
Я работаю в крупной компании, которая в настоящее время проходит слияние. Мы работаем над несколькими проектами, связанными и не связанными со слиянием. Одна проблема, которую я замечаю, заключается в том, что многие группы разработчиков сильно фрагментированы, хотя в основном они поддерживают множество различных проектов в своей сфере бизнеса, и базы данных, над которыми мы все работаем, похоже, отражают это. Я не слишком уверен в точности большей части данных из-за этого.
Существуют ли какие-либо модели или стандарты, которые были успешны в управлении этими типами изменяющихся сред? Каковы хорошие способы донести эти изменения до пользователей? Существуют ли способы создания избыточности, поэтому, если предлагается изменение в одной части производства, оно передается по конвейеру?
Редактировать: создание этого сообщества вики из-за его субъективности
3 ответа
Выделенные ресурсы для контроля процессов, миграции и создания.
Мы прошли через слияния и слияния, затем купили другие компании и в настоящее время интегрируем их в наш "процесс". Я цитирую процесс здесь, потому что, по моему мнению, нам еще не о чем говорить.
То, где мы в конечном итоге добьемся успеха, я думаю, это то, что у нас есть выделенные ресурсы для создания процесса, который работает в масштабах компании. Скрам - это хорошо, но он не обязательно применим к циклам выставления счетов и маркетинга на предприятии, однако он удивителен в наших командах разработчиков, разработчиков и разработчиков (возможно, даже из одной команды из одной!). Так, как мы придумали лучший процесс и методы для каждого, чтобы эффективно работать в их областях экспертизы, сохраняя все это вместе?
Наша волшебная пуля здесь в том, что у нас есть кто-то, посвятивший себя этой задаче, он смотрит на то, как оно сейчас, смотрит на то, что нужно, и составляет планы, чтобы добраться до него, а затем выполняет их. Он будет работать с отделами, с ИТ и с кем угодно, чтобы это сделать. Самое главное, что у него есть руководство и поддержка со стороны больших руководителей, чтобы дать ему надлежащие рычаги для того, чтобы заставить большие тяжелые валуны катиться (я уверен, что у вас это есть, любая достаточно большая компания в конечном итоге дает хорошие удобные кресла тому, у кого есть превысил их порог Петерс). Как только процесс определен, наступает задача надлежащего инструментария процесса и переноса всех данных из всех различных систем, принятых ad-hoc каждой группой - компаниями до определения.
Делать все это, в то время как вы должны выполнять свои другие задачи, но невозможно, я знаю, что чуть не уволили, пытаясь сделать это (наступив на один из множества валунов), поэтому вам нужны выделенные ресурсы для этой внутренней структуры. Если у вас этого еще нет в вашей компании, я бы сделал это своим первым полем битвы.
Чтобы провести аналогию, мы получили шеф-повара Орчестра, который знает, что такое процесс, и имеет штаны, чтобы сделать это. Это не могут быть люди типа CE*, которым они слишком заняты, но кто-то, кто не находится на критическом пути каких-либо проектов. Таким образом, он остается объективным и может сделать шаг назад и посмотреть на общую картину, не будучи постоянно втянутым в зоопарк. Я считаю, что для этой работы лучше всего подходит человек с опытом разработки, имеющий опыт работы с гибкими и формальными парадигмами процессов. Скорее всего, процесс разработки является самым сложным, чтобы по-настоящему приступить к работе, если он сможет это сделать, все остальное должно быть легким, хотя бы на бумаге.
С тех пор, как мы получили это здесь, изменения происходят, это происходит медленно, но это происходит, и до сих пор это бог посылает каждый раз. Каждое внесенное изменение выявляет, насколько остальное неэффективно, и дает ему больше боеприпасов, чтобы сделать это. Таким образом, мне легче жить с неэффективностью, зная, что кто-то работает над этим, и они, в конце концов, будут устранены.
Я желаю вам удачи, это не невозможно, но это, безусловно, выполнимо.
Ваш большой бизнес звучит как любой другой. Сколько из этих характеристик относится к вам?
- Разнообразная экосистема серверов, операционных систем, систем, языков, баз данных и т. Д.
- Дублирование систем (например, обе компании, участвующие в слиянии, имеют системы, которые делают одно и то же несколько отличающимися друг от друга способами).
- Много избыточных баз данных; ни одного источника правды.
- Данные, используемые несколькими приложениями.
- Много сложностей и зависимостей, которые затрудняют тестирование кода.
- Много сложностей, вызванных "практическими" попытками обойти ограничения.
Я не думаю, что здравый смысл, профессионализм или какая-либо магия сообщают об изменениях в процессе производства.
Одна мысль состоит в том, чтобы иметь группу людей, которые наблюдают за проектами, чтобы удостовериться, что они соответствуют бизнесу. Требуется некоторое лидерство, чтобы не допустить превращения вещей в крушение поезда.
Я знаю в Scrum, есть концепция Scrum of Scrums. В основном, представители каждой команды встречаются каждый день (или реже в некоторых случаях), чтобы рассказать о том, чем занималась команда, над чем они работают сегодня, и обсудить препятствия (которые могут быть другой командой).
Кроме того, гибкие практики в целом решают именно вашу проблему в том смысле, что они ожидают изменений.
Таким образом, если руководство не будет следить за ходом событий, потребуется некоторое действительно хорошее общение и лидерство изнутри.