Domino 9 und frühere Versionen > Entwicklung

Notes Entwicklungsrichtlinien + QS

<< < (3/3)

animate:

--- Zitat von: Marinero Atlántico am 07.06.05 - 17:20:56 ---... und glaub mir, ich hab immer das Gefühl, dass nicht ich sondern Teile meiner Kundschaft kreative Individualisten sind.  ;D

--- Ende Zitat ---
LMAO! Mir gehts da nicht anders.

Es gibt doch bestimmt Gründe, warum sich deine Leute nicht an die Regeln halten. Hast du die schon herausgefunden?

Meine Meinung ist, dass wenn du am Montag jedem Entwickler nen Packen Regeln gibst und ihm sagst, dass es sich daran halten soll - ab sofort - dann ist das schwierig für den Entwickler. Er versteht ihren Zweck/Sinn nicht. Er hält dich nicht für fähig genug, ihm Regeln vorzuschreiben weil du keine Ahnung hast. Er mag dich einfach so nicht, weil du ihm kürzlich erst vor die Nase gesetzt worden bist. Er befolgt die Regeln nicht, weil ohne sie bis jetzt auch alles wunderbar funktioniert hat. Er hasst Regeln und Vorschriften einfach. Da gibts noch 1000 andere Gründe. Und um einen Mitarbeiter dazu zu bringen, dir zu folgen, gibts bestimmt genauso viele Möglichkeiten.

Eine Empfehlung, die ich geben kann ist, dass du solche Richtlinien am besten in Zusammenarbeit mit den Betroffenen entwickelst.
Also mit ihnen das Problem der schlechten Kooperation erörtern. es ihnen bewusst und verständlich machen. Und dann gemeinsam mit ihnen eine Lösung für das Problem erarbeiten. Die meisten werden sich daran halten (zumindest eine Zeit lang), denn sie ist ja schließlich auch ihrem Kopf entsprungen.

animate:
ach so nochwas, auch wenn das von meiner Warte aus unmöglich zu beurteilen ist: in meinen Augen ist nicht Notes die Ursache deiner Probleme. Ich bin mir sicher wenn du statt Notes XYZ einsetztest, wärs das gleiche.

koehlerbv:

--- Zitat von: Thomas Völk am 07.06.05 - 22:23:42 ---ach so nochwas, auch wenn das von meiner Warte aus unmöglich zu beurteilen ist: in meinen Augen ist nicht Notes die Ursache deiner Probleme. Ich bin mir sicher wenn du statt Notes XYZ einsetztest, wärs das gleiche.

--- Ende Zitat ---

Dieser Gedanke kam mir als allererstes, als ich diesen Thread erstmals sah. Es ist kein Notes-Problem.
Vor vielen Jahren hatte ich das Glück, an eine begnadete Programmiererin und Projektleiterin zu geraten, die mich von grundlegenden Regeln der Programmierung im Team überzeugt hat. Ich habe die "innere Umstellung" durchgestanden, ich habe die Erfolge genossen und dann selber eine Ader dafür gefunden, diese Überzeugung auch an andere weiterzugeben. Ich sehe das genauso wie Thomas: Es ist ein menschliches Problem, das man im Team lösen muss. Meine Erfahrung ist aber auch: Wenn in diesem Teamwork jemand partout nicht mitspielen will (oder - warum auch immer - kann), dann muss er zumindest das Team verlassen. Der Erfolg kommt nur, wenn wirklich alle mitmachen.

Bernhard

Marinero Atlántico:
Ich halte Generalisierungen generell für gefährlich.
Beispiel: ich beschäftige mich zwar mit Unit-Testing, finde aber 100% Test-Coverage für die meisten Projekte Unsinn.
Ein gesundes Team ist für mich auch ein dynamischer Prozess, wo es eben auch schon mal Konflikte gibt. Es sollte aber bei manchmal bleiben.

- Hacks werden oft mit Kreativität verwechselt. Das ist Unsinn. Hacks lösen zwar oft ein *anscheinend* existierendes Problem, schaffen aber dafür ein paar weitere in der Zukunft. Es gibt eine Menge Hacks, die eigentlich mehr ein Anzeichen für fehlende Imaginationskraft für Probleme in der Zukunft sind. Also eher das Gegenteil von Kreativität.

- Das größte Problem von unerfahrenen Projektmanagern und Entwicklern ist, dass sie sich überschätzen. Sie glauben sich im Besitz von *Wahrheiten*, die keine sind. Arbeitest du basierend auf Allgemeinplätzen, verlierst du jede Flexibilität und gerade das benötigst du für den Erfolg von Projekten. Das ist eigentlich genau wie GO (das Brettspiel). Du hast immer einen gewissen Spielraum, agierst zwischen den Steinen des Gegners. Damit muß man leben. Zu glauben, nur wenn man irgendwelche Regeln befolgt, dass es dann Manna vom Himmel regnet, ist eine Illusion. In dieser Hinsicht sollte man zwar die stark amerikanisch geprägte Projektmanagementliteratur lesen, aber mit Skepsis. Das sind die Amis nämlich auch.

Produktiver werden, ist ein längerer Prozess, der Energie kostet. Dabei gibt es auch Rückschläge (diese Woche bei mir z.B.). Die z.Zt in diesem Land vielerorts herschende leicht panische Stimmung, befördert nicht, dass Leute produktiver werden. Du mußt da ziemlich stark sein und ehrlich gegenüber dir selber.

Gruß Axel

Navigation

[0] Themen-Index

[*] Vorherige Sete