Geekly articles weekly

Problemidentitäten unter Entwicklern



In der Wüste qualifizierter Talente sind Wasserentwickler wie Wasser gefragt, auch wenn sie an Händen getragen oder beleidigt werden, aber das ist eine Tatsache. Ohne sie wird es keine Industrie geben, und sie selbst sind sich dessen bewusst. Dies führt zu einem so aufregenden Selbstrechtsgefühl, das in der Geschichte der Menschheit selten zu sehen ist. Infolgedessen wurde ein ganzes Spektrum sehr heller Problempersönlichkeiten geboren.

Ein guter Entwickler kann Gold wert sein - im wahrsten Sinne des Wortes . In wenigen Berufen ist ein solches Einkommen möglich. Einige der reichsten Menschen auf dem Planeten waren früher Programmierer. Daher ist es einer der einfachsten und direktesten Wege zu großem Wohlstand, zur richtigen Zeit am richtigen Ort Entwickler zu sein.

Mit solchen Möglichkeiten geht jedoch häufig ein völliger Mangel an Respekt für die Projektteilnehmer in anderen Berufen einher. Dieser Mangel an Respekt kann sich als so tief herausstellen, dass der Entwickler fest davon überzeugt ist, dass er nicht nur der wertvollste Teilnehmer am Softwareprojekt ist, sondern auch für das gesamte Unternehmen notwendig ist. Obwohl sich nur eine kleine Anzahl von Entwicklern in der Lage ist, etwas zu sammeln, das dem Reichtum ähnelt, verhalten sich viele leider so, als würden sie Mark Zuckerberg, Bill Gates oder Steve Jobs folgen. obwohl es sehr weit von der Wahrheit entfernt ist. Dies führt zu Persönlichkeitsproblemen, die von der Seite genauso aufregend zu betrachten sind, wie es beängstigend ist, in sich selbst nachzudenken.

Folgendes sind problematische Identitäten unter Softwareentwicklern:


Primadonna


Der Entwickler ist von seiner Unentbehrlichkeit so überzeugt, dass er arrogant und unmöglich zu führen wird.


Das Problem


Ab einer bestimmten Ebene muss der Mitarbeiter das tun, was Sie sagen, um ihn zu verwalten. Die Primadonna kann nicht kontrolliert werden, weil sie von Natur aus nicht glaubt, dass sie für Sie funktioniert. Seiner Meinung nach ist es Ihr Privileg, mit ihm zusammenzuarbeiten. Er hält sich in jeder Diskussion für unverzichtbar und richtig.

Entgegen ihrer eigenen Überzeugung ist die Primadonna nicht unbedingt eine qualifizierte Entwicklerin (siehe Rockstar-Typ ). Seine Arroganz basiert auf der Darstellung seines Platzes in der Organisation und nicht auf tatsächlichen technischen Fähigkeiten. Infolgedessen bewerten Primadonnen ihr Können zu oft als viel höher als das ihrer Altersgenossen, obwohl dies tatsächlich nicht der Fall ist . Dies führt normalerweise dazu, dass die Primadonna von Kollegen normalerweise nicht gemocht wird.

Primadonna kann durch typische Sätze identifiziert werden:

  • "Das ist dumm - ich werde es nicht so machen"
  • "Wir müssen es so machen."
  • "Wenn es dir nicht gefällt, kannst du mit meinem Manager sprechen."
  • "Nun, wir werden sehen."
  • "Ich werde mit deinem Chef sprechen und sehen, was er sagt."

Die Primadonna akzeptiert keine Führung. Er sieht jeden Führungsversuch als Beleidigung an, da er nicht für seine Handlungen zur Rechenschaft gezogen werden muss. Dieses Persönlichkeitsproblem tritt häufig bei langjährigen Entwicklern auf, die stark am frühen Erfolg von Unternehmen beteiligt sind. Jetzt, Jahre später, sieht er dank langjähriger Beziehungen zu den Gründern des Unternehmens seine Meinung höher als die eines einfachen Managers auf mittlerer Ebene.

Die Primadonna stellt keine materielle Gefahr für das Projekt dar, da sie normalerweise nichts tut, sondern nur das Gesetz erschüttert. Dies wirkt sich jedoch negativ auf die Moral des Teams aus, insbesondere auf neue, produktivere Entwickler. Daher muss es so eingerichtet werden, dass das Projekt reibungslos läuft.

Lösung


Die Lösung für die Diva besteht darin, den Grundglauben zu widerlegen: dass er unersetzlich ist und daher tun kann, was er will . Der direkteste Weg, diesen Glauben zu widerlegen, besteht darin, einen Ersatz zu engagieren, um eng mit ihm zusammenzuarbeiten. Um der Primadonna angemessen zu vermitteln, dass dies tatsächlich sein Ersatz ist, müssen zwei Bedingungen erfüllt sein:

  • Der Ersatz sollte qualifizierter sein.
  • Es ist notwendig, der Primadonna klar zu machen, dass sein Ersatz keine andere Aufgabe hat, als dem Schatten der Primadonna zu folgen und zu lernen, wie man sie ersetzt.

Je schneller der Ersatz das gesamte Wissen über den Legacy-Code sammelt, den die Primadonna besitzen kann (siehe Entwicklertypen, Legacy-Code-Bewahrer und Geiselnehmer ), desto schneller kehrt die Primadonna zur Kontrolle zurück. Der Effekt kann dramatisch sein: In wenigen Tagen kann sich alles ändern. In der Form beginnt die Diva, eine zusätzliche Funktion zu ihrem Ersatz auszuführen. Letztendlich ist er nicht mehr unverzichtbar und daher keine Diva mehr, sondern einfach ein armer Angestellter.

