it-swarm.dev

Ich bin ein Manager. Wie kann ich die Arbeitsbeziehungen und die Kommunikation mit Programmierern verbessern?

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

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, und es wurde kaum ohne Verluste beendet. Es hat zu vielen frustrierenden Situationen geführt, von denen eine so weit eskalierte, dass einer unserer leitenden Entwickler das Unternehmen nach einem heftigen Streit mit uns (dem Management) verließ. Das war eine rote Fahne für mich: Ich habe etwas schrecklich Falsches getan. (für die Aufzeichnung war das Argument über mehrere falsche Zeitschätzungen)

Ich habe an vielen Orten nach Antworten gesucht und ein Freund hat mich auf diese Seite hingewiesen. Hier gibt es viele Fragen zu Frustrationen mit dem Management. Ich kann verstehen, dass die allgemeinen schlechten Erfahrungen zu einer allgemeinen Zurückhaltung gegenüber "den Jungs in den Anzügen" führen.

Ich bin der Typ im Anzug. Es mag nicht so aussehen, aber ich möchte nur ein erfolgreiches Projekt und mit begrenzten Ressourcen schmerzhafte Entscheidungen treffen. Das ist mein Beruf. Eines der Dinge, über die sich der oben genannte 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 stillsten 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 unterversorgten PCs ist nur einer von vielen, die mich zu der Annahme geführt haben, 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 Manager lieben (oder zumindest wie :)), erzählen Sie mir bitte davon. Was machen sie richtig? Wenn Sie es hassen, beschreiben Sie bitte ausführlich, warum. Ich suche nach Antworten zur Verbesserung der Kommunikation, weil ich denke, dass dies mein Problem ist, aber ich könnte mich irren.

431
AgentSmith

Beeindruckend! Danke für die Frage. Technisch gesehen bin ich wie Sie das Management, da ich viel mehr Zeit mit der Kommunikation und Führung von Teams verbringe als mit dem Schreiben von Code. Aber hier ist meine Ansicht von beiden Seiten des Managementhorizonts. Egal, ob ich Entwickler oder Manager bin und für einen anderen Manager arbeite, hier sind einige Dinge, die mir bei der Kommunikation mit meinem Management helfen:

  • Warum? ist eine sehr wichtige Frage - fast jede sachliche Antwort hat ein "Warum" und dieses "Warum" kann wichtiger sein als das tatsächliche Frage. Das hat ein paar Tangenten:
    • Der Entwickler Warum - Entwickler haben viele Antworten, die für das Management absolut keinen Sinn ergeben. Ich habe es auf jeden Fall getan, und eine der Möglichkeiten, wie ich ins Management gekommen bin, bestand darin, den Teams wirklich gut zu erklären, warum sie das Management verstehen können. Wenn Sie keinen "Sprecher für die Geeks" zur Hand haben, können Sie lernen, Geek zu sprechen, indem Sie ihre Antworten auf die Warum-Frage in allgemeineren Metaphern wiederholen. Bleiben Sie dabei, 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 ist etwas, in das Sie als Manager wahrscheinlich gute Einblicke haben, 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, zeitnah und nachdenklich zu sein - aber wenn er das "Warum" nicht kennt, kann er auf eine Weise optimieren, die Sie lieber hätten, als dass er es nicht getan hätte. Bieten Sie Ihr Warum an und bitten Sie ihn, dasselbe zu tun - wiederholen Sie die Antwort in seinen eigenen Begriffen. In ähnlicher Weise - gehen Sie auf das Warum des Geschäfts ein - sind Entwickler oft interessiert, haben aber kein direktes Wissen darüber, wie die Geschäftsentwicklung funktioniert - wenn jemand diese Informationen freiwillig zur Verfügung stellt, ist dies sowohl motivierend als auch aufschlussreich.

