Einige Funktionen der benutzerdefinierten Entwicklung / Sudo Null IT News

Hallo alle. Ich arbeite seit mehr als 10 Jahren in der kundenspezifischen Entwicklung und möchte meine Erfahrung teilen. Sagen Sie mir, mit welchen Merkmalen ich in meiner Arbeit konfrontiert werde. Vielleicht findet es bei Ihnen Anklang oder hilft Ihnen, Fehler zu vermeiden, oder hilft Ihnen, auf manche Arbeitssituationen vorbereitet zu sein.

Es kommt vor, dass in der Vorverkaufsphase unbedachte Versprechungen gemacht werden, um den Kunden zufrieden zu stellen. Und es kommt oft vor, dass diese Versprechen tatsächlich nicht eingehalten werden.

Die Strategie, allem zuzustimmen, nur in das Projekt einzusteigen und zu hoffen, dass wir es später herausfinden, ist ein Fehlschlag. „Später“ kommt zu schnell und die Folgen können äußerst unangenehm sein. Darüber hinaus müssen die direkten Teilnehmer des Projekts höchstwahrscheinlich herausfinden.

Meiner Meinung nach lohnt es sich, möglichst wahrheitsgemäß und bewusst darüber zu sprechen, was getan werden kann und wie lange. Im Zweifelsfall lieber pausieren, mit den Spezialisten im Unternehmen besprechen. Und sich danach auf die Funktionalität zu einigen, die implementiert werden kann. Und wenn es strittige oder unverständliche Punkte gibt, können diese eingeschränkt werden.

Es kommt vor, dass der Kunde auf seiner Wunschliste besteht, auch wenn sie nicht realisierbar ist. Er argumentiert, dass er Geld zahlt, also hat er Recht, und wir müssen tun, was er sagt. Und seine Wunschliste kann sich auf kleine Schnittstellenänderungen beziehen oder grundlegende architektonische Entscheidungen betreffen.

Mein Rat – nicht sofort zur Umsetzung laufen. Es ist sinnvoll, eine Reihe von Besprechungen abzuhalten. Kommunizieren Sie Ihre Position, untermauern Sie sie mit einer vergleichenden Tabelle mit Optionen, erstellen Sie eine Liste möglicher negativer Konsequenzen.

Aber zu meinem Bedauern hilft dies nicht immer, den Kunden zu überzeugen. Und wir müssen tun, was der Kunde will. Wenn bereits klar ist, was zu tun ist, schlage ich vor, Zeit zu investieren, um alle Informationen an einem Ort zu sammeln, beispielsweise in Form eines Briefes.

Beschreiben Sie in dem Schreiben Ihre Vorschläge, Ihre Empfehlungen, weisen Sie auf die Nachteile des Kundenvorschlags hin. Erstellen Sie eine Liste möglicher Konsequenzen, nämlich wozu eine solche Implementierung führen kann. Es ist sehr wichtig, dass das Schreiben keinen arroganten Ton hat, auf keinen Fall zu Persönlichkeiten übergeht und nicht versucht, den Kunden zu demütigen. Mit all dem beweisen Sie Ihren Fall nicht, sondern verschlechtern nur die Beziehung zwischen Ihnen und dem Kunden. Es lohnt sich, ohne Wasser trocken auf den Punkt zu schreiben.

Hier sehe ich jedoch den nächsten wichtigen Punkt. Denken Sie nicht, dass Sie später, wenn (oder wenn) der Kunde bereit ist zuzugeben, dass er falsch lag, ein Ass im Ärmel haben. Dass Sie Ihren Brief finden und das geschätzte „Ich habe es Ihnen gesagt!“ sagen werden. Leider wird dies nicht passieren. Wenn der Kunde zugibt, dass sein Vorschlag falsch war, dann gibt es eine andere Situation, andere Eingaben und andere Personen.

Erleben Sie daher die Situation jetzt, fixieren Sie die Entscheidungen in einem kalten Geist, akzeptieren Sie sie als Tatsache und machen Sie weiter.

Es kommt vor, dass der Kunde einfach keine coole technische Lösung braucht. Und es bereitet den Entwicklern Schmerzen. Entwickler wollen es cool und richtig machen. Aber es gibt Zeiten, in denen es einfach nicht nötig ist.

Damit muss man sich meiner Meinung nach einfach abfinden. Verstehen Sie, dass der Kunde möglicherweise keine gute, korrekte Architektur benötigt. Unsere Arbeit soll dem Kunden Geld bringen. Daher kann es sein, dass Sie es einfach tun müssen, indem Sie eine Krücke ersetzen. Auch wenn es Entwicklungsmustern widerspricht.

Um einfache Geschäftsprobleme zu lösen, müssen Sie keine komplexen Technologien verwenden. Egal, wie Sie sie verwenden möchten. Sie müssen immer darüber nachdenken, welches Geschäftsproblem wir lösen und warum wir es tun.

In meiner Arbeit begegne ich oft der Entwicklung eines Softwareprodukts nicht von Grund auf neu, sondern mit der Implementierung einer Box-Lösung. Und schon wird diese Boxed-Lösung fertiggestellt oder ein separates Subsystem darauf geschrieben.

Es kommt vor, dass der Kunde folgende Behauptung aufstellt: Sie müssen alles wissen, im Detail wissen, wie die Lösung out of the box funktioniert. Oder Sie müssen über die Bedeutung jedes Parameters nachdenken, wofür er verantwortlich ist und wie Sie ihn anwenden. Was tun damit? Hier habe ich leider keinen klaren Rat. Ich empfehle nur, was ich tue. Erklären Sie jedes Mal den Unterschied zwischen einer Boxed-Lösung und ihrer Verfeinerung. Von Zeit zu Zeit zu sagen, dass die Boxed-Lösung ihre Grenzen, ihre Probleme, ihre Fehler hat. Dass der Kunde, der sich für eine bestimmte Box-Lösung entscheidet, auch für diese Wahl verantwortlich ist.

Es gibt noch viele weitere Fälle. Wenn das Thema interessant ist, kann ich fortfahren.

Abschließend möchte ich erklären, warum ich weiterhin in der kundenspezifischen Entwicklung arbeite. Ich arbeite in der kundenspezifischen Entwicklung, weil ich mich dadurch recht schnell entwickeln kann. Jedes Projekt ist einzigartig, hat seine eigenen Eigenschaften und gibt mir ein exklusives Erlebnis. Diese Art von Arbeit hält mich auf Trab. Ich brauche es.

Welche Situationen sind Ihnen begegnet? Interessant zu wissen und zu diskutieren 🙂

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *