Project Management Flashcards

Question

Nenne mögliche ML-Modell Hubs

Answer 1

- Paperswithcode - Huggingface

Answer 2

- Improve existing process - augment manuel process - automate manuel process

Answer 3

Automatisiere, beschelunige, reduziere Fehler oder verbessere Antworten von existierenden Prozessen Beispiel: Code Completion, Customized Recommender Systems

Answer 4

Unterstütze manuelle Aufgaben mit Empfehlungen, Korrekturen und Alternativen Beispiele: - Slide Designer - Transcription Engine - Rechtschreib und Grammatikhilfe

Answer 5

Ersetze manuelle Prozesse durch automatische KI-Prozesse Beispiele: - Selbstfahrende Autos - Chatbots - Customer Support - Website Designs

Answer 6

Wirtschaftlich: Mehr Profit, Weniger Kosten Sozial: Nutzerfreundlichkeit, Mehr Nutzerzufriedenheit Technologisch: Nutzung neuer Technologie im Unternehmen (zukunftssicherheit)

Answer 7

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

Answer 8

(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

Answer 9

Business: Increase Profit Non-Profit: Improve Society

Answer 10

Meistens **nicht** durch die model performance! - Logging der Software - Nutze nur zielführende Metriken - Guardrail Metriken (Gegenmetriken im A/B Test)

Answer 11

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.

Answer 12

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“

Answer 13

**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

Answer 14

**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

Answer 15

**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.

Answer 16

**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

Answer 17

**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

Answer 18

**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

Answer 19

1. Cross-Functional Teams (in gemeinsamen Büro) 2. Das Besitzen des kompletten Prozesses von Datenextraktion bis Deployment für ein Team sorgt für einen Full-Stack View 3. Zentralisierte Infrastruktur mit separaten Infrastruktur-Team vereinheitlicht Porzesse und Tools für mehrere ML Teams innerhalb einer Orga 4. Startups stellen Allrounder ein, je größer das Produkt desto spezialisierte die neuen Angestellten 5. 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)* 6. Dokumentation Artifakte, Code und Prozesse um Kommunikationsprobleme zu lösen -> Notwendige Voraussetzung für Unterscheidung zwischen Produkt & Dev Team 7. Nutze Agiles Projektmanagement 8. Um den Wert einer ML Lösung herauszufinden, können Kosten von Alternativlösungen ohne interner ML Lösung berechnet werden 9. Nutze dedizierte Lösungen wie Model Registry und Feature Store, um klare Qualitäts Spezifikationen aufzustellen und umzusetzen 10. 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** 11. Führe diversifizierte Teams ein AAC DDD FPS VZ

Answer 20

1. **Novel or Ad-hoc ML ** *No or limited ML Knowledge in-house; selten umsetzbare Modelle; wenig Risiko* 2. **ML in R&D** *Unternehmen macht R&D Abteilung auf; schwierig an Daten zu kommen; ML Modelle selten produktiv* 3. **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* 4. **Independent ML Team** *Separater ML Teammanager; unterschiedliche ML Rollen; Budget für Investitionen eingeplant; EInfacher an qualifiziertes Personal zu kommen* 5. **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; ....*

Answer 21

1. Haben wir unterschiedliche Teams für ML Research und Product Development / Deployment 2. Wie viel SE Knowledge ist benötigt, brauchen wir ML Pipelines? 3. Wer ist verantwortlich für Daten (Sammeln, Labeln und Preprocessing) 4. Wer macht die Qualitätskontrolle 5. Ist das ML Team verantwortlich ihre Models in der Produktion zu warten?

Answer 22

1. Interdisziplinäre Teams für bessere Bildung, Verständnis und Knowledge Silos 2. Collaboration Points: Klare Verantwortlichkeiten und Team-Schnittpunkte (Meetings, Tools, ...) 3. Key Task ist Productionizing of a Product 4. Prozess und Planen: Investiere in klare Prozesse und plane voraus anstatt ad-hoc (e.g. OKR) 5. Limitiere die durch Komplexität und Tools eingeführte kognitive Belastung des Teams -> sonst werden Teams unproduktiv

Answer 23

Haupttypen: 1. Skills (**intrinsic**) -> Regression, Python 2. Mechanismen (**extraneous**) -> How to Deploy 3. Domain Knowledge (**germane**) -> Which Products? **Minimiere äußerlich & maximiere relevant**

Answer 24

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.

Answer 25

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.*

Answer 26

- **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

Project Management Flashcards

(52 cards)