Speziell zu Zeitschätzungen - Ich musste eine Menge tun, und ich habe absolut davon profitiert, meinem Entwicklungsteam zu sagen: "Ich brauche das, weil ich mehr Geld verlangen werde, um unsere Gehälter zu bezahlen. Ich werde darauf vertrauen, was Sie mir sagen und." Ich werde Ihre Zahlen verwenden ... das heißt, wenn Sie mich niederwerfen, 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 wechselten die Entwickler von niedrigen Schätzungen, die mir zeigen wollten, wie sicher und brillant sie waren, zu hohen Schätzungen, die der tatsächlichen Erwartungshaltung viel näher kamen.

  • Niemand ist falsch - Die "Warum" -Frage geht lange mit einer Folgerung einher - "Warum" zu fragen, anstatt zu sagen "Das ist empörend! Auf keinen Fall!" hält das Gespräch im Fluss. Manchmal gibt es eine gravierende Trennung zwischen dem, was jemand fragt, und dem, was der Fragesteller 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 zur Erreichung eines Wettbewerbsziels reduziert, aber erst, nachdem ich intensiv darüber gesprochen habe, wie wir die Szene ä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 - Hier sind einige Dinge, die ich gemocht und gestohlen habe, um sie selbst zu verwenden:

    • hängen Sie im Arbeitsbereich ab, machen Sie selbst etwas Produktives (versuchen Sie nicht, Entwickler zu werden, 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 die wirklich Skinny bei ihrer direkten Einschätzung von Ihnen oder dem Management im Allgemeinen hören, aber Sie können ein wirklich gutes Gefühl dafür bekommen, wo sich Problembereiche befinden. Stellen Sie sicher, dass Sie etwas Eigenes tun, das produktiv ist. Niemand mag Spionage, aber wenn die Moral nicht so niedrig ist, dass man nicht in der Nähe sein kann, ohne dass jeder evakuiert, sollte 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 Machtentfernung zwischen Ihnen und den Entwicklern gibt (und es klingt so), möchten sie Ihnen möglicherweise nicht widersprechen oder sich Ihnen stellen. Aber der Grundinstinkt, "Hey, du liegst falsch" zu sagen, 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 jedes zu etablieren der Fluss der Kommunikation. Die Leute sind so vielfältig, dass nur ein Trick nicht funktioniert. Und ich sehe es als Aufgabe des Managers an, der Multi-Format-Kommunikator zu sein, nicht der Entwickler.

  • es lohnt sich, mit Ihnen zu sprechen Wenn Ihnen jemand von einem Problem und möglicherweise einer möglichen Lösung erzählt, sollte und wird er wahrscheinlich akzeptieren, dass Sie der Manager sind und dies möglicherweise auch Entscheiden Sie sich für eine andere oder gar keine Lösung, weil Sie der Meinung sind, dass sich die Mühe nicht lohnt. Aber nach dem dritten Mal passiert dies, besonders wenn es ohne eine Erklärung passiert, dass 99% der Leute aufhören, Ihnen etwas zu erzählen.

Und hier ist eine, die unglaublich schwer für mich ist, aber großartig funktioniert hat, wenn ich es kann - sei dir des Unterschieds zwischen Introvertierten und Extrovertierten bewusst . Die Chancen stehen gut, dass Sie extrovertiert sind - deshalb schien Ihr Job gut zu sein und eine Entwicklungsposition nicht. Entwickler sind größtenteils introvertiert. "Introvertiert" bedeutet nicht "kann nicht kommunizieren", aber es bedeutet, dass sich Muster, Prozess und Geschwindigkeit erheblich unterscheiden und der Drang, ununterbrochen zu kommunizieren, praktisch nicht vorhanden ist. Planen Sie den zeitlichen und ruhigen (aber zusammengestellten) Raum ein, damit introvertierte Gedanken herauskommen. Viele meiner introvertierten Freunde sagen mir, dass sie nur darauf warten, dass ich "etwa 5 Minuten lang die Klappe halte", damit sie einen Gedanken zusammenstellen und antworten können. Hier sind ein paar großartige Artikel über dasselbe - 5 Dinge, die Extrovertierte über Introvertierte wissen sollten und Rands in Repose in der Nerd-Höhle - ein besonders entwicklerfreundliches Beispiel dafür, was für Introvertierte großartig ist =. Rands ist übrigens ziemlich fantastisch. Er ist selbst ein Geek, also kommt er von einem Entwicklerfokus, der abschreckend sein kann, wenn das nicht dein Stil ist, aber er ist lustig und hat einige wirklich gute Einblicke in die Teamentwicklung.

Ich denke, die Nummer 1, die ich an meinen Lieblingsmanagern geliebt habe, war:

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

  • Ich hatte nie Zweifel daran, 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 erhielt das Eigentum an etwas Bedeutendem und Angemessenem für meine Fähigkeiten zu der Zeit, aber mit genügend Ressourcen, 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 damit beschäftigt, meine Stärken und Schwächen zu kennen und mir zu helfen, meine Stärken auszunutzen und meine Schwächen zu vergrößern.

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

  • sie waren offen, als sie mich glücklich machten, konnten und wollten keine Priorität haben. Es ist wirklich wertvoll 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 Moment), 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.

  • da war 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.

331
bethlakshmi

