Wie findet man _nicht_ die richtigen Kollegen?

In der Biologie findet Evolution durch Mutation bzw. Mischung der Gene statt. Im Zuge dessen sollten sich Firmen - die an einer Weiterentwicklung interessiert sind -  gezielt verändern. Zum Beispiel durch die gelegentliche Einstellung von Kandidaten, die nicht ins Schema passen, also die normalerweise durchs Raster fallen würden. Etwa durch
- Bildungsgrad
- Alter
- Herkunftsland / kultureller Hintergrund
- Sprache
- Berufserfahrung
- Geschlecht (nur der Vollständigkeit halber erwähnt)
- Lebenslauf
- Kleidung
…
anders sind.
Also: 99 Linientreue einstellen - und danach eine Einstellung "mit Gendefekt".

Your package structure is broken

Each package structure is sort of broken:

Layered package structure

controller
  file1
  file2
  file3
  …
repos
  file1
  file2
  file3
  …
services
  file1
  file2
  file3
  …

Good: Easy to understand
Bad: Things that belong together are spread all over the project. No true modules.

Module package structure

module1
  FileController
  FileRepo
  FileService
module2
  FileController
  FileRepo
  FileService

Good: True modules
Bad: Layer-Info hard to distinguish, not so easy to understand

Mixed mode

module1
  Controller
    File1
    …
  Repo
    File1
    …
  Service
    File1
    …
module2
  Controller
    File1
    …
  Repo
    File1
    …
  Service
    File1
    …

Good: True modules, Layers easy to spot.
Bad: Mixing of two concepts: Folders for modules, folders for layers. Developers have to travers large dir-structures.

———————
Main problem: You need folder structures to group modules, build modules, show layers. (one concept for different purposes)
Possible solution: Folders for group of modules. (may be nested) Folders with with Manifesto.xml - sorry Manifesto.yml to show module structure to IDE. And „markers“ for layers. (Which are maybe inspected automatically by the IDE.)

What is your favourite? Do you have suggestions?

Speed is king!

Natürlich ist eine schnelle Website eine gute Sache. Nutzer bekommen ihre Inhalte schneller, Google bewertet höher und der Server läuft effizienter.

Nicht von ungefähr liegt also Software-Entwicklern dieses Thema am Herzen. Ich habe aber viele Entwickler kennengelernt, die das Ziel mit einer ungewöhnlichen Inbrunst verfolgen. (Ich gehöre auch ab und zu dazu …)

Der Grund dafür mag in der einfachen Messbarkeit liegen. In der Softwareentwicklung gibt es sonst keine leichter verständlichere, einfach messbarere und für den Nutzer nützlichere Messgröße. Aussenstehenden lässt sich eine gesteigerte Performance besser verdeutlichen als z.B. eine höhere Testabdeckung. 

Fazit: Softwareentwickler sind auch nur Menschen. Positives Feedback - und sei es in Form von ein paar Zahlen - ist wichtig.

Auswege aus dem Pitch Dilemma

In der Internet/Marketing Branche ist es üblich, neue Aufträge durch sogen. Pitches auszuschreiben. Gewöhnlich werden hier nach unbekannten Methoden eine Reihe von Agenturen ausgewählt. Ich vermute hier, dass Faktoren wie 

• persönliche Bekanntschaft
• Position in Agenturrankings
• Größe und Bekanntsgrad der Agentur
• Referenz zum Briefing passend
• Schmiergeldeinsatz (?)

eine Rolle spielen. Nicht selten werden 5 oder gar mehr Agenturen angeschrieben. Das Briefing schwankt stark in seiner Qualität, oft werden aber bereits ausgearbeitete Lösungen erwartet.

Nun erfolgt eine teuflische Dynamik bei den teilnehmenden Agenturen: Je größer das zu erwartende Budget ist, desto größer der Pitchaufwand. Nicht selten wird bereits 20% des “Pottes” verbraucht. Dies sind nicht selten 3 stellige Tagesaufwände. Oft werden diese unter extremem Zeit- und Leistungsdruck in Nacht- und Wochenendschichten erbracht. Wenn nicht genug eigene Mitarbeieter verfügbar sind, werden auch Freelancer eingesetzt.

