Manager ändert die Anforderungsspezifikation nach jeder Demo [geschlossen]

Hintergrund meiner Arbeitswelt

Mein Manager hat keinerlei Kenntnisse über Computer oder Software. Es ist sehr wahrscheinlich, dass er in seinem Leben keinen Code in irgendeiner Form gesehen hat (nicht einmal aus einer Entfernung von 10 Fuß oder weniger).

Es gibt niemanden, der die Komplexität dessen versteht, was ich implementieren soll. Bis zu dem Punkt, dass wenn ich semi-hardcode würde niemand wissen.

Bei Joels Test erzielen wir eine unglaubliche Punktzahl von 0.

Die Probleme

• Der Manager und zuweilen auch andere "Senioren" ändern ständig die Anforderungsspezifikation. Änderungen, die, wenn ein gutes Engineering durchgeführt und keine lückenhaften "Korrekturen" vorgenommen werden, eine Änderung des zugrunde liegenden Designs erfordern.
• Es gibt absolut niemanden, der sich Code ansieht (wahrscheinlich, weil niemand weiß, wie es geht oder auch wenn es getan werden sollte), was bedeutet, dass niemand jemals in der Lage sein wird:
  • Schätzen Sie die Komplexität des Problems oder die Eleganz der Lösung.
  • Schlagen Sie eine Verbesserung des Ansatzes vor.
  • Schätzen Sie die Qualität des Codes.
  • Zeigen Sie auf, wo der Code verbessert werden kann.
• Es wird viel Jargon verwendet, was grammatikalisch sinnvoll ist, aber auf andere Weise keinen Sinn ergibt.
• Fühlt, benimmt sich oder arbeitet nicht wie ein Softwareunternehmen.

Die Frage

Was soll getan werden? Vor allem, wenn es niemanden gibt, der auf Verbesserungen in meinem Code hinweist.

Aktualisieren

Um die Frage von HLGEM (und möglicherweise anderen) zu beantworten, was ich getan habe, um zu versuchen, sie zu beheben. Ich habe angeboten, Redmine einzurichten und allen die Quellcodeverwaltung vorzustellen. Ich sagte, ich würde verteilt (git oder mercurial) empfehlen, werde aber auch über zentralisierte reden und das Team entscheiden lassen. Die Antwort war, dass die Dinge in wenigen Wochen erledigt werden. Ich habe das noch nicht gesehen und weiß auch nicht, ob andere Teile des Unternehmens es verwenden.

Die kurze Version :

Lauf.

Die etwas längere Version :

Wenn der Manager nicht weiß, wie man ein Projekt durchführt, und wenn der Senior mitmacht, dann haben Sie so gut wie keine Chance, Dinge zu reparieren.

Um Softwareprojekte verwalten zu können, muss ein Manager etwas über Software verstehen. Wenn Manager dies nicht tun, müssen sie zuerst lernen. Wie hoch sind Ihre Chancen, dass Sie Ihr Management und Ihre Senioren davon überzeugen, dass sie alles falsch verstanden haben? Wie hoch sind die Chancen, dass Sie ihnen etwas beibringen?

Ich war einmal in einer ähnlichen Situation (nur dass es keinen Senior gab). Ich hörte nach einem schrecklichen Jahr auf und schaute nie zurück (außer angewidert).

... die Anforderungsspezifikation ständig ändern. Änderungen, die, wenn ein gutes Engineering durchgeführt und keine lückenhaften "Korrekturen" vorgenommen werden, eine Änderung des zugrunde liegenden Designs erfordern.

Klingt nach der realen Welt. Das passiert immer und überall. Ja, es ist zum Kotzen, aber mit einer Art agiler Haltung erträglich. Ein Maß für die Güte von Software ist außerdem die Formbarkeit. Nimm es als Herausforderung an.

Es wird viel Jargon verwendet, was grammatikalisch sinnvoll ist, aber auf andere Weise keinen Sinn ergibt.

Auch das klingt nicht so ungewohnt ;-)

Es gibt niemanden, der die Komplexität dessen versteht, was ich implementieren soll.