Der einfache Teil zuerst: Es gibt eine technische rote Fahne in Ihrem Beitrag: Ich schaudere bei Ihrer Erwähnung von "falschen Schätzungen" - es ist eine Schätzung, es KANN NICHT FEHLERHAFT SEIN, deshalb wird es eine Schätzung genannt. Es kann ein wenig abweichen, es kann viel abweichen, deshalb wird es eine Schätzung genannt. Wenn Sie Schätzungen als Evangelium betrachten, wird dies eines der Hauptprobleme sein, die "Ihre" Entwickler mit Ihrem Stil haben.

Ich stimme Ihnen jedoch zu 100% hinsichtlich der Schwierigkeit der Kommunikation mit Entwicklern zu. Ich hatte vor einigen Jahren eine Offenbarung als Entwickler in einem Projektmanagement-Training. Ich habe einige meiner Entwicklerkollegen gesehen, die sich absolut gegen das Management gewehrt haben, nachdem eine offene Diskussionsatmosphäre geschaffen wurde (Management war hier anwesend). Alles, was falsch war, war in den Augen der Entwickler die Schuld der Manager. 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 können, und das Management ging davon aus, dass die Entwickler ihnen sagen würden, was sie brauchen.

Daher muss meiner Meinung nach der erste Teil der Antwort darin bestehen, Ihre Entwickler wissen zu lassen, dass Sie nicht psychisch 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 und nicht schwerer zu machen.

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

160

Es gibt viele gute Sachen hier, aber ich denke, das Folgende muss gesagt werden ... 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, einen Entwickler wegen schlechter Arbeitsbedingungen als erste echte rote Fahne kündigen zu lassen .

Was ich denke, dass Sie haben, ist ein Vertrauensproblem, mehr als ein Kommunikationsproblem. Niemand sagt, was falsch ist, weil sie nicht vertrauen, was Sie mit diesen Informationen machen werden, und kann sogar befürchten, dass sie gegen sie verwendet werden. Der Entwickler, der Ihnen von all diesen Problemen erzählt hat, hat dies getan, weil Es gab keine Konsequenzen, er gab auf.

Persönlich würde ich niemals einen PM einstellen, der keine Entwicklungserfahrung in seinem Hintergrund hatte. Ich denke an Ihr nächstes Projekt, Sie sollten einen kleinen Teil Ihrer Zeit als Teil von widmen das Entwicklerteam. Sagen wir 8 Stunden pro Woche und arbeiten als Jr-Entwickler unter der Teamleitung.

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

"Wir werden unseren besten Mann verlieren, wenn du nichts tust."

Das sollte die rote Fahne Nr. 2 sein.

69
Morons

Als Manager haben Sie sicher von kaizen gehört, einem der Grundsätze des Toyota-Produktionssystems, der kontinuierliche Verbesserung bedeutet.

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

Kaizen hat fünf Hauptelemente:

  • Qualitätskreise : Gruppen, die sich treffen, um Qualitätsstufen in Bezug auf alle Aspekte des Betriebs eines Unternehmens zu diskutieren.

  • Verbesserte Arbeitsmoral : Eine starke Arbeitsmoral ist ein entscheidender Schritt, um langfristig Effizienz und Produktivität zu erreichen, und Kaizen legt dies als grundlegende Aufgabe fest, um konstant zu bleiben Kontakt mit der Moral der Mitarbeiter.

  • Teamwork : Ein starkes Unternehmen ist ein Unternehmen, das jeden Schritt des Weges zusammenhält. Kaizen möchte Mitarbeitern und Management helfen, 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 zur persönlichen Disziplin stellt sicher, dass das Team stark bleibt.

  • Verbesserungsvorschläge : Durch die Anforderung von Feedback von jedem Mitglied des Teams stellt das Management sicher, dass alle Probleme geprüft und behoben 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 entscheidende Sache: Niemals feilschen im Laufe der Zeit schätzt Ihr Team Ihnen. 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 Baby bekommen, denken Sie daran.

Also mein erster Rat:

Listen : 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, dem Team zu ermöglichen, großartige Software zu entwickeln, nicht sie zu hüten. Denken Sie daran.

Ehrlichkeit und Loyalität : Wenn niemand antwortet, wenn Sie etwas fragen, liegt es daran, dass er nicht glaubt, dass Sie zuhören werden, oder, schlimmstenfalls, er glaubt, dass Sie es tun werden bestrafe sie dafür. 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 schließlich, obwohl ich hier einige Kritiken darüber gesehen habe, möchte ich Ihnen empfehlen, ein Buch mit dem Titel The Mythical Man-Month: Essays on Software Engineering zu lesen. Das Buch handelt von Fred Brooks Erfahrung bei IBM bei der Verwaltung der Entwicklung von OS/360. Während einige Dinge hier und da veraltet sein mögen, ist dies der erste Schritt, um zu verstehen, wie der Entwicklungsprozess komplexer Software funktioniert. S.Lott zitiert das Agile Manifesto , das mir nicht besonders gefällt, aber es ist auch lesenswert.

