Was tun, wenn der Chef wichtige Entscheidungen über Anforderungen und Gesamtdesign immer aufschiebt?


12

Wenn mein Chef ein neues Projekt startet, vermeidet er es immer, feste Entscheidungen zu treffen. Normalerweise sagt er: Okay, fang einfach an, etwas zu schreiben und sei so allgemein wie möglich. Wenn Sie fertig sind, schauen wir, wie wir weitermachen. Sein Argument ist im Grunde, dass Sie nie wissen, und "agile Entwicklung".

Um die Frage so allgemein wie möglich zu halten: Was machen Sie, wenn Ihr Chef keine Entscheidungen treffen möchte?

Einfach dranbleiben und Code schreiben, der einige Wochen später möglicherweise stark überarbeitet und teilweise umgeschrieben wird? Oder weiter diskutieren, bis der Chef wenigstens ein paar Entscheidungen trifft? Das ist mehr oder weniger meine derzeitige Strategie. Da es wie ein physikalisches Gesetz ist, muss irgendwann etwas geliefert werden. Entweder weil der Chef des Chefs Ergebnisse sehen will oder weil irgendwann etwas lächerlich wird.

Ich beobachte auch, dass mein Chef fast alles kritisiert. Sogar Vorschläge, die auf seinen eigenen beruhen ...


1
Beginnen Sie gemäß den SICP-Vorlesungen mit dem Schreiben von Code in LISP :)
Job

@Job - Ist LISP für diesen Workflow ausgelegt? ;)
Jimbo

Lisp (aber ich würde Clojure wirklich empfehlen) erlaubt es einem, drastische Änderungen am Design vorzunehmen. Bei richtiger Anwendung können Ebenen auf Ebenen der Abstraktion aufgebaut, umgedacht
Job

Antworten:


12

Prototypen bauen

Beginnen Sie einfach mit dem Zeichnen von Bildschirmen, die zunächst nichts tun (wahrscheinlich haben Sie genug, um das zu tun?).

Sie sollten in der Lage sein, es teilweise langsam funktionsfähig zu machen und schließlich einen Teil des fehlerhaften Codes umzugestalten, wenn klarer wird, was Sie tun möchten.

Es ist ein häufiges Problem, dass sie nicht wissen, was sie wollen, bis sie etwas sehen und erkennen, dass es nicht das ist, was sie wollen. Ich habe herausgefunden, dass wenn jemand möchte, dass Sie einfach anfangen 'ein Framework' oder etwas 'generisches' wie das, was er Ihnen sagt, zu erstellen, Sie nur in Schwierigkeiten geraten, wenn Sie es versuchen. Die Frameworks sind bereits geschrieben, das müssen Sie nicht tun.


Das klingt wirklich vertraut: "ein Rahmen". Wahrscheinlich sollte ich warten, bis alles in Stein gemeißelt ist, nachdem ich mindestens zwei oder drei Demos / Prototypen gezeigt habe.
Jimbo

4
+1 Niemand weiß was er will. Jeder weiß, was er nicht will. Kritik ist leicht zu bekommen und kann informativ sein.
JohnFx

4

Es gibt mehrere Probleme, die ich in Ihrer Nachricht festgestellt habe: 0-Es ist nicht Ihre Aufgabe, das Projekt zu verwalten, und es ist nicht Ihre Aufgabe, die Anforderungen der Endbenutzer zu erfassen. 1 - Der Chef kennt die genauen Anforderungen nicht. 2 - Der Chef spricht nicht mit den Endbenutzern über die Anforderungen. 3 - Der Chef spricht Begriffe aus, die er nicht wirklich versteht. mehrmals geschrieben und du freust dich nicht darüber

Was 1,2 und 3 anbelangt, kann man wenig dagegen tun, wenn man keine ältere Person ist. Es kann jedoch Folgendes durchgeführt werden:

A - Bitten Sie ihn, Ihnen den Projektplan mitzuteilen. Er kann einen haben oder wird einen bauen, der die Aufgaben und Fristen zeigt. Eines davon sollte die Analyse und das Sammeln von Anforderungen sein. Wenn nicht, schlagen Sie es vor.

B - Bereiten Sie einige Hinweise auf die Bedeutung der Anforderungen für den Erfolg eines Softwareprojekts vor

C - Bereiten Sie ihm eine Seite darüber vor, was Agile ist und was nicht.

D - Bereiten Sie ihm eine Liste typischer Eingaben für die Entwurfsphase vor und überzeugen Sie ihn vom jeweiligen Wert.

