Je travaille pour une grande entreprise qui traverse actuellement une fusion. Nous travaillons sur plusieurs projets impliquant et non impliquant la fusion. Un problème que je remarque, c'est que bon nombre des groupes de développeurs sont très fragmentés, même s'ils soutiennent principalement de nombreux projets dans leur propre domaine de l'entreprise et que les bases de données que nous travaillons tous semblent également refléter cela. Je ne suis pas trop confiant dans la précision d'une grande partie des données à cause de cela.
Y a-t-il des modèles ou des normes qui ont réussi à gérer ces types d'environnements changeants? Quels sont les bons moyens de communiquer ces modifications aux utilisateurs? Existe-t-il des moyens de créer des licenciements, donc un changement est proposé dans une partie de la production, il est communiqué de haut en bas sur le pipeline?
EDIT: Faire ce wiki communautaire en raison de son subjection
3 Réponses :
Votre grande entreprise sonne comme tous les autres. Combien de ces caractéristiques s'appliquent à vous?
Je ne pense pas que le bon sens ou le professionnalisme ou à une magie consiste à communiquer des changements de production de haut en bas.
Oui, ils s'appliquent tous. J'ai du mal à vivre avec cela comme un état actuel acceptable.
Une pensée est d'avoir un groupe de personnes qui superviseraient les projets pour s'assurer qu'ils sont en alignement sur l'entreprise. Il faut du leadership pour empêcher les choses de devenir une épave de train.
Je sais dans Scrum, il y a le concept de Scrum of Scrums. Fondamentalement, un représentant de chaque équipe se réunit chaque jour (ou moins souvent dans certains cas) de dire ce que l'équipe a fait jusqu'à ce qu'elles travaillent aujourd'hui et discutent des obstacles (ce qui peut être l'autre équipe (s)).
Aussi, les pratiques agiles en général adressent exactement votre problème en ce qu'ils anticipent le changement.
Ainsi, si la direction ne garde pas les choses sur la bonne voie, il y aura une très bonne communication et leadership de l'intérieur.
Nous avons traversé la fusion et les Salesgers, puis nous avons acheté d'autres entreprises et sommes en train de les intégrer dans notre "processus". Je cite un processus ici parce que, à mon avis, nous n'avons toujours pas de parler de.
Où nous réussirons éventuellement, je pense que nous avons des ressources dédiées à la création d'un processus qui fonctionne et qui est large. Scrum est tout bon mais il ne s'applique pas nécessairement aux cycles de facturation et de marketing de l'entreprise, mais cela fonctionnerait émerveillement dans nos équipes de développement, R & D et Mise en œuvre (peut-être même faire une seule équipe sur trois!). Alors, comment pouvons-nous trouver le meilleur processus et les meilleures pratiques pour que chacun fonctionne efficacement dans leurs domaines d'expertise tout en le gardant ensemble?
Notre balle magique ici est que nous avons une personne dédiée à cette tâche même, il examine comment elle est maintenant, examine ce qui est nécessaire et dessine des plans pour y arriver, puis les exécutera. Il travaillera avec les départements, avec elle et quiconque est tenu de le faire. Le plus important de tous, il a le leadership et le soutien des grandes têtes pour lui donner le bon effet de levier pour que les gros rochers lourds roulent (je suis sûr que vous en avez, toute entreprise suffisamment grosse éventuellement de belles chaises confortables à Whomever dépassé leur seuil de péter). Une fois que le processus est défini, la tâche consiste à affecter le processus de manière appropriée et à migrer toutes les données de tous les systèmes différents adoptés ad-hoc par chaque équipe - entreprises avant la définition.
Pour faire tout cela pendant que vous devez faire vos autres tâches n'est que impossible, je sais que vous savez presque être tiré en essayant de faire cela (piétiné sur un à nombre d'entre eux), c'est pourquoi vous avez besoin de ressources dédiées à cette structuration interne . Si vous n'avez pas encore cela dans votre entreprise, je ferais cela mon premier champ de bataille.
Pour faire une analogie ce que nous sommes arrivés ici est un chef d'orchestre qui sait quel processus est et qui a le pantalon de le faire faire. Cela ne peut pas être des personnes de type CE * Ils sont trop occupées pour cela, mais une personne ne figure pas dans le chemin critique d'aucun projet. De cette façon, il reste objectif et peut prendre un recul et regarder la grande image sans être constamment sucé dans le zoo. Je trouve que quelqu'un avec le développement de développement qui a de l'expérience dans les paradigmes d'agilité et de processus formels est le mieux adapté à cet emploi. Le processus de développement est très probablement le plus difficile de réellement clouer et d'y aller, s'il peut le faire, le reste doit être facile, le moins sur papier.
Depuis que nous avons eu cela ici, les changements arrivent, cela vient lent mais il vient et jusqu'à présent, c'est un dieu envoyé à chaque fois. Chaque modification apportée apporte à la lumière de la manière dont le repos est inefficace et lui donne plus de munitions pour le faire. De cette façon, je trouve plus facile de vivre avec les inefficiences sachant que quelqu'un travaille et ils seront finalement repassés.
Je vous souhaite bonne chance, ce n'est pas impossible, mais il est définitivement faisable.