37
Vitor Py

Lesen Sie dies:

http://agilemanifesto.org/

  • Individuen und Interaktionen über Prozesse und Werkzeuge

  • Arbeitssoftware über umfassende Dokumentation

  • Kundenzusammenarbeit über Vertragsverhandlungen

  • Antworten auf Umstellung nach einem Plan

In vielen Fällen fordert die Organisation (d. H. Ihr Chef) dies von Ihnen

  • folgen Sie einem klar gebrochenen Prozess zu seiner logischen Schlussfolgerung, die zu einem "Todesmarsch" führt. Dies führt wiederum zu Argumenten und Rücktritten.

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

  • komplexe Änderungskontrolle bei Vertragsverhandlungen durchführen. Jede Benutzeränderung erfordert ein ausgeklügeltes Ritual, um die Änderung zu "qualifizieren" und zu "priorisieren". Wirklich, es geht nur um das "Einfrieren" - das Verhindern von Veränderungen.

  • befolgen Sie den Plan unabhängig von den Folgen. Einige Unternehmen legen Wert auf eine pünktliche Lieferung defekter (oder sogar nutzloser) 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 sind.

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

26
S.Lott

Für mich klingt das so, als hätten Sie nie in einer lockeren Atmosphäre mit den Entwicklern gesprochen. Ihre Gespräche mit ihnen waren lediglich offizieller Natur? Das ist sehr schade.

Warum lernen Sie sie nicht persönlich kennen und erfahren so, was gut und was schlecht an dem Unternehmen, ihrem Arbeitsplatz und ihren Projekten ist? Respektieren Sie sie und verdienen Sie sich ihren Respekt, indem Sie aufrichtiges Interesse und Wertschätzung für ihre Arbeit zeigen.

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 die ganze 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 fast bösen Kunden, der fast unmöglich zu beenden war, aber wir haben es schließlich geschafft, weil wir über alles sehr offen und offen sprechen.

22
Falcon

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

Nachfolgend finden Sie, was ich in einem großartigen Manager gesehen und persönlich angenommen habe, als ich das Team als leitendes Mitglied leitete.

  • M entor mehr als verwalten.
  • A Lassen Sie die Teammitglieder ihre Gedanken und Bedenken äußern. Sei ganz Ohr dafür. Nehmen Sie die konstruktiven.
  • N Verrate jemals Teammitglieder, indem du spaltende Politik spielst. Dies schlägt früher und lautlos zurück.
  • A nger nicht. Haben Sie niemals Grimassen im Gesicht, wenn Sie mit Ihrem Team zusammen sind. Dieser ist wirklich schwierig.
  • G würdigt den Gewinner aufrichtig und offen für seine gute Arbeit. In der gleichen Breite, sehr sanft und taktisch kritisieren die Arbeit nicht Person für irgendwelche Fehler, gegenüber der Person, die verantwortlich ist, isoliert und nicht offen.
  • E Förderung von Eigenverantwortung und Führung in jedem Einzelnen. Dies steigert die Moral und das Engagement des Menschen, weil er sich respektiert fühlen würde.
  • R ab und zu mit deinem Team herumlaufen. Dieser induziert/erhöht die Bindung innerhalb der Teammitglieder.

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

20
karthiks

Im Allgemeinen fühlen sich die Jungs in den Schützengräben meuterisch, wenn sie das Gefühl haben, dass ihre Griffe von Menschen nicht gehört werden, die die Situationen beheben können und werden. Wenn sie nicht einmal das Gefühl haben, sich beschweren zu können, ohne ihr Ansehen im Unternehmen 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 es gut machen und damit keine Wellen schlagen wollen, Wege finden, um dieses Problem zu umgehen oder es einfach zu ignorieren. Dies führt zu aufgestauten Frustrationen, die schließlich dem gesamten Team ins Gesicht sprengen. In einem Geschäft, das von einem Theory-X-Manager betrieben wird, gibt es wahrscheinlich Leute, die sich viel früher beschweren. Die Angestellten sind nur für das Geld dabei. Wenn der Job mehr als sonst nervt, werden sie sich beschweren.

