Wie soll ich den Prozess des Lernens des Codes einer anderen Person beschreiben? (In einer Rechnungssituation.) [Geschlossen]

Bearbeiten: Justin Cave machte einen guten Punkt, dass diese Art der Kommunikation in meinen Zitaten / Schätzungen im Vordergrund stehen sollte. In diesem Fall bin ich immer noch daran interessiert zu wissen, mit welcher Art von Sprache die vorhandenen Code-Lernaktivitäten beschrieben werden. Vor allem für ein Unternehmen, das sich noch nie mit Softwareanbietern befasst hat. Bearbeitung beenden

Ich habe einen Vertrag zur Aktualisierung einer internen Software für ein großes Unternehmen. Das Unternehmen hat mehrere Funktionserweiterungen und einige Fehlerbehebungen angefordert. Dies ist mein erster freiberuflicher Job.

Zuerst musste ich mich mit der Funktionsweise der Anwendung vertraut machen - ich habe es gelernt, als ob ich ein Benutzer wäre.

Als nächstes musste ich lernen, wie die Software funktioniert. Ich habe mit umfassenden Konzepten begonnen und mich dann auf die notwendigen Details beschränkt, bevor ich an den einzelnen Fehlerkorrekturen und Funktionen arbeitete.

Zumindest zu Beginn des Projekts habe ich viel länger gebraucht, um den vorhandenen Code zu lernen, als um die zusätzlichen Funktionen zu schreiben.

Wie kann ich den Prozess des Lernens des vorhandenen Codes auf der Rechnung beschreiben? (Dieser Teil des Unternehmens erledigt die Dinge normalerweise intern. Daher hat er nicht viel Erfahrung im Umgang mit Software-Anbietern wie mir, und ich befürchte, dass sie den Aufwand für das Erlernen des Codes eines anderen nicht verstehen.) Ich möchte nicht nur die Lernzeit auf das eigentliche Feature-Upgrade beschränken, da dies in einigen Fällen dazu führen würde, dass eine "einfache Aufgabe" so aussieht, als hätte ich viel zu lange gebraucht. Ich möchte die Rechnung in relevante Schritte aufteilen und mitteilen, dass ich den hohen Aufwand für das Erlernen des Codes einer anderen Person in Rechnung stelle, bevor ich meinen Code hinzufügen kann.

Gibt es eine Standardmethode, um diese Art von Aktivität bei der Abrechnung eines Auftrags zu beschreiben?

Ich würde Aufgaben wie "Vorhandene Funktionalität überprüfen" und / oder "Vorhandenen Code überprüfen" in Rechnung stellen. Abhängig von der Komplexität der neuen Funktionen würde ich eine "Design xxx" -Aufgabe hinzufügen, die die Zeit einschließt, die ich mit dem Herausfinden der Integrationspunkte in den vorhandenen Code verbringe.

Ich halte es für eine gute Idee, dem Kunden zu verdeutlichen, dass die Aktualisierung eines neuen Beraters mit einem gewissen Aufwand verbunden ist. Wenn er mit dem Ergebnis zufrieden ist, kann die Fortsetzung der Zusammenarbeit mit demselben Berater wahrscheinlich Abhilfe schaffen Geld.

Problemdiagnose.

Es ist ein bekannter Begriff. Wenn Sie jemals eine Autoreparatur bekommen oder zum Arzt gehen, ist die Diagnose ein üblicher Begriff, um herauszufinden, was falsch ist. Es ist auch genau, Sie müssen unter die Haube gehen und sehen, wie alles verbunden ist, um herauszufinden, was nicht funktioniert. Es ist wirklich so, als würde man an einem Motor ohne Handbuch arbeiten, und die Firma hat den Motor hergestellt, ohne vorher einen anderen Motor angesehen zu haben (also wahrscheinlich einzigartig).

Eine langatmige oder seltsam formulierte Werbebuchung wird mehr Fragen haben, die Sie wirklich nicht wollen. "Problemdiagnose" ist ein mehr oder weniger allgemein verständliches Konzept.

Nichts auf einer Rechnung für einen Kunden sollte für den Kunden eine Überraschung sein. Angesichts dessen hoffe ich, dass Sie dem Kunden bereits die Erwartung gestellt haben, dass zunächst ein erheblicher Teil Ihrer Zeit darauf verwendet wird, sich sowohl aus Anwendersicht als auch aus Entwicklersicht mit der Anwendung vertraut zu machen. Und Ihre Schätzungen für die ersten Funktionen haben hoffentlich ergeben, dass sie eine angemessene Zeitspanne enthalten, um sich mit dem Code vertraut zu machen.

Wenn Sie beim Kunden bereits die Erwartung aufgestellt haben, dass der Großteil der Zeit auf der Erstrechnung damit verbracht wird, sich mit der Anwendung vertraut zu machen, sollte es keine große Rolle spielen, wie Sie sie auf der Rechnung aufführen. Verwenden Sie die Sprache, die Sie bei der Erstellung der Schätzungen und der Festlegung der Erwartungen verwendet haben. Wenn Sie jetzt nur versuchen, dies zu kommunizieren, haben Sie ein Problem.

In meiner Eigenschaft als Freiberufler würde ich dies im allgemeinen Sinne wahrscheinlich als "Wissensassimilation" bezeichnen. Und dies wäre in jeder Schätzung enthalten gewesen, die dem Kunden ursprünglich zur Verfügung gestellt wurde.

Hier hilft es Ihnen vielleicht nicht weiter, aber ich schlage vor, dass Sie dies in Zukunft zu einer aktiveren Aufgabe machen. Stellen Sie dem Kunden beispielsweise die Zeit in Rechnung, die Sie für das Hinzufügen von Kommentaren zu nicht kommentiertem Code, für das Hinzufügen von Komponententests zu nicht getestetem Code usw. aufgewendet haben. Dies sind Beispiele für Aufgaben, die zumindest einen geringen Mehrwert bieten und das Verständnis der Codebasis erleichtern .

Auch wenn es beim Dokumentieren keinen großen Unterschied zwischen Lesen und Lesen gibt, hat Ihr Kunde wahrscheinlich eine geringe psychologische Präferenz für diese aktiveren Aufgaben. Vielleicht lernen Sie sogar mehr, indem Sie den Code einer anderen Person dokumentieren, als wenn Sie ihn nur lesen. (Dies wird sicherlich der Fall sein, wenn Sie Tests gegen ihren Code schreiben).

Wenn Sie dies tun, können Sie eine Rechnungsposition haben, die so etwas wie "Knowledge Assimilation and Legacy Code Testing / Documentation" enthält.

Bearbeiten: In Ihrer Situation, wie beschrieben, würde ich ehrlich gesagt wahrscheinlich die Kosten für diese Aktivität essen. Ich kann nicht mit Ihren Finanzdaten sprechen, und ich möchte nicht vermuten, dass Sie, wenn Sie anfangen, viel mehr Wert darauf legen, Testimonials und zufriedene Kunden zu sammeln, als einige Stunden Abrechnung. Wenn dies zu Beginn eine effektive Senkung des Zinssatzes bedeutet, kann dies eine gute Investition sein. Langfristig ein paar abrechnungsfähige Stunden zu essen, ist wahrscheinlich ein kleiner Preis für einen zufriedenen Kunden, der denkt, er oder sie habe einen fairen Shake.

Behebung eines Fehlers: Ursachenanalyse.

Neues Feature: Analyse, Design, Integration und Testen.

Einführung neuer Fehler: Arbeitsplatzsicherheit. :)

Mit einem Kunden, der verstehen möchte, wie Dinge funktionieren, und der mir mit verträumten Augen zuhört, würde ich mich für eine Straße entscheiden Codebase Familiarization. Ich hätte ihm bereits erklärt, in was für einen Schmerz er mich versetzt und welchen Vorteil es hat, zu mir zu kommen, um weitere Upgrades zu erhalten.

Mit der anderen Art von Kunde ... (die gleiche Behandlung, aber er hört offensichtlich nicht auf ein einziges Wort, das ich sage ) würde ich mit etwas in den Zeilen gehen:

• Planning Phase

• Intervention Planning

  (Eigentlich würde ich dieses verwenden, aber ich würde das auf Italienisch schreiben, in dem es sich viel besser anhört.)

• Dann vielleicht... Solution Planning

Ich mag den DiagnosisTeil des Problem DiagnosisVorschlags von anon, aber der Problemklingt für mich nicht richtig. Es kann offen sein für milde, voreingenommene, ignorante und oberflächliche Kritik ... die einen schlechten Geschmack hinterlassen kann.

Sie wissen, jeder möchte einen Pfeil auf den externen Berater werfen, und das tun sie auch. (... als wäre er nicht gut genug, um die Wurzel des Problems zu verstehen, während er mit ihnen sprach, und musste seine Ahnungslosigkeit in Rechnung stellen, oder Gott weiß was)

Mein Mechaniker schickt mir eine Rechnung "Öl wechseln, Zündfunke plus, Filter prüfen, Reifendrehung. Motor rasseln, Fahrversuch beheben .....

Teile (aufgeschlüsselt),

Arbeit x @ $ y / Stunde = z)

Er zerlegt die Arbeit nicht, und Sie sollten es auch nicht tun. Berechnen Sie die Gesamtstunden und beschreiben Sie, was Sie getan haben.