Großer Rückstand in der Umsetzung von HiOrg-Verbesserungen (und Fehlern)

Technik & Fragen
1

Hallo,

im November 2008 wurde der VV mit der ID 657 dahingehend von HiOrg-Server beantwortet, dass es eventuell in der Zukunft die Möglichkeit gibt Voting-Punkte käuflich zu erwerben um eigene Verbesserungsvorschläge zu priorisieren.

Wir sind mittlerweile bei mehr als 850 Vorschlägen angelangt, was aus meiner Sicht einen Arbeitsvorrat an mehreren Jahren für die HiOrg-Entwicklung bedeutet.

Ist das Entwickler-Team immer noch rein “ehrenamtlich” unterwegs? Könnte der zusätzliche finanzielle Erwerb von Voting-Punkten mehrere Entwickler-Stellen bezahlen, die sich dann um eine zeitnahere Entwicklung kümmern?

Da der HiOrg-Server mittlerweile für uns “DAS” Verwaltungstool geworden ist, wären wir gerne bereit gezielt finanziell Verbesserungsvorschläge zu fördern, um diese früher als geplant zu erhalten.

Wie ist der aktuelle Stand zu diesem Thema?

1 „Gefällt mir“
2

Ja, das finde ich auch heftig. Vielleicht kann ja @hiorgserver mal so ganz grob sagen, wie der Plan dazu aussieht, also sprich wie diese ganzen Sachen umgesetzt werden (bzw. ob überhaupt)…

Siehe Alltag bei dem HiOrg-Server-Team?

Grundsätzlich keine schlechte Idee. Aber was ist mit Vereinen / Verbänden, die nicht so viel Geld haben und das dann nicht dort einsetzen können? :thinking:

3

Blockquote

Blockquote

Ich sehe es so: Wenn HiOrg-Server finanziell von den „stärkeren“ Vereinen für gezielte Verbesserungen besser unterstützt wird, können mehr Entwickler Dinge schneller implementieren. Letztlich führt HiOrg-Server ja immer alle Verbesserungen für ALLE ein (was auch gut so ist). D.h. die etwas schwächeren Vereine würden von der finanziellen Unterstützung an HiOrg automatisch mit partizipieren.

Werden Vorschläge aufgrund der finanziellen Förderung mit mehr Man-Power schneller umgesetzt, hat HiOrg auch wieder Kapazitäten frei um Vorschläge die nicht finanziell gepusht wurden ebenfalls schneller umzusetzen. Es würden also alle Seiten profitieren.

Grundsätzlich ist mir an dieser Stelle noch eines ganz wichtig: Das Team von HiOrg Server macht einen klasse Job und ist jederzeit kurzfristig erreichbar bei Fehlern oder anderem Support! Ich thematisiere hier nur eine gefühlte Überlastung des HiOrg Server Teams und eine eventuelle Lösung dafür. Letztlich ist der Arbeitsvorrat über die Jahre aus meiner Sicht zu groß geworden um es „nach dem alten Entwicklungsmuster“ abzuarbeiten. Die Komplexität des HiOrg Servers ist massiv angestiegen mit Zusatzmodulen, Apps etc. etc.

HiOrg-Informationen über den Plattform-Wechsel bei Apps, die das Team zusätzlich um Monate nach hinten wirft sprechen ebenfalls für sich.

Man könnte sich auch überlegen eine „Task-Force“ ins Leben zu rufen, die temporär alles abarbeitet, bis wieder ein überschaubares Level von vielleicht 200 Verbesserungsvorschlägen erreicht ist.

1 „Gefällt mir“
4

Die meisten der gestellten Fragen haben wir im Bereich „FAQ“ auf der Info-Webseite in einem Übersichtsartikel beantwortet:
https://info.hiorg-server.de/faq/wie-wird-entschieden-welche-funktion-als-naechstes-umgesetzt-wird/

Trotzdem gehe ich hier gerne nochmal auf einige konkrete Fragen/Aussagen ein.

Ein „Voting-Punkte-Online-Shop“ ist uns zu unpersönlich :wink: – Nein, im Ernst: wenn jemand gegen Bezahlung ein Feature (bzw. meist einen ganzen Funktionsbereich) entwickeln lassen will, hat es sich als sehr sinnvoll herausgestellt, die gewünschte Funktionalität vorher persönlich zu besprechen. Auf dieser Basis können wir meist den Aufwand (=Kosten) grob abschätzen, und wenn sich dies mit dem Budget des Nutzers deckt, nach genauer Entwicklungsplanung ein konkretes und verbindliches Angebot (finanziell und zeitlich) erstellen.
Da dieser Prozess allerdings für uns einen erheblichen (Zeit-)Aufwand bedeutet, wurde dieses Vorgehen in der Vergangenheit überwiegend nur bei Anfragen von Dachverbänden eingesetzt, die im Vorfeld bereits mit ihren Gliederungen intern die Bedürfnisse abgestimmt hatten.

