RnD
zabezpieczenie wiedzy

Table of contents

• Wiedza
• Komunikacja
• Procesy wewnętrzne
• Procesy współpracy z klientem
• Brudnopis Luźne myśli  - Na etap sprzedaży
• Working with Synergy Codes – what happens after signing the contract?
• FAQ
• Operational Framework - konkurencja

RnD - Ogólna charakterystyka

Rnd składa się z 2 osobnych zespołów developerskich:

• Milky Way

• Pathfinder

Oraz zespołu product design:

• Hypernova

Każdy z zespołów developerskich posiada pełen zestaw kompetencji:

• Project Manager

• Business Analyst

• *Delivery lead/Principal

• Developerzy (wachlarz technologii i seniority)

Każdy zespół developerski ma 8-12 osób oraz prowadzi 2-5 projektów równocześnie.

Projekty są od kilkudniowych do kilku- kilkunastotygodniowych. Również zdarzają się dłuższe jednoosobowe współprace.

Rnd wspiera również proces sprzedażowy. DL, BA uczestniczą w spotkaniach discovery bądź technicznych, aby zrozumieć potrzeby leada i móc przygotować wycenę do oferty.
‍

W Rnd zdefiniowaliśmy grupę Rnd board, w skład której wchodzą:

• PM – Beata Szlachta

• PD PM – Joanna Pawłowska

• DL – Mateusz Jagodziński

Wiedza

Dokumentacja dotycząca leadów, wycen i karty projektów znajduje się na Sharepoincie New Business.
O zrealizowanych projektach można przeczytać na Confluence.

Komunikacja

Slack – bieżąca komunikacja:  

• rnd – cały zespół rnd & friends

• rd-planning – kanał dla Sales + PM + Rd board + CTO + COO

• rd-board – kanał dla grupy Rnd board

• zespol-rnd-NAZWAZESPOŁU – prywatny kanał zespołu

• lead-klient – kanał leadowy, który tworzy lead owner, skład: Sales + PM + Rnd board + CTO + COO

• klient – kanał projektowy wewnętrzny

• klient-ext – kanał projektowy z klientem

• *niektórzy klienci zamiast Slacka wybierają komunikację na Teamsie

Mail – raporty do klienta

Procesy wewnętrzne

1 - Puzelki czyli Resource management

Alokacja osób do projektów i inicjatyw odbywa się w Agileday. https://synergycodes.agileday.io/

2 - Planowanie Rnd-Sales

Kiedy:
W poniedziałki o godz. 9:30 odbywa się cotygodniowe planowanie Rnd-Sales.  
Czas trwania: 1h.

Uczestnicy:

• Rnd:
  – PM: Beata Szlachta
  – DL: Mateusz Jagodziński
  

• PD:
  ‍– PM: Joanna Pawłowska

• Sales:
  ‍– Maciej Teska

• COO:
  ‍– Aleksandra Bury

• CTO:
  ‍– Łukasz Jaźwa

Omawiane tematy:

• Bieżący status projektów i wypalonego budżetu Rnd i PD
  

• Obłożenie/Ławeczka osób w zespołach Rnd i PD
  

• Lejek sprzedażowy
  

• Planowane spotkania sprzedażowe z potrzebą wsparcia przez DL i BA
  

• Status przygotowania wycen
  

• Bieżący status projektów i wypalonego budżetu Rnd i PD
  

• Obłożenie/Ławeczka osób w zespołach Rnd i PD
  

• Lejek sprzedażowy
  

• Planowane spotkania sprzedażowe z potrzebą wsparcia przez DL i BA
  

• Status przygotowania wycen
  

3 - Rnd team weekly sync

Kiedy:
W poniedziałki o godz. 10:30 i 10:45 odbywają się cotygodniowe zespołowe weekly Rnd (każdy zespół osobno).  Dodatkowy “elektronowy sync” - odbywa się w czwartki. Jest to spotkanie jedynie dla “wolnych elektronów” (osoby w projektach jednoosobowych lub na ławeczce).
Czas trwania: 15 min.  

Uczestnicy:

• Poniedziałek - zespoły developerskie Rnd w swoim gronie
  

• Czwartek - osoby w projektach jednoosobowych lub na ławeczce z zespołów Rnd w swoim gronie zespołowym
  

Omawiane tematy:

• W jakim projekcie jestem?
  

• Co ciekawego w ostatnim tygodniu realizował_m?
  

• Nad czym będę pracował_ w tym tygodniu?
  

• Czy potrzebuje jakiegoś wsparcia?
  

• Update PM
  

4 - Rnd board

Kiedy:
W poniedziałki o godz. 11:00 odbywa się cotygodniowe spotkanie grupy Rnd board.  
Czas trwania: 30 min.

Uczestnicy:

• Rnd board
  

Omawiane tematy:

• Czy bieżące projekty potrzebują jakiegoś wsparcia międzyzespołowo, rd boarda lub dev<>des?
  

• Czy są jakieś obszary do optymalizacji?
  

• Omówienie statusu inicjatyw Rnd board
  

5 - DL-PM sync

Kiedy:
W ustalonym pomiędzy PM a DL slocie odbywa się cotygodniowy sync.  \
Czas trwania: 30 min.  

Uczestnicy:

• DL: Mateusz Jagodziński + PM: Beata Szlachta
  

Omawiane tematy:

• Projekty, które wymagają uwagi  
  

• Bieżące leady, wyceny
  

• Puzelki, plany projektowe
  

6 - Wyceny projektów developerskich

Opis potrzeb klienta przygotowuje BA we współpracy z DL po spotkaniach discovery z leadem. DL proponuje technologie i jakie skille będą potrzebne do realizacji tego projektu, tak aby PM mógł zaplanować zespół pod projekt.
Opis ballpark przygotowuje BA. Wycenę wizji przygotowuje DL.
Dokumenty trafiają do folderu danego leada/klienta na Sharepoint New business.

Standardowe narzuty

• *2,6 – typowy projekt bez dodatkowych ról 2*DEV+BA+PM
  

• *3,0 – projekt ze wszystkimi rolami: 2*DEV+DES+BA+QA+PM
  

• *2,0 – małe zlecenie bez procesu, BA, PM
  

Szablony opisu ballpark:

• ballpark description example.docx
  

• ballpark workflow editor features.docx
  

Wyceny przygotowujemy na Karcie wycen.
Wycenę przygotowuje DL, ze wsparciem BA oraz drugiego developera.  
PM weryfikuje narzuty i daje zielone światło sprzedaży do ofertowania.

7 - Przekazanie projektu z Sales do Delivery

Po podpisaniu kontraktu Sales przekazuje projekt do Delivery.

Przekazanie polega na:

• Uzupełnienie w CRM metryczki:
  - Opis projektu
  - Budżet godzinowy min i max
  - Stawka Oczekiwany start i deadline
  - Technologie Model współpracy (T&M, Fixed budget/team, Fixed price) i fakturowania
  - Osoba kontaktowa klienta podczas projektu
  - Inne specyficzne ustalenia
  

• Informacja na kanale #metryczki, że projekt przekazany
  

• Mail do osoby kontaktowej klienta DW PM o starcie projektu i przekazaniu do PMa komunikacji
  

8 - Role projektowe

Role w zespole

Role, które będą uczestniczyć w danym projekcie zależy od modelu współpracy, wielkości i potrzeb scopu.

• Project Manager (PM)‍
  

Odpowiada za ogólną koordynację projektu, zarządzanie budżetem, harmonogramem oraz raportowanie do klienta. Zapewnia regularne informacje na temat budżetu, statusu postępów i potencjalnych wyzwań. Bieżąca komunikacja operacyjna odbywa się jednak bezpośrednio między zespołem a klientem.

• Delivery Lead (DL)
  

Rola wspierająca koordynację projektu, odpowiedzialna za zapewnienie, że projekt toczy się bez przeszkód i zgodnie z oczekiwaniami klienta. Delivery Lead dba również o sprawne rozwiązywanie bieżących problemów i wspiera zespół w realizacji zadań. Często przejmuje rolę Scrum mastera.

• Business Analyst (BA)
  

Analityk biznesowy dba o to, aby backlog produktu był na bieżąco aktualizowany i zgodny z ustalonym zakresem. Podstawą jest zawarty kontrakt, jednak w razie zmieniających się potrzeb lub priorytetów możliwe są modyfikacje. Każda zmiana jest wówczas obsługiwana zgodnie z ustalonym procesem zarządzania zmianami, co zapewnia przejrzystość i obustronną zgodę. Jest właścicielem spotkań Refinement, gdzie priorytetyzuje zadania i omawia szczegóły funkcjonalności wspólnie z zespołem (i opcjonalnie klientem).

• Tech Lead (TL)
  

Odpowiada za techniczne aspekty projektu, zapewniając, że rozwiązania są zgodne z wymaganiami i najlepszymi praktykami. Współpracuje z klientem lub jego przedstawicielami technicznymi w celu ustalania szczegółów technicznych. Set-upuje projekt, konfigurując środowiska, narzędzia oraz architekturę techniczną, aby zespół mógł efektywnie rozpocząć pracę. Dba o wsparcie zespołu w rozwiązywaniu problemów technicznych i podejmowaniu kluczowych decyzji.

• Designer
  

Odpowiada za projektowanie interfejsu użytkownika i doświadczenia użytkownika (UI/UX). Tworzy makiety, prototypy i inne materiały graficzne, które wspierają realizację celów projektu.
Lead Designer - Ta rola jest definiowana, gdy w zespole pracuje więcej niż jeden designer. Lead Designer jest główną osobą odpowiedzialną za dostarczenie wszystkich designów do projektu i utrzymanie kontaktu z klientem w kwestiach projektowych.

• Developer
  

Realizuje zadania związane z implementacją funkcjonalności zgodnie z backlogiem i wymaganiami klienta. Współpracuje z zespołem w celu dostarczenia kodu wysokiej jakości zgodnego z przyjętymi standardami.

• *QA (Quality Assurance)
  

Odpowiada za manualne testowanie funkcjonalności dostarczanych przez zespół. Dba o wykrywanie błędów i zapewnienie, że produkt spełnia wymagania jakościowe.

• Scrum Master (Daily/Planning/Demo)
  

Prowadzi spotkania daily, planning i demo. Dba o to, aby zespół efektywnie planował i realizował sprinty, a klient był na bieżąco z postępami projektu (mając dostęp do backlogu w Jirze). Tą rolę może przyjąć dowolna osoba w zespole.

• Owner Retrospective
  

Odpowiada za organizację i przeprowadzenie spotkań retrospektywnych, post-mortem. Pomaga zespołowi identyfikować obszary do poprawy i zdefiniować działania usprawniające pracę w kolejnych projektach. Tą rolę może przyjąć dowolna osoba w zespole.

Wspólne obowiązki

Standardowe narzuty

• Odpowiedzialność za sukces projektu
  Każdy członek zespołu ma wpływ na sukces projektu. Oznacza to proaktywne podejście do rozwiązywania problemów, zgłaszania ryzyk, wspierania innych członków zespołu i dbania o jakość dostarczanych rezultatów.
  

• Teamwork i komunikacja
  Współpraca i otwarta komunikacja są kluczowe. Każdy jest zobowiązany do dzielenia się informacjami, które mogą być istotne dla zespołu, oraz do wspierania kolegów w trudnych sytuacjach.
  

• Dbanie o przestrzeganie ustalonego scope'u projektu
  Wszyscy członkowie zespołu powinni być czujni na zmiany w zakresie projektu i raportować je do odpowiednich osób (np. BA). Ważne jest, aby jasno komunikować klientowi, jeśli wprowadzane zmiany wykraczają poza pierwotne ustalenia.
  

