Wie nähere ich mich dem alten "Dies wird nur eine kleine Anwendung sein"? Ja, genau?


11

Ok, ich bin schon oft darauf gestoßen, aber hier ist das Worst-Case-Szenario etwas übertrieben.

Ein Kunde sagt: "Hey, können Sie uns dieses kleine Modul für diese kleine Aufgabe machen?"
Ich: "Sicher kein Problem".

Aufgrund von Budgets, Einschränkungen usw. überspringe ich einige der Architekturen und tauche direkt ein, damit es nicht ins Schwitzen kommt.

Dann fragen sie nach einem anderen Modul. Und ein anderer. Und einige Verbesserungen. Und das alles geschieht über Jahre hinweg sehr langsam. Und bevor Sie es wissen, haben Sie diese Monsteranwendung, die schrecklich aufgebaut ist.

Was machst du, wenn du aufgefordert wirst, etwas Kleines zu tun? Sie wissen nicht, ob es weiter wachsen wird ... ob der Kunde weiterhin nach Ergänzungen fragen wird (und sie auch nicht).

Sie können das Ding nicht überarchitekturieren, weil es immerhin nur eine kleine Anwendung ist, und sie werden woanders hingehen, wenn Sie sagen (da ich alle Stimmen kenne): "Nun, nur für den Fall, lassen Sie uns dieses Ding in Schichten mit Top konstruieren -o-the-Line-Sicherheit und Trennung von Bedenken. Lassen Sie uns in der Tat mit einem Tool zur Abhängigkeitsinjektion gehen, das dieses Ding wirklich fantastisch macht. bla bla bla ".

Sie werden "Ja, richtig" sagen und zu jemand anderem gehen.

Budget, Zeit und Wahrnehmung sind ebenso wichtig wie die Architektur der Anwendung selbst.

Wie soll das angegangen werden?

Ich denke, die Frage läuft wirklich darauf hinaus: "Wenn Sie nicht alle Informationen für das Endergebnis einer scheinbar kleinen Anwendung haben, wie können Sie vermeiden (oder abschwächen), frühzeitig architektonische und Designentscheidungen zu treffen, die vollständig sind." später nicht geeignet?

Antworten:


17

Ich bin auf einige davon gestoßen, und was ich normalerweise mache, ist genau das, was du getan hast, tauche direkt ein und erledige es.

Wenn sie für mehr zurückkommen, bedeutet dies, dass ihr Geschäftsmodell funktioniert und sie bereit sein sollten, etwas mehr zu investieren. Dann setze ich sie hin (normalerweise 3. Modul, abhängig von der Komplexität) und sage ihnen die schlechten Nachrichten.

Ich werde alles auf den Tisch legen, anbieten, das Ganze einschließlich des neuesten Moduls zu wiederholen und ihm zu sagen, wie viel es kosten wird. Normalerweise haben sie zu Beginn einen Aufkleberschock, aber wenn Sie eine gute Arbeitsbeziehung haben und Ihre Sachen funktionieren, sollte dies kein großes Problem sein.

Stellen Sie jedoch sicher, dass sie drei Dinge verstehen:

  1. Wenn sie sich wirklich nicht um ein vollständiges Umschreiben kümmern möchten, werden Sie trotzdem das 3. Modul ausführen. Es kann noch ein paar Stunden dauern und Sie werden es ihnen in Rechnung stellen. Erinnern Sie sie daran, dass sie wirklich darüber nachdenken sollten, in Zukunft eine Neufassung vorzunehmen, denn je länger sie warten, desto mehr wird es kosten.

  2. Es wird sie wirklich mehr kosten, jemanden dazu zu bringen, es zu tun. Die neue Person muss alles mit minimalem Verständnis ihrer Bedürfnisse und Macken neu gestalten, was zusätzliche Umschreibzeit und das Risiko bedeutet, dass sie nicht so gute Arbeit leistet.

  3. Dass Sie nicht versuchen, schnell Geld zu verdienen. Das Ding muss neu gestaltet werden.