Die einzige Hoffnung der Primadonna besteht darin, ein Gefühl für den Status zu bewahren - eine Beförderung in eine Führungsposition zu erreichen (siehe Entwickler wie Marking Manager ). Je besser er ist, desto eher wird er versuchen, einen Ersatz zu finden. Die Erhöhung wird jedoch nicht empfohlen, da Sie wahrscheinlich die Entlassung der Entwickler sehen, für die die Diva verantwortlich ist. Wenn er einen Antrag auf Beförderung ablehnt, hat er daher nur zwei Möglichkeiten: sich mit anderen Entwicklern zu messen oder zu gehen. In jedem Fall ist Ihr Problem behoben.

Idealist


Der Entwickler ist so besessen davon, architektonische Eleganz und Code-Exzellenz zu erreichen, dass er vergisst, dass seine Arbeit dem Geschäft zugute kommen sollte.


Das Problem


Der Beruf eines Softwareentwicklers erfordert ein konstantes Gleichgewicht zwischen zwei gegensätzlichen Aufgaben:

  1. Der Wunsch, dem Geschäft zu nützen (und bezahlt zu werden).
  2. Der Wunsch, exzellente Software zu schreiben (und stolz zu sein).

Der Idealist ignorierte das Ziel, dem Geschäft zu nützen, völlig und konzentrierte sich stattdessen ausschließlich auf das Schreiben großartiger Software.

Der idealistische Entwickler ist normalerweise sehr klug, erfahren und professionell. Er weiß wirklich, wovon er spricht. Er weiß wirklich, wie man großartige Software schreibt, und wenn ihm genügend Zeit gegeben wird, kann er das perfekte System erstellen. Das Problem ist, dass er glaubt, die ganze Zeit auf der Welt und völlige Freiheit zu haben , obwohl dies weit davon entfernt ist.

Anstatt Kompromisse einzugehen, konzentrierte er sich darauf, das perfekte System zu schaffen. Er glaubt, dass dies besser für das Geschäft ist. Verwechseln Sie sie nicht mit Wissenschaftlern, die etwas „Absolutes“ oder „Cooles“ schaffen: Idealisten glauben aufrichtig, dass ihr ideales System am besten für die Entwicklung des Unternehmens geeignet ist. Wegen der Standhaftigkeit dieses Glaubens sind sie so schwer zu korrigieren.

Idealisten sind für ein Projekt besonders gefährlich, weil sie normalerweise die Macht über andere Schlüsselentwickler haben, weil sie das Ideal darstellen, das Entwickler anstreben, so dass sie andere Programmierer so einfach auf ihre Seite bringen können, weil alle Entwickler stolz auf die Software sein wollen, die sie schreiben. Somit nehmen sie das gesamte Entwicklungsteam als Geisel , und Sie sind jetzt in ihrer Macht. Wenn Sie Glück haben, werden sie anfangen, dem Unternehmen einen Mehrwert zu bieten, aber es wird nur ein zufälliger Nebeneffekt bei ihrer Suche nach großartiger Software sein. Tatsächlich werden die Vorteile für das Unternehmen erst am Ende der Arbeit angezeigt, aber sie können Ihnen nicht den Zeitrahmen mitteilen oder diesen Nutzen bewerten. In Wahrheit sind sie nicht einmal daran interessiert, etwas zu vollenden, denn es ist der Prozess selbst, nicht das Ziel, das sie zufriedenstellt.

Lösung


Wir fassen die idealistischen Merkmale zusammen:

  • Sehr klug, erfahren und professionell.
  • Mit freundlichen Grüßen glaubt, dass sein System besser für die Zukunft des Unternehmens ist.

In vielerlei Hinsicht ist er ein sehr guter Mitarbeiter, und wenn man sich die innovativsten Unternehmen der Welt ansieht, haben sie viele Idealisten in den Forschungs- und Entwicklungsabteilungen. Die besten Unternehmen haben jedoch drei Dinge, die der Rest nicht hat:

  1. Führungskräfte sind ebenso kompetent wie Idealisten und bieten Checks and Balances für ihre technischen Entscheidungen an.
  2. Die Erwartung, dass eine bestimmte Anzahl von Projekten scheitern wird, was die üblichen Geschäftskosten sind.
  3. Ein großes Budget, um weiterhin Projekte zu finanzieren, die unrentabel sind.

Wenn Ihr Unternehmen diese drei Dinge hat, lassen Sie den Idealisten in Ruhe und lassen Sie ihn tun, was er will. Aber wenn Sie, wie die meisten Unternehmen, diese luxuriösen Bedingungen nicht haben, tritt ein echtes Problem auf, da fast alles, was Sie tun, zu einer Katastrophe führen wird:

  • Wenn Sie ihn sofort entlassen, können treue Entwickler ihm bald folgen.
  • Wenn Sie strenge Regeln festlegen, kann er sich mental vom Projekt trennen, sodass Sie keine technische Anleitung erhalten.
  • Wenn Sie ihn in Ruhe lassen, werden die Behörden irgendwann den Mangel an greifbaren Fortschritten satt haben.

Um einen Idealisten zu zwingen, sein Verhalten zu ändern, müssen Sie jemanden finden, der ihn überzeugen kann. Diese Person muss dem Idealisten zeigen, dass auch sie ein ausgezeichnetes System schaffen kann. Dies ist wichtig, da eine Person ohne technische Kompetenz einfach ignoriert wird, weil sie das Genie eines idealen Designs nicht verstehen kann.

