Was macht ein Start Up erfolgreich?

277 Aufrufe

Veröffentlicht am

Diese Präsentation beschreibt, welche Faktoren für ein IT Start Up wichtig sind und zeigt Beispiele.

Veröffentlicht in: Kleinunternehmen & Unternehmertum
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
277
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Was macht ein Start Up erfolgreich?

  1. 1. 1 Agenda ● Was macht ein Start Up erfolgreich? ● Das Team ● Business und IT Alignment ● Technologie ● Entwicklungsprozesse ● Deployment ● Sicherheit ● Monitoring ● Dokumentation
  2. 2. 2
  3. 3. 3 Start Up Erfolg ● Pro ● Schnelles lernen ● Günstiges lernen ● Gutes Team ● Exzellente Ausführung ● Contra ● Zu früh skalieren ● Schlechte Anforderungen ● „Verzetteln“ → Fokussierung auf unwichtige Dinge Quelle: Startup Genome Report 01 https://www.startupcompass.co/
  4. 4. 4 Start Up Stages Discovery Validation Efficiency Scale Profit Maximation Renewal
  5. 5. 5
  6. 6. 6 Zyklisches Controlling ● Alles messen ● Smart/e Ziele ● spezifisch ● messbar ● akzeptiert ● realistisch ● terminiert ● Regelmäßig messen ● fester Tag im Monat an dem Ziele kontrolliert werden, bei neuen Zielen wöchentlich bis täglich
  7. 7. 7 Kommunikation ● Eine auffällige Gemeinsamkeit erfolgreicher Unternehmen ist effiziente und effektive Kommunikation ● Wann wird effektiv kommuniziert? ● Entscheidungen werden im Zeitplan getroffen und werden von allen respektiert und akzeptiert ● Es herrscht ein Vertrauensverhältnis zwischen allen Mitarbeitern ● Es gibt nur Meetings, wenn Entscheidungen zu treffen sind
  8. 8. 8 Das Team
  9. 9. 9
  10. 10. 10 Personal ● Personal ● Teuerste Komponente im Unternehmen ● Schwer zu beschaffen ● IQ guter Indikator, ob passend für Stelle ● Fähigkeiten messen ● Effizientes Arbeiten ● Programmierer Produktivität schwankt um den Faktor 10 ● Persönliche Ziele ● Klare Anforderungen http://www.johndcook.com/blog/2011/01/10/some-programmers-really-are-10x-more-productive/
  11. 11. 12
  12. 12. 13 Identität für Team anbieten
  13. 13. 14 Recruitment ● Am effektivsten über persönliches Netzwerk ● Frühzeitig Personen an sich binden ● Personen, die für Geld kommen, werden auch wieder für Geld gehen "In looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if they don't have the first, the other two will kill you." Warren Buffet CEO, Berkshire Hathaway
  14. 14. 15 Business und IT Alignment
  15. 15. 16 Prozesse ● Die Kernprozesse sollten aufgeschrieben sein z.B. Porter Wertkette ● Wann ist etwas ein Kernprozess? – Er trägt mehr als 10% zu den Unternehmenseinnahmen bei – Er trägt mehr als 10% zu den Unternehmensausgaben bei ● Prozesse erst nach Etablierung dokumentieren ● IT Systeme zur Unterstützung dieser Prozesse sollten zugeordnet sein
  16. 16. 17 Beispielkernprozesse Entwicklung Betrieb Support Qualitäts- sicherung Entwicklung und BetriebEntwicklung und Betrieb Vertrieb und Marketing / B2B Lead Generierung Vertrags- abschluss Bereit- stellung Lead- qualifizierung und -pflege ... bis zu 70% der IT Kosten bis zu 50% der Gesamtkosten bei SaaS
  17. 17. 18 IT kann Prozesse beeinflussen ● Neue IT Systeme bilden meist nicht die Prozesse so ab, wie sie vorher im Unternehmen waren ● Sinnvoll die Best Practises von Software zu übernehmen anstatt für viel Geld anpassen zu lassen ● Auswahl der Lösungen die möglichst gut die momentanen Prozesse beschreiben
  18. 18. 19 Wann brauche ich ein IT System ● Viele Prozesse werden implizit durch IT unterstützt ● Standardprogramme: Email, Office, Tabellenkalkulation, Kalender ● IT Systeme sind primär zum Sammeln von Daten, Auswerten und Präsentation an mehrere Personen ● IT Systeme werden oft gebraucht, wenn ein Prozess mit mehreren Personen statt findet und die Daten an dem Prozess anstatt in den Mailboxen der beteiligten Personen landen sollen
  19. 19. 20 Start Up Kosten von Entwicklung dominiert ● Sinnvolle Strategie schnell zu entwickeln und auf Funktionen und möglicherweise Qualität zu verzichten um Geschäftsmodell zu validieren ● Startups need 2-3 times longer to validate their market than most founders expect. (Startup Genome Report) ● Performanzprobleme sind Luxusprobleme ● Wenn erfolgreiches Businessmodell, dann ist Geld vorhanden um gute IT zu bauen
  20. 20. 21 Technologie
  21. 21. 22 Welche Technologie wählen? ● Technologie egal, die Probleme liegen woanders: ● Die festgestellten Haupterfolgsfaktoren sind: – Einbindung der Endbenutzer – Unterstützung durch das obere Management – Klare Anforderungen ● Die Hauptpunkte, die zum Scheitern der Projekte führen sind: – fehlende Zuarbeit durch Benutzer – unvollständige/unklare Anforderungen – häufige Anforderungsänderungen Quelle http://de.wikipedia.org/wiki/Chaos-Studie CHAOS-Studie der Standish Group
  22. 22. 23 https://www.plat-forms.org/results-2011 Produktivität von Webplatformen
  23. 23. 24 Produktivität abhängig von ● Daumenregel ● Person (50%) ● Anforderungen (30%) ● Technologie (20%)
  24. 24. 27 Performance Tests ● ab - http://httpd.apache.org/docs/2.2/programs/ab.h tml ● JMeter - http://jmeter.apache.org/
  25. 25. 28 Entwicklungsprozesse
  26. 26. 29 Teamgröße ● Optimales Entwicklungsteam zwischen 4-9 Leute ● Experten sollten sich viel mit Planung, Dokumentation und den Kollegen helfen beschäftigen, nicht alles selbst coden ● Um eine Anforderung zu erfüllen sollten immer zuerst bereits bestehende Lösungen evaluiert werden ● 20% der Personen machen ausschließlich Managementarbeit
  27. 27. 30 Vorgehensmodelle ● Vorgehensmodelle sollten nur so benannt werden, wenn der Verantwortliche mindestens 200 Seiten zu dem Modell gelesen hat ● Wasserfall – V Modell XT – PRINCE2 (project management) ● Iterative (agile) – Rational Unified Process – Xtreme Programming – Scrum (momentan trendy) – Kanban (noch cooler als Scrum)
  28. 28. 31 http://www.joelonsoftware.com/articles/fog0000000043.html Joels Rules for productivity ● Do you use source control? ● Can you make a build in one step? ● Do you make daily builds? ● Do you have a bug database? ● Do you fix bugs before writing new code? ● Do you have an up-to-date schedule? ● Do you have a spec? ● Do programmers have quiet working conditions? ● Do you use the best tools money can buy? ● Do you have testers? ● Do new candidates write code during their interview? ● Do you do hallway usability testing?
  29. 29. 32 Application Lifecycle Management SCM e.g. git, svn Issue Management e.g. JIRA, Redmine Continious Integration Server e.g. Hudson, Bamboo Server Runtime e.g. Tomcat, Apache
  30. 30. 33 Ticketing System ● Arbeitsanweisungen werden nur über Tickets kommuniziert ● Messbarer Fortschritt ● Klarer Lebenszyklus (Erstellt, In Arbeit, Fertig) ● Quellcode und Deployment integrierbar
  31. 31. 34 Continious Integration ● Eine Funktion muss innerhalb von 8 Stunden so implementiert sein, dass das System kompilierbar ist ● System wird täglich kompiliert ● System wird täglich getestet ● System ist ständig auslieferbar ● Automatisiertes Kompilieren, Testen und optionale Auslieferung
  32. 32. 35 Integration und Traceability ● SCM, Ticketing und CI sollten integriert sein ● Typische Fragen ● Warum wurde folgender Code geschrieben? ● Welche Features sind in dem momentanen Build, die nicht in dem vorherigen waren? ● Gibt es für alle Tickets Test Cases ● Wer hat wie viele Zeilen Code geschrieben für den momentanen Build
  33. 33. 36 Vorgehensmodelle ● Vorgehensmodelle sollten nur so benannt werden, wenn der Verantwortliche mindestens 200 Seiten zum dem Modell gelesen hat ● Wasserfall – V Modell XT – PRINCE2 (project management) ● Iterative (agile) – Rational Unified Process – Xtreme Programming – Scrum (momentan trendy) – Kanban (noch cooler als Scrum)
  34. 34. 37 Anforderungen a.k.a User Stories aber wie? ● Anforderung z.B. wie folgt definieren: ● Welches Problem löst die Anforderung ● Bewertung des Geschäftswert ● Textuelle Beschreibung ● Prozess Diagramm machen ● Wireframes machen ● Optional: PSDs für Designs machen ● Entity-Relationship Diagramme machen ● Schätzung der Kosten ● Akzeptieren der Entwicklung
  35. 35. 38 Einflußfaktoren und Gewichtung für Produktqualität
  36. 36. 39 Vorstellung von Scrum Quelle: 2006 Softwaretechnik II Vorlesung bei Dr. Eckhardt Holz
  37. 37. 40 http://scrumcrazy.wordpress.com/2012/06/26/a-diagram-of-the-user-story-life-cycle/
  38. 38. 41 Problem ● Welche Dinge mag ein Kunde?
  39. 39. 42 Beschreibung For the following items, it is advisable to capture explicit feedback: • Fashion dresses • DVDs, especially movies • Books • Recipes The explicit feedback will also be associated with the user. Afterwards, it  may be used to make better recommendations. Additionally, it could possibly  be the case that the cross domain knowledge improves the cold start  problem when adding a new domain. This functionality should be integrated  in social networks like studiVZ. A mobile app should be made available. A survey is a special case of explicit feedback. It collects multiple,  enumerable attributes by requesting the user to answer multiple questions  on their review concerning a specific item.
  40. 40. 43 Prozessmodel User fills out survey missing fields
  41. 41. 44 Wireframe
  42. 42. 45 Entity Model
  43. 43. 46 Anfoderung ready to implement ● Nun ist die Anforderung fertig zum implementieren
  44. 44. 47
  45. 45. 48 Deployment
  46. 46. 49 Installation von Software ● Automatisiertes Bereitstellen ● Welche Funktion ist neu? ● Ausfallzeiten begrenzen ● Checklisten durchgehen nach Bereitstellung
  47. 47. 50 CI Servers production system test system SCM Entwickler 1. coden 2. commiten 3. bauen 4. automatisch testen 5. manuell testen 6. deployen
  48. 48. 51 Sicherheit
  49. 49. 52 Sicherheit ● Checkliste: ● https://www.owasp.org/index.php/Top_10_2010-Mai n ● Prozesse ● PCI compliance (Kreditkarten) ● ISO/IEC 10181 Security frameworks ● Penetration testing ● http://www.backtrack-linux.org/ ● nmap ● Nessus (http://www.tenable.com/)
  50. 50. 53 Intrusion Detection/Prevention ● Hardening PHP (Suhosin) – outdated ● Snort - http://www.snort.org/ ● „Web Application Firewall“ ● http://www.modsecurity.org/ - Apache
  51. 51. 54 Monitoring
  52. 52. 55 Monitoring ● Sicherstellung, dass angebotene Systeme laufen ● Benachrichtigung bei Ausfall von Services ● Verschiedenste Systeme ● New Relic ● Icinga → empfohlen ● Derdack Enterprise Alert ● Zabbix
  53. 53. 56

×