Tajemnice Sand Hill Road – Scott Kupor

Recenzja książki Scotta Kupora partnera zarządzającego w Andreessen Horowitz. Zasady rządzące rynkiem Venture Capital.

Ta książka to fascynująca podróż po Dolinie Krzemowej począwszy od upadku bańki internetowej w 2000 r. do czasów aktualnych. Podróż ta jest pokazana przez pryzmat funduszy Venture Capital, spółek technologicznych i założycieli startupów (founderów). Historia zaczyna się od pierwszych inwestycji Venture Capital i Business Angels, pierwszego akceleratora Y Combinator w znane obecnie na całym Świecie startupy jak Airbnb, Oculus, Slac, GitHub, Pinteres czy Instacard.

Ta książka to nie tylko opowieść o powstawaniu startupów, to ogromna wiedza zarówno o rynku kapitałowym w fazach zalążkowych (seed) jak i trudnej drogi do budowania jednorożców wśród startupów. Drogi okupionej ciężką pracą, błędami, zdrowiem.

Scott Kupor jako wieloletni pracownik największych funduszy inwestycyjnych pokazuje startupom jak pracują fundusze Venture Capital, skąd biorą pieniądze, czym się kierują podejmując decyzje inwestycyjne, jak wspierają swoje spółki portfelowe, itd. Wiedza ta jest przydatna aby founderzy startupów rozumieli drugą stronę, ich politykę inwestycyjną, jej cele, zamierzenia i aby cele obu stron były jak najbardziej zbliżone i jasne, a poszukiwanie inwestora VC przemyślane i zrozumiane. Fundusze VC to nie tylko źródło finansowania to przeogromne źródło kontaktów, wiedzy, doświadczenia, potencjalnej synergii pomiędzy spółkami portfelowymi, itd. (smart money).

Jako founderzy lub członkowie zespołu znajdziecie w tej książce ogromną dawkę praktycznej wiedzy na tematy jak:

  • Zakładanie startupu
  • Finansowanie z zadłużenia czy kapitału własnego?
  • Czy Twój startup powinien sięgnąć po kapitał Venture Capital?
  • Vesting akcji założycielskich
  • Własność intelektualna (IP) w startupach
  • Opcje pracownicze, programy motywacyjne
  • Proces pozyskania kapitału z funduszu VC
  • IPO droga do exitu dla VC
  • Wycena startupu
  • Dobry Term Sheet od A do Z
  • Jak wybrać fundusz VC
  • Kryzysy w startupach
  • Konflikty startup – fundusz
  • i wiele innych.

Gorąco polecam książką zarówno dla członków startupów, którzy rozpoczynają swoją drogę lub szukają finansowania dla swojego biznesu jak i także dla inwestorów i członków zespołów funduszy inwestycyjnych.

Link do wydawnictwa MIT

Przemysław Federowicz

UAT czyli Testy Akceptacyjne

UAT (User Acceptance Tests) to testy akceptacyjne, które pozwalają odebrać stworzone oprogramowanie lub ich fragment przez osoby odpowiedzialne za procesy biznesowe lub klienta końcowego. Pozwalają one w prosty sposób określić dany ekran lub funkcjonalność jest zgodna z oczekiwaniami wszystkich odbiorców oprogramowania.

Testy akceptacyjne powinny uwzględniać np. za ISTBQ:

  • Wymagania użytkowników końcowych
  • Wymagania systemowe
  • Przypadki użycia
  • Procesy biznesowe

Przykłady testów akceptacyjnych UAT:

  • Testy akceptacyjne przez użytkownika wewnętrznego – czy product spełnia wymagania
  • Testy akceptacyjne przez klienta (CAT – Customer Acceptance Test) – czy oprogramowanie spełnia wymagania klienta
  • Testy Alfa – testy wewnętrzne deweloperów np. u wykonawcy
  • Testy Beta – testy poza zespołem wytwarzającym testy np. wśród użytkowników końcowych, itd.
  • Testy zgodności z podpisaną umową
  • Testy zgodności z prawem (legalności)
  • Testy akceptacyjne produkcyjne – testy na środowisku produkcyjnym, w różnych warunkach np. podczas obciążenia, awarii, problemów z danymi, itd.

