Je suis directeur de l'ingénierie produit pour mon entreprise. Mon PDG m'a demandé de créer un document sur les normes technologiques, expliquant des choses comme la technologie que nous utilisons, notre politique d'adaptation aux nouvelles technologies et les normes de conception comme le pourcentage de code couvert par les tests unitaires. Je n'ai jamais eu à faire quelque chose comme ça, et j'ai passé beaucoup de temps à chercher des exemples sur le web, mais je n'en ai pas trouvé du tout. Les plus proches que j'ai trouvés sont des documents décrivant des spécifications techniques pour un produit individuel. Cependant, j'essaie de définir cela pour toute l'entreprise. Quelqu'un peut-il fournir des exemples de la façon dont ce document pourrait être formaté/organisé, et quel serait le contenu typique? Merci!Comment créer un document de normes technologiques pour mon entreprise?
Répondre
Vous devriez probablement penser à la raison pour laquelle on vous demande d'écrire le document. Est-ce quelque chose destiné à faciliter votre processus d'ingénierie et de développement de produits? Cela fait-il partie du programme de diligence raisonnable que les investisseurs potentiels recevront? Essayez-vous d'obtenir une sorte de certification de processus comme ISO9000? Est-ce simple fluff chargé de jargon-mission-déclaration qui ne servira aucun but réel?
Du haut de ma tête, vous voudrez peut-être parler:
- en utilisant la technologie appropriée
- comment la sélection et les décisions d'achat seront: sur une base technique défendable?
- se tenir au courant de la communauté accepté les meilleures pratiques pour les technologies que nous déployons
- identifier et utiliser les meilleurs outils pour le travail afin d'améliorer la productivité des développeurs
- votre attitude à l'égard des solutions open-source (peut-être OK, à condition qu'ils résolvent le problème et les aspects juridiques sont extraits, vous pouvez souhaiter inclure des règles sur les licences Open Source les plus courantes)
- vos processus de développement. Utilisez-vous une méthodologie formelle (cascade/agile/scrum/extrême/TDD/...) ou quelque chose de plus ad hoc? Qu'en est-il du flux de travail de développement? (Je veux dire le suivi des bogues, le contrôle des validations du code source, les procédures de publication, etc.)
- laissez-vous du temps aux ingénieurs pour le développement professionnel? (conférences, cours, projets parallèles)? Qu'en est-il de quelque chose comme "20% du temps" que l'on trouve dans Google et ailleurs?
Vous devriez simplement aller de l'avant. C'est généralement le genre de documents internes que vous ne trouverez pas sur le net.
Le meilleur document que vous écrivez viendra de vous-même, en écrivant les grandes choses. Le contenu organisationnel d'un tel document est trop spécifique à l'activité et à la culture de votre entreprise.
Il y a plusieurs façons d'aborder un tel document. Le contenu exact dépend de ce que vous voulez accomplir. Voici un exemple (link to page/direct link to PDF). Il semble axé sur la liste des technologies existantes, abandonnées et à venir dans l'organisation afin que les fournisseurs sachent avec quoi ils vont travailler. Ceci illustre une approche.
De toute évidence, ce document particulier ne couvre pas les normes de conception comme les tests unitaires. Encore une fois, le contenu dépend de vos objectifs particuliers ...
Les PDG ne demandent cela que s'ils ont de sérieuses inquiétudes à propos de quelque chose. Votre premier pas est d'aller lui parler de l'inquiétude qu'il essaie d'aborder.Il peut s'agir d'un malentendu, de problèmes de coûts, de délais de mise sur le marché, de problèmes de verrouillage des fournisseurs sur des éléments stratégiques, de manque de ressources pour les RH, etc. Votre PDG appréciera grandement que vous posiez des questions pour savoir quelles sont les préoccupations qu'il essaie d'aborder. Cela vous donnera également une idée de la chronologie et du niveau de détail requis.
J'ai créé deux jusqu'à présent. Un pour la production de semi-conducteurs et un pour la consolidation des centres de données. C'est le flux de travail que j'ai utilisé.
Demandez à vos architectes créent une vision de haut niveau Faire une structure wiki qui divise par la technologie pour faire des mises à jour sûres sont faciles et peuvent être distribués Affectez un propriétaire de documentation pour chaque technologie/équipe Assigner une avance technologique à posséder la cohérence et pour examiner les dépendances Déléguer chaque équipe pour documenter chaque technologie avec un SWOT et une décision Affecter un bon gestionnaire de programme, mettre en place une gouvernance solide et communiquer beaucoup à tous les niveaux Après trois semaines, revenez en arrière et faites une stratégie qui met l'accent sur la standardisation et l'élimination des menaces dans le SWOT Si nécessaire, vous pouvez mettre des processeurs (ITIL, ISO, etc.) à votre convenance. point. Le faire avant est un gaspillage de ressources.
Les principaux facteurs de succès pour cette tâche sont la propriété distribuée par des experts, la participation et l'adhésion ascendantes, une gouvernance forte et (comme toujours) la communication.
Ce n'est pas une tâche facile et elle a un impact stratégique profond. Selon la taille de votre entreprise et l'expérience de votre personnel, vous pourriez avoir besoin de conseils pour vous aider. Si vous le faites, regardez à l'extérieur de vos fournisseurs, et choisissez quelqu'un d'une industrie en mouvement rapide (IT/semi-conducteurs/automobile etc.)
N'hésitez pas à me contacter si vous avez besoin de plus d'aide. Je ne cherche pas d'emploi, et je ne cherche pas à vous vendre du conseil, promis.
Il existe une approche fondée sur les «meilleures pratiques» parmi les grandes entreprises. Il existe une hiérarchie des «artefacts» de gouvernance ou des documents. Le plus haut niveau est la stratégie d'entreprise et la stratégie informatique. Cela semble être hors de votre portée. Il devrait y avoir un ensemble de principes informatiques (voir le groupe ouvert) qui décrivent le type de qualités que vous souhaitez, et ceux-ci pourraient avoir un niveau supérieur de «principes directeurs» et des principes spécifiques tels que la gestion des données, la conception des applications, l'infrastructure et même IT Management. Mais ce n'est pas ce que vous avez demandé. Quand il s'agit de politiques et de normes, il est bon de comprendre la différence. La politique est générale et sur le contrôle et la gestion, les normes sont spécifiques et sur ce qu'il faut faire et ne pas faire. Il existe également des lignes directrices sur la façon de faire les choses ou sur les domaines où vous ne voulez pas être trop impératif, mais qui offrent les meilleures façons de faire les choses. Ceux-ci sont normalement sur des domaines très spécifiques ... par exemple: Test Automation Documentation; Codage de la qualité du code; Collection de métadonnées automatisation des tâches par lots .... à ce niveau. Mais ceux-ci pourraient être des normes si vous voulez créer des règles strictes et rapides, plutôt que des conseils utiles. Donc, revenons aux normes et aux politiques ... Vous avez besoin des deux. La politique devrait définir le domaine, définir l'autorité - ce que les postes de direction/titres propres responsabilité. Définitions C'est très important. Même si vos définitions n'incluent pas toutes les significations possibles dans la pratique générale de l'industrie, vous devez dire ce que cela signifie à la société XYZ et dans le contexte de cette politique ... de réduire les arguments sur l'interprétation de la politique.
Il existe des exemples là-bas. Généralement, les gouvernements des États ont de bons exemples parce qu'ils ont tendance à aimer et à avoir besoin d'une «gouvernance» des TI et que leurs documents sont souvent des «informations publiques». Même les gouvernements étrangers (j'ai trouvé de bons exemples d'Australie).
Les normes suivent la politique et énoncent les règles spécifiques, pas seulement le cadre de gestion. Donc, non, vous ne devriez pas écrire simplement du fond du cœur, ou écrire ce que vous voulez. Il y a un moyen de le faire. Vous pouvez commencer à écrire des normes, et ce n'est pas un mauvais point de départ. Vous ne vous contentez pas d'écrire un document de normes pour tout ce qui est sous le soleil. Vous identifiez les zones où il y a un besoin. Où il y a de la turbulence dans la qualité de la conception ou la maniabilité ou quoi que ce soit qui provoque la douleur. Mais vous avez besoin de la couche de documents de politique au-dessus des normes pour dire qui est chargé de les appliquer, qui les possède, qui a la responsabilité de réviser, de changer. Y a-t-il un comité directeur exécutif? Y a-t-il un comité de propriété technique qui fera appel aux bonnes PME pour rédiger et réviser la norme afin de s'assurer qu'elle est logique sur le plan technique et qu'elle règle les problèmes réels ... ne fait-elle pas plus de mal que de bien? Alors peut-être essayer d'écrire un Standard ou deux (trouver un bon modèle ou un exemple sur Internet) et ensuite imaginer la politique qui serait nécessaire pour donner à votre nouvelle norme Backbone et vitalité - c'est-à-dire un sponsor puissant, une conformité processus et un processus d'examen. Il peut et devrait y avoir un tas de normes dans chaque politique. Alors faites une liste de candidats pour commencer - peut-être quelques priorités et montrez-le à votre patron. Parlez-lui de la symbiose de la politique et des normes. Tu seras un héros.