Ich bin Manager. Wie kann ich die Arbeitsbeziehungen und die Kommunikation mit Programmierern verbessern? [geschlossen]

Ein kleiner Hintergrund zuerst. Ich bin Projektmanager bei einem mittelständischen Unternehmen. Ich habe als CS-Hauptfach angefangen und war ein wenig mit Programmieren vertraut, aber nach ein paar Monaten wusste ich, dass dies nicht mein Weg ist, und wechselte zum Management. Das hat sich als gute Entscheidung erwiesen, und nach meinem Abschluss habe ich (seit 5 Jahren) in verschiedenen Unternehmen im Softwaremanagement gearbeitet.

Vor kurzem hatten wir ein sehr schmerzhaftes Projekt. Es war das Schlimmste vom Schlimmsten, mit vielen Fehlern sowohl auf unserer Seite als auch auf der Kundenseite, die es kaum ohne Verluste beenden konnten. Es hat zu vielen frustrierenden Situationen geführt, von denen eine zu einem Punkt eskalierte, an dem einer unserer leitenden Entwickler das Unternehmen nach einem lautstarken Streit mit uns (dem Management) verließ. Das war eine rote Fahne für mich: Ich habe etwas Schreckliches falsch gemacht. (Für das Protokoll war das Argument über mehrere falsche Zeitschätzungen)

Ich suchte an vielen Stellen nach Antworten und ein Freund verwies mich auf diese Seite. Hier gibt es viele Fragen zu Frustrationen mit dem Management. Ich kann verstehen, dass die allgemeinen schlechten Erfahrungen zu einer allgemeinen Zurückhaltung gegen "die Typen in den Anzügen" führen.

Ich bin der Typ im Anzug. Es sieht vielleicht nicht so aus, aber ich möchte nur ein erfolgreiches Projekt und mit begrenzten Ressourcen werden schmerzhafte Entscheidungen getroffen. Das ist mein Beruf. Eines der Dinge, über die sich der erwähnte leitende Entwickler beschwerte, war die Arbeitsausrüstung. Ehrlich gesagt hatte ich keine Ahnung, dass die Computer, die wir hatten, nicht zum Arbeiten geeignet waren. Danach habe ich viele Programmierer gefragt und der allgemeine Konsens war, dass wir bessere Maschinen brauchen. Ich habe das seitdem behoben, aber es gab offensichtlich eine große Kommunikationslücke zwischen mir und den Programmierern. Einige der brillantesten Entwickler sind die schüchternsten und leisesten Leute. Ich weiß das und es war nie ein Problem während eines Interviews. Menschen sind unterschiedlich und haben Stärken in verschiedenen Bereichen.

Der Fall der leistungsschwachen PCs ist nur einer von vielen, die mich zu der Annahme veranlassten, dass es ein Kommunikationsproblem gibt. Wie kann ich die Kommunikation mit Programmierern verbessern, ohne mich einzuschüchtern und zu wiederholen?

Ich hoffe, dass sich die Leute nicht über gute Dinge beschweren. Wenn Sie Ihren Arbeitsplatz lieben und Ihren Vorgesetzten lieben (oder zumindest mögen :), teilen Sie mir dies bitte mit. Was machen sie richtig? Ebenso, wenn Sie es hassen, beschreiben Sie bitte im Detail, warum. Ich suche nach Antworten zur Verbesserung der Kommunikation, weil ich denke, dass das mein Problem ist, aber ich könnte mich irren.

Beeindruckend! Danke für die Frage. Technisch gesehen bin ich wie Sie Management, da ich viel mehr Zeit mit der Kommunikation und der Führung von Teams verbringe als mit dem Schreiben von Code. Egal, ob ich ein Entwickler oder ein Manager bin, der für einen anderen Manager arbeitet:

• Warum? ist eine sehr wichtige Frage - fast jede sachliche Antwort hat ein "Warum" dahinter und das "Warum" ist möglicherweise wichtiger als die eigentliche Frage. Dazu gibt es ein paar Tangenten:
  • Der Entwickler Warum - Entwickler werden viele Antworten haben, die für das Management absolut keinen Sinn ergeben. Das habe ich auf jeden Fall getan, und einer der Wege, die ich in das Management gekommen bin, bestand darin, das "Warum" des Teams in Bezug auf das Management wirklich gut zu erklären. Wenn Sie keinen "Sprecher für Geeks" zur Hand haben, können Sie lernen, Geek zu sprechen, indem Sie ihre Antworten auf die Warum-Frage in allgemeineren Metaphern wiederholen. Behalten Sie es bei, bis Sie beide verstehen und sich einig sind, was los ist.
  • Das Management Warum- Ihr "Warum" ist genauso wichtig. Warum brauchen Sie die Zeitschätzungen? Wofür benutzt du sie? Wie verrückt werden wir als Unternehmen sein, wenn sie zu hoch oder zu niedrig sind? Dies sind Dinge, die Sie als Manager wahrscheinlich genau kennen, aber das ist alles Voodoo für den Entwickler. Der Trick ist, der Entwickler darf nicht fragen. Das Management hat ihn um etwas gebeten, und er wird sein Bestes tun, um genau, rechtzeitig und nachdenklich zu sein - aber wenn er das "Warum" nicht kennt, optimiert er möglicherweise auf eine Weise, die Sie lieber nicht wissen. Geben Sie Ihr Warum an und fordern Sie ihn auf, dass er dasselbe tut - wiederholen Sie die Antwort in seinen eigenen Worten.

Über Zeitschätzungen speziell - ich musste eine Tonne tun und habe absolut davon profitiert, meinem Entwicklungsteam zu sagen: "Ich brauche das, weil ich mehr Geld für die Bezahlung unserer Gehälter verlangen werde. Ich werde darauf vertrauen, was Sie mir sagen und Ich werde Ihre Zahlen verwenden ... das heißt, wenn Sie mir auf den Fersen sind, sind wir alle durcheinander, weil ich kein zweites Mal um Geld bitten kann - wir müssen mit dem leben, was wir vorschlagen. " In diesem Zusammenhang haben die Entwickler von niedrigen Schätzungen, die mir zeigen wollten, wie selbstbewusst und brillant sie sind, zu hohen Schätzungen gewechselt, die den tatsächlichen Erwartungen viel näher kamen.

• Niemand hat Unrecht - Die "Warum" -Frage geht lange mit einer Konsequenz einher - die Frage nach dem "Warum" anstatt zu sagen "Das ist empörend! Auf keinen Fall!" hält das Gespräch am Laufen Manchmal gibt es eine starke Trennung zwischen dem, was jemand fragt, und dem, was der Fragende fragt. Mein bestes Management war schrecklich überrascht von meinen Antworten, und wenn sie überrascht sind, blinken sie erstaunt und fragen dann "Warum sagst du das?". Sie sagen nicht (sofort) - "Sie müssen es ändern". Ich habe die Anzahl der Vorschläge reduziert, um ein Wettbewerbsziel zu erreichen, aber erst nachdem ich intensiv darüber gesprochen habe, wie wir die Szene verändern und einen anderen Kontext für die Frage schaffen können.

• Achten Sie auf Umgebungsgeräusche, Wortwahl und den Abstand zwischen den Wörtern. Ich habe eine Reihe von Dingen gemocht und gestohlen, um mich selbst zu benutzen:

  • Hängen Sie im Arbeitsbereich ab, machen Sie etwas Produktives für sich selbst (versuchen Sie nicht, Entwicklerarbeit zu leisten, sie wissen, dass Sie kein Entwickler sind) und hören Sie einfach zu. Wie löst das Team Probleme? Was sind ihre großen Probleme? Sie werden nie erfahren, wie dünn die Leute sind, die Sie oder das Management im Allgemeinen direkt beurteilen, aber Sie bekommen möglicherweise ein gutes Gefühl dafür, wo sich die Problembereiche befinden. Stellen Sie sicher, dass Sie etwas Eigenes tun, das produktiv ist. Niemand mag es auszuspionieren, aber wenn die Moral nicht so niedrig ist, dass Sie nicht in der Nähe sind, ohne dass alle evakuieren, sollte die Produktivität in der Nähe tolerierbar sein.
  • Suchen Sie nach Wortwahlen - sie sind oft genauso wichtig wie die Wörter selbst. Wenn ich besonders positive oder negative Wörter verwendet habe, fragt mich mein Management häufig, warum ich diese Wörter gewählt habe, wenn es sich um eine Situation handelt, mit der sie nicht vertraut sind.
  • Achten Sie auf Pausen, Lücken und Körpersprache. Wenn es eine Machtdistanz zwischen Ihnen und den Entwicklern gibt (und es hört sich so an, als gäbe es sie), möchten sie Ihnen möglicherweise nicht widersprechen oder sich Ihnen stellen. Aber der Grundinstinkt zu sagen "Hey, du liegst falsch" manifestiert sich normalerweise irgendwo.