W metodyce zwinnej Scrum UAT może być częścią Definition of Done czyli opisem jak ma wyglądać oddany produkt. Testy akceptacyjne UAT są w gestii odpowiedzialności Product Ownera i powinny być częścią sprintów Scruma.

Zobacz naszą ofertę doradztwa w zakresie projektów informatycznych

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Uczenie maszynowe – Machine Learning, Uczenie głębokie – Deep Learning

Pojęcia Uczenie maszynowe (Machine Learning), Głębokie uczenia (Deep Learning) czy Sztuczna Inteligencja (AIArtificial Intelligence) pojawiają się w ostatnich dość często i są grupowane jako technologie automatyzujące, predykcyjne oraz wspierające podejmowanie decyzji. Technologie opierają się na sieciach neuronowych. To one budzą zarówno zachwyt jak i przerażenie.

Machine Learning i sieci neuronowe

Machine Learning jest podstawą obecnych systemów Sztucznej Inteligencji i zajmuje się eksploracją danych (Data Mining). Machine Learning koncentruje się na wyszukiwaniu wzorców danych w dużych zbiorach danych zasilanych przez różne systemy lub procesy. Uczenie maszynowe często z uwagi na potrzebę dużej mocy obliczeniowej korzysta z chmur obliczeniowych (Cloud) lub specjalistycznych superkomputerów.

Deep Learning a ludzie

Deep Learning jako „dziecko” Machine Learningu pozwala skoncentrować się na człowieku i jego zachowaniach. Deep learning potrafi wchodzić w interakcję z człowiekiem, słucha dźwięków, muzyki, głosu, obserwuje np. rozpoznając obrazy. Deep Learning jest bardzo popularny z uwagi na koncentracji na zachowaniach człowieka, co w przypadku obecnych biznesów jest kluczowe.

Gdzie najprościej wykorzystać Machine Learning?

W organizacjach gdzie są spełnione dwa elementy. Są zbierane duże ilości danych (Big Data) oraz, w których innowacja jest w DNA firmy. Duże ilości aktualnych danych pozwalają „uczyć” systemy zachowań np. użytkowników czy linii produkcyjnej. Czym więcej danych na początku tym lepsze wyniki uczenia. Jeśli danych jest mniej systemy muszą za każdym razem kiedy wystąpi nieoczekiwana sytuacja uczyć się, co wydłuża proces wdrożenia i produkcyjnego wykorzystania tychże systemów.

Zobacz naszą ofertę doradztwa technologicznego:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Poziom gotowości technologicznej TRL w Startupach

Poziom gotowości startupu zarówno rozwoju produktu jak i gotowości do komercjalizacji TRL (Technology Readiness Level) określa się w skali od 1 do 9. Skala jeden to ocena wstępnej koncepcji, walidacja pomysłu, realności wdrożenia, natomiast skala dziewięć to gotowość produktu do sprzedaży (po wszystkich testach, certyfikacji, itd.). TRL określa zatem poziom dojrzałości produktu do jego komercjalizacji. Czym wyżej w skali tym mniejsze ryzyko niepowodzenia i szybszy czas rozpoczęcia sprzedaży produktu.

Skala ta ułatwia zewnętrznym inwestorom śledzenie postępu rozwoju produktów i jest pomocnym narzędziem i wskaźnikiem rozwoju KPI (Key Performance Indicator). TRL jest powszechnie stosowany nie tylko w Polsce, ale także jest standardem w Unii Europejskiej w Stanach Zjednoczonych, gdzie został pierwotnie wymyślony przez NASA w latach 70-tych. Z punktu widzenia inwestora czym wyższym TRL tym większa szansa na sukces i mniejsze ryzyko inwestycyjne. Oczywiście należy pamiętać także o własnym IT Due Diligence, nie zawsze founderzy rozumieją TRL, a wręcz podwyższają skalę dojrzałości produktu.

Skalę TRL można podzielić na trzy grupy:

  • TRL 1: Prace koncepcyjne, analiza pomysłu, produktu, realności jego stworzenia
  • TRL 2-6: Badania przemysłowe nad produktem
  • TRL 7-9: Prace rozwojowe nad produktem