E - Schlagen Sie die Hinzufügung eines Geschäftsanalysten und / oder Datenmodellierers zum Team vor. Solche Rollen müssen beim Endbenutzer sitzen und liefern Ihnen die erforderlichen Informationen oder zumindest einen guten Teil davon.

F - Sehen Sie, wie andere Entwickler mit diesem Typen zusammengearbeitet haben.

In Bezug auf # 4 können Sie ihm vorschlagen, einen Prototyping-Ansatz oder einen Codegenerator zu verwenden, der es ihm, Ihnen und dem Benutzer ermöglicht, sich ein Bild über die funktionalen Aspekte der Anwendung zu machen. Die meisten Tools generieren keine perfekte GUI, aber Sie könnten zumindest die erforderliche Funktionalität erfassen.

Stellen Sie in jedem Fall sicher, dass Sie jede der Iterationen klar dokumentieren und ihm eine E-Mail senden, in der Sie angeben, welche Eingaben Sie erhalten haben, was Sie getan haben (im Detail) und was das Ergebnis ist. Stellen Sie sicher, dass Sie die Ergebnisse der richtigen Ursache zuschreiben, z. B. (fehlende Anforderungen usw.).

Leider akzeptieren manche Leute keine Ratschläge. Seien Sie also vorsichtig, wie Sie mit ihm kommunizieren.

Das läuft nicht gut!

Viel Glück.


Vielen Dank für Ihre detaillierte Antwort! Meine derzeitige Position liegt zwischen Junior und Senior, zumindest habe ich mich während des A so beschrieben: Er hat kein Interesse an irgendwelchen, empirischen Einsichten. B, C: Nicht jetzt ;-) Zumindest über das aktuelle Projekt weiß er viel über die alltäglichen Probleme. E ist eine schöne Idee. Heute habe ich eine kleine Demo geschrieben, wir haben heute viel darüber diskutiert. Obwohl ich erstaunt war, wie viele Punkte er unzufrieden war. Können Sie bitte erklären, was Sie mit D meinen?
Jimbo

Design erfordert Eingaben. Zum Beispiel Datenmodell (bei der Analyse erstellt), Geschäftsregeln, Sicherheitsanforderungen, Anwendungsfälle, Grundlegende Architektur (ist es ein Web, Windows Forms oder was). Die Eingaben unterscheiden sich nach dem Namen der Mehtodologie. Sie führen jedoch alle dazu, dass der Entwickler weiß, wie das Design aussehen sollte.
NoChance

4

Früher hatte ich so einen Chef - in der Tat würde ich scherzen, dass sein Motto war "Unentschlossenheit ist der Schlüssel zur Flexibilität".

Unabhängig von Ihrer Entwicklungsarbeit sind Sie wahrscheinlich besser in der Lage, das Problem des Kunden zu lösen als Ihr Chef. Wenn Sie nicht wissen, was das Problem ist, das der Kunde zu lösen versucht (was nicht das Gleiche ist wie eine Spezifikation), führt jemand die Erfassung seiner Anforderungen nicht ordnungsgemäß durch.

Skizzieren Sie einige Seitenlayouts oder erstellen Sie einen nicht- oder halbfunktionalen Prototyp. Aber mach etwas. Aus Ihrem Posting geht nicht hervor, ob Sie Voll-Client-Software oder Web-Apps erstellen, aber das Schöne an letzterer ist, dass Sie frühzeitig und häufig veröffentlichen können. Beginnen Sie mit den Knochen und arbeiten Sie es von dort aus. Ein falscher Start schadet nicht, wenn Dialoge fließen und Entscheidungen getroffen werden.

Wir haben ein Sprichwort rund um $ WORK (interne Web-Apps) für unsere Kunden: "Ich gebe Ihnen etwas, damit Sie mir sagen können, was Sie wollen." Seien Sie bereit, den ersten Entwurf wegzuwerfen, aber Sie werden überrascht sein, wie selten Sie dies tatsächlich tun müssen.


3

Weisen Sie ihn darauf hin, dass in den Agilen Büchern vorgeschlagen wird, Entscheidungen so lange wie möglich aufzuschieben, aber nicht mehr . Jede Entscheidung hat einen Punkt, an dem sie getroffen werden muss, und vielleicht sind Sie gerade dort.

Fragen Sie sich andererseits auch. Müssen Sie wirklich entscheiden, welche Persistenzschicht Sie für diese App verwenden möchten? Oder können Sie damit beginnen, es in eine CSV zu schreiben und es so weit abstrahieren, dass Sie diese Entscheidung später treffen können?


