Le vieux programmeur a disparu. Sur le point d'embaucher un autre programmeur. Comment puis-je aborder cela? [fermé]

Après avoir passé plus d'un an à travailler sur un projet de réseau social pour moi en utilisant WordPress et BuddyPress , mon programmeur a disparu, même s'il était payé chaque semaine, pour toute la période. Oui, il n'est pas mort car j'ai utilisé un outil de suivi des e-mails pour confirmer et voir qu'il ouvre mes e-mails, mais il ne répond pas. Il semble qu'il ait obtenu un autre emploi. Je me demande pourquoi il ne pouvait tout simplement pas le dire. Et je lui ai même payé un salaire d'avance pour le travail qu'il n'a pas fait.

Le problème est que je n'ai jamais demandé de documentation complète pour la plupart des fonctions qu'il a codées. Et il y avait BEAUCOUP de fonctions pour cette période d'un an et plus, et certaines d'entre elles ont des bugs qu'il n'a toujours pas corrigés. Maintenant, tout semble déroutant.

Quelle est la première chose que je dois faire maintenant? Comment dois-je procéder?

Je suppose que la première chose à faire sera d'obtenir un autre programmeur, mais je veux commencer du bon pied en faisant documenter tout le code actuel afin que tout programmeur puisse travailler sur toutes les fonctions sans problèmes.

Est-ce la première chose que je dois faire? Si oui, comment dois-je procéder?

Quel est le type de documentation standard requis pour quelque chose comme ça? Puis-je obtenir un programmeur qui fera juste la documentation de tous les codes et corrigera les bogues ou la documentation n'est-elle pas vraiment importante?

Aussi, pensez-vous qu'il est préférable d'avoir un autre programmeur "individuel" ou de faire travailler une entreprise avec des programmeurs pour que, si le programmeur affecté à mon projet disparaisse, un autre puisse le remplacer, sans ma participation? Je pense que c'est l'approche que j'aurais dû adopter au début.

Sur la base de cette interaction que nous avons eue dans les commentaires, je partirai de l'hypothèse que vous n'avez pas chassé votre seul développeur à cause de choses personnelles. Cependant, sur la base de cette conversation, je vais faire une autre supposition que ce revers est toujours principalement de votre responsabilité en tant que gestionnaire d'embauche. Comme vous l'avez mentionné, vous n'avez AUCUNE expérience avec les développeurs, mais comment décidez-vous comment en embaucher un?

On dirait que vous avez fait de votre mieux, mais vous avez embauché quelqu'un qui ne pouvait tout simplement pas gérer l'ampleur de ce projet, il a construit une fondation fragile qui s'est effondrée sous lui, puis il est simplement parti. Malheureusement, la différence entre les développeurs et les entrepreneurs est que les premiers sont payés à l'heure / salaire, mais ils peuvent choisir d'aller et venir à leur guise. Il a été payé pour les heures travaillées et il est parti quand il a choisi de ne plus être payé. Vous ne pouvez rien y faire.

Et maintenant? Il semble que vous ayez commencé à remplacer les gens par des processus. Si seulement vous aviez suffisamment de documents, les gens pourraient partir et d'autres pourraient reprendre là où ils se sont arrêtés. OMI qui ne fonctionne pas et si cela fonctionne, ce sera toujours beaucoup plus cher que d'avoir une équipe fiable d'employés permanents. Au cours des 30 dernières années, la direction de diverses entreprises a tenté de remplacer les personnes par une documentation suffisante (y compris mon dernier emploi) et a échoué à chaque fois. C'est pourquoi j'ai décidé de changer d'emploi et maintenant ils sont coincés avec leurs documents obsolètes et jamais précis, alors que je passe le temps de ma vie dans une nouvelle startup.

Ce que je ferais si vous étiez, ce serait d'essayer de trouver la bonne personne avec suffisamment de compétences et d'expérience pour reprendre ce projet et le mener à terme. Cela comprend non seulement les compétences de codage, mais aussi la conception, l'architecture ainsi que la gestion de base des projets. N'essayez pas de définir comment il fait son travail, ni combien de documents il doit produire. Concentrez-vous simplement sur la recherche de la bonne personne et soyez prêt à payer en conséquence. Lorsque vous le trouvez, assurez-vous que votre rôle est de le soutenir et de supprimer les obstacles sur son chemin, pas de surveiller / microgérer. Je ne veux pas dire que vous l'avez fait auparavant, mais je sais que beaucoup de gestionnaires ont tendance à le faire et c'est tout simplement contre-productif.