Skala TRL w NCBiR:

  • TRL 1: Zaobserwowano i opisano podstawowe zasady danego zjawiska – najniższy poziom gotowości technologii, oznaczający rozpoczęcie badań naukowych w celu wykorzystania ich wyników w przyszłych zastosowaniach. Zalicza się do nich między innymi badania naukowe nad podstawowymi właściwościami technologii.
  • TRL 2: Określono koncepcję technologii lub jej przyszłe zastosowanie. Oznacza to rozpoczęcie procesu poszukiwania potencjalnego zastosowania technologii. Od momentu zaobserwowania podstawowych zasad opisujących nową technologię można postulować praktyczne jej zastosowanie, które jest oparte na przewidywaniach. Nie istnieje jeszcze żaden dowód lub szczegółowa analiza potwierdzająca przyjęte założenia.
  • TRL 3: Potwierdzono analitycznie i eksperymentalnie krytyczne funkcje lub koncepcje technologii. Oznacza to przeprowadzenie badań analitycznych i laboratoryjnych, mających na celu potwierdzenie przewidywań badań naukowych wybranych elementów technologii. Zalicza się do nich komponenty, które nie są jeszcze zintegrowane w całość lub też nie są reprezentatywne dla całej technologii.
  • TRL 4: Zweryfikowano komponenty technologii lub podstawowe jej podsystemy w warunkach laboratoryjnych. Proces ten oznacza, że podstawowe komponenty technologii zostały zintegrowane. Zalicza się do nich zintegrowane „ad hoc” modele w laboratorium. Uzyskano ogólne odwzorowanie docelowego systemu w warunkach laboratoryjnych.
  • TRL 5: Zweryfikowano komponenty lub podstawowe podsystemy technologii w środowisku zbliżonym do rzeczywistego. Podstawowe komponenty technologii są zintegrowane z rzeczywistymi elementami wspomagającymi. Technologia może być przetestowana w symulowanych warunkach operacyjnych.
  • TRL 6: Dokonano demonstracji prototypu lub modelu systemu albo podsystemu technologii w warunkach zbliżonych do rzeczywistych. Oznacza to, że przebadano reprezentatywny model lub prototyp systemu, który jest znacznie bardziej zaawansowany od badanego na poziomie V, w warunkach zbliżonych do rzeczywistych. Do badań na tym poziomie zalicza się badania prototypu w warunkach laboratoryjnych odwzorowujących z dużą wiernością warunki rzeczywiste lub w symulowanych warunkach operacyjnych.
  • TRL 7: Dokonano demonstracji prototypu technologii w warunkach operacyjnych. Prototyp jest już prawie na poziomie systemu operacyjnego. Poziom ten reprezentuje znaczący postęp w odniesieniu do poziomu VI i wymaga zademonstrowania, że rozwijana technologia jest możliwa do zastosowania w warunkach operacyjnych. Do badań na tym poziomie zalicza się badania prototypów na tzw. platformach badawczych.
  • TRL 8: Zakończono badania i demonstrację ostatecznej formy technologii. Oznacza to, że potwierdzono, że docelowy poziom technologii został osiągnięty i technologia może być zastosowana w przewidywanych dla niej warunkach. Praktycznie poziom ten reprezentuje koniec demonstracji. Przykłady obejmują badania i ocenę systemów w celu potwierdzenia spełnienia założeń projektowych, włączając w to założenia odnoszące się do zabezpieczenia logistycznego i szkolenia.
  • TRL 9: Sprawdzenie technologii w warunkach rzeczywistych odniosło zamierzony efekt. Wskazuje to, że demonstrowana technologia jest już w ostatecznej formie i może zostać zaimplementowana w docelowym systemie. Między innymi dotyczy to wykorzystania opracowanych systemów w warunkach rzeczywistych

Zobacz naszą ofertę doradczą dla startupów i funduszy Venture Capital:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Zwinne wytwarzanie oprogramowania Scrum i Kanban

Zwinne wytwarzanie oprogramowania (Agile Software Development) na dobre zagościło w polskich firmach. Obecnie mało, w której nie stosuje się jakiegoś “zwinnego” procesu  wytwarzania oprogramowania. Dlaczego tak się dzieje? Dlaczego firmy odchodzą od tradycyjnych metod prowadzenia projektów na rzecz bardziej elastycznych lub je łączą? Powodów jest wiele. A więc od początku.

W 2001 roku powstał manifest zwinności, który obecnie brzmi “Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.

