Quelques questions auxquelles vous devrez être prêt à répondre:

- Qu'avez-vous fait tout ce temps?

Soyez prêt à montrer votre travail et à discuter des obstacles que vous ont été incapables de sauter pour accomplir le travail.

- Qu'avons-nous si nous nous arrêtons maintenant? Est-ce que l'un de ces éléments est récupérable?

Espérons que oui. Si vous avez une partie du système qui fonctionne, montrez-la, car cela peut éliminer une partie de la piqûre.

- Pourquoi n'êtes-vous pas venu me voir plus tôt?

Cette question va être difficile à répondre. En tant que développeur junior, vous avez probablement été aveuglé par l'orgueil. Les estimations de la plupart des projets sont inférieures à leur temps réel d'achèvement. Cela est passé de mois en années, donc quelques grandes explications seront nécessaires.

En fin de compte, votre patron ne sera pas content de cela, mais vous êtes un développeur junior, donc des erreurs sont attendues. Vous devez les avouer beaucoup plus tôt dans le futur. Je ne pense pas que ce soit une infraction licenciable, mais il peut s'agir d'un récit ou d'une sorte d'avertissement verbal. Bonne chance.

En plus de l'excellente réponse de Garrison Neely, je vous conseille de dire que la façon dont vous dites cela est presque aussi importante que le fait que vous le disiez.

Au lieu de quelque chose comme j'ai échoué; Je ne peux pas terminer ce projet , essayez de le cadrer de manière plus positive - quelque chose comme Je frappe un mur et j'ai besoin de l'aide d'une ressource plus expérimentée pour le dépasser. En plus pour vous permettre de potentiellement sauver le succès ici, il sert un double objectif en expliquant pourquoi vous êtes en retard sur le calendrier, ainsi qu'en proposant une solution à ce problème même.

J'appuie tous ceux qui vous disent que vous devez en informer votre patron dès que possible.

• Donnez un rapport de situation sans fioritures sur le projet, mais ne dites pas simplement que vous avez échoué s > - une évaluation aussi succincte vous collerait comme une encre noire indélébile sur une chemise blanche.
• Commencez votre rapport d’état en disant que le projet est en retard sur le calendrier que vous aviez établi, puis passez en revue les parties qui se sont bien déroulées et celles qui ne se sont pas bien déroulées.
• Ne vous contentez pas de passer en revue les parties qui n'ont pas bien marché, car si vous le faites, vous donnerez aux gens une perception déformée de vos capacités et de vos efforts. Laissez-les déterminer ce qu'ils veulent faire ensuite.
• Enfin, supprimez le bénévolat pour quoi que ce soit pendant un certain temps.

Comme vous êtes un développeur junior, traitez cela comme une opportunité d'apprentissage. L'une des choses qu'un junior n'est généralement pas censé être capable de faire est de superviser la portée et les conséquences d'un grand projet comme celui que vous êtes

Le meilleur plan d'action maintenant est de planifier une réunion avec votre superviseur direct et de lui avouer que vous êtes au-dessus de votre tête avec votre projet et que vous souhaitez des conseils sur la façon de procéder Vous pouvez vous attendre à des questions difficiles, comme celles de la réponse de @GarrisonNeely, mais le plus important pour y répondre est de dire la vérité et de ne pas essayer de rendre les choses plus belles qu'elles ne le sont. .

Si vous avez un bon manager, admettre que vous êtes au-dessus de votre tête en tant que développeur junior n'est pas nécessairement une mauvaise chose. Il est possible que votre responsable savait déjà que vous ne seriez pas en mesure de terminer le projet avant la nouvelle date limite et attend que vous surmontiez votre fierté et admettez vous-même l'échec. J'apprécierais cela plus que d'avoir à tirer de force quelqu'un de sa tâche car il est devenu évident qu'il ne peut pas (encore) le gérer.

Quant à l'avenir du projet, il peut aller dans plusieurs

• Il peut être complètement supprimé, surtout si le projet n'était pas si important pour l'organisation au départ
• Il peut être réaffecté à quelqu'un d'autre, avec vous obtenez un travail qui correspond mieux à vos capacités actuelles
• Vous pouvez affecter des développeurs supplémentaires plus expérimentés au projet pour vous aider.

