CodeIsland

Hier ein paar Ideen nach welchen Kriterien man Leute einstellen sollte:

Moderne IT-Firmen werden nicht mehr streng hierarchisch geführt und wenn auch nicht jede IT Firma so weit geht wie Valve (Valve Angestellten Handbuch) so sollte ein IT-ler Heute viel mehr Eigeninitiative zeigen als es früher noch der Fall war (und auch die Möglichkeiten bekommen eigeninitiativ zu agieren). Die folgende Liste von Kriterien ist natürlich subjektiv und unvollständig.

Smart:
Natürlich will jede Firma die besten Leute. Dieses Ziel ist aller ehrenhaft, aber erkennen kann man dies kaum in einem Bewerbungsgepräch. Aber ob die Person intelligent ist sollte zumindest ansatzweise erkenntlich sein.

Pragmatisch:
Natürlich möchte man eine perfekte Software, aber bevor man etwas perfekt ausliefern kann muss man erstmal ausliefern können. Eine gewisse Pragmatik ist in der IT-Branche unumlässlich. Braucht jemand sehr lange etwas sehr einfaches zu programmieren oder neigt die Person zum übertriebenen design, ist er vermutlich nicht der Richtige. Das gilt natürlich auch umgekehrt. Falls jemand alzu kurzsichtig agiert ist dies noch schädlicher. Derartiges kann man durch eine Coding Übung herrausfinden.

In die Firmenkultur passend:
Ein potenzieller Angestellter sollte gleiche oder ähnliche Werte, Normen, Ziele und Verfahren sein eigen nennen. Nur dann wird er sich integrieren, wird motiviert sein und wird Teil des Teams werden.
Möglichkeiten hier etwas in Erfahrung zu bringen sind zum Beispiel:
• Ein Bier trinken gehen oder gemeinsam Essen
• Interviews
• Gruppendiskussionen
• Die Firmenkultur ermitteln in der der Kandidat vorher tätig war
• Wie schnell reagiert er auf emails oder Anfragen ?

Passion/Eigenmotivation:
Es ist einfach etwas zu machen wenn man Geld dafür bekommt und jemand einem sagt was man machen soll (zumindest gibt es viele Menschen denen das einfach fällt), aber bringt sich die Person auch ein wenn er keine Anweisungen bekommt und wenn er nicht sofort immer für alles bezahlt wird ? Handelt er weil er es möchte oder weil er dafür bezahlt wird. Jeder Angestellte verdient eine gute Bezahlung, aber wenn Bezahlung das Hauptmotiv für das Handeln ist wird die Person sich niemals überdurchschnittlich einbringen. Deshalb macht es Sinn in Erfahrung zu bringen ob die Person sich auch persönlich interessiert (Teilnahme an Open source Projekten, Vorträgen, ....).
Wartet die Person auf Probleme oder schlägt die Person selber mögliche nächste Schritte vor ? Begeistert sich die Person eventuell für eigene Produkte oder für die Prozesse ?

Bezahlbar:
Natürlich muss die Person bezahlbar sein, d.h. einen enstprechenden Mehrwert erbringen.

Technisch versiert:
Je nach Kontext ist Vorwissen, d.h. technische Expertise natürlich wichtig. Wobei nach meiner Meinung dies nicht ansatzweise so wichtig wie die Soft-Skills ist.

Pflegeleicht:
Gute Leute sind oft schwierig. Dies ist in Ordnung, wenn die Mischung in der Firma stimmt und es sich in Grenzen hält. Ein Mitarbeiter der nicht Kommunikativ ist und ständig Probleme bereitet, ist sicherlich nicht die richtige Wahl.

Selektiv anstellen:
Massenanstellungen machen keinen Sinn. Vielmehr sollte man gut auswählen.