Od tego się zaczęło. Od tamtego czasu powstało wiele odmian metodyk zwinnych takich jak XP (Extreme programming), Crystal Clear, Scrum i inne. Jednakże dopiero Scrum został tak szeroko przyjęty przez programistów i organizacje. Tzw. “wdrożenie” Scruma nie jest łatwe, gdyż zmienia on sposób myślenia i funkcjonowania nie tylko samego działu deweloperskiego, ale i całej organizacji. Scruma możemy wykorzystywać stale w procesie wytwarzania oprogramowania lub w przypadku wyjątkowo ważnych projektów, które charakteryzują się dużą zmiennością, ograniczonym czasem i obarczonych dużym ryzykiem.

Zacznijmy od najważniejszego: ludzi. Scrum składa z trzech ról: właściciela produktu (Product Owner), zespołu oraz Scrum Mastera. Właściciel produktu reprezentuje osoby zainteresowane produktem np. sponsor, zarząd, dział sprzedaży, itd. Ustala on priorytety i odbiera wytworzone produkty. Zespół deweloperski jest odpowiedzialny za wykonanie zadań i ponosi grupową odpowiedzialność za ich realizację. Zespoły budujemy w zależności od czekających nas zadań tak, aby znaleźli się w nim specjaliści o kompetencjach umożliwiających wykonanie zleconych im zadań. Scrum Master jest rolą odpowiedzialną za realizowanie całego procesu scrumowego i “ochronę” jego przed próbami łamania zasad. Ta rola nie jest ani Team Leaderem ani Project Managerem.

Zobaczmy jak wygląda proces wytwarzania oprogramowania w Scrumie:

  • Planowanie (Sprint Planning), spotkanie inicjujące, które składa się z dwóch części. Pierwsza część to prezentacja przez product ownerów zadań do wykonania, celów, priorytetów, itd. Druga część to analiza przez zespół programistyczny czasochłonności, trudności wykonania, możliwej do zastosowania technologii lub architektury. Wynikiem tego jest Sprint Backlog – lista zadań wybrana na jeden sprint z Product Backloga.
  • Codzienne spotkania (Daily Scrum lub Daily Standup), krótkie kilkuminutowe spotkania członków zespołu, zazwyczaj w godzinach porannych. Każdy z zespołu odpowiada na 3 pytania, co zrobił wczoraj, co zrobi dzisiaj i czy są tematy, które blokują jego pracę.
  • Przegląd sprintu (Sprint Review) to spotkanie pod koniec każdego sprintu, gdzie zespół oddaje wykonaną pracę w postaci działającego produktu.
  • Analiza sprintu (Sprint Retrospective) to spotkanie, na którym możemy omówić, co się nie udało podczas tego sprintu, co należy poprawić, itd. Bardzo ważne spotkanie, które często jest pomijane ze względu na brak czasu (spotkanie można realizować np., co drugi lub trzeci sprint, ale nie wolno pomijać jego zgodnie z procesem samodoskonalenia).

Zatem jak “wdrożyć” Scruma w kilku krokach:

  • Podziel ludzi na małe zespoły (kilku osobowe w zależności od skali organizacji i projektów) posiadających w sobie różne kompetencje.
  • Wyznacz rolę właściciela projektów lub zadań (Produkt Owner) oraz Scrum Mastera.
  • Podziel zadania lub projekty na mniejsze zadania, ustal z Product Ownerami ich priorytety i oszacuj potencjalny czas ich realizacji, zrób z tego kolejkę lub listę zadań (Product Backlog).
  • Wyznacz czas jednego sprintu (czas, w którym będziemy pracowali a na koniec jego oddawali zlecone zadania) zależnie od skali zadań od jednego do kilku tygodni.
  • Rozpocznij sprint zgodnie z procesem opisanym wyżej.

Co daje nam Scrum? W teorii są to: łatwość reagowania na zmiany i łatwość realizacji zadań, zwiększona produktywność i jakość, szybsze reagowanie na pojawiające się ryzyka, wcześniejsze uzyskiwanie półproduktów, poprawę komunikacji pomiędzy biznesem a działami IT, większe zaangażowanie całej organizacji w prace rozwojowe, zmniejszenie kosztów realizacji projektów i jeszcze kilka innych. Oczywiście jest to tylko teoria i wszystko zależy od ludzi i chęci zmiany aktualnej rzeczywistości w organizacji.