Nicht mal du? Wenn Sie das verstehen, gibt es eine Person im Spiegel, die das versteht. Daher ist Ihre Verantwortung für das Wohlergehen Ihres Unternehmens wahrscheinlich größer als Ihr formeller Titel vermuten lässt. Wenn Sie die Probleme verstehen und Ihr Vorgesetzter nicht, dann liegt es in Ihrer Verantwortung, die Dinge dem Management klar zu machen, damit dieses das Unternehmen richtig lenken kann. Es könnte sinnvoll sein , anzunehmen , dass Ihr nächster Manager sollte technisch kompetent sein (nicht unbedingt so kompetent wie Sie - während sie Manager, Sie sind der Experte - aber zumindest ein klein wenig kompetent), aber wenn sie offensichtlich nicht ist und du könntest ihnen helfen, warum nicht?

Eine einfache Fluchtlösung ist der Wechsel der Firma. Als weitere Option sollten Sie die Elemente von Joel Test implementieren. Die Punkte 1 bis 4 erfordern zwar eine stärkere Zusammenarbeit mit dem Management, aber Sie können sie einfach einrichten, ohne jemanden zu fragen.

Das heißt, niemand hier bei SE kann Ihre genaue Situation kennen. Es ist möglich, dass Sie in einem Unternehmen sind, das von inkompetenten Idioten überfüllt ist, und dass es für jeden zu viel sein kann, aus einem solchen Durcheinander etwas Gutes zu machen. Sie müssen die Situation selbst einschätzen.

Sie sagen in einem der Kommentare, dass dies Ihr erster Job ist. Manager sind nach meiner Erfahrung oft nirgendwo anders als in einem speziellen Software-Shop. Das ist ein Teil des Lebens, gewöhne dich einfach daran.

Sie weinen und jammern, weil es niemanden gibt, der die Eleganz Ihrer Lösungen zu schätzen weiß. Das eigentliche Problem dabei ist nicht, dass niemand die Eleganz Ihrer Lösungen zu schätzen weiß, sondern dass niemand Ihnen beibringt, dass Ihre Lösungen bei weitem nicht so gut sind, wie Sie denken. Praktisch alle neuen Programmierer überschätzen ihre tatsächlichen Fähigkeiten. Ohne Mentor gibt es niemanden, der Ihnen zu besseren Praktiken verhilft. Wenn niemand da ist, der Sie als Mentor unterstützt, treten Sie lokalen Benutzergruppen bei, beteiligen Sie sich aktiv und holen Sie sich jemanden, der Sie als Mentor unterstützt. Noch besser, das wird Ihnen helfen, irgendwann einen besseren Job zu finden.

Sie haben beim Joel-Test eine Null erzielt? Wenn Sie der einzige Codierer sind (und es klingt nach dem, was Sie geschrieben haben), warum verwenden Sie keine Quellcodeverwaltung? Was hindert dich daran? Wenn Sie nicht der einzige Programmierer sind, warum gibt es dann niemanden, der Codeprüfungen durchführen kann? Alle unsere Entwickler führen eine Codeüberprüfung durch. Dies ist keine Verwaltungsfunktion, insbesondere wenn die Manager nicht technisch sind.

Anforderungen ändern sich an so ziemlich allen Orten. Die geschäftlichen Anforderungen ändern sich ständig und Nicht-Programmierer können sich oft nicht vorstellen, was das Programm tun wird, bis sie etwas erreichen. Dann stellen sie fest, dass es nicht das ist, was sie brauchen. Das ist der Grund, warum Agile wirklich ins Leben gerufen wurde, weil die älteren Methoden diese Änderung nicht gut handhabten.

Richten Sie die Fehlerverfolgung ein, auch wenn das Management die Daten nicht selbst eingeben möchte. Seien Sie dafür verantwortlich, neue Fehler / Funktionen einzugeben, wenn Sie von jemandem darauf hingewiesen werden. Es ist wirklich hilfreich, dem Manager mitteilen zu können, wenn er eine Änderung wünscht, dass Ihnen 27 andere Dinge zugewiesen wurden. Hier ist die Liste. Welche soll ich in der Prioritätsliste nach unten verschieben, um diese neue Änderung zu berücksichtigen? Dies wird bei der Überprüfung hilfreich sein, da Sie die Anzahl der von Ihnen implementierten Fehlerbehebungen und Funktionen zählen können. Wenn es nicht von allen benutzt wird, können Sie es zumindest für Ihre eigene Arbeit tun. Wenn Sie keine Software installieren können, verwenden Sie eine Excel-Tabelle. Ergreifen Sie eine Initiative. Sobald Sie Ergebnisse zeigen können, werden andere mehr interessiert sein. Wenn Sie der Meinung sind, dass es zu viel Arbeit für eine Person gibt, hilft Ihnen der Bug-Tracker, dies zu beweisen.