• Öffnen Sie sich für so viele Kommunikationsmedien wie möglich - seien Sie bereit, persönlich, telefonisch, per E-Mail, per IM zu chatten - alles und jeden, um den Kommunikationsfluss herzustellen. Die Menschen sind so unterschiedlich, dass nur ein Trick nicht funktioniert. Und ich sehe es als die Aufgabe des Managers an, der Multi-Format-Kommunikator zu sein, nicht der Entwickler.

• Es lohnt sich, mit Ihnen zu sprechen Wenn Ihnen jemand ein Problem und möglicherweise eine mögliche Lösung vorstellt, sollte und wird er wahrscheinlich akzeptieren, dass Sie der Manager sind, und sich daher möglicherweise für eine andere Lösung oder gar keine Lösung entscheiden, weil Sie dies nicht tun denke, es ist die Mühe wert. Aber nach dem dritten Mal passiert dies, besonders wenn es ohne Erklärung passiert, dass 99% der Leute aufhören, Ihnen irgendetwas zu erzählen.

Und hier ist eine, die unglaublich schwer für mich ist, aber großartig funktioniert hat, wenn ich es kann - beachten Sie den Unterschied zwischen Introvertierten und Extrovertierten . Die Chancen stehen gut, dass Sie extrovertiert sind - deshalb schien Ihr Job gut und eine Entwicklungsposition nicht. Entwickler sind größtenteils Introvertierte. "Introvertiert" bedeutet nicht "kann nicht kommunizieren", aber es bedeutet, dass sich Muster, Prozess und Geschwindigkeit erheblich unterscheiden und der Drang, unablässig zu kommunizieren, praktisch nicht vorhanden ist. Planen Sie die Zeit und den ruhigen (aber kollokierten) Raum ein, damit introvertierte Gedanken zum Vorschein kommen. Viele meiner introvertierten Freunde sagen mir, dass sie nur darauf warten, dass ich "für etwa 5 Minuten die Klappe halte", damit sie einen Gedanken zusammenstellen und antworten können. Hier'5 Dinge, die Extrovertierte über Introvertierte und Rands in Repose in der Nerd-Höhle wissen sollten - ein besonders für Entwickler schmackhaftes Beispiel dafür, was für Introvertierte großartig ist . Rands ist übrigens ziemlich fantastisch. Er ist selbst ein Freak, also kommt er von einem Entwickler-Fokus, der abschreckend sein kann, wenn das nicht dein Stil ist, aber er ist lustig und hat ein paar wirklich gute Einblicke in die Teamentwicklung.

Ich denke, die # 1 Dinge, die ich an meinen Lieblingsmanagern geliebt habe, waren:

• Sie waren genauso engagiert und aufgeregt über das Projekt wie ich (wenn nicht mehr)

• Ich hatte nie Zweifel, dass sie meinen Rücken hatten - ich wusste mit Sicherheit, dass ich (oder meine Kollegen) niemals die Scape-Ziege sein würden, wenn sie vor der nächsten Autoritätsebene standen. Es wäre immer ein Gruppenfehler, wenn es einen Fehler gäbe.

• Ich hatte das Eigentum an etwas Bedeutendem und Angemessenem, das für meine damaligen Fähigkeiten geeignet war, aber über genügend Ressourcen verfügte, um meine Fähigkeiten zu erweitern und die Arbeit zu erledigen.

• Sie sahen mich sowohl als Einzelperson als auch als Teil des Teams - sie waren aktiv dabei, meine Stärken und Schwächen zu kennen und mich dabei zu unterstützen, meine Stärken auszunutzen und meine Schwächen zu verstärken.

• Sie waren sich meiner persönlichen Ziele bewusst und waren daran interessiert, sie so weit wie möglich einzubeziehen

• Sie waren vorne mit dabei, als es mir nicht gelingen konnte und wollte, mich glücklich zu machen. Es ist sehr wichtig zu hören, "Ich weiß, dass Sie diese Art von Arbeit hassen, aber Sie müssen es tun - so wird es nicht für immer sein ...".

• In einer Woche war immer Zeit (vielleicht nicht im Augenblick), um das große Ganze zu erklären

• Es gab nahezu ständiges Feedback und Status ohne Fingerzeig, aber viel Anerkennung für die individuelle Arbeit.

• Es gab immer die Wahrheit. Wenn etwas sensibel war und nicht besprochen werden konnte, sagten sie dies aus nächster Nähe. Wenn etwas ungewiss war, gaben sie ein gewisses Maß an Vertrauen.

Der einfache Teil zuerst: Es gibt eine technische rote Fahne in Ihrem Beitrag: Ich schaudere , wenn Sie von "falschen Schätzungen" sprechen - es handelt sich um eine Schätzung, die NICHT FEHLERHAFT ist. Deshalb wird sie Schätzung genannt. Es kann ein wenig ausfallen, es kann einiges ausfallen, deshalb nennt man es eine Schätzung. Wenn Sie Schätzungen als Evangelium ansehen, wird dies eines der Hauptprobleme sein, die "Ihre" Entwickler mit Ihrem Stil haben.

Ich stimme Ihnen jedoch zu 100% zu, dass es schwierig ist, mit Entwicklern zu kommunizieren. Ich hatte vor einigen Jahren eine Offenbarung als Entwickler in einem Projektmanagement-Training. Ich habe gesehen, wie einige meiner Kollegen absolut gegen das Management protestiert haben, nachdem eine offene Diskussionsatmosphäre entstanden war (das Management war hier anwesend). Alles, was falsch war, war die Schuld der Manager in den Augen der Entwickler. Der Kicker war, dass das Management keine Ahnung von fast allen großen Problemen hatte, die an diesem Tag aufgeworfen wurden. Die Entwickler gingen davon aus, dass alles so offensichtlich war, dass das Management es unmöglich übersehen hätte, und das Management ging davon aus, dass die Entwickler ihnen sagen würden, was sie brauchen.

Aus diesem Grund muss der erste Teil der Antwort lauten, dass Ihre Entwickler wissen, dass Sie kein Hellseher sind, und in der Tat wahrscheinlich geradezu dumm, wenn es um die technische Seite geht. Sie verlassen sich darauf, zählen darauf und vertrauen darauf, dass sie rechtzeitig zu Ihnen kommen. Sie sind da, um ihr Leben leichter zu machen, nicht schwerer.

Und was auch immer Sie tun, stellen Sie ihnen KEINE Fragen, auf die Sie die Antwort eigentlich nicht wissen möchten - unter Bezugnahme auf die "falschen Schätzungen" oben ;-). Das ist der Kryptonit eines Entwicklers.

Es gibt eine Menge guter Sachen hier, aber ich denke, dass Folgendes gesagt werden muss. Tut mir leid, hart zu sein. Aber das muss gesagt werden:

• 5 Jahre als PM und nicht zu wissen, welche Art von PC ein Entwickler benötigt, ist empörend.
• Es ist verrückt, wenn ein Entwickler als erste echte rote Fahne wegen schlechter Arbeitsbedingungen gekündigt wird.

