Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Grundsätze beim Programmieren: Funktionen nicht vergolden
irgendwann in den letzten 20 Jahren sah ich eine Liste von Grundsätzen.
Es wären entweder Grundsätze beim Programmieren, oder für Anforderungsmanagement oder für das gestalten von Webseiten / HTML.
Eine dieser Regeln war eine, die etwa lautete: "Funktionalitäten nicht vergolden"
Es ging darum, dass wenn der Kunde etwas wünscht, dass man dies nicht "noch schöner" macht als gefordert, sondern einfach das implementieren soll was gefordert ist. Man soll keine Funktionalitäten implementieren, die schön sind, aber gar nicht genutzt werden.
Ich suche eine oder mehrere Webseiten, wo sowas beschrieben ist.
Man sollte das aber auch nicht übertreiben mit dem "nicht vergolden". Ich habe es erlebt, dass Projektmanager pissig waren, wenn man öfters bei Code-Reviews dazwischen gegrätscht ist, weil der Code einfach hingerotzt war und einen schlechten Stil hatte. Eine Quick&Dirty-Lösung die irgendwie funktioniert aber für niemanden lesbar oder wartbar ist, ist mittelfristig genauso schlimm und zieht Bugs förmlich an, oder kostet später viel Extrazeit für Refactoring.
Viele verwechseln einfach den Aufwand einen guten, schönen Code zu schreiben mit "vergolden". Das sollte man schon nicht verwechseln, auch wenn man als PM so gar keinen Schimmer haben sollte.
Das wichtigste ist, dass man klipp und klar definiert, was nun die Anforderungen Ziel der jeweiligen Aufgabe sind. Dann muss alles in den gemeinsam vereinbarten Code-Conventions umgesetzt werden.
Werden keine klaren Vorgaben gesetzt, dann wird immer zuviel oder zu wenig entwickelt. Das ist aber nicht versagen der Entwickler dann, sondern des Projektmanagements bzw. dem Product Owner
So dogmatische Regeln würde ich aus Prinzip ignorieren.
Dein Beispiel ist auch eher eine Vorgabe von Product Ownern, als etwas für Programmierer zum Nachdenken.
Perfektion kann man oft nicht erreichen, aber wenn hinterher was schönes rauskommt, das man später auch bei Changes wieder schön umbauen kann und vorallem das Gesamtkonstrukt so flexibel aufgebaut ist, dass es einfach Spaß macht, wenn man später was erweitern muss, dann macht man das deutlich lieber.
Am schlimmsten finde ich Projekte, wo nur alles durchgepusht wird, hauptsache irgendwas kommt raus und jeder ist froh, wenn er aus dem Mist draußen ist. Ausbaden darf den Müll dann der Teil der übrig bleibt für die Pflege
In der Theorie sind die Anforderungen ja stets im Lastenheft definiert, welches der Auftraggeber erstellt. Nicht selten ist dieses Lastenheft aber unvollständig oder zumindest nicht eindeutig formuliert, weil der Auftraggeber seine Anforderungen gar nicht richtig definieren kann bzw. bestimmte Anforderungen nicht vollends durchdacht hat.
Der Begriff "vergolden" ist meines Erachtens etwas irreführend. Sicherlich sollte man generell keine unnötigen Funktionen implementieren und womöglich noch viel Zeit darin versenken, ohne dass sie irgendeinen Mehrwert bringen, aber man kann dazu auch außer der Reihe in einen Dialog treten und die Vergoldung gewissermaßen vorschlagen obwohl sie gar nicht gefordert war - natürlich stets mit allen damit verbundenen Konsequenzen was den Aufwand und die Bezahlung angeht.
Ich entwickle zwar keine Kundensoftware im eigentlichen Sinne, sondern Software für unsere Industriemaschinen und aktuell auch eine betriebsinterne Software für unsere Serviceabteilung, aber ich muss unserem Serviceleiter manchmal auch ein paar sinnbildliche Schellen mit der Tastatur verpassen, wenn ich Ideen einstreue, bei denen mich er ganz verdutzt anguckt, weil er daran gar nicht gedacht hatte. Im Kontext mit externen Kunden kann einem sowas natürlich auch passieren, keine Frage.
Meines Erachtens kann es für solche Dinge daher kein pauschales Regelwerk geben, sondern es ist stets mit Augenmaß zu betrachten wann man sich strikt an Vorgaben zu halten hat und wann man gegebenenfalls als Ideengeber fungieren kann, um das Endergebnis womöglich noch bedienfreundlicher oder auch mächtiger zu gestalten. Niemandem ist damit gedient, wenn nach Release plötzlich die Stimmen laut werden, dass eben diese eine Funktion fehlt oder jene andere blöd zu bedienen ist. Mit Glück kriegt man zwar einen Folgeauftrag für eine Erweiterung, aber mit Pech ist der Kunde oder dessen Mitarbeiter, die damit arbeiten sollen, einfach nur unzufrieden.
Ich weiß nicht woher hier die Diskussion um Code-Qualität (sauberes Programmieren) kam, wenn doch die Personen selbst geschrieben haben, dass dies was anderes ist als Gold-Plating.
Es ging in meinem Fall darum, dass wir eine Art Suche implementiert haben, wo man jetzt die Wildcard * benutzen kann, die aber gar nicht vom Kunden gefordert war. Diese Wildcard hat uns sehr viel Entwicklungszeit und Testzeit gekostet für eine Funktionalität, wo der Kunde mir heute gesagt hat, dass er diese Funktionalität nie nutzen wird.
Ich hatte vor 2 Wochen angeboten mit dem Kunden zu sprechen, um die Anforderungen zu klären. Ich bin der Programmierer. Ich wurde dann zurückgepfiffen, dass ich das nicht tun soll. Dies würde die Abteilung machen, die das nachher testet. Also habe ich mich gefügt. Das ist meiner Ausbildung nach auch in der theorie völlig in Ordnung und eher sogar richtig, dass der Programmierer eben nicht mit dem Kunden über die Anforderungen spricht.
Das Problem ist nur, dass unsere Tester absolut gar keinen technischen Hintergrund haben und nicht programmieren können. Ergo können sie nicht in den gleichen Denkmustern denken und verstehen den Code nicht. Ergo können sie auch nicht Anforderungen schlau durchdacht aufschreiben. Zusätzlich dazu kam die Anforderung mit der Wildcard sogar von unserem Chef selbst, obwohl er Ahnung vom programmieren hat. Aber eben keine Ahnung von Anforderungsmanagement und wirtschaftlichem Arbeiten.
Wieso schreiben Tester bei euch Anforderungen? Das läuft doch was ziemlich falsch...
Und das mit der Wildcard: Entwickelt ihr für jeden Kunden alles immer neu und macht keine Module/Libs, die man nach Bedarf einbindet? Also zum Beispiel ein Eingabefeld, das eben Wildcards kann und dann eben in künftigen Projekten wiederverwendet wird. Standard-Entwicklung eben.
Ergänzung ()
Enomine88 schrieb:
Ich weiß nicht woher hier die Diskussion um Code-Qualität (sauberes Programmieren) kam, wenn doch die Personen selbst geschrieben haben, dass dies was anderes ist als Gold-Plating.
Weil das Leute oft nicht unterscheiden können, vorallem nicht, wenn sie keinen technischen Hintergrund haben, sondern nur eine PM-Sicht in der es ausschließlich um zahlen geht.
Ergänzung ()
Enomine88 schrieb:
Ich hatte vor 2 Wochen angeboten mit dem Kunden zu sprechen, um die Anforderungen zu klären. Ich bin der Programmierer.
Also hast du gold plating betrieben? Weils ein Chef gesagt hat? Dann ist es doch in Ordnung. Für dich ist nicht der Endkunde entscheidend, sondern das, was dir als Arbeitsauftrag gegeben wird. Wenn dein Chef ne Wildcard will, bekommt er sie halt. Wenn er das an seinen Kunden weitergibt und der braucht es nicht, dann ist das sein Fehler.
Du hast im Grunde alles richtig gemacht.
Und grundsätzlich: Wir machen auch teilweise eine Übererfüllung, wenns zeitlich machbar ist. Das passiert meist in den Fällen, wo man merkt "Jepp, das könnte ein Standardfeature sein, das sollten wir gleich so allgemein und wiederverwendbar machen, dass es auf den Stapel der internen Vorlagen landen kann." Dann kann mans im nächsten Projekt, oder auch im selben bei ähnlichen Anforderungen, wiederverwenden. Im Schnitt brauchen wir gefühlt die Hälfte dann wirklich innerhalb von zwei Jahren wieder und verkürzen die Zeiten dadurch enorm, dass wir nicht alles 5x entwickeln sondern gleich ein gutes Konstrukt bauen.
Das ist eigentlich auch eine Vergoldung, aber diese zahlt sich mittelfristig aus, weil dadurch ein Baukasten entsteht um künftige Projekte schneller bzw. billiger umzusetzen. Verkauft werden sie deshalb nicht zwangsläufig billiger, weil Sales ja nicht weiß, dass wir intern Sachen bereithaben. Nimmt uns viel Stress und Druck weg und man kann Projektteile die zu schnell fertig werden, die Puffer noch aufbrauchen. Dankt einem niemand, wenn man deutlich vor der Zeit fertig ist.
Ergänzung ()
Also, was ich damit eigentlich sagen will:
Es gibt Sachen, die wirken als gold plating auf den ersten Blick, können aber auch richtig und gut sein.
Dieses Schwarz-Weiß-Denken des PM ist einfach weit von der Realität entfernt.
Wären diese PM-Richtlinien und Best Practices so gut, würden nicht soviel Projekten scheitern.
Es sind einfach immer nur Richtlinien die einem den Weg zeigen sollen, aber niemals die ultimativen Wahrheiten. Man sollte immer mit Hirn an Sachen rangehen und abwägen, ob sich ein Extraaufwand rentiert.
Und das kann man nicht so sauber trennen zwischen "Guter Code" und "Vergolden", das ist ein fließender Übergang oft. Manche Funktionalitäten ergeben sich auch einfach aus dem Design/Algorithmus der Funktion und warum dann nicht nutzen?
Es gibt Sachen, die wirken als gold plating auf den ersten Blick, können aber auch richtig und gut sein.
Dieses Schwarz-Weiß-Denken des PM ist einfach weit von der Realität entfernt.
Wären diese PM-Richtlinien und Best Practices so gut, würden nicht soviel Projekten scheitern.
Es sind einfach immer nur Richtlinien die einem den Weg zeigen sollen, aber niemals die ultimativen Wahrheiten
Ich hatte vor 2 Wochen angeboten mit dem Kunden zu sprechen, um die Anforderungen zu klären. Ich bin der Programmierer. Ich wurde dann zurückgepfiffen, dass ich das nicht tun soll. Dies würde die Abteilung machen, die das nachher testet. Also habe ich mich gefügt
Sicherlich ist es bei manchen Projekten so, dass nicht alle Beteiligten auch an den Besprechungen teilnehmen können/müssen, aber es muss nun mal mindestens eine Person mit entsprechendem fachlichen Background dabei sein. Leider ist das nicht immer der Fall und das ist in meinen Augen zu 100% ein Versagen des Projektverantwortlichen. Sowas solltest du offen ansprechen, weil es auch mal andersherum laufen kann wie im vorliegenden Fall: Es wird ein Feature versprochen und verkauft, das nicht umsetzbar ist, zumindest nicht im definierten Zeitrahmen.
Außerdem: Stell dir vor, wenn es beim Kunden ähnlich läuft. Dann hockt da der Chef, der von der Arbeit seiner Angestellten keinen Plan hat, blubbert rum, dass das Feature vollkommen überflüssig ist, und diejenigen, die am Ende mit der Software arbeiten, lieben diese Funktion. Ein Grund mehr warum bei solchen Meetings nach Möglichkeiten alle involvierten Abteilungen auf beiden Seiten vertreten sein sollten oder im Vorwege der Besprechung Gelegenheit bekommen, ihren Sempf () dazuzugeben.
Enomine88 schrieb:
Es ging in meinem Fall darum, dass wir eine Art Suche implementiert haben, wo man jetzt die Wildcard * benutzen kann, die aber gar nicht vom Kunden gefordert war. Diese Wildcard hat uns sehr viel Entwicklungszeit und Testzeit gekostet für eine Funktionalität, wo der Kunde mir heute gesagt hat, dass er diese Funktionalität nie nutzen wird.
Da muss ich aber ganz klar sagen: Das ist grundsätzlich ein sehr sinnvolles Feature, welches sich zu 100% in einem späteren Projekt wiederverwenden lässt - und sei es auch nur die angeeignete Erfahrung, um so eine Suche oder etwas Vergleichbares zu implementieren.
Es ging in meinem Fall darum, dass wir eine Art Suche implementiert haben, wo man jetzt die Wildcard * benutzen kann, die aber gar nicht vom Kunden gefordert war. Diese Wildcard hat uns sehr viel Entwicklungszeit und Testzeit gekostet für eine Funktionalität, wo der Kunde mir heute gesagt hat, dass er diese Funktionalität nie nutzen wird.
Ich hatte vor 2 Wochen angeboten mit dem Kunden zu sprechen, um die Anforderungen zu klären. Ich bin der Programmierer. Ich wurde dann zurückgepfiffen, dass ich das nicht tun soll.
Lass dich befördern zum Product Owner o.ä. oder bewirb dich weg in so eine Rolle oder bewirb dich weg und versuche danach zu screenen, dass es im neuen Unternehmen besser läuft.
In einer anderen Firma C wo ich mal war gab es ein Scrum konzept.
Da haben sich Kunde, Business Owner, Designer und Programmierer getroffen und die Themen in kleine Bereiche aufgespalten, priorisiert und diese dann gemeinsam mit Schätzpoker geschätzt.
Beim schätzen fallen eh einige wertungen raus und dann wird die schätzung oft noch erklärt. mmn war das schon gut, ich schätze da gibts auch unterschiedliche sub-philosophien.
Ich kenne da halt auch oft die Diskussionen die da entstehen. Wenn da ein Kunde dabei ist, kann das Team doch gar nicht richtig offen sprechen und diskutieren. Halte ich also entsprechend für kontraproduktiv.
Besser ist es, wenn dem Kunden eine gewisse Anzahl an Story-Points verkauft werden und dieser dann selbst entscheiden kann und ggf. eingreifen, wenn ein Feature zu teuer sein sollte. Wenn die Storypoints nicht ausreichen, müssen eben weitere gekauft werden, mit entsprechender Verschiebung des finalen Liefertermins.
Wobei letzteres den Kunden eigentlich nicht stören sollte, weil er ja in der Regel alle 2-4 ein neues Inkrement bekommt und damit ab einem gewissen Stadium schon ein voll funktionsfähige Software hat, die dann eben noch weitere Funktionen bis zur Endabnahme dazu bekommt.
Wobei ich sagen muss: Bei uns wirds leider auch nicht so gehandhabt. Wenn wir Glück haben, können wir etwas wirklich nach Aufwand verkaufen, das ist dann natürlich super, weil kein Risiko auf unserer Seite. Die Regel sind aber leider Festpreis-Angebote wie unsäglichen Diskussionen, wie nun die Anforderungen im Detail dann ausschauen soll. Da kann halt eine kleine, unbedachte Formulierung des Sales-Teams mal eine kleine Funktionalität mit 8h Entwicklung zu einer Woche Entwicklung aufblähen, wenn der Kunde drauf besteht.
) dazuzugeben.