Wenn eine Person mit einem solchen Vertrauen gefunden wird, muss sie den Idealisten langsam und methodisch aus seiner idealistischen Denkweise ableiten. Dies erfordert, dass ein hochintelligenter, erfahrener Fachmann bereit ist, das zu tun, was er für richtig hält. Die Chancen dafür sind gering, und daher gibt es kaum eine Chance, den Idealisten zu korrigieren.

Rockstar


Der Entwickler ist so talentiert, so produktiv und so wichtig, dass das gesamte Projekt zusammenbricht, wenn er geht.

  • Kann zu einem Geiselnehmer und einer Diva mutieren
  • In Kombination mit einem optimistischen Typmanager ist dies gefährlich
  • Korrekturmöglichkeit: nein
  • Projektgefahr: extrem hoch

Das Problem


In der Softwareindustrie wird der Begriff "Rockstar" häufig von Personalvermittlern verwendet, die versuchen, Entwickler anzuziehen, indem sie ihr Ego aufblähen, dh "wir suchen mehrere Entwickler von Rockstars". Es ist schwer, echte Rockstars zu finden, da sie ideale Programmierer sind:

  • Es gibt kein Problem, das sie nicht (und zwar schnell) lösen können.
  • Sie arbeiten die ganze Nacht, um die Frist einzuhalten.
  • Der Code enthält praktisch keine Fehler, oder Fehler werden schnell behoben.
  • Sie übernehmen die schwierigsten Teile des Projekts.
  • Sie sind normalerweise sehr gern Kollegen.

Leider werden sie nach ihrer Einstellung für das Projekt unverzichtbar.

Ein Rockstar sieht aus wie ein Schwarzes Loch: Um ihn herum sammelt sich Arbeit an und wird letztendlich unweigerlich angesaugt, um erledigt zu werden. Es kann zu einem Punkt kommen, an dem sie langsameren Entwicklern die Arbeit wegnehmen, um die Fristen einzuhalten - zur Erleichterung aller. Wenn sich das Projekt in einem Dilemma befindet, werden sie die Situation retten. Wenn etwas Dramatisches und Unerwartetes passiert, wissen sie, was zu tun ist. Sie sind wirklich großartig - und das weiß jeder Personalvermittler.

Personalvermittler rufen mehrmals täglich einen Rockstar an. Ihr Ruf liegt vor ihnen. Unternehmen wollen immer Rockstars anlocken, weil sie ihren Wert verstehen, und in vielen Fällen werden sie fast alles tun, um sie zu bekommen. Daher ist die Situation so, dass für Ihr Projekt jemand unverzichtbar ist, den jedes zweite Unternehmen anlocken möchte. In diesem Fall schlägt das Projekt fehl. Der klassische Fall ist, wenn zu viele Eier in einen Korb gelegt werden.

Lösung


Es gibt keine "Lösung" für einen Rockstar. Am Ende wird nur ein Narr es „reparieren“ wollen, weil er Ihr bisher produktivster Entwickler ist. Alles, was Sie tun können, ist, den Schaden zu mindern, indem Sie ein Team bilden, das effektiv funktioniert, wenn er geht. Höchstwahrscheinlich benötigen Sie mehrere Entwickler, um die Leistung eines Rockstars zu ersetzen, aber zumindest können Sie seine Abreise überleben.

Um zu überprüfen, wie schlecht Ihre Situation ist, achten Sie genau auf die Entwicklerproduktivität, wenn ein Rockstar in den Urlaub fährt. Wenn während der wöchentlichen Abwesenheit alle Entwicklungen gestoppt werden, müssen Sie die Anstrengungen verdoppeln, um andere Entwickler auf das Niveau zu bringen, auf dem sie die Entwicklung des Projekts auch ohne Rockstar fortsetzen können.

Dies kann schwierig sein, wenn die Entwickler daran gewöhnt sind, dass er mit komplexen Problemen fertig wird, sie faul und selbstgefällig werden. Es besteht die Möglichkeit, dass mit dem plötzlichen Abgang des Rockstars andere Entwickler Maßnahmen ergreifen. Aber höchstwahrscheinlich lieben sie ihn so sehr, dass sie ihm zu einer neuen Firma folgen werden.

Kennzeichnung bei Managern


Ein Entwickler, der sich entschied, Programmierschwierigkeiten zu vermeiden und einer der Manager zu werden.


Das Problem


Programmierung ist schwer zu lernen. Es erfordert die Fähigkeit, Probleme schnell zu lösen, viel Wissen und noch mehr reale Erfahrung. Im Gegensatz zu vergleichbaren Berufsfeldern werden diese Kenntnisse und Erfahrungen viel schneller (manchmal innerhalb von Monaten) veraltet, was die ständige Entwicklung neuer Methoden, Technologien und Werkzeuge erfordert. Das Einwerfen von Managern möchte diese Aufregung loswerden und sieht einen Ausweg im Management .

Für Entwicklungsmanager sind die Anforderungen an Programmierkenntnisse in der Regel geringer als für Entwickler. Die Zeit wird für Besprechungen, das Versenden von E-Mails oder sogar für das Gehen und Chatten mit anderen Personen aufgewendet. Manager neigen auch dazu, mehr zu verdienen als Programmierer, aber mit dem Status kommen Befugnisse. Dies ist eine offensichtliche Wahl für Entwickler, die das Schreiben von Software loswerden möchten.