Das wäre sicherlich richtig - sofern wir den Plan hätten, alle diese Vorschläge umzusetzen. Danach wäre HiOrg-Server allerdings so komplex, dass es niemand mehr bedienen könnte.
Durch die Annahme eines Vorschlages signalisieren wir eher: „Diese Funktion wäre grundsätzlich sinnvoll, und könnte aus unserer (technischen) Perspektive umgesetzt werden“. Ob sie jedoch tatsächlich umgesetzt wird (nicht nur wann!), entscheidet die Mehrheit der Nutzer durch Vergabe von Voting-Punkten.
Wenn ein Vorschlag jedoch nach 1-2 Jahren keine oder nur sehr wenige Votes erhält, werden wir diesen meist eher nicht umsetzen: auch wenn er (zumindest für den Einreicher) sinnvoll wäre, wird er offensichtlich von den meisten anderen Nutzern nicht benötigt.

Schon jahrelang nicht mehr. Seit Gründung der GmbH vor über 6 Jahren wird das System von mehreren hauptberuflichen Informatikern betreut. Aktuell umfasst unser (Kern-)Team 8 Personen (davon 6 in der Entwicklung tätig) auf 5 Vollzeit-Stellen.
Zu unserer Arbeit gehört allerdings nicht nur die (für die Nutzer sichtbare) Entwicklung neuer Features, sondern auch zu nicht unerheblichen Anteilen der Kundensupport (z.B. 6254 E-Mail Tickets in 2016, Anrufe zählen wir nicht), Umstrukturierung und Optimierung des bestehenden Code (137.000 Zeilen) sowie die Pflege und der ständige Ausbau der Serverlandschaft (aktuell 13 selbst betreute Maschinen in 3 Rechenzentren), damit rund um die Uhr Performance, Sicherheit und Stabilität für das Produktivsystem und unsere interne Infrastruktur zu gewährleistet bleibt.

Zunächst einmal könnte das machbar klingen, aber…

  • gute Entwickler (die einigermaßen fachlich und menschlich in unser Team passen) fallen nicht einfach vom Himmel
  • als verantwortungsvoller Arbeitgeber und Ausbildungsbetrieb lehnen wir es ab, sensbilen Code durch osteuropäische Auftragsprogrammierer mit häufig wechselndem Personal entwickeln zu lassen
  • das bestehende System ist (vor und hinter den Kulissen) inzwischen nicht ganz trivial, so dass ein neues Mitglied in unserem Team zunächst eingearbeitet werden muss. Das kostet Zeit, meistens für zwei Personen.
  • Aufgrund der längeren Lernkurve / Einarbeitung, der entwickelten Kompetenzen, aber auch aus menschlicher Sicht auf die Perspektive des Arbeitnehmers, sind wir sehr daran interessiert unsere Mitarbeiter langfristig im Team zu behalten. Um dies zu ermöglichen, benötigen wir natürlich entsprechende (finanzielle) Planungssicherheit - diese ist mit kurzfristigen Finanzierungen einzelner Features leider nicht gegeben.

Trotzdem gab es für Bestandskunden (mit einer einzigen Ausnahme) noch nie eine Preiserhöhung… :thinking:

Vielen Dank! Diese Aussage motiviert unser gesamtes Team, dafür strengen wir uns gerne täglich an! :star_struck:

2 „Gefällt mir“
5

alles in allem verständlich - sowohl der gefühlte Frust auf HiOrg-Seite und auf der anderen Seite auch der auf Entwickler-Seite.

Dennoch würde ich sagen…
1.) Ich habe gehört, dass viele die kostenlose Version nutzen. Das erzeugt bei Vorschlägen im Support Kosten, bringt aber kein Geld ein. Somit ein Ungleichgewicht, was zu ungunsten der Supporter fällt.

2.) Zahlende Kunden sollten schon etwas Vorteil haben… haben sie auch, da Votingpunkte aufgefüllt werden!

3.) Trotzdem finde ich schon, dass Features, die angenommen werden und nur wenig Zeit in Anspruch nehmen auch irgendwann mal (und zwar nicht etliche Jahre später) umgesetzt werden müssen oder es muss ganz klar gemacht werden, dass der Vorschlag ab JETZT nicht mehr weiter implementiert wird - quasi wie im Forum, wo ein Thread ab einem gewissen Punkt geschlossen wurde.

