Meetings sind eine Performance Bremse für Programmierer im Betriebsablauf
zum Leitartikel mit Quellen
Ich habe bei meinen 10 Jahren als Webdeveloper viele Firmen und deren Kulturen kennengelernt. So war ich beispielsweise mal für einen Berliner Gaming Publisher TYPO3 und Landingpage-Tool PHP Developer. Die hatten bei sich den „Meeting Monday“ erfunden und eingeführt. Dieser Tag bestand ausschließlich aus Meetings. Nachteil war hier, daß man jeden Montag den ganzen Tag niemanden erreichen konnte. Vorteil war, daß auch niemand versucht hat einen Webdeveloper zu erreichen, und man einen ganzen Tag Ruhe und Code hatte. Das Unternehmen hatte zu dem noch „Redlight und Greelight Meetings“. Ich kann gar nicht genau sagen, was es damit auf sich hatte. Es war ein Mehrpersonen Abnahmeprozess. Gut, die haben in Berlin gesessen und die Webdev Abteilung in Düsseldorf. Von daher hat es sich auf meinen Arbeitsalltag nur indirekt ausgewirkt. Das Unternehmen war am Ende natürlich zu langsam für den Markt und scheiterte auch daran und der hohen Uneffektivität bei extermen Personalkosten. Einen anderen Meetingtrend gab es bei einem Hamburger Gaming Publisher. Dort war zu meiner Zeit ein unglaublich langsamer und unfähiger CTO auch gleichzeitig Abteilungleiter für die Webentwickler. „Roland, ich bin hier um die richtigen Entscheidungen zu treffen und nicht um mich mit Sachverhalten auseinander zu setzen.“ Warum man in einer so hohen Position soviel Basisarbeit macht war mir nie klar. Das hatte glaube ich etwas mit Langeweile zu tun. Jeden Morgen gab es dort ein Standup Meeting. Die sollen ja eigentlich, aus der Scrum Welt kommend, reine Status Meetings sein, in denen kein Dialog stattfindet. Natürlich war auch hier der CTO nicht nur persönlich anwesend, sondern hatte auch ein Schlußwort von ca. 10 Minuten und mit jeden Teilnehmer, der fast 20 köpfigen Abteilung – alle Bereiche!! – zusätzlich einen Dialog im eigenen Büro. Schön vor dem eigenen großen JIRA Ticket System Fernseher. Da wurden natürlich auch nochmal alle Einstellungen vorgenommen. Während des morgendlichen Standups wohlgemerkt. Ergänzend gab es noch Scrum Meetings von ca. 15 Stunden in der Woche mit Schätzpoker, Kärtchen in allen Farben und Whiteboards mit einer tollen Auswahl an Stickern. Thema war hier auch eher Vision als Quellcode. Da die Pulszahl in dem Unternehmen allerdings Flatline war, wurde mit der Einrichtung von privaten PCs, lästern über Mitarbeiter und Abteilungen, Rauchen und gemeinschaflichen Kaffeholen die restliche Zeit des Tages verbrannt. Ich hatte dort zum Beispiel einen Kollegen, der in 10 Arbeitstagen 18 Codezeilen commitet hat. Das steht in meinen Augen in direktem Zusammenhang zu den Meetings und die spiegeln auch direkt die Unternehmenskultur wider. Egal was man tut es wird eh erstmal noch in zig Meetings diskutiert, alle Ideen und Innovationen mit dem Hinweis auf gemeinschaftliche Gesprächsrunden erstickt. Und da das Deployment dort auch einen Tag dauerte und nur einmal in der Woche durchgeführt wurde war es auch egal, ob man was entwickelt oder nicht. Der daraus resultierende Frust tötet jede Produktivität. Ganz in Gegensatz zu den beiden negativ Beispielen aus der Browsergaming Industrie steht mein heutiger Arbeitgeber aus dem Bereich des eCommerce. Da gibt es einfach keine Meetings. Die sind von oben her gesteuert als unnötiger Kostenfaktor abgeschafft worden. Absprachen finden unmittelbar direkt zwischen den beteiligten Mitarbeitern statt ohne das sich andere Mitarbeiter während dieser Gespräche langweilen müssen. U.a. deshalb ist diese Firma mit Abstand Marktführer.
Fazit zu Meetings in Firmen und ihren Einfluß auf die Produktivität von Webentwicklern:
Ein guter Programmierer kann zu jeder technischen Herausforderung auch nur sagen „Ja das geht und es ist kein Problem“. Oder er kann sagen, wie viele Stunden hierfür nötig sind. Dafür braucht er nicht in einem Marketing Meeting zu sitzen und sich mit der Frage zu beschäftigen, ob ein Registrierungsbutton rot oder grün sein soll und was beim Mouseover wohl passieren muß. Übrigens nur sehr selten können Marketing Fragen direkt beantwortet werden. Hier ist es meistens nötig, das Userverhalten in AB-Tests auszuwerten.
Ich persönlich halte nicht viel von Meetings. Ich werde dafür bezahlt Codezeilen zu schreiben. Ich muß mich hier sehr für konzentrieren und brauche jeden Tag viel Zeit dafür. Zusätzlich muß ich mich jeden Tag stark weiterbilden, meine Entwicklung Refaktorisieren und mich mit systemübergreifender Technik auseinander setzen. Beim Beispiel des Registrierungsbuttons, ich weiß das hierfür 8 Stunden mit 6 Leuten gemeeted wurde, habe ich keine Meinung zu der Farbe. Wahrscheinlich wirkt rot besser als Eyecatcher und grün wird lieber gedrückt. Mich interssiert mehr, daß der Button schnell geladen wird und der Registrierungsprozess sauber läuft. Ich habe bei der Arbeit kein Telefon und wenn, dann ist es aus. Ich gehe nicht in Blabla Meetings und bin da auch der ständigen Gefahr ausgesetzt einzuschlafen.
Das ist aber jetzt Office Anekdote. Es bleibt festzuhalten Absprachen sind ok, aber das unendliche verbrennen von zig Mannstunden ist Quatsch. Im Agentur-Kunden-Kontakt und auch bei internen Absprachen, sollten diese allerdings auch schriftlich fixiert werden. Als Programmierer schreibt man Codezeilen und programmiert. Das tut man nicht in Meetings. Das Meetings die Produktivität von Programmierern töten trifft voll zu.