Das Problem mit dem Entwickler, der anfing, über die Karriere des Managers nachzudenken, ist, dass er versucht, seine Managementfähigkeiten in der Hoffnung auf Verbesserung zu demonstrieren, anstatt über Programmierung nachzudenken . Um Managementfähigkeiten zu üben, versucht der zukünftige Manager, andere Entwickler zu befehlen: Arbeit zuweisen, bei Besprechungen sprechen und in der Regel versuchen, an strategischeren Entscheidungen teilzunehmen. Daher werden sie von anderen Entwicklern und anderen Managern, die eine Bedrohung für ihre Arbeit sehen, nicht gleichermaßen geliebt.

Lösung


Es ist unmöglich, das Problem des zukünftigen Managers zu lösen, da er bereits eine klare Berufswahl getroffen hat. Sobald die Entscheidung getroffen ist, gibt es kein Zurück mehr. Sie können ihn nicht zwingen, erneut Programme zu schreiben. Selbst wenn er gezwungen wird, werden Sie bald den Grund finden, warum er über die Karriere eines Managers nachdachte: Der Typ ist nicht sehr gut im Programmieren. Aufgrund der Komplexität dieser Situation erhalten so viele Programmierer und Manager, was sie wollen: Beförderung zum Manager, wenn eine Stelle frei ist.

Entwickler in dieser Position sind in der Regel nicht besonders schädlich für das Projekt, da ihre Produktivität zu niedrig ist und sie normalerweise nicht das besondere Vertrauen von Entwicklern oder Managern haben. Oft hängen diese Leute während ihrer gesamten Karriere in der Organisation herum, und die Geschäftsleitung hat Schwierigkeiten, eine Bewerbung für sie zu finden . Als solche können sie gefährlich werden, wenn sie mit einer kritischen Mission betraut werden. Da dies jedoch vollständig vermieden werden kann, können sie sicher nur ein kleiner ärgerlicher Faktor bleiben.

Geiselnehmer


Ein Entwickler, der eine kritische Software geschrieben hat und niemandem erlaubt, daran zu arbeiten, um ihre Unentbehrlichkeit aufrechtzuerhalten.


Das Problem


Für Personen mit finanziellen Verpflichtungen ist es wichtig, die Sicherheit ihres Arbeitsplatzes und ihres Gehalts zu gewährleisten. Darüber hinaus ist das Arbeiten mit bekanntem Code viel einfacher als das Arbeiten mit unbekanntem Code. Aus der Kombination dieser beiden Wünsche entsteht ein Geiselnehmer - ein Entwickler, der eine kritische Software geschrieben hat und allein besitzt und sich weigert, an irgendetwas anderem zu arbeiten .

In der Regel handelt es sich hierbei um einen schlechten Softwareentwickler, der ironischerweise zu einem wichtigen Vorteil wird: Sein Code ist normalerweise für niemanden verständlich , sodass andere Entwickler Angst haben, in einen solchen Sumpf zu geraten, weil sie befürchten, mehr Schaden als Nutzen zu verursachen. Daher werden alle neuen Arbeiten an einem kritischen System an den Eindringling übertragen, wodurch der Teufelskreis fortgesetzt wird.

Der Geiselnehmer nimmt normalerweise eine defensive und konfrontative Position ein, er ist absolut offen für Kritik oder Zusammenarbeit in Bezug auf seine Codebasis. Wenn Sie ihn wirklich in eine Ecke fahren, droht er zu gehen, und da niemand anderes ein schlecht gestaltetes und geschriebenes Produkt übernehmen möchte, wird ein solcher Bluff selten bestraft. Sie können zu einem Engpass im Projekt werden, da das gesamte Schicksal des Projekts von ihrem Wunsch und ihrer Fähigkeit abhängt, einen Code herauszugeben.

Lösung


Egal wie gefährlich der Geiselnehmer ist, die Lösung ist einfach: Weisen Sie zwei oder mehr Entwicklern die Verantwortung für einen Teil des Eindringlingssystems zu und übertragen Sie ihn auf einen anderen Teil. Für einige Zeit wird die Leistung niedrig sein, bis neue Entwickler versuchen, den Code zu verstehen und zu überarbeiten. Am Ende dieses Zeitraums wird der Eindringling jedoch vollständig neutralisiert und stellt kein Problem mehr dar.

Elefant in einem Porzellanladen


Der Entwickler konzentriert sich so auf die Fertigstellung der Arbeit, dass er jegliches Qualitätskonzept völlig aufgibt.


Das Problem


Entwickler stehen immer unter enormem Druck. "Das Internet schläft nie" bedeutet, dass Entwickler oft auch nicht schlafen. Um das Gleichgewicht zwischen Arbeit und Leben wiederherzustellen, möchte ein Elefant in einem Porzellanladen seine Aufgabenliste so schnell wie möglich vervollständigen und zu seiner Familie zurückkehren.

Diese Art von Programmierer erzeugt Projektdruck. Egal wie gut der Entwickler ist, wenn der Druck bis zu einem gewissen Grad steigt, wird er unweigerlich aufhören, seine eigene Arbeit zu testen, und sich stattdessen auf die Testabteilung verlassen (siehe die Art des Testers der Staatsanwaltschaft) als einziges Mittel, um Fehler zu finden. Darüber hinaus verweigern sie der Einfachheit halber die Überprüfung von Peer-Codes, das automatische Testen und das Refactoring, wodurch der Code in einem schlechten Zustand bleibt. Diese schlecht gestaltete Software verursacht dann neue Fehler und die Codebasis verwandelt sich schnell in einen Sumpf von Fehlern, die nicht vollständig behoben werden können.