Ich denke, Sie haben ein Vertrauensproblem , mehr als ein Kommunikationsproblem. Niemand sagt, was falsch ist, weil sie nicht vertrauen, was Sie mit diesen Informationen machen werden, und vielleicht sogar befürchten, dass sie gegen sie verwendet werden. Der Entwickler, der Ihnen von all diesen Problemen erzählte, gab auf, weil dies keine Konsequenzen hatte.

Persönlich würde ich niemals einen PM einstellen, der keine Entwicklungserfahrung in seinem Hintergrund hat. Ich denke, bei deinem nächsten Projekt solltest du einen kleinen Teil deiner Zeit als Teil des Entwicklers verwenden. team . Sagen wir 8 Stunden pro Woche, als Jr. Entwickler unter der Leitung des Teams.

Dies wird Ihre Augen für die Dynamik eines Entwicklungsteams wirklich öffnen, denn im Moment sind Sie nicht einmal Teil dieses Teams, sondern ein Außenseiter. Die Tatsache, dass Ihr Dev-Austritt ein Schock für Sie war, beweist es. Jeder im Team wusste, dass er unglücklich war. Und keiner von ihnen hat dir gesagt:

"Wir werden unseren Besten verlieren, wenn du nichts tust."

Das sollte die rote Fahne Nr. 2 sein.

Ich bin mir sicher, dass Sie als Manager von Kaizen gehört haben , einem Grundsatz des Toyota-Produktionssystems, der eine kontinuierliche Verbesserung bedeutet .

Sie haben zugegeben, dass Sie ein Problem haben. Das ist also ein guter Anfang.

Kaizen hat fünf Hauptelemente:

• Qualitätszirkel : Gruppen, die sich treffen, um Qualitätsniveaus in Bezug auf alle Aspekte der Unternehmensführung zu erörtern.

• Verbesserte Arbeitsmoral: Die hohe Arbeitsmoral der Belegschaft ist ein entscheidender Schritt, um langfristig Effizienz und Produktivität zu erzielen, und Kaizen sieht es als grundlegende Aufgabe an, den ständigen Kontakt zur Arbeitsmoral der Mitarbeiter aufrechtzuerhalten.

• Teamwork : Ein starkes Unternehmen ist ein Unternehmen, das jeden Schritt auf dem Weg zusammenführt. Kaizen zielt darauf ab, Mitarbeiter und Management dabei zu unterstützen, sich als Mitglieder eines Teams und nicht als Konkurrenten zu verstehen.

• Persönliche Disziplin : Ein Team kann nicht erfolgreich sein, ohne dass jedes Mitglied des Teams in sich selbst stark ist. Die Verpflichtung jedes Mitarbeiters zu persönlicher Disziplin stellt sicher, dass das Team stark bleibt.

• Verbesserungsvorschläge : Durch das Anfordern von Feedback von jedem Mitglied des Teams stellt das Management sicher, dass alle Probleme untersucht und angegangen werden, bevor sie signifikant werden.

( Quelle )

Wenn Sie sich das genauer ansehen, ist eine Konstante über diese Elemente der Schwerpunkt auf Teamarbeit und Feedback.

Ein Beispiel, Sie sagen, Sie hatten einen Streit über Zeitschätzungen. Sind Sie für diese Zeitschätzungen verantwortlich? Sprichst du mit dem Team darüber? Es tut mir leid, aber ich habe gesehen, wie Manager einfach eine Nummer aus ihrer Liste gezogen haben. Eine wichtige Sache: Feilschen Sie niemals mit Zeitschätzungen, die Ihr Team Ihnen gibt. Viele Manager stellen sich vor, dass sie kürzere Fristen einhalten können, wenn ihr Team härter arbeitet. Das ist eine Lüge. Neun Frauen können in einem Monat kein Kind bekommen.

Also mein erster Rat:

Hören Sie zu : Beginnen Sie mit einer einfachen E-Mail an das Team: "Wie kann das Entwicklungsteam dem Management am besten Feedback zur Managementleistung geben?". Iterieren Sie mit dem Team und setzen Sie den Konsens um. Ihre Aufgabe ist es, das Team in die Lage zu versetzen, großartige Software zu entwickeln, und nicht, sie zu hüten. Behalte dies im Kopf.

Ehrlichkeit und Loyalität : Wenn niemand antwortet, wenn Sie etwas fragen, liegt das daran, dass er nicht glaubt, dass Sie zuhören werden, oder, schlimmstenfalls, dass Sie ihn dafür bestrafen werden. Also sei ehrlich. Wenn jemand sagt, dass Sie saugen, nehmen Sie dies als Feedback und nehmen Sie keine Rache. Verstehe ihre Gründe, verbessere sie.

Und, obwohl ich hier einige Kritiken dazu gesehen habe, möchte ich Ihnen empfehlen, ein Buch mit dem Titel Der Monat des mythischen Mannes: Essays on Software Engineering zu lesen . Das Buch handelt von Fred Brooks Erfahrung bei IBM während der Entwicklung von OS / 360. Während hier und da ein paar Dinge veraltet sein mögen, ist dies der erste Schritt, um zu verstehen, wie der Entwicklungsprozess komplexer Software funktioniert. S.Lott zitiert das Agile Manifest , das ich nicht besonders mag , aber es ist auch lesenswert.

Lesen Sie dies:

http://agilemanifesto.org/

• Individuen und Interaktionen über Prozesse und Werkzeuge

• Arbeitssoftware über umfangreiche Dokumentation

• Zusammenarbeit der Kunden bei Vertragsverhandlungen

• Reagieren, um nach einem Plan umzuschalten

In vielen Fällen verlangt die Organisation (dh Ihr Chef), dass Sie

• folge einem klar gebrochenen Prozess bis zu seiner logischen Schlussfolgerung, die zu einem "Todesmarsch" führt. Dies führt wiederum zu Auseinandersetzungen und Rücktritten.

• Erstellen Sie übermäßige, nicht verwendete Dokumentation mit geringem Wert.

• Komplexe Änderungskontrollen durchführen und Vertragsverhandlungen führen. Jeder Benutzerwechsel erfordert ein aufwändiges Ritual, um die Änderung zu "qualifizieren" und zu "priorisieren". Es geht wirklich nur um das "Einfrieren" - das Verhindern von Veränderungen.

• Befolgen Sie den Plan unabhängig von den Konsequenzen. Einige Unternehmen legen Wert auf die pünktliche Lieferung defekter (oder sogar unbrauchbarer) Software. Es ist der Plan, der geschätzt wird, nicht die Lösung eines Geschäftsproblems.

Es kann sein, dass das Problem nicht Ihre persönlichen Kommunikationsfähigkeiten ist.

Es kann sein, dass die gesamte "Entwicklungsumgebung" oder "Methodik" tödlich gebrochen ist und schlechte Gefühle nur ein Symptom für allgemeine schlechte Praktiken sind.

Für mich hört sich das so an, als hättest du nie in einer lockeren Atmosphäre mit den Entwicklern gesprochen. Ihre Gespräche mit ihnen waren nur offizieller Natur? Das ist sehr schade.

Warum lernst du sie nicht persönlich kennen und erfährst so, was gut und was schlecht am Unternehmen, an ihrem Arbeitsplatz und an ihren Projekten ist? Respektiere sie und verdiene dir ihren Respekt, indem du aufrichtiges Interesse und Wertschätzung für ihre Arbeit zeigst.

Wenn sie dir vertrauen und keine Angst haben müssen, Bauernangebote zu sein, werden sie dir höchstwahrscheinlich sogar unattraktive Wahrheiten sagen.

Ich bin ein Teamleiter und mein Team vertraut mir. Ich beschütze sie. Ich nehme alle Schuld auf mich und teile den Ruhm mit ihnen. Unser Management schützt mich. Das steigert die Moral. Wir hatten ein wirklich hartes Projekt und einen beinahe bösen Kunden, der fast unmöglich zu Ende zu bringen war, aber wir haben es schließlich getan, weil wir sehr offen und offen über alles gesprochen haben.

Klatschen! Klatschen! Klatschen! Sie sollten auf jeden Fall ein guter Mensch sein, denn Sie haben sich offen gezeigt, was getan werden kann, um Ihre Arbeit zu verbessern.