• Proaktywność w zgłaszaniu problemów i ryzyk
  Każdy członek zespołu jest odpowiedzialny za identyfikację potencjalnych problemów lub ryzyk w swoim obszarze pracy i zgłoszenie ich na odpowiednich spotkaniach lub bezpośrednio do PM/BA.
  

• Zrozumienie celu projektu
  Wszyscy powinni mieć pełne zrozumienie celu projektu i wartości dostarczanej klientowi, co pozwoli na podejmowanie lepszych decyzji w trakcie realizacji zadań.
  

• Dbanie o jakość
  Niezależnie od roli, każdy członek zespołu powinien dążyć do dostarczania pracy o jak najwyższej jakości, zarówno w aspekcie technicznym, jak i w komunikacji z klientem.
  

• Szacunek i wspieranie atmosfery współpracy
  W zespole ważna jest kultura wzajemnego szacunku i wspierania atmosfery współpracy. Konflikty powinny być rozwiązywane konstruktywnie, z poszanowaniem różnych perspektyw.
  

• Odpowiedzialność za własny rozwój i naukę
  Każdy członek zespołu powinien być otwarty na feedback i dążyć do rozwijania swoich umiejętności, co przyczynia się zarówno do indywidualnego sukcesu, jak i sukcesu projektu.
  

9 - Rutyny w Jirze
(? Czy tylko w Jirze? Do ustalenia, w zaleznosci od tego jak nam ta lista urośnie)

Do opisania:

• Set up projektu w Jirze
  

• Account per kontrakt
  

• Import tasków do Jiry
  

• Podział epików, tasków, subtasków (zgodność z kontraktem w celu raportowania)
  

• Workflow w Jira i sugerowane kolumny w Active sprint
  

• Backlog – ustawienia, zasady pracy (priorytety..)
  

• Aktualizacja pól – status, Remaining hours
  

• Standard description taska, buga
  

• Standard dokumentacji poprojektowej (techniczna dla klienta i wewnetrzna dla nas)
  

Procesy współpracy z klientem

10 - Project staging - Przygotowanie startu projektu

Przygotowanie do startu projektu wymaga następujących kroków:

• Ustalenie składu zespołu

• Mail do klienta w odpowiedzi na maila przekazującego projekt

• Utworzenie kanału #klient

• *Utworzenie kanału #klient-ext (do ustalenia na kick off z PMa z klientem czy slack czy Teams)

• Utworzenie Account w Tempo

• Utworzenie projektu w Jira, podpięcie Accounta jako domyślny

• Import tasków do Jiry lub BA tworzy backlog

• Podział tasków na sprinty wraz z BA/tech leadem (tworzenie roadmapy)

• Utworzenie karty projektu (szablon)

• Zaplanowanie kick-offu wewnętrznego oraz z klientem

11 - Project staging - Kick off projektu PMa z klientem

Celem spotkania kick-offowego jest zbudowanie wspólnego rozumienia projektu i ustalenie zasad współpracy. To pierwszy krok do sprawnego zarządzania projektem – umożliwia doprecyzowanie oczekiwań, potwierdzenie założeń, wyłapanie potencjalnych ryzyk oraz zaplanowanie komunikacji i sposobu pracy. Dobrze przeprowadzone spotkanie kick-offowe zwiększa szanse na bezproblemowy start i efektywną realizację projektu.

Kiedy:
W pierwszy dzień startu projektu lub przed.
Czas trwania: 30 min.  

Uczestnicy:

• PM
  

• PM/Osoba kontaktowa ze strony klienta
  

Omawiane tematy:

• Przedstawienie procesu delivery (bardziej szczegółowo niż w fazie sprzedażowej)
  - Zależności i blokery – czy coś po stronie klienta może wpłynąć na naszą pracę? Czy są inne zespoły, od których zależymy? Np. Gdy backend niegotowy, to my działamy z mockowym api i to kosztuje (czas na przygotowanie i potem na rework gdy przyjdzie własciwe api).
  - Integracja z procesami klienta – czy dołączamy do spotkań/rytuałów klienta?
  

• Timeline – kiedy start zaangażowania zespołu, od kiedy liczymy godzinki
  

• Budżet – potwierdzenie zakresu, założeń i ewentualnych ograniczeń.
  

• Raportowanie – ustalenie formy, częstotliwości, adresatów.
  

• Spotkania cykliczne – ustalenie slotów, składów, częstotliwości (np. statusy, sprint plany, review, PM:PM sync).
  

• Scope projektu – potwierdzenie co wchodzi, a co nie.
  

• Zarządzanie zmianą – co robimy, gdy pojawiają się nowe potrzeby lub feedback na demo:
  - feedback trafia do backlogu,
  - realizujemy po podstawowym scope lub zastępujemy istniejące taski,
  - możliwe zwiększenie budżetu lub przesunięcie priorytetów,
  - Definicja zmiany – np. zmiany >4h lub przekraczające X% budżetu wymagają akceptacji klienta; mniejsze zmiany bierzemy automatycznie do Xh.
  

• Zespół projektowy – przedstawienie składu, ról, wskazanie ewentualnych ról których nie ma (np. QA, BA).
  

• Ustalenia techniczne – narzędzia: Jira, repozytorium, deployment, dostęp do środowisk, komunikacja (Slack / Teams).
  

• Ustawienie spotkania Meet the team & present expectations – umawiamy spotkanie, na którym zespoły się poznają i klient dzieli się swoimi oczekiwaniami.
  

12 - Przekazanie wiedzy merytorycznej o scopie projektu

13 - Kick off - wewnętrzny

Spotkanie kick-off wewnętrzny projektu ma na celu zebranie całego zespołu projektowego po raz pierwszy. Kick-off wewnętrzny pozwala zespołowi na ujednolicenie wiedzy, zrozumienie kontekstu projektu i jego celu, ustanowienie ról i odpowiedzialności. Dodatkowo, jest to okazja do budowania relacji w zespole i zadawania pytań, które mogą wyjaśnić wątpliwości na starcie.