Ein Elefant in einem Porzellanladen lebt aufgrund des Drucks seiner Vorgesetzten in ständigem Stress. Er ist das Opfer eines schlecht geplanten Projekts, aber der Entwickler wird immer noch als Problem angesehen. In Bezug auf Elefanten im Porzellanladen wird der Ausdruck „Burnout und Ersatz“ verwendet, da ständiger Stress sie schließlich brechen wird und sie aufgrund ihrer scheinbaren Inkompetenz entweder gehen oder gefeuert werden.

Lösung


Da das Problem nicht bei der Person liegt, muss die Organisation die folgenden Schritte ausführen:

  1. , . .
  2. , .
  3. . . , , .
  4. , . , .
  5. , , .

Obwohl diese Schritte das Problem eindeutig lösen können, werden sie fast nie unternommen. Das heißt, das Management bleibt die Ursache des Problems und nicht die Quelle der Lösung. Wenn die Führung jedoch ihre Rolle beim Erscheinen von Elefanten im Porzellanladen erkennt, kann der Schaden in wenigen Wochen ausgeglichen werden, und die Entwicklung des Projekts wird sich wieder normalisieren.

Inkompetent


Ein Entwickler, dem die Intelligenz oder die Fähigkeiten zum Schreiben von Software fehlen.


Das Problem


Nicht jeder kann ein Profisportler, ein erfahrener Musiker oder ein Arzt werden. Es gibt auch Leute, die einfach nicht dafür geschaffen sind, Softwareentwickler zu sein. Diese inkompetenten Entwickler bestreiten häufig ihre Inkompetenz und weigern sich aufgrund des hohen Gehalts und der großen Anzahl verfügbarer Stellen, den Beruf zu verlassen.

Es mag für einen Manager ohne technische Ausbildung schwierig sein, einen inkompetenten Entwickler zu erkennen, aber es gibt mehrere Anzeichen:

  • In ihrer geringen Produktivität machen sie den Mangel an Unternehmensschulungen verantwortlich.
  • Der Einsatz „zu komplexer“ Technologien, Werkzeuge und Methoden ist umstritten.
  • Überschätzen Sie den Zeitrahmen für die Arbeit stark (siehe Pessimist ) und geben Sie ihn dann immer noch nicht rechtzeitig weiter.
  • Sie erzeugen Funktionen, die nicht den Spezifikationen entsprechen.
  • Die implementierten Funktionen sind voller Fehler.
  • Erfahrene Entwickler vermeiden oder lehnen es ab, mit ihnen zu arbeiten.
  • Wenn sie nach Fortschritten gefragt werden, machen sie Ausreden und nehmen oft eine defensive Position ein.
  • Sie bewerben sich um eine Führungsposition (siehe Kennzeichnung von Managern ), um „mehr Nutzen“ zu bringen.

Die gesamte Softwareindustrie leidet unter einem Inkompetenzproblem. Dies ist ein einfaches Beispiel für Angebot und Nachfrage, wenn es auf dem Arbeitsmarkt nicht genügend qualifizierte Entwickler gibt.

Lösung


Wenn ein Manager einen inkompetenten Entwickler bemerkt, fordert ihn das natürliche Gefühl von Empathie oft dazu auf, Aufgaben einfacher zuzuweisen. Leider kann niemand ein nur teilweise kompetenter Softwareentwickler sein, so wie man kein halbkundiger Herzchirurg oder teilweise kompetenter Pilot sein kann. Wenn Sie nicht in der Lage sind, Software zu entwickeln, können Sie selbst einfache Aufgaben nicht gut ausführen.

Wenn einfache Aufgaben zu komplex sind, besteht der nächste Schritt normalerweise darin, ein Schulungsbudget vorzusehen. Das Hauptproblem dabei ist, dass ein inkompetenter Entwickler, wenn er lernen könnte, dies bereits tun würde - als seine kompetenteren Kollegen, da kompetente Entwickler selbst lernen.

Es gibt den Gedanken, dass die Anwesenheit eines nicht sehr produktiven Entwicklers im Staat keinen Schaden anrichtet, aber dies ist ein großer Fehler. Sie verursachen zwei sehr schädliche Wirkungen:

  1. Zerstörung der Qualität der Codebasis, Erscheinen eines neuen Buggy-Codes und Einführung von Bugs in den Arbeitscode (siehe auch den Elefanten im Porzellanladen )
  2. Sie stoßen kompetente Entwickler ab, die es satt haben, mit ihnen zu arbeiten.

Wenn das Projekt von einem inkompetenten Entwickler abhängt, wird das Projekt letztendlich nicht abgeschlossen . Dies führt zu der traurigen Schlussfolgerung, dass solche Arbeitnehmer die Organisation verlassen müssen. Wenn sie nicht übereinstimmen (normalerweise nach immer direkteren Hinweisen), sollten sie gefeuert werden.

Optimist


Ein Entwickler, der den Zeitaufwand für die Ausführung einer Aufgabe ständig unterschätzt.

  • Kann zu einem Pessimisten mutieren
  • Gefährlich in Kombination mit einem optimistischen Projektmanager
  • Korrekturmöglichkeit: hoch
  • Gefahr für das Projekt: mittel

Das Problem