Beweisen Sie keine polierten Demos! Demos sollten so aussehen, als wären sie mit einem Stift auf ein Stück Papier gekritzelt. Je ausgefeilter die Oberfläche aussieht, desto mehr denkt die nicht-technische Person, dass sie fertig ist.

Auch wenn niemand wissen würde, ob Sie nicht Best Practices und halbharten Code befolgen, werden Sie es wissen und schlampige, schlechte Gewohnheiten entwickeln. Das wird dir bei deinem nächsten Job nicht gut tun. Gehen Sie also so nah wie möglich am richtigen Weg. Stellen Sie sicher, dass Sie Tests schreiben (betrachten Sie dies einfach als Teil der Entwicklungszeit und geben Sie die Zeit dafür in die Schätzungen ein, die Sie verwalten, auch wenn Sie nicht ausdrücklich sagen, dass dies Teil der Schätzung ist), und verwenden Sie diese Tests, um sicherzustellen spätere Änderungen machen nichts anderes kaputt.

Sie müssen dies als eine unbezahlbare Gelegenheit betrachten, um zu wachsen und sich zu verbessern. Sie haben in der eigentlichen Programmierung mehr Freiheit als viele Menschen in dieser Phase Ihrer Karriere. Betrachten Sie dies als Gelegenheit, ein Portfolio erfolgreich umgesetzter Projekte zu erstellen. Wenn Sie sich auf die Suche nach dem nächsten Job begeben, werden Sie sich von anderen abheben, wenn Sie auf Errungenschaften wie z.

Sie haben hier auch eine großartige Gelegenheit zu lernen, wie Sie mit Erwartungen nach oben umgehen können. Dies ist eine Frage, die sich für den Rest Ihrer Karriere als nützlich erweisen wird. Sie haben nichts zu verlieren, wenn Sie versuchen, dies hier zu tun, die Dinge sind bereits nicht gut. Aber Sie können die politischen Fähigkeiten erlernen, die Ihnen später an besseren Orten helfen werden. Erfahren Sie, wie Sie eine Kosten-Nutzen-Analyse durchführen. Lernen Sie, die Geschäftsdomäne zu verstehen, damit Sie überzeugen können, wenn Sie mit ihnen sprechen. Lernen Sie, in Bezug auf die Vorteile für das Unternehmen und den Gewinn zu sprechen. Führen Sie Schätzungen für jede Ihnen zugewiesene Aufgabe durch, und führen Sie auch dann Aufzeichnungen darüber, was Sie geschätzt haben und was tatsächlich erforderlich war, um Ihre eigene Fähigkeit zur Schätzung der Arbeit zu verbessern. Sobald Sie nachweisen können, dass Ihre Schätzungen in der Vergangenheit genauer waren als die des Managements, Sie werden eher zuhören, wenn Sie ihnen mitteilen, dass die Schätzung zu niedrig ist. Sie müssen jedoch eine Erfolgsbilanz aufbauen, die sowohl genauere Schätzungen als auch vor allem die Fähigkeit beinhaltet, die Projekte umzusetzen und zum Funktionieren zu bringen. Auch dies ist eine gute Fähigkeit, wenn Sie in Ihrer Karriere aufsteigen.

Seien Sie vor allem nicht passiv und erwarten Sie eine Verbesserung von oben.

Wenn ich du wäre, würde ich versuchen, einen anderen Job zu finden. Warum? Ich denke, Sie wissen, dass Ihr Manager leider "nicht gut" ist. Sie sollten jedoch versuchen, einige Dinge mit Ihrem Manager zu klären.

