Wie erkläre ich den Zeitaufwand dem Chef?
-
Hallo!
Ich soll meinem Chef eine Aufstellung machen, wie lange ich für was von dem Programm brauche. Er will dass ich an anderen Projekten arbeiten kann.
Nun habe ich grob überschlagen 2 Jahre noch zu tun - das wird ihm kaum gefallen.
Wie bringe ich ihm das schonend und verständlich bei?
Von Windowsprogrammierung hat er keinen Schimmer, er hatte zu Zeiten des C64 viel Ahnung und ist dort leider zum Großteil hängen geblieben. Also nicht ganz doof aber man kann auch nicht "normal" mit ihm reden.Ich mache Version 3 von einem firmeneigenen Programm, etwa alle 10 Jahre kommt eine neue Version.
Version 1 kenne ich nur von Fotos.
Version 2 läuft unter DOS und hat etwa 30 Bildschirmmasken.
Version 3 ist für Win98 und hat bisher geplant um die 80 Masken.
Es ist also deutlich mehr als das alte, aber wie bringe ich ihm das bei? Ich sollte das alte "nachbauen". Dabei habe ich es gleich noch modernisiert und um alles erweitert, was fehlte. Er hat die Analyse abgesegnet...Wo sind die Projektleiter und Formulierungstalente? Ich habe hier viele Zahlen, die ich schonend und überzeugend rüberbringen muss.
Programmieren und Planen kann ich, aber an der Kommunikation mit nicht-Entwicklern scheitere ich immer wieder. Irgendwie finde ich nie die richtigen Worte.
Wie begründet man 4 Monate Analyse? oder 3 Monate Design? Oder warum man für etwas, was man nicht sehen kann (Programmgrundgerüst, Basisklassen) gleich 4 Monate gebraucht hat?
Mich erschrecken die Zahlen selber. Ich habe einfach vor mich hin gearbeitet und stetigen Fortschritt gehabt - bisher reichte das aus.
Bin für Vorschläge echt dankbar
-
dein fehler ist (aus meiner sicht), dass du gleich das riesen ding anfängst anstatt eine version mit grundfunktionalität zu machen. wenn 30 masken reichen, dann mach halt eine mit 30. du kannst dir ja trotzdem die option für mehr freihalten, aber wenn du gleich mit 80 masken anfängst, dann übertreibst du es.
du mußt es ja dem chef so verkaufen, dass er einen nutzen sieht von der mehrarbeit. wenn du ihm nur sagst: "hier, ich hab das dos programm dass in 6monaten gecodet wurde nach 3jahren endlich fertig nachgeschrieben", dann wird er schon drüber nachdenken was für ne niete du bist.
wenn du in 6monaten die gleiche funktionalität erreicht hättest wie das dos programm, wäre dein chef zufrieden gewesen. wenn du dann erweiterungen wollen würdest, kannst du es ihm 'verkaufen'. du kannst ihm z.b. sagen 'wenn ich ... einbaue, dann passiert ... automatisch und jeder der mit dem programm arbeitet sparrt täglich 50% der zeit' und dein cheffe wird dann denken "boah, der coder hier bringt unsere firma wirtschaftlich echt weiter" oder er denkt sich halt, dass im reicht was das programm kann und du sollst besser was wichtigeres machen.
der punkt dabei ist aber, dass du das erledigt hast was dir aufgetragen wurde und dein cheff über deine arbeitsleistung verfügen kann.
rapso->greets();
-
Oh man, die Chefs werden es NIE lernen.
Mach dir keine Sorgen, das Problem haben alle Entwickler. Wir bekommen hier auch einfach Termine von "Oben" aufgedrückt, die an uns weiter "kommuniziert" werden. Ich kann nur köstlich darüber lachen! 
Nun zu deinem Problem: Die Zahlen sollten dich nicht erschrecken, meistens liegen Aufwandsschätzung eh zu niedrig. Am ende wirst du wahrscheintlich 6 Monate länger benötigen, als du schon eingeplant hast.
Versuche einen Kompromiss zu finden und stimme einfach keinem Termin zu. Schlage deinem Chef Meilensteine vor, das sieht günstiger aus, als nur einen finalen Termin. Soll heißen (nur als Beispiel!):
nach 6 Monaten: erste Grundfunktionen (z.B. Datensätze anlegen). Key-User können mit ersten Tests beginnen.
nach 9 Monaten: diese und jene Basis-Funktionen, die einfach wichtig sind. Key-User können erste produktive Daten eingeben.
nach 12 Monaten: diese und jene Funktionen
nach 16 Monaten: das meiste fertig
nach 24 Monaten: Goodies und GimmiksDu mußt den Leuten das ganze so verkaufen, das es nicht einen harten Schnitt gibt, zwischen der Benutzung alter Software und neuer Software. Sondern das man es Step-by-Step machen kann. Sagen wir mal, ihr habt 300 User im Hause. Dann könnten z.B. nach 6 Monaten ein paar ausgewählte User (Key-User) schon mal anfangen mit der ersten Version damit zu "spielen", sagen wir mal 6 Personen.
Weiterhin können diese aktiv am Entstehungsprozess teilnehmen, also Kritik und Wünsche äußern. Hat den Vorteil, das sie nicht 24 Monate däumchendrehend warten müssen, sondern immer Action haben. Das finden User ganz toll!
Die Key-User sollten nach Möglichkeit Führungspersonen o.ä. sein (muß nicht der Vorstand sein, sondern z.B. Teamleader aus verschiedenen Abteilungen, oder so). Die können das dann auch den anderen vermitteln, das was passiert. Ist besser, als wenn man 24 Monate nichts von dir und deiner Arbeit hört.Was die Basis-Funktionen angeht, mußt du durch Befragung der User analysieren, heraus zu finden, was wichtige Basisfunktionen sind. Die werden zu anfang sagen: Alle Funktionen!
Aber es gibt evtl. einen Workflow den die Software hat. Dann kann man z.B. erstmal einen Mini-Workflow mit den Key-Usern definieren. Wenn sie für bestimmte Dinge den großen Workflow benötigen, nehmen sie die alte Software. Irgendwann wird es einen Zeitpunkt geben, wo die alte Software ausgedient hat. Im Prinzip sollst du nicht versuchen alle Masken zu anfang umsetzen. Das wird nicht funktionieren!!! Also mache Meilensteine! Und du solltest deinem Chef ein Argument knall hart und ohne Umschweife vermitteln: "Wenn es schneller gehen soll, dann wird auch mehr Manpower benötigt!"
-
@Artchi:
Danke, deine Antwort macht mir echt Hoffnung, dass ich es nicht total vergeigt habe.Es gibt leider keine wirklich "Grundfunktionalität". Alles hängt irgendwie zusammen und das so arg, dass es wie ein Labyrinth ist, überhaupt zu entwickeln.
Die einzige Aufteilung, die irgendwie machbar ist, ist die Hintenanstellung von Drucken, Hilfe und Datenabgleich.
Der Test durch Endbenutzer wurde bisher immer wieder abgelehnt. Erst soll es fertig sein.
-
Ihr solltet aber auch mal den Kostenfaktor miteinkalkulieren. Entwicklungszeit von 2 Jahren das bedeutet in etwa 420 Manntage. Wenn man nun einen Tagessatz für einen Consultant als Beispiel nehmen der nicht von T-Sy<beeeeep> kommt in Höhe von 1500 EUR annimmt dann bedeuten das 630000 EUR Entwicklungskosten. Da fragt sich jeder Chef, ob er nicht billiger wegkommt, wenn er das extern machen lässt und sein teurer Mitarbeiter an anderen (womglich geldbringenden) Projekten arbeitet. Ich weiss es ist schlimm aber es wird nunmal so hart kalkuliert. Insofern wirds wirklich schwierig das deinem Chef zu argumentieren. Den Vorschlag ein Stufenkonzept einzuführen halte ich für sinnvoll. Zuerst die Funktionalität bieten, die tatsächlich benötigt wird. In einer der weiteren Stufen können dann so Gimmicks etc. eingebaut werden. Das könnte den Chef lustig stimmen
-
estartu_de schrieb:
Die einzige Aufteilung, die irgendwie machbar ist, ist die Hintenanstellung von Drucken, Hilfe und Datenabgleich.
Wäre schon mal ein Anfang. Versuche weiter jede Maske irgendwie nach hinten zu stellen. Und versuche auf jeden Fall den Chef und Key-User regelmäßig über den Fortschritt auf den Laufenden zu halten.
estartu_de schrieb:
Der Test durch Endbenutzer wurde bisher immer wieder abgelehnt. Erst soll es fertig sein.
Verkauf denen das nicht als Testen! Wie von mir beschrieben, mache die Key-User zu Mitentwicklern bzw. Mitwirkenden! Soll heißen, sie sollen Vorschläge zum Aufbau von Masken usw. einbringen können. So werden sie Teil des Projektes und das Projekt wird diesen Personen wichtig erscheinen, da es auch ihr "Baby" ist! Das technische ist dein Bier, aber alles was mit Masken, Eingabefelder, Goodis, Gimmiks usw. zu tun hat, kann man von den Key-Usern mitbestimmen lassen. Gib ihnen eine Testversion, ohne ihnen zu sagen: "Bitte testen!". Sondern: "Hier könnt ihr immer den aktuellen Entwicklungsstand sehen!" Testen werden sie indirekt durch Neugierde.
Wir machen einmal im Monat ein Meeting, da werden die Key-User eingeladen (jeweils einer oder zwei Personen, aus allen Abteilungen die damit arbeiten werden). Die bekommen Kaffee und Kuchen, der Beamer wird angeschmissen, dann zeigen wir ihnen die neuesten Funktionen, labern technisches Zeugs, mögliche Features usw. Die Key-User kommen dann autom. ins Spiel, wir fragen sie, ob sie es so oder so besser finden usw. Dann diskutieren diese heftigst untereinander und sind voll motiviert und man sitzt als Entwickler genüsslich daneben bis was festgelegt wird. Das geht dann von 9 Uhr morgens bis 13 Uhr so, monatlich!
So kannst du eigentlich nicht verlieren. Wenn du Ärger von deinem Chef bekommst, werden die Key-User dir den Rücken stärken! Denn sie haben auch mitgewirkt und sie profitieren von ihren eigenen Wünschen, die in das Projekt einfliessen.
-
Ach Artchi, das klingt wie das, was ich mir hier erhofft hatte.
Ich habe mit so vielen Ideen mit dem Projekt angefangen und immer wieder wurden mir die Flügel gestutzt.Ich habe halt mal vorgeschlagen, dass ich einen zweiten Rechner bekomme, auf dem dann das akteulle lauffähige Programm drauf ist und wo jeder mal gucken darf, der gerade im Haus ist.
Die Antwort war ein sehr entschiedenes "NEIN!".
Die Begründung war, dass dann zu viele Meinungen nur Chaos machen würden und dass die Leute eh keine Ahnung haben und was weiß ich nicht noch alles. Unsere Chefs müssen ihre Entscheidungen nicht begründen und umstimmen ist fast aussichtslos.Aber deine Argumente klingen so gut, ich werde es einfach noch mal versuchen. Vielleicht klappt es ja jetzt, denn bisher war es eine wage Idee - nun habe ich auch Worte dazu.
@CengizS: Ich bin ursprünglich für dieses Projekt angestellt worden. Und rausgeben wird er es wohl eher nicht...
Außerdem ist alle Software hier für den Eigenbedarf. Verkauft wird nur selten, glaube ich.
-
Das zu viele Beteiligte ein Chaos verursachen können, stimmt schon. Hat dein Chef ja wenigstens einmal Recht.
Aber trotzdem kann es nicht schaden, und man muß dann selber dann die Leute freundlich darauf hinweisen, wenn es das Projekt eher behindert. Dann muß man alles wieder in die richtige Richtung lenken.Aber das ist normal.
Sollte es nicht so hinhauen, mach folgendes: einfach weiter an dem Projekt arbeiten, mehr als gefeuert werden kann man nicht. Und das wird nicht so schnell passieren, wenn man Fortschritte sieht. Auch wenn das Projekt erst in 24 Monaten fertig ist. Vielleicht solltest du das mit der zusätzlichen Manpower als Alternativ-Vorschlag einbringen?
Wünsche dir viel Glück und Erfolg!
-
Danke!
Das macht irgendwie gleich optimistischer, ich werde noch kräftig Argumente sammeln und dann mal sehen, dass es was wird.
-
hi,
nur kurz eine frage, du sollst eine software über diesen zeitraum mit den kosten entwickeln für den eigenbedarf? ich weiss ja nicht um was es sich dabei dreht aber ich glaube da sollte man über die anschaffung einer passenden softwarelösung nachdenken.
man darf nicht vergessen das du sicher dann auch nach abschluss fehler beseitigen darfst, mitarbeiter geschult werden müssen usw.. was dich übrigens auch unabdingbar macht. aber eins sollte man auch in betracht ziehen...den chef feuern. die brgündung zuviele mitarbeiter bringen chaos mag nur bedingt stimmen. die sind es doch die damit arbeiten müssen. hier werden dann fehler auftreten die die nutzung unnötig verzögern oder es fallen fehlende funktionen auf usw.. eine software sollte bei der entwicklung immer wieder getestet werden. hierfür gibt es sogar protokolle die die mitarbeiter abarbeiten müssen, welches feld, welche eingabe usw..
klingt alles ganz schön komisch. mich würde aber mal interessieren was das für eine software ist.
-
Was das für eine Software die 2 Jahre braucht?
-
genau wollte ich auch wissen und vorallem für die eigenbedarf! und was für eine ausbildung hat dein chef....die kosten hier wurden dir einmal vorgerechnet, was auch ungefähr hinkommt. aber eine software für 680000 und zum eigenbedarf scheint mir etwas over dressed
-
@*keiner*! Hier wo ich sitze, wird so gut wie nur Software für den Eigenbedarf entwickelt. Bis auf MS-Office u.ä. wird keine fertige Software benutzt. Ich schätze mal, mit allem drum und dran mind. 2000 Entwickler (kenne leider keine offizielle Zahl), die Software für den Eigenbedarf entwickeln. Und das über Jahrzehnte hinweg! Wird sich auch in Zukunft nicht ändern, da es da draussen auf dem Markt die Software halt nicht gibt, die hier benötigt wird. Ist also nicht ganz so abwägig.
Und was soll an 2 Jahren ungewöhnlich sein? Eine Software ist praktisch niemals fertig!
-
ok dann rechne mir mal kosten / nutzen vor. 2000 entwickler die software für den eigenbedarf entwickeln kann ich mir einfach nicht vorstellen. was sollen das für produkte sein? es gibt darüber hinaus sicherlich office alternativen die ich nich unbedingt neu entwickeln muss. da kostet mich eine stunde mehr als 100 lizenzen so einer software.
womit verdient euer unternehmen sein geld udn vorallem muss dass je enorm viel sein. aber gut ich habe da nicht viel erfahrun aber vorstellen kann ich es mir nur sehr schwer...
-
nachtrag die behauptung software ist nie fertig mag sein past aber meiner meinugn nicht hier her. eine software hat irgendwann ein status x erreicht denn man akzeptieren sollte. da es sich um eine lösung handelt die ich selbst im unternehmen einsetze habe ich hier eine anforderugn die die software erfüllen soll zum zeitpunkt a. wenn sich der markt ändert udn ich sie anpassen muss ok aber 2000 entwickler machen dann irgednwas falsch oder programmiert ihr euer eigenes bs.
eine software die ich über so einen zeitraum entwickle und hier nicht den entsprechenden nutzen habe, kommerziell, soll die noch weiterentwicklet werden tag für tag mit den kosten?
was ist das für eine software? warum dann nicht lieber produkte einkaufen die eine vernünftige fuinktionalität mitbringen,die gibt es´und diese vielleicht für dieses unternehmen weiterentwickeln lassen. der rpeis dafür kann doch nicht den rahmen solcher entwicklungskosten sprengen.
aber egal dafür habe ich zu wenig ahnung
-
2 Jahre
Ich glaube Informatiker gehen so was viel zu präzise und planerisch an. Das Ding muss grob zusammengezimmert werden, dass es funzt. Ob der Code dahinter besonders schön oder effizient ist, interessiert doch keine Sau, das Programm muss möglichst schnell stehen und funktionieren. So ist es jedenfalls, wenn man als Ingenieur Software macht
-
Ich weiß ja nicht in welchen Branchen ihr arbeitet, kann sein das es da unterschiede gibt. Aber in meiner Branche, ist das normal. Die 2000 Entwickler (es sind nur die am Standort Wolfsburg!) entwickeln natürlich nicht an einer Software, sondern an gaaaanz vielen. Ein Autokonzern mit Hauptsitz in Wolfsburg findet seine Software nicht auf dem freien Markt. Klar, MS-Office, CATIA (CAD) usw. sind Produkte die eingekauft werden. Aber da hört es auch schon auf! Selbst die Stundenerfassung der Mitarbeiter kann man nicht mit einer Standard-Software lösen, wenn es mehr als 23 Schichtmodelle gibt.
Wie wird ein Auto gebaut? Jeder einzelne Schritt (bitte Wörtlich verstehen!!!) den der Werker am Band macht, alle Maschinen und Roboterwege, muß eingeplant werden. Jeder Handgriff, jede Just-In-Time-Kiste die am Band ankommt, die Grundrisse aller Werkshallen müssen beachtet werden, um genau zu planen, wann welches Bauteil und welche Maschine, welcher Arbeitsplatz aufgestellt wird. Darf der Werker sich bücken, weil es gewerkschaftlich erlaubt ist? Muß das Auto gedreht werden? Wieviel Zeit wird am Ende alles benötigen, bis das Auto hinten fertig rauskommt? Usw. usf.
Das sind nur ein paar Stichworte, die in einem (!) Software-Projekt eingebaut wurden. 3000 Menschen planen in ALLEN Autokonzern-Werken weltweit mit diesem einem System, für jedes Modell, jedes Bauteil für jedes Werk.
Wo bitte soll man so eine Software auf dem Markt finden, mit all den speziellen Autokonzern-Anforderungen???
Und das ist nur ein Software-System, das gut 2 Jahre entwickelt wurde. Mit 3D-Grafik, wie die Autos am Band in der jeweiligen Halle lang laufen, mit den Behältern und den Werkern. Incl. allen Auswertungsdaten und man kann alles ausdrucken um jedem Werker seine Arbeitsschritte an seiner Station zu erklären.
Alleine in Wolfsburg arbeiten 40.000 Autokonzern-Menschen plus Partnerfirmen. Zwei Kollegen von mir basteln an einer Software speziell für Bremsentests, das nehmen die Bremsentester auf ihr Notebook mit, wenn sie in die Sahara oder Finnland fahren. Können gleich alle Daten eingeben und auswerten und im Hotel nach Wolfsburg in die Mainframe-Datenbank übertragen.
Soll ich noch mehr aufzählen, wie über 2000 Entwickler zu einem Job bei einem Unternehmen kommen?
-
Minimee schrieb:
2 Jahre
Ich glaube Informatiker gehen so was viel zu präzise und planerisch an. Das Ding muss grob zusammengezimmert werden, dass es funzt. Ob der Code dahinter besonders schön oder effizient ist, interessiert doch keine Sau, das Programm muss möglichst schnell stehen und funktionieren. So ist es jedenfalls, wenn man als Ingenieur Software macht
Wer sagt denn, das in der Realität nicht alles zusammen gezimmert wird?
-
@Artchi also wenn es in richtung maschinensteuerung geht ist es ok aber programme die keine vernünftige zeiterfassung bieten ist quatsch. auch im bereich simulationssoftware gibt der markt einiges her. und die sache mit dem bremstest und der übertragung der daten ist ja nun nicht der hit. nur ist das unternehmen sicherlich in der lage diese kosten zu tragen.
nur ich glaube das deine erfahrung hier etwas weit entfernt vom thema ist. es ging hier um ein einmann projekt. der vergleich mit solchen unternehmen in den dimensionen ist etwas weithergeholt.
sorry ist nicht bös gemeint.
-
@keiner schau mal was artchie geschrieben hat:
Ich weiß ja nicht in welchen Branchen ihr arbeitet, kann sein das es da unterschiede gibt. Aber in meiner Branche, ist das normal. Die 2000 Entwickler (es sind nur die am Standort Wolfsburg!) entwickeln natürlich nicht an einer Software, sondern an gaaaanz vielen. Ein Autokonzern mit Hauptsitz in Wolfsburg findet seine Software nicht auf dem freien Markt.
damit sagt er, dass er in solch einem unternehmen arbeitet, du wilslt ihn doch nicht der lüge bezichtigen, oder?