Das Unterschätzen von Fristen ist in der Softwareindustrie ein so häufiges Symptom, dass viele dies nicht einmal als Problem betrachten. Jeder unterschätzt immer das Timing, und in vielen Fällen wird dies als Teil des Geschäfts akzeptiert. Trotzdem bringt der optimistische Entwickler das Problem auf eine ganz neue Ebene, da er die Arbeit fast immer viel später aufgibt.

Ein Optimist beeinflusst die Vorhersehbarkeit eines Projekts: Ohne gute Noten ist es unmöglich, die Zukunft zu planen. Software-Releases sind manchmal mit vertraglichen Verpflichtungen gegenüber Kunden und / oder Partnern verbunden, was Vorhersehbarkeit zu einer geschäftlichen Notwendigkeit macht. Natürlich kann man immer ein wenig Unvorhersehbarkeit erwarten, da in Wirklichkeit die gesamte Softwareindustrie auf der Tatsache beruht, dass es unmöglich ist, genau vorherzusagen, wie lange es dauert, Software zu schreiben. Der Optimist missbraucht diese Toleranz für die Nichteinhaltung von Fristen und erledigt seine Aufgaben in wenigen Wochen anstatt in den versprochenen Tagen. oder, noch schlimmer, in ein paar Monaten anstelle der versprochenen paar Wochen.

Der Optimist versteht die negativen Auswirkungen solcher Verzögerungen auf den Gesamterfolg des Projekts grundsätzlich nicht. Er könnte auch der Ansicht sein, dass die Bewertung selbst eine sinnlose Praxis ist, da nichts jemals genau geschätzt werden kann. Auf diese Weise kann er eine beliebige Zahl ohne Analyse eindrucksvoll bewerten oder ausgeben.

Lösung


Glücklicherweise kann ein Optimist durch Befolgen einiger Regeln korrigiert werden:

  • Bitten Sie sie, nur den Code auszuwerten, mit dem sie vertraut sind.
  • Bitten Sie um eine Bewertung nur für Technologien, mit denen sie vertraut sind.
  • Bitten Sie niemals darum, den Zeitpunkt der Implementierung neuer Funktionen zu bewerten, sondern verbessern Sie nur vorhandene.
  • Es muss darauf geachtet werden, dass sie alle Anforderungen vollständig verstehen - sie können die Anforderungen nicht im laufenden Betrieb frei interpretieren.
  • Bitten Sie den Optimisten, in Bereichen, in denen Änderungen vorgenommen werden müssen, „TODO“ -Kommentare hinzuzufügen. Dies wird die Beziehung zwischen Softwarekomplexität und Zeitplänen stärken.
  • Machen Sie sie verantwortlich: Zeigen Sie ihre Noten einer Gruppe, die solche Fristen anfechten kann.

Wenn der Optimist diesen Prozess mehrmals durchlaufen und seine Verpflichtungen erfüllt hat, können Sie seiner Einschätzung der Begriffe für neue Funktionen sowie für Codebasen und Technologien, mit denen er weniger vertraut ist, vertrauen.

Achten Sie während des Rehabilitationsprozesses eines Optimisten genau darauf, wie er seine Fristen einhält:

  • Leidet die Qualität der Arbeit unter erhöhten Verpflichtungen (siehe den Elefanten im Porzellanladen ). Wenn ja, schlagen Sie vor, die erforderliche Zeit zum Testen hinzuzufügen.
  • Arbeiten sie Überstunden, um die Fristen einzuhalten (siehe Soldat )? In diesem Fall schlagen Sie vor, Zeit hinzuzufügen, um die Arbeit während der Geschäftszeiten abzuschließen, und Überstunden sollten für unvorhergesehene Umstände verbleiben.

Wenn ein Optimist seine Rehabilitation ernst nimmt, kann er zu einem sehr vertrauenswürdigen Teammitglied heranwachsen, da Entwicklern vertraut wird, die einen Code von ausreichender Qualität herausgeben, der die Anforderungen in einem vereinbarten Zeitraum erfüllt. Sobald sie nachweisen, dass sie dies stabil tun können, können sie eine Beförderung oder ein Gehalt erhalten, das an sich als Anreiz für ihre Rehabilitation angeboten werden kann.

Pessimist


Ein Entwickler, der solche Angst vor Terminüberschreitungen hat, dass er nach der maximal möglichen Zeit für die Ausführung der Aufgabe fragt.

  • :
  • :

Das Problem


Wenn es eine Wahl gibt, würden die meisten Projektmanager Pessimisten Optimisten vorziehen. Sie können zwar lange arbeiten, sind aber zumindest vorhersehbar. Der Pessimist weiß das sehr gut und nutzt diesen Umstand voll aus und fordert die maximale Zeit für seine Aufgabe an, anstatt realistische Begriffe zu berücksichtigen.

Pessimisten sind manchmal nicht zu bemerken. Sie können für ausgereift und verantwortungsbewusst gehalten werden, da sie im Gegensatz zu ihren scheinbar weniger erfahrenen Kollegen nie die Frist verpassen. Aber es gibt einige Anzeichen:

  • Ihre Kollegen mit der gleichen Einschätzung geben deutlich kürzere Vorlaufzeiten.
  • Wenn Sie ihnen eine Frist zuweisen, stimmen sie ohne formelle Bewertung sofort zu.
  • Wenn sie sich schnell einig waren und Sie das Datum leicht auf ein früheres Datum verschieben, stimmen sie auch diesem Datum zu. Dies bedeutet, dass zwischen den beiden Daten keine zusätzliche Zeit erforderlich ist, um die Aufgabe abzuschließen.