Czym jest Kanban i w czym może nam pomóc? Kanban wywodzi się z systemów produkcyjnych, głównie z branży motoryzacyjnej. Pozwala śledzić postępy prac nad poszczególnymi produktami na liniach montażowych. Kanban należy do tzw. systemów “ciągnionych” (pull), które różnią się od systemów “pchanych” (push) realnym zapotrzebowaniem na wytwarzanie niż z góry wytyczoną polityką produkcji. Proces wytwarzania oprogramowania może zostać porównany z linią montażową w hali produkcyjnej, dlatego Kanban idealnie nadaje się, jako technika sygnalizacyjna przy zarządzaniu realizacją zadań czy projektów.

Wszystkie zadania poruszają się zgodnie z przepływem (flowem) w jednym kierunku (np. z lewa do prawa) i przechodzą przez kolejne etapy (np. analiza, implementacja, testowanie, wdrożenie, itd.) . Każdy z etapów posiada określone zasoby (pracownicy o odpowiednich umiejętnościach) oraz możliwość przerobu (ilość możliwej do wykonania pracy w tej samej jednostce czasu). Dzięki takiemu podejściu szybko widzimy, na jakim etapie znajdują się zadania, gdzie mamy ograniczenia oraz co musimy zrobić, aby zwiększyć przerób, czyli produkcję oprogramowania.

Kanban posiada kilka podstawowych zasad:

  • Wizualizacja – stworzenie i rozrysowanie (na tablicy lub za pomocą oprogramowania) procesu wytwarzania oprogramowania ze statusami działań np. analiza, wytwarzanie, testowanie, wdrażanie, zadania skończone.
  • Limit pracy w toku (WIP – Work in Progress) – nie możemy pracować nad większą liczbą zadań niż jesteśmy w stanie wykonać w tej samej jednostce czasu oraz jeśli nie dostaliśmy zlecenia na wykonanie pracy przez jednostkę zlecającą. Jest to zasada wywodząca się z systemów “ciągnionych” (pull).
  • Zarządzanie strumieniem – monitorowanie i raportowanie o etapach wykonywania zadań, prędkości i płynności wykonywania zadań. Idealny proces charakteryzuje się dużą prędkością wykonywania zadań i płynnością oraz przewidywalnością.


Jak zacząć? Zastosowanie Kanbana jest bardzo proste. Poniżej kilka kroków, jakie należy uczynić, aby móc sprawnie zarządzać zadaniami w procesie wytwarzania oprogramowania.

  • Rozrysuj aktualny proces wytwarzania oprogramowania np. na tablicy lub dużej powieszonej na ścianie kartce papieru. Kolumny będą oznaczały kolejne elementy procesu.
  • W pierwszej kolumnie (np. nazwanej listą zadań, backlog-iem lub wish listą) umieść karteczki z zadaniami. Powstanie kolejka zadań. Nadaj im priorytety. Podziel zadania na kategorie zadań np. błędy, zadania, poprawki, itd.
  • Nazwij kolejne kolumny np. analiza, programowanie, testowanie, wdrażanie i zadania skończone.
  • Określ możliwy przerób na każdym etapie (tzw. WIP) np., jeśli posiadamy jednego testera to możemy przyjąć, że na etapie testowania będziemy mogli równocześnie testować tylko jedno zadanie.
  • Podziel oznaczone już etapy (kolumny) na dwa statusy: w trakcie, skończone.
  • Zacznij działać. Pobieraj zadania z kolejki zgodnie z możliwościami przerobu (WIP). Przesuwaj zadania zgodnie ze zmianami statusów do lewa do prawa, aż do kolumny zadania skończone (wdrożone).

Co dalej? Kanban pozwala na analizę czasu potrzebnego na wykonania zadań. Dzięki takiej wiedzy i grupowaniu zadań nie musimy szacować czasochłonności wykonania zadań a określać wielkość zadań za pomocą prostych miar np. duże, małe, średnie. Zaoszczędzi to nam bardzo dużo czasu na estymację, która i tak będzie błędna. A co w przypadku pisania oprogramowania dla klienta zewnętrznego? Tutaj warto przyjrzeć się połączeniu Scruma i Kanbana, co zrobimy w dalszej części. Kanban pozwala wykrywać wąskie gardła w procesie od pojawienia się pomysłu, aż do wdrożenia oprogramowania. Często wąskie gardła znajdują się poza procesem wytwarzania oprogramowania np. w dziale biznesowym, który jest odpowiedzialny za testy akceptacyjne wytworzonych produktów.