Übrigens, wenn Ihre Abrechnungsgewohnheit ungefähr halb so groß ist, halb so weit, wenn Sie fertig sind, können Sie erwägen, ihnen verlängerte Zahlungsbedingungen anzubieten. Ändern Sie es jetzt auf die Hälfte und teilen Sie den Saldo über den Zeitraum auf, in dem Sie daran arbeiten werden. Das könnte die Krise verringern, wenn sie Budgetprobleme haben.


Dies scheint ein perfekter Weg zu sein.
Sevenseacat

1
Ja, das ist ein guter Ansatz. Halten Sie es für vorteilhaft, sie gleich zu Beginn (1. Modul) darüber zu informieren, dass dies eine Möglichkeit ist, damit sie wissen, was sie mit diesem ersten schnellen und schmutzigen Modul sind (und nicht bekommen)?
Richard

1
@ Richard DesLonde. Ich wäre nicht ehrlich. Wenn das erste Modul klein ist, konzentrieren Sie sich nur darauf, das Geschäft abzuschließen. Bis Sie die Beziehung tatsächlich über ein erstes Modul hergestellt haben, kann es schwierig sein, sie dazu zu bringen, wirklich zuzuhören. Sobald das erste Modul installiert ist und die Benutzer es lieben, sollten Sie eine beträchtliche Hebelwirkung finden, wenn sie ein zweites Modul planen. Sobald Sie das Gefühl haben, dass die Beziehung stark genug ist, entscheiden Sie sich dafür.
Permas

10

Mach ihm einfach eine kleine App und werde dafür bezahlt.

Nach meiner Erfahrung ist es zwingend, am Anfang mehr Zeit zu investieren, als wirklich benötigt wird, nur für den Fall, dass der Kunde mehr möchte. Aber Sie müssen den Aufwand dafür abwägen (werden Sie dafür bezahlt) und die Wahrscheinlichkeit, dass all diese zusätzlichen Änderungen tatsächlich eintreten werden. Die gesamte App wird möglicherweise nach einem Jahr vollständig ersetzt.

Und wenn Sie Zeit in die ursprüngliche Architektur investieren, haben Sie möglicherweise das Gefühl, sich selbst einen Gefallen zu tun. Aber wirklich, Sie tun dem Kunden nur einen Gefallen, indem Sie die anderen Module für ihn billiger machen.

Stellen Sie Ihrem Kunden für jedes nachfolgende Modul ein bisschen mehr in Rechnung und überarbeiten Sie das erste Projekt Schritt für Schritt, aber immer nur, um den Kundenanforderungen zu entsprechen.


Ein guter Ansatz ... Refactoring und Abrechnung für genau das, was der Kunde benötigt, aber um die Anwendung seinem Wachstum angemessen zu halten ... danke.
Richard

1
Zustimmen. Lernen Sie auch geeignete Refactoring-Tools kennen, damit Sie die Anwendung bei Bedarf schnell umgestalten können.

@ Thorbjørn Ravn Andersen: Irgendwelche Vorschläge für Werkzeuge?
Richard

@ Richard, hängt davon ab, mit was Sie arbeiten. Für Visual Studio sollte "Resharpener" ein sehr hilfreiches Werkzeug sein.

Ich denke, Sie denken an Resharper ... Es gibt natürlich auch andere Tools wie dieses. Visual Studio unterstützt auch sehr grundlegende Refactoring-Tools.
Ramhound

8

Frühere Antworten sind gut und, wenn ich ehrlich bin, was ich wahrscheinlich tun würde. Trotzdem bin ich bei diesem Ansatz etwas unruhig, da Sie Entscheidungen treffen, die dem Kunden gehören, basierend auf der Annahme, was er will (und dem Wunsch, den Job zu bekommen).