Wenn du nicht gehen willst und / oder mit niemandem reden willst, musst du selbst etwas finden. Wenn niemand im Unternehmen von Ihrem Code weiß, wie soll Ihr Manager wissen, dass Sie die Anforderungen erfüllen? Ich sage es nur.

Sprechen Sie mit Ihrem Vorgesetzten und den Senioren darüber. Erläutern Sie Ihre Probleme und schlagen Sie Lösungen vor. Bereiten Sie das Gespräch ein wenig vor, damit Sie die allgemeine Botschaft kennen, die Sie vermitteln möchten.

Geben Sie nach dem Gespräch etwas Zeit . Sehen Sie, ob sich die Dinge ändern oder nicht. Wenn dies nicht der Fall ist, versuchen Sie, die Änderungen selbst umzusetzen, und zeigen Sie dem Manager und den Senioren die positiven Ergebnisse Ihrer Änderungen .

Wenn das Gespräch nicht hilft und Ihre Änderungen verworfen werden, müssen Sie selbst beurteilen, wie gerne Sie an diesem Ort arbeiten. Ja, die Arbeit mag schlecht sein, aber vielleicht ist die Bezahlung gut und Sie haben nur 5 Minuten Fahrtzeit? Wiegen die positiven Aspekte Ihres Jobs die negativen auf? Wenn sie es nicht tun, würde ich anfangen, nach einem neuen Job zu suchen.

Ihr Problem ist, dass Ticketing-Systeme und Versionskontrolle TECHNISCHE Fragen sind und Sie dies unabhängig von der Eingabe eines nicht-technischen Managers tun sollten. Dies sollte technisch als bewährte Methode angesehen werden. Wenn dies nicht eingerichtet ist, sollten Sie es selbst in die Hand nehmen, um dies zu erreichen.

Von einem nicht-technischen Manager können Sie nicht erwarten, dass er die Vorteile von Fehlerverfolgung, Quellcodeverwaltung und kontinuierlicher Integration versteht. Dies ist der Grund, warum sie nicht technisch sind, sie sollten das nicht wissen oder sich darum kümmern, sie sind Experten für Fach- und Geschäftskenntnisse. Das Einzige, was sie bieten sollten, sind Richtlinien und Anforderungen auf hohem Niveau.

Ich habe auch einen nicht-technischen Manager und konnte die Joel-Test-Punktzahl von 4 auf 8 erhöhen, nur weil ich sie gemacht und nicht um Erlaubnis gebeten habe.

Ihre Gruppe braucht einen starken technischen Leiter, und niemand ist auf den Tisch getreten.

Unter http://community.rallydev.com/ finden Sie eine Community-Edition, die hervorragende Arbeit im Bereich Agiles Projektmanagement und Fehlerverfolgung leistet. Dies allein erhöht Ihre Joel-Punktzahl und kostet Sie KEINEN Platz oder Zeit für die Einrichtung des Servers.

Wenn es sich um einen kleinen Laden handelt, in dem Sie und der andere "Senior" im Grunde die einzigen Personen sind, die die Kodierung vornehmen , liegt es möglicherweise in Ihrer Verantwortung, dem Manager mitzuteilen, was getan werden muss, um den "Joel-Test" zu bestehen.

Änderungen in den Anforderungen werden immer vorhanden sein, und Ihre Aufgabe ist es, sie zu berücksichtigen, was eines der Grundprinzipien der agilen Entwicklung ist :

Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel zum Wettbewerbsvorteil des Kunden.

Sich an veränderte Anforderungen anzupassen, bedeutet aber auch, anderen agilen Prinzipien zu folgen. Auf Managementebene bedeutet dies, dass der Manager dem Kunden transparent präsentieren muss, dass alle diese Änderungen mit Kosten verbunden sind: Entweder muss der Projektumfang geändert werden, um die Fristen einzuhalten, oder die Fristen müssen verschoben werden (letzteres wird nicht empfohlen).

Wenn dies eine Art Projekt ist, bei dem Ihr Manager alle Anforderungen erfüllt, sollten Sie so handeln, als ob er / sie Ihr agiler Kunde ist, und diesen das Gleiche erklären (Frist <-> Kompromisse eingehen) ).

Aber auf Entwicklerebene in einem kleinen Unternehmen liegt es in Ihrer Verantwortung, sicherzustellen, dass das Codierungsteil den agilen Empfehlungen entspricht.