Kiedy:
W pierwszy dzień startu projektu lub w najbliższej okolicy.
Czas trwania: 1 h.  

Uczestnicy:

• Cały zespół projektowy wewnętrzny

Omawiane tematy:

• Zrozumieć ramy projektu:
  - Kim jest klient – Delivery lead/BA
  - Cel aplikacji i założona technologia – Delivery lead/BA
  - Harmonogram i terminy – PM
  - Budżet i ograniczenia – PM
  - Wszelkie inne istotne ustalenia lub wytyczne od klienta. – PM

• Omówić szczegóły organizacyjne projektu – PM
  - Długość sprintu
  - Planowane timesloty na spotkania

• Podzielić role i odpowiedzialności – PM
  - Przedstawiamy role projektowe i ich zakres odpowiedzialności, aby każdy członek zespołu miał jasność co do swojej roli oraz współpracy z innymi.

• Omówić wymagania biznesowe – Delivery lead/BA
  - DL lub BA przedstawiają założenia biznesowe projektu, cele klienta. Komplet wymagań przedstawiany jest na osobnym spotkaniu zorganizowanym przez BA, aby zespół techniczny miał pełne zrozumienie zakresu.

• Zidentyfikowanie ryzyk i wyzwań – cały zespół  
  - Zebranie ryzyk, możliwości ich mitygacji i przedstawienia klientowi.

• Wyznaczyć najbliższe kroki
  - Ustalane są pierwsze działania, priorytety i plan na pierwsze tygodnie pracy, aby projekt mógł płynnie wystartować.

14 - Kick off - Meet the team & present expectations

Klient zapoznaje się z zespołem oraz przedstawia ze swojej perspektywy cel projektu, co chce osiągnąć, nad czym po swojej stronie pracuje.
‍Wartość spotkania:
‍Spotkanie Meet the team & present expectations z klientem buduje fundamenty współpracy. Zapewnia obu stronom jasność co do celu i oczekiwań oraz pozwala na szybkie rozpoczęcie pracy w oparciu o wspólne ustalenia. Jest to także okazja do budowania relacji i wzmacniania zaufania między PMami ze strony SC a PMem ze strony klienta.

Kiedy:
W pierwszy dzień startu projektu lub przed.  
Czas trwania: 30 min.  

Uczestnicy:

• Cały zespół projektowy wewnętrzny

• PM/Osoba kontaktowa ze strony klienta i dodatkowe osoby wyznaczone przez klienta

Omawiane tematy:

• Cel spotkania – PM
  - Celem dzisiejszego spotkania jest wspólne zrozumienie celów i założeń projektu oraz zapoznanie członków i ról w zespole

• Cel i priorytety projektu – prezentacja klienta

• Zaprezentowanie zespołu projektowego – PM i Klient
  - Przedstawienie członków zespołu, ich ról.

• Założenia, kamienie milowe, timeline – PM
  - Przedstawienie harmonogramu projektu, kluczowych kamieni milowych.

• Zakres projektu i wstępne wymagania – BA + DL
  - Pogłębienie wiedzy o wymaganiach klienta, omówienie wymagań biznesowych i technicznych.
  - Wyjaśnienie ewentualnych niejasności oraz zebranie dodatkowych informacji.
  - Jeżeli scope wymaga dalszych doprecyzowań, BA informuje Klienta, że będzie potrzebował dodatkowych spotkań.
  - *Jeżeli pojawią się rozbieżności w rozumieniu celu, zakresu projektu, zespół spotyka się wewnętrznie po spotkaniu z klientem, aby omówić temat i podjąć odpowiednie działania.

• Omówienie sposobu pracy (proces dostarczania, raportowania, zarządzania zmianami) – PM

• Kanały komunikacji, punkty kontaktowe – PM

• Ryzyka i wyzwania projektowe – PM

• Wnioski / następne kroki (np. potrzebne warsztaty, spotkania doprecyzowujące) – BA / PM

15 - Modele współpracy

Typ 1: Dostarczenie produktu zgodnie z ustalonym scopem

Zdefiniowany zakres, timeline i proces po stronie Synergy Codes.
👉 np. Kuberno, Zeenea, Aera, Klea, TVO

• Zespół: Zdefiniowany zespół lub dostosowywany w ramach ustalonego capacity/budżetu lub timeline i w zależności od potrzeb projektu (*i ławeczki).
  Role:  
  - PM
  - opcjonalnie DL
  - Developerzy
  - BA (w wyjątkowych sytuacjach bez tej roli) gdy zakres tego wymaga to Designer.

• Scope: zdefiniowany przed startem lub doprecyzowany na początku projektu
  - Design od klienta lub dostarczony przez nas we wcześniejszej fazie

• Budżet: zgodnie z kontraktem (T&M, T&M z max budżetem, Fixed price)

• Proces: Scrum prowadzony po naszej stronie, klient uczestniczy w demo
  - Iteracje 1–2 tyg. w zależności od wielkości aplikacji i chęci zaangażowania klienta
  - Planning, refinement, estymacje, capacity, risk management
  - Codzienne daily wewnętrzne
  - Demo z klientem efektów pracy zakończonego sprintu i plan na kolejny sprint

• Narzędzia:  
  - Backlog najczęściej w naszej Jirze, dostęp dla klienta
  - Repozytorium najczęściej po naszej stronie
  - Komunikacja - kanał Slack lub Teams

• Project management: niezbędny, owner procesu, scope’u i budżetu, w roli raportującej i weryfikującej status wykonania kontraktu, zadbanie o płynność współpracy.
  - Status i feedback z PM: PM sync z klientem co 2 tyg. (lub w innej ustalonej cykliczności)
  - Raportowanie: raportowania cykliczne i miesięczne statusu i budżetu projektu

Typ 2: Stały zespół zmienny scope

Stały dedykowany zespół, długoterminowy budżet, elastyczny zakres
👉 np. Fluence, Logicnets, Beck

