Pourquoi séparer support et développement ?
L'infrastructure et le développement ont été séparés depuis des années dans la plupart des entreprises. Une autre séparation est également souvent faite entre le support applicatif et le développement. Les principales raison étant la séparation des rôles, nature différentes des tâches et un meilleur contrôle.
Separation des rôles (Sox 404)
Bien que ce chapitre de Sox ne dit pas clairement que les activités de projet et de maintenance devraient être séparées, les auditeurs demandent d'avoir des "release managers" indépendants pour avoir un meilleur contrôle sur ce qui est livré. Des environnements distincts assurent que la livraison est faite à travers un processus après que les tests concluant aient été effectués.
Mettre en place un "release manager" pousse ce concept un peu plus loin pour assurer également la tracabilité des besoins à la livraison. Ce qui est livré doit être cohérent avec les besoins et le "release manager" est responsable d'assurer cette tracabilité qui ne peut être garantie par les services d'infrastructure.
Le "release manager" ne peut faire partie des équipes de développement (conflit d'intérêt évident) et devrait donc faire partie de l'équipe de support. Réaliser tests et livraison dans l'équipe de support application apporte d'autre avantages : l'équipe de support est impliquée plus tôt, connait la nouvelle version à l'avance et sera en mesure d'apporter un meilleur support.
Parce que le travail est différent
Les capacités nécessaires pour développer ou pour gérer des systèmes diffèrent : le développement mobilise des personnes innovantes et créatrices tandis que le support requiert des personnes fiables et solides.
Le rythme de travail est également différent : le support doit traiter tout incident immédiatement mettant de côté les tâches en cours. Les équipes de développement ne peuvent pas se permettre le risque de différer une livraison du fait de nombreux incidents.
De plus, résoudre un incident demande beaucoup d´énergie, d´attention et de résistance au stress. Quant un incident est clos, la pression retombe, réduisant la capacité de travail sur une période bien plus longue que celle de l´incident.
Parce qu´avoir une vue indépendante apporte de la valeur
Mettre en place un support indépendant apporte une vue complémentaire, utile en particulier lors des mises en production. Une équipe de support indépendante permet d´assurer que les procédures de test ont été suivies et que les vues optimistes de certains ne gouvernent pas les mises en production. Disposer d´une vue indépendante sur la manière dont le développement suit les procédures est un plus important. On pourrait penser que ce type d´organisation génère des conflits, l´expérience montre que ce n´est pas le cas, les deux parties connaissant les règles du jeu.
Bien sûr séparer développement et support applicatif comporte des inconvénients comme : une communication plus difficile, un fonctionnement avec deux équipes au lieu d´une seule et enfin ce type d´organisation ne peut s´appliquer que pour des équipes de taille suffisante.
Communication
Au lieu d´avoir une seule équipe en face d´eux, les utilisateurs dialoguent avec deux équipes (support et développement) et ont besoin de comprendre les rôles de chaque équipe. N´étant plus impliqué sur les incidents, le développement échange moins avec les utilisateurs. Cela pourrait appauvrir les retours utilisateur impactant la qualité du code produit.
Travailler ensemble
Avoir deux équipes au lieu d´une seule est plus difficile et exige un étroit travail en commun en particulier pour les phases critiques comme les livraisons.
Les deux équipes doivent également travailler ensemble sur le support de niveau 3 : l´équipe de support applicatif n´a pas la connaissance intime du code, il doit se reposer sur l´équipe de développement pour le support de niveau 3.
Dans l´autre sens, l´équipe de support peut aider l´équipe de développement sur les tâches techniques proches de l´infrastructure sur lesquelles le support a plus de connaissance.
Enfin, une attention particulière doit être portée sur la responsabilité : deux équipes livrant un service joint peut générer une perte de responsabilité dans la résolution des incidents.
Même si une telle organisation n´est pas facile à mettre en œuvre et qu´elle présente des inconvénients, d´un point de vue général, les avantages sont solides. L´expérience montre que pour des équipes taille moyenne ou grande ce type d´organisation a du sens. Pour des plus petites équipes (moins de 10 personnes) cette organisation a moins d´intérêt.
Application and infrastructure activities have been segregated for years in most organizations.
Another split is also often made between support and development. Main drivers for doing so are usually: segregation of duties, different nature of activities and control
Segregation of duties (Sox 404)
Although this section of Sox does not state clearly that run and change should be separate, auditors are asking for separate release managers in order to have more control on what is been released. Separate environments ensure that rollout is done through a managed process after a proper testing has been performed.
Having in place a release manager is pushing this concept a step further to also ensure traceability from requirements to delivery. What is delivered must be consistent with the requirements and the release manager is accounting for this traceability which cannot be guaranteed by infrastructure.
The release manager cannot be part of the development team (obvious conflict of interest) and should belong to the support team. Performing testing in the support team brings additional benefits: the support team is involved and knows about the new version in advance and is likely to give a better support
Because work is different
Skill set is different: for development the need is to have creative/innovative people bringing new solutions whereas for support the need is reliable and sound people managing safely systems. Managing a system is different from creating a system
Timeframe is also different: support needs to pickup immediately any incident postponing other activities they may have. Development cannot afford to put at risk project commitments due to multiple incidents. Furthermore, solving incidents is very intense, demanding a lot of concentration and resistance to pressure. When the incident is solved, pressure releases impacting work capacity for a much longer period than the incident itself.
Because having an independent view is bringing value
Having a separate support brings an independent view especially useful for rollouts. This ensures that the proper testing procedure has been followed and that wishful thinking is not driving system upgrades! Having an independent opinion on how development is following procedures is also valuable. On could think that this kind of organization is generating conflicts, experience shows that it is not the case as both parties know the rules of the game.
Of course, such organization has drawbacks like: communication, working together in two teams instead of one and also such an organization cannot be applied for small teams where the critical mass is not sufficient to split one team in two.
Communication
Instead of having only one team in front of them, users need to talk to two teams (support and development) and need to understand the difference between the two. Development team is also losing some interactions with users and they may not get all the feedback they get when they provide also support. This potential farther distance between development and users could impact the relevance of the software produced.
Working together
Obviously, having two teams working on the same topic is more difficult than having one and the two teams need to work closely together especially in critical phases like rollouts.
Another area where the two teams need to interact is third level support: as the support team is losing intimate knowledge with the software, they need to rely on development to perform third level support activities.
On the other way round, support may help development on technical matters linked to infrastructure where they usually have a greater knowledge.
Last but not least, special attention should be put in not losing accountability: having two team delivering a combined service to users may lead to less accountability from support as they handle the incidents.
Even if such an organization is not so straightforward to implement and is showing drawbacks, overall benefits are strong. For mid size or large development teams, experience shows that it is making a lot of sense. For smaller setups, (less than 10 people), it is definitely less relevant.
Aucun commentaire:
Enregistrer un commentaire