Fractional CTO i CTO as a service

Osoba odpowiedzialna za technologię w firmie może przyjąć jedną z trzech form:

• Fractional CTO: doświadczony lider techniczny, który pracuje z Twoją firmą w niepełnym wymiarze. Wyznacza kierunek techniczny, podejmuje decyzje o architekturze i prowadzi inżynierów, ale nie jest pracownikiem na pełny etat.
• CTO as a service: ta sama rola, ale dostarczana przez firmę, a nie przez jedną osobę.
• CTO na pełny etat: lider techniczny zatrudniony w Twojej firmie.

Startupy i scale-upy bez lidera technicznego rozważają dwie pierwsze, gdy zatrudnienie CTO na etat to jeszcze nie ten krok. Nasz model to ten drugi: Order Group dostarcza tę rolę jako firma, więc osoba ustalająca architekturę pracuje obok inżynierów, którzy piszą kod.

Firma potrzebuje CTO, gdy decyzje techniczne zaczynają kształtować biznes, a nikt za nie nie odpowiada. Objawia się to tak:

• Produkt trzeba zbudować, a jego architektura jest wciąż otwarta.
• Dostajesz szacunki, a strona biznesowa nie ma jak ich zweryfikować.
• Ryzyka techniczne siedzą w głowach ludzi zamiast w planie.
• Zespół pisze kod bez ustalonych standardów i procesu code review.
• Decyzje o rozwiązaniach technicznych stoją w miejscu, bo nikt nie ma ostatniego słowa.

Założyciel z pomysłem i bez partnera technicznego szybko trafia na dwa pierwsze problemy. Scale-up, który skaluje działający produkt przy rosnącym zespole, częściej mierzy się z trzema ostatnimi. Każda z tych luk wchodzi w zakres obowiązków tej roli, a w naszych projektach trzyma je Project Tech Leader.

Wybór Project Tech Leadera to pierwszy punkt checklisty, którą przechodzimy na starcie projektu, a Project Manager pilnuje, żeby ta osoba została przypisana. Każdy projekt ma trzy role: Project Tech Leadera, Product Ownera i opcjonalnie Scrum Mastera. Reszta checklisty obejmuje metodykę pracy, kick-off z Tobą i wdrożenie zespołu.

Rola wymaga znajomości frontendu i backendu oraz potwierdzonego doświadczenia w rozmowach z klientem.

Project Tech Leader zostaje w projekcie, gdy ten rośnie. Wdraża nowych członków zespołu, dba o ponowne użycie komponentów razem z designem oraz sprawdza user stories i kryteria akceptacji pod kątem zrozumiałości i wykonalności. Gdy w projekcie brakuje umiejętności technicznej, może zaproponować zmianę w składzie zespołu.

Gdy kierunek jest niejasny, Project Tech Leader najpierw konsultuje się z doświadczonymi programistami i innymi Project Tech Leaderami. Gdy go nie ma, wchodzi zastępca, wyznaczony w porozumieniu z zespołem delivery i za zgodą CTO, więc decyzje techniczne nie czekają na koniec urlopu.

Rola CTO sięga poza pojedynczy projekt. Zmiana narzędzi, których używamy do pisania i wdrażania kodu, także narzędzi AI, wymaga jego zatwierdzenia. Takie zmiany proponują szefowie zespołów frontendu i backendu po analizie trendów technologicznych.

Wejściem są bezpłatne warsztaty discovery: jedno spotkanie prowadzone przez inżynierów, którzy później budują produkt. Na ich podstawie przygotowujemy podstawowy PoC lub mockup, dzięki któremu szacujemy koszt, czas i skład zespołu. Rozbudowane discovery to osobny, szerszy zakres, a jego pełny zestaw artefaktów obejmuje roadmapę. Więcej przeczytasz na stronie o naszych usługach doradczych i discovery oraz o warsztatach discovery.

Po starcie praca toczy się w Scrumie, z Product Ownerem po stronie klienta. Pracujemy w Twoich narzędziach, jeśli wolisz: w Skyfri kontakt idzie przez MS Teams, Outlook i Slacka, a od października 2024 zadania są w Jirze klienta. W KYOTO był to Slack i Jira klienta. Co miesiąc dostajesz raport przepracowanego czasu. Więcej na stronie Jak pracujemy.

