Готовитесь к постоянным изменениям в корпоративной среде? - PullRequest
8 голосов
/ 17 июля 2009

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

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

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

Ответы [ 3 ]

2 голосов
/ 17 июля 2009

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

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

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

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

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

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

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

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

1 голос
/ 17 июля 2009

Ваш большой бизнес звучит как любой другой. Сколько из этих характеристик относится к вам?

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

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

0 голосов
/ 17 июля 2009

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

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

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

Так что, если руководство не будет следить за ходом событий, будет необходимо действительно хорошее общение и лидерство изнутри.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...