Kanban pozwala zmniejszyć skutki wielozadaniowości poprzez stosowanie limitów WIP. Pozwala to na zajmowanie się zadaniami, które w rzeczywistości mają wysoki priorytet i które możemy rzeczywiście wykonać w jednej jednostce czasu.

Proces wytwarzania powinien charakteryzować się też płynnością wykonywania zadań. Monitorujmy zatem  i udoskonalajmy wszystkie elementy procesu. Pozwoli to w przyszłości do osiągnięcia dużej prędkości wytwarzania oprogramowania, unikania wąskich gardeł i nie tracenia cennego czasu.

Kolejne kroki? Mamy już działający Scrum. Widzimy także tablicę Kanbana. Jak to teraz połączyć i co dzięki temu zyskamy? Scrum działa w określonych okresach czasu tzw. iteracjach. Kanban to zmienia mówiąc, że zasoby są wolne i domagają się otrzymania kolejnych zadań. Praca w Scrumbanie zaczyna przypominać taśmociąg, który pracuje niezależnie od okresu czasu. Dzięki takiemu podejściu możemy wykonać więcej zadań niż w typowym sprincie. Możemy także mniej uwagi przywiązywać do estymacji czasu wykonania a bardziej bazować na priorytetach i kolejce. W praktyce w niedługim czasie zobaczymy, że wykonujemy więcej zadań niż pracując w typowym Scrumie.

Jakie są różnice pomiędzy Scrumem a Scrumbanem? Nie ograniczamy się do sprintu. Bierzemy pierwsze zadanie z kolejki. Tablica Kanbana może być stosowana dla wielu zespołów a także dla całych firm. W przypadku tablicy Scruma, korzysta z niej tylko zespół scrumowy. Jak widzimy tablica Kanbana poprawia komunikację i poszerza wiedzę o innych zadaniach i projektach wykonywanych przez inne zespoły, niekoniecznie informatyczne. W Scrumbanie nie patrzymy na wykres spalania (burndown chart) a bardziej na czas wykonania zadania. A co z codziennymi spotkaniami, sprint planningiem czy sprint review? Polecam kontynuowanie codziennych stand-upów, planowanie tylko wtedy, kiedy jest to potrzebne, a przeglądy regularnie, co kilka tygodni w z góry ustalonym terminie. Zachęcam do eksperymentowania i procesu ciągłego doskonalenia. Jestem też zwolennikiem adoptowania najlepszych elementów z różnych metodologii do istniejącej organizacji np. elementów Scruma, Princa2, PMI, CCPM lub Kanbana.

Zobacz naszą ofertę doradczą:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Metodyka rozwoju oprogramowania DevOps

Nazwa DevOps pochodzi od słów „development” czyli wytwarzanie oprogramowania i „operations” czyli operacje, eksploatacji systemów. Metodyka DevOps ma połączyć światy wytwarzania, testowania, wdrażania, administrowania i utrzymania, często inne, o innych celach i kompetencjach. Kładzie ona nacisk na komunikację pomiędzy działem utrzymania (administratorami systemów) oraz programistów i testerów oprogramowania.

Włączenie administratorów do rozwoju oprogramowania ma ewidentne zalety:

  • Pozwala na szybsze wdrażanie zmian „na produkcję” dzięki czemu biznes osiąga więcej korzyści np. częstsze wdrożenia zmian w platformie eCommerce (sklep internetowy) lub na platformie SaaS
  • Pozwala na lepsze wykorzystaniu posiadanych zasobów serwerowych i obniżeniu kosztów
  • Zwiększa wydajność i bezpieczeństwo systemów obniżając koszty utrzymania.

Metoda DevOps wykorzystuje szeroko zdalne narzędzia do komunikacji pomiędzy członkami zespołu jak wiki, wideokonferencje, czaty, itd. Dlatego bardzo dobrze sprawdza się w okresie pandemii wirusa corona Covid-19.

