How to talk to programmers

Aus barcamp.at
Wechseln zu: Navigation, Suche

MacLemon stellte dieses Thema spontan in den Raum, und bald schon kam es zu einer lebhaft interessanten Diskussion mit vielen Beispielen.

Zuerst differenzierte MacLemon in Programmierer / Software-Entwickler.

  • Programmierer (aka "CodeMonkey"): Reine Implementierung eines Auftrags ohne großes Nach/Rück-fragen. Bekommt Ticket XY, arbeitet das ab. Fertig.
  • Softwareentwickler: Sieht das größere Bild, entwickelt auch Produkt/Geschäfts/…-Ideen, hat tendenziell mehr Interesse am großen Ganzen.

Aus der Diskussion kristallisierte sich folgendes heraus:

  • Respekt & Empathie! Nicht vergessen: Alle Teilhabenden sind Menschen! Zumindest respektvoller Umgang miteinander! Besser und wünschenswerter: Interesse aneinander! Was bedeutet für die jeweilige andere Seite "schöne Umsatzung", "100%", "Perfektion", Freude/Ziele, etc. Kann sehr hilfreich sein!
  • Interdisziplinäres Gespräch zu Projektbeginn, wo alle angeben was Ihnen wichtig ist. Denn wenn der Programmierer bei der Umsetzung ist, und ihm etwas an der Spezifizierung nicht klar ist, will er nicht immer Zeit verwenden rückzufragen, und auf Beantwortung zu warten. Wenn jedoch die andere Seite und deren Motivationen aufgrund der zuvor erfolgten Vorstellung klar ist, ist besser abzuschätzen, wo es wirklich wert ist, doch noch mal rückzufragen, und hat dann auch mehr Bereitschaft das tatsächlich zu tun.
  • Der Geschäftsleitung klar machen dass Gespräch zwischen Designer und Programmierer die Zeit wert ist um zu klarifizieren bevor es zu Falschentwicklungen kommt.
  • Teilweise auch scheinbar einfache Begriffe trotzdem besprechen/definieren um Missverständnisse zu vermeiden.
    • Super Anekdote dazu: Designer-Vorgabe "Ein 3D-Karussell mit Bildern die alle den gleichen Abstand zueinander haben. Der Designer meinte mit gleichem (Pixel)Abstand wirklich den gleichen Abstand (der 2D-Abbildung). Der Programmierer verstand "den gleichen Winkelabstand", somit nach Regeln der Perspektive tiefer im Raum befindliches näher beisammen, vorne weiter auseinander, wie beispielsweise die Bäume in einer Allee. Der Programmierer setzte das mit einer existierenden 3D-Engine/Framework um. Als dann das Missverständnis klar wurde, war eine Programmier-Adaptierung kaum mehr möglich (nur mehr sehr umständlich über perspektivische Verzerrungen, quasi ein Feature um wiederum einen Bug zu entkräften), quasi ein Zurück an den Start. Wenn die "gleicher Abstand zueinander" in der frühen Phase klarer definiert/kommuniziert geworden wäre, wäre dies erspart geblieben.
  • Immer wieder rückfragen!
  • Programmierer anfragen ob man Zugang zu Testversionen/Versionskontrollsystem haben kann. Programmierer sind viel eher bereit Änderungen WÄHREND des Projekts als gegen/zum ENDE des Projekts entgegenzunehmen.