Nachfolgend finden Sie, was ich in einem großartigen Manager miterlebt und persönlich adoptiert habe, als ich das Team als leitendes Mitglied geführt habe.

• M entor mehr als managen.
• Ein geringes Teammitglied, um seine Gedanken und Bedenken zu äußern. Seid ganz Ohr dafür. Nehmen Sie die konstruktiven.
• Verrate niemals Teammitglieder, indem du spaltende Politik spielst. Das feuert schneller und leiser zurück.
• Ein Neger nicht. Niemals Grimassen im Gesicht haben, wenn Sie mit Ihrem Team zusammen sind, kommen Sie, was auch immer mag. Dieser ist wirklich schwierig.
• G eifrig und offen den Gewinner für seine gute Arbeit zu schätzen. In der gleichen Breite, sehr sanft und taktisch kritisieren die Arbeit nicht Person für irgendwelche Ungerechtigkeiten, an die Person, die verantwortlich ist, isoliert und nicht offen.
• E ncourage Eigentum und Führung in jedem einzelnen. Dies fördert die Moral und das Engagement des Menschen, weil er sich respektiert fühlt.
• R OAM um mit Ihrem Team einmal in einer Weile. Dieser induziert / erhöht die Bindung innerhalb der Teammitglieder.

Wünsche dir viel Glück in deinem aufrichtigen Bemühen :)

Im Allgemeinen fühlen sich die Jungs in den Schützengräben meuterisch, wenn sie das Gefühl haben, dass ihre Griffe nicht von Menschen gehört werden, die die Situation verbessern können und werden. Wenn sie nicht einmal das Gefühl haben, dass sie sich beschweren können, ohne ihr Ansehen in der Firma zu riskieren, ist das noch schlimmer.

Ich bin ein Theory-Y-Typ und die meisten "Wissensarbeiter" neigen dazu; Wenn wir eine Chance haben, mögen wir unsere Arbeit und wollen sie gut machen. Der Nachteil eines Theory-Y-Arbeitsplatzes ist jedoch, dass es möglicherweise nicht sofort offensichtlich ist, dass es ein Problem gibt, da Menschen, die gute Arbeit leisten und daher keine Wellen schlagen möchten, Wege finden, um dieses Problem zu umgehen, oder es einfach ignorieren. Dies führt zu aufgestauten Frustrationen, die schließlich im Gesicht des gesamten Teams explodieren. Ein Laden, der von einem Theory-X-Manager betrieben wird, hat wahrscheinlich Leute, die sich viel früher beschweren. die mitarbeiter sind nur für das geld dabei, also wenn der job mehr als sonst nervt, werden sie meckern.

Was Sie in einer Umgebung mit Senioren und leitenden Angestellten tun können, die die Arbeit erledigen, ist Ihr bestes Kapital. Rede mit ihnen. Sie können 30 Minuten pro Woche für "Zweiwege" einplanen, bei denen die Leads Sie über Aktualisierungen und aktuelle Probleme im Zusammenhang mit dem Projekt informieren. Außerdem geben Sie ihnen Aktualisierungen auf der Geschäftsseite und planen mit ihnen, um Probleme zu lösen bevor sie zu Problemen werden, die das Team ernsthaft betreffen.

In Agile hat am Ende jedes "Sprints" oder jeder "Iteration" (eine Einheit der Entwicklungsarbeit, die normalerweise zwischen einer und drei Wochen dauert) das gesamte Team, vom jüngsten Mitglied bis zum Premierminister, eine "Retrospektive" ". Sie blicken zurück auf das, was sie getan haben, was richtig gelaufen ist, was nicht und identifizieren Dinge, die sie weiterhin tun und die sich ändern müssen. Es gibt verschiedene Formate, und Sie können Ihre eigenen erfinden, aber das Ergebnis des Retros sollte sein, dass die Leute das Gefühl haben, ihre Stimme gehört zu haben, und dass sich die Dinge dadurch ändern.

Apropos Agilität; Mein erster Job war für eine kleine Firma, und mit "klein" meine ich, dass die ganze Firma kein Softballteam aufstellen konnte. Als ich anfing, gab es vier Programmierer, und der ging auf zwei zurück, bevor ich ging. Der Gründer, Präsident, CEO und 95% der Anteilseigner des Unternehmens entschied mit eiserner Faust, und er war die einzige Planungsquelle in der Organisation, was bedeutete, dass es nicht viel gab. Der Boss war ein Workaholic und erwartete, dass es auch alle anderen sein würden. Alles, was Sie zu geben hatten, war nicht mehr oder weniger als er erwartet hatte, und dafür zahlte er ein Einstiegsgehalt an Leute, die ein Jahrzehnt lang für ihn gearbeitet hatten.

Ich verließ diese Firma und begann bei einer anderen Firma zu arbeiten, die die Dinge SEHR anders machte. Sie übten die SCRUM Agile-Basismethode mit täglichen Stand-ups, Pair Programming, Sprint-Teams und Rückblick. Zu Beginn jedes Sprints haben wir alle zwei Wochen einen Tag lang nur die nächsten zwei Wochen geplant. Für einen großen Teil eines anderen Tages haben wir nichts anderes getan, als auf das zurückzublicken, was wir getan hatten, und Wege zu finden, uns als Team zu verbessern. Neben mir saßen Entwickler, die Microsoft-MVPs waren, die ihre Arbeit erledigten und mich ermutigten und ergänzten.

Nacht. Und. Tag. Der Hauptunterschied? Erstens hatte ich nicht das Gefühl, dass ich mich für das Projekt umbringen sollte. Ein grundlegender Grundsatz von Agile ist das nachhaltige Entwicklungstempo. Zweitens hatte ich eine Stimme bei der Entscheidung, wie ich meine Arbeit machen sollte. Ich musste die Arbeit machen, aber wenn ich über das, was ich im nächsten Sprint erwarten würde, "Sodbrennen" hätte, könnte ich diese Meinung äußern und sie würde gehört und gewichtet werden. Wenn ich das Gefühl hätte, dass es einen besseren Weg gibt, könnte ich das sagen und es wäre unterhaltsam.

Bei der Suche nach Lösungen und der Lösung von Problemen müssen Sie darauf achten, dass Sie nicht von oben nach unten arbeiten. Für Computer; Angenommen, Ihre RMR (wiederkehrende monatliche Einnahmen) ermöglicht es dem Unternehmen nur, vier Computer alle zwei Wochen zu aktualisieren. Die ersten vier Computer sollten nicht alle an die Leads und Senioren gehen; Sie sollten zu den Leuten mit den langsamsten Computern gehen. Wenn Sie dem Team Boni geben, geben Sie diese nicht nur an "unsere wertvollen Senioren und Leads, ohne die dies nicht möglich gewesen wäre". JEDER in Ihrem Entwicklerteam hat es möglich gemacht. Wenn ein Junior eine Beschwerde hat, hören Sie ihn an. Nur weil er ein Junior ist, heißt das nicht, dass er nichts weiß.

Verbesserung der Beziehungen:
Hatten Sie gerade ein hartes Projekt? Machen Sie danach eine Pause. Urlaubszeit, um sich zu entspannen, den Atem zu holen.
Coders Bill of Rights Diese Dinge sind eine Selbstverständlichkeit . Grundlegende Dinge, die selbstverständlich sein sollten. Wenn Sie diese missachten, missbrauchen Sie Ihre Codemonkeys.
Dem Joel-Test stimme ich den meisten zu. Aber einige hängen wirklich davon ab. Wenn Sie etwas vermissen, machen Sie Ihren Programmierern wahrscheinlich das Leben schwerer, als es sein muss.
Technische Schulden . Sie können also auf die Fertigstellung drängen, müssen sich jedoch darüber im Klaren sein, dass Sie technische Schulden haben, deren Behebung zu einem späteren Zeitpunkt mehr Zeit in Anspruch nimmt. Wenn dieses Datum vor dem Ende des Projekts liegt, haben Sie es wirklich vermasselt.
RSA-Animation: MotivationDies ist ein fantastisches Stück, das wirklich zeigt, wie man Wissensarbeiter motiviert.
Freier Tag, um zu programmieren, was sie wollen. Aus dem RSA-Video. Erinnern Sie sich nicht an den Namen, aber die Firma, die darin erwähnt wird, hat eine kurze Erklärung auf ihrer Website. Scheint mir eine gute Idee zu sein. In den meisten Geschäften gibt es Dinge, von denen jeder weiß, dass sie kaputt sind, aber niemand hat Zeit, sie zu reparieren, und es hat keine hohe Priorität. Dies ermöglicht es ihnen, technische Schulden in den Griff zu bekommen. Sie können damit auch ihre brillanten Ideen zur Schau stellen.