Was Sie tun können, in einer Umgebung mit Senioren und Führungskräften im Raum, die die Arbeit erledigen, sind sie Ihr bestes Kapital. Rede mit ihnen. Sie können 30 Minuten pro Woche für "Zweiwege" einplanen, bei denen die Leads Ihnen Aktualisierungen und Bedenken hinsichtlich des Tagesablaufs des Projekts geben und Sie sie auf der Geschäftsseite aktualisieren und mit ihnen planen, um Bedenken auszuräumen 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, von den jüngsten Mitgliedern bis zum Premierminister, eine "Retrospektive" ". Sie schauen zurück auf das, was sie getan haben, was richtig gelaufen ist, was nicht und identifizieren Dinge, die sie weiter tun und die sie ändern müssen. Es gibt verschiedene Formate, und Sie können Ihre eigenen erfinden, aber das Ergebnis des Retro sollte sein, dass die Leute das Gefühl haben, dass ihre Stimme gehört wurde, und dass sich die Dinge dadurch ändern werden.

Apropos Agilität; Mein erster Job war für eine kleine Firma, und mit "klein" meine ich, dass die ganze Firma keine Softballmannschaft aufstellen konnte. Als ich anfing, gab es vier Programmierer, und diese gingen auf zwei zurück, bevor ich ging. Der Gründer, Präsident, CEO und 95% der Beteiligten des Unternehmens regierte es 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 geben mussten, war nicht mehr oder weniger als erwartet, und dafür zahlte er ein Einstiegsgehalt an Leute, die ein Jahrzehnt für ihn gearbeitet hatten.

Ich verließ diese Firma und begann für eine andere Firma zu arbeiten, die die Dinge SEHR anders machte. Sie übten die SCRUM Agile-Grundmethode mit täglichen Stand-ups, Paarprogrammierung, Sprintteams und Retrospektiven. Für einen Tag alle zwei Wochen zu Beginn jedes Sprints haben wir nur die nächsten zwei Wochen geplant. Für einen großen Teil eines anderen Tages haben wir nichts weiter getan, als auf das zurückzublicken, was wir getan hatten, und Wege gefunden, uns als Team zu verbessern. Neben mir saßen Entwickler, die Microsoft MVPs waren, die Arbeit erledigten und meine Arbeit 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 "Sodbrennen" über das hätte, was ich im nächsten Sprint erwarten würde, 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ürde unterhalten werden.

Wenn Sie Lösungen finden und Probleme lösen möchten, müssen Sie darauf achten, dass Sie nicht von oben nach unten arbeiten. Für Computer; Angenommen, Ihr 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 geschafft. 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ß.

16
KeithS

Beziehungen verbessern:
Hatten Sie gerade ein hartes Projekt? Geben Sie ihnen danach eine Pause. Urlaubszeit, um sich zu entspannen und Luft zu holen.
Codierer Bill of Rights Diese Dinge sind selbstverständlich. Grundlegende Dinge, die selbstverständlich sein sollten. Wenn Sie gegen diese verstoßen, missbrauchen Sie Ihre Codemonkeys.
Der Joel-Test Ich stimme den meisten von ihnen zu. Aber manche hängen wirklich davon ab. Wenn Sie welche vermissen, machen Sie Ihren Programmierern wahrscheinlich das Leben schwerer, als es sein muss.
Technische Schulden . Sie können also auf Vollendung drängen, aber Sie müssen dies erkennen, indem Sie Ecken abschneiden technische Schulden entstehen, deren Behebung zu einem späteren Zeitpunkt länger dauern wird. Wenn dieses Datum vor dem Ende des Projekts feststeht, haben Sie es wirklich vermasselt.
RSA animieren: Motivation Dies ist ein fantastisches Stück, das wirklich zeigt, wie man Wissensarbeiter motiviert.
Freier Tag, um zu codieren, was sie wollen. Aus dem RSA-Video. Ich erinnere mich nicht an den Namen, aber das Unternehmen, das es erwähnt, hat eine kurze Erklärung auf seiner 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 das hat keine hohe Priorität. Auf diese Weise können sie technische Schulden in den Griff bekommen. Außerdem können sie ihre brillanten Ideen vorführen.

Und aus Liebe zu Gott, versuchen Sie, eine 40-Stunden-Woche zu halten. Auch Gleitzeit. Gleitzeit kann eine ganze Welt voller Scheiße ausgleichen. Für mich zumindest.

Verbesserung der Kommunikation zwischen Programmierern und Vorgesetzten
Das ist schwieriger für mich. Diese ganze Sache ist eher ein Boss-Skillset als der Fokus eines Programmierers. Ich könnte sagen, dass einige grundlegende Dinge wie Zeitschätzungen nur Schätzungen sind. Das Gehen auf dem Wasser und das Erfüllen von Anforderungen sind einfach, wenn sie gefroren sind. Vielleicht bitten Sie die schüchternen Programmierer, bei einer Codeüberprüfung oder so etwas eine Präsentation über ihr Projekt zu halten. Übung macht den Meister, oder? Aber ich würde mich dem Rat anderer beugen.