Metodyka i inżynierowie DevOps lubą pracować ze zwinnymi metodykami wytwarzania oprogramowania (Agile np. Scrum) czy z środowiskami chmurowymi (np. Microsoft Azure, Google GCP, Amazon AWS).

Metodyka DevOps pozwala na lepsze zarządzania cyklem życia aplikacji (oprogramowania), gdzie już w fazie planowania przewidujemy przyszłość i rozwój systemu w kolejnych latach.

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Startupy IoT – Internet of Things

Urządzenia Internetu Rzeczy (IoT – Internet of Things) obecnie można spotkać zarówno w domach, fabrykach (IIoTIndustrial Internet of Things), podczas leczenia czy rehabilitacji, podczas uprawiania sportu, w inteligentnych miastach (Smart Cities) w transporcie, itd. Dostępność urządzeń IoT jest spowodowana m.in. łatwym dostępem do szybkich sieci WiFi, Mobile, zmniejszającymi sie cenami urządzeń, wydłużającym się czasem działania na baterii czy coraz większą ilością aplikacji i dostawców urządzeń. Dostęp do 5G także zaczyna potęgować pomysły wykorzystujące 5G i IoT praktycznie wszędzie.

Startupy działające w branży IoT można podzielić na kilka kategorii.

Startupy IoT w podziale na branże

  • IoT Smart Home – inteligentne domy
  • IoT Smart Cities – inteligentne miasta
  • IIoT w Przemyśle (Industrial Internet of Things) – rozwiązania przemysłowe
  • IoT w Medycynie, opiece osób starszych, rehabilitacji, itd. Internet of medical things (IoMT)
  • IoT w Rolnictwie
  • IoT w branży zbrojeniowej, lotniczej i kosmicznej

Startupy IoT w podziale na produkty

  • IoT Middleware & Operation Systems – systemy dla IoT
  • IoT Hardware – sensory IoT, Beacony, Tagi i czytniki tagów, gateways, routers, system on chip, mikrokontrolery, moduły komunikacyjne.
  • IoT Connectivity – Mobile, sieci niskoprądowe LPWAN (SigFox, LoRa), 5G, Bluetoout, NB-IoT, WiFi, VSAT, itd.
  • IoT Platform – connectivity management, platformy analityczne, platformy end to end.
  • IoT Security – bezpieczeństwo urządzeń, bezpieczeństwo sieci, bezpeiczeństwo przesyłania danych i ich gromadzenia.
  • IoT Development Boards & Kits
  • IoT Stacks

GoTechnologies wspiera od lat zarówno największe fundusze Venture Capital m.in. w IT Due Diligence, startupy w rozwoju produktów, pozyskaniu klientów i kapitału jak i największe firmy produkcyjne, eCommerce w zastosowaniu najnowszych technologii, tworzeniu nowych strumieniu przychodowych (monetyzacja danych) czy optymalizacji procesów za pomocą technologii.

Zobacz naszą ofertę doradczą dla startupów i funduszy Venture Capital:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Współpraca Startup – Korporacja

Idea współpracy startupów z korporacjami jest znana i praktykowana od już lat. Rezultaty są niestety znane. Większość tego typu projektów kończy się albo porażką, albo „pseudo” sukcesem, gdzie startup zostanie kupiony a jego produkt „zamknięty w szafie”. Do tego działania PR i marketing powodują, że myślimy o takiej współpracy jako łatwej. Nic bardziej mylnego. Współpraca elastycznego startupu z proceduralną i „okopaną” korporacją jest bardzo trudna.

Jakie mamy ograniczenia i wyzwania we współpracy Startup – Korporacja:

  • Zmuszenie zespołu korporacji do dodatkowej pracy ze startupami, mimo swoich obowiązków i KPI-ów tzw. „awans”.
  • Priorytetyzacja zadań wewnątrz organizacji.
  • Brak dedykowanego zespołu do współpracy ze startupami.
  • Chęć posiadania, gdyż inni też mają działy innowacji, Spin-off czy Startupy.
  • Silne procedury compliance i security, do których musi się dostosować Startup i gdzie potrzebuje otrzymać silne wsparcie.
  • Zbyt agilowe podejście za strony Startupu nieuwzględniające specyfiki i struktury organizacyjnej korporacji oraz punktów decyzyjnych.
  • itd.