Ich kann nicht Gefühl , das man Hilfe sollte tun werden , ist mit dem Kunden ehrlich zu sein und gibt ihnen die Wahl: 1. Ich kann dies tun , schnell und (relativ) billig jetzt. Es wird großartig sein - es wird funktionieren - aber zukünftige Verbesserungen werden inkrementell etwas mehr kosten. 2. Ich kann mehr Zeit im Voraus damit verbringen, was etwas mehr kostet und keinen wirklichen Nutzen für die Benutzer bringt, ABER Auf lange Sicht sparen Sie Geld, wenn Sie neue Funktionen hinzufügen müssen.

Im Idealfall können Sie ihnen einige Zeit- / Kostenangaben für das Baseballstadion geben - andernfalls könnte das Gespräch zu akademisch sein -, aber ich schätze, dass es auch mühsam sein kann, diese Zahlen zu ermitteln. Zumindest würde die Gestaltung der Diskussion in Bezug auf frühere Projekte dem Kunden das Leben erleichtern (und das Leben des Kunden zu erleichtern, sollte oberste Priorität haben :-))

Kommentare, die andere über eine gute Arbeitsbeziehung abgegeben haben, sind genau richtig - aber Sie können diesen Prozess beginnen, indem Sie selbst ehrlich sind. Wenn der Kunde der Typ ist, mit dem Sie nicht einmal ein Gespräch führen können, ist es jetzt vielleicht an der Zeit, sich zu fragen, wie sehr Sie diesen Job brauchen ...


Ja, ich denke, vielleicht könnte eine Diskussion vor den Optionen oder zumindest der Ansatz (schnell und schmutzig jetzt, später neu schreiben) von Vorteil sein.
Richard

1

Ich würde jede dieser "Iterationen" als separates Projekt behandeln. Sie sollten diese Projekte schließen, wenn jedes kleine Modul oder jede Ergänzung abgeschlossen ist. Wenn sie dann etwas anderes wollen, entwerfen Sie die Unterlagen. Und mit der Zeit wird die Software teurer ... was bedeutet, dass Sie für jedes kleine Projekt mehr verlangen.

Es ist eine Möglichkeit, es zu betrachten, anstatt eines ... LONGGGGGG-Projekts.


1

Wie können Sie vermeiden (oder abschwächen), frühzeitig architektonische und gestalterische Entscheidungen zu treffen, die später völlig unangemessen sind?

Das kannst du nicht . Programmierer sind keine Hellseher. Während wir einfache Dinge vorhersagen oder Verbesserungen der Benutzeroberfläche sehen können, können wir nicht wirklich über das hinaus programmieren, von dem wir nicht wissen, dass der Client es später möchte (sehen Sie den Wahnsinn dort?).

In Ihrer Frage wurde erwähnt, dass es Geschäftsprozesse gab, aber ich bin mir nicht sicher, ob es sich um gute Prozesse handelt. Hier sind einige Hinweise:

  • Erfordern alle Änderungen und Ergänzungen, die schriftlich und mit einem Budget unterzeichnet wurden.
    • Weil Sie Rechnungen bezahlen müssen
    • Das Schreiben und der unterschriebene Teil stellen sicher, dass es das ist, was sie wirklich wollen, und reduzieren 90% der leichtfertigen Dinge, die Kunden auf halbem Weg während des Projekts ändern

Ihr überwachsenes Produkt

Es passiert uns allen. Der Wiederaufbau von Grund auf ist normalerweise eine schreckliche Idee, insbesondere wenn man bedenkt, dass er in Zukunft erneut durchgeführt wird.

Stattdessen würde ich die vom Benutzer angeforderten Änderungen unter Vertrag nehmen. Fügen Sie für jedes Feature zusätzliche Zeit hinzu, indem Sie die ursprüngliche Zeit für die Bearbeitung des Features und die zusätzliche Zeit für die Verbesserung der Gesamtarchitektur verwenden, jeweils eine kleine Verbesserung. Das Ziel ist nicht, die Architektur in einem Vertrag vollständig zu "reparieren", sondern sie im Laufe der Zeit langsam zu bearbeiten.

Verbessern Sie langsam die Code-Iteration durch Iteration und konzentrieren Sie sich dabei auf die Teile, die wirklich wichtig sind.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.