Versuchen Sie aus Liebe zu Gott, eine 40-Stunden-Woche einzuhalten. Auch Gleitzeit. Gleitzeit kann eine ganze Welt der Scheiße ausgleichen. Für mich zumindest.

Verbesserung der Kommunikation zwischen Programmierern und Chefs
Das ist schwieriger für mich. Diese ganze Sache ist mehr ein Boss-Skillset als der Fokus eines Programmierers. Ich könnte sagen, einige grundlegende Dinge wie Zeitschätzungen sind nur Schätzungen. Auf dem Wasser zu gehen und die Anforderungen zu erfüllen, ist einfach, wenn sie gefroren sind. Vielleicht bitten Sie die schüchternen Programmierer, bei einer Codeüberprüfung oder so etwas einen Vortrag über ihr Projekt zu halten. Übung macht den Meister, oder? Aber ich würde mich den Ratschlägen anderer beugen.

"Ebenso, wenn Sie es hassen, beschreiben Sie bitte im Detail, warum."
Nun, das wird hier die Schleusen öffnen. Und wenn ich keine openID verwenden würde, die offensichtlich mit mir verbunden sein könnte, würde ich wahrscheinlich auch entlüften. Wenn Sie wirklich eine riesige Liste von Dingen haben möchten, die Sie nicht tun sollten, fragen Sie in einem Forum nach, das für anonyme Beiträge besser geeignet ist.

Ich habe immer festgestellt, dass die Leute Sie im Allgemeinen nicht besser behandeln als Sie (obwohl sie Sie möglicherweise schlechter behandeln). Ich persönlich (ich bin ein Entwickler) antworte auf Ehrlichkeit mit Ehrlichkeit, auf Respekt mit Respekt, auf Vertrauen mit Vertrauen und so weiter. Sie sollten in einer neutralen Atmosphäre ein informelles Gespräch mit Ihrem Team führen und ihm sagen, was Sie uns gerade gesagt haben. Der Punkt, in dem toxischen „wir gegen sie“ Umgebungen vergessen wird ist , dass es sollte alles sein „uns“. Sowohl das Management als auch die Mitarbeiter müssen das wissen, und das Unternehmen muss das unterstützen.

Viel Glück.

Sie können nachweisen, dass Sie Feedback nicht nur akzeptieren, sondern auch darauf reagieren. Sie haben gezeigt, dass Sie Einfluss auf höhere Entscheidungsträger haben, und Sie können Dinge für Ihr Team erledigen. Das macht einen großen Unterschied. Programmierer sind zwar introvertierter, aber wir sprechen gerne über Programmierung. Eine informelle Umgebung ist nett, aber jeder muss trotzdem professionell sein. Erlauben Sie den Leuten, etwas abzulassen, aber stellen Sie sicher, dass die Diskussionen produktiv sind und nicht nur eine Schlampensitzung.

Aus meiner Erfahrung ist es für mich am wichtigsten, meinen Manager zu mögen oder nicht zu mögen, wenn er / sie die Entwicklung im Allgemeinen versteht und die Arbeit versteht, die ich tue. Einige positive Ergebnisse sind hier aufgelistet:

• Ich muss nicht zu viel Zeit verschwenden, um zu rechtfertigen, warum eine Änderung so lange dauert oder nicht durchgeführt werden kann. Technisch gesehen kann jede Änderung umgesetzt werden, und das obere Management fordert normalerweise die Umsetzung auf irgendeine Weise. Aber zumindest in einer solchen Situation ist Ihr direkter Manager auf Ihrer Seite und bittet um mehr Zeit (anstatt Sie zu drängen oder auszubrennen).
• Ich weiß, dass ich eine bessere Chance habe, in einer schlechten Situation (einem WTF-Hack, einem Produktionsproblem usw.) unterstützt zu werden. Normalerweise neigen nicht-technische Personen dazu, dem Entwickler die Schuld für eine solche Situation zu geben, während ein guter Manager VERSTEHT, was wirklich vor sich geht, und seinen / ihren Entwickler unterstützt (nicht nur weiß oder bereit ist, es so zu nehmen, um nett zu sein).
• Ich weiß, dass meine Arbeit und Leistung von einer geeigneten Person bewertet werden muss.

Meiner Meinung nach ist die Wahrscheinlichkeit, dass Ihre Entwickler dies mögen, sehr gering, wenn Sie nicht mehr programmieren und normalerweise einen engen Projektzeitplan oder ein knappes Budget haben. In diesem Fall ist es besser, schnell aufzusteigen und jemanden als direkten Manager zu beauftragen. Es tut mir leid, dass ich mich in diesem Absatz schlecht angehört habe, aber ich sehe das so. Ihr scheint ein guter Mensch zu sein und verdient etwas Wahrheit.

Ich bin auch einer der Typen in einem Anzug, und das schon seit mehr als 15 Jahren. Ich war ein Softwareentwickler, als ich anfing, und ich schreibe immer noch Code, wenn ich die Gelegenheit dazu bekomme. Ich denke, ich kann für beide Seiten sprechen und habe ein bisschen Erfahrung in diesen Situationen. Ich habe auch Referenzen wie "Mitarbeiter des Jahres", die von den Mitarbeitern gewählt werden und die mich zuversichtlich machen, mit diesen Situationen umzugehen.

Was ich sehr oft erlebe, ist, dass es zwischen Management und Entwicklern erhebliche Unterschiede in den Wertesystemen und operativen Methoden / Ansätzen gibt.

Für viele Entwickler stehen Aufrichtigkeit, Ehrlichkeit und ansonsten ein flexibles Arbeitsumfeld ganz oben auf der Liste. Leider stehen die gleichen Werte nicht ganz oben auf der Liste der Top-Manager. Und dies führt unweigerlich zu gewaltigen Auseinandersetzungen, insbesondere wenn sich das mittlere Management (Sie und ich) dafür entscheidet, die oberste Führungsebene vollständig zu übernehmen. Der einzige Ausweg (aus meiner Sicht) besteht darin, eine feste Position vor Ihrem Team einzunehmen, diese zu unterstützen und durch offene Kommunikation und vor allem durch das, was Sie sagen, eine Vertrauensbeziehung aufzubauen (Das ist oft das Gegenteil von dem, was Sie vom Top-Management erhalten, wo die Politik die Aufrichtigkeit völlig überwältigt).

Gleichzeitig müssen Sie selbst einsatzbereit bleiben, um mit dem Top-Management in einer Sprache kommunizieren zu können, die sie verstehen und die sie spielen. Das ist die wahre Herausforderung des mittleren Managements.

Ich glaube, dass mit der Zufriedenheit der Entwickler die Produktivität auf die kleinen Dinge ankommt. Die Mathematik ist für das Management ziemlich gut. Gib mir morgens einen Donut (-25 Cent) und ich werde den ganzen Tag doppelt so hart arbeiten (+ viele Dollar). Es ist nicht so, dass wir Dinge aktiv sabatieren, indem wir langsam arbeiten, wenn wir unzufrieden sind, es ist so, dass wir an extrem komplizierten Systemen arbeiten und es extrem schwierig ist, uns zu konzentrieren, wenn wir über etwas frustriert sind. Es ist wirklich wahrscheinlich besser, dass wir nicht so viel programmieren, wenn wir wütend sind.

