En règle générale, dans le domaine du développement Web personnalisé, toutes les agences ne rêvent que de clients dont les projets augmenteront de deux fois en chiffre d'affaires annuel, livrent régulièrement des cas dont vous pouvez vous vanter et gagnent des notes de profil pour l'agence. Ces clients sont des leaders de l'industrie. Il s'agit soit de sociétés dont l'activité se construit sur le web, soit de grands réseaux offline qui, grâce à des investissements impressionnants, accèdent aux premières places du canal web.
Il semble qu'ayant quelques clients, vous pouvez vous reposer sur vos lauriers - arrêtez de vendre et contrôlez simplement le flux toujours croissant de tâches. Mais en réalité, à mesure que le projet se développe, il vous donnera de nouveaux et nouveaux défis pour faire face et sauver le client, tout en travaillant de manière rentable, ce sera une tâche très difficile.
Croissance du projet et défis connexes
Il est important de prendre des mesures proactives à temps et de supporter les coûts supplémentaires associés à la mise à l'échelle. Au début, cela peut nuire à la rentabilité, mais en atteignant certains volumes, il deviendra clair que l'investissement initial était justifié.
Voici les principaux défis auxquels l'agence peut être confrontée sur un tel projet:
- Le problème de la mise à l'échelle est la restructuration de la structure de l'équipe avec la croissance des volumes.
- La nécessité de comprendre le produit et les tâches commerciales - sans une analyse de produit solide, il est impossible de travailler efficacement sur un grand projet.
- Architecture logicielle et serveur sophistiquée - parallèlement à la croissance des volumes de production dans le cadre du projet, il y a également une augmentation de la fréquentation, conduisant à une architecture plus complexe et à la nécessité d'utiliser des solutions à haute charge.
- Exigences de qualité élevées.
- La nécessité d'assurer un fonctionnement ininterrompu 24h / 24 et 7j / 7 et une réponse rapide aux incidents, y compris en dehors des heures.
- Haut degré de responsabilité pour l'arrêt des ventes.
- Suivi et contrôle des indicateurs métiers.
Toutes les agences sur le marché n'ont pas les compétences nécessaires pour relever tous ces défis. Aujourd'hui, nous allons parler du problème de la mise à l'échelle de l'équipe - l'aspect le plus difficile, à mon avis, de travailler avec un projet en pleine croissance.
J'ai eu l'opportunité de travailler sur plusieurs projets à croissance explosive, dont la plus grande boutique en ligne de produits pour enfants et une grande compagnie d'assurance.
J'ai participé à ces projets d'abord en tant que manager, puis en tant que chef d'une équipe de direction, et je souhaite partager l'expérience acquise.
Rôles sur un petit projet et pourquoi vous devez évoluer
Le schéma de rôle ressemble à ceci dans le cas général:
Chez AGIMA, nous utilisons une gestion en trois étapes, lorsque tous les problèmes tactiques sont décidés dans le cadre d'une interaction au sein de l'équipe de projet, et que les problèmes stratégiques sont portés au niveau du directeur de compte et du chef du service client. Une hiérarchie se construit au sein de l'équipe projet, en fonction de l'ampleur du projet, j'en parlerai ci-dessous.
Voici à quoi ressemble un diagramme de rôle typique au sein d'une équipe de projet sur un petit projet:
Le projet a deux rôles clés: chef de projet (RP) et chef d'équipe.
L'entreprise communique avec le client, formalise les tâches, établit un carnet de commandes, détermine les priorités, établit les plans et exerce le contrôle des tâches pour le respect de la logique métier. De plus, RP communique à toutes les étapes du travail avec les départements de conception, de conception, d'analyse et d'administration système.
Timlid procède à la formalisation technique des tâches, définit les technologies / outils utilisés, procède à une revue de code, réalise les versions, surveille l'intégrité architecturale du projet et coordonne les équipes de développement.
Les ressources restantes peuvent être connectées au projet selon les besoins et sont hautement interchangeables.
Une étape importante dans la croissance du projet et un changement de paradigme particulier se produisent à un moment où il est impossible de garder toutes les informations dans une seule tête. Un chef d'équipe ne peut physiquement contrôler toute l'architecture du projet, car il se développe trop rapidement. Un manager n'a pas le temps de se plonger dans toutes les tâches et de contrôler tout le travail.
Il y a un besoin de séparation et de duplication des tâches des employés, et le schéma de rôle standard se développe et devient plus compliqué.
Structure de l'équipe de gestion
L'une des unités les plus difficiles à évoluer est la RP.
Au fur et à mesure que le projet se développe, il est logique de mettre en œuvre le schéma classique de gestionnaire de compte - gestionnaire de projet, lorsqu'un RP prend en charge le service client, y compris les problèmes de produit, et le second organise le processus de production au sein de l'entreprise.
Cependant, un tel régime devient une impasse avec une croissance ultérieure. Dans le cadre d'un projet, il peut y avoir jusqu'à plusieurs dizaines de produits, chacun nécessitant une attention particulière du point de vue des processus métier. Dans ce cas, des situations surviennent périodiquement lorsque le développement parallèle de différents produits conduit à des conflits logiques dans le cadre de l'architecture d'application web ou de la logique métier, ce qui comporte des risques extrêmement élevés.
Par conséquent, le schéma idéal du point de vue d'une plus grande évolutivité est le suivant:
Le chef de groupe (GH) gère le personnel de gestion du projet et est responsable du contrôle des budgets, de la rentabilité, de la formation des équipes (à la fois exécutives managériales et directes) et de l'allocation des ressources, et résout les problèmes stratégiques de gestion de projet. Il effectue également le contrôle des produits et surveille l'absence de conflits dans les processus parallèles. Il ne consacre pas de temps aux activités opérationnelles et au suivi de la mise en œuvre de chaque tâche spécifique.
Grâce à l'introduction de ce rôle, les cas sont éliminés lorsque plusieurs tâches importantes sont effectuées en parallèle et des contradictions et des conflits logiques sont révélés au stade final, ce qui dans le cas le moins réussi aboutit à une refactorisation complète.
Si nécessaire, un rôle de Product Owner supplémentaire est connecté, auquel GH délègue une partie des responsabilités du produit. Le plus souvent, cet employé est basé sur le côté client et relaie tous les souhaits de l'entreprise sous forme de tâches formalisées d'exécution.
Chaque RP de l'équipe est responsable de sa «partie» du projet, en prenant le contrôle de toutes les tâches en cours pour un certain nombre de produits (idéalement, ces domaines devraient être liés). Ses responsabilités incluent le calendrier et la qualité de toutes les tâches dans le cadre du développement de produits responsables.
Le schéma est facilement évolutif et a un seuil d'entrée relativement bas, car lors de la connexion d'un nouveau RP, il n'a pas besoin de couvrir simultanément toute la base de connaissances du projet, il suffit de comprendre le principe de fonctionnement de "vos" produits.
Il est important que chaque RP soit non seulement responsable du processus de production, mais également bien versé dans la logique métier de ses produits. Grâce à cela, toutes les décisions de gestion sont non seulement correctes du point de vue de la gestion de projet, mais également utiles pour les entreprises et vérifiées architecturalement.
Dans certains cas, le rôle de l'administrateur de projet doit être distingué séparément - cet employé ne se plonge pas dans la composante produit ou le processus de production, mais participe à la préparation des rapports, est responsable de la gestion des documents et joue également le rôle de «première ligne», assurant la continuité de la communication et des réponses rapides à toutes les demandes des clients et partenaires .
Dans le même temps, toute l'équipe de gestion a inclus la motivation collective, liée à la gestion des attentes des clients, en premier lieu - entrer dans les délais du projet.
- 10 jours ouvrables avant le début du mois, chaque RP alloue lui-même de trois à cinq de ses tâches clés pour le mois suivant.
- 5 jours ouvrables avant le début du mois, GH en sélectionne deux ou quatre pour chaque manager et fixe les délais: 1 - terme client (50%), 2 - terme interne (100%) et le saisir dans le tableau.
Conditions bonus (selon les résultats du mois):
- Le manager reçoit 100% de bonus si toutes ses tâches sont achevées dans le délai interne.
- Le manager reçoit 50% de bonus si au moins une de ses tâches a quitté le mandat interne, mais a été achevée dans le mandat du client.
- Aucun des managers ne reçoit de bonus si au moins une tâche de la liste générale n'a pas été réalisée dans le temps du client.
Ce schéma permet à toute l'équipe de direction de travailler efficacement et de gérer correctement les attentes des clients.
Tester non seulement le code final - Commande QA
Au fur et à mesure que le projet se développe, une solide base de connaissances s'accumule, le nombre de nuances et de fonctionnalités augmente, les relations logiques deviennent plus complexes et diversifiées. À un moment donné, ces facteurs commencent à exercer une telle influence que le débogage pré-version prend du temps proportionné au développement et prend la même quantité de ressources.
Pour éviter cette situation, nous avons eu l'idée de créer une équipe QA à part entière basée sur l'équipe de test. La principale différence est que les tests sont effectués non seulement au stade du développement-débogage-libération, mais à toutes les étapes du projet:
- Les AQ sont responsables de la qualité du produit et de sa conformité stylistique et logique avec les autres produits et sont généralement acceptés dans les règles du projet.
- Le contrôle qualité examine tous les artefacts qui apparaissent sur le projet: la formalisation initiale de la tâche, les prototypes, les spécifications, la conception et, bien sûr, testent le code et la mise en page, écrivent des cas de test, couvrent les fonctionnalités existantes et nouvelles avec une grille d'autotests.
- Sans la validation des matériaux par l'équipe QA, le RP n'a pas le droit de lancer la prochaine étape ou d'envoyer des matériaux pour acceptation au client.
Une telle approche peut réduire considérablement les risques de débogage prolongé et de retarder les dates de publication.
Timlids - efficacité ou interchangeabilité?
Dès que le deuxième chef d'équipe est présenté au projet, la question surgit immédiatement - quel schéma de répartition des responsabilités doit être appliqué?
Il existe plusieurs options: soit diviser le projet par type d'activité, c'est-à-dire que l'équipe A se concentre sur l'architecture, la révision du code et la formalisation technique des tâches, tandis que l'équipe B gère les équipes de développement et publie les builds, est responsable de la continuité et de la sécurité. La deuxième option est une ventilation des produits, dans laquelle chaque chef d'équipe est entièrement responsable de son ensemble de produits au sein du projet.
Les deux options sont bonnes en termes d'utilisation des ressources, mais comportent de grands risques en termes d'interchangeabilité.
Par exemple, que dois-je faire si l'un des chefs d'équipe tombe malade, part en vacances ou quitte? Il sera difficile d'inclure un nouveau chef d'équipe dans le processus, car la période d'immersion dans ce rôle est extrêmement longue.
Par conséquent, il est utile d'utiliser un schéma hybride sur le projet, dans lequel chaque chef d'équipe est engagé dans ses propres tâches, mais il existe un certain nombre d'activités dans lesquelles tous ou au moins deux chefs d'équipe sont consacrés.
Ces activités incluent les activités les plus à risque, par exemple: l'architecture de projet, la continuité, la sécurité, les produits clés qui représentent les ventes les plus actives et dont les performances sont spécifiées dans le SLA.
Bien entendu, ce régime réduit la productivité du travail, mais élimine la plupart des risques. Il est nécessaire de trouver un équilibre entre efficacité et interchangeabilité, décrivant une liste des moments les plus cruciaux.
Séparément, il est logique de connecter les chefs d'équipe à des activités aliénées: un produit qui est architecturalement séparé de la partie principale du projet, ou une activité qui peut être engagée en parallèle. Par exemple, il est tout à fait possible de distinguer une disposition de chef d'équipe qui prendra complètement le contrôle de toutes les opérations de première ligne; séparément, les rôles de chef d'équipe AQ, conception, analyse.
Interchangeabilité des membres de l'équipe
Plus il y a de personnes impliquées dans le projet, plus vous devez utiliser activement des outils pour abaisser le seuil d'entrée pour les nouveaux employés, cela simplifie également l'interchangeabilité des membres de l'équipe existants et réduit le facteur de bus.
Voici un certain nombre d'outils qui fonctionnent bien sur presque tous les projets.
Système de conceptionLe système de conception est un kit de conception complet et à jour et une bibliothèque de composants dans le référentiel. Il reflète l'ensemble complet des éléments standard du projet et vous permet de collecter de nouvelles pages à partir de ces blocs. Le système de conception contient non seulement un ensemble d'éléments, mais décrit également leur interaction et contient également des exemples de code.
L'utilisation d'un système de conception peut grandement simplifier la compréhension d'un nouvel employé, qu'il soit gestionnaire, concepteur ou programmeur, des règles visuelles du projet, et appliquer des solutions existantes au lieu d'en inventer constamment de nouvelles.
L'utilisation de tels outils nécessite une dépense importante de ressources pour le développement et le soutien. De plus, il faut souvent beaucoup d'efforts moraux pour expliquer au client pourquoi il est nécessaire d'adhérer à ce système et pour quelle raison des propositions comme «Ajouter un nouveau bouton vert sur cette page, comme sur le site N, qui est si beau» seront rejetées.
La documentationPlus le projet est grand, plus chaque produit et chaque fonctionnalité doivent être documentés avec soin, sinon, les experts consacreront de plus en plus de temps au débogage et à la détermination du fonctionnement de l'une ou l'autre fonction.
La documentation du projet est judicieuse de se diviser en 4 types:
- Spécifications d'interface - une description du comportement de la fonctionnalité implémentée (logique de travail, validation sur le terrain, ensemble d'écrans).
- Des cas de test (description des scénarios utilisateurs et résultats de leur passage), basés sur eux, si nécessaire, des autotests sont développés.
- Spécifications du service (description de l'interaction avec les services Web, données de test, exemples de demande-réponse).
- Documentation du code (description des composants, des classes et de leur hiérarchie, modèles).
Toute la documentation doit être regroupée dans une base de connaissances en ligne (Wiki) et maintenue à jour.
GitPour accélérer la connexion de nouveaux développeurs d'autres projets de l'entreprise, une approche standard de GitFlow est en cours d'introduction. Chez AGIMA, nous utilisons l'approche «travailler avec deux branches principales».
Au lieu d'utiliser la branche principale, deux branches principales de l'historique du projet sont utilisées: master pour les versions et develop pour fusionner les fonctionnalités développées à partir des branches de fonctionnalité.
WorkflowUn autre outil qui régule et standardise le travail de tous les membres de l'équipe est le flux de travail par jour de la semaine.
Chaque semaine est un cycle de production standard: les sorties se font strictement les mardis et jeudis; Mercredi - jour des évaluations; La rétrospective et la planification des nouveaux envois ont lieu en fin de semaine - jeudi et vendredi. Il s'agit d'un exemple de flux de travail d'un des projets, pour chaque cas spécifique, une approche doit être développée.
Le client doit également être impliqué dans le workflow - un tel système ne peut pas fonctionner unilatéralement.
Le workflow sur les statuts de tâches n'est pas moins important, ce qui simplifie la transition des employés entre les projets. Il doit être identique sur tous les projets de l'entreprise. Dans AGIMA, cela ressemble à ceci:
Tenir les membres de l'équipe informés
Même si la documentation est parfaitement organisée sur le projet et que tous les processus fonctionnent comme sur des roulettes, il est impossible de prévoir tous les risques liés au manque de sensibilisation de chaque artiste en particulier. Pour cela, des événements réguliers de différents formats sont organisés.
1. Réunions produitsLors de telles réunions, des employés plus expérimentés parlent à l'équipe de produits spécifiques. Les aspects de la logique métier, de la mise en œuvre technique et de l'architecture sont mis en évidence. La sensibilisation de chaque collaborateur aux principales nuances des produits permet de proposer des idées utiles et de prendre les bonnes décisions à toutes les étapes de la mise en œuvre.
2. Sections d'infrastructureLe projet connaît une croissance dynamique, ce qui implique le développement et l'expansion constants des infrastructures. Dans les sections régulières, les problèmes actuels et les tâches de développement des infrastructures sont discutés et les progrès de la mise en œuvre de chacun d'entre eux sont discutés.
3. Rétrospectives et planification du travailIl est nécessaire de tenir des réunions hebdomadaires pour discuter des tâches mises en œuvre au cours de la semaine écoulée, mettre en évidence les erreurs et planifier les travaux pour la prochaine période comptable.
Conclusions
Une application réfléchie de tous les outils et approches ci-dessus aidera à créer une équipe cohérente et résiliente qui s'adaptera facilement à la croissance future du projet.
Sans aucun doute, l'organisation d'un tel système comporte un certain nombre de difficultés et nécessite à la fois des compétences approfondies au sein de l'agence et la volonté du client d'investir dans de telles décisions, ce qui peut être difficile sur notre marché en développement, mais ces efforts sont payants et conduisent à une coopération à long terme et fructueuse et permettent l'émission. le marché est vraiment des produits de qualité.