• Zespół: Stały dedykowany zespół.
  Role:  
  - PM
  - opcjonalnie DL
  - Developerzy
  - BA (w wyjątkowych sytuacjach bez tej roli) gdy zakres tego wymaga to Designer.

• Scope: definiowany przez klienta (nie musi być precyzyjnie określony, może się zmieniać, definiować na bieżąco), priorytety ustalane wspólnie, reagujemy na bieżące potrzeby

• Budżet: Ustalony miesięczny budżet (np. na 3–6 miesięcy)

• Proces:  
  - Bi-weekly / Daily (lub inna uzgodniona częstotliwość) zespołu z klientem
  - Opcjonalnie proces Scrum prowadzony po naszej stronie, dostosowany do potrzeb klienta
  - Opcjonalnie sync wewnętrzny cotygodniowy

• Narzędzia:  
  Jeśli klient nie ustali inaczej, narzędzia wewnętrzne

• Project management: wsparcie w koordynacji, płynność realizacji, punkt kontaktowy dla klienta w sprawach kontraktu, zadbanie o płynność współpracy.
  - Status i feedback z PM: opcjonalnie
  - Raportowanie: comiesięczne realizacji budżetu, opcjonalnie inna ustalona częstotliwość.

Typ 3: Dev Consulting

👉 np. Hymdl, Netwelve, Transactionlink, Reasonmap
Konsultant realizujący konkretne zlecenie dla klienta bez wsparcia ról dodatkowych, zwykle zlecenie nie większe niż 40-80h.

• Zespół: Zdefiniowany ekspert lub eksperci.
  Role:  
  - Developer
  - PM w roli raportującej

• Scope: i priorytety zdefiniowane przez klienta.

• Budżet: zgodnie z kontraktem (T&M, T&M z max budżetem)

• Proces:  
  - Ekspert realizuje zlecenie wg ustalonych priorytetów przez klienta – Kanban
  - Pracuje bezpośrednio z klientem
  - Brak ról wspierających
  - Opcjonalnie sync wewnętrzny (nie częściej niż 1x na tydzień)  

• Narzędzia:  
  wewnętrzna Jira, ustalone z klientem repozytorium

• Project management: PM ze strony Synergy Codes w roli raportującej i weryfikującej status wykonania zlecenia, zadbanie o płynność realizacji, punkt kontaktowy dla klienta w sprawach kontraktu.
  - Status i feedback z PM: brak
  - Raportowanie: raport po zakończeniu prac.

Typ 4: Team augumentation

Zespół dołączająca do procesu klienta, zespół koordynowany jest przez klienta.
👉 np. Fluence, Druid, Composabl, Reasonmap, Knowis

• Zespół: Zdefiniowana osoba lub zespół.
  Role:  
  - Uzgodnione role eksperckie: Developer, Designer, BA
  - PM w roli raportującej

• Scope: i priorytety zdefiniowane przez klienta.

• Budżet: miesięczny określony (np. 1 FTE)

• Proces:  
  - Pracujemy w procesie klienta  
  - Opcjonalnie sync wewnętrzny (nie częściej niż 1x na tydzień)  

• Narzędzia:  
  Ustalone przez klienta backlog i repozytorium

• Project management: po stronie klienta. PM ze strony Synergy Codes w roli raportującej, punkt kontaktowy dla klienta w sprawach kontraktu.
  - Status i feedback z PM: brak
  - Raportowanie: miesięczne raportowanie wykorzystania budżetu

16 - Proces dla modelu Typ 1 – Dostarczenie produkty zgodnie z ustalonym scopem

Pracujemy w oparciu o framework Scrum, który zapewnia strukturę wraz z przejrzystością, iteracyjnością i elastycznością w dostarczaniu wartości dla klienta.

Scrum to zwinna metodyka zarządzania projektami, która przynosi klientowi realne korzyści już od pierwszych etapów współpracy. Dzięki podziałowi pracy na krótkie iteracje (sprinty) klient regularnie otrzymuje działające fragmenty produktu i ma możliwość bieżącego wglądu w postępy oraz wykorzystanie budżetu. Cykliczne demo oraz bliska współpraca z zespołem pozwalają na szybkie reagowanie na feedbacki i doprecyzowanie wymagań, co zwiększa szansę na to, że końcowy produkt rzeczywiście odpowiada na potrzeby biznesowe.  

Scrum – elastyczność, przejrzystość i wspólna odpowiedzialność za produkt

W podejściu Scrum punktem wyjścia jest jasno określona potrzeba biznesowa oraz cel produktu. Jeśli zakres funkcjonalny jest już dobrze zdefiniowany – na przykład po fazie Product Design – pracujemy zgodnie z ustalonym planem, realizując kolejne funkcjonalności w ramach sprintów. Jednocześnie zachowujemy przestrzeń na doprecyzowanie szczegółów, reagowanie na feedback oraz – jeśli zajdzie taka potrzeba – dogrywanie drobnych zmian. Dzięki temu proces pozostaje iteracyjny i elastyczny, ale bez utraty kontroli nad zakresem, budżetem i jakością.
Ten model pracy zapewnia:

• szybki start projektu – prace mogą rozpocząć się niemal natychmiast, bez potrzeby wielomiesięcznego przygotowania,

• przyrostowe rezultaty widoczne już po pierwszym sprincie,

• elastyczność i możliwość redefiniowania priorytetów na bieżąco,

• ciągłe doskonalenie i adaptację – zespół nie tylko buduje produkt, ale też go rozwija, reagując na nowe potrzeby.

Time & Material jako model współpracy

Standardem w pracy Scrumowej jest model Time & Material, który naturalnie wspiera zwinność, możliwość częstego feedbacku oraz dynamiczne dostosowywanie zakresu.
To oznacza, że:

• klient płaci za realnie wykonaną pracę, zgodnie z ustalonymi stawkami i czasem zaangażowania zespołu,

