Beurteilung von Sachverstand
1. November 2020 19:02
Hallo Gemeinde,
ich möchte mich heute mit einem Thema an Euch wenden, das, so denke ich, eher den Sachverstand als Fachverstand anspricht. Es geht um zwei Fragen: Gibt mein hier geschildertes Beispiel einen Einblick in den Level des Sachverstand einer Ressource und seht Ihr eine wie unten beschriebene Ressource als befähigt an, lenkend und leitend - insbesondere auch projektleitend - tätig sein zu dürfen.
Ein NAV-Endkunde befindet sich in einer schwierigen Situtation, ist vor einem halben Jahr ohne Integrationstest in den Echtstart getrieben worden. Seit dieser Zeit ist "Land unter". Der NAV-Standard wurde kaum genutzt, es wurde programmiert, programmiert, programmiert und das Unternehmen hat ein 7köpfiges ERP-Team, bestehend aus 2 internen und 5 externen Ressourcen zusammengestellt, um über die Runden zu kommen. Um die diesen Stand verursachende Ressource geht es NICHT, diese ist bereits nicht mehr vorhanden. Es wurde eine unmenge Tabellen verbraucht, Pages usw. analog dazu, ein ziemlich heilloses Durcheinander. Es wird angedacht, ein neues Projekt aufzusetzen.
Die festangestellten beiden Ressourcen kümmern sich u.a. um den Objekttransport der Korrekturentwicklungen, hier das 3Schichtsystem DEV-TEST-PROD. Die Objektstände der drei Datenbanken laufen auseinander. Die Ressource, die den Objekttransport durchführt hat sich folgende Regel ausgedacht (Zitat): "Was an Objekten in der Test und/oder Prod ist, ist eigentlich nicht relevant. Die Objekte müssen auf allen Stufen vorhanden sein." Das bedeutet, wenn jemand eine in der DEV NICHT existierende Tabellennummer für sich neu verwendet, und diese Nummer in der TEST jedoch existiert (selbstverständlich mit einem "alten" Namen), dann wird die neue Tabelle beim Transport ungefragt überschrieben werden. Ohne Prüfung, Rücksprache, Abklärung.
Im konkreten Fall wurde eine Tabelle, die bereits in DEV/TEST/PROD in Verwendung war durch eine Neuentwicklung eines bestehenden Bereichs ersetzt. Nennen wir diese Arbeit "1. Projekt/Ticket". Es entstand eine neue Tabelle mit anderer Nummer, nach dem Transport muss noch ein Report für Datenmapping Alttabelle -> Neutabelle durchgeführt werden. Nach dem Transport von DEV in TEST wurde die Alttabelle in DEV gelöscht - es sind kaum noch freie Tabellennr. vorhanden - und bestand noch in der TEST und auch PROD, da im Tagesgeschäft noch mit der Altenwicklung gearbeitet werden muss, bis der Transport in PROD stattfindet. Die Neuentwicklung wurde noch nicht in PROD transportiert. Einen Tag später wurde die Nummer der Alttabelle von einer Ressource in DEV verwendet (2. Projekt/Ticket)und am gleichen Tag in die TEST transportiert. Dort existierte die Alttabelle noch (mit Daten) und wurde mit FORCE überschrieben. Demnach wurden zwei Projekte/Tickets kurz hintereinander geschoben, zu diesem Zeitpunkt war der Transport von 1. Projekt/Ticket in PROD wie angegeben noch nicht durchgeführt.
Die dem Transporteur übergeordnete festangestellte Ressource, die alles NAV-seitige steuert (der Abteilungsleiter ist kein NAVler), bestätigt diese Vorgehensweise mit "Die neue Tabelle kann in der DEV bereits neu vergeben werden und schon in die Test eingespielt werden. Allerdings darf dieses neue Projekt erst nach dem Paket von oben in das Echt System gehen."
Noch ein eventueller Hinweis zur Beurteilung: Gleichzeitig saß eine freiberufliche Ressource eine Woche lang ohne Arbeit im eigenen Büro.
Ich bin seit mehren Jahrzehnten im Beruf und würde gerne Eure Einschätzung hören, wie Ihr zu der geschilderten Thematik als auch zur Befähigung von Ressourcen bzgl. deren Sachverstand steht mit dem Hinweis, dass dies nur ein Beispiel von mehreren ist.
Grüsse an alle
Achim
ich möchte mich heute mit einem Thema an Euch wenden, das, so denke ich, eher den Sachverstand als Fachverstand anspricht. Es geht um zwei Fragen: Gibt mein hier geschildertes Beispiel einen Einblick in den Level des Sachverstand einer Ressource und seht Ihr eine wie unten beschriebene Ressource als befähigt an, lenkend und leitend - insbesondere auch projektleitend - tätig sein zu dürfen.
Ein NAV-Endkunde befindet sich in einer schwierigen Situtation, ist vor einem halben Jahr ohne Integrationstest in den Echtstart getrieben worden. Seit dieser Zeit ist "Land unter". Der NAV-Standard wurde kaum genutzt, es wurde programmiert, programmiert, programmiert und das Unternehmen hat ein 7köpfiges ERP-Team, bestehend aus 2 internen und 5 externen Ressourcen zusammengestellt, um über die Runden zu kommen. Um die diesen Stand verursachende Ressource geht es NICHT, diese ist bereits nicht mehr vorhanden. Es wurde eine unmenge Tabellen verbraucht, Pages usw. analog dazu, ein ziemlich heilloses Durcheinander. Es wird angedacht, ein neues Projekt aufzusetzen.
Die festangestellten beiden Ressourcen kümmern sich u.a. um den Objekttransport der Korrekturentwicklungen, hier das 3Schichtsystem DEV-TEST-PROD. Die Objektstände der drei Datenbanken laufen auseinander. Die Ressource, die den Objekttransport durchführt hat sich folgende Regel ausgedacht (Zitat): "Was an Objekten in der Test und/oder Prod ist, ist eigentlich nicht relevant. Die Objekte müssen auf allen Stufen vorhanden sein." Das bedeutet, wenn jemand eine in der DEV NICHT existierende Tabellennummer für sich neu verwendet, und diese Nummer in der TEST jedoch existiert (selbstverständlich mit einem "alten" Namen), dann wird die neue Tabelle beim Transport ungefragt überschrieben werden. Ohne Prüfung, Rücksprache, Abklärung.
Im konkreten Fall wurde eine Tabelle, die bereits in DEV/TEST/PROD in Verwendung war durch eine Neuentwicklung eines bestehenden Bereichs ersetzt. Nennen wir diese Arbeit "1. Projekt/Ticket". Es entstand eine neue Tabelle mit anderer Nummer, nach dem Transport muss noch ein Report für Datenmapping Alttabelle -> Neutabelle durchgeführt werden. Nach dem Transport von DEV in TEST wurde die Alttabelle in DEV gelöscht - es sind kaum noch freie Tabellennr. vorhanden - und bestand noch in der TEST und auch PROD, da im Tagesgeschäft noch mit der Altenwicklung gearbeitet werden muss, bis der Transport in PROD stattfindet. Die Neuentwicklung wurde noch nicht in PROD transportiert. Einen Tag später wurde die Nummer der Alttabelle von einer Ressource in DEV verwendet (2. Projekt/Ticket)und am gleichen Tag in die TEST transportiert. Dort existierte die Alttabelle noch (mit Daten) und wurde mit FORCE überschrieben. Demnach wurden zwei Projekte/Tickets kurz hintereinander geschoben, zu diesem Zeitpunkt war der Transport von 1. Projekt/Ticket in PROD wie angegeben noch nicht durchgeführt.
Die dem Transporteur übergeordnete festangestellte Ressource, die alles NAV-seitige steuert (der Abteilungsleiter ist kein NAVler), bestätigt diese Vorgehensweise mit "Die neue Tabelle kann in der DEV bereits neu vergeben werden und schon in die Test eingespielt werden. Allerdings darf dieses neue Projekt erst nach dem Paket von oben in das Echt System gehen."
Noch ein eventueller Hinweis zur Beurteilung: Gleichzeitig saß eine freiberufliche Ressource eine Woche lang ohne Arbeit im eigenen Büro.
Ich bin seit mehren Jahrzehnten im Beruf und würde gerne Eure Einschätzung hören, wie Ihr zu der geschilderten Thematik als auch zur Befähigung von Ressourcen bzgl. deren Sachverstand steht mit dem Hinweis, dass dies nur ein Beispiel von mehreren ist.
Grüsse an alle
Achim
Re: Beurteilung von Sachverstand
1. November 2020 20:33
Hallo,
ich denke wir sind schon zu lange im Beruf
Ich bevorzuge eigentlich erst ein mal zu verstehen, was der Kunde eigentlich macht, und wo er hin möchte. Dabei ist das größte Problem eigentlich zu verstehen was der Kunde eigentlich sagen will und was das für Konsequenzen hat. (siehe hier)
Leider stellen sich aber viele Entscheidungsträger die Einführung eines ERPs sehr einfach vor. Da werden dann auch Funktionalitäten die die Flexibilität des Unternehmens einschränken gefordert, die völlig von der vorhandenen etablierten und vor allen Dingen funktionierenden Arbeitsweise abweicht.
Außerdem will man oft erst mal anfangen, damit man Erfolge sieht.-> "Um die Sonderfälle kümmern wir uns später". Da aber die "karierten Maiglöckchen" ganze Konzepte zu Einsturz bringen, sollte man versuchen zumindest, diese Sonderfälle bereits zu Beginn ermitteln. Ob und wie man diese Fälle löst, muss man dann bewerten.
Grundsätzlich würde ich allerdings in deinem Fall versuchen, die einzelnen Programmstände möglichst kompatibel zu halten. D.h. es sollte keine überschneidenden Objekte geben.
Gruß Fiddi
ich denke wir sind schon zu lange im Beruf
Ich bevorzuge eigentlich erst ein mal zu verstehen, was der Kunde eigentlich macht, und wo er hin möchte. Dabei ist das größte Problem eigentlich zu verstehen was der Kunde eigentlich sagen will und was das für Konsequenzen hat. (siehe hier)
Leider stellen sich aber viele Entscheidungsträger die Einführung eines ERPs sehr einfach vor. Da werden dann auch Funktionalitäten die die Flexibilität des Unternehmens einschränken gefordert, die völlig von der vorhandenen etablierten und vor allen Dingen funktionierenden Arbeitsweise abweicht.
Außerdem will man oft erst mal anfangen, damit man Erfolge sieht.-> "Um die Sonderfälle kümmern wir uns später". Da aber die "karierten Maiglöckchen" ganze Konzepte zu Einsturz bringen, sollte man versuchen zumindest, diese Sonderfälle bereits zu Beginn ermitteln. Ob und wie man diese Fälle löst, muss man dann bewerten.
Grundsätzlich würde ich allerdings in deinem Fall versuchen, die einzelnen Programmstände möglichst kompatibel zu halten. D.h. es sollte keine überschneidenden Objekte geben.
Gruß Fiddi
Re: Beurteilung von Sachverstand
2. November 2020 00:44
Re: Beurteilung von Sachverstand
2. November 2020 09:33
Ich frage mich, warum nicht einfach neue Tabellen gekauft werden - klar, kostet es ein wenig(!) Geld, aber mit 10 weiteren Tabellen könnte man sicherlich mehr anfangen.
Wie fiddi schon sagte, sollten die Programmstände möglichst gleich sein - es kann aus meiner bescheidenen Sicht nicht sein, dass eine Tabelle aus dem Dev ins Test geschoben wird, dann kurz danach die
Tabelle aus dem Dev überschrieben wurde (ggf. war der Test ja auch noch garnicht abgeschlossen), wobei davon noch nichts im Prod war.
Man muss dann eben einfach mal in den sauren Apfel beißen und die ursprüngliche Entwicklung abwarten, wenn keine freien Objekte mehr vorhanden sind.
Hier ist doch schon das Problem - natürlich ist es relevant, was in den jeweiligen Systemen ist und ich kann nicht einfach nach Lust und Laune einspielen und überspielen.
Ich muss ehrlich gestehen, dass ich nicht verstehe, was dieser Hinweis mit der Sachlage zu tun hat - außer das vll. zu viele "Ressourcen" eingesetzt sind.
Ich bin erst seit 10 Jahren dabei, kann also defintiv nicht auf jahrzehnte lange Erfahrungen zurückgreifen, allerdings ist mir in den 10 Jahren aufgefallen, dass wenn zu viele Externe (ich rede hier nicht von NAV-Partner und Kunde) dabei sind, sich
das Projekt oft ...sagen wir... verkompliziert - von den Kosten wollen wir da auch mal garnicht sprechen.
Ich möchte niemanden seinen Sachverstand absprechen, aber manchmal sollte die Situation entsprechend beobachtet und darauf reagiert werden (und zwar im Sinne des Kunden), anstatt sich profilieren zu wollen.
Wie fiddi schon sagte, sollten die Programmstände möglichst gleich sein - es kann aus meiner bescheidenen Sicht nicht sein, dass eine Tabelle aus dem Dev ins Test geschoben wird, dann kurz danach die
Tabelle aus dem Dev überschrieben wurde (ggf. war der Test ja auch noch garnicht abgeschlossen), wobei davon noch nichts im Prod war.
Man muss dann eben einfach mal in den sauren Apfel beißen und die ursprüngliche Entwicklung abwarten, wenn keine freien Objekte mehr vorhanden sind.
AchimMueller hat geschrieben:"Was an Objekten in der Test und/oder Prod ist, ist eigentlich nicht relevant. Die Objekte müssen auf allen Stufen vorhanden sein."
Das bedeutet, wenn jemand eine in der DEV NICHT existierende Tabellennummer für sich neu verwendet, und diese Nummer in der TEST jedoch existiert (selbstverständlich mit einem "alten" Namen), dann wird die neue Tabelle beim Transport ungefragt überschrieben werden. Ohne Prüfung, Rücksprache, Abklärung.
Hier ist doch schon das Problem - natürlich ist es relevant, was in den jeweiligen Systemen ist und ich kann nicht einfach nach Lust und Laune einspielen und überspielen.
AchimMueller hat geschrieben:Noch ein eventueller Hinweis zur Beurteilung: Gleichzeitig saß eine freiberufliche Ressource eine Woche lang ohne Arbeit im eigenen Büro.
Ich muss ehrlich gestehen, dass ich nicht verstehe, was dieser Hinweis mit der Sachlage zu tun hat - außer das vll. zu viele "Ressourcen" eingesetzt sind.
Ich bin erst seit 10 Jahren dabei, kann also defintiv nicht auf jahrzehnte lange Erfahrungen zurückgreifen, allerdings ist mir in den 10 Jahren aufgefallen, dass wenn zu viele Externe (ich rede hier nicht von NAV-Partner und Kunde) dabei sind, sich
das Projekt oft ...sagen wir... verkompliziert - von den Kosten wollen wir da auch mal garnicht sprechen.
Ich möchte niemanden seinen Sachverstand absprechen, aber manchmal sollte die Situation entsprechend beobachtet und darauf reagiert werden (und zwar im Sinne des Kunden), anstatt sich profilieren zu wollen.
Re: Beurteilung von Sachverstand
2. November 2020 09:42
Hallo,
hinderlich ist oft auch ein Abteilungsdenken beim Kunden.
Das Lager sagt, das die im Verkauf/Einkauf keine Ahnung haben, was eigentlich in der Firma passiert, und umgekehrt natürlich genauso. Und leider haben beide Recht.
Aus diesem Grund ist niemand bereit zu verstehen, dass eine Firma nur als Ganzes funktionieren kann.
Für ein Projekt bedarf es eines Teams, das bereit ist, die Zusammenhänge zu verstehen und zwar von eigenen Lieferenten bis zum eigenen Kunden. Und zwar soweit wie möglich bevor man anfängt etwas zu programmieren.
Gruß Fiddi
hinderlich ist oft auch ein Abteilungsdenken beim Kunden.
Das Lager sagt, das die im Verkauf/Einkauf keine Ahnung haben, was eigentlich in der Firma passiert, und umgekehrt natürlich genauso. Und leider haben beide Recht.
Aus diesem Grund ist niemand bereit zu verstehen, dass eine Firma nur als Ganzes funktionieren kann.
Für ein Projekt bedarf es eines Teams, das bereit ist, die Zusammenhänge zu verstehen und zwar von eigenen Lieferenten bis zum eigenen Kunden. Und zwar soweit wie möglich bevor man anfängt etwas zu programmieren.
Gruß Fiddi
Re: Beurteilung von Sachverstand
2. November 2020 09:55
Prinzipiell habt ihr schon einmal zwei hervorragende Voraussetzungen:
a) Ihr arbeitet mit DEV/TEST/PROD, so dass die Keyuser die Entwicklungen in Ruhe testen können, ohne dass die Entwickler "dazwischenfunken".
b) Ihr habt einen führenden Objektstand (DEV vor TEST, TEST vor PROD).
Gerade, wenn es mal einen Objekt-Konflikt zwischen den Datenbanken gibt, und man dadurch Anpassungen verliert, ist es umso wichtiger, an diesem Konzept festzuhalten, damit alle Beteiligten daraus lernen können.
In dem Moment ist das natürlich ein mehr oder weniger schwerwiegendes Problem, aber nur durch solche Fehler lernt man. ("Lernen durch Schmerzen")
Das ist bei uns in der Vergangenheit auch schon zweimal passiert, glücklicherweise hatte es in beiden Fällen nur "kosmetische" Auswirkungen, aber alle Beteiligten hatten daraus gelernt.
Es bringt auch nichts, einen Schuldigen zu suchen, denn das behebt das Problem nicht.
Wir haben auch eine extrem stark individualisierte Datenbank (NAV 2017), jedoch haben wir uns im Vorfeld genaue Gedanken gemacht, wie wir die zahlreichen Anforderungen abbilden wollen.
a) Möglichst universell halten
Anforderungen, die anfangs nur vor "Verkaufsaufträge" gelten, könnten später auch für andere Belegarten und sogar andere Bereiche (Einkauf, Service, Umlagerung, Produktion) benötigt werden.
Aus diesem Grund arbeiten wir sehr viel mit RecordRef & Co.
b) Schon bei der Spezifikation an a) denken. (Insbesondere auch an die Reklamationen, bei denen alles "umgekehrt" läuft.)
c) Nummern-Konzept für die Objekte und Felder ausarbeiten.
Welche Bereiche (Fibu, Verkauf, Einkauf, Service, Umlagerung, Produktion, Personal, ...) bekommen welche Nummernbereiche zugewiesen?
Bei international tätigen Unternehmen auch Nummernbereiche für weltweite sowie landesspezifische Anforderungen berücksichtigen.
Wir gehen sogar so weit, dass wir unsere Individualfelder einmal definiert in allen Datenbanken und allen Tabellen immer mit derselben Feld-ID anlegen.
(Das hat unzählige Vorteile, die man meisten erst später entdeckt.)
d) "Temporäre" Objekte sind bei uns verboten
Einzige Ausnahme: Die Objekt-ID 50050 haben wir für Testzwecke definiert. Die darf jeder nach belieben ändern und diese wird niemals in die nächste Datenbank übertragen.
Wenn Objekt-IDs im Laufe der Zeit nicht mehr benötigt werden, dann werden diese in der DEV-Datenbank entsprechend gekennzeichnet und werden aus der Lizenz herausgenommen.
Dadurch werden die Objekte in der Lizenz wieder frei und können anderen Nummernbereichen zugewiesen werden.
Da dieser (nicht mehr benötigten) Anpassung ein bestimmter Nummernbereich zugewiesen wurde, wird dieser zukünftig auch nicht wieder verwendet. (Umgekehrt betrachtet wurde ja dieser Nummernbereich dieser Funktionalität zugeordnet.)
e) Anforderungen müssen in einer speziellen Art und Weise formuliert werden, damit genau klar wird, wer was warum benötigt, und unter welchen Bedingungen die Anpassung als vollständig umgesetzt gilt.
Wer: Wenn man die Abteilung und den Mandanten kennt, ergibt sich schon ein gewisser Kontext, in dem die Anforderung betrachtet werden kann.
Was: Der eigentliche Anpassungswunsch.
Warum: Welchen Vorteil bringt es der Abteilung bzw. dem Unternehmen?
Akzeptanzkriterien: Damit gibt es keine Ausreden wie "Das hatte ich aber so-und-so gemeint." bzw. "Da habt ihr aber noch das-und-das vergessen."
Was nicht geschrieben wurde, ist keine Anforderung.
Ich hoffe, etwas geholfen zu haben.
a) Ihr arbeitet mit DEV/TEST/PROD, so dass die Keyuser die Entwicklungen in Ruhe testen können, ohne dass die Entwickler "dazwischenfunken".
b) Ihr habt einen führenden Objektstand (DEV vor TEST, TEST vor PROD).
Gerade, wenn es mal einen Objekt-Konflikt zwischen den Datenbanken gibt, und man dadurch Anpassungen verliert, ist es umso wichtiger, an diesem Konzept festzuhalten, damit alle Beteiligten daraus lernen können.
In dem Moment ist das natürlich ein mehr oder weniger schwerwiegendes Problem, aber nur durch solche Fehler lernt man. ("Lernen durch Schmerzen")
Das ist bei uns in der Vergangenheit auch schon zweimal passiert, glücklicherweise hatte es in beiden Fällen nur "kosmetische" Auswirkungen, aber alle Beteiligten hatten daraus gelernt.
Es bringt auch nichts, einen Schuldigen zu suchen, denn das behebt das Problem nicht.
Wir haben auch eine extrem stark individualisierte Datenbank (NAV 2017), jedoch haben wir uns im Vorfeld genaue Gedanken gemacht, wie wir die zahlreichen Anforderungen abbilden wollen.
a) Möglichst universell halten
Anforderungen, die anfangs nur vor "Verkaufsaufträge" gelten, könnten später auch für andere Belegarten und sogar andere Bereiche (Einkauf, Service, Umlagerung, Produktion) benötigt werden.
Aus diesem Grund arbeiten wir sehr viel mit RecordRef & Co.
b) Schon bei der Spezifikation an a) denken. (Insbesondere auch an die Reklamationen, bei denen alles "umgekehrt" läuft.)
c) Nummern-Konzept für die Objekte und Felder ausarbeiten.
Welche Bereiche (Fibu, Verkauf, Einkauf, Service, Umlagerung, Produktion, Personal, ...) bekommen welche Nummernbereiche zugewiesen?
Bei international tätigen Unternehmen auch Nummernbereiche für weltweite sowie landesspezifische Anforderungen berücksichtigen.
Wir gehen sogar so weit, dass wir unsere Individualfelder einmal definiert in allen Datenbanken und allen Tabellen immer mit derselben Feld-ID anlegen.
(Das hat unzählige Vorteile, die man meisten erst später entdeckt.)
d) "Temporäre" Objekte sind bei uns verboten
Einzige Ausnahme: Die Objekt-ID 50050 haben wir für Testzwecke definiert. Die darf jeder nach belieben ändern und diese wird niemals in die nächste Datenbank übertragen.
Wenn Objekt-IDs im Laufe der Zeit nicht mehr benötigt werden, dann werden diese in der DEV-Datenbank entsprechend gekennzeichnet und werden aus der Lizenz herausgenommen.
Dadurch werden die Objekte in der Lizenz wieder frei und können anderen Nummernbereichen zugewiesen werden.
Da dieser (nicht mehr benötigten) Anpassung ein bestimmter Nummernbereich zugewiesen wurde, wird dieser zukünftig auch nicht wieder verwendet. (Umgekehrt betrachtet wurde ja dieser Nummernbereich dieser Funktionalität zugeordnet.)
e) Anforderungen müssen in einer speziellen Art und Weise formuliert werden, damit genau klar wird, wer was warum benötigt, und unter welchen Bedingungen die Anpassung als vollständig umgesetzt gilt.
Wer: Wenn man die Abteilung und den Mandanten kennt, ergibt sich schon ein gewisser Kontext, in dem die Anforderung betrachtet werden kann.
Was: Der eigentliche Anpassungswunsch.
Warum: Welchen Vorteil bringt es der Abteilung bzw. dem Unternehmen?
Akzeptanzkriterien: Damit gibt es keine Ausreden wie "Das hatte ich aber so-und-so gemeint." bzw. "Da habt ihr aber noch das-und-das vergessen."
Was nicht geschrieben wurde, ist keine Anforderung.
Ich hoffe, etwas geholfen zu haben.
Re: Beurteilung von Sachverstand
2. November 2020 10:07
Hallo,
damit Punkt e) erfolgreich durchgeführt werden kann, müssen aber alle Betroffenen dazu gehört/beachtet werden, sonst funktioniert die neue Funktionalität im Verkauf hervorragend, das Lager kann sie nur nicht umsetzen.
Gruß Fiddi
damit Punkt e) erfolgreich durchgeführt werden kann, müssen aber alle Betroffenen dazu gehört/beachtet werden, sonst funktioniert die neue Funktionalität im Verkauf hervorragend, das Lager kann sie nur nicht umsetzen.
Gruß Fiddi
Re: Beurteilung von Sachverstand
2. November 2020 10:52
Aus diesem Grund haben wir bei uns ein vierstufiges Benutzerkonzept für die Anforderungen aufgebaut:
1. "End-Anwender": Wendet sich mit seinem Verbesserungsvorschlag an seinen Abteilungs-Keyuser bzw. dessen stellvertretenden Abteilungs-Keyuser
2. Abteilungs-Key-User: Erkennt und klärt Interessens-Konflikte mit anderen Abteilungen und formuliert die Anforderung
3. NAV-Consultant: Prüft auf ungeklärte Interessens-Konflikte, sowie Kompatibilität der Anforderung zu der (vom Unternehmen) gewünschten Arbeitsweise, und formuliert die technische Spezifikation.
4. NAV-Developer: Prüft die technische Spezifikation auf Widersprüche und Konflikte. Setzt die Anforderung um.
Anschließend erfolgt der Test sowie die Freigabe:
[DEV-Datenbank]
1. Developer-Test: Derjenige, der die Anforderung programmiert hat, testet seine Anpassung gegen die technische Spezifikation
2. Lead-Developer-Test: Prüft die Anpassung des Developers auf Einhaltung der internen Entwicklungsrichtlinien (C/AL-Guideline, Dokumentation, Nummernbereiche, ...) und führt die Auslieferungen durch.
[TEST-Datenbank]
3. Conultant-Test: Prüft die Anpassungen gegen die vom Key-User aufgeführten Akzeptanz-Kriterien.
4. Key-User-Test: Prüft die Anpassungen und erteilt die Freigabe zur Auslieferung in die PROD-Datenbank.
Das klingt jetzt im ersten Augenblick nach viel Bürokratie, erweist sich aber langfristig als gut investierte Zeit, da es dringende Fehlerkorrekturen in der PROD-Datenbank bereits im Vorfeld verhindert.
Ich hatte ich meiner Zeit bei den Systemhäusern schon häufig erlebt, dass man "keine Zeit für anständige Spezifikation, Programmierung, Dokumentation" hat, aber "unendlich viel Zeit für die Fehlerkorrekturen".
"Ich habe keine Zeit, meine stumpfe Axt zu schärfen, denn ich muss Bäume fällen."
1. "End-Anwender": Wendet sich mit seinem Verbesserungsvorschlag an seinen Abteilungs-Keyuser bzw. dessen stellvertretenden Abteilungs-Keyuser
2. Abteilungs-Key-User: Erkennt und klärt Interessens-Konflikte mit anderen Abteilungen und formuliert die Anforderung
3. NAV-Consultant: Prüft auf ungeklärte Interessens-Konflikte, sowie Kompatibilität der Anforderung zu der (vom Unternehmen) gewünschten Arbeitsweise, und formuliert die technische Spezifikation.
4. NAV-Developer: Prüft die technische Spezifikation auf Widersprüche und Konflikte. Setzt die Anforderung um.
Anschließend erfolgt der Test sowie die Freigabe:
[DEV-Datenbank]
1. Developer-Test: Derjenige, der die Anforderung programmiert hat, testet seine Anpassung gegen die technische Spezifikation
2. Lead-Developer-Test: Prüft die Anpassung des Developers auf Einhaltung der internen Entwicklungsrichtlinien (C/AL-Guideline, Dokumentation, Nummernbereiche, ...) und führt die Auslieferungen durch.
[TEST-Datenbank]
3. Conultant-Test: Prüft die Anpassungen gegen die vom Key-User aufgeführten Akzeptanz-Kriterien.
4. Key-User-Test: Prüft die Anpassungen und erteilt die Freigabe zur Auslieferung in die PROD-Datenbank.
Das klingt jetzt im ersten Augenblick nach viel Bürokratie, erweist sich aber langfristig als gut investierte Zeit, da es dringende Fehlerkorrekturen in der PROD-Datenbank bereits im Vorfeld verhindert.
Ich hatte ich meiner Zeit bei den Systemhäusern schon häufig erlebt, dass man "keine Zeit für anständige Spezifikation, Programmierung, Dokumentation" hat, aber "unendlich viel Zeit für die Fehlerkorrekturen".
"Ich habe keine Zeit, meine stumpfe Axt zu schärfen, denn ich muss Bäume fällen."
Re: Beurteilung von Sachverstand
3. November 2020 13:54
Timo Lässer hat geschrieben:...
e) Anforderungen müssen in einer speziellen Art und Weise formuliert werden, damit genau klar wird, wer was warum benötigt, und unter welchen Bedingungen die Anpassung als vollständig umgesetzt gilt.
Wer: Wenn man die Abteilung und den Mandanten kennt, ergibt sich schon ein gewisser Kontext, in dem die Anforderung betrachtet werden kann.
Was: Der eigentliche Anpassungswunsch.
Warum: Welchen Vorteil bringt es der Abteilung bzw. dem Unternehmen?
Akzeptanzkriterien: Damit gibt es keine Ausreden wie "Das hatte ich aber so-und-so gemeint." bzw. "Da habt ihr aber noch das-und-das vergessen."
Was nicht geschrieben wurde, ist keine Anforderung...
Bietest du Kurse an?
Edit:
Wie handhabt ihr denn Korrekturschleifen? Also Key-User stellt fest, ist irgendwas nicht so wie es sein soll, Entwickler muss nochmal ran.
Re: Beurteilung von Sachverstand
3. November 2020 14:30
m_schneider hat geschrieben:Wie handhabt ihr denn Korrekturschleifen? Also Key-User stellt fest, ist irgendwas nicht so wie es sein soll, Entwickler muss nochmal ran.
Ganz einfach:
Key-User trägt in dem Issue sein Testergebnis ein und verschiebt den Issue auf dem Kanban-Board von "Test (Keyuser)" nach "Development".
Developer korrigiert und verschiebt (nach Auslieferung der Korrektur in die Test-Datenbank) den Issue wieder auf "Test (Consultant)", so dass die Korrektur zuerst nochmal von dem Consultant getestet wird, bevor es wieder bei "Test (Keyuser)" landet.
Bevor wir diesen Prozess in dieser Form eingeführt hatten, liefen die Anforderungen über das Ticket-System des Helpdesks, in dem jeder "Wünsch-Dir-Was" spielen konnte und mit dem Ergebnis nie zufrieden war.
Seit wir diesen Prozess eingeführt haben, ist alles für alle Beteiligten viel entspannter und planbarer.