Comment dois-je décrire le processus d'apprentissage du code de quelqu'un d'autre? (Dans une situation de facturation.) [Fermé]

Edit: Justin Cave a fait un bon point que ce type de communication devrait être au premier plan dans mes citations / estimations. Dans ce cas, je suis toujours intéressé de savoir quel type de langage les gens utilisent pour décrire les activités «d'apprentissage de code existantes». Surtout pour une entreprise qui n'a jamais eu affaire à des sous-traitants de logiciels auparavant. Fin de la modification

J'ai un contrat pour mettre à niveau certains logiciels internes pour une grande entreprise. La société a demandé plusieurs ajouts de fonctionnalités et quelques corrections de bugs. Ceci est mon premier travail de style indépendant.

Tout d'abord, je devais me familiariser avec le fonctionnement de l'application - je l'ai apprise comme si j'étais un utilisateur.

Ensuite, j'ai dû apprendre comment fonctionnait le logiciel. J'ai commencé avec des concepts généraux, puis je me suis rétréci dans les détails nécessaires avant de travailler sur chaque correction de bogue et fonctionnalité.

Au moins au début du projet, il m'a fallu beaucoup plus de temps pour apprendre le code existant que pour écrire les fonctionnalités supplémentaires.

Comment puis-je décrire le processus d'apprentissage du code existant sur la facture? (Cette partie de l'entreprise fait généralement des choses en interne, donc elle n'a pas beaucoup d'expérience avec des sous-traitants comme moi, et je crains qu'ils ne comprennent pas les frais généraux liés à l'apprentissage du code de quelqu'un d'autre). Je ne veux pas simplement attacher le temps d'apprentissage à la mise à niveau réelle des fonctionnalités, car dans certains cas, cela donnerait l'impression d'une `` tâche simple '' que cela m'a pris beaucoup trop de temps. Je souhaite décomposer la facture en étapes pertinentes et communiquer que je facture les frais généraux importants liés à l'apprentissage du code de quelqu'un d'autre avant de pouvoir y ajouter le mien.

Existe-t-il une manière standard de décrire ce type d'activité lors de la facturation d'un emploi?

Je facturerais des tâches telles que "Revoir les fonctionnalités existantes" et / ou "Revoir le code existant". En fonction de la complexité des nouvelles fonctionnalités, j'ajouterais une tâche "Conception xxx" qui inclurait le temps que je passe à déterminer les points d'intégration dans le code existant.

Je pense que c'est une bonne idée de faire comprendre au client qu'il y a des frais généraux pour amener un nouveau consultant à jour - et que, s'il est satisfait du résultat, continuer à travailler avec le même consultant les sauvera probablement argent.

Diagnostic des problèmes.

C'est un terme familier, si jamais vous faites réparer votre auto ou allez chez un médecin, le diagnostic est un terme courant pour déterminer ce qui ne va pas. Il est également précis, vous devez passer sous le capot et voir comment tout est connecté pour comprendre ce qui ne fonctionne pas. Cela ressemble vraiment à travailler sur un moteur sans manuel, et la société est allée fabriquer le moteur sans regarder un autre moteur auparavant (donc c'est probablement unique).

Un élément de campagne de longue haleine ou à la formulation étrange recevra plus de questions dont vous ne voulez vraiment pas. Le «diagnostic de problème» est un concept plus ou moins universellement compris.

Rien sur une facture à un client ne devrait surprendre le client. Compte tenu de cela, j'espère que vous avez déjà défini l'attente avec le client qu'une fraction significative de votre temps serait initialement consacrée à vous familiariser avec l'application à la fois du point de vue de l'utilisateur et du point de vue du développeur. Et vos estimations pour les premières fonctionnalités ont, espérons-le, précisé qu'elles incluaient un temps décent pour vous familiariser avec le code.

Si vous avez déjà défini cette attente avec le client que la plupart du temps sur la facture initiale sera dépensée pour vous familiariser avec l'application, la façon dont vous l'énumérez sur la facture ne devrait pas trop d'importance. Utilisez la langue que vous avez utilisée pour fournir les estimations et définir les attentes. Si vous essayez seulement de communiquer cela maintenant, vous avez un problème.

En ma qualité de pigiste, j'appellerais probablement ce quelque chose comme "Assimilation des connaissances", au sens général. Et cela aurait été inclus dans toute estimation fournie initialement au client.

Cela ne vous aidera peut-être pas ici, mais pour référence future, je vous suggère de faire de cette tâche une tâche plus active à l'avenir. Par exemple, facturez au client le temps que vous avez passé à passer et à ajouter des commentaires au code non commenté, à ajouter des tests unitaires au code non testé, etc. Ce sont des exemples de tâches qui ajoutent au moins un peu de valeur tout en facilitant votre compréhension de la base de code .

Même s'il n'y a pas beaucoup de différence entre lire et lire pendant la documentation, votre client aura probablement une petite préférence psychologique pour ces tâches plus «actives». Et, vous pourriez en fait en savoir plus en documentant le code de quelqu'un d'autre qu'en le lisant simplement. (Ce sera certainement le cas si vous écrivez des tests par rapport à leur code).

Si vous faites cela, vous pouvez avoir un élément de ligne de facture qui dit quelque chose comme "Assimilation des connaissances et test / documentation du code hérité".

Edit: Dans votre situation telle que décrite, je mangerais honnêtement probablement le coût de cette activité. Je ne peux pas parler de vos finances, et je ne veux pas présumer, mais lorsque vous commencez, j'accorderais beaucoup plus de valeur à l'accumulation de témoignages et de clients satisfaits qu'à quelques heures de facturation. Si cela signifie un taux inférieur effectif au début, cela peut être un bon investissement. Manger quelques heures facturables à long terme est probablement un petit prix à payer pour un client satisfait qui pense qu'il ou elle a été secoué équitablement.

Correction d'un bug: analyse des causes profondes.

Nouvelle fonctionnalité: analyse, conception, intégration et test.

Introduire de nouveaux bugs: la sécurité d'emploi. :)

Avec un client qui aime comprendre comment les choses fonctionnent et qui m'écoute avec des yeux rêveurs, j'irais avec une ligne droite Codebase Familiarization. Je lui aurais déjà expliqué dans quel flot de douleur il me mettait et l'avantage de venir me voir pour d'autres mises à niveau.

Avec l'autre type de client ... (même traitement, mais il n'écoute évidemment pas un seul mot que je dis ), j'irais avec quelque chose comme:

• Planning Phase

• Intervention Planning

  (J'utiliserais celui-ci, en fait, mais j'écrirais cela en italien, dans lequel cela semble beaucoup mieux)

• Alors peut-être... Solution Planning

J'aime la Diagnosispartie de la Problem Diagnosissuggestion de anon, mais cela Problemne me semble pas juste. Il peut être ouvert à des critiques douces, partiales, ignorantes et superficielles ... qui peuvent laisser un mauvais goût derrière.

Vous savez, tout le monde veut lancer une fléchette sur le consultant externe, et ils le font. (... comme s'il n'était pas assez bon pour comprendre la racine du problème en leur parlant, et qu'il devait facturer son impuissance, ou Dieu sait quoi)

Mon mécanicien m'envoie une facture "Changer l'huile, l'étincelle plus, vérifier les filtres, les rotations des pneus. Réparer le cliquetis du moteur, essai routier .....

Pièces (détaillées),

Travail x @ $ y / heure = z)

Il n'interrompt pas le travail, vous non plus. Facturez le nombre total d'heures et décrivez ce que vous avez fait.