• wszystkie działania – w tym rundy feedbackowe, poprawki czy uzupełnianie funkcjonalności – są częścią tej współpracy, ponieważ wspólnie tworzymy i doskonalimy produkt w procesie.

Możemy również uzgodnić tzw. budżetowy cap, czyli punkt kontrolny, po którego osiągnięciu wspólnie podejmujemy decyzję, czy kontynuujemy, czy finalizujemy prace.

Kontrast: Waterfall – nieelastyczny i ryzykowny

Dla kontrastu warto wspomnieć o klasycznym podejściu Waterfall, w którym:

• projekt rozpoczyna się od długiej, często trwającej 20–30% całego czasu projektu, fazy analizy i planowania,

• zakres, budżet i harmonogram są sztywno określone na początku,

• nie przewiduje się elastycznych zmian w trakcie – cały produkt powstaje „na raz” i dopiero na końcu prezentowany jest klientowi.

Taki model nie daje przestrzeni na iteracyjny rozwój, feedback ani adaptację. Z tego względu coraz rzadziej jest stosowany w projektach IT i nie jest rekomendowanym sposobem współpracy przy tworzeniu nowoczesnych produktów cyfrowych.
Nasz proces obejmuje:

Iteracje - Sprinty

• Sprint, czyli cykl pracy trwa 1 tydzień lub 2 tygodnie.

• W ramach każdego sprintu koncentrujemy się na zdefiniowanym scopie, aby iteracyjnie dostarczyć fragment funkcjonalności.

• Na koniec sprintu prezentujemy wyniki na spotkaniu Demo, gdzie klient ma możliwość zobaczenia postępów oraz przekazania feedbacku. Spotkania Scrumowe

Spotkania Scrumowe

Daily projektowe (wewnętrzne)

Kiedy:
Codzienne poranne 15-minutowe spotkanie, termin ustalany na kick offie wewnętrznym z zespołem, podczas którego zespół synchronizuje postępy, identyfikuje przeszkody i planuje działania na bieżący dzień. Częstotliwość może być dostosowywana.   

Uczestnicy:

• Cały team projektowy Synergy Codes

• *DL/PM

Omawiane tematy:

• Czym zajmował_m się poprzedniego dnia?

• Czym planuję zająć się dzisiaj?

• Czy mam jakieś przeszkody, potrzebuję czyjegoś wsparcia?

Refinement i Sprint Planning

Refinement najczęściej realizowany na koniec poprzedniego sprintu. Refinement kończymy planowaniem. Ownerem spotkania jest BA i na spotkaniu zespół wspólnie z BA doprecyzowuje wymagania, omawia szczegóły zadań, wycenia i przygotowuje backlog na kolejnesprinty.
W drugiej części spotkania odbywa się planowanie zadań na nadchodzący sprint, biorąc pod uwagę capacity.
W razie potrzeby BA organizuje dodatkowe spotkanie refinementowe.

Kiedy:
Ostatni dzień sprintu.
Czas trwania: 1 – 1,5 h.  

Uczestnicy:

• Cały team projektowy Synergy Codes

• *DL/PM

Omawiane tematy:

• Doprecyzowanie wymagań – zespół i BA wspólnie analizują zadania z backlogu, wyjaśniają kontekst, zakres i oczekiwania biznesowe.

• Omówienie zadań pod kątem technicznym – identyfikacja potencjalnych wyzwań, zależności i wstępna analiza rozwiązania.

• Szacowanie zadań – estymacje (np. story points) dla zadań kwalifikujących się do sprintu.

• Priorytetyzacja backlogu – ustalenie kolejności realizacji zadań zgodnie z wartością biznesową i zależnościami.

• Planowanie sprintu – wybór zadań do realizacji w nadchodzącym sprincie, uwzględniając dostępność zespołu (capacity).

• Zdefiniowanie celu sprintu – wspólne określenie, jaki cel sprintu zespół planuje osiągnąć.

• Ustalenie potencjalnych blokad lub ryzyk – identyfikacja elementów mogących utrudnić realizację zadań.

• Ewentualne potrzeby dotyczące dodatkowego refinementu – jeśli rozwiązania nie są wystarczająco omówione, BA planuje osobne spotkania.

Demo

Demo, to spotkanie podsumowujące zakończony sprint, podczas którego zespół prezentuje klientowi efekty swojej pracy. Spotkanie służy nie tylko pokazaniu ukończonych funkcjonalności, ale również zebraniu feedbacku, który może wpłynąć na dalszy rozwój produktu. To okazja do wspólnej refleksji nad tym, czy dostarczone elementy spełniają oczekiwania biznesowe i czy kierunek rozwoju jest właściwy.

Kiedy:
Na zakończenie sprintu, zazwyczaj w ostatni dzień sprintu.
Czas trwania: 0,5 – 1 h.  

Uczestnicy:

• Cały team projektowy Synergy Codes

• Klient/Product Owner po stronie klienta oraz interesariusze z zespołu klienta

• DL/PM

Omawiane tematy:

• Prezentacja ukończonych zadań – pokazanie działających funkcjonalności zrealizowanych w danym sprincie.

• Feedback od klienta – otwarta dyskusja, komentarze, uwagi do zaprezentowanych funkcji.

• Zmiany w backlogu – ewentualne modyfikacje priorytetów lub dodanie nowych elementów na podstawie otrzymanego feedbacku. *change requesty będą realizowane zgodnie z uzgodnionym procesem z klientem.

• Plan na kolejny sprint – zapowiedź kierunku dalszych działań, jeśli to możliwe.

Backlog Produktu

• Zarządzany w Jira przez Business Analityka (BA), który zapewnia, że opis rozwiązania są jasne, szczegółowe i zgodne z oczekiwaniami klienta.

• Regularne Refinementy zapewniają aktualność backlogu i odpowiednie przygotowanie zadań do sprintów.

Transparentność i komunikacja

• Bieżący status postępów – Jira jest źródłem prawdy; wszystkie zadania, ich status i postęp są na bieżąco aktualizowane i widoczne dla wszystkich interesariuszy.

