L'une des tâches principales de mon assiette est de communiquer avec le client. Une chose que je trouve particulièrement difficile est de traiter les délais car ils sont mandatés par le client et je ne suis souvent pas consulté.
Si vous êtes censé être responsable de la communication avec le client, pourquoi n'êtes-vous pas consulté sur la planification (et la budgétisation) afin de pouvoir communiquer ces informations entre les personnes responsables au sein de votre organisation et leurs homologues du côté du client? Je pense que la résolution de ce problème sera un énorme avantage pour vous, votre équipe et votre projet.
Le client propose une fonctionnalité qu'il souhaite ajouter, la fonctionnalité X. La fonctionnalité X aurait fière allure dans la version d'application de la semaine prochaine, dans environ 6 jours ouvrables. À ce stade, la demande de fonctionnalité doit passer par l'approbation et il existe fréquemment d'autres dépendances qui doivent être traitées. Finalement, N jours plus tard, la demande de fonctionnalité parvient à mon équipe. Même si la date limite d'origine (qui a été définie par un gestionnaire non développeur) était réalisable, elle ne l'est plus.
Ce système de planification semble pour le moins étrange.
D'après mes expériences, le client signe pour une version particulière. Ils peuvent soumettre une liste des fonctionnalités et des modifications qu'ils souhaitent et quand ils les souhaitent, puis négocier avec l'équipe qui élabore le logiciel. Ou ils peuvent donner une liste prioritaire de fonctionnalités à l'équipe de développement, et l'équipe de développement fournit des estimations quant au moment où ils peuvent expédier divers ensembles de fonctionnalités. Il existe également d'autres variantes.
Mais une chose que je n'ai jamais vue autorisée est qu'un client puisse changer la version si tard dans le jeu, surtout pas à une semaine d'une version. Cela ne semble pas juste de mettre les concepteurs, les développeurs et les testeurs sous ce genre de pression. Si vous effectuez un développement itératif, s'il s'agit d'une fonctionnalité de haute priorité, assurez-vous simplement de l'ajouter au formulaire de backlog et de le prendre dès que vous le pouvez. Si ce n'est pas une fonctionnalité de haute priorité, ils n'en ont certainement pas besoin pendant cette version et peuvent attendre la prochaine.
Je recommanderais de définir des règles de base adaptées à vos équipes de conception, de développement, de test et de livraison ainsi qu'à votre client en ce qui concerne les blocages, les blocages de code et les livraisons. Mettez-les par écrit, obtenez l'engagement de tous et respectez-le. Si vous bougez une fois, vous devrez vous plier davantage et vous perdrez le contrôle du processus.
Malheureusement, je ne peux pas faire grand-chose car je ne suis pas en position de pouvoir ici.
Vous pourriez ne pas être seul. Mais il semble que vos concepteurs et / ou développeurs et / ou testeurs subissent beaucoup de pression pour respecter les horaires. Vous devriez vous asseoir avec vos supérieurs en équipe et expliquer la situation. Tout d'abord, demandez à votre organisation de s'engager à améliorer le processus, puis travaillez avec le client pour obtenir son adhésion à la façon dont les choses vont fonctionner.
Cela ressemble beaucoup à des excuses.
Lorsque vous commencez à trouver des excuses, il est peut-être temps d'avoir une conversation difficile ou une conversation cruciale . Je recommanderais l'un de ces deux livres. Les lire m'a aidé à améliorer mes compétences en communication, surtout lorsque vous devez faire face à une situation difficile où les tensions sont élevées de tous les côtés.
Pour répondre à certaines des autres réponses.
Malheureusement, le pouvoir est principalement pris par vous-même plutôt que par les autres.
Je ne sais pas où va Andrea . Oui, vous devez corriger le flux d'informations. Mais vous devez travailler avec les PM et le client pour vous assurer que tout le monde sait ce qui a été (je suppose, de toute façon) convenu au début du projet. Si l'arrangement, pour une raison quelconque, ne fonctionne pas, revoyez-le et redistribuez le travail et les rôles aux personnes qui leur conviennent le mieux.
Vous ne prenez pas le pouvoir ou ne combattez pas le pouvoir, mais vous travaillez avec, essayant de l'apprivoiser et de le faire fonctionner pour tout le monde.
Le problème est que le client connaît surtout la valeur commerciale de la fonctionnalité, mais ne se rend pas compte de sa complexité. Il suffit de discuter et de clarifier. Toujours.
Cette citation de loki2302 est à peu près exacte . L'un de vos emplois en tant qu'ingénieur logiciel consiste à vous assurer que les bonnes personnes savent à quel point la tâche est difficile, combien de temps cela prendra et quels types d'options et de risques existent pour faire quelque chose. En tant que principal communicateur de votre équipe, la transmission de ces informations de votre organisation à votre client est, en théorie, votre travail.