Więcej o technologicznych startupach:

GoTechnologies wspiera od lat zarówno startupy jak i największe korporacje i fundusze Venture Capital i Private Equity. Zapraszamy do zapoznania się z ofertą doradztwa dla Startupów.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Metody rozliczeń za projekty z dostawcami (Software House)

Usługi informatyczne można podzielić na usługi łatwo wycenialne jak np. na sprzęt komputerowy, licencje czy usługi SLA oraz usługi trudniej wycenialne jak tworzenie aplikacji czy integracji.

Dlaczego tak trudno wycenić fix stworzenie aplikacji? Ponieważ zespół wykonawczy (programiści, project manager, itd. ) nie otrzymują „książki” z opisanymi szczegółowo wymaganiami. Proces zbierania wymagań i ulepszenia produktu jest tworzony w trakcie kodowania (developmentu) i jest obecnie jego częścią. Dlatego dużo zależy od zespołu biznesowego, który jest odpowiedzialny za odpowiedni „wsad” dla zespoły wykonawczego.

Metody rozliczeń z dostawcami (dział wewnętrzny, Software House, itd.):

  • Wycena Fix Price – wycena z góry ustalona za wykonanie usługi. Dobra metoda i tania, jeśli mamy dobrze zdefiniowany zakres zrozumiały dla dostawcy oraz klienta. Ważne jeśli ta usługa jest wykonywana przez dostawce wielokrotnie, więc może też poprzez porównanie być wyceniana. Metoda Fix Price jest wykorzystywana w tradycyjnych metodach zarządzania projektami tzw. Waterfall.
  • Wycena Time & Material – wycena z ustaloną stawką godzinową lub dzienną, kiedy zakres nie jest ustalony szczegółowo. Płacimy do momentu kiedy dostawca zrealizuje usługę. Wycena Time & Material jest podstawą zarządzania projektami z metodykach zwinnych Agile np. w Scrum.
  • Capped Time & Material – metoda pracy jak w Time & Material jednakże z górnym ograniczeniem budżetu narzuconym przez klienta. W przypadku jego przekroczenia dostawca zrealizuje resztę usług w ramach zadeklarowanego budżetu bez konieczności dopłat (chyba, że zakres się zwiększa i jest ustalony i zaakceptowany przez kienta).

Zobacz naszą ofertę na Project Management – wsparcie klientów w kluczowych projektach.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Najnowsze inwestycje w Startupy przez Brave Venture Capital

Fundusz Brave Venture Capital, w ramach którego inwestujemy w ciekawe startupy technologiczne dokonał kolejnej, już trzeciej inwestycji. Obecnie są zrealizowane następujące inwestycje w startupy technologiczne:

  • Petal International – międzynarodowy Agri Startup opracowujący aplikację SIFA (Smart Indoor Farming App), która będzie służyła do kontroli i monitoringu parametrów czynników wpływających na uprawę roślin wewnątrz pomieszczeń np.: szklarnie, farmy horyzontalne i kontenerowe. Software ten można stosować dla wszelkiego rodzaju upraw – warzyw, owoców, marihuany medycznej.
  • Youartme – inwestycja wraz ze spółką Candellana. Produkty Candellana to unikalne rzeźby z wosku i świece, a także designerskie donice pod marką Concrette, które produkuje Youartme. W procesie produkcyjnym używana jest technologia druku 3D, która świetnie sprawdziła się do produkcji wyrobów z dużą ilością, nawet bardzo małych detali. Produkty obu spółek są sprzedawane na całym świecie.
  • Artigiano – międzynarodowy startup prowadzi prace badawczo- rozwojowe w dziedzinie inżynierii materiałowej, w szczególności polimerów i nanotechnologii. Inwestujemy m.in. w projekty badawczo-rozwojowy, który docelowo będzie umożliwiał produkcję i sprzedaż zaawansowanych technologicznie masterbatchy czy dodatków do polimerów. Innowacyjne kompozyty polimerowe kierowane są do przedsiębiorców i podmiotów działających na rynku tworzyw sztucznych.

Jeśli jesteś zainteresowany współpracą z naszym funduszem zapraszamy do kontaktu przez stronę brave.vc lub pfederowicz@gotechnologies.pl