• Bezpośrednia i otwarta komunikacja – odbywa się poprzez Jira (komentarze, tagowanie), spotkania synchronizacyjne oraz dedykowany kanał komunikacyjny (Slack lub Teams).

• Regularne raportowanie wykorzystania budżetu – klient otrzymuje cykliczne zestawienia (według ustalonego cyklu – co sprint lub miesięczne), zawierające informacje o wykorzystanych godzinach, pozostałym budżecie.  

Dzięki temu procesowi dostarczamy wartość w sposób przewidywalny, przy jednoczesnym zachowaniu elastyczności w dostosowywaniu się do zmieniających się potrzeb.

17 - Raportowanie

Raport sprintowy (operacyjny, dla kontroli postępu i budżetu w czasie rzeczywistym)

Cel: informowanie klienta o zużyciu budżetu w krótkich cyklach, ułatwiające bieżące decyzje.

Zakres informacji:

• Zakres realizowany w sprincie – zrealizowane cele sprintu, odwołanie do Jiry

• Zużycie godzin w sprincie

• Łączne zużycie budżetu od początku projektu

• Pozostały budżet godzin

• Prognozy – przy obecnym tempie zostało X sprintów do wyczerpania budżetu.

• Komentarz PM-a – np. obserwacje dot. tempa, ryzyk, wąskich gardeł.

Raport miesięczny (formalny, rozliczeniowy, pod fakturę)

Cel: zestawienie godzin zrealizowanych w danym miesiącu w celu wystawienia faktury.

Zakres informacji:

• Łączna liczba przepracowanych godzin w miesiącu, z podziałem na:
  - Typy prac (development, design lub inne, jeśli typy prac/ról mają różne stawki)
  - * Jeżeli z klientem (na kick off z PM) ustalone zostaną inne dane szczegółowe, mogą być dodatkowe podziały na, np. Osoby, Zestawienie zadań (Jira)

• Łączne zużycie budżetu od początku projektu i zużyty % budżetu

• Pozostały budżet godzin

• Podsumowanie (krótki komentarz) – co udało się zrealizować, ewentualne ryzyka, odchylenia.

Brudnopis Luźne myśli  - Na etap sprzedaży

• NIE DOŁĄCZAć EXCELA ze szczegolowymi wycenami DO SOWa, bo staje sie to twardym commitmentem i fixed scopem i max budzetem. Robi to również wrazenie, ze już bardzo dokładnie przeanalizowaliśmy jego potrzeby i nie ma wiec ryzyka ze się rozjedziemy i naszą estymacje traktuje jak twardy commitment, fixed price. Nie rozumie tez tego, że...  

• „Drogi Kliencie, teraz przygotowaliśmy wysokopoziomową wycenę i koncepcję rozwiązania jakiego potrzebujesz. Jesli rozpoczniemy współpracę, kolejne kroki wygladaja tak i tak, proces delivery… doprecyzowanie scopu vs budget/estymacja, reestymacja.”

• T&M Wytlumaczyc ze w trakcie developmentu jest dużo zmiennych, niepewności i może scope, budżet się zmienić.  

• Przestoje przy dedykowanym zespole sa płatne

• Bug fixing przy T&M jest płatny, jest to czesc procesu  

• Jeśli chcesz staly budżet i scope, to cena +25%

• FAQ dla leadów:
  ‍https://synergiapro-my.sharepoint.com/:w:/g/personal/katarzyna_czerw_synergycodes_com/EWYrOIjlvgpLpZKnCoC_o0YBlQ9h3xSxY0FfRtb-mWy0Iw?e=7hYAhc:

🤝 Working with Synergy Codes – what happens after signing the contract?

1 - Collaboration models – flexibly tailored to your needs

We offer different collaboration models tailored to the nature, scale, and ownership level of your project. All models are based on mutual trust, transparency, and high-quality delivery.

2 - Team roles – what to expect?

Depending on the chosen collaboration model, different roles may be involved. Not all roles are present in every setup – we adjust based on project needs and complexity.

Roles we engage in the process:

• Project Manager (PM): Coordinates the team, manages budget and timeline, handles reporting and communication with the client.

• Business Analyst (BA): Gathers requirements , defines solutions (often in collaboration with the Designer), leads refinements, documents expectations, ensures the solution meets business needs.

• Tech Lead (TL): Oversees the technical vision and architecture, supports developers, and also actively contributes as a senior developer.

• Developer: Implements functionality, ensures code quality.

• Product Designer: Creates UX/UI, prototypes and visual concepts.

3 - How we kick things off

✅ Once the contract is signed:

• We assemble a team tailored to your project.

• We align on communication channels (Slack, Teams).

• We set up your project in Jira, code repository, and access to environments.

• We run a series of onboarding meetings:
  - PM Kick-off with client – setting collaboration rules, reporting cadence, and change management.
  - Internal team kick-off – the team learns about the project, roles, and responsibilities.
  - Meet the Team & Expectations – you meet the team and share your goals and priorities.

4 - Collaboration when we manage the project

This is our standard model for product-focused projects. We work in the Scrum framework:

• 🟢 We begin development on day one.

• 🔁 Work is delivered in 1–2 week sprints.

• 📋 Refinement and planning happen at the beginning of each sprint. Separate BA–client sessions to clarify specific solution details, if needed.

• 🎯 We hold demo sessions with you – presenting completed features and gathering feedback.

• 🗂️ Full transparency – Jira backlog, progress tracking.

• 🔄 Flexibility – changes and new ideas are added to the backlog and prioritized together.

💡 We believe in partnership – your ongoing involvement (e.g. feedback during demos or helping set priorities) plays a key role in building the right solution.

5 - Billing models explained

We use different billing models depending on the collaboration type:

• Time & Material (T&M): Standard for Model 1 and Model 3. You pay for the actual time spent. This allows for flexibility, iteration, and scope evolution. We can also agree on a budget cap as a control mechanism. Best suited for projects where requirements may change or arenot fully defined at the start.

