"Sztuczna inteligencja" - temat jak najogólniejszy, by zmieścić wszystko!
- Thread starter Drzewo
- Start date
Drzewo
UFC Heavyweight
Polacy stworzyli system AI przeciwko dronom. Inicjatywę wspiera współtwórca Booksy
Polski zespół naukowców, ekspertów branży obronnej oraz przedsiębiorców technologicznych pracuje nad TridentAI – systemem podwójnego zastosowania (dual-use) służącym do podejmowania strategicznych decyzji w czasie rzeczywistym oraz umożliwiającym koordynację i autonomiczne działania rojów dronów.
www.dlahandlu.pl
Nie założyłem tego tematu bo jestem ekspertem, tak jak nie trzeba być ekspertem by założyć jakikolwiek temat na tym forum. Zluzujcie rajtuzy, dzieciaczki, bo żyłki pękną i na co to komu
Drzewo
UFC Heavyweight
Chuj, podzielę się z Wami, co mi tam -
Nagranie od ludzi z Product Heroes, a tu wkleję Wam opis paru sztuczek sztucznej z filmu, w designie i prototypowaniu:
Zwłaszcza ostatnia sztuczka jest konkretna, bo możliwość kopiowania działającego rozwiązania ze strony www jest konkretem na maksa.
- Traktuj AI jako akcelerator inspiracji, a nie generator finałów – narzędzia takie jak Figma Make czy v0 generują projekty o niskiej jakości. Stanowią jednak doskonałe źródło inspiracji, gotowych tekstów i struktury do dalszej, już manualnej pracy projektowej. To narzędzia, które wymagają kontekstu, iteracji i ludzkiego "smaku".
Zacznij research od rozmowy z ChatGPT – jeśli wchodzisz w zupełnie nowy temat, tak jak Tomek w edukację finansową dzieci, poproś AI o przygotowanie wstępnego raportu i założeń do walidacji. To potężnie skraca czas potrzebny na wstępne rozpoznanie i daje solidny punkt wyjścia do dalszej pracy.
Używaj FigJam AI do przygotowania warsztatów – zamiast wymyślać agendę od zera, wklej tam swój "problem statement". AI wygeneruje gotowy szablon warsztatu z pomysłami na ćwiczenia, co pomaga szybko i skutecznie wyrównać wiedzę w zespole.
Prototypuj złożone interakcje w Cursorze, a nie w Figmie – nawet jeśli nie jesteś programistą, możesz w kilkanaście minut stworzyć w pełni interaktywny prototyp, który uwzględnia różne stany i pozwala znaleźć błędy, o których nie pomyślałbyś w statycznym projekcie.
Możesz inspirować się i adaptować rozwiązania konkurencji – w nagraniu zobaczysz, jak za pomocą wtyczki HTML to Design i Cursora można skopiować komponent ze strony konkurencji (np. kalkulator PKO), ostylować go zgodnie z design systemem własnej firmy (ING) i stworzyć w pełni interaktywny prototyp w kilkanaście minut, bez dostępu do oryginalnych plików projektowych.
Nagranie od ludzi z Product Heroes, a tu wkleję Wam opis paru sztuczek sztucznej z filmu, w designie i prototypowaniu:
Zwłaszcza ostatnia sztuczka jest konkretna, bo możliwość kopiowania działającego rozwiązania ze strony www jest konkretem na maksa.
- Traktuj AI jako akcelerator inspiracji, a nie generator finałów – narzędzia takie jak Figma Make czy v0 generują projekty o niskiej jakości. Stanowią jednak doskonałe źródło inspiracji, gotowych tekstów i struktury do dalszej, już manualnej pracy projektowej. To narzędzia, które wymagają kontekstu, iteracji i ludzkiego "smaku".
Zacznij research od rozmowy z ChatGPT – jeśli wchodzisz w zupełnie nowy temat, tak jak Tomek w edukację finansową dzieci, poproś AI o przygotowanie wstępnego raportu i założeń do walidacji. To potężnie skraca czas potrzebny na wstępne rozpoznanie i daje solidny punkt wyjścia do dalszej pracy.
Używaj FigJam AI do przygotowania warsztatów – zamiast wymyślać agendę od zera, wklej tam swój "problem statement". AI wygeneruje gotowy szablon warsztatu z pomysłami na ćwiczenia, co pomaga szybko i skutecznie wyrównać wiedzę w zespole.
Prototypuj złożone interakcje w Cursorze, a nie w Figmie – nawet jeśli nie jesteś programistą, możesz w kilkanaście minut stworzyć w pełni interaktywny prototyp, który uwzględnia różne stany i pozwala znaleźć błędy, o których nie pomyślałbyś w statycznym projekcie.
Możesz inspirować się i adaptować rozwiązania konkurencji – w nagraniu zobaczysz, jak za pomocą wtyczki HTML to Design i Cursora można skopiować komponent ze strony konkurencji (np. kalkulator PKO), ostylować go zgodnie z design systemem własnej firmy (ING) i stworzyć w pełni interaktywny prototyp w kilkanaście minut, bez dostępu do oryginalnych plików projektowych.
Drzewo
UFC Heavyweight
Notebook LM od Google'a to bardzo mocne narzędzie do pracy naukowej - bazę wiedzy tworzymy najpierw, dodając źródła, a później za pomocą promptów odpytujemy silnik na interesujące nas tematy z wybranych źródeł, dzięki czemu znika lub jest minimalizowane ryzyko halucynacji.
Google NotebookLM | AI Research Tool & Thinking Partner
Meet NotebookLM, the AI research tool and thinking partner that can analyze your sources, turn complexity into clarity and transform your content.
notebooklm.google
Drzewo
UFC Heavyweight
Użycie Notebook LM na jebitnym dokumencie, jakim jest BABOK 3.0 i możliwość błyskawicznego przeanalizowania tak dużego dokumentu i wygenerowanie dowolnej treści z czegoś takiego jest genialne.
Ten soft zrewolucjonizuje prace badawcze i prace z jakimikolwiek dokumentami.
"
Jako analityk biznesowo-systemowy pracujący w software house i zajmujący się organizacją chaosu powstałego po fuzji trzech firm (tzw. "merge"), muszę zastosować usystematyzowane podejście, aby dopasować istniejące wymagania i stworzyć nowe. Złożoność projektu, wynikająca z integracji systemów i procesów (czego przykładem są potrójne wynagrodzenia), wymaga połączenia perspektyw IT, zarządzania procesami biznesowymi oraz silnego nacisku na analizę strategiczną.
Poniżej przedstawiam wdrożenie na projekt (onboarding) bazujące na wytycznych BABOK® Guide v3 [1]:
---
## 1. Definicja Roli i Cele Projektu
Moja rola jako analityka biznesowo-systemowego polega na byciu kluczowym łącznikiem między potrzebami biznesowymi (interesariuszy) a zespołem dostarczającym rozwiązanie techniczne [2].
**Głównym celem** jest **umożliwienie zmiany** (post-merger integration) poprzez zdefiniowanie potrzeb i rekomendowanie rozwiązań, które **dostarczają wartość** interesariuszom [3]. W obecnym kontekście, wartość ta jest realizowana głównie poprzez **organizację chaosu, eliminację niespójności** i redukcję ryzyka operacyjnego i finansowego (np. eliminacja potrójnych wypłat) [3, 4].
Musimy dążyć do zrozumienia **stanu obecnego (Current State)**, zdefiniowania **stanu przyszłego (Future State)** oraz określenia działań niezbędnych do przejścia między nimi (Change Strategy) [3].
## 2. Perspektywa Analityczna i Podejście
Biorąc pod uwagę złożoność *merge’u* w regulowanej branży finansowej oraz problemy z chaosem procesowym i danymi (potrójne wypłaty), należy zidentyfikować kluczowe perspektywy i metody pracy:
1. **Perspektywa Zarządzania Procesami Biznesowymi (BPM Perspective 11.5):** Jest to kluczowa perspektywa w przypadku racjonalizacji organizacji po fuzjach (post merger and acquisition rationalization) [5]. Skupia się na identyfikacji, priorytetyzacji i optymalizacji procesów biznesowych w celu dostarczenia wartości [5].
2. **Perspektywa Technologii Informacyjnych (IT Perspective 11.3):** Konieczna do zarządzania systemami i aplikacjami, szczególnie gdy celem jest **integracja systemów** [6, 7]. W tym kontekście, IT BA pełni rolę tłumacza, pomagając biznesowi i zespołowi technicznemu zrozumieć wzajemne potrzeby i ograniczenia [2].
3. **Podejście do Projektu (Approach):** Biorąc pod uwagę, że firma jest **środowiskiem silnie regulowanym** [8, 9] i problemem jest wysokie ryzyko (błędy finansowe), zalecane jest przyjęcie **Podejścia Predykcyjnego (Predictive Approach)**, które preferuje formalną dokumentację i zdefiniowanie wymagań w celu maksymalizacji kontroli i minimalizacji ryzyka [10, 11]. Można zastosować **metodykę hybrydową** [12], łącząc ogólną predykcyjną strategię (dla dużych zmian architektonicznych) z adaptacyjnymi technikami na poziomie detali.
## 3. Kluczowe Obszary Wiedzy BABOK (Knowledge Areas)
W obliczu chaosu wynikającego z fuzji i konieczności weryfikacji dokumentów innego analityka, kluczowe będą zadania z obszarów *Strategy Analysis* oraz *Requirements Analysis and Design Definition*:
| Obszar Wiedzy | Kluczowe Zadania i Zastosowanie w Projekcie Fuzji |
| :--- | :--- |
| **Strategy Analysis** (Analiza Strategii) [13] | **Zarządzanie Chaosem i Ryzykiem** |
| **Analyze Current State** (6.1) [14] | **Natychmiastowa analiza procesów i systemów płatności** w celu zidentyfikowania **pierwotnej przyczyny (Root Cause Analysis 10.40)** problemu [15, 16]. Zrozumienie, jak funkcjonują trzy zintegrowane (lub niezintegrowane) organizacje, ich zdolności (capabilities), technologie i infrastruktura [17, 18]. |
| **Define Future State** (6.2) [18] | Określenie warunków niezbędnych do osiągnięcia celów biznesowych po fuzji, w tym jednolitych procesów (to-be process models) i zintegrowanej architektury systemowej [19]. |
| **Assess Risks** (6.3) [20] | Identyfikacja, ocena i priorytetyzacja ryzyk związanych z integracją (np. dalsze problemy finansowe, ryzyko niezgodności regulacyjnej [8, 21]). |
| **Requirements Analysis and Design Definition** (7) [22] | **Weryfikacja Wymagań (dostarczonych przez innego analityka)** |
| **Verify Requirements** (7.2) [23] | Zapewnienie, że istniejące wymagania i projekty są **kompletne, spójne wewnętrznie i wysokiej jakości** [23, 24]. Błędy w wymaganiach są źródłem większości poważnych problemów z jakością w projektach [25]. |
| **Validate Requirements** (7.3) [23] | Upewnienie się, że wymagania te **dostarczają wartość biznesową** i wspierają cele organizacji po fuzji [23, 26]. |
| **Define Requirements Architecture** (7.4) [27] | Strukturyzowanie wszystkich wymagań (pochodzących z trzech różnych źródeł) w spójną całość [27]. Jest to niezbędne, aby nowe systemy działały w harmonii i wspierały wspólne cele biznesowe [28]. |
| **Requirements Life Cycle Management** (5) [29] | **Trace Requirements** (5.1): Ustanowienie śledzenia, aby powiązać wymagania z celami biznesowymi i komponentami rozwiązania, co jest kluczowe w zarządzaniu zakresem i ocenianiu wpływu zmian (impact analysis) [30, 31]. |
## 4. Analiza Wymagań Funkcjonalnych i Niefunkcjonalnych
Skoro dokumenty zostały już wstępnie utworzone, kluczowe jest ich dogłębne zweryfikowanie [23]:
### A. Wymagania Funkcjonalne (Functional Requirements)
Wymagania funkcjonalne opisują, co rozwiązanie musi robić w zakresie zachowania i informacji [32, 33].
* **Weryfikacja spójności:** Należy sprawdzić, czy listy wymagań z każdej z trzech pierwotnych firm nie są sprzeczne. W tym celu można posłużyć się technikami modelowania:
* **Process Modelling (10.35):** Utworzenie modeli *as-is* dla kluczowych procesów (np. proces obsługi płatności ) z każdej z trzech firm i porównanie ich. Użycie notacji BPMN [34] pomoże w szybkim zidentyfikowaniu różnic (nielogiczności i zbędnych czynności [35]) oraz w zaprojektowaniu ujednoliconego procesu *to-be* [36].
* **Use Cases and Scenarios (10.47):** Scenariusze (dialogi Aktor <—> System [37]) są doskonałym narzędziem do testowania logiki wymagań funkcjonalnych [38].
### B. Wymagania Niefunkcjonalne (Non-Functional Requirements – NFR)
NFR opisują atrybuty jakościowe (performance, security, usability) i są kluczowe [39, 40].
* **Compliance/Regulatory Requirements:** W branży finansowej przepisy i regulacje (Regulatorzy [41, 42]) narzucają formalne ograniczenia [8, 9, 43, 44]. NFR muszą odzwierciedlać wymogi prawne (Legal/Regulatory Information [43, 45]) oraz korporacyjne (corporate governance standards [41]).
* **Skalowalność (Scalability) i Wydajność (Performance Efficiency):** Nowe zintegrowane rozwiązanie musi być w stanie obsłużyć połączoną bazę klientów i wolumen transakcji [39, 46]. NFR powinny być mierzalne (Measurable) [39, 47].
* **Analiza NFR (10.30):** Musi być wykorzystana do dogłębnej definicji tych atrybutów, zwłaszcza że problem potrójnych wypłat może być związany z błędami integracji danych (Data Quality) [48].
## 5. Kluczowe Kompetencje i Techniki Wymagane na Projekcie
Sukces w zarządzaniu tak chaotycznym projektem będzie wymagał wykorzystania określonych kompetencji podstawowych (Underlying Competencies) [49, 50]:
| Kompetencja (BABOK) | Znaczenie w Projekcie Fuzji/Chaosu |
| :--- | :--- |
| **Systems Thinking** (Myślenie Systemowe 9.1.5) [51] | Niezbędne do zrozumienia, jak zmiana w jednym systemie/procesie (np. potrójna wypłata) wpływa na cały system (ludzie, procesy, technologia) [51-53]. |
| **Analytical Thinking and Problem Solving** (Myślenie Analityczne i Rozwiązywanie Problemów 9.1) [50] | Umożliwia asymilację różnorodnych informacji i identyfikację, które zmiany dostarczą największą wartość [54]. Niezbędne do **Root Cause Analysis** [15, 16]. |
| **Negotiation and Conflict Resolution** (Negocjacje i Rozwiązywanie Konfliktów 9.5.4) [55] | Konieczne do rozwiązywania sporów między pracownikami i działami (Stakeholder groups frequently have varying points of view and conflicting priorities [56]), zwłaszcza przy wyborze ujednoliconych procesów i systemów. Analityk działa jako neutralny facylitator [57]. |
| **Organization Knowledge** (Wiedza Organizacyjna 9.3.3) [58] | Zrozumienie, jak zintegrowane przedsiębiorstwo generuje zyski, jego struktura (formalna i nieformalna) i kanały komunikacji. Krytyczne do *organizacji chaosu* [58]. |
### Techniki Zarządzania Stakeholderami:
* **Stakeholder List, Map, or Personas (10.43):** Konieczne do zidentyfikowania kluczowych uczestników ze wszystkich trzech firm, ich oczekiwań i poziomu wpływu [59].
* **RACI Analysis:** Użycie macierzy RACI [60, 61] jest zalecane do jasnego określenia ról i odpowiedzialności w zarządzaniu wymaganiami i procesami, co zapobiega powielaniu pracy i konfliktom (jedna osoba akceptująca zakres, jedna odpowiedzialna za realizację) [61, 62].
## 6. Wnioski Końcowe i Przygotowanie
Moje wdrożenie na projekt koncentruje się na metodycznym przejściu od chaosu do spójności:
1. **Audyt Wymagań:** Nie ufamy automatycznie istniejącym dokumentom. Musimy **zweryfikować i zatwierdzić** (Verify and Validate) wymagania funkcjonalne i niefunkcjonalne pod kątem ich spójności, kompletności i zgodności ze wspólnymi celami biznesowymi po fuzji [23].
2. **Modelowanie Dziedziny (Domain Model):** W kontekście problemu (potrójne wypłaty), kluczowe jest **modelowanie danych** i **reguł biznesowych** [63, 64] w dziedzinie finansów/płatności, aby upewnić się, że dane (Dane reprezentują Fakty [65]) są magazynowane i przetwarzane w sposób jednoznaczny i strukturalny [66, 67].
3. **Analiza Korzenia Problemów (Root Cause Analysis):** Zamiast po prostu poprawiać wymaganie, które pozwala na potrójne wypłaty, musimy zrozumieć, co jest **przyczyną** tego błędu (fakt a przyczyna [68]). Jest to prawdopodobnie wynik niespójności systemowej, procesowej lub nieprawidłowo zintegrowanych danych.
**Dobra analiza to nie setki stron, ale zaawansowane metody analizy, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu** [69]."
I jak wrazenia?
To tylko jedno niedopracowane pytanie... I jedna książka w PDFie.
Książek, filmów, stron czy baz danych może być 50. Głowa rozjebana.
Ten soft zrewolucjonizuje prace badawcze i prace z jakimikolwiek dokumentami.
"
Jako analityk biznesowo-systemowy pracujący w software house i zajmujący się organizacją chaosu powstałego po fuzji trzech firm (tzw. "merge"), muszę zastosować usystematyzowane podejście, aby dopasować istniejące wymagania i stworzyć nowe. Złożoność projektu, wynikająca z integracji systemów i procesów (czego przykładem są potrójne wynagrodzenia), wymaga połączenia perspektyw IT, zarządzania procesami biznesowymi oraz silnego nacisku na analizę strategiczną.
Poniżej przedstawiam wdrożenie na projekt (onboarding) bazujące na wytycznych BABOK® Guide v3 [1]:
---
## 1. Definicja Roli i Cele Projektu
Moja rola jako analityka biznesowo-systemowego polega na byciu kluczowym łącznikiem między potrzebami biznesowymi (interesariuszy) a zespołem dostarczającym rozwiązanie techniczne [2].
**Głównym celem** jest **umożliwienie zmiany** (post-merger integration) poprzez zdefiniowanie potrzeb i rekomendowanie rozwiązań, które **dostarczają wartość** interesariuszom [3]. W obecnym kontekście, wartość ta jest realizowana głównie poprzez **organizację chaosu, eliminację niespójności** i redukcję ryzyka operacyjnego i finansowego (np. eliminacja potrójnych wypłat) [3, 4].
Musimy dążyć do zrozumienia **stanu obecnego (Current State)**, zdefiniowania **stanu przyszłego (Future State)** oraz określenia działań niezbędnych do przejścia między nimi (Change Strategy) [3].
## 2. Perspektywa Analityczna i Podejście
Biorąc pod uwagę złożoność *merge’u* w regulowanej branży finansowej oraz problemy z chaosem procesowym i danymi (potrójne wypłaty), należy zidentyfikować kluczowe perspektywy i metody pracy:
1. **Perspektywa Zarządzania Procesami Biznesowymi (BPM Perspective 11.5):** Jest to kluczowa perspektywa w przypadku racjonalizacji organizacji po fuzjach (post merger and acquisition rationalization) [5]. Skupia się na identyfikacji, priorytetyzacji i optymalizacji procesów biznesowych w celu dostarczenia wartości [5].
2. **Perspektywa Technologii Informacyjnych (IT Perspective 11.3):** Konieczna do zarządzania systemami i aplikacjami, szczególnie gdy celem jest **integracja systemów** [6, 7]. W tym kontekście, IT BA pełni rolę tłumacza, pomagając biznesowi i zespołowi technicznemu zrozumieć wzajemne potrzeby i ograniczenia [2].
3. **Podejście do Projektu (Approach):** Biorąc pod uwagę, że firma jest **środowiskiem silnie regulowanym** [8, 9] i problemem jest wysokie ryzyko (błędy finansowe), zalecane jest przyjęcie **Podejścia Predykcyjnego (Predictive Approach)**, które preferuje formalną dokumentację i zdefiniowanie wymagań w celu maksymalizacji kontroli i minimalizacji ryzyka [10, 11]. Można zastosować **metodykę hybrydową** [12], łącząc ogólną predykcyjną strategię (dla dużych zmian architektonicznych) z adaptacyjnymi technikami na poziomie detali.
## 3. Kluczowe Obszary Wiedzy BABOK (Knowledge Areas)
W obliczu chaosu wynikającego z fuzji i konieczności weryfikacji dokumentów innego analityka, kluczowe będą zadania z obszarów *Strategy Analysis* oraz *Requirements Analysis and Design Definition*:
| Obszar Wiedzy | Kluczowe Zadania i Zastosowanie w Projekcie Fuzji |
| :--- | :--- |
| **Strategy Analysis** (Analiza Strategii) [13] | **Zarządzanie Chaosem i Ryzykiem** |
| **Analyze Current State** (6.1) [14] | **Natychmiastowa analiza procesów i systemów płatności** w celu zidentyfikowania **pierwotnej przyczyny (Root Cause Analysis 10.40)** problemu [15, 16]. Zrozumienie, jak funkcjonują trzy zintegrowane (lub niezintegrowane) organizacje, ich zdolności (capabilities), technologie i infrastruktura [17, 18]. |
| **Define Future State** (6.2) [18] | Określenie warunków niezbędnych do osiągnięcia celów biznesowych po fuzji, w tym jednolitych procesów (to-be process models) i zintegrowanej architektury systemowej [19]. |
| **Assess Risks** (6.3) [20] | Identyfikacja, ocena i priorytetyzacja ryzyk związanych z integracją (np. dalsze problemy finansowe, ryzyko niezgodności regulacyjnej [8, 21]). |
| **Requirements Analysis and Design Definition** (7) [22] | **Weryfikacja Wymagań (dostarczonych przez innego analityka)** |
| **Verify Requirements** (7.2) [23] | Zapewnienie, że istniejące wymagania i projekty są **kompletne, spójne wewnętrznie i wysokiej jakości** [23, 24]. Błędy w wymaganiach są źródłem większości poważnych problemów z jakością w projektach [25]. |
| **Validate Requirements** (7.3) [23] | Upewnienie się, że wymagania te **dostarczają wartość biznesową** i wspierają cele organizacji po fuzji [23, 26]. |
| **Define Requirements Architecture** (7.4) [27] | Strukturyzowanie wszystkich wymagań (pochodzących z trzech różnych źródeł) w spójną całość [27]. Jest to niezbędne, aby nowe systemy działały w harmonii i wspierały wspólne cele biznesowe [28]. |
| **Requirements Life Cycle Management** (5) [29] | **Trace Requirements** (5.1): Ustanowienie śledzenia, aby powiązać wymagania z celami biznesowymi i komponentami rozwiązania, co jest kluczowe w zarządzaniu zakresem i ocenianiu wpływu zmian (impact analysis) [30, 31]. |
## 4. Analiza Wymagań Funkcjonalnych i Niefunkcjonalnych
Skoro dokumenty zostały już wstępnie utworzone, kluczowe jest ich dogłębne zweryfikowanie [23]:
### A. Wymagania Funkcjonalne (Functional Requirements)
Wymagania funkcjonalne opisują, co rozwiązanie musi robić w zakresie zachowania i informacji [32, 33].
* **Weryfikacja spójności:** Należy sprawdzić, czy listy wymagań z każdej z trzech pierwotnych firm nie są sprzeczne. W tym celu można posłużyć się technikami modelowania:
* **Process Modelling (10.35):** Utworzenie modeli *as-is* dla kluczowych procesów (np. proces obsługi płatności ) z każdej z trzech firm i porównanie ich. Użycie notacji BPMN [34] pomoże w szybkim zidentyfikowaniu różnic (nielogiczności i zbędnych czynności [35]) oraz w zaprojektowaniu ujednoliconego procesu *to-be* [36].
* **Use Cases and Scenarios (10.47):** Scenariusze (dialogi Aktor <—> System [37]) są doskonałym narzędziem do testowania logiki wymagań funkcjonalnych [38].
### B. Wymagania Niefunkcjonalne (Non-Functional Requirements – NFR)
NFR opisują atrybuty jakościowe (performance, security, usability) i są kluczowe [39, 40].
* **Compliance/Regulatory Requirements:** W branży finansowej przepisy i regulacje (Regulatorzy [41, 42]) narzucają formalne ograniczenia [8, 9, 43, 44]. NFR muszą odzwierciedlać wymogi prawne (Legal/Regulatory Information [43, 45]) oraz korporacyjne (corporate governance standards [41]).
* **Skalowalność (Scalability) i Wydajność (Performance Efficiency):** Nowe zintegrowane rozwiązanie musi być w stanie obsłużyć połączoną bazę klientów i wolumen transakcji [39, 46]. NFR powinny być mierzalne (Measurable) [39, 47].
* **Analiza NFR (10.30):** Musi być wykorzystana do dogłębnej definicji tych atrybutów, zwłaszcza że problem potrójnych wypłat może być związany z błędami integracji danych (Data Quality) [48].
## 5. Kluczowe Kompetencje i Techniki Wymagane na Projekcie
Sukces w zarządzaniu tak chaotycznym projektem będzie wymagał wykorzystania określonych kompetencji podstawowych (Underlying Competencies) [49, 50]:
| Kompetencja (BABOK) | Znaczenie w Projekcie Fuzji/Chaosu |
| :--- | :--- |
| **Systems Thinking** (Myślenie Systemowe 9.1.5) [51] | Niezbędne do zrozumienia, jak zmiana w jednym systemie/procesie (np. potrójna wypłata) wpływa na cały system (ludzie, procesy, technologia) [51-53]. |
| **Analytical Thinking and Problem Solving** (Myślenie Analityczne i Rozwiązywanie Problemów 9.1) [50] | Umożliwia asymilację różnorodnych informacji i identyfikację, które zmiany dostarczą największą wartość [54]. Niezbędne do **Root Cause Analysis** [15, 16]. |
| **Negotiation and Conflict Resolution** (Negocjacje i Rozwiązywanie Konfliktów 9.5.4) [55] | Konieczne do rozwiązywania sporów między pracownikami i działami (Stakeholder groups frequently have varying points of view and conflicting priorities [56]), zwłaszcza przy wyborze ujednoliconych procesów i systemów. Analityk działa jako neutralny facylitator [57]. |
| **Organization Knowledge** (Wiedza Organizacyjna 9.3.3) [58] | Zrozumienie, jak zintegrowane przedsiębiorstwo generuje zyski, jego struktura (formalna i nieformalna) i kanały komunikacji. Krytyczne do *organizacji chaosu* [58]. |
### Techniki Zarządzania Stakeholderami:
* **Stakeholder List, Map, or Personas (10.43):** Konieczne do zidentyfikowania kluczowych uczestników ze wszystkich trzech firm, ich oczekiwań i poziomu wpływu [59].
* **RACI Analysis:** Użycie macierzy RACI [60, 61] jest zalecane do jasnego określenia ról i odpowiedzialności w zarządzaniu wymaganiami i procesami, co zapobiega powielaniu pracy i konfliktom (jedna osoba akceptująca zakres, jedna odpowiedzialna za realizację) [61, 62].
## 6. Wnioski Końcowe i Przygotowanie
Moje wdrożenie na projekt koncentruje się na metodycznym przejściu od chaosu do spójności:
1. **Audyt Wymagań:** Nie ufamy automatycznie istniejącym dokumentom. Musimy **zweryfikować i zatwierdzić** (Verify and Validate) wymagania funkcjonalne i niefunkcjonalne pod kątem ich spójności, kompletności i zgodności ze wspólnymi celami biznesowymi po fuzji [23].
2. **Modelowanie Dziedziny (Domain Model):** W kontekście problemu (potrójne wypłaty), kluczowe jest **modelowanie danych** i **reguł biznesowych** [63, 64] w dziedzinie finansów/płatności, aby upewnić się, że dane (Dane reprezentują Fakty [65]) są magazynowane i przetwarzane w sposób jednoznaczny i strukturalny [66, 67].
3. **Analiza Korzenia Problemów (Root Cause Analysis):** Zamiast po prostu poprawiać wymaganie, które pozwala na potrójne wypłaty, musimy zrozumieć, co jest **przyczyną** tego błędu (fakt a przyczyna [68]). Jest to prawdopodobnie wynik niespójności systemowej, procesowej lub nieprawidłowo zintegrowanych danych.
**Dobra analiza to nie setki stron, ale zaawansowane metody analizy, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu** [69]."
I jak wrazenia?
To tylko jedno niedopracowane pytanie... I jedna książka w PDFie.
Książek, filmów, stron czy baz danych może być 50. Głowa rozjebana.
Last edited:
Prorok Izajasz
UFC Light Heavyweight
Drzewo
UFC Heavyweight
Drzewo
UFC Heavyweight
Notebook LM to narzędzie mistrzów.
Wrzuciłem wymaganie do sprawdzenia warunków brzegowych i ogólnej analizy czego brak - po minucie mam gotowy brudnopis do pracy i zweryfikowania poszczególnych problemów, które są ładnie i sensownie wypisane.
Zaraz podeślę do starszych stażem analityków, żeby sprawdzili początkującego "kota" i dostarczą mi cennego feedbacku, który potem zostanie użyty do kolejnej sesji notebooka...
I tak to się ciężko pracuje w IT
Wrzuciłem wymaganie do sprawdzenia warunków brzegowych i ogólnej analizy czego brak - po minucie mam gotowy brudnopis do pracy i zweryfikowania poszczególnych problemów, które są ładnie i sensownie wypisane.
Zaraz podeślę do starszych stażem analityków, żeby sprawdzili początkującego "kota" i dostarczą mi cennego feedbacku, który potem zostanie użyty do kolejnej sesji notebooka...
I tak to się ciężko pracuje w IT
Drzewo
UFC Heavyweight
PS. Notebook LM to również ciekawe narzędzie do transferu dokumentów, bo dokumenty podpięte pod konkretny projekt są widoczne na innych urządzeniach, które się do tego projektu zalogują.
Wrzucałem Dokumenty z poziomu apki na telefonie, w firmie zalogowałem się na projekt z poziomu www i wszystkie docsy są dostępne, możliwe do pobrania. Niby nic, a cieszy.
Wrzucałem Dokumenty z poziomu apki na telefonie, w firmie zalogowałem się na projekt z poziomu www i wszystkie docsy są dostępne, możliwe do pobrania. Niby nic, a cieszy.
Drzewo
UFC Heavyweight
Widmo zwolnień w Krakowie. Nawet 800 osób może stracić pracę
Pracownicy Shell Business Operations w Krakowie obawiają się masowych zwolnień. Redukcja może objąć nawet 800 etatów. Rzeczniczka firmy, Katarzyna Cyran-Solarz, w odpowiedzi dla krnews.pl, podkreśla, że zmiany...
www.o2.pl
Heh, wcale nie AI...
Drzewo
UFC Heavyweight
NVIDIA inwestuje w ElevenLabs. Polsko-brytyjski startup doceniony przez giganta
NVIDIA inwestuje w polsko-brytyjski startup ElevenLabs, specjalizujący się w syntezie mowy opartej na AI. To krok wzmacniający współpracę technologiczną USA i Wielkiej Brytanii. Szef NVIDII, Jensen Huang, przyznał, że sam korzysta z rozwiązań firmy.
www.benchmark.pl
Ciekawe, ciekawe...
Drzewo
UFC Heavyweight
Tak sobie gadamy, ale jakie są zarobki w Polsce w AI?
Warto się uczyć?
Króciutko:
AI engineer: 21-29 tys. zł netto,
ML engineer: 21-28 tys. zł netto,
MLOps engineer: 24,5-28,5 tys. zł netto,
data scientist: 18,5-25 tys. zł netto.
www.pulshr.pl
Warto się uczyć?
Króciutko:
AI engineer: 21-29 tys. zł netto,
ML engineer: 21-28 tys. zł netto,
MLOps engineer: 24,5-28,5 tys. zł netto,
data scientist: 18,5-25 tys. zł netto.
To teraz topowa specjalizacja na rynku pracy. Zarobki sięgają 30 tys. zł na rękę | pulshr.pl
AI engineer, machine learning engineer i ai developer to najbardziej pożądane specjalizacje dotyczące sztucznej inteligencji - wynika z raportu Just Join IT. We wrześniu zanotowano w tym segmencie skokowy wzrost ofert pracy. Wysokość proponowanych zarobków kształtowała się do kilkunastu do 30...
www.pulshr.pl