"Wenn Sie es hassen, beschreiben Sie bitte ausführlich, warum."
Nun, das wird die Schleusen hier öffnen. Und wenn ich keine openID verwenden würde, die offensichtlich mit mir verknüpft sein könnte, würde ich wahrscheinlich auch entlüften. Wenn Sie wirklich eine riesige Liste von Dingen wünschen, die Sie nicht tun sollten, fragen Sie in einem Forum nach, das für anonyme Beiträge freundlicher ist.

11
Philip

Ich habe immer festgestellt, dass Menschen 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 sich in neutraler Atmosphäre informell mit Ihrem Team unterhalten und ihm mitteilen, was Sie uns gerade gesagt haben. Der Punkt, der in den giftigen "wir gegen sie" -Umgebungen vergessen wird, ist, dass es sollte alle "wir" sind. Sowohl das Management als auch die Mitarbeiter müssen das wissen, und das Unternehmen muss dies unterstützen.

Viel Glück.

8
PSU

Sie haben jetzt nachweislich nicht nur Feedback angenommen, sondern auch darauf reagiert. Sie haben gezeigt, dass Sie Einfluss auf höhere Entscheidungsträger haben und Dinge für Ihr Team erledigen können. Das macht einen großen Unterschied. Programmierer sind introvertierter, aber wir sprechen gerne über Programmierung. Ein informelles Umfeld ist schön, aber jeder muss professionell sein. Erlauben Sie den Leuten, etwas zu entlüften, aber stellen Sie sicher, dass die Diskussionen produktiv sind und nicht nur eine Schlampensitzung.

7
JeffO

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

  • Ich muss nicht zu viel Zeit verschwenden, um zu rechtfertigen, warum eine Änderung so lange dauern würde oder nicht umgesetzt werden kann. Technisch gesehen kann jede Änderung implementiert werden, und das obere Management verlangt normalerweise die Implementierung in irgendeiner 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 macht eine nicht-technische Person den Entwickler für eine solche Situation verantwortlich, während ein guter Manager VERSTEHT, was wirklich vor sich geht, und seinen Entwickler unterstützt (nicht nur weiß oder bereit ist, dies so zu verstehen, um nett zu sein).
  • Ich weiß, dass meine Arbeit und Leistung von einer geeigneten Person bewertet werden müssen.

Meiner Meinung nach ist die Chance für Ihre Entwickler sehr gering, wenn Sie nicht mehr programmieren und normalerweise in einem engen Projektplan oder Budget arbeiten. Wenn dies der Fall ist, sollten Sie schnell aufsteigen und einen anderen als direkten Manager haben. Tut mir leid, dass ich in diesem Absatz schlecht geklungen habe, aber so sehe ich das. Ihr scheint ein guter Mensch zu sein und verdient etwas Wahrheit.

7
Codism

Ich glaube, dass bei der Zufriedenheit der Entwickler die Produktivität auf die kleinen Dinge hinausläuft. Die Mathematik funktioniert 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 codieren, wenn wir wütend sind.

Schätzungen müssen jedoch selbst vorgenommen werden. Jedes Problem, das ich habe, kann gelöst werden, indem ich einen Donut bekomme, mit Ausnahme von unrealistischen Schätzungen. Richtig oder falsch, so sieht es ein Entwickler: Das Management hat alles zu gewinnen (wie ein neues Boot) durch eine kürzere Schätzung, während Entwickler alles zu verlieren haben (wie ein Monat Schlaf). Das Management ist jedoch verantwortlich, so dass 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, also wie würde ein Manager?), Aber das Management motiviert sie positiv, ehrgeizig zu sein, mit dem Verständnis, dass keine Entwickler auf die Schiene kommen ein bisschen daneben sein.

5

Ich bin auch einer der Jungs in einem Anzug und 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 Anmeldeinformationen wie "Mitarbeiter des Jahres", die von Mitarbeitern gewählt wurden und die mich zuversichtlich machen, mit diesen Situationen umzugehen.

Was ich sehr oft sehe, ist, dass es erhebliche Unterschiede in den Wertesystemen und Betriebsmethoden/-ansätzen zwischen Management und Entwicklern gibt.

Für viele Entwickler stehen Aufrichtigkeit, Ehrlichkeit und ansonsten ein flexibles Arbeitsumfeld ganz oben auf der Liste. Leider stehen die gleichen Werte auf der Liste der Top-Führungskräfte nicht ganz oben. Und dies führt unweigerlich zu großen Zusammenstößen, insbesondere wenn das mittlere Management (Sie und ich) beschließt, die Seite des Top-Managements vollständig zu übernehmen. Der einzige Ausweg (aus meiner Sicht) besteht darin, einen festen Standpunkt vor Ihrem Team einzunehmen, sie vollständig 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 man vom Top-Management bekommt, wo die Politik die Aufrichtigkeit völlig überwältigt).

