Nous avons un projet pour développer et implémenter un nouveau système informatique! Et vous avez besoin d'un PM ...
Que s'est-il passé? Où sans ça. Et il semble que le marché soit saturé de toutes sortes de chefs de projets.
- Choisissez! Chacun a une merveilleuse expérience riche. Il y a des PM ayant de l'expérience dans la mise en œuvre de projets dans la construction et la défense. Il existe des PM expérimentés dans la mise en œuvre de projets médicaux. Il y en a même dans l'avion! De quoi d'autre avez-vous besoin!? Le niveau de responsabilité et d'exigence dans ces industries est un véritable dépotoir.
"Le connaît-il?"
- Pourquoi avez-vous besoin de ça?! Il a une excellente connaissance de la méthodologie de gestion de projet ... c'est l'essentiel!
Et cela s'est également produit ...
Comprenons si l'informatique est nécessaire pour un chef de projet qui devrait venir organiser le développement et la mise en place d'un système d'information.
Donc, vous devez d'abord développer un système d'information!
- Allez, PM, que ferez-vous en premier?
- Définissez le besoin et les objectifs!
- Bien. Et alors?
- Préparons un plan de projet de développement!
- C'est logique. Et quelles sont les étapes de développement? Il est nécessaire de déterminer les tâches de haut niveau pour la composition!
"Pourquoi ai-je besoin de ça?" Je vais demander à quelqu'un!
- Et qui en informatique possède ces informations?
- Qui, qui? Le programmeur ... probablement ...
Plus récemment, je suis tombé sur une histoire similaire. D'une part, tout semble bien se passer. En effet, le programmeur connaît les étapes de développement habituelles. Mais, faisons un amendement. Pour ne pas rater la cible, passons à l'architecte! Il doit être sûr.
- Salut, architecte. En quoi consiste le développement? Besoin de tâches dans le plan.
- Nous devons prendre les savoirs traditionnels et les entailles fonctionnels dessus!
"C'est tout?!" Si facile
- Eh bien, teste toujours.
- Et si les savoirs traditionnels changent dans le processus?
"Je ne sais pas." Mon travail consiste à travailler sur les savoirs traditionnels
Nous sommes descendus. Ils ont demandé. A reçu 2 points: savoirs traditionnels et développement.
- Qu'allons-nous faire, PM?
- Alors tout est clair! Nous le demanderons et le remettrons à l'architecte. Qu'on l'apprécie. Dit la date limite. Il déterminera les points de préparation et nous le contrôlerons à ces points. Et montrez périodiquement à l'utilisateur le résultat.
C'est comme ça que ça se passe, approximativement, quand le PM n'est pas au courant.
Et que lui demanderions-nous lorsque nous aurions embauché? Et si vous allez très loin, alors quel est le cycle de vie du système d'information de sa naissance à sa mort. Bien que les systèmes ne meurent pas. Ils sont «moralement» obsolètes.
Je n'oublierai jamais l'histoire «drôle» avec le système de climatisation des canaux qui s'est produite dans notre usine. On a donc trouvé un système. Bon, puissant. Il devait refroidir toute l'usine et les bâtiments administratifs adjacents. Bien acheté. Pour quelque chose autour de 200K roubles américains. Ils l'ont dit. Mise en service. Après plusieurs mois de fonctionnement, le système est plié. Pourquoi? Oui, car aucun système ne peut survivre sans assistance et sans assistance technique régulière!
Mais le système d'information n'est pas différent. En outre, comme d'autres systèmes, il nécessite une mise en service. Tout comme les autres, ce sont les infrastructures. Et, parfois, les erreurs de mise en œuvre qui se sont produites sur un projet de mise en œuvre d'un système financier sont beaucoup plus coûteuses que la rupture d'un kondeya.
Alors, comment le PM qui est venu dans le projet informatique de l'industrie de l'aviation ou de la construction peut-il dessiner un plan qui devrait contenir toutes ces étapes?
Obtenez des conseils de l'architecte? Qui voit fragmentairement sa tâche et n'imagine pas ce qui est «avant» et ce qui est «après»? Hélas. Un tel projet est voué à l'avance.
Par conséquent, il est important pour un projet informatique de comprendre PM, les tâches qui composent le projet, les tâches liées et celles qui peuvent être effectuées en parallèle.
Et comment comprenons-nous maintenant combien de PM correspondent au résultat attendu? Pour ce faire, il y a un certain nombre de questions pas difficiles auxquelles nous devons obtenir des réponses claires.
Question 1: Quelles sont les étapes de la formation des spécifications techniques pour le développement?La réponse est:- De la formation des exigences fonctionnelles du client
- Formation de la tâche pour l'infrastructure, qui, à son tour, est le résultat du développement du contrat de tolérance aux pannes et de sauvegarde
- Et à partir de la carte de l'interaction du futur système avec d'autres systèmes.
En fait, nous obtenons 3 tâches à la sortie: fonctionnelle et technique, spécifications techniques pour l'infrastructure, spécifications techniques pour le développement de l'interface. Ce sont aussi des points de contrôle pour le contrôle.
Question 2: Quelles sont les étapes de développement?La réponse est:- De la répartition des tâches par les développeurs
- De la formation du plan d'acceptation
- De tests complets (pilotage)
- De la création d'un plan de migration à l'élaboration de ce plan
Question 3: Quelles sont les étapes de la mise en service?
La réponse est:- Test de charge
- La formation du matériel pédagogique
- Formation des utilisateurs
- Remplir tous les NSI (Informations de référence normatives + accès utilisateur)
- Migration de données
- Rapprochement des soldes
- Début des travaux opérationnels (pilotage)
- Assistance à chaud lors du premier lancement
Question 4: À quoi ressemble le schéma de transfert du système vers le support après la mise en service?La réponse est:Au moins, le système a 3 niveaux de support:
- Prise en charge de l'infrastructure et surveillance de la charge du serveur
- Support fonctionnel et surveillance des threads, en cas de problème dans le système.
- Support méthodologique apportant des réponses aux questions de savoir pourquoi cela fonctionne ainsi et non autrement, ainsi que la collecte des besoins d'évolutions
Et chacune de ces étapes devrait avoir son propre SLA. Voici également un mot qui n'est pas toujours clair pour les personnes extérieures à l'informatique.
Si le candidat PM n'a pas nommé toutes les étapes - cela n'a pas d'importance. Pourrait oublier quelque chose ou s'inquiéter. Une fois le plan établi, il les rencontrera d'une manière ou d'une autre. C'est bien pire s'il ne l'imagine pas du tout. La situation deviendra plus compliquée s'il commence à projeter son expérience antérieure d'autres secteurs d'activité sur l'informatique. Dans ce cas, l'équipe commencera les conflits et la "mort" des développeurs. Le bénéfice d'un technicien lui-même peut toujours être trouvé partout où la gestion compétente d'un projet informatique sera sa zone de confort.