Bei mangelndem Erfolg der Person schulen oder Feuern:
Dies ist eigentlich keine Frage der Anstellung, aber selbst bei sorghaftester Auswahl wird es passieren, dass man falsche Mitarbeiter bekommt. Ist dies der Fall muss man schnellstmöglich Versuchen die Leute zu unterstützen. Sei es durch Schulungen oder durch neue Teamzusammensetzungen. Falls das alles nicht greift muss man die Nerven haben sich von der Person zu trennen.

Dies ist eine Liste von Fragen welche helfen könnten zu bewerten ob eine IT-Firma effektiv funktioniert. Aus der Beantwortung der Fragen ergeben sich häufig direkte Optimierungsansätze.

Manche Fragen sind nicht für jeder Form für eine IT Firma relevant. Viele Fragen überschneiden sich zudem. Man sollte die Fragen deshalb nur als Hilfsmittel nicht aber als harte Kriterien verwenden, wenn man eine Analyse durchführt. Die Fragen enthalten teilweise Anmerkungen wie Lösungen aussehen könnten und Beispiele die einem helfen können die Fragen zu beantworten.

1.Wie leicht kann eine Person hinzugefügt oder entfernt werden ?

Ansätze zur Beantwortung der Frage könnten sein einfach zu Verfolgen was ein neuer Mitarbeiter alles machen muss bis er wirklich tätig sein kann.

2.Hilft oder behindert die Organisationsstruktur das Finden von Metriken zur Messung der durchgeführten Arbeit ?

Wenn man die Prozesse optimieren möchte sind Metriken häufig unausweichlich. Ansonsten bleibt die Optimierung im Bereich von Gefühlen. In vielen Fällen erlaubt die Struktur der Firma aber überhaupt nicht das Anlegen von Metriken.

3.Hilft oder behindert die Organisationsstruktur die Arbeit des Einzelnen ?

Dies betrifft zum Beispiel:
• Einteilung von Teams
• Aufgabenverteilung

4.Um wieviel wird eine Person uneffektiver durch Hinzufügen von weiteren Personen zur Firma ?

Beispiele sind hier:
• erhöhtes Emailaufkommen
• Mehraufwände in der Entwicklung durchs mergen (Versionskontrollsystem)
• Kommunikation von Aufgaben

5.Wie überschaubar ist die Firmenstruktur ?

Ein Indiz wäre zum Beispiel die Frage "Wie funktioniert das Adressieren von Problemen"

6.Wie effektiv fließt die Arbeit durch das Unternehmen ?

• Zyklen (zum Beispiel Dauer von der Idee bis zur Livenachverfolgung oder von commit bis Abnahme)
• Passt die Struktur zu den Anforderungen

7.Sind die Verantwortlickeiten verteilt ?

Rollen könnten sein:
• Architektur / Architekt
• Operations / Operator
• Infrastruktur
• QA
• Kapzität/Performanz Planning
• Development / Entwickler
• financial lead = CFO
• technical lead =CTO
• manager = CEO

8.Sind die Teams empowered (Verteilung von Aufgaben auf die Teams um Bottlenecks zu vermeiden) ?

9.Gibt es eine greifbare Vision ?

Eine Vision sollten folgende Kriterien erfüllen:
• Lebendige Beschreibung einer optimalen Zukunft
• Werte erzeugend
• Messbar
• Inspirierend
• Sollte Elemente der Überzeugung verbinden
• Weitesgehend Resistent äussere Einflüsse

Mission Statements können dies unterstützen, diese sollten:
• vom aktuellen Stand ausgehen
• notwendige Aktionen enthalten
• eine Richtung zur Vision enthalten

10.Gibt es Milestones zur Überprüfung von Zwischenständen ?

Milestones geben einen die Möglichkeit den Forschritt mit dem Soll zu vergleichen
• Diese sollte specifisch sein
• Messbar
• Erreichbar aber fordernd
• Eine überschaubaren Zeitbereich berschreiben

11.Gibt es Feedback für die Mitarbeiter ?

Eine Weg wären 360-degree reviews oder Eins-zu-Eins-Gespräche