Skyfri zaczęło się od Technical Feasibility Study w listopadzie 2023: analizy rynku, studium wykonalności i specyfikacji technicznej. Potem przyszły architektura i wdrożenie systemu zarządzania energią (EMS), a rozwiązanie trafiło na produkcję w czerwcu 2024.

Decyzja techniczna, która ukształtowała architekturę, dotyczyła tego, jak komunikują się urządzenia i dane. System musiał zbierać sygnały z kilku źródeł: handlu energią, operatora sieci, baterii z jej systemem zarządzania mocą oraz liczników energii. Sygnały operatora ograniczają eksport do sieci, a liczniki stoją po stronie sieci, baterii i fotowoltaiki. Alternatywą była replikacja danych na dedykowany serwer. Wybraliśmy Azure IoT Hub i Edge, bo komunikacja jest wbudowana w pakiet Azure: dane są strumieniowane, a urządzenia sterowane centralnie po stronie Azure.

Zakres obejmował moduły komunikacji Modbus, czyli przemysłowego protokołu, oraz sterowanie bateriami i panelami PV, z trybami pracy takimi jak peak shaving, czyli ścinanie szczytów mocy, i utrzymanie poziomu naładowania baterii (SoC). Moduł logiki steruje baterią, a potoki danych zasilają procesy ETL (extract, transform, load). Stos to React, Python asyncIO i Databricks, w którym działają backend w chmurze i procesy ETL.

Prace planujemy z klientem cyklicznie, na sesjach Big Room Planning, na których ustalamy kolejny etap pracy. W Skyfri zespół wszedł do projektu w styczniu 2024, tuż przed sesją, na której zaplanowano pierwsze prace. Kolejna, w październiku 2024, objęła okres od października 2024 do lutego 2025.

Trzy projekty pokazują tę rolę techniczną w działaniu:

• Skyfri. Nowy system IoT z opisanym wyżej EMS, który steruje pracą 7 obiektów, z ponad 5 MWh pojemności magazynów i ponad 4 MW mocy baterii. Przeczytaj case study Skyfri; jest częścią naszego hubu oprogramowania dla energetyki.
• KYOTO (Norwegia). W pierwszym etapie nasz zespół zbudował MVP, a Project Tech Leaderem był Maciej Sułek, Co-founder & CTO. W 2024 wróciliśmy do projektu, a rozwój produktu trwał od stycznia do grudnia 2024, w Scrumie, w Pythonie, Reactcie / React Native i AWS. Zakres obejmował infrastrukturę chmurową, platformę planowania i symulacji, system zarządzania baterią cieplną ze stopioną solą oraz integrację danych zewnętrznych, takich jak prognozy pogody i bieżące ceny energii. Obejmował też kokpity SCADA (nadzór i pozyskiwanie danych) i interfejs webowy. Przeczytaj case study KYOTO.
• Mudita. Sklep z aplikacjami dla Mudita Kompakt, telefonu z ekranem e-ink, i platforma aktualizacji bezprzewodowych (OTA), budowane w Scrumie w Javie, Kotlinie, Pythonie i Android Open Source Project (AOSP). Maciej Sułek jest Project Tech Leaderem od lipca 2022 i sam przygotował wymagania techniczne. W tym projekcie wspiera też procesy klienta.

Rolę CTO pełni Maciej Sułek, nasz Co-founder & CTO, razem z Project Tech Leaderem każdego projektu. Maciej współzałożył Order Group w 2013 i w pierwszych latach firmy prowadził projekty jako tech lead. Gdy projekt tego potrzebuje, sam pisze epiki, user stories i konfiguracje CI. Jego profil znajdziesz na stronie eksperta.

Zespoły budują z nami, bo plan i budowa zostają w rękach jednej grupy ludzi. Inżynierowie, którzy prowadzą warsztaty discovery, budują potem produkt, Project Tech Leader uczestniczy w Twoich spotkaniach, a gdy go nie ma, zastępuje go osoba zatwierdzona przez CTO. Maciej był Project Tech Leaderem w pierwszym etapie KYOTO i jest nim w Mudicie, gdzie sam napisał wymagania techniczne. Order Group to software house z Warszawy. Od 2013 zrealizowaliśmy 160+ projektów w 15+ branż, z oceną 5,0/5 w Clutch na podstawie 18 zweryfikowanych opinii.

Zapisz się na bezpłatne warsztaty discovery albo napisz przez formularz kontaktowy. Odpowiadamy w ciągu 48 godzin w dni robocze.