Développement de logiciels - Projet, 1 programmeur - Et si vous êtes touché par un bus?

La société pour laquelle je travaille actuellement me développe un tas de logiciels internes critiques. J'ai une autre personne qui travaille pour moi, mais c'est plus un gars de test et pas vraiment un développeur. L'entreprise est préoccupée par certains de ces projets et ce qui se passe si je suis heurté par un bus. Comment l'entreprise reprend-elle après quelque chose comme ça quand il n'y a qu'une seule personne qui connaît la base de code. Une personne qui connaît l'état actuel du projet.

J'ai expliqué qu'avec ma documentation et avec la documentation dans le code, ils n'auraient vraiment besoin que d'embaucher un autre programmeur qui comprend les langues utilisées et qu'ils pourraient être mis à jour assez rapidement.

Ils ont suggéré une entreprise extérieure qui pourrait être "tenue à jour" sur une base mensuelle et qui pourrait "prendre le relais" en cas de problème. Je ne vois pas comment cela pourrait être utile au-delà de payer quelqu'un pour le plaisir de le payer. Pire, j'envisage de perdre une journée par mois à discuter du projet avec cette société de conseil. Je vois comment cela pourrait être utile, mais je ne pense pas que cela soit plus utile que d'embaucher un programmeur après ma disparition prématurée.

Pensées? Situation similaire et comment est-elle actuellement gérée là où vous travaillez?

Malheureusement, ce qu'ils font, c'est «mettre tous leurs œufs dans le même panier».

Travailler avec une entreprise extérieure est très susceptible de générer des revenus pour eux, mais je doute fortement que cela en vaille la peine. La documentation est toujours belle et claire lorsque vous la rédigez. Le problème est que vous ne savez combien cela vaut que lorsque quelqu'un d'autre essaie de le lire - quelqu'un qui connaît à peine quelque chose (technique) sur le (intérieur du) projet.

Quoi qu'il en soit, la lecture d'une base de code complète dont vous ne savez rien est possible, cela pourrait prendre beaucoup de temps (bien au-delà de ce que la plupart des entreprises peuvent se permettre).

Leur meilleur pari honnête est d'embaucher quelqu'un pour travailler avec vous (strictement pas sous l' un de vos conseils) pendant une certaine période de temps, et de tester combien de temps il lui faut pour arriver à un point où il peut comprendre et changer des parties importantes de le projet.

Si cela prend plus de temps qu'ils ne pourraient vous le permettre si vous partiez, alors ils devraient sérieusement envisager d'embaucher un ou plusieurs programmeurs permanents (à temps plein ou à temps partiel), et ne jamais les laisser prendre le même bus. :)

Quoi qu'il en soit, les bons programmeurs qui partent soudainement aggravent toujours les choses.

J'espère que vous ne serez pas renversé par un bus! Vous avez raison, je ne vois pas l'intérêt de faire cela. Tout d'abord, l'autre entreprise facturera un montant plus proche d'un développeur à temps plein et critiquera les choses et vous ralentira. Ils peuvent vous demander trop de livrables et d'explications. De plus, il n'y a aucune garantie réelle qu'ils seront en mesure de les récupérer, car vous n'aurez aucune chance de les tester avant qu'ils ne soient requis.

Je suggère plutôt que l'entreprise investisse dans un autre développeur. Ce développeur ne doit pas nécessairement être à votre niveau d'expertise, mais le temps passé avec lui serait un investissement pour le projet. Vous aurez plusieurs occasions de tester sa compréhension, car il travaillera avec vous sur le terrain.

Assurez-vous de ne pas conduire la même voiture lorsque vous allez déjeuner :)

Une solution qui aurait réellement de la valeur serait de vous embaucher un mentor. Il s'agit d'un service que je fournis aux éditeurs de logiciels locaux. Je visite une demi-journée par semaine ou une journée par semaine. Chaque visite apporte une valeur immédiate, comme s'assurer que les développeurs utilisent les meilleures pratiques, leur enseigner de nouvelles choses dont ils ont besoin d'apprendre, leur donner une chance d'être exposés à de nouvelles choses car ils sont généralement occupés à coder et ne vont pas aux lancements et aux comme résoudre leurs bugs et barrages routiers immédiats, expliquer des choses qu’ils ne savent pas faire, etc. Parfois, je gère des tâches de codage, en particulier pour les travaux ponctuels où le personnel aurait besoin d'apprendre beaucoup pour faire la tâche, puis n'aurait plus besoin de le faire à nouveau. Je peux également gérer des projets, comme rédiger un plan de reprise après sinistre - il a besoin des réponses des développeurs et de la direction

Un tel arrangement est probablement moins cher que ce que votre patron suggère et a de la valeur pour vous. Cela a pour effet secondaire que le mentor apprendra votre système et pourrait probablement former votre remplaçant si vous étiez frappé par une loterie .

ISO 9001 dans ce domaine consiste à se faire frapper par un scénario de bus . L'obtention des services de cette entreprise permettra-t-elle à votre entreprise de se qualifier pour cette certification? Cela peut être une question intéressante à leur poser.