12.Sind die jobs mit entsprechend talentierten Personen besetzt ?
Im Idealfall sollte man die besten Leute anheuern welche man mit dem genehmigten Budget bekommen kann. Diese sollten ständig bewertet und gefördert werden. Zum staffing gehört aber nicht nur das Einstellen von Leuten, sondern auch das Fördern oder versetzen und im Zweifel auch das Feuern von Leuten.

13.Werden die Mitarbeiter Unterstützt ?

14.Wie ist das Verhältnis zwischen Arbeitszeit - Fortbildung - Krankheit - geblockt sein weil die Mitarbeiter auf Ressourcen warten ?

15.Gibt es Messungen und Ziele von Leistung ?

z.B.
• Anzahl Stunden reine Entwicklung
• Zeilen Code pro Tag
• Anzahl Bugs pro release
• Anzahl Downtime
• SLAs
• Codecoverage
• Kosten
• Einnahmen
• Time to Market
• Zyklen

16.Werden Erfolge gemeinsam gefeiert ?

Dies betrifft so banale Dinge wie bier trinken usw oder mit Beispiel vorangehen anstatt anderen die Fehler in die Schuhe zu schieben

17.Wie werden Prozessen gewartet ?

Prozesse durchlaufen häufig die Zustände:
• Inkomplet
• Einmalig manuell durchgeführt
• Managed (infrastruktur ist geschaffen)
• Defined (Doku ist erzeugt)
• Quantitatively Managed (gemessen)
• Optimierung

18.Wie werden Incidents gehändelt ?

Als Incident ist zu verstehen jede Art von Event welches die Quality der Dienstleistung oder des Produkts schädigt.

Es sollte einem "incident management life cycle" gefolgt werden das bedeutet das kataglosieren, schliessen, weiterberichten und tracken von incidents inklusive schneller Wiederherstellung des Serves und späterer root cause Lösung
Klasische Schritte sind:

• Incident detection und Aufnehmen
• Klassifizierung/Katalogisierung
• initialer support
• Untersuchung un finden einer schnelle Lösung
• Root cause Lösung / long term solution

Als Vorbereitung bedarf es häufig:
• Incident ownership, monitoring, tracking, und eine Abgesprochene Kommunikation
• Bestimmen welche Daten gesammelt werden müssen um zu helfen und welche gesichert werden müssen für eine System Wiederherstellung.
• Bestimmen wie lange information gesammelt werden sollten
• Bestimmen wie häufig kleine Fixes erlaubt sind bevor das Problem intensiver an der Wurzel angepackt werden muß
• Bestimmen wer das Vorgehen enscheidet
• Monitoring der Anwendung aus technischer Sicht und aus der Kundenperspektive

Ergänzend sollte vierteljährliches Incident review erfolgen:
• wurden doe root causes identifiziert ?
• welche subsysteme fallen vermehrt aus oder werden fehldiagnostiziert?
• wer baut ständig mist (Achtung Fingerpointing Gefahr)?
• Architektur feedback
• Incident process teamübergreifend besprechen

19.Wie werden changes gemanaged ?

Eine Änderung ist eine Aktion welche das System modifiziert (code, daten, Umgebung, config , ...)

Jede Änderung sollte geloggt werden. Das bedeutet:
• Exakter Zeitpunkt
• Welche Systeme sind betroffen
• Änderung selber
• Erwartetes Ergebnis
• Kontakt information der durchführenden Person

20.Werden bei der Architektur sinnvolle Grundprinzipien bedacht ?