Schätzungen müssen jedoch von sich aus berücksichtigt werden. Jedes Problem, das ich habe, kann gelöst werden, indem ich einen Donut erhalte, mit Ausnahme von unrealistischen Schätzungen . Richtig oder falsch, so sieht es ein Entwickler: Das Management hat alles zu gewinnen (wie ein neues Boot), während der Entwickler alles zu verlieren hat (wie ein Monat Schlaf). Das Management ist jedoch verantwortlich, sodass sie jedes Mal den geschätzten Krieg gewinnen. Ich denke, das Schätzsystem funktioniert am besten, wenn Entwickler die Frist festlegen (es ist schwierig genug für uns, eine genaue Schätzung abzugeben, wie würde es ein Manager tun?), Aber das Management motiviert sie positiv, ehrgeizig zu sein, mit dem Verständnis, dass kein Entwickler dafür gefordert wird ein bisschen aus.

Überlegen Sie, welche Art von Reaktion Sie einem Programmierer geben, der Fragen, Kommentare oder Bedenken hat. Gibt es ein "Was willst du jetzt ?" oder "Warum belästigst du mich damit ?" eine Art Antwort? Wie gut können Sie die Entwickler ermutigen, Bedenken und Kommentare zu äußern? Das ist jedoch nur ein Ausgangspunkt.

Zweitens: Achten Sie darauf, wo Sie diese Diskussionen führen möchten. Ich bezweifle, dass ich sehr offen sein würde, meine Arbeitsmaschine mit jemandem im nächsten Würfel zu besprechen, wenn ich wüsste, dass mein Manager in Hörweite ist, um die ganze Sache zu hören. Wenn Sie möchten, dass die Leute offen und ehrlich Feedback geben, müssen Sie etwas Privatsphäre wahren, damit Sie wissen, dass ihre Antworten nicht öffentlich ausgestrahlt oder gegen sie verwendet werden.

Drittens überlegen Sie, welche emotionalen Intelligenzfähigkeiten Sie haben. Emotionale Intelligenz für Projektmanager: Die Fähigkeiten der Mitarbeiter, die Sie benötigen , um herausragende Ergebnisse zu erzielen, von Anthony Mersino, wäre eine Buchempfehlung, die ich gestern bei einem Mittagessen erhalten habe und die sich mit EQ befasst. Wenn Sie hier wirklich tief in die Psychologie eintauchen möchten, gibt es verschiedene Persönlichkeitsprofil-Tools, die verwendet werden können, z. B. Enneagramm, soziale Stile und MBTI.

Überlegen Sie abschließend, welche Kultur in Ihrem Unternehmen herrscht. Werden Fehler unter den Teppich gekehrt? Sind Beschwerden ein großes Nein, das leicht jemanden in Schwierigkeiten bringen kann? Welche Verhaltensweisen werden belohnt oder gefördert und welche werden toleriert und akzeptiert? Während ein Teil davon Beobachtung ist, kann ein Teil auch einige Gespräche erfordern, die entweder außerhalb des Büros oder in einem Raum stattfinden sollten, in dem es wahrscheinlich nicht zu Lauschangriffen kommt. Sie werden wahrscheinlich wiederholt versuchen, dies am Anfang zu verwenden. Das ist keine schlechte Sache, wenn Sie versuchen, eine neue Praxis zu etablieren und die Leute dazu zu bringen, sich zu äußern, wenn die Kultur in erster Linie eine war, bei der jeder wusste, dass er es "aufsaugen" sollte. Das mag empfindlicher sein als andere Antworten, aber das wäre, was ich

Glauben die Entwickler, dass Sie ihr Anwalt sind? Damit meine ich, dass sie wissen, dass sie frei sind, ihre Sorgen / Frustrationen mit Ihnen zu teilen, ohne geschlagen zu werden? Haben sie das Gefühl, dass Sie für sie kämpfen? Haben sie das Gefühl, dass Sie ihre Arbeit schätzen? Haben sie das Gefühl, dass Sie wirklich wollen, dass sie in ihrer Karriere Erfolg haben?

Wenn sie sich geschätzt fühlen, haben Sie wahrscheinlich eine bessere Kommunikation.

Als Entwickler bin ich ein großer Nerd und habe keine sozialen Fähigkeiten und ich entschuldige mich nicht dafür. Immerhin bin ich das Talent und du hast mich für mein Talent engagiert. Wenn Sie einen Social-Butterfly-Partner benötigen, um die Arbeit zu erledigen, haben Sie einen Raum voller Projektmanager anstelle von Entwicklern.

Ich weiß, dass einige Entwickler sehr klug sind, aber ich denke, der Median tendiert zu introvertiertem Nerd.

Wenn mich jemand auffordert, etwas zu tun, kann ich absolut keine Schlussfolgerungen ziehen und genau das tun, was verlangt wird. Es scheint, als ob ich bei einigen Projektmanagern immer Probleme habe, weil sie von mir erwarten, dass ich Rückschlüsse auf ihr Projekt ziehe, was ich absolut nicht tun werde. Manchmal laufen die Dinge also nicht so, wie sie es erwarten, obwohl sie genau das sind, was sie sind sie haben angefordert. Ich denke, der Grund, warum dies bei einigen Projektmanagern vorkommt, ist, dass sie keine qualitativ hochwertigen HLDs und BRDs liefern und dem sozialen Aspekt des Projektmanagements zu viel Wert beimessen, anstatt dem, was in Schwarzweiß dargestellt ist.

Ich denke, dass hier Welten kollidieren. Ich denke in der Welt des Projektmanagements sind die sozialen Fähigkeiten und die Qualität der persönlichen Offenheit wichtige Faktoren, aber für Entwickler wie mich bedeutet dies absolut nichts. Es beeindruckt mich nicht, darüber zu jammern, wie wichtig diese oder jene Aufgabe ist. Ich möchte nicht einmal zum Mittagessen ausgehen oder Bier trinken, wie es einige Leute hier vorgeschlagen haben.

Was ich wirklich will, sind gute, hochwertige HLDs und BRDs. Ich möchte Zeitpläne und Fristen, die erreichbar sind, und wenn neue Entwürfe oder Pläne eingeführt werden, möchte ich, dass der Zeitplan und die Fristen neu angepasst werden. Ich habe an Projekten gearbeitet, bei denen sich die Anforderungen augenblicklich zu ändern scheinen - für mich ist dies meine rote Fahne, dass ich es mit einer Projektleitung von schlechter Qualität zu tun habe. Das Schlimmste, was Sie als Entwickler tun können, ist, dass Sie mir täglich neue Projektanforderungen stellen, insbesondere, wenn wir bereits einen Zeitplan haben oder Terminvereinbarungen getroffen haben. Es ist unerträglich, wenn neue Anforderungen eingehen, ohne dass Fristen eingehalten werden. Ich arbeite mehr Stunden, arbeite spät, ich habe kein Problem damit, aber es ist nicht etwas, das bei der Entwicklung immer quantitativ ist. Einige Änderungen können einige zusätzliche Stunden dauern. Einige Änderungen können Wochen in Anspruch nehmen, um F & E, Tests, Qualitätssicherung usw. ordnungsgemäß durchzuführen. Es ist nicht immer so, als würde man einen Kuchen backen. Manchmal kann eine einzelne Änderung der Anforderungen bedeuten, dass das gesamte Rezept geändert wird. Ich habe miterlebt, wie Projektmanager bei Telefonkonferenzen zusammenbrachen und Wutanfälle hatten, weil ihre Fristen die zusätzliche Entwicklung nicht zulassen, sie jedoch nach einer Entwicklung fragten, die nicht ihren ursprünglichen Projektanforderungen entsprach.

Ich kann nur meine persönliche Voreingenommenheit und Erfahrung als Beispiel geben. Bitte schließen Sie nicht, dass ich im Namen aller Entwickler spreche. Ich sehe diese Dinge nur durch den Mikrokosmos meiner eigenen Karriere, aber dieser Beitrag beschreibt die genauen Bedingungen, unter denen ich das sprichwörtliche Handtuch geworfen habe.