Gleichzeitig müssen Sie selbst betriebsbereit bleiben, damit Sie einen Weg finden, mit dem Top-Management in einer Sprache zu kommunizieren, die sie verstehen und ihr Spiel spielen. Das ist die wahre Herausforderung des mittleren Managements.

5
wolfgangsz

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

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

Drittens überlegen Sie, welche Art von emotionale Intelligenz Fä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 von einem Mittagessen erhalten und etwas über EQ erfahren habe. Wenn Sie hier wirklich tief in die Psychologie eintauchen möchten, gibt es verschiedene Persönlichkeitsprofil-Tools, die verwendet werden können, z. Enneagramm, soziale Stile und MBTI.

Zuletzt überlegen Sie, was die Kultur in Ihrem Unternehmen ist. Werden Fehler unter den Teppich gekehrt? Sind Beschwerden ein großes Nein-Nein, das jemanden wirklich leicht in Schwierigkeiten bringen könnte? Welche Verhaltensweisen werden belohnt oder gefördert und welche werden toleriert und akzeptiert? Während ein Teil davon Beobachtung ist, kann ein Teil davon auch einige Gespräche erfordern, die entweder außerhalb des Büros oder in einem Raum geführt werden sollten, in dem es wahrscheinlich nicht zu Abhören kommt. Sie werden wahrscheinlich am Anfang wiederholt versuchen, dies 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, in der jeder nur wusste, dass er sie "aufsaugen" sollte. Dies mag empfindlicher sein als andere Antworten, aber dies wäre das, was ich für eine Antwort geben würde, wenn ich danach gefragt würde, wo ich arbeite.

4
JB King

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

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

Wenn mich jemand auffordert, etwas zu tun, mache ich absolut keine Schlussfolgerungen und tue genau das, was verlangt wird. Es scheint, als ob ich bei einigen Projektmanagern immer Probleme habe, weil sie erwarten, dass ich Rückschlüsse auf ihr Projekt ziehe, was ich absolut nicht tun werde. Manchmal laufen die Dinge 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 der Fall ist, liegt darin, dass sie keine qualitativ hochwertigen HLDs und BRDs liefern und zu viel Wert auf den sozialen Aspekt des Projektmanagements legen als auf das, was in Schwarzweiß geschrieben ist.

Ich denke, hier kollidieren Welten. 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, dass Zeitpläne und Fristen 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 im laufenden Betrieb zu ändern scheinen - für mich ist dies meine rote Fahne, dass ich es mit einer Projektleitung von schlechter Qualität zu tun habe. Als Entwickler können Sie mir am schlechtesten täglich neue Projektanforderungen stellen, insbesondere nachdem wir bereits einen Zeitplan haben oder Zeitplanverpflichtungen eingegangen sind. Es ist unerträglich, wenn neue Anforderungen gestellt werden, ohne die Fristen zu kompensieren. Wenn ich mehr Stunden arbeite, spät arbeite, habe ich kein Problem damit, aber es ist nicht immer quantitativ mit der Entwicklung. Einige Änderungen können einige zusätzliche Stunden dauern, einige Änderungen können Wochen für ordnungsgemäße Forschung und Entwicklung, Tests, Qualitätssicherung usw. dauern. Es ist nicht immer wie das Backen eines Kuchens, manchmal kann eine einzelne Änderung der Anforderungen wie das Ändern des gesamten Rezepts sein. Ich habe gesehen, wie Projektmanager bei Telefonkonferenzen zusammengeschmolzen sind und Wutanfälle hatten, weil ihre Fristen keine zusätzliche Entwicklung zulassen, aber sie fordern eine Entwicklung, die nicht ihren ursprünglichen Projektanforderungen entsprach.

Ich kann nur meine persönlichen Vorurteile und Erfahrungen als Beispiel nennen. Daraus schließen Sie bitte 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.

3

Haben die Entwickler das Gefühl, dass Sie ihr Anwalt sind? Damit meine ich, dass sie wissen, dass sie frei sind, ihre Bedenken/Frustrationen mit Ihnen zu teilen, ohne verprügelt 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 erfolgreich sind?

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

3
David Weiser

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

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

2
Stephen Bailey

Wie oft sprechen Sie mit Ihren Entwicklern? Ich meine nicht Projektstatusbesprechungen, Fragen zu Ergebnissen oder anderen Themen, die Sie ihnen vorlegen - wie oft setzen Sie sich mit einem Ihrer Programmierer zusammen, fragen ihn, wie die Dinge laufen, und hör einfach zu .

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