Si vous prévoyez de renflouer, présentez les raisons pour lesquelles vous devez le faire. Si votre plan va aussi loin, vous devez avoir des arguments solides. Dans ce cas, préparez un plan de projet pour les six prochains mois de travail, disons, et prouvez qu'aucun de ces travaux n'était prévu lorsque vous avez commencé. Donnez autant d'informations que possible. Indiquez pourquoi cela fait plus d'un an et quels travaux supplémentaires / inattendus ont été réalisés à ce jour.

Une fois que vous avez un aperçu de vos performances passées, ainsi que de vos attentes futures envers vous-même, vous pouvez présenter ceci à un responsable avec quelque chose comme "D'après mes observations, cela prend plus de temps que prévu. Voici mes conclusions. Pour cette raison et cette raison (mettez de solides arguments ici), cela peut même prendre plus de temps. Dois-je continuer à travailler sur ce projet? " Avec cela, vous dites effectivement: "Oui, cela prend plus de temps que prévu, mais je sais en quelque sorte où je vais et où je me suis trompé dans le passé, mais je vous laisse aussi, le manager décider du résultat". Les gestionnaires aiment décider, donc vous obtenez un +1 ici tout de suite.

Pour les projets futurs (je suppose que vous n'allez pas abandonner le travail de développement simplement parce que vous avez échoué une fois), ne prenez jamais quelque chose que vous percevez comme compliqué. Il y a de fortes chances que vous ne le terminiez jamais (comme celui-ci), ou que cela prendra plus de temps que prévu et que les avantages n'en valent pas la peine (du point de vue de la direction).

Au lieu de cela, prenez le travail que vous trouvez super simple (et réalisable en moins d'une journée). Cela finira souvent par s'étirer de 4 à 5 jours, vous apprendrez donc à estimer, mais l'entreprise ne perdra pas autant d'argent sur vous. Échouez rapidement et souvent. N'oubliez pas que vous apprenez de vos erreurs, pas de vos succès.

S'il n'y a pas de petit travail, essayez de diviser le travail que vous avez en petits morceaux autonomes, c'est-à-dire que chacun doit avoir une valeur et être autonome. Vous devez estimer votre travail avant de le démarrer. C'est à dire. jamais quelque chose comme "eh bien, c'est une tâche de recherche, donc ça va prendre 2 semaines, peut-être un mois ..." Connaissez le domaine, sachez que les questions vont être résolues.

Si vous ne le faites pas sachez exactement ce que vous recherchez, ne vous engagez pas sur un calendrier, dites "j'ai besoin d'un jour pour construire un plan de projet pour mes recherches, je vais alors fournir une estimation". Utilisez ce temps pour avoir une meilleure compréhension de votre problème.

Si vous ne pouvez pas faire une estimation sur une tâche, vous ne savez pas ce que vous faites. Ne commencez pas une tâche, si tel est le cas. Obtenez plus d'informations, jusqu'à ce que vous soyez absolument sûr que cela prendra X jours. Parfois, il est utile d'utiliser vos expériences passées, c'est-à-dire "cela devrait prendre 1 jour, mais une tâche similaire il y a 3 mois a pris 5 jours, peut-être que je manque quelque chose ..."

Il semble que vous incluez certaines évaluations que vous n'êtes pas qualifié pour faire, comme «[le cadre] est bien au-dessus de ma capacité à comprendre» et «je ne devrais plus être le développeur du projet». Ces évaluations nécessiteront que votre patron fasse des recherches supplémentaires pour savoir ce qui s'est réellement passé, ce qui aurait dû se passer et ce qui devrait être fait maintenant.

Plutôt que de vous concentrer sur de telles évaluations, votre objectif devrait être de fournir votre patron avec des détails factuels spécifiques sur le projet, y compris les limites spécifiques de votre compréhension. Par exemple, "J'ai travaillé pendant 3 mois sur la réécriture du composant de connexion. À ce moment-là, il était censé s'interfacer avec LDAP, et ce n'est toujours pas le cas. Il suit avec état les tentatives de connexion. Comme je ne comprends pas le protocole de hachage LDAP , Je ne sais pas si le code que j'ai écrit peut être ajusté pour s'interfacer avec LDAP, ou s'il nécessite une approche totalement différente. ... "