4.) Fehler melden mal hier mal da… auch ich mach das gerne mal falsch… aber es gehört bei einem solch Großen System ein “vernünftiges” Fehlermangement dazu. Da gehören Pflichtmeldungen, Screenshots dazu und abschließend auch die Rückmeldung, dass etwas bearbeitet wurde. Darüber kann man dann einsehen, ob mein Fehler in Bearbeitung gegangen ist oder schon geclosed wurde. Transparenz ist hier ein großer Punkt, der zu Unzufriedenheit führt, weil es Intransparent wirkt - nicht immer ist!

5.) Ob ein Feature wesentlich ist oder nicht, ist auch eher subjektiv. Daher finde ich, dass eine bezahlte Implementierung auch von einer anderen Gruppe gemacht werden muss als von den normalen Programmieren… sonst würden die nämlich ihren Aufgaben nicht mehr gerecht werden.

Grundsätzlich fühlt es sich tatsächlich so an, dass aufgrund der rasant gewachsenen Server-Zahl der Aufwand exponentiell angestiegen ist, Personal nicht so schnell verfügbar ist. Und genau dann muss man gegenagieren.
Wie gesagt, es muss zwei-gleisig gearbeitet werden, wenn es Bezahl-Implementierungen geben soll.

Team a --> nur Bezahlte Apps, usw.
Team b --> Vorschlagsverwaltung, usw. --> was angenommen wurde, muss auch zeitnah umgesetzt werden oder z.B. aufgrund von Zeitmangel auch mal abgelehnt werden. Dann kann ich mir ja überlegen, ob es mir so wichtig ist, dass ich damit Team a gegen Geld beauftragen möchte.

Grundsätzlich finde ich es auch richtig, dass man Apps und Extensions aus Team a auch für alle bereitstellt (Sozialprinzip). Man beschleunigt eigentlich nur die eigene Wunschumsetzung.

Ansosnten kann ich @frank unterstützen… ihr macht einen guten Job!!!

1 „Gefällt mir“
6

Tatsächlich bieten wir den persönlichen Support per E-Mail, Telefon oder Forum für alle Nutzer des HiOrg-Server gleichermaßen an, unabhängig von der genutzten Version. Trotzdem erreichen uns 9 von 10 Support-Anfragen von Nutzern einer kostenpflichtigen Version, so dass wir hier kein Ungleichgewicht oder eine mögliche Benachteiligung sehen.

Vor dem Hintergrund, dass die Anzahl der Wünsche in den letzten (1-2) Jahren deutlich stärker gestiegen ist als zuvor und damit das geschilderte Problem häufiger auftritt, haben wir unser Vorgehen in solchen Fällen nochmals intern diskutiert. Wir werden in Kürze den Aufwand zu jedem Vorschlag neu ermitteln, und dann zukünftig konsequenter und öfter die Wunschliste durchgehen, um Vorschläge wieder zu streichen (und den Einreicher darüber zu informieren), wenn die Umsetzung unrealistisch erscheint.

Genau dieses Management von Fehlern und Wünschen haben wir in der „Wunschliste“ implementiert. Meldungen, die uns hier erreichen, können am effektivsten dem jeweiligen Entwickler zugewiesen werden, und gleichzeitig hat der einreichende Nutzer hier immer einen transparenten Einblick über den Status seiner Meldung.
Daher bitten wir immer wieder darum, Wünsche und mögliche Fehler nur dort (im HiOrg-Server: Menü „System - Wunschliste“) zu melden, und möglichst exakt zu formulieren sowie dort auch Screenshots einzureichen.

Bei der inzwischen erreichten Komplexität des Systems, braucht ein Entwickler erhebliche Zeit um sich in einen neuen Bereich einzuarbeiten. Jeder Mitarbeiter hat inzwischen „Kerngebiete“ in welchen er sich besonders gut auskennt, effizienter arbeiten kann und dabei weniger Fehler macht. Vor diesem Hintergrund finden wir es strategisch sinnvoller, die Verteilung von Aufgaben an Entwickler nach diesen Spezialgebieten zu organisieren, als nach Art der Finanzierung des Projektes.
Dies haben wir auch in den FAQ kürzlich mal erklärt:

https://info.hiorg-server.de/faq/wie-wird-entschieden-welche-funktion-als-naechstes-umgesetzt-wird/

7

Hallo zusammen,

ich habe hier nun auch lange still mitgelesen, musste in den letzten Monaten aber feststellen, dass fast ausschließlich Fehler behoben aber kaum neuen Funktionen implementiert wurden. Aus diesem Grund werden wir uns leider auch spätestens zum nächsten Abrechnungszeitraum vom HiOrg-Server trennen müssen. Wirklich schade, aber gefühlt ist das Projekt hier eingeschlafen.

8

Hallo NieD,

