¿Está desarrollándose para un cambio constante en un entorno corporativo?

Question

Trabajo para una gran empresa que actualmente está en proceso de fusión.Estamos trabajando en varios proyectos que involucran y no involucran la fusión.Un problema que estoy notando es que muchos de los grupos de desarrolladores están muy fragmentados, aunque en su mayoría apoyan muchos proyectos diferentes dentro de su propio ámbito de negocio, y las bases de datos en las que todos trabajamos parecen reflejar eso también.Debido a esto, no confío demasiado en la exactitud de muchos de los datos.

¿Existen modelos o estándares que hayan tenido éxito en la gestión de este tipo de entornos cambiantes?¿Cuáles son buenas formas de comunicar esos cambios a los usuarios?¿Hay formas de crear redundancias para que, si se propone un cambio en una parte de la producción, se comunique a lo largo del proceso?

Editar:hacer esta wiki comunitaria debido a su subjetividad

Answer 1

Recursos dedicados para la supervisión, migración y creación de procesos.

Hemos pasado por fusiones y escisiones, luego compramos otras empresas y estamos en proceso de integrarlas en nuestro "proceso".Cito aquí el proceso porque, en mi opinión, todavía no tenemos ninguno del que hablar.

Creo que donde finalmente tendremos éxito es en que hayamos dedicado recursos a la creación de un proceso que funcione y que abarque a toda la empresa.Scrum está muy bien, pero no necesariamente se aplica a los ciclos de facturación y marketing de la empresa; sin embargo, funcionaría de maravilla en nuestros equipos de desarrollo, I+D e implementación (¡tal vez incluso formar un solo equipo con los tres!).Entonces, ¿cómo podemos encontrar los mejores procesos y prácticas para que cada uno trabaje eficientemente en sus áreas de especialización manteniendo todo unido?

Nuestra fórmula mágica aquí es que tenemos a alguien dedicado a esta misma tarea, que observa cómo están las cosas ahora, analiza lo que se necesita y traza planes para llegar allí y luego los ejecuta.Trabajará con los departamentos, con TI y con quien sea necesario para hacerlo.Lo más importante de todo es que tiene el liderazgo y el respaldo de los cabezudos que le dan la influencia adecuada para hacer rodar las grandes y pesadas rocas (estoy seguro de que usted las tiene, cualquier empresa lo suficientemente grande eventualmente le da sillas cómodas y agradables a quien tenga excedieron su umbral de Peters).Una vez definido el proceso, viene la tarea de instrumentar el proceso adecuadamente y migrar todos los datos de los diferentes sistemas adoptados ad-hoc por cada equipo - empresa antes de la definición.

Hacer todo esto mientras tienes que hacer tus otras tareas es imposible, sé que casi me despiden tratando de hacer precisamente eso (pisé una de muchas de esas rocas), es por eso que necesitas recursos dedicados a esta estructuración interna.Si aún no tienes esto en tu empresa, haría de este mi primer campo de batalla.

Para hacer una analogía, lo que tenemos aquí es un Chef d'Orchestre que sabe lo que es un proceso y que tiene los recursos para hacerlo.No pueden ser personas del tipo CE*, están demasiado ocupadas para esto, pero alguien que no se encuentra en la ruta crítica de ningún proyecto.De esa manera, sigue siendo objetivo y puede dar un paso atrás y mirar el panorama general sin ser absorbido constantemente por el zoológico.Creo que alguien con experiencia en desarrollo que tenga experiencia en paradigmas de procesos tanto ágiles como formales es el más adecuado para este trabajo.El proceso de desarrollo es probablemente el más difícil de concretar y poner en marcha; si puede hacerlo, el resto debería ser fácil, al menos en el papel.

Desde que tenemos esto aquí, los cambios vienen, son lentos pero llegan y hasta ahora es un regalo de Dios cada vez.Cada cambio realizado saca a la luz cómo el resto es ineficiente y le da más municiones para lograrlo.De esta manera, me resulta más fácil vivir con las ineficiencias sabiendo que alguien está trabajando en ello y que, eventualmente, se solucionarán.

Te deseo suerte, no es imposible pero definitivamente es factible.

Answer 2

Su gran negocio suena como cualquier otro. ¿Cuántas de estas características se aplican a usted?

1. diverso ecosistema de servidores, sistemas operativos, sistemas, lenguajes, bases de datos, etc.
2. La duplicación de sistemas (por ejemplo, las dos empresas en la fusión tienen sistemas que hacen lo mismo de forma ligeramente diferente).
3. Muchas bases de datos redundantes; hay una sola fuente de la verdad.
4. Los datos compartida por múltiples aplicaciones.
5. Las porciones de complejidad y dependencia que hace que sea difícil de probar el código.
6. Las porciones de la complejidad causada por esfuerzos "prácticas" de trabajar alrededor de las limitaciones.

No creo que el sentido común o la profesionalidad o cualquier magia va comunicar los cambios hacia arriba y hacia abajo la producción.

Answer 3

Una idea es tener un grupo de personas que supervisan los proyectos para asegurarse de que están en alineación con el negocio. Se necesita algo de liderazgo para mantener las cosas se convierta en un choque de trenes.

Sé que en Scrum, existe el concepto de Scrum de Scrums. Básicamente, un representante de cada equipo se reúne cada día (o con menos frecuencia, en algunos casos) para decirle lo que el equipo ha estado haciendo, lo que se está trabajando en la actualidad, y discutir los obstáculos (que puede ser el otro equipo (s)).

Además, las prácticas ágiles en la dirección general de exactamente el problema en que anticipan el cambio.

Por lo tanto, si la administración no es mantener las cosas en la pista, no va a tener que ser algo realmente buena comunicación y el liderazgo desde el interior.