Ein Pessimist kann die Wettbewerbsfähigkeit eines Unternehmens verringern. Wenn Sie an einem Rennen mit einem Konkurrenten beteiligt sind, sind Sie immer langsamer als er.

Lösung


Pessimisten werden durch die Schuld einer Organisation geboren, die die Nichteinhaltung von Fristen bestraft. Die natürliche Reaktion der Menschen besteht darin, so viel Zeit wie möglich zu fordern, um die Wahrscheinlichkeit einer Bestrafung zu minimieren. Dies mag wie eine einfache Lösung erscheinen, aber drei Dinge wirken gegen Sie:

  1. Pessimistische Arbeit ist viel weniger stressig als normale Arbeit.
  2. Pessimisten werden in der Regel häufiger belohnt und befördert als diejenigen, die wichtige Fristen verpassen.
  3. Unternehmen sollten toleranter gegenüber Verspätungen sein. Wenn eine bestimmte Entwicklungskultur etabliert ist, sind die meisten Unternehmen dazu nicht in der Lage.

Daher ist das Problem behebbar, aber normalerweise gibt es keinen Willen, es zu beheben. Pessimisten stellen naturgemäß keine Bedrohung für das Projekt dar, sind jedoch potenziell sehr gefährlich für die Zukunftsfähigkeit des Unternehmens.

Ein Soldat


Ein Entwickler, der ohne Frage genau das tut, was er sagt, unabhängig davon, ob es richtig ist.


Das Problem


Wer kann aus Managersicht besser sein als ein Entwickler, der genau das tut, was gesagt wird? In der Tat ist das Hauptproblem bei der Primadonna, dass sie nicht den Anweisungen folgt. Natürlich ist ein völlig gehorsamer Entwickler ein Segen für das Projekt. Leider hat der Soldat seinen eigenen Nachteil: Er wird gehorsam in den Abgrund springen, wenn sie es ihm sagen, und das ganze Projekt mitnehmen .

Ein Soldat kann jede Fähigkeitsstufe haben: von einem inkompetenten zu einem Rockstar . Ein wesentliches Merkmal ist sein Gehorsam: Jedes Mal wird er genau das tun, was Sie ihm sagen. Es ist leicht, einen Fehler zu machen, wenn man bedenkt, dass dies ein Effekt fantastischer Führung ist, aber exzellente Chefs sind sehr selten.

Soldaten werden auf verschiedene Arten geboren:

  • , : . , , .
  • , , , .
  • , , , .
  • , , , - .
  • , , .
  • , — , .
  • Sie haben sich selbst davon überzeugt, dass die vollständige Einreichung der Weg zum Karrierewachstum ist, was sehr traurig ist, da dies im innovativen Bereich der Softwareentwicklung so gut wie nie der Fall ist.
  • Dies sind wirklich ehemalige Militärs, die eine bestimmte Mentalität mitgebracht haben.

Unabhängig davon, wie angenehm es scheint, einen Soldaten in seinem Kommando zu haben, ist dies kaum gut.

Lösung


Wenn Sie die richtigen Befehle erteilen, verursacht der Soldat keine Probleme. In der Tat ist bei starker Führung die Anwesenheit einer Abteilung von Soldaten eine sehr effektive Waffe. Wenn Sie jedoch Feedback von Entwicklern benötigen, um das Projekt gemeinsam zu leiten, erhalten Sie keine solche Zusammenarbeit. Dies versetzt Sie in eine Situation der Spannung, in der Sie nicht einmal wissen, dass Ihnen etwas fehlt. Aber der Soldat wird es nicht sagen.

Wenn Sie feststellen können, warum der Soldat Ihnen implizit gehorcht, besteht die Möglichkeit, dies zu beheben. Von Natur aus wird er jedoch nicht offen sagen, warum er so wurde. Normalerweise kommuniziert ein Soldat lieber zu bestimmten Arbeitsthemen. Wenn Sie drücken und fragen, ob ein Problem vorliegt, lautet die wahrscheinlichste Antwort "Nein", unabhängig von seinen wahren Gefühlen.

Sie können nur hoffen, dass seine Kollegen von dem Soldaten erzählen, aber dann verraten sie sein Vertrauen, was unwahrscheinlich ist. Selbst wenn Sie das wahre Problem identifizieren, müssen Sie es beheben, was schwierig sein kann. Nachdem die Grundursache beseitigt wurde, bleibt zu hoffen, dass der Soldat sein Verhalten ändert. Nur er kann sich ändern.

Im Allgemeinen sind sie fast unmöglich zu reparieren. Daher sind dies normalerweise gute Mitarbeiter, um eine starke Führungskraft zu unterstützen.

Tech-Fan


Ein Entwickler, der so gerne neue Technologien ausprobiert, dass er sie in das Projekt implementiert, ist es angemessen oder nicht.

  • Kann zu einem Geiselnehmer mutieren
  • Gefährlich in Kombination mit dem Idealisten
  • Korrekturmöglichkeit: hoch
  • Gefahr für das Projekt: gering

Das Problem


Um das Produkt erfolgreich zu starten, müssen Sie die Technologie auswählen. Dies ist eine sorgfältige Auswahl unter Berücksichtigung einer Reihe von Geschäftsproblemen, die angegangen werden müssen. Ein Tech-Fan liebt neues Spielzeug.