Dies sind einige Schritte, die Sie unbedingt ausführen müssen, und wahrscheinlich müssen Sie sie selbst ausführen:

• Sie benötigen ein Versionskontrollsystem (es dauert einen Tag, um es für ein kleines Team einzurichten)
• Sie müssen Skripte erstellen, um sicherzustellen, dass Sie häufig Releases erstellen können.
• Sie müssen automatisierte Komponententests verwenden (dies ist eine Codierungsmethode, die Ihr gesamtes Design radikal diktiert, sodass es schwierig sein kann, sie in einem eng gekoppelten Projekt hinzuzufügen).
• Sie könnten auch ein kontinuierliches Integrationssystem einrichten, um automatisierte Builds und Tests sowie Funktions- und GUI-Tests (die etwas schwieriger zu schreiben sind) sicherzustellen.

Denken Sie daran, dass Sie ein SVN-Repository lokal auf Ihrem eigenen Computer haben können. Eine einfache TODO-Liste kann als Fehlerverfolgungssystem für Arme dienen (ein bisschen extrem, aber hey). Und es gibt keine Entschuldigung dafür, keine Build-Skripte zu haben.

Bevor Sie Aussagen zu Umfangs- / Fristenkompromissen treffen, müssen Sie auch Vorhersagen darüber treffen, wie viel Zeit eine bestimmte Funktion in Anspruch nehmen wird. Dies geschieht in der Regel an "idealen Tagen" in einer agilen Welt. Dies bedeutet, dass Sie Ihr Bestes tun sollten, um den relativen Aufwand der einzelnen Funktionen vorherzusagen, und dann Ihre tatsächliche Codierungsgeschwindigkeit verwenden, um festzustellen, wie gut Sie die "Kurve" vorhergesagt haben (und sie entsprechend skalieren sollten) ).

Ich denke, es fehlen Ebenen der Verantwortung in Ihrem Team. Es sollte einen Projektmanager, Systemanalytiker, Geschäftsanalytiker und Entwickler geben. Die Rolle des Projektmanagers ist unter anderem für die Definition und Durchsetzung der Kunden-Projekt-Kommunikationsstrategie verantwortlich.

Manager müssen weder Code noch Komplexität verstehen. Das Bedürfnis zu verstehen, Ressourcen, Kosten und Risiken.

Quellcodeversionen, Codequalität, Komplexität usw. liegen entweder in der Verantwortung des PM oder des Senior Developers.

Lösung ist:

1-Definieren Sie die Struktur des Projektteams und deren Verantwortlichkeiten

2-Informieren Sie den Manager über Softwarefehler, die auf ein schlechtes Management zurückzuführen sind. - Halten Sie sich von technischen Details fern. Sie können einige Beispiele finden, indem Sie googeln.

Vor allem, wenn es niemanden gibt, der auf Verbesserungen in meinem Code hinweist.

Könnten Sie nicht versuchen, Codeüberprüfungen einzurichten, damit sich Leute den Code ansehen? Gibt es Konventionen und Standards, die dem Code eine gewisse Struktur verleihen könnten? Dies setzt natürlich voraus, dass Sie nicht der einzige Entwickler sind.

Während Sie wahrscheinlich an einem weniger als großartigen Ort sind, sieht es am Ende so aus, als würde es funktionieren? Werden Projekte durchgeführt und die Dinge schreiten voran? Werden die Dinge erledigt? Der Duct Tape Programmer ist der Joel-Artikel, den Sie vielleicht lesen möchten.

Option 1 - Geben Sie an, dass das System bei allen Änderungen, die Sie an diesem Projekt vornehmen, zu dem Zeitpunkt, zu dem wir es bereitstellen, sehr langsam läuft, oder dass der Kunde dies nicht herausfinden kann. Ihre Manager interessieren sich nicht für Spaghetti-Code, aber sie interessieren sich für Kunden. Stellen Sie ihnen das Problem in Bezug auf das, was sie verstehen, und nicht in Bezug auf das Schreiben von Code.

Option 2 - geben Sie ihnen, was sie wollen. Wenn sie sich über etwas beschweren, sagen Sie: "Aber darum haben Sie gebeten."