Zum Beispiel die AKF’s Architectural Principles:
•N+1 Design (sicherstellen das man mindesten eine Instanz mehr hat als nötig um Ausfälle kompensieren zu können)
•Design for Rollback (Rückwärts kompatibel sein um im Zweifel auf einen bekanntlich funktionierenden Stand zurückgehen zu können. Dann bleibt einem mehr Zeit vorwärts fixen zu können)
• Design to Be Disabled
• Design to Be Monitored
• Design for Multiple Live Sites (Sicherheit gegen regionale Ausfälle)
• Bekannte und verifizierte Techniken verwenden
• Asynchronous Design (Wo möglich asynchron arbeiten)
• Stateless Systems
• Scale Out Not Up (horzontal Skalieren)
• Design for at Least Two Axes of Scale
• Buy When Non Core (Auf Kernkopetenzen konzentrieren)
• Use Commodity Hardware (billigste hardware die reicht)

21. Gibt es Joint Architecture Design ?

Feature sollten Abteilungsübergreifend (DevOps) entwickelt werden.
• Pflichtteilnehmer bestimmen: Software engineer, architect, operations engineer (database administrator, systems administrator, and/or network engineer).
• Optionale Teilnehmer bestimmen : Product manager, project manager, quality assurance engineer.
• Sitzungen mit den Beteiligten organisieren Getrennt wenn sinnvoll (database, server, cache, storage, etc).
• Architectur Prinzipien beachten
• Brainstorming zulassen
• Pro und Contra falls verschiedene Ansätze
• Ideen mitschreiben und rumschicken
• Konsens erzielen
• Dokumentieren und vom Architecture Review Board bestätigen lassen.

22.Gibt es ein Architecture Review Board ARB ?

Es sollte ein Architecture Board oder Architecture Review Board geben. Dieses board sollte aus Architekten und Anführern der verschiedenen Bereiche (funktional der business) bestehen. Genauer sollte das sein:
• ca 6 Leute
• Architekten
• Senior entwickler
• Ehrfahrene Leute aus der Infrastuktur
• Bereichsleiter

Die Teilnahme sollte freiwillig und zusätzlich zur normalen arbeit sein.

Möglicher Ablauf einer Sitzung:
1. Introduction
2. Sinn Ziel.
3. Architecture Presentation
4. Fragen
5. Diskussion
6. Abstimmen
7. Ergebnisbekanntgabe (Approval, Ablehnung, Bedingte Zustimmung, Ablehnung vn Teilkomponenten)

23.Gibt es Performanz und Stress Testing ?

Es sollten bottlenecks der Anwendung identifiziert, dokumentiert, und wenn sinnvoll
eliminiert werden. Ebenso sollte das Erreichen von SLAs (wenn gegeben) und Ausfallsicherheit verifiziert werden.

Dabei werden folgende Schritte beim Performanztest durchgeführt:
• Definition der erwarteten Kriterien
• Einrichten der Testumgebung
• Definieren der Tests
• Ausführen der Tests
• Analysieren der Daten.
• Report an Ingeneure (Entwicklungt, Ops, ...)
• Wiederholen

Beim Stresstest geht es mehr um die Ausfallsicherheit.
Die Schritte sind ähnlich:
• Definition der Fail-over-szenarien
• Auswahl der wichtigen Services und deren Monitoring
• Definition der benötigten Last
• Einrichten der Testumgebung
• Ausführen der Tests
• Analysieren der Daten.
• Report an Ingeneure (Entwicklungt, Ops, ...)
• Wiederholen

24.Werden Barrier Conditions and Rollbacks bedacht ?

Features welche beim Livegang massive Auswirkungen haben könnten sollten nur released werden wenn Bedingungen einghalten wurden und/oder Rollback-Mechanismen existieren.

Barriers könnten sein:
• Architecture Review Board.
• Code Reviews.
• Performance Testing
• Production Monitoring and Measurement.
Für eine Rollback oder "Design to Be Disabled" Strategie ist wichtig:

Wichtige Rollback Bedingungen sind:
• Wie viel zeit wird zwischen dem release und ersten ernsthaften Traffic für das Produkt vergehen?
• Handelt es sich um eine modifikation oder um ein neues Feature?
• Wie viele Versionen muss ich im Zweifel rückwärtskompatibel sein ?