Bin ich zu langsam?

[Meccarianer]

Mal ne Frage nicht zum Programmieren sondern zur Arbeitsgeschwindigkeit.

Habe für unser Firmenintranet eine aus 16 verschiedenen ASP Dateien bestehende Anwendung programmiert (plus eine Datenbank). Der Quelltext ist insgesammt etwa 35 DinA4 Seiten lang. Das Teil ist komplett von mir also auch Benutzeroberfläche, Grafiken, Sicherheit...

Dafür habe ich etwa 15 Tage gebraucht. Ist das zu lang? Ich hab teilweise einige Schwierigkeiten, aus meinem Chef die nötige Arbeitszeit rauszukitzeln. Ist jedes mal wieder ein Kampf.

Grüße
Meccarianer

[Sven Rautenberg]

Moin!

Habe für unser Firmenintranet eine aus 16 verschiedenen ASP Dateien bestehende Anwendung programmiert (plus eine Datenbank). Der Quelltext ist insgesammt etwa 35 DinA4 Seiten lang. Das Teil ist komplett von mir also auch Benutzeroberfläche, Grafiken, Sicherheit...

Diese Beschreibung sagt eigentlich noch nichts über das aus, was du da produziert hast. Die Anzahl der ASP-Dateien ist für die Problemlösung eigentlich irrelevant, die Tatsache, dass eine Datenbank eingebunden wird, ist für sich genommen auch kein komplizierender Faktor. Und die Tatsache, dass eine Benutzeroberfläche, Grafiken und Sicherheit eingebaut wurden, ist lediglich ein Hinweis, dass außer reinem Programmieren auch noch andere Arbeiten angefallen sind.

Wie aufwendig deine Lösung aber sein könnte, und wieviel Zeit man dafür verbraten könnte, ist aus diesen Angaben nicht zu ermitteln. Und außerdem ist natürlich die erzielte Qualität nicht zu ermitteln - schnellschnell-Programmierung geht vielleicht wirklich etwas schneller, hat aber langfristig möglicherweise Probleme, weil Erweiterungen schwierig zu implementieren sind. Ein sauberes, überlegtes Aufbauen kostet natürlich nochmal zusätzlich Zeit.

Dafür habe ich etwa 15 Tage gebraucht. Ist das zu lang? Ich hab teilweise einige Schwierigkeiten, aus meinem Chef die nötige Arbeitszeit rauszukitzeln. Ist jedes mal wieder ein Kampf.

In 15 Tagen kann man schon was schaffen. Die Frage ist eben, was du geschafft hast.

- Sven Rautenberg

[Thomas J.S.]

Hallo,

Dafür habe ich etwa 15 Tage gebraucht. Ist das zu lang? Ich hab teilweise einige Schwierigkeiten, aus meinem Chef die nötige Arbeitszeit rauszukitzeln. Ist jedes mal wieder ein Kampf.

Zusätzlich zu dem was Sven gesagt hat:
Hast du vor der Beginn deiner Arbeit eine Aufwandschätzung abgegeben?
Ja: hast du diese überschritten? --> Ja: um wie viel?
Nein: hat dir jemand einen Zeitraum genannt in dem du diese Anwenundg programmieren musst?
--> Ja: hast du diese "Schätzung" akzeptiert? --> Nein*
--> Nein/Nein*: woraus leitet denn dann dein Chef ab, dass du zuviel Zeit verbrauchtest? (Frag nach!)

Bei vielen "Ja":

1. du hast dich überschätzt
2. du hast die Arbeit unterschätzt --> falsche Konzeptionierung(?)

Grüße
Thomas

[Meccarianer]

Hallo!

Mir gings nicht um den Kampf mit meinem Chef sondern ich würde gerne wissen, ob ich langsam programmiere. Mir ist schon klar, dass das sehr schwer einzuschätzen ist. Ich bin kein Anfänger, programmiere schon seit Jahren in dieser Firma, da ich aber der einzige bin, hab ich keinen zum Austausch bzw. zum Vergleich.

Beispiel: Mal angenommen Ihr solltet einen Shop mit Warenkorb, Online-Produktverwaltung, Schnittstelle für Bankeinzug, Autoemails als Bestell- u. Versandbestätigung proggen. Ihr habt vorher noch nie einen Shop programmiert und macht alles selbst. Was würdet Ihr dafür etwa an Zeit einplanen?

Gruß
Meccarianer

[Thomas J.S.]

Hallo,

Beispiel: [...]

Was würdet Ihr dafür etwa an Zeit einplanen?

Ich? 10 minuten für die Absage und/oder an Weitergabe, denn ich würde es nicht alleine machen können.

Grüße
Thomas

PS: Alternative: 3 Jahre, bis ich einige mir nicht vertraute Prog.Sprachen dazu lerne.

[Sven Rautenberg]

Moin!