Wie oft sprichst du mit deinen Entwicklern? Ich meine nicht Projektstatusmeetings, Fragen zu Ergebnissen oder anderen Themen, die Sie an sie richten - wie oft setzen Sie sich mit einem Ihrer Programmierer zusammen, fragen sie nach dem Stand der Dinge und hören ihnen einfach zu .

Viele der anderen Antworten sind wirklich gut - Sie sollten sich mit agiler Entwicklung befassen. Sie brauchen Ihre Entwickler, um zu lernen und in ihren Rollen zu wachsen. Aber wenn Sie nicht genau zuhören, was Ihre Entwickler sagen (oder nicht!), Müssen Sie sich zuerst darum kümmern.

Gute Referenz zu Einzelgesprächen - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Kurz und bündig. Excel bei dem, was Sie tun - das wird die Kommunikation erzeugen.

Was bedeutet Hervorragendes für Ihre Entwickler? .. Lesen, nochmal lesen, ja sogar PeopleWare studieren

Alle tollen Ideen und Kommentare in den obigen Beiträgen!

Hier ist eine Idee: Schicken Sie Ihre IT-Mitarbeiter zu Kommunikationsworkshops an Ihr lokales Community College - natürlich von der Firma bezahlt.

Stellen Sie sicher, dass a) die Werkstätten einen guten Ruf haben und b) Ihre Mitarbeiter nicht zusammenschicken. Sie werden dazu neigen, zusammen zu bleiben und sich nicht mit den anderen Klassenmitgliedern zu vermischen, was nicht nur den Wert der Workshops verringert, sondern auch die anderen stört.

Produktive teamorientierte Kommunikation ist eine Fähigkeit, die jeder erlernen kann, aber ein Thema, das meiner Meinung nach auf den meisten akademischen Pfaden fehlt.

Diese Idee ist in keiner Weise magisch, aber sie ist ein gutes Grundelement des Puzzles. Nicht nur, dass Ihre Mitarbeiter lernen, besser miteinander zu kommunizieren, sondern auch, dass sie beginnen, IHRE Arbeit besser zu verstehen und zu respektieren (Kommunikation ist der Kern von PM).

Nur meine 2 Bits :)

Nur um aus einer Empfehlung eine Antwort zu machen, die bereits in einigen Antworten auftaucht . Michael Lopp (aka rands ) wurde das Schreiben über die Entwickler die Verwaltung und "immer in den Köpfen" in seinem Blog, Rand in der Ruhe und in einem Buch, Managing Humans ( Buch Quellen ). Das Buch enthält hauptsächlich bearbeitete Inhalte aus seinen Beiträgen vor 2007 und bietet eine gute Möglichkeit, sich mit den verwaltungsbezogenen Teilen seines Blogs vertraut zu machen (er spricht auch über z. B. Glücksspiele und darüber, ob Sie dies auch lesen möchten). Sein Schreiben ist im Allgemeinen großartig und oft humorvoll, so dass das Risiko, ihn zu lesen, gering ist.

Nehmen Sie das Team für Bier (und Sie kaufen).

Ich bin zu spät zur Party, habe aber gerade diese Frage gesehen.

Eine Sache, die ich nicht sehr gut angesprochen sehe, ist die folgende:

Grunzer sagen den Anzügen nie die ganze Wahrheit. Rands sagt dies in der DNA , spricht es aber nicht direkt an, er befasst sich mit einem anderen Thema.

Sie tragen einen Anzug und unterschreiben die Schecks. Sie vertreten die Interessen des Unternehmens. Sie vertreten nicht die Ingenieure. Wenn Sie dies tun würden, würden Sie nicht ihre Schecks unterzeichnen, sondern Ihre.

Dies ist natürlich keine Neuigkeit für Sie oder die Ingenieure. Aber wenn ein Ingenieur weiß, dass bestimmte Probleme - Probleme - mit seinem Arbeitsplatz zu erheblichen Konflikten führen würden, begünstigt der Risiko / Ertrag-Kompromiss den Ingenieur nicht. Ingenieure werden dafür bezahlt, Produkte zu produzieren, statt Kämpfe um die Arbeitskultur auszulösen. Sich darauf einzulassen, ist ein schneller Weg, um den Job falsch zu machen.

Teil der Managementaufgabe ist es daher, den Ingenieuren eine Möglichkeit zu bieten, offen für Probleme zu sein, ohne dass es zu einer Rückwirkung auf die Unternehmenspolitik und die Karriere kommt. Es ist immerhin schön, Erhöhungen zu haben, und es gibt andere Unternehmen, wenn sich dieses Unternehmen nicht sympathisch anfühlt.

Ich bin überrascht, dass niemand dieses großartige Buch erwähnt hat, das sich genau mit Ihrer Frage und Ihrem Thema befasst - "Peopleware: Productive Projects and Teams" von DeMarco und Lister . Aus dem Editorial: Die Hauptprobleme bei der Softwareentwicklung sind menschliche und keine technischen . Die ersten drei Rezensionen zu amazon würden leicht ausreichen, um mich zu überzeugen, dieses Buch zu kaufen, wenn ich in Ihrer Situation wäre.

Viele der Antworten hier haben sehr gute Punkte, aber ich möchte nur ein paar Ressourcen einwerfen, die helfen könnten. Ich war in einigen Situationen, die entweder in einem riesigen Durcheinander zusammengebrochen sind oder aufgrund der Kommunikation zwischen den beteiligten Personen sehr effizient gelöst wurden. Drei Bücher haben mir geholfen, meine Kommunikationsfähigkeiten persönlich zu verbessern, insbesondere in Situationen mit hohem Stress, in denen viel auf dem Spiel steht:

• Schwierige Gespräche: Wie man bespricht, was am wichtigsten ist
• Entscheidende Gespräche: Hilfsmittel für Gespräche bei hohen Einsätzen
• Entscheidende Konfrontationen: Tools zum Auflösen gebrochener Versprechen, verletzter Erwartungen und schlechten Verhaltens

Wenn Sie Ihre Frage lesen, werden Sie den Wert der Kommunikation erkennen. Ich persönlich bin der Meinung, dass Kommunikation für einen Manager oder eine Führungskraft wichtiger ist als geschäftliche oder technische Fähigkeiten. Die Leute, die Sie leiten, sollten die harten Fähigkeiten haben, die Sie benötigen, um den Großteil des Projekts zu erledigen. Ein guter technischer Leiter oder Projektmanager sollte sich auf die Kommunikation konzentrieren können, sei es innerhalb des Teams oder zwischen dem Team und dem Kunden oder dem Team und der Geschäftseinheit (oder sogar einer Kombination dieser drei).

Lesen Sie ein paar großartige Romane, die einen Einblick in die Perspektiven der technischen Belegschaft geben:

• Hacker, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Kathedrale und der Basar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Diese sind genauso wichtig wie typische Management-Memoiren (Drucker et al.).

Ich habe über viele Jahre verschiedene Rollen gespielt - Entwickler, leitender Entwickler, technischer Leiter usw.

Aus Ihrer Frage geht hervor, dass Ihre Entwickler Ihnen nichts erzählen, weil sie nicht glauben, dass Sie helfen können.

Dies kann zwei Gründe haben.

1. Sie glauben nicht, dass Sie die Macht haben, Dinge zu reparieren. Ich halte dies jedoch für unwahrscheinlich, da Sie es dann wahrscheinlich wissen würden und auch die Entwickler darüber gewimmert hätten.
2. Sie sind die Art von Person, die eines oder mehrere der folgenden Dinge unternimmt, wenn ein Entwickler mit einem Problem zu Ihnen kommt
   • Wenn sie mit Problemen zu dir kommen, sagst du es ihnen - ich mag Lösungen, keine Probleme.
   • Sie hören ihnen gut zu und beauftragen sie dann, das Problem zu beheben. Sie sprechen mit ihnen darüber, was für eine Ehre es für sie ist, die Verantwortung dafür zu tragen, das Problem zu beheben. Mit der Zeit verstehen Ihre Kollegen, dass sie bei Problemen zusätzliche Arbeit leisten müssen, damit sie nicht mit Problemen zu Ihnen kommen.
   • Sie bestreiten, dass es ein Problem ist. Sie geben überzeugende Gründe dafür an. Aber im Laufe der Zeit erfahren Ihre Kollegen, dass es keinen Grund gibt, sich mit einem Problem an Sie zu wenden.
   • Sie sagen "Ja, ich verstehe". Sie sagen, dass solche Dinge gelegentlich vorkommen und man nichts tun kann. Wenn dies ein Muster ist, dann verstehen Ihre Leute es wieder.