Parlez à d'autres entrepreneurs, peut-être à ceux qui ont plus d'expérience en génie logiciel. Lisez ces forums et trouvez une série de questions à poser à votre futur locataire. Présentez le problème et demandez quelle serait l'approche. S'il est le bon gars (et en supposant qu'il n'a pas vu cette page), il devrait être en mesure de suggérer beaucoup de choses que d'autres personnes ont déjà suggérées en termes de ce qui devrait être fait dans votre entreprise lorsque vous commencez à récupérer. Demandez-lui de définir un plan à partir du moment où il est embauché jusqu'au moment où votre v1.0 sera livrée. Comment vous y mènera-t-il? Demandez de l'aide pour interviewer une telle personne.

Juste quelques-unes de mes propres pensées: le suivi des bugs est un must (Jira coûte 10 $ pour une équipe de 10 personnes maximum). Le contrôle des sources est un must (git est gratuit. Forcément coûte des cacahuètes pour une équipe de 5 personnes maximum). Votre code est votre documentation. Pas vos documents écrits. Il devrait revoir le code et conserver ce qui est récupérable; jeter le reste et se concentrer sur l'écriture de code maintenable et lisible. Enregistrez la documentation de quelques documents de conception de haut niveau sur quelques pages. Il doit connaître la technologie sur laquelle vous travaillez. N'embauchez pas quelqu'un avec juste de bonnes intentions; vous ne pouvez pas vous permettre de les faire apprendre à votre rythme. Demandez-leur quels autres projets ils ont réalisés (malheureusement, vous ou quelqu'un que vous trouvez devrez peut-être suivre l'aspect technique des choses). Vous cherchez quelqu'un avec suffisamment d'expérience mais en même temps pas trop que cette étincelle d'excitation a déjà brûlé. Trouvez quelqu'un qui a faim pour avoir un impact. La méthodologie qu'il propose ou suit devrait vous permettre de voir le travail sur une base régulière (périodes d'une ou deux semaines) et de fournir un feedback instantané. N'embauchez personne qui dit, il sera prêt dans 7,4 mois exactement, je vous ferai savoir quand c'est fait.

Bonne chance

C'est une situation étrange, et je suis sûr que vous ne racontez pas toute l'histoire. J'ai travaillé avec beaucoup de gens, dont certains sont partis pour diverses raisons (moi étant leur collègue), mais n'essayez pas de nous dire que tout était super bien et un jour, tout simplement pas de contact.

Mais ce n'est pas un problème. Du moins plus; vous devriez apprendre de votre erreur et essayer de ne pas la répéter à l'avenir. Et oui, je suggère fortement que 50% de votre faute est de son départ.

Maintenant sur la résolution du problème actuel:

1. Essayez de contacter votre programmeur. Il lit votre e-mail - offrez-lui de l'argent pour la documentation / la correction des bugs les plus cruciaux. Personne d'autre ne pourra les réparer plus rapidement que lui. Ça ne marche pas? Essayez de trouver où il travaille, contactez cette entreprise et racontez votre histoire. Une bonne entreprise n'engagera pas une personne qui pourrait faire de même pour elle. Au moins, ils lui diront de terminer la documentation pour vous.

   REMARQUE: vous ne voulez pas que cette personne revienne, vous avez juste besoin d'une documentation terminée

2. Préparez-vous à ce que votre travail d'une année soit nul. Il a peut-être fui lorsque vous avez demandé des résultats et il savait qu'il ne pouvait pas livrer. Il est possible que le code soit plein de hacks, d'implémentation sale et de mauvaise qualité globale. Même s'il revient - il n'aura probablement pas les compétences ni même le temps de bien faire les choses.

3. Cherchez une autre personne. Il a besoin de connaître les mêmes technologies (langage de programmation, frameworks, etc.). Si la qualité du code est bonne - il pourrait continuer, sinon, il pourra le refactoriser. Oui, le refactoring prend du temps sans implémentation de nouvelles fonctionnalités, mais il rend le code maintenable et c'est ce dont vous avez besoin. De plus, une personne qui peut remanier le mauvais code est un très bon programmeur, accrochez-vous.

   REMARQUE: il est stupide de payer de l'argent à l'avance. L'idée même du salaire est de payer pour le travail accompli. Pas pour une promesse faite :)

4. Faites des listes. Il est dans votre intérêt d'avoir un plan. Une spécification technique qui, une fois lue, permettra au nouveau programmeur de comprendre le travail et les jalons. Avoir au moins trois documents importants:

   • Description générale du projet - un document qui permettra même à un non-programmeur de savoir de quoi parle le projet.

   • Chronologie - quelle partie et quand pensez-vous être prêt? Que fait-on déjà?

   • Spécifications techniques - elles sont longues. C'est LE document qu'un programmeur veut lire. Séparez-le en parties logiques et décrivez le plus en détail possible les fonctionnalités et le flux de travail de cette partie spécifique.

Travailler avec des entreprises n'est pas vraiment bon; vos chances ne s'amélioreront pas. Et vous paierez 10 fois trop si vous n'embauchez qu'un seul programmeur. Si vous avez une petite équipe, disons 3-5 personnes, embauchez simplement un programmeur prêt à être chef d'équipe. Il fera un bien meilleur travail de gestion de l'équipe.

Documenter ensuite le code par un autre programmeur? C'est simplement ma propre expérience et mon opinion de vous dire que vous ne devriez pas emprunter cette voie.

Sans une connaissance plus détaillée de la qualité de cette base de code, mon avis est que votre meilleure approche est d'embaucher un nouveau programmeur pour corriger les bogues, maintenir et éventuellement apporter les modifications dont vous avez besoin.

Cette opinion a le point clé des modifications possibles (modification ou ajout), car elles doivent être remplies. Cela signifie qu'une sorte de spécification d'exigence doit être écrite. Ceci est un document.

Ce qui conduit à un point de maintien de l'ensemble du projet. Vous n'avez pas dit dans votre question si les exigences actuelles des programmes ou même une documentation fonctionnelle approximative existent, mais c'est là que vous devriez vous concentrer maintenant.

Dans le cas où vous n'avez aucune documentation du tout, à ce stade, c'est à vous de combler ce vide. Vous ne pouvez pas engager un programmeur pour effectuer une rétro-ingénierie de votre application et façonner miraculeusement la documentation à partir de cela . Vous devez "expliquer" ce que vous voulez que le programme fasse (même si cela signifie ré-expliquer ce qui a déjà été programmé).

Lorsque vous avez écrit ce document (que ce soit sous forme d'exigences ou de spécifications fonctionnelles), vous obtiendrez de bien meilleurs résultats en embauchant un nouveau programmeur, car vous pouvez remettre la documentation et commencer à travailler à partir de là.

Il existe également de nombreux programmes qui produisent des documents à partir du code source, ce qui est un bon moyen de produire un squelette d'explication du code source réel (c'est dans le domaine des spécifications techniques) que vous ne pouvez travailler que dans le contexte de l'explication des aspects techniques de la fonctionnalité spécifiée dans la spécification fonctionnelle, qui spécifie la fonctionnalité des exigences spécifiées dans la spécification des exigences.

Alors oui, mon avis est d'embaucher un programmeur pour corriger les bugs. Après avoir corrigé les bogues qui, selon vous, devraient être corrigés, vous pouvez discuter de l'aspect documentaire comme un autre contrat. Avec de la chance, vous avez embauché un programmeur qui a une certaine expérience et peut contribuer aux étapes à suivre à partir de là.

Voici comment j'aborderais le problème:

• Vous avez la connaissance du domaine. Vous savez maintenant quelles fonctionnalités sont disponibles sur le site Web, lesquelles vous aimeriez ajouter à l'avenir, et vous pouvez probablement répertorier quelques bogues signalés par les utilisateurs également.

• Il y a cette pile de code assise là, laissée à elle-même dans un coin. Il peut être bogué, mais il offre toujours de la valeur car le site a des utilisateurs actifs. Une réécriture complète serait donc une erreur de l'OMI.

Le pont entre votre expertise de domaine et le code a été rompu lorsque le programmeur est parti. Vous devez le reconstruire afin que la base de code puisse à nouveau être synchronisée avec vos besoins et que les futures mises à jour puissent être développées.

Le fait est que ce pont ne peut pas être entièrement constitué de documentation. Le logiciel est autant une affaire humaine que technique. Si vous n'expliquez pas en détail ce que vous attendez du nouveau programmeur, il ou elle aura du mal à déduire cela du seul code - d'autant plus si le programmeur précédent a écrit du code cryptique, mal documenté et mal testé. Et si vous ne travaillez pas en étroite collaboration avec le nouveau programmeur pour trouver un moyen automatisé et continu de vérifier que le code correspond à vos besoins, en d'autres termes pour rendre le pont plus robuste, le problème est voué à se répéter.

• Asseyez-vous régulièrement (même virtuellement) avec le nouveau programmeur pour les sessions de traitement des connaissances du domaine. Au cours de chacune de ces sessions, écrivez ensemble les spécifications d'une petite partie de votre produit. Il peut s'agir d'une seule page Web, d'une fonctionnalité. En leur faisant des spécifications exécutables (à la manière du développement basé sur le comportement ), vous augmenterez votre niveau de confiance dans le fonctionnement du pont, car vous pouvez les exécuter en continu et être averti en cas de problème. Cela facilitera également la vie du développeur.

  Après une session, le développeur est en mesure de retourner à son travail et d'écrire des tests de niveau inférieur qui valident que le code actuel est conforme à la spécification. S'il n'est pas conforme, le programmeur a tout ce dont il a besoin pour le réparer. Il est également important de rester disponible pour toute question qu'il pourrait avoir.

• Essayez de maintenir une collaboration étroite et continue entre vous et les programmeurs sur votre projet, et assurez-vous que cela est également vrai entre eux. Cela est nécessaire si vous souhaitez que la culture fonctionnelle et technique autour de votre projet se perpétue, en évitant les problèmes comme celui que vous rencontrez actuellement. Bien sûr, cela nécessite non seulement 2+ développeurs travaillant sur votre projet, mais aussi qu'ils partagent entre eux les connaissances sur tout ce qu'ils écrivent. Ainsi, on peut agir comme un basculement lorsqu'un autre est porté disparu. Des techniques telles que la programmation de paires et les révisions de code sont de bons moyens d'y parvenir.

En ajoutant simplement à ce que tout le monde a dit,

Si vous ne pouvez pas faire en sorte que l'ancien programmeur documente son code même à un prix, alors ne vous attendez pas à ce que quelqu'un d'autre puisse mieux le documenter. Voici donc quelques options sur ce que vous pouvez faire pour l'instant pour rendre le nouveau programmeur productif dès le premier jour.

1. Obtenez une base de données de bogues et commencez à entrer tous les bogues que vous y avez trouvés. Il s'agit de la liste de tâches prioritaires du programmeur. Documentez-le bien et mettez le plus de détails possible (fichier source / cause racine, ce qu'il fait et ce qu'il doit faire). Il existe de nombreux logiciels gratuits de suivi des bogues, comme Bugzilla , Redmine et JIRA . N'hésitez pas à utiliser celui que vous aimez.
2. Créez une fiche technique pour votre projet. Cela donnera au nouveau programmeur des indications une fois les bogues résolus. Vous pouvez consulter le guide de Joel sur la rédaction des spécifications .
3. Créez un calendrier ou un calendrier pour votre projet. Ils devraient avoir des délais et des jalons dans lesquels ils sont payés pour le travail qu'ils ont rendu plutôt que de les payer à l'avance.

Maintenant que cela n'est plus possible, vous pouvez commencer à chercher un programmeur. Et comme Creative Magic l'a dit, l'externalisation du travail à des entreprises peut conduire à une catastrophe ou faire exploser le prix à l'infini et au-delà.

Cette fois-ci, commencez à planifier correctement le facteur bus lors de l'embauche de programmeurs. Les gens vont et viennent et il n'y a rien que vous puissiez faire à ce sujet, alors préparez-vous au pire cette fois en obtenant deux programmeurs, ou comme Uooo l'a dit, obtenez un programmeur et un testeur.

Maintenant, une fois que les programmeurs sont dans la boutique avec vous, vous pouvez commencer à leur demander de documenter leur code à l'avenir plutôt que de leur demander de documenter l'ancien code, vraiment, oubliez cela.

Autres éléments à considérer lors de l'acquisition d'un nouveau programmeur, assurez-vous qu'il connaît le contrôle des sources et les tests automatisés. Aussi, essayez d'obtenir autant de contrôles sur le test Joel que possible avec leur aide, vous ne pouvez le faire que par vous-même.

Donc, votre seul programmeur a été touché par un bus , et vous devez le remplacer maintenant.

Vous pourriez essayer de poursuivre votre ancien programmeur, sur la base de votre contrat, ou découvrir ce qui ne va pas avec lui. En supposant qu'il ne reviendra pas, cela ne vous aidera pas.

• Vous voulez que votre produit soit fait, alors recherchez un programmeur qui a de l'expérience dans la maintenance et le développement de systèmes existants. Je ne me concentrerais pas à dire à votre programmeur quoi faire dans quel ordre. Assurez-vous d'embaucher un professionnel qui rédige la documentation et les tests unitaires chaque fois que nécessaire.
• De votre côté, vous pouvez vous assurer que le nouveau programmeur a tout ce dont il a besoin pour son travail : spécifications des exigences, machine puissante et ainsi de suite. Vous voulez un programmeur professionnel, alors offrez-lui un environnement de travail professionnel.

Pensez également à embaucher un deuxième développeur pour faciliter ce genre de situations difficiles à l'avenir. Un testeur serait également utile pour l'assurance qualité.