Разработка для постоянных изменений в корпоративной среде?

Question

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

Существуют ли какие-либо модели или стандарты, которые успешно справляются с такими меняющимися условиями?Каковы хорошие способы сообщить об этих изменениях пользователям?Существуют ли способы создать дублирование, чтобы, если изменение предлагается в одной части производства, оно распространялось по всему конвейеру?

Редактировать:создание этой вики-сообщества из-за ее субъективности

Answer 1

Выделенные ресурсы для контроля процессов, миграции и создания.

Мы прошли через слияния и разделения, затем купили другие компании и находимся в процессе интеграции их в наш «процесс».Я цитирую здесь процесс, потому что, по моему мнению, нам пока не о чем говорить.

Я думаю, что в конечном итоге мы добьемся успеха, так это если у нас будут выделены ресурсы для создания работающего процесса в масштабах всей компании.Скрам — это хорошо, но он не обязательно применим к биллинговому и маркетинговому циклам предприятия, однако он будет творить чудеса в наших командах разработчиков, исследований и разработок и внедрения (возможно, даже получится одна команда из всех трех!).Так как же нам разработать наилучшие процессы и методы для эффективной работы каждого в своей области знаний, сохраняя при этом все это взаимосвязанным?

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

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

Если провести аналогию, то мы имеем здесь руководителя оркестра, который знает, что такое процесс, и у которого есть штаны, чтобы его довести до конца.Это не могут быть люди типа CE*, они слишком заняты для этого, но это не те, кто находится на критическом пути каких-либо проектов.Таким образом, он остается объективным и может сделать шаг назад и посмотреть на картину в целом, не затягиваясь постоянно в зоопарк.Я считаю, что для этой работы лучше всего подойдет человек с опытом разработки, имеющий опыт работы как в гибких, так и в формальных парадигмах процессов.Процесс разработки, скорее всего, является самым трудным для того, чтобы действительно добиться успеха и начать работу. Если он сможет это сделать, остальное должно быть легким, по крайней мере, на бумаге.

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

Желаю вам удачи, это не невозможно, но вполне выполнимо.

Answer 2

Ваш крупный бизнес похож на любой другой.Какие из этих характеристик применимы к вам?

1. Разнообразная экосистема серверов, операционных систем, систем, языков, баз данных и т. д.
2. Дублирование систем (например, обе компании, участвующие в слиянии, имеют системы, которые выполняют одну и ту же функцию несколько разными способами).
3. Множество избыточных баз данных;нет единого источника истины.
4. Данные, совместно используемые несколькими приложениями.
5. Большая сложность и зависимости, которые затрудняют тестирование кода.
6. Много сложностей, вызванных «практическими» попытками обойти ограничения.

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

Answer 3

Одна из идей — создать группу людей, которые будут курировать проекты, чтобы убедиться, что они соответствуют бизнесу.Требуется определенное лидерство, чтобы не допустить, чтобы все превратилось в крушение поезда.

Я знаю, что в Scrum есть концепция Scrum of Scrums.По сути, представитель каждой команды встречается каждый день (а в некоторых случаях реже), чтобы рассказать, чем занимается команда, над чем они работают сегодня, и обсудить препятствия (которыми могут быть другие команды).

Кроме того, гибкие методы в целом решают именно вашу проблему, поскольку они предвидят изменения.

Итак, если руководство не следит за ходом дел, потребуются действительно хорошие коммуникации и лидерство изнутри.