• Fixed Price: Option for Model 1. You pay a set price for the agreed scope of work. This model provides full cost predictability. Ideal when project requirements are well-defined. Less flexibility during the project—any change in scope requires renegotiation.

• Fixed Monthly Budget: Standard for Model 2 and Model 4. You pay a flat rate for a defined team over a fixed duration. This allows for predictable costs and dedicated capacity planning.

6 - Reporting – full transparency

• Sprint Report (every 1–2 weeks):
  - Progress update, completed features,
  - Budget usage.

• Monthly (billing) Report:
  - Hours logged per role/type of work, used and remaining budget, followed by invoicing per contract terms.

Jak to opisuje konkurencja w ofercie:

Operational Framework  

Roles and Responsibilities

• Agency Engineers (2)  
  - UI/UX Engineer to design and build user  interface  
  - Frontend Engineer to implement state  management, data fetching and  interactive elements  Execute assigned tasks, provide technical  expertise, and communicate progress.  

• Client Project Manager
  - assign tasks, monitor progress, provide  feedback to the agency engineer.  

• Client Internal Team Collaborate with the agency engineer
  - provide  necessary resources and information.  

• Agency Representative
  - manage contracts, handle administrative tasks,  facilitate communication as needed.

Communication Plan

• Weekly progress report: Friday  

• On-Demand Meetings as required to check in or clarify requirements  

• Availability with 4h overlap to GMT+2

• Communication channel: [Platform e.g., Slack, Microsoft Teams]

Task Management

• Use [Tool e.g. Jira, Linear] to track tasks, assignments, and progress.

• Clear task definitions and acceptance criteria.

Onboarding Process

• Provide access to necessary systems and documentation.

• Introduction to the API schema to be integrated.  

• Clear explanation of project goals and requirements.  

Implementation

• Spec Review & Tech Stack & AI Rule  Setup & CI/CD Setup  

• API & Realtime Integration  

• Websocket Integration

• Design System Integration  

• UI Components  

• UX/Data flow Integration  

• Functionality & User flow  

• Performance & Quality Refinements  

Project Management and QA  (Manual/Automated) are included.

Post-delivery support includes 2 weeks of  bug fixing. Additional support and feature  changes are available via hourly billing or a  support retainer

Assumptions and Exclusions  

This proposal is based on the following:

• Assumptions:
  - Backend APIs will be fully documented and available at the start of the development  phase.
  - The client will provide Corporate Identity Guidelines for the UI design phase.
  - Feedback during the design phase will be provided within 2-3 business days to  maintain the timeline.  

• Exclusions:
  - Backend API development and maintenance.
  - Auto-save functionality.
  - Concurrent multi-user collaboration features.
  - Advanced mobile responsiveness beyond ensuring usability on standard laptop  screens.
  - Hosting and deployment of the application.

Confirmation of Requirements

• Timezone: I confirm my availability to work within ±2 hours of UK time (GMT/BST).

• Availability: I am available to begin the Product Design Phase immediately upon  agreement.

Confirmation of Requirements

• Backend
  - Azure Functions for AI image/PDF processing
  - Azure OpenAI / Cognitive Services to extract people, relationships, metadata
  - Store and structure extracted data as JSON
  - Interface with existing .NET backend via secure APIs  

• Frontend
  - Angular 18+ as requested
  - Diagram rendering via D3.js or optional GoJS if needed for advanced layout  
  - Clickable/editable nodes, relationship linking, read-only and edit modes
  - Save/load with JSON structure through backend API

Team & Roles  

We assign a compact, senior-level team:

• Role Time Involvement

• Senior Full-Stack Engineer (Angular, .NET) Full-time, 3 months

• UI/UX Designer ~1.5 months full-time equivalent

• Project Manager (recommended) 0.25 FTE throughout project  

• Senior QA Engineer (recommended) 0.5 FTE during last 2 months  

Timeline

• Phase Duration Notes

• UX & UI Design ~6 weeks Includes 2 feedback rounds  

• Backend Implementation 4 weeks Azure Functions, .NET APIs  

• Frontend Implementation 9 weeks Angular UI, diagram logic  

• Stabilization & QA 1 week Bug fixes and final adjustments  

All phases are included within the expected 3-month duration

Pricing Model

We propose a Time & Material engagement based on actual time worked.
Core Team (Requested)
‍Role Rate (USD/hr) Est. Hours Est. Cost
Senior Full-Stack Engineer $43/hr ~480 hrs (3 months) xxxUSD
UI/UX Designer $50/hr ~240 hrs (1.5 months) xxxUSD
Subtotal - Core Team xxxUSD

Optional (Recommended for Production-Grade Delivery)  
To ensure coordination, timely delivery, and a stable, well-tested product, we strongly recommend  
including:  
Role Rate (USD/hr) FTE Duration Est. Hours Est. Cost  
Project Manager $35/hr 0.25 FTE 3 months ~120 hrs xxxUSD QA Engineer $35/hr 0.5 FTE last 2 months ~160 hrs xxxUSD  
Subtotal - Optional xxxUSD  
QA involvement is critical to ensuring a production-ready, stable, and fully tested result. By focusing  
QA work on the final two months, we strike a balance between quality and cost-efficiency.

Total Budget Overview
‍Scope Estimated Cost  
Core Team Only xxxUSD  
With PM + QA (Recommended) xxxUSD  
All figures are non-binding and for planning purposes. Final billing will reflect actual tracked hours.

Pricing Model

Assumptions

• API documentation, branding assets, and sample diagrams will be provided

• Client approves UX/UI within 2 rounds of feedback  

• ELITEX will work within Client's Azure cloud environment  

Risks & Mitigations

• AI extraction quality from varied PDFs/images Prototype AI flow early with samples

• Diagram layout performance (large families) Use virtual rendering & layout optimization

• UI feedback cycles longer than planned Time & Material model allows flexible adaptation