Personenabhängigkeit bei selbstgeschriebenen Programmen
-
Klar hilft eine Dokumentation; diese zu erstellen dauert aber noch einmal so lange wie das Programm zu schreiben. Und dann müßtest du immer noch jemanden finden, dem die Dokumentation etwas sagt und der das bestehende Programm gezielt ändern kann.
Hierfür müßte der Abteilungsleiter explizit jemanden suchen, der VBA Programmieren kann. Das Personalbüro wird ihm aber sagen, daß er das mit den VBA-Kenntnissen in der Stellenausschreibung vergessen soll, da sowas auf diesem Posten nicht vorgesehen ist. In großen Firmen sind auch Abteilungsleiter bei sowas ganz schön eingeschränkt.
-
Man kann solche Tools auch extern entwickeln lassen.
Wenn man dabei auf eine Technologie setzt die gerade "in" ist, dann ist es auch relativ einfach einen selbständigen Entwickler zu finden der da mal schnell ein paar Formulare ändert.
Wobei man das natürlich auch in dem Fall üblicherweise von der selben Person warten lässt die es auch entwickelt hat.Die Idee dass alles problemlos weiterlaufen muss, egal welcher Mitarbeiter ausfällt, ist auch ziemlich beknackt, weil realitätsfremd.
-
Man kann solche Tools auch extern entwickeln lassen.
In der Firma wo ich arbeite (Börsennotiert, ca.4000 Mitarbeiter, eigene IT(?)-Abteilung mit 120 Mitarbeitern), würde das bedeuten: mehrere Monate Vorlaufzeit bis es zu ersten Gesprächen kommt, es muß dem Programmierer erst erklärt werden was wir wollen (dazu muß er auch erst den Geschäftsprozeß dahinter verstehen), dann sieht man ihn 1/2 Jahr lang nicht, bis er dann endlich einmal eine erste Version präsentiert. Danach wird noch nachgebessert und nach insgesamt 1-2 Jahren bekommen wir dann ums sehr teure (firmenintern verrechnete) Geld eine Anwendung, die ich selbst in 1 Monat (auf Excel-VBA-Basis) zusammengebracht hätte.
Nur sind mit der externen Variante inzwischen 1-2 Jahre vergangen und bei uns ändern sich die Geschäftsprozesse schneller, als unser träger Apparat in der Lage ist mitzuhalten.....Es geht aber noch weiter: Inzwischen ist die IT-Abteilung so weit, daß sie selbst keine Programme mehr entwickeln wollen, weil "Programmcode immer sehr personenbezogen ist, und was mache ich wenn der Mitarbeiter nicht mehr da ist" - so sagte es mir wortwörtlich ein dortiger Abteilungsleiter!
Deswegen reicht jetzt die firmeneigene IT die Anforderung erneut weiter, damit sich die verantwortlichen Leiter immer auf jemand anderen abputzen können.Klingt alles wie bei den Schildbürgern, aber so geht's in vielen großen Firmen zu.
Die Idee dass alles problemlos weiterlaufen muss, egal welcher Mitarbeiter ausfällt, ist auch ziemlich beknackt, weil realitätsfremd.
Schau dir noch einmal das obige Zitat in Kursiv-Schrift an; "Wie sag' ich's dem Abteilungsleiter?" Diese "lieber nichts selber entwickeln"-Haltung haben inzwischen auch IT-fremde Abteilungsleiter angenommen.
Obwohl an allen Ecken und Enden gespart werden soll, werden aber schnell einige 100k-Euro locker gemacht um eine externe Firma damit zu beauftragen......
-
Und wo ist das Problem damit es richtig zu machen?
Solche Insel Loesungen wo ein Mitarbeiter irgendwas zusammen pfuscht ist langfristig immer ein Problem fuers Unternehmen.
Die korrekte Loesung ist durch alle Instanzen zu gehen und eine ordentliche Loesung zu bekommen.
-
Solche Insel Loesungen wo ein Mitarbeiter irgendwas zusammen pfuscht ist langfristig immer ein Problem fuers Unternehmen.
Ja, langfristig gibt es sicher ein Problem. Der Begriff "Pfuschen" ist für mich aber vollkommen unzulässig, wenn sich dieses Tool im harten Praxiseinsatz täglich auf's neue bewährt und vielleicht noch zusätzlich Funktionen bietet, die keine kommerzielle Software bietet.
Die korrekte Loesung ist durch alle Instanzen zu gehen und eine ordentliche Loesung zu bekommen.
Das wird jetzt seit ein paar Jahren so gemacht; wir bekommen zwar personenunabhängige Lösungen, die treffen aber NIE EXAKT unsere Anforderungen; da heißt es dann immer: "Na darauf müßt ihr halt verzichten" oder "das geht jetzt nicht mehr so".....
Anders ausgedrückt:
Eigenentwicklung eines engagierten Mitarbeiters = die Frau von der Männer träumen - echte Liebe auf ewig
Offiziell angeschaffte Software = die übliche Ehe, und man bleibt halt z'samm wegen der Kinder.......
-
@Fletcher
Klingt für mich so als ob da allgemein was in der Firma schief läuft. Weil es ist auch in mittelgrossen bis grossen Firmen nicht Standard dass für ein Tool das in einem Monat entwickelt ist ein riesen Aufstand gemacht werden muss und mehrere Monate oder gar Jahre vergehen bis überhaupt mal angefangen wird.Unglücklicherweise bist du nicht in der Situation dagegen etwas zu unternehmen. Der der in der Lage wäre, ist vermutlich dein Chef, bzw. Abteilungsleiter. Und wenn der nicht will, hast du kaum Chancen.
Also was willst du jetzt von uns hören?
Es gibt genug Argumente die gegen Softwareentwicklung mit selbstgelernten Cowboy-Programmierern aus der eigenen Abteilung sprechen. z.B. kommt es sehr häufig zu Problemen wenn die Software anfängt zu wachsen/eine gewisse komplexität anzunehmen.
Zu dem Zeitpunkt hat man die ganzen Prozesse dann schon soweit auf die so entstandenen Tools abgestimmt, bzw. es weiss einfach keiner mehr wie man es mit Hand macht, so dass ein Umstieg zurück auf das wie man vorher gearbeitet hat ziemlich kostspielig wäre.Ich sehe jetzt nichts was du deinem Chef sagen könntest, das diese einfache Wahrheit unwahr macht.
Wenn man sich das ganze Unternehmen ansieht, dann könnte man da vermutlich viel machen. z.B. könnte eine Firma mit 4000 Mitarbeitern vermutlich leicht ein oder zwei Entwicklerteams vertragen, die dann In-House Software entwickeln. Wenn man da mit einem passenden Prozess (z.B. SCRUM) arbeitet, dann ist auch sichergestellt dass es für jedes Tool bzw. sogar jede Komponente eines jeden Tools mindestens 2-3 Leute gibt die davon einen Plan haben. D.h. man ist nicht mehr auf einen einzigen Mitarbeiter angewiesen.
Weiters können mit solchen Prozessen langwierige Planungsphasen und das "vorbeientwickeln" an den Bedürfnissen der Abteilung vermieden werden.
Funktioniert aber natürlich nur wenn man sich wirklich an den Prozess hält, und zumindest die Schlüsselpositionen passend besetzt hat (bei SCRUM z.B. ganz wichtig der Product-Owner und der Scrum-Master).Nur wie bereits gesagt ... du bist leider nicht in der Position da etwas ändern zu können. Natürlich kannst du mal mit deinem Chef darüber sprechen, und der könnte dann mit seinem Chef darüber sprechen und... Ich sehe da aber nicht viel Licht. Solche Dinge von unten heraus zu ändern ist quasi unmöglich. Damit das funktioniert müssen ein paar Leute in ein paar "höheren" Positionen bestimmte Dinge verstanden haben und vor allen auch bestimmte Fähigkeiten mitbringen. Und das kannst du als kleiner Angestellter ihnen nicht reinprügeln.
-
Fletcher schrieb:
Solche Insel Loesungen wo ein Mitarbeiter irgendwas zusammen pfuscht ist langfristig immer ein Problem fuers Unternehmen.
Ja, langfristig gibt es sicher ein Problem. Der Begriff "Pfuschen" ist für mich aber vollkommen unzulässig, wenn sich dieses Tool im harten Praxiseinsatz täglich auf's neue bewährt und vielleicht noch zusätzlich Funktionen bietet, die keine kommerzielle Software bietet.
Nur dass etwas im täglichen Einsatz gut funktioniert, heisst nicht dass es nicht Pfusch ist.
Der Begriff ist für mich vollkommen zulässig.
Wenn du keinen offiziellen Auftrag hast etwas zu machen, die Firma eigentlich gar nicht will dass du das machst, deine Stellenbeschreibung es nicht mit einschliesst, deine Ausbildung es nicht abdeckt, du weder von der Firma vorgegebene Prozesse noch offiziell anerkannte Prozesse verwendest um es umzusetzen uswusf. - wie soll man das denn bitte schön sonst nennen?Und BTW... wie ich im anderen Thread auch schon geschrieben habe: ich vermute dass du das Thema Softwareentwicklung massiv unterschätzt.
-
Du hast einige Dinge richtig erkannt!
Bis vor gut 1 Jahr lief in unserer Firma quasi einiges falsch, bis endlich der sesselklebende eigennützige Direktor abgelöst wurde, und auch der lethargische Typ darunter, mein Ex-Chef. Den neuen Chef kenne ich seit 14 Jahren und habe mich schon immer gut mit ihm verstanden. Der neue Direktor ist auch OK, der räumt jetzt den "Müll" der letzen 20 Jahre weg......
Meine "Dienste" wurden damals gerade einmal für das Dienstplanprogramm in Anspruch genommen und das nur zaghaft "Brauchen Sie da eh nicht zu lange dafür?".
Ich habe es deswegen gemacht, weil die Mitarbeiter durch das Programm weitgehend ihre Lieblingsdienste erhalten haben (auch ich), ohne der Firma damit zu schaden.Jetzt mit neuem Chef und Direktor - beide interessieren sich für mein "Know-How" - kommt Schwung in die Bude. Ich habe meinem Chef die 1 Personen-Problematik jedenfalls erläutert, obwohl das gegen mich spricht. Die Lösung ist einfach, daß der Direktor versucht ein professionelles Programm anzuschaffen, das von internen und externen Leuten gewartet wird. Ein dezitiertes Front-End mit RDBMS-Backend.
Geredet wir darüber schon über 1 Jahr; jetzt gerade läuft erst die Ausschreibungsphase. Inzwischen kommt in meiner Abteilung zum 12.Mal in Folge der neue Dienstplan heraus, erstellt mit der neuesten Version meines Programms. Alle sind froh, daß es das gibt, denn sonst wären sie schon verrückt geworden. Es läuft so zuverlässig, daß ich auch 3 Wochen in Urlaub fahren kann, ohne das die etwas von mir brauchen!Es wird sich zeigen, was passiert wenn die Ausschreibung aus irgendeinem Grund ins Wasser fällt, denn es gibt bereits erste Anzeichen daß das passieren könnte........
-
Wenn du keinen offiziellen Auftrag hast etwas zu machen, die Firma eigentlich gar nicht will dass du das machst, deine Stellenbeschreibung es nicht mit einschliesst, deine Ausbildung es nicht abdeckt, du weder von der Firma vorgegebene Prozesse noch offiziell anerkannte Prozesse verwendest um es umzusetzen uswusf. - wie soll man das denn bitte schön sonst nennen?
Nennen wir es Notlösung; aus jener Not heraus, daß kein Geld und keine Zeit da ist um den offiziellen Weg zu gehen. Unserer Abteilung nützt es auf jeden Fall etwas, denn sonst würde mein Chef nicht erlauben daß ich sowas in meiner Normalarbeitszeit erledige.
Meine "Notlösung" ist jedenfalls so gut (ich weiß - Eigenlob), daß wir das SAP nur mehr als Schönschreibheft verwenden - als Pflichteingabe für die endgültige erbrachte Arbeitszeit zwecks Personalverrechnung. Solange im SAP alles richtig drin steht, wird keiner Fragen wie wir zu den Eingaben gekommen sind.
Mein Programm hat auch schon unser Personalcontroller gesehen, und ich habe ihm gesagt, daß die ausgeschriebene Software (um mehrere 100k-Euro!) dieses Tool bzw. "Notlösung", schlagen muß. Er meinte nur "Das ist eine gute Meßlatte!".
-
Ich sehe hier fast einen "Domänenexperte vs. Informatiker Mismatch". Domänenexperten schreiben oft Software, die bis zu einem gewissen grad genau das macht, was sie wollen, und mit der alle in der Abteilung zufrieden sind. Informatiker interessieren sich meist eher für die Architektur und den Stil des Programms, und interessieren sich oft überhaupt nicht für die eigentliche Fachdomäne. Deswegen würden sie zu dem was der Domänenexperte geschrieben hat pauschall "Bullshit" sagen, es komplett neu schreiben, sauberer und eleganter, aber leider aus Sicht des Domänenexperten schlechter, weil sie sich in die Thematik nicht tief genug renkdenken wollten. Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
-
Guter Einwurf Mechanics!
Dann bin ich wohl ein "Domänenexperte". Der "Informatiker" paßt zu jenem Typ Professor den ich (leider) an der Schule im EDV-Unterricht hatte: Der interessierte sich kaum dafür, was das Programm genau kann, sondern wollte immer den Code sehen: "Wie haben sie das realisiert?" - "Ist doch Blunzen!" dachte ich mir, es funktioniert, es performt, was gibt's da noch zu fragen?
Etwas selbsterstelltes hat man von ihm natürlich nie gesehen, aber kritisieren konnte er gut. Spiele-Programmierer waren für ihn sowieso das letzte, nur wer sich an Datenbanken ran gewagt hat war für ihn eine Respektperson; so war zumindest seine Denke.Z.B. in MS-Office 97 soll in Excel noch der Bubble-Sort-Algorithmus zur Anwendung gekommen sein! Sowas gibt eine große Softwarefirma heraus?
Im "Notepad" von Windows-XP dürfte auch etwas nicht sauber programmiert gewesen sein: Wenn man Text in großen CSV-Dateien ersetzt hat (z.B. Punkt gegen Komma), stieg die zeitliche Dauer quadratisch mit der Größe der Datei! Auch "sehr professionell". Wie ist das durch die Microsft Qualitätskontrolle gekommen?
Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
In dem Bereich wo ich arbeite (Flugzeugabfertigung) gibt es kein "auf lange Sicht" mehr. Ständig kommt aus irgendeiner Ecke (Airlinekunden, Behörden und firmenintern) ein neuer Blödsinn und es ist inzwischen alles so komplex geworden, daß niemand mehr zu 100% durchblickt. Daher stellen wir uns mit "Notlösungen" diesen Problemen entgegen, denn bis wir was offizielles bekommen würden, ist so viel Zeit vergangen, daß wir eventuell das ursprünglich geforderte nicht mehr brauchen und es außerdem ein neues Problem gibt......
-
Fletcher schrieb:
Der "Informatiker" paßt zu jenem Typ Professor den ich (leider) an der Schule im EDV-Unterricht hatte: Der interessierte sich kaum dafür, was das Programm genau kann, sondern wollte immer den Code sehen: "Wie haben sie das realisiert?" - "Ist doch Blunzen!" dachte ich mir, es funktioniert, es performt, was gibt's da noch zu fragen?
Dein Lehrer hatte hier Recht.
Denn guter sauberer wartbarer Code erkennt man nur daran, wenn man sich auch den Code anschaut und nicht nur die Oberfläche.
Etwas selbsterstelltes hat man von ihm natürlich nie gesehen, aber kritisieren konnte er gut.
Das ist doch toll!
Manche Informatikstudenten wären froh, wenn die Professoren mal ihren Code wirklich ansehen würden.
Wie soll man sonst lernen guten Code zu schreiben, wenn man niemanden hat, der einem auf Code hinweist, der schlecht umgesetzt wurde?
Sei also dankbar, dass du so einen Kritiker hattest!Spiele-Programmierer waren für ihn sowieso das letzte, nur wer sich an Datenbanken ran gewagt hat war für ihn eine Respektperson; so war zumindest seine Denke.
Okay, hier war er dann natürlich im unrecht.
Allerdings könnte es sein, das er immer die ganzen verbuggten Spiele im Hinterkopf hatte und deswegen so dachte.Im "Notepad" von Windows-XP dürfte auch etwas nicht sauber programmiert gewesen sein: Wenn man Text in großen CSV-Dateien ersetzt hat (z.B. Punkt gegen Komma), stieg die zeitliche Dauer quadratisch mit der Größe der Datei! Auch "sehr professionell". Wie ist das durch die Microsft Qualitätskontrolle gekommen?
Notepad wurde zu Win3.x Zeiten schnell dahingeschmiert, damit man wenigstens einen Editor in Windows 3.x hatte und diese Codebasis wurde dann weitgehend in neue Windows Versionen unverändert übernommen.
Oder anders gesagt, die ganze Manpower und Zeit wurde in die Windows Kernkomponenten investiert, Notepad war nur Beiwerk und somit nicht so wichtig.
Win3.0 mußte laufen, das unter DOS und einer 16 Bit Umgebung mit sehr wenig RAM.
Das hat genug Gehirnschmalz erfordert und als dann Win9x und WinNT entwickelt wurde, gab es schon wieder andere Prioritäten.Natürlich wäre es toll gewesen, wenn dann spästens bei WinXP das bis dahin zum Riesenkonzern mutierte Unternehmen wenigstens mal ein oder zwei gute Entwickler extra eingestellt hätte, um sich dem Notepad Problem mal ernsthaft anzunehmen und den Code neu zu schreiben, aber hier war man wohl zu geizig, denn im großen und ganzen funktionierte ja Notepad für die kleinen Sachen und wer mehr wollte, der hat sowieso immer nen gescheiten Editor verwendet.
Wozu also Geld investieren für etwas, wo es keinen Bedarf für gab?
WinXP hatte genug andere Baustellen, die es zu optimieren gab.Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
In dem Bereich wo ich arbeite (Flugzeugabfertigung) gibt es kein "auf lange Sicht" mehr. Ständig kommt aus irgendeiner Ecke (Airlinekunden, Behörden und firmenintern) ein neuer Blödsinn und es ist inzwischen alles so komplex geworden, daß niemand mehr zu 100% durchblickt. Daher stellen wir uns mit "Notlösungen" diesen Problemen entgegen, denn bis wir was offizielles bekommen würden, ist so viel Zeit vergangen, daß wir eventuell das ursprünglich geforderte nicht mehr brauchen und es außerdem ein neues Problem gibt......
Guter Code ist sehr modular und sollte sich daher modular recht einfach und unkompliziert über Module, Plugins usw. erweitern lassen.
-
@Fletcher
Gerade wenn ihr Anforderungen habt die sich so schnell und so oft ändern wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann.
Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, und auch einige Firmen die Auftragsarbeiten machen nicht wirklich sehr gute Softwarearchitekten haben. (Also nicht alle, einige natürlich schon.)Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet.
Das kostet aber auch ordentlich Geld, und vor allem ist es für nicht-IT Firmen alles andere als einfach eine IT-Abteilung so aufzubauen und zu betreiben dass die auch gut arbeiten kann.Von daher also auch sehr riskant.
-
...wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann. Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, ....
Auf die Gefahr hin, daß ich dich jetzt (wieder?) verärgere; so ein Programm gibt es schon, es heißt Excel
Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet. Das kostet aber auch ordentlich Geld,...
Ja, wäre eine gute Idee, wenn sich mehrere Leute mit diversen Tools auskennen, aber wie du sagst: "kostet Geld". Und schon ist die Idee für die Manager nicht mehr so toll, und so dringend brauchen wir die Tools laut denen eh nicht, weil es nur "nice to have"-Dinge sind.
Es dürfte also wirklich so sein, daß wenn Personenunabhängigkeit gefordert ist, mehrere Leute da sein müssen, die sich mit jedem Detail auskennen, oder man läßt es bleiben, wenn weiterwurschteln ohnehin billiger ist.
Oder man läßt eben von nur einem einzigen Mitarbeiter alles machen, hat als Manager aber eine Rückfallebene, wo im Falle das Falles, zumindest zur Kundenseite hin, der Geschäftsbetrieb normal weiterläuft.
-
Sorry wenn ich was übersehen habe, aber wieso erklärst du deine Excel-Sachen nicht einfach noch zwei weiteren Kollegen? Die müssen ja nicht selbst schon so gut VBA und co. können wie du, aber zumindest die Denkfähigkeit und das Interesse dafür mitbringen, um wenn du dann (warum auch immer) mal weg bist, was damit anfangen zu können. Damit sie bis dahin nicht vergessen haben, was du ihnen erklärt hast, könntet ihr ja grob schriftlich festhalten, worum es ging.
-
Das wäre in unserem Fall die beste Idee - habe ich auch schon deponiert - aber auch unser Direktor muß sich an unternehmeneigene Spielregeln halten bezüglich Planposten. Er muß dann dem Vorstand erklären, warum er jetzt 2-3 neue Hanseln in ein Büro setzt.
Wegen dem Auskennen: In unserem Bereich haben wir einige hundert Angestellte, aber es mir ist noch keiner über den Weg gelaufen den VBA-Programmieren interessieren würde.
-
Muss ja kein VBA sein. Aber wenn irgendein Ingenieur generell Interesse am Programmieren hat, und auch hin und wieder sowas macht, sollte das ja schon irgendwie gehen, wobei ich natürlich nicht weiß, wie highly sophisticated die Sachen, die du da machst, sind.
Gehts denn darum, dass wenn du weg bist, jemand da sehr kurzfristig irgendwas drin machen können muss, oder hat er dann noch etwas Einarbeitungszeit?
-
Es gibt rein gar niemand bei uns der auch nur einfachste Sachen in VBA machen könnte. Du müßtest die Gesichter sehen, wenn ich auf deren PC zum ersten mal "Alt+F11" drücke (es öffnet sich der Makro-Editor); die haben gar nicht gewußt, daß es das gibt und wozu es gut ist.
Das bzw. mein Glück dürfte sein, daß meine Sachen doch weitgehend zuverlässig funktionieren, und mir im Laufe der Zeit daher immer wieder neue Kleinigkeiten anvertraut werden. Gäbe es nur Probleme mit meinen Tools würde das schon niemand mehr verwenden oder mich dafür konsultieren.
-
Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!
-
berniebutt schrieb:
Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!
Naja, vor 1 Jahr sind sie schließlich doch auf mich gestoßen, weil es in der Führungsriege (wie weiter oben schon beschrieben) einen großen Wechsel gab. Seitdem werde ich oft von der eigentlichen Arbeit befreit um mich verstärkt um die VBA-Sachen zu kümmern. Ein dauerhafter Planposten dafür ist noch in Schwebe.
Einen Mitarbeiter vom Typ "ich bin unverzichtbar" darf es in der Tat nicht geben; würde er zugelassen werden, wäre das Management erpressbar. Ich darf meine Stellung daher keinesfalls in dieser Richtung ausnutzen.
Das mit dem "eigenen Laden aufmachen" habe ich immer wieder überlegt, aber wenn ich auf meinen Gehaltszettel schaue, habe ich Zweifel ob ich diese Summen mit dauerhafter Regelmäßigkeit bei "einem eigenen Laden" erreiche. Abgesehen davon, kann ich, wenn ich will, 6 Wochen am Stück in Urlaub gehen und kein "Schwein" ruft mich an. (positiv)