es ist schade, wenn Sie das so sehen - aber zum Glück ist in Wirklichkeit niemand von unserem Entwickler-Team eingeschlafen :sleeping: :sleeping_bed: :wink:

In der ersten Jahreshälfte konnten wir relativ viele Updates in kurzer Abfolge veröffentlichen (siehe die jeweiligen Ankündigungen auf dem Admin-Blog), und im Herbst ein größeres Auftrags-Projekt für einen großen bayrischen Kreisverband beenden (wovon alle anderen Nutzer nicht viel sehen können).

Seit Sommer arbeiten wir hochmotiviert mit einem Team an einer komplett neuen Mobilgeräte-App, gleichzeitig startet ein anderes Team derzeit mit einer kompletten Überarbeitung der Funktion “Dienstanforderung”.
Dieses (vergleichsweise große) Projekt ist notwendig, um diesen Bereich auf eine zeitgemäßere Architektur zu bringen. Neben einem kompletten Rewrite des Codes “hinter den Kulissen”, wird es dort viele kleinere Neuerungen geben, die wir aus den Anforderungen der “Wunschliste” entnommen haben.

Die Arbeit an diesen beiden großen Projekten will sorgfältig geplant, implementiert und getestet sein - das kann niemand in zwei Tagen “aus dem Ärmel schütteln”. In dieser Zeit sieht man leider aus Ihrer Perspektive des Nutzers nicht viel vom emsigen Treiben in der Entwicklung.
Aber wenn Sie Ihre Augen und Ohren gut offen halten, entdecken Sie vielleicht schon im Januar einen ersten Testballon vom App-Team (psst ! :zipper_mouth_face:)

(Vor-)Weihnachtliche Grüße :christmas_tree:
Christoph

9

Da meine Anfrage thematisch passt, habe ich einmal diesen alten Thread ausgegraben um keinen neuen anfangen zu müssen.

Nach Durchsicht des Forums und des verlinkten Blogposts erschliesst sich mir dennoch nicht ganz, wie die Wunschliste priorisiert. Ich hätte erwartet, dass diese nach Votingpunkten sortiert wird, und dann innerhalb dieser Sortierung ggf. einzelne Vorschläge vorgezogen werden aufgrund der beschriebenen Faktoren (Fehler, thematischer Zusammenhang, fachliche Vertiefung der Entwickler).

Da ich aber nun sehe dass die „TOP 4“ der Vorschläge Votingpunkte von 544 bis 83 aufweist, auf Platz 35 jedoch 485 Votingpunkte abgesetzt wurden und auf Platz 66 sogar 502 Punkte, scheint es noch andere Faktoren zu geben, die die reine Darstellung der Liste beeinflusst.

Welche sind dies?
Ich frage vor dem Hintergrund, da die beiden genannten Vorschläge ansonsten rein vom Voting der Nutzer deutlch weiter vorne liegen müsste.

1 „Gefällt mir“
10

Hallo,

Bei der Berechnung der Rangfolge in der Wunschliste wirken mehrere Faktoren mit. Der Wichtigste ist ein Quotient aus Votingpunkten und grob geschätztem Aufwand für die Umsetzung. Damit haben auch kleine Wünsche, die in einem Tag umgesetzt wären, aber nur 50 Votes haben, eine Chance gegen die richtig großen Wünsche, die mehrere Hundert Votingpunkte haben und deren Umsetzung das ganze Entwicklungsteam für ein halbes Jahr binden würden. Daneben fließt mit ein, wieviele unterschiedliche Kunden einem Vorschlag Voting-Punkte geben - damit nicht ein einzelner Kunde, der über Jahre eine große Anzahl Punkte angesammelt hat, einen Wunsch fast im Alleingang nach oben bringt, der den Großteil der Kunden nicht interessiert und ggf. bei denen nur die Bedienoberfläche unübersichtlicher macht. Zusätzlich bewertet der Algorithmus Voting-Punkte in jüngerer Zeit etwas höher als Punkte, die vor Jahren vergeben wurden. Das soll uns helfen, Wünsche von akutem, großem Interesse von denen, die über einen längeren Zeitraum immer mal wieder einen Voting-Punkt erhalten haben, zu unterscheiden.

Grundsätzlich dient uns die Wunschliste inzwischen aber mehr als Richtschnur, was unseren Kunden auf dem Herzen liegt, als dass wir stoisch die Punkte von oben herab abarbeiten. Bei der Auswahl zukünftiger Erweiterungen haben wir grob gesagt das obere Viertel der Liste im Blick, lassen uns auch vom Dialog mit Kunden (Support, Schulungen, …) und unserem Blick auf die „Branche“ der Hilfsorganisationen und Kurse-Anbietern leiten.

2 „Gefällt mir“