Gibt es einen Zusammenhang zwischen Besprechungszeit und Einsparung von Entwicklungszeit?

Ich arbeite an einem Projekt und wir haben regelmäßige (normalerweise wöchentliche) informelle Treffen, bei denen wir den Status des Projekts und die grafische Benutzeroberfläche besprechen.

Ich bin der einzige Entwickler dort, die anderen 4-5 Leute haben einen Nicht-IT-Hintergrund.

Dieses Treffen dauerte viel länger als gewöhnlich, aber irgendwann fragte einer meiner Kollegen nach einigen Feldern im Programm und wie sie gefüllt werden. Ich antwortete und in der Diskussion bemerkte ich, dass ich den Prozess völlig falsch verstanden hatte.

Aber da wir darüber gesprochen und den Fehler vorher gefunden haben, kann ich ihn ziemlich schnell ändern.

Während ich darüber nachdachte, habe ich mich gefragt, ob es einen Faktor zwischen der Besprechungszeit gibt, wenn es darum geht, Entwicklungszeit zu sparen.

Beispielsweise kann 1 Minute Besprechungszeit X Minuten Entwicklungszeit einsparen.

In diesem Fall ist es hilfreich zu definieren, wie oft und wie lange unsere Besprechungen dauern sollen.

(Nur um zu verdeutlichen: Ich möchte keine besseren Besprechungen abhalten, auch wenn es ungefähr ist, die Länge der Besprechungen ungefähr bestimmen zu können. Ich bin hauptsächlich interessiert, WENN es einen Zusammenhang zwischen Besprechungszeit und Entwicklungszeit gibt! Mein Grund zu fragen: Neugier! )

"Solange sie sein müssen und nicht mehr."

Hierbei ist zu beachten, dass die Besprechungszeit zur Einsparung von Entwicklungszeit in keiner Weise linear ist. Für Ihr Team, für Ihr Unternehmen und für dieses Thema kann eine Stunde Besprechung 2 Stunden Entwicklungsarbeit einsparen. Wenn Sie 10 Stunden Besprechungen haben, kann eine weitere Stunde Besprechungen 0 Entwicklungsarbeit sparen. Zum Teufel, es kann Ihnen aufgrund von Unterbrechungen oder Auswirkungen auf die Moral -2 Stunden Entwicklungsarbeit ersparen.

Am Ende geht es bei Besprechungen darum, dass die Kommunikation und Zusammenarbeit Ihnen dabei hilft, Dinge zu erledigen. Wenn Meetings Ihnen nicht dabei helfen, Dinge zu erledigen, sollten sie getötet werden.

Nicht genau.

Das Verständnis des Kunden / Stakeholder kann Entwicklungszeit sparen. Und Gespräche müssen lang genug sein, um das Verständnis zu erleichtern. Wenn Sie jedoch eine Funktion diskutieren, von der Sie bereits annehmen, dass Sie sie verstehen, wird dies Ihr Verständnis nicht unbedingt verbessern.

Wenn niemand im Raum den Verdacht auf Missverständnisse oder falsche Annahmen hat, verlassen Sie den Raum. Eine künstliche Verlängerung einer "Diskussion" in der Hoffnung, dass die Scherzeit und der Druck einen Konflikt verdrängen und Harmonie schaffen, ist hoffnungslos und demoralisierend.

Und denken Sie daran, dass Kommunikation eine Kombination aus Können und Glück ist. Diskussion bedeutet nicht unbedingt Kommunikation (gegenseitiges Verständnis). Je länger Sie vor Ort arbeiten und je länger Sie zusammenarbeiten, desto besser können Sie schlechte Annahmen aufdecken.

In der Zwischenzeit kann "Agility" hilfreich sein.

Halten Sie Besprechungen "kurz" und implementieren Sie so bald wie möglich nach jeder Besprechung grobe Benutzeroberflächen oder Modelle - lange bevor Sie überhaupt den Verdacht haben, ein umfassendes Verständnis zu haben. Ihre UI's / Mocks dienen als Material zur Klärung von Missverständnissen. Die Zeit zwischen den Sitzungen wird allen helfen, das Gesagte zu dekomprimieren und zu reflektieren. Und wenn Sie Ihre Show-and-Tell-Materialien in Code implementieren , haben Sie auch tatsächlich mit der Entwicklung begonnen. (Und Ihre Kunden / Kollegen werden begeistert sein, dies zu hören!)

Und das schlimmste Szenario, wenn Sie einen kleinen Teil des sichtbaren Codes implementiert haben : Sie befinden sich völlig außerhalb der Basis und werfen ihn weg. Aber, wenn Sie nur eine kleine Menge an Zeit gewidmet haben, zahlt sich die Investition groß bei der Klärung grober Missverständnis.

Und denken Sie daran, das Unternehmen kümmert sich nicht um die Entwicklungszeit . es kümmert sich nur um die Zeit der Person . (Um die Gesamtkosten zu berechnen , wohlgemerkt.) Sie müssen also nach dem Gleichgewicht suchen, in dem die Zeit der Person minimiert wird. keine Zeit damit verbracht, Code zu schreiben.

Ich glaube nicht, dass es dort irgendeine Korrelation gibt, die allgemein angewendet werden könnte. Es hängt wirklich von der Besprechung und den Dingen ab, die Sie dort tun und die sich auf die Entwicklung beziehen.

In der von Ihnen beschriebenen Situation sind Sie in wenigen Minuten von einer schlechten oder schlecht verstandenen Anforderung zu einer besseren übergegangen. Wir wissen, dass gute Anforderungen einen direkten Einfluss auf die Entwicklungszeit haben.

Was aber, wenn Ihr Meeting so etwas wie ein Unternehmensstatus-Meeting war? Sie geben gute Informationen weiter, damit Sie wissen, wie es dem Unternehmen geht, sich anderer Dinge bewusst sind usw. Dies hat jedoch größtenteils keine Auswirkungen auf die Entwicklungszeit Ihres Projekts. Die ganze Zeit ist "verschwendet", wenn man sie aus entwicklungspolitischer Sicht betrachtet.

Sobald Sie zu genügend Besprechungen gehen mussten, werden Sie feststellen, dass einige wirklich produktiv sind (z. B. nehmen Sie ein kleines Entwicklerteam und eine Reihe guter Anforderungen und beginnen Sie mit dem Whiteboarding einer Architektur. Sie können viel erledigen, wenn Sie konzentriert bleiben .). Sie finden auch einige, die überhaupt nicht produktiv sind oder sogar eine negative Produktivität aufweisen (einmal hatte ein Kunde eine 15-minütige Debatte zwischen einigen von ihnen darüber, ob auf einer Anmeldeseite "Anmelden" oder "Anmelden" angezeigt werden sollte Ende davon wusste niemand und es musste bis später eingereicht werden).

TL / DR: Abhängig von der Besprechung, den Personen und den Zielen der Besprechung.