Beispiel: Mal angenommen Ihr solltet einen Shop mit Warenkorb, Online-Produktverwaltung, Schnittstelle für Bankeinzug, Autoemails als Bestell- u. Versandbestätigung proggen. Ihr habt vorher noch nie einen Shop programmiert und macht alles selbst. Was würdet Ihr dafür etwa an Zeit einplanen?

Das doppelte. :)

Naja, mal ernsthaft: Wenn du schon länger programmierst, dann hast du gewisse Erfahrungen und Codeteile bereits "in der Hinterhand". Einen Formmailer wirst du z.B. schon mal geschrieben haben, so dass die Aufgabe "Autoemails" eigentlich nur noch zerfällt in "Mailtext generieren" und "generierten Mailtext dem angepaßten Formmailer geben" - natürlich nicht per Formular, sondern direkt als Funktionsaufruf. Insgesamt eine Aufgabe von nicht mehr als einem halben Tag. Wenn du den Mailer allerdings noch recherchieren und selber schreiben mußt, dauert das natürlich länger. Mit Kenntnis der passenden Programmier-Hilfeseiten vielleicht einen Tag, ohne Kenntnis der Seiten vielleicht zwei Tage.

Entscheidend in der Diskussion zwischen dir und dir bzw. dir und deinem Chef ist daher eigentlich nicht, wieviel Zeit "man" braucht, sondern wieviel Zeit _du_ brauchst - und zu Planungszwecken ist es eben vorher wichtig zu wissen, wie lange du meinst, für eine Aufgabe zu benötigen.

Es hilft dir doch absolut nichts, wenn am Ende dieser Diskussion rauskommt, dass du eigentlich nur die Hälfte der Zeit benötigen solltest, und du aufgrund dieser Angabe deine Arbeit derart beschleunigst, dass am Ende nur noch Müll rauskommt. Oder du dich derart unter Stress setzt, weil die Arbeit länger dauert, als du gedacht (oder leichtsinnigerweise sogar gesagt) hattest. Das ist eben "der Fluch der ersten Zahl": Der vermutete Aufwand kann anhand der Aufgabenbeschreibung immer nur geschätzt werden. Wer diese Schätzung aber als Zahl festlegt, wird hinterher immer irgendwie drauf festgenagelt, auch wenn er sich fürchterlich (und offensichtlich) verschätzt hat oder während der Bearbeitung der Aufgabe Probleme für eine Verzögerung sorgen. Mehraufwand kann man immer schlechter verkaufen, als wenn man schneller fertig ist.

Die "Scotti-Taktik" hingegen wird auf Dauer aber leider auch nicht aufgehen (zumindest gegenüber informierten Personen, die diese "Scotti-Schätzungen" häufiger entgegennehmen). Scotti, Chefingenieur auf dem Raumschiff Enterprise, hat bei seinen Zeitschätzungen gegenüber Captain Kirk immer maßlos übertrieben: "Captain, den Warpkern zu reparieren dauert mindestens 4 Wochen." "Scotti, ich geb' dir 4 Tage." "Ok, Captain, ich machs in zwei!" (und war trotzdem noch vorher fertig ;) ).

- Sven Rautenberg

[Ich-bleib-mal-lieber-anonym-Kollege-liest-mit]

Hallo!

Aus meiner Erfahrung heraus hat sich folgender "Schätzalgorithmus" bewährt:

1. Zeitschätzung aus dem Bauch heraus (das geht natürlich nur mit etwas Erfahrung)
2. großzügig aufrunden (+20% oder so)
3. verdoppeln
4. und noch mal mind. 50% oben drauf, wenn's intensiv getestet werden soll.

Das bedeutet im "Real Life":
* Triviale Änderungen (drei Zeilen) gibt's nicht unter einer Stunde.
* Eine komplett neue Funktion (im Sinne von function f()) dauert mindestens einen Tag.
* Neue Features (mehr als eine function f()) dauern eine Woche oder mehr.

Das ist keine Faulheit, das sichert mich ab. Meistens brauche ich etwa 90% meiner Schätzung (nach Schritt 3/4), ich hab also nur 10% Luft um irgendwelche unerwarteten Probleme zu beseitigen.

Wenn jemand anfängt, angesichts der finalen Schätzung zu jammern, hilft die Drohung mit ungetestetem Code recht gut. Spätestens, wenn man das einmal durchzieht (also explizit ungetesteten Code rausgibt und deutlich -- schriftlich -- darauf hinweist, daß die ganze Sache explodieren kann), läßt das Jammern deutlich nach. Denn ungetesteter Code explodiert fast garaniert.

Just my 2 cents ...

[Michael Schröpl]

Hi Du,

4. und noch mal mind. 50% oben drauf, wenn's intensiv getestet werden soll.
   Meistens brauche ich etwa 90% meiner Schätzung (nach Schritt 3/4), ich hab also nur 10% Luft um irgendwelche unerwarteten Probleme zu beseitigen.

und wann schreibst Du die Dokumentation?

Viele Grüße
      Michael

[Thomas J.S.]

Hallo Michael,

und wann schreibst Du die Dokumentation?

Danke für die Frage!

Grüße
Thomas