Ou de les faire tourner en rond à la recherche d'une réponse. (cela semblerait probablement très similaire à "non")

Je suis d'accord avec l'OP. L'embauche d'un autre développeur est préférable. Si la base de connaissances se trouve dans une autre entreprise sur laquelle ils n'ont aucun contrôle, la situation est tout aussi risquée.

Pour moi, il semble qu'ils veulent vous remplacer par une main-d'œuvre offshore, où les gens peuvent survivre avec 10 $ par mois.

Ils ont besoin d'un développeur supplémentaire. C'est vraiment aussi simple que cela. Vous devriez tous les deux travailler sur l'ensemble de la base de code. Ou au moins être suffisamment familier avec le travail de chacun pour intervenir pour résoudre les problèmes en cas d'urgence. Si les budgets sont serrés, vous pourriez en théorie même embaucher un minuteur partiel - ce serait probablement suffisant. Quelqu'un qui pourrait consacrer quelques heures chaque semaine à apprendre le code en effectuant la maintenance et les correctifs. Cela les familiariserait suffisamment.

Vous embauchez une entreprise extérieure? Je suis avec vous là-bas - ils pourraient aussi bien jeter cet argent dans les toilettes. Le fait qu'ils envisagent d'embaucher une entreprise externe pour apprendre votre système me dit qu'ils ne sont pas réellement concernés par le scénario du bus (car, comme indiqué, la solution est évidente) et ont juste besoin d'une raison pour lancer la phrase à la mode `` frappé par un bus 'tout en jouant au golf avec leurs collègues managers, ou ... qu'ils cherchent à externaliser votre travail. Après tout, si une entreprise externe peut apprendre l'intégralité de votre base de code à un prix inférieur à celui d'un employé, à un moment donné, les personnes aux cheveux pointus demanderont alors pourquoi ont-elles besoin de vous?

Il est plus courant que vous ne le pensez pour les entreprises d'avoir un plan en place si un employé critique est heurté par un bus.

Habituellement, il associe le talent clé à une personne interne (qui n'est pas autorisée à voyager sur les mêmes vols ... ou les bus) pour empêcher que les avantages et les idées concurrentiels ne fuient à l'extérieur de la compétition.

Premièrement, la personne qui teste votre code ne devrait pas travailler «sous» vous; c'est un conflit d'intérêts.

En votre absence, ils doivent évaluer le risque de retard dans les domaines du débogage et de l'ajout de nouvelles fonctionnalités. Ils peuvent permettre à quelqu'un de devenir rapidement un débogueur, à moins que vous n'ayez écrit un mauvais code. Habituellement, l'ajout de nouvelles fonctionnalités peut attendre jusqu'à ce qu'un nouveau programmeur soit prêt. Ce n'est pas toujours le cas lorsqu'il y a des promesses faites à des clients existants ou sur un marché où vous essayez de suivre la concurrence.

J'ai travaillé dans une entreprise dont j'étais le seul développeur. Ils ne m'ont pas remplacé par un autre programmeur, mais ont radicalement changé de direction et se sont installés pour une application tierce. Des décisions d'affaires plus étranges ont été prises. Cela les empêche de se séparer radicalement de la concurrence et d'avoir un énorme levier pour développer leur entreprise. Peut-être que ce n'était plus leur objectif?

En fait, il existe un terme appelé numéro de bus du projet. Si le numéro de bus est un, vous avez un gros problème. Aux États-Unis, la FEMA demande aux entreprises d'être mieux préparées aux catastrophes.

Ce n'est pas seulement la perte d'un développeur clé. C'est l'impact d'une catastrophe naturelle ou le manque de sauvegardes hors site. Il y a beaucoup de questions sur ce site demandant s'ils ont besoin d'utiliser le contrôle de code source en tant que développeur solo. La possibilité pour un nouveau développeur d'extraire la version la plus récente du logiciel et de voir quelles pièces sont nouvelles les aidera.

Il y a plus d'informations sur PS-Prep sur http://www.fema.gov/privatesector/preparedness et http://readyrating.org/ .

Je connais ta douleur. L'entreprise pour laquelle je travaille compte plus de 20 développeurs et tout le monde a ses connaissances.

Les bits qui se chevauchent sont vraiment ... des bits, donc si quelqu'un disparaît (vacances, maladie, etc.) et que quelque chose arrive aux outils qu'ils gèrent, vous êtes foutu.

Le problème est qu'ils connaissent la situation et ne s'en soucient pas beaucoup, peut-être qu'ils ne se sont pas encore frappés la tête.

J'aime la citation qui dit quelque chose comme "Les cimetières sont pleins de gens auparavant considérés comme indispensables". Cela dit, votre entreprise a le devoir de minimiser les risques, actuellement vous êtes perçu comme tel. J'y suis allé à l'occasion, il est préférable non seulement de ne pas résister, mais de faire un effort supplémentaire. Ne vous contentez pas de former une entreprise externe, recommandez la meilleure entreprise de la ville, c'est-à-dire celles en lesquelles vous auriez le plus confiance. Pensez également, si vous faites un travail mieux que quiconque, vous êtes irremplaçable par définition.