Project Management Flashcards
Unterschied von Projektprogress in ML vs SE
Was sind Ursachen dafür, dass 87% der ML Projekte scheitern, bzw. 53% der ML Prototypen nicht die Produktion erreichen?
5
- Unklares Projektziel
- ML Ziel =!= Business Ziel
- Unkoordinierte Arbeite von DS vs SE
- Explodierende Kosten für Expertise und Hardware
- Komplexität des Projektes benötigt versch. Skills (SE, DevOps, Data Science, Data Engineer, …)
Was ist Hoftstadter’s Law?
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Nenne Gründe gegen AI Software
3
- Errors Costs > Improvement Costs
- Entscheidungen müssen erklärbar sein
- Entwicklung muss schnell gehen -> Starte mit Heuristiken
4 Gründe für Automatisierung
- Mehr Effizienz
- Mehr Sicherheit für Menschen
- Weniger langweilige Tasks
- Ermögliche Funktionalität, die Menschen ohne Automatisierung nicht beherrschen
4 Gründe für Augmentation (Zunahme)
- Höhere Kundezufriedenheit bei Aufgabe
- Mehr User Control
- Mehr Kundenverantwortung
- Mehr Kreativität
Definiere den Lebenszyklus eines ML-Projekts
(4)
Scoping & Planning < Data < Model < Deployment
Was gehört zu Scoping & Planning hinzu? (ML LC)
3
- Define Projekt Goals
- Specify Requirements
- Allocate Ressources
Model metric does not align with project goal; performance unsatisfiable/disappointing; requirements revisiting
Was gehört zu Data hinzu? (ML LC)
4
- Define and collect Data
- Preprocessing
- Label
- Organize Data
Data mismatch (different distribution in production); rare cases required; bias found
Was gehört zu Model hinzu? (ML LC)
5
- Model Selection
- Training
- Experimantation
- Error Analysis
- Debugging
*Production performance != training performance; non-functional properties not met; *
Was gehört zu Deployment hinzu? (ML LC)
3
- Deploy model
- monitor and maintain system
- feedback loop
Wie geht man an AI-Projekte heran?
Ziel: Budgetierung
4 + Budgetierung
Was sind Probleme an der folgenden Metrik für AI System “Credit Card Fraud”:
“Success the more unauthorized withdrawals we block”
2
- Bestes Outcome wird erreicht, wenn das System alle Transaktionen blockt
- Je mehr Transaktionen geblockt werden, desto mehr wird sich das herumsprechen, desto weniger Leute werden es bei der Orga versuchen -> Es wird angeblich schlechter über Zeit (bei Design)
Beschrifte die Achsen
Impact & Feasibility
Feasibility Pyramid for Cost Drivers + je 3 Beispielfragestellung
DMD
Difficulty
Availlability of Similar Solutions, Education, Ressource for Training, Deployment
Model Accuracy
Cost of wrong predictions, mininmum accuracy, retrain frequency
Data Availlability
Data aquiration, labeling and amount
Was sollte man bei der Datenverfügbarkeit und der Modellkomplexität beachten, wenn man über die Machbarkeitsanalyse nachdenkt?
Daten(2), Model(1)
- Wie schnelllebig sind die Daten?
- Zu welchen benötigten Informationen habe ich keinen Zugriff?
- Wie viel kostet ein Inferenzschritt?
Techniken für die Verbesserung der Machbarkeit
4
- keine 100% Accuracy Produktdesigns!
- Keine Abhängigkeit von einem einzigen Modell
- Sicherheitsmechanismen für KI-Nutzung (Anzeige bei guter Pseudo-Wahrscheinlichkeiten)
- Alpha-Test (Experimental)
Manage and Mitigate Risk
1. -> 2. -> 3.
1.Identify -> 2. Mitigate -> 3. Monitor
- Identifizierung
- Mildern / Reduzieren
- Beobachten
Was ist eine von Amazon erfunden gängige Methode für Riskmanagement?
Scoreboards in verschiedenen Kontexten:
z. B. :
- Project
- Finance
- Project Processes
- Data Quality
- Summary
Nenne die 3 Meilensteine um den Progress und Fokus für Entwicklungsstresspunkte im Auge zu behalten
- Domain Expertise
- Reproduziere Arbeit von anderen mit ähnlichen Zielen
- Automatisiere das Training und Inferenz Pipeline abgeleitet von 2.
Nenne den 1. Meilenstein während der Projektmanagement Phase ganz am Anfang und beschreibe, was ihn ausmacht.
3 + 3
Domain Expertise
**Starte einfach **
- kein ML / nur Heuristiken
- Wie lösen Menschen das Problem derzeit?
- Wie würdest du mit den aktuellen Daten es manuell lösen?
Schau dir die Daten zuerst an
- Exploratory Data Analysis (EDA)
- Manuelle Validierung der Annahmen
- Manuelles Labeln für Heuristiken zum Lösen des Problems
Nenne den 2. Meilenstein in AI-Software Engineering und beschreibe, was ihn ausmacht.
Idee + 2
Reproduziere ähnliche Arbeit
Idee: Was sind die technologischen Einschränkungen
- Ähnliche open source Repos finden
- Ähnliche ML / DL Modelle finden
Nenne den 3. Meilenstein in PM und beschreibe, was ihn ausmacht.
Simple Pipelining
Baue eine minimalistische einfache Pipeline
a) Training Pipeline
b) Inference / Production Pipeline
Nenne mögliche Datenquellen für Training
6
- Web-Archive
- reddit/r/datasets
- Kaggle
- UCI ML Repo
- Crawling
- Simple Google Search
Nenne mögliche ML-Modell Hubs
- Paperswithcode
- Huggingface
Nenne Steps in der Training Pipeline
7
Nenne Steps in der Production / Inference Pipeline
7
Nenne die Project Archetypes für AI-Software Projekte
3
- Improve existing process
- augment manuel process
- automate manuel process
Definiere den Archytype “Improve existing process” und nenne Beispiele
Automatisiere, beschelunige, reduziere Fehler oder verbessere Antworten von existierenden Prozessen
Beispiel: Code Completion, Customized Recommender Systems
Definiere den Archytype “augment manuel process” und nenne Beispiele
Unterstütze manuelle Aufgaben mit Empfehlungen, Korrekturen und Alternativen
Beispiele:
- Slide Designer
- Transcription Engine
- Rechtschreib und Grammatikhilfe
Definiere den Archytype “automate manuel process” und nenne Beispiele
Ersetze manuelle Prozesse durch automatische KI-Prozesse
Beispiele:
- Selbstfahrende Autos
- Chatbots
- Customer Support
- Website Designs
Nenne verschiedene Projekterwartungen / Ziele
Wirtschaftlich: Mehr Profit, Weniger Kosten
Sozial: Nutzerfreundlichkeit, Mehr Nutzerzufriedenheit
Technologisch: Nutzung neuer Technologie im Unternehmen (zukunftssicherheit)
Erkläre anhand des Beispieles (Organisatorisch vs Futuristisch) warum verschiedene Ziele von verschiedenen Projekterwartungen abstammen.
Organisatorisch: Profit, Umwelt, Sozial
- > Schwer den Bezug zu KI zu finden
- > Wird durch mehr als das KI Projekt beeinflusst
- > Effekte sind nicht direkt messbar
Futuristisch: Kundenzufriedenheit, -engagement
- > Könnte Organisatorische Ziele positiv beeinflussen
- > Effekte durch kleine Änderungen schwer messbar
Nenne drei Erfolgskriterien für KI-Projekte
(1) Definiere das gewünschte Ziel
(2) Defniere einen Plan, der beschreibt wie du das Ziel erreichen kannst
(3) Definiere Metriken, die deinen direkten Erfolg messen
Under the bottom line: Was ist das ultimative ML Ziel ?
(1) (1)
Business: Increase Profit
Non-Profit: Improve Society
Wie kann man die Business value messen?
Meistens nicht durch die model performance!
- Logging der Software
- Nutze nur zielführende Metriken
- Guardrail Metriken (Gegenmetriken im A/B Test)
Was sind Guardrail Metriken?
Beschreibe das Beispiel von Airbnb
Guardrail Metriken sind Gegenmetriken in A/B Tests, die gewisse Folgeeffekte messen sollen.
Wenn zum Beispiel eine Änderung einen positiven Effekt auf die Registrierungen des Dienst hat, aber die Käufe zurückgehen, sind die Anzahl der Käufe ein Guardrail-Metrik.
Airbnb hat bei der Prozessänderung “Anzeigen der Hausregeln bei der Buchung” gesehen, dass die Buchungen zugenommen haben, aber die Guardrail Metrik “Bewertung” verschlechterte sich. Stakeholder wurden informiert und der Test wurde eventuell abgebrochen.
Nenne 5 Verantwortlichkeiten eines AI Teamleiters und mögliche Hindernisse
Responsibilities
- Hire the right people
- Manage and develop people
- Managing teams’ output and align goals
- Good long-term decisions and technical debt
reduction
- Manage expectations from leadership
Obstacles
- Education, composition, scarcity of people and
limited budget
- Diverse roles, technology-hyped, CV-driven
- Timelines and uncertainty
- Technical debt (pipeline erosion), unclear
technological trend
- Management level often have a limited or false
understanding of „artificial intelligence“
Nenne 2 * 3 Organisatorische Anti-Patterns im Gebiet “Organizational Silos” und deren Gründe
Organizational Anti-Patterns
Model to Production Integration
Anti-Patterns
1. long discussion over details due lack of abstractions, documentation and processes
2. complaints driven by lack of understanding
3. blocked data scientists due their responsibility to productionize the model
Gründe
1. Verschiedene kulturelle Hintergründe zwischen DS und SE
2. DS hat keinerlei Kenntnisse in SE Prinzipien
3. SE hat keinerlei Grundkenntnisse in ML Basics
Data Producer vs Data Consumer
Anti-Patterns
1. Requesting Data is hard
2. Zwei Teams (Producer & Consumer) sind sehr eng miteinander verbunden in der SW und Data Store, aber arbeiten in Silos -> unbemerkte Fehler beim Kunden
3. unvollständige Daten im Producer Team können zu schlechter Performance in Production führen
Gründe
1. Fehlendes Bewusstsein
2. Fehlende gemeinsame Ziele
3. Fehlende Dokumentation
4. Unklare Verantwortlichkeiten
Nenne 4 + 2 Recommendations im Gebiet “Organizational Silos” gegen Organizational Anti-Patterns
Organizational Anti-Patterns
Model to Production Integration
1. Model Registry & Feature Store
Sorgt für ein sauberes Interface und Übersicht für mehrere Teams
2. Cross-Functional Teams
Schließt die Lücke zwischen DS und SE; verhindert Knowledge Silos
3. Paare DS mit SE (Code Reviews)
4. Übersetzungsarbeit zwsichen verschiedenen Rollen und gemeinsame Ziele von DS + SE
Data Producer vs Data Consumer
1. Baue Bewusstsein auf für Data Producers, dass Daten benötigt werden
2. Stelle eine zentrale Plattform bereit zwischen Data Producers und Data Consumers, welche die Daten zum Entdecken verfügbar macht und Standards, Metriken und Dokumentationen enthält
Nenne 3 + 2 Organisatorische Anti-Patterns im Gebiet “Kommunikation” und deren Gründe
Organisatorische Anti-Patterns
Redundante Entwicklung
Anti-Patterns
1. Features sind nicht erkundbar, zugreifbar oder wiederverwendbar
2. Jede Model Entwicklung benötigt deren eigene Rohdaten und Preprocessing -> Redundante ML Infrastructure und Tools
3. Shadow IT -> Teams nutzen lieber self-hosted IT Solutions mit schlechter Security als verfügbare dedizierte zentrale Infrastruktur Provider
Gründe
1. Fehlende Schnittpunkte zwsichen Teams, Dokumentation, kein Vertrauen
Management vs Data Science
Anti-Patterns
1. Data Scientists haben Probleme ihre Rolle zu erfüllen -> Burn-out (unproduktiv, keine nützlichen Resultate für das Unternehmen, endlose Iteration ohne Progress)
2. Gereizte Stimmung zwischen DS und Management (*DS sind oft direkt aus akad. Laufbahn -> Wenig Erfahrung mit ROI, Business Value, … *)
Gründe:
1. Fehlende DS Prozesse (Research orientierte Entwicklung ist zu unsicher -> es benötigt SCRUM o.ä.)
2. Kommunikationsprobleme in komplexen Themen zwischen Fachleuten und Nicht-Fachleuten
3.
Nenne 2 + 2 Recommendations im Gebiet “Kommunikation” gegen Organizational Anti-Patterns
Organisatorische Anti-Patterns
Redundante Entwicklung
1. Vereinigung und Erkundung durch Zentralisierung (Feature Stores, etc ermöglichen viele Teams zur Zusammenarbeit und Kommunikation
2. Verbessere die Verständnis zwischen Teams durch Showcase Meetings
DS vs Management
1. Neue eindeutige Entwicklungsprozesse müssen implementiert werden -> Experimentiell getrieben
2. Dokumentation und Bericht erstattung ermöglichen bessere Kommunikation mit nicht-technischen Personen
Nenne 2 + 1 + 3 Organisatorische Anti-Patterns im Gebiet “Vacuum” und deren Gründe
Organisatorische Anti-Patterns
Headless Chicken Hiring
1. Personal mit unzureichenden Fähigkeiten
2. Eingestellte DS mit Inselwissen in einem Spezialaufgabe werden obsolet nachdem die Aufgabe erfüllt wurde
Gründe
1. Unklare Rollen und Titel
2. Unqualifizierter einstellender Manager
3. Zu wenig suchende Arbeitnehmer mit notwendigen Fähigkeiten
Résumé-driven Development
1. Ausgesuchte Tools, Libraries, Frameworks passen nicht zum Produkt oder Team
Gründe
1. DS identifizieren sich nicht mit dem Business Value (Fokussieren sich nur auf technischen Erfolg)
2. Fehlender Entscheidungsträger im Team
Hype-Driven Development
1. Viele PoC’s, keine Produkte
2. Keine Analyse über die tatsächlichen Teile in der Anwendung, welche von ML profitieren könnte (Einstellung: alles profitiert von ML)
3. Produkt ist nicht machbar, wegen fehlender Daten oder Expertise
Gründe
1. Fehlende unternehmerische Strategie, Regelungen und Strukturen (e.g. unmanaged Data Collection Processes)
2. Management hat keine ML Kenntnisse
3. Schlechte Übersetzung der Business Goals in die technologischen Ziele
4. Fehlende Product-Metrics, da DS nicht in der Lage ist für das Produkt relevante Metriken aufzustellen
Nenne 1 + 1 + 3 Recommendations im Gebiet “Vacuum” gegen Organizational Anti-Patterns
Organizational Anti-Patterns
Headless Chicken Hiring
1. Stelle Fähigkeiten und Potentiale ein anstelle von Jobtitel
Résumé-Driven Development
1. Nutze existierende Technolgien aus anderen Abteilungen als Fallback Alternative, falls es keine Authorität gibt, welche diese genehmigen muss
Hype-Driven Development
1. Nutze Prozesse, welche machbare Use-Cases identifizieren und Produkt Roadmaps erstellen (Awareness Raising, Proposals für Machbarkeitsschätzungen, Datenverfügbarkeit, …)
2. DS sollten mit Kunden kommunizieren
3. Education um Datenverfügbarkeit aufzuzeigen
Zähle organisatorische Best-Practice Empfehlungen auf
Organisatorische Best Practice
- Cross-Functional Teams (in gemeinsamen Büro)
- Das Besitzen des kompletten Prozesses von Datenextraktion bis Deployment für ein Team sorgt für einen Full-Stack View
- Zentralisierte Infrastruktur mit separaten Infrastruktur-Team vereinheitlicht Porzesse und Tools für mehrere ML Teams innerhalb einer Orga
- Startups stellen Allrounder ein, je größer das Produkt desto spezialisierte die neuen Angestellten
- Separierung des DS Prozesses mit T-Shaped Knowledge Base sorgt für spezialisierte Teilgebiete mit guten Überblick (Data Prepro T Feature Engineering T Learning & Validation)
- Dokumentation Artifakte, Code und Prozesse um Kommunikationsprobleme zu lösen -> Notwendige Voraussetzung für Unterscheidung zwischen Produkt & Dev Team
- Nutze Agiles Projektmanagement
- Um den Wert einer ML Lösung herauszufinden, können Kosten von Alternativlösungen ohne interner ML Lösung berechnet werden
- Nutze dedizierte Lösungen wie Model Registry und Feature Store, um klare Qualitäts Spezifikationen aufzustellen und umzusetzen
- Favorisiere Proaktive Kommunikation: Identifiziere Stakeholder, setze Meetings an um mit Techs Entscheidungen zu kommunizieren; Kommuniziere, was Teams leisten bzw. delivern müssen; Die wenigsten werden mir proaktiv die Informationen liefern, die ich benötige
- Führe diversifizierte Teams ein
AAC DDD FPS VZ
Nenne und beschreibe kurz 5 verschiedene unternehmerische Archetypes (ML Unternehmen)
Organisatorische Best Practice
- **Novel or Ad-hoc ML **
No or limited ML Knowledge in-house; selten umsetzbare Modelle; wenig Risiko -
ML in R&D
Unternehmen macht R&D Abteilung auf; schwierig an Daten zu kommen; ML Modelle selten produktiv -
ML eingebaut im Business / Produkt
Produkt Teams haben ML Kenntnisse; ML ist in Entscheidungen beachtet; -> schwierig Talente zu bekommen, ML Projektzyklus oft nicht im Einklang mit SW -
Independent ML Team
Separater ML Teammanager; unterschiedliche ML Rollen; Budget für Investitionen eingeplant; EInfacher an qualifiziertes Personal zu kommen -
ML First
CEO geht ALL-IN ML; ML Divisionen; Große ML Expertise in allen Bereichen; Datenverfügbarkeit überall; Einfache Deployments, Schwierig ML First zu werden; Teuer; ….
Nenne 5 organisatorische Entscheidungen, welche vorher getroffen werden sollten.
Organisatorische Best Practice
- Haben wir unterschiedliche Teams für ML Research und Product Development / Deployment
- Wie viel SE Knowledge ist benötigt, brauchen wir ML Pipelines?
- Wer ist verantwortlich für Daten (Sammeln, Labeln und Preprocessing)
- Wer macht die Qualitätskontrolle
- Ist das ML Team verantwortlich ihre Models in der Produktion zu warten?
Nenne 5 Best Practice Richtlinien in Teams
Organisatorische Best Practice
- Interdisziplinäre Teams für bessere Bildung, Verständnis und Knowledge Silos
- Collaboration Points: Klare Verantwortlichkeiten und Team-Schnittpunkte (Meetings, Tools, …)
- Key Task ist Productionizing of a Product
- Prozess und Planen: Investiere in klare Prozesse und plane voraus anstatt ad-hoc (e.g. OKR)
- Limitiere die durch Komplexität und Tools eingeführte kognitive Belastung des Teams -> sonst werden Teams unproduktiv
Wie genau kann man bestehende kognitive Überlastung in Teams senken. Gehe auf die drei Haupttypen ein.
Organisatorische Best Practice
Haupttypen:
1. Skills (intrinsic) -> Regression, Python
2. Mechanismen (extraneous) -> How to Deploy
3. Domain Knowledge (germane) -> Which Products?
Minimiere äußerlich & maximiere relevant
Was ist Ensemble Programming?
Organisatorische Best Practice
Mehrere Entwickler gleichzeitig an einem einzigen Computer
Dieses kollaborative Vorgehen fördert den Wissensaustausch, reduziert Fehler und ermöglicht es, verschiedene Perspektiven und Lösungsansätze zu kombinieren.
Was ist Domain Driven Design und wie beeinflusst es die kognitive Belastung in SE Teams
Organisatorische Best Practice
Domain-Driven Design (DDD) ist eine Softwareentwicklungsmethode, die darauf abzielt, komplexe Softwareanwendungen zu entwerfen, indem sie eng an die Domäne (das Geschäftsfeld) und dessen Begriffe angepasst wird. Der Fokus liegt auf einer klaren Kommunikation zwischen Entwicklern und Fachexperten und darauf, das Domänenwissen im Code zu verankern.
-
Reduzierte Komplexität:
Durch die klare Trennung von Domänen in Bounded Contexts wird die Komplexität des Systems in kleinere, besser verständliche Teile aufgeteilt.
Gemeinsame Sprache: DDD fördert eine Ubiquitous Language, die von Entwicklern und Fachexperten verwendet wird, um Missverständnisse zu minimieren und die kognitive Last zu verringern.
Gehe auf das Team Topologies Konzept ein. Welche vier Haupt-Topologien für das Entwickeln von modularisierter Software gibt es?
Wie helfen diese die kognitiven Belastung zu reduzieren?
Organisatorische Best-Practice
- Streamlined Team: End-2-End Entwicklung von Features bis Deployment
- Enabling Team: Baut unterstützende Services
- Komplizierte Subsysteme: Teams, welche sich nur darauf konzentrieren (KI, Encryption)
- Plattform Teams: Biete fundamentelle Technologien an (zB Infrastruktur)
Enabling, Subsystems und Plattform Teams helfen den Stream-Line Teams durch reduzierte kognitive Belastung. Das Stream-Line Team schafft die Main-value des Unternehmens