Gute Referenz für Einzelgespräche - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

2

Nur um eine Antwort aus einer Empfehlung zu machen, die bereits in ein paarAntworten eingegangen ist. Michael Lopp (aka rands ) hat in seinem Blog Rands in Repose und in einem Buch . Menschen verwalten ( Buchquellen ). Das Buch enthält hauptsächlich bearbeitete Inhalte aus seinen Posts vor 2007 und bietet eine gute Möglichkeit, die verwaltungsbezogenen Teile seines Blogs nachzuholen (er spricht auch beispielsweise über Glücksspiele und darüber, ob Sie dies lesen möchten, ist eine andere Sache). Sein Schreiben ist im Allgemeinen großartig und oft humorvoll, daher besteht wenig Risiko, ihn zu lesen.

1
Francois G

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

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

Grunzer sagen den Anzügen nie die ganze Wahrheit. Rands sagt dies in DNA , spricht es aber nicht direkt an, er hat ein anderes 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 ihre Schecks nicht unterschreiben, sie würden Ihre unterschreiben.

Dies ist natürlich keine Neuigkeit für Sie oder die Ingenieure. Wenn ein Ingenieur jedoch weiß, dass das Aufwerfen bestimmter Probleme - Probleme - mit seinem Arbeitsplatz zu erheblichen Konflikten führen würde, begünstigt der Kompromiss zwischen Risiko und Ertrag den Ingenieur nicht. Ingenieure werden für die Herstellung von Produkten bezahlt, nicht für die Auseinandersetzung mit der Kultur am Arbeitsplatz. Sich darauf einzulassen, ist ein schneller Weg, um die Arbeit falsch zu machen.

Teil der Managementaufgabe ist es daher, den Ingenieuren die Möglichkeit zu geben, offen für Probleme zu sein, ohne dass es zu Unternehmenspolitik und Karriereproblemen kommt. Es ist schließlich schön, Erhöhungen zu haben, und es gibt andere Unternehmen, wenn sich dieses nicht sympathisch anfühlt.

1
Paul Nathan

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

1
Graham Borland

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

Hier ist eine Idee: Senden Sie Ihre I.T. Mitarbeiter zu Kommunikationsworkshops an Ihrem örtlichen Community College - natürlich vom Unternehmen bezahlt.

Stellen Sie sicher, dass a) die Werkstätten einen guten Ruf haben und b) Ihre Mitarbeiter nicht zusammenschicken. Sie neigen dazu, zusammenzuhalten und sich nicht unter die anderen Klassenmitglieder zu mischen, 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 schulischen Wegen fehlt.

Diese Idee ist in keiner Weise ein Wundermittel, aber sie ist ein gutes Fundament des Puzzles. Ihre Mitarbeiter werden nicht nur lernen, besser miteinander zu kommunizieren, sondern der Bonus wird auch sein, dass sie beginnen, IHRE Arbeit besser zu verstehen und zu respektieren (Kommunikation ist das Kernstück von PM).

Nur meine 2 Bits :)

1

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

1
dodgy_coder

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 Ihnen darüber gejammert hätten.
  2. Sie sind die Art von Person, die, wenn ein Entwickler mit einem Problem zu Ihnen kommt, eines oder mehrere der folgenden Dinge tut
    • Wenn sie mit Problemen zu Ihnen kommen, sagen Sie ihnen - ich mag Lösungen, keine Probleme.
    • Sie hören ihnen gut zu und beauftragen sie dann mit der Behebung des Problems. Sie geben ihnen einen aufmunternden Vortrag darüber, was für eine Ehre es für sie ist, die Verantwortung zu übernehmen, das Problem zu beheben. Mit der Zeit verstehen Ihre Jungs, dass sie, wenn sie mit einem Problem zu Ihnen gehen, zusätzliche Arbeit haben, damit sie nicht mit Problemen zu Ihnen kommen.
    • Sie bestreiten, dass es ein Problem ist. Sie geben überzeugende Gründe dafür. Aber während dies so weitergeht, lernen Ihre Jungs im Laufe der Zeit, dass es keinen Sinn macht, sich Ihnen mit einem Problem zu nähern.
    • Sie sagen "Ja, ich verstehe". Sie sagen, solche Dinge passieren gelegentlich und es gibt nichts, was man tun kann. Wenn dies ein Muster ist, dann verstehen es eure Jungs wieder.

Wenn es eines oder alle der oben genannten ist, müssen Sie es korrigieren.

0
user93353

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

Wenn Sie Ihre Frage lesen, sehen Sie den Wert der Kommunikation. 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 über die harten Fähigkeiten verfügen, 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).

0
Thomas Owens

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

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

0