Die technischen Entscheidungen sind für mich mehr oder weniger klar: Programmiersprachen, Auswahl von Bibliotheken oder Persistenzschichten. Er hat eine starke Meinung dazu, und ehrlich gesagt ist es mir wirklich egal, ob diese Entscheidungen vernünftig sind. Es geht eher um Dinge wie: Wie wird der Bildschirm aussehen? Was kann der Benutzer und wie? Ich habe mir schon gedacht, dass es eine Menge meiner Arbeit ist, Ideen zu entwickeln. Es ist jedoch kaum möglich, abstrakte Ideen vorzuschlagen und ihn zu fragen, ob er mit einer Idee einverstanden ist.
Jimbo

3

Schreiben Sie Ihr eigenes Spezifikationsdokument und schreiben Sie eine Rezension, in der Sie es erklären, und er unterschreibt. Dann werden Sie Chef, und Ihr Chef wird sich mehr mit Fragen des zwischenmenschlichen Managements als mit technischen Fragen befassen.


2

Sprechen Sie mit Ihrem Chef und Ihren Kunden über Aufwärtsmanagement, finden Sie einige Lösungen heraus, wählen Sie die beste Lösung für Ihr Team aus, finden Sie Fehler in den anderen und führen Sie Ihren Manager dazu, die richtige Entscheidung zu treffen.

Und stellen Sie natürlich sicher, dass er denkt, es sei alles seine / ihre Idee. (Besonders wenn alles schief geht!)


Wenn Softwareingenieure Sozialingenieure werden .. :)
MattDavey

1
Im Ernst, die meisten Softwareprobleme sind lösbar, die Kommunikation mit anderen halbempfindlichen Säcken Wasser ist oft das problematische Problem ...
NWS

1

Sie müssen etwas entwerfen und implementieren. Da Ihr Chef keine Entscheidungen trifft, treffen Sie diese selbst. Nehmen Sie sich etwas Zeit, um Ihre Entscheidungen und Annahmen zu dokumentieren, bevor Sie sie umsetzen. Schicken Sie es an alle Personen, einschließlich Ihres Chefs. Hoffentlich enthält diese Liste mehr als nur Ihren Chef, da er dadurch leicht unter Druck gesetzt wird, einige Entscheidungen zu treffen, da er weiß, dass andere wissen, dass Sie bereit sind, fortzufahren. Sie werden überrascht sein, wie schnell Sie Feedback erhalten, wenn Sie Entscheidungen schriftlich treffen, insbesondere wenn Sie Entscheidungen treffen, mit denen andere nicht einverstanden sind. In der Zwischenzeit würde ich mit den von Ihnen getroffenen Entscheidungen fortfahren, bis etwas anderes gesagt wird.

Wenn Sie keine Zeit mehr damit verschwenden, das umzusetzen, was Ihr Chef nicht wollte, dann liegt es an ihm und nicht an Ihnen, da er wusste, welchen Weg Sie einschlagen würden.

Manche Menschen haben es auch schwer, anzufangen, aber wenn sie etwas Greifbares sehen, setzt ihr Verstand ein. Vielleicht ist Ihr Chef so, und wenn Sie ihm sagen, was Sie schriftlich vorhaben, wird er in den Sinn kommen.


0

Treffen Sie Ihre Entscheidungen selbst und beginnen Sie mit dem Programmieren. Natürlich hilft eine flexible Entwicklung (lesen Sie Robert C. Martins Agile Patterns, Principles and Practices, falls Sie dies noch nicht getan haben), aber die Flexibilität der Welt hilft nicht, wenn keine Entscheidungen getroffen werden. Möglicherweise müssen Sie nur entwickeln, was Sie denkenerforderlich ist, und ändern Sie es dann nach Bedarf. Oft wissen Kunden / Chefs nicht, was sie wollen, bis sie es sehen oder bis sie etwas sehen, was sie nicht wollen. Dies wird Sie wahrscheinlich aus dem Bereich der Entwickler herausführen, aber so ist das Leben. Ich stelle oft fest, dass ich und meine Kollegen tatsächlich geschäftliche Entscheidungen treffen. Manchmal werden diese Dinge nicht in Frage gestellt, und Entscheidungen, die ich getroffen habe, steuern das Geschäft, nur weil sonst niemand die Entscheidung treffen würde. Stellen Sie sicher, dass Sie ALLE Annahmen und Entscheidungen auflisten (keine Ausnahmen) und diese Ihrem Chef vorlegen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.