Wenn es sich um eines oder alle der oben genannten Probleme handelt, müssen Sie es korrigieren.

Was ich am meisten hasse, sind Leute, die sich zwischen mich, den Entwickler und den Endbenutzer stellen. Die besten Manager lassen mich dies tun und passen unsere Lösung an das an, was der Benutzer meiner Meinung nach will oder kann.

Die schlechteste Praxis ist für mich oft, sich als "gut" zu verkleiden - normalerweise hat der Manager selbst oder ein BA oder jemand schreibt Spezifikationen, die die Entwickler interpretieren und umsetzen müssen, wobei die Zeitpläne im Voraus vereinbart wurden.

Wenn es sich häufig um eine maßgeschneiderte Lösung handelt, wissen selbst die Entwickler nicht, wie lange es dauern wird, und normalerweise hat der Kunde keine Ahnung, was für ihn am besten ist. Deshalb ist die iterative Entwicklung großartig. Ist das nicht die Art und Weise, wie die meisten Geschäfte gemacht werden, so wird ein guter Manager darum kämpfen, wie oben beschrieben zu arbeiten.

Schließlich sind einige Entwickler nicht gut in der Kommunikation und können sich nicht auf Kunden beziehen. Sie eignen sich am besten für Probleme mit klaren Anforderungen, insbesondere mit klaren technischen Anforderungen. Vielleicht brauchen Sie Entwickler, die besser kommunizieren und an der Lösung von Geschäftsproblemen arbeiten möchten, nicht an rein technischen Problemen.

Es ist sehr einfach, das Team bei Laune zu halten

Versuchen Sie, ihnen oft zuzuhören, wenn ihre Frage auch Antworten enthält. Ich würde das Teammitglied ermutigen, mit Problemen und der wahrscheinlichen Lösung zu kommen.

Ein Teamausflug ist eine gute Idee (könnte ein Spielplan sein)

Wenn Ihr Projekt einige späte Abende und Wochenendarbeit erfordert und Sie der Meinung sind, dass Sie dem Team nicht viel Wert hinzufügen, ist es eine gute Idee, etwas zu essen mitzunehmen und das Team nach Möglichkeit über ihre Bemühungen zu informieren vereinbaren Sie eine Zapfwelle

Mache alle zwei Monate 1: 1 mit jedem Teammitglied, um sicherzustellen, dass sie sich wohl fühlen.

Zu guter Letzt ist es vielleicht eine gute Idee für Sie, das Projekt funktional und auch technisch zu verstehen.

Bitte lassen Sie mich wissen, wenn Sie weitere Fragen haben

Ich bin auch ein (französischer, also verzeih mir mein Englisch) Software-Manager, der ursprünglich einen naturwissenschaftlichen Hintergrund, aber nicht speziell einen IT-Software-Hintergrund hat. Daher habe ich zu Beginn keine besondere Affinität zum Kodieren, aber ich war ein Ingenieur für statistische Qualität an der Schule von Deming, der alle "modernen" Schulen unterrichtet, die folgten, obwohl sie vortäuschen, von Deming zu erben. Das Schlimmste ist , 6 Sigma, Lean war besser , aber leider , was passiert ist diese http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

„Ursprünglich wurde Six Sigma vom Toyota Quality Management (TQM) von Motorola abgeleitet, um sechs Sigma-Qualitätsstufen zu erreichen, und dann über Allied Signal und GE in Projekte von Black Belts umgewandelt, die auf Statistiken basieren, um ein Kostensenkungsprogramm zu entwickeln - jedes Projekt braucht einen klaren ROI. Mit anderen Worten, wir haben das Programm von einer Führungsphilosophie zu einer Reihe von Einzelprojekten verunglimpft, um die Kosten zu senken. Es war eine völlige Bastardisierung des Originals und führte selten zu dauerhaften, nachhaltigen Veränderungen, da Führung und Kultur fehlten.

„Ähnliches passierte, als es auf ein Toolkit reduziert wurde (z. B. Wertstrom-Mapping, KPI-Boards, Zellen, Kanban).

"Lean und Six Sigma spiegeln in keiner Weise das ursprüngliche Denken exzellenter japanischer Unternehmen oder ihrer Lehrer wie Deming wider."

Heute ist die Agile Bewegung wie schlank (siehe Jeff Sutherland Kurs und seine Ehrung von Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), es ist besser als Waterfall, aber es ist immer noch sehr weit von der ursprünglichen Lehre von Deming entfernt, denn anstatt Deming in seinem ursprünglichen Text zu lesen, verpacken ihn die Gurus nur neu, wobei er ungefähr nie seine gesamten 14 Managementprinzipien zitiert. und verkauft Tools und Seminare, die für sich genommen wenig Wert haben.

Wenn es um Software geht, gibt es Probleme. Es gibt Menschen, die die allgemeinen Prinzipien kennen, aber keine wirklichen Ideen haben, wie man sie wirklich anwendet, und Menschen, die Software schreiben, aber die Prinzipien ignorieren, weil sie nur zuhören gefälschte Gurus, die ihnen Tools verkauft haben, ohne ihnen die wahren Prinzipien zu erklären, und sie sollten in der Tat ihre eigenen Management-Tools bauen.

Daher sollte sich der Software-Projektmanager für mich bemühen, die alltägliche Funktionsweise der Software-Codierung zu vertiefen, und nicht nur die Planung in Microsoft Project (oder ein Ablaufdiagramm mit Agile) oder eine nette Präsentation in Powerpoint für das obere Management vornehmen, sondern auch einige Werte für das Entwicklerteam. Wenn das Entwicklerteam Probleme hat, auch wenn es sich um technische Probleme handelt, kann der Projektmanager helfen, die Diagnose mit externen Augen zu orientieren. Er kann sich Code ansehen, auch wenn er die winzigen Details nicht versteht. Er kann einige naive Fragen stellen, die Entwickler dazu veranlassen, zu erkennen, dass sie nicht über diesen Hinweis nachgedacht haben (ich habe zahlreiche persönliche Beispiele, aber es ist zu lang, also werde ich es tun) schreibe lieber einen Artikel in meinem Blog).

Eine andere Sache ist, dass ich versuche, durch das Lesen technischer Artikel ein allgemeines Bewusstsein für die Entwicklung auf diesem Gebiet wie neue Frameworks und neue Architekturparadigmen zu entwickeln. Ich werde an einigen Integrationstests teilnehmen, selbst einige Dokumentationen schreiben (Stuff-Programmierer hassen es, dass ich für sie tue, sie würden mich natürlich mit dem Kern füttern), alles, was ich praktisch tun kann, um dem Team zu helfen.

Im Allgemeinen haben Entwickler das Gefühl, dass sie die harte Arbeit leisten, und es ist wahr, dass ich ihnen oft sage, dass ich den einfachen Teil mache, indem ich in der Abstraktion bleibe. Trotzdem versuche ich konkret zu helfen, wenn es nötig ist - wegen des Mikromanagements ist auch nicht gut, da es Interferenzgefühle erzeugen kann.

Als Fazit: Eliminieren Sie Slogans mit Entwicklern (das ist tatsächlich eines der 14 Prinzipien von Deming), und zeigen Sie ihnen, dass Sie sich für die konkrete Projekt-Software interessieren, nicht nur für Dokumente oder Ihre Besprechung mit dem oberen Management.