Alle Entwickler sind etwas in Technologie verliebt: Sie müssen so sein, dass sie ihre Fähigkeiten behalten. Wenn ein Entwickler jedoch seine berufliche Verantwortung und seine persönliche Neugier verwechselt, kann dies zu einem Technologie-Stack führen, der mit Geschäftsaufgaben völlig unvereinbar ist.

Ein Entwickler, der in Technologie verliebt ist, ist sehr leicht von der Masse zu unterscheiden. Er wird sich oft und öffentlich für den Einsatz neuer Technologien einsetzen, oft mit nicht schlüssigen Argumenten. Er ändert auch plötzlich die Technologie mitten in der Arbeit, ohne es jemandem zu sagen und andere zu überraschen. In vielen Fällen kann dies eine wirklich hervorragende technische Lösung für ein bestimmtes Problem sein. Da die Technologie jedoch den richtigen Test nicht bestanden hat, ist sie möglicherweise für das gesamte Projekt schlecht geeignet.

Lösung


Technologie-Fans werden sich selbst reparieren, wenn das Unternehmen einen Standard-Technologie-Stack installiert hat. Dann müssen Sie nur noch sicherstellen, dass die Entwickler nicht davon abweichen. Wenn Sie keinen Technologie-Stack installiert haben, wird dringend empfohlen, diesen im Voraus zu definieren, da es unpraktisch ist, ihn einzugeben, nachdem der Technologie-Lüfter aktiv wird.

Die Nachricht, dass Sie Ihre neue Technologie nicht verwenden können, kann die Moral eines Technologieliebhabers beeinträchtigen, aber diese Moral kann schnell wiederhergestellt werden, indem Sie ihn bitten, eine Präsentation über diese neue Technologie zu halten. Dies ist eine äußerst gesunde Entscheidung, da das Team nach der Präsentation gemeinsam diskutieren kann, ob es sinnvoll ist, den Stapel von Unternehmenstechnologien zu erweitern. Die meisten Technologieliebhaber werden mit einem solchen Test zufrieden sein, auch wenn ihnen die endgültige Entscheidung nicht gefällt.

Legacy Keeper


Ein Entwickler, dessen einzige Fähigkeit darin besteht, veraltete Software zu warten, und der daher keinen neuen Job annehmen kann.

  • Kann zu einem Geiselnehmer oder Soldaten mutieren
  • Gefährlich in Verbindung mit einem kreativen Designer
  • Korrekturmöglichkeit: nein
  • Gefahr für das Projekt: nein

Das Problem


Wenn ein neuer Entwickler in das Unternehmen kommt, ist er normalerweise voller Feuer und Leidenschaft und versucht, sich auf jede erdenkliche Weise zu beweisen. Aber im Laufe der Zeit nimmt der Ort der Leidenschaft Selbstzufriedenheit: Der Entwickler glaubt, dass die Erfahrung im Unternehmen ihm bestimmte Privilegien verleiht. Für sich selbst erkennt er die Verpflichtung an, seine Systeme zu warten, aber keine neuen Teile zu entwickeln.

Das Problem mit dem Legacy-Code-Custodian hängt mit der Skalierung zusammen: Sie sind einfach nicht im Pool verfügbarer Ressourcen für neue Arbeiten enthalten. An dieser Stelle stellt sich die Frage, ob Sie es sich leisten können, Mitarbeiter zu beschäftigen, dh ob andere Entwickler ihre Aufgabe übernehmen können, Legacy-Code zu warten. Es ist normalerweise aus zwei Gründen schwierig, andere Entwickler davon zu überzeugen:

  1. Alter Code ist normalerweise schlecht geschrieben und schwer zu bearbeiten.
  2. Support ist eine Sackgasse, da Sie nichts Neues oder Innovatives tun, für das Sie möglicherweise gekennzeichnet sind.

Aus diesem Grund sind alte Betreuer schon so lange im Unternehmen. Oft sind sie seit ihrer Gründung im Unternehmen und die Autoren der Software, auf der das Unternehmen basiert. Als das Unternehmen wuchs, kamen sie jedoch nicht in den Service oder versuchten nicht, neue Fähigkeiten oder neue Teile des Systems zu beherrschen, wodurch sie fest mit dem einzigen Code verbunden waren, den sie kannten.

Lösung


Legacy Code Keeper verursacht keine Probleme, wenn Sie verstehen, dass es nicht zu den Ressourcen für die Arbeit an neuen Projekten gehört. Im besten Fall können Sie ihn bitten, Fehler zu beheben und kleine Funktionsverbesserungen zu implementieren. Das einzige Problem entsteht, wenn sie anderen verbieten, sich mit ihrem Teil des Systems vertraut zu machen (siehe Geiselnehmer ).

Der Wächter kann nicht repariert werden, weil er keinen solchen Wunsch hat. Er hat die Mentalität eines Fabrikarbeiters: während seiner Karriere jeden Tag die gleiche Nuss drehen und dann in den Ruhestand gehen. Diese Haltung kann nicht geändert werden, weil sie das Wesen des Menschen ist.

Eine der Optionen, die diese Einstellung ändern können, besteht darin, dass eine Person bedeutende Ereignisse im Leben erlebt (Hochzeit, Geburt, Hauskauf usw.), die zusätzliches Einkommen erfordern. In diesem Fall wird er verstehen, dass die Unterstützung für veraltete Software nicht zu einer Erhöhung führen wird. Leider kontrollieren Sie diesen Faktor nicht.

Siehe auch:

Source: https://habr.com/ru/post/de431534/

More articles:


All Articles