Gezahlt wird vom Auftraggeber oft nichts oder nur ein viel zu kleiner Betrag.

Wenn ein Pitch verloren wird, muss die Agentur diese Aufwände abschreiben. Dies bedeutet eigentlich, dass die Aufwände über andere Projekte querfinanziert werden müssen. Diese werden dadurch teurer. Oder aber die Agentur macht weniger Gewinn oder rutscht gar dadurch in den roten Bereich und muss um die Existenz fürchten. In jedem Fall führt der Verlust eines Pitches zu einem Frustrationserlebnis bei den Mitarbeitern.

Oder aber die Agentur gewinnt: aber auch in diesem Fall wird der Aufwand auf das Projekt abgeschrieben oder die Agentur leidet auf andere Weise.

Resultat eines Pitches sind also teurere Projekte bzw Destabilisierung einer Branche.

Beides sollte nicht im Sinne der Auftraggeber sein.

Natürlich möchte ein Auftraggeber auf der anderen Seite die passendste und beste Agentur für die Aufgabe wählen.

Folgende Lösungen kommen mir in den Sinn:

Auswahl über Refenzen: Agenturen sollten Wert auf gut präsentierte und ausführlich beschriebene Referenzen legen. Evtl könnten dort auch Infos über Budgets oder Umsetzungszeiten gegeben werden. Codemetriken könnten die Qualität beschreiben.

Probearbeit: eine definierte Aufgabe muss von einem repräsentativen Team vor Ort gelöst werden. Das Team muss auch an der späteren Umsetzung beteiligt sein. Die Probearbeit ist entweder hinreichend kurz - oder sie wird bezahlt. (Z.b. Mit ca 500 Euro Tagessatz)

Pitchaufwände entlohnen: komplette pitchaufwände werden entlohnt bis zu einer sinnvollen Obergrenze.

Pitchzeit stark begrenzen: Auftraggeber kündigt Pitchbeginn und Abgabe rechtzeitig an, nennt aber nicht den Inhalt. Beginn und Abgabe liegen z.b. 3 Tage auseinander. (Nicht durch Wochende trennen, Kollegen! :)

Und folgende Rahmenbedingungen sollten fairerweise angegeben werden:

• Zur Verfügung stehendes Budget (warum verschweigen? Vielleicht macht es ja eine Agentur billiger!)
• Entschiedungskriterien (billigstes Angebot, beste Idee, wirtschaftlichstes Pflegekonzept…)
• Nennung eines Ansprechpartners der für Rückfragen bereitsteht. Die Antworten sollten (evtl zeitverzögert) allen Teilnehmenrn auch zugänglich sein.
• Formblätter, um Angebote abzugeben, evtl mit Aufteilung nach Aufgabengruppen und Gewerken.

Um die Pflegefalle (= Angebot sehr günstig, nachträgliche Änderungen extrem teuer) zu vermeiden, sollten Aufwände aufgeschlüsselt abgegeben werden müssen und fachkundig beurteilt werden.

Nun wünsche ich … tja, das Ende der herkömmlichen Pitchkultur herbei. 

Start

Nach beinahe 20 Jahren Interneterfahrung, drängt es mich, einige Gedanken und Erfahrungen dazu festzuhalten und zu teilen.

Und natürlich fange ich mit meinem ersten Kontakt zum Internet an:

Ich begann 1991 meine Ausbildung im Rechenzentrum der RWTH Aachen. Uns wurden klobige MS-Dos Maschinen vorgesetzt - eine Maus suchte man vergeblich.

Eines der installierten Programme ermöglichte den Versand von Textnachrichten zwischen unseren Rechnern. Unsere Adressen folgten einem Namensschema, bei dem Name und Zugehörigkeit mit einem Klammeraffen getrennt wurden. Man eröffnete uns, dass man diese Nachrichten weltweit verschicken könnte.

Später auf einer Einführungsveranstaltung wurde ein Forschungsprojekt vorgestellt: ein Mailprogramm mit grafischer Bedienung (Unix, X-Windows) ermöglichte auch das Versenden von gesprochenen Nachrichten. Andächtiges Gemurmel. Bis einer von hinten rief: “Hey, die Jungs haben das Telefon erfunden!”