Sollte ich meinem Vertrag eine Garantieklausel garantieren oder hinzufügen, falls der Code bricht oder eine Anomalie außerhalb der Hand oder der Handlung Gottes des Kunden auftritt?

Wenn ja, was soll diese Sprache sagen?

Bieten Sie keine an, es sei denn, Ihr Kunde verlangt eine Garantie oder Gewährleistung. Viele Kunden werden es am Ende nutzen, um Sie in die Knechtschaft zu zwingen.

Auch wenn sie einen verlangen, konsultieren Sie einen Anwalt. Ansonsten bereiten Sie sich auf eine Katastrophe vor.

Sollte ich meinem Vertrag eine Garantieklausel garantieren oder hinzufügen, falls der Code bricht oder eine Anomalie außerhalb der Hand oder der Handlung Gottes des Kunden auftritt?

Nein niemals

Wenn nötig, nehmen Sie den Job nicht an. Dies ist eine unmögliche Situation. Die Liste der Dinge, die geändert werden könnten und die dazu führen würden, dass Ihr Code kaputt geht oder nicht funktioniert, hat kein Ende.

Wenn Sie nicht gerne kostenlos arbeiten, fahren Sie fort.

Die Standardmethode, um darauf zu reagieren, besteht darin, eine Support- oder Wartungsklausel hinzuzufügen - "die ersten 10 Arbeitsstunden sind kostenlos enthalten, der Rest ist mit der folgenden Rate verfügbar:".

Ich habe Adams "Nicht tun" positiv bewertet, aber das Anbieten einer solchen Garantie für ein kommerzielles Softwareprodukt könnte bei den Kunden viel positive Aufmerksamkeit finden. Es würde auch zeigen, dass Sie im Vergleich zum Rest der Branche riesige Cojones hatten. :-)

Ich könnte unter folgenden Umständen in Betracht ziehen, eine Garantie anzubieten:

• Es ist mein Produkt, im Gegensatz zu Leiharbeit für jemand anderen.
• Ich hatte die Kontrolle über den gesamten Softwareentwicklungs- und Release-Prozess, einschließlich Spezifikation, Programmierung, Test und Dokumentation.
• Ich habe in der Dokumentation sorgfältig angegeben, unter welchen Umständen die Software ausgeführt werden kann, für die die Garantie gelten würde. Zum Beispiel Hardwareanforderungen, keine Ausführung unter Betriebssystememulatoren usw.
• Ich habe die Garantiezeit begrenzt.
• Ich war von der Qualität der Software sehr überzeugt

In diesem Fall biete ich möglicherweise eine Garantie wie "Für einen Zeitraum von einem Jahr ab Kaufdatum garantieren wir, dass wir die Software reparieren und eine kostenlose Garantie ausstellen, wenn sie nicht im Wesentlichen wie im Benutzerhandbuch dokumentiert ausgeführt wird aktualisieren."

Das klingt nicht nach einer großen Garantie, ist aber weit mehr als die meisten kommerziellen Softwareprodukte, versichert den Kunden, dass Sie Fehler beheben werden, und das Wort "im Wesentlichen" lässt genug Spielraum, damit Sie nicht pleite gehen.

Wenn es Vertragsprogrammierung für jemand anderen ist, vergessen Sie es. Ich bin einmal in eine ähnliche Situation geraten, als ich ein Windows-Programm auf den Mac portiert habe, und habe Zehntausende von Dollar verloren, um "Fehler" zu beheben, die tatsächlich versteckte Funktionen in der Windows-Version waren, die der Client vor Vertragsunterzeichnung nicht erwähnt hat , obwohl wir wiederholt nach Spezifikationen gefragt hatten. Diese Erfahrung war einer der Hauptgründe, warum ich aufgehört habe, Festpreisverträge abzuschließen.

Es ist üblich, eine Garantie zu geben, die Fehlerbehebungen für einen bestimmten Zeitraum nach Projektende (z. B. 3-6 Monate) enthält. Dies sagt dem Kunden, dass Sie hinter Ihrem Code stehen, und ehrlich gesagt sollten Sie eine gewisse Haftung für Probleme haben, die Sie mit Ihrem Code liefern.

In unseren Projekten bieten wir normalerweise eine SLA (Service Level Agreement) an, in der die Fehler und der Zeitplan für die Behebung der Fehler entsprechend ihrem Schweregrad festgelegt werden. Beispielsweise sollten kritische Probleme in einem Live-Projekt innerhalb einer Stunde nach Erhalt des Berichts behoben (zumindest versucht) werden. Visuelle Probleme und kleinere Fehler sollten innerhalb von 48 Stunden behoben sein.

Es ist sehr wichtig, eine klare Definition des Fehlers zu haben, da Clients häufig versuchen, neue Funktionen als Fehlerberichte zu verwenden (manchmal unbeabsichtigt). Diese Definitionen sind immer etwas offen für Interpretationen, daher müssen Sie einen Schiedsrichter (normalerweise eine Autorität in der Entwicklungssprache / -plattform) zuweisen, der Meinungsverschiedenheiten vermitteln kann.

Der Vertragstext müsste ähnliche Angaben enthalten:

1. Sie dürfen diesen Code nicht erweitern
2. Sie dürfen diesen Code nicht zurückentwickeln
3. Sie können diesen Code möglicherweise nicht in Ihr Framework integrieren (ähnlich wie Nummer 1, jedoch anders in dem Sinne, dass er zu einer ganzen Ebene ihres Geschäfts wird).
4. Sie dürfen diesen Code nicht auf andere Betriebssysteme portieren (IE Windows zu Unix).

Nur ein paar, an die ich denken konnte.