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

Progressive Web Application (PWA)

Progressive Web Application (PWA) jest nowym standardem łączącym zalety stron internetowych i aplikacji mobilnych. Jest następcą standardu RWD (Responsive Web Design) czyli responsywnych stron internetowych dostosowujących się do różnych urządzeń szczególnie mobilnych takich jak smartphone czy tablety.

Dzięki PWA strony internetowe mogą zachowywać się tak jakby były aplikacją mobilną. Są szybkie, dostosowane do ekranu urządzenia mobilnego, z ikonką aplikacji na pulpicie czy z trybem pełnoekranowym bez menu przeglądarki. Frontend PWA może także cashować odwiedzane strony i działać offline w przypadku braku internetu lub jego zaniku. Strony PWA cechują się także lepszym interfejsem (UIUser Interface) bardziej dostosowanym do użytkownika (UXUser Experience).

Jeśli wahasz się czy wybrać PWA, RWD przy Twoim kolejnym redesignie strony www czy sklepu internetowego zapraszamy do kontaktu. Pomagamy wybrać technologię, wspieramy przy wyborze najlepszego Software House-u, wspieramy w project managemencie kluczowych projektów.

Zobacz także naszą ofertę doradztwa technologicznego:


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

Systemy Web Content Management (WCM)

Systemy WCM (Web Content Management) pozwalają na tworzenie, przechowywanie i udostępnianie różnego contentu w różnych kanałach cyfrowych takich jak sklepy internetowe, portale informacyjne,strony internetowe, aplikacje mobilne, intranet wewnętrzny, itd.

Popularnymi systemami do zarządzania contentem są: Adobe, Sitecore, Acquia, Episerver, Oracle Content and Experience (OCE), Kentico, OpenText, Automattic, Progress, Crownpeak, CireMedia, e-Spirit, Bloomreach, SDL, WP Engine (WordPress – open source), Squiz, Magnolia czy eZ.

Na co powinniśmy zwrócić uwagę przy wyborze platformy WCM:

  • Multisite i multilanguage management
  • Moduł analityczny i raportowy
  • Łatwość projektowania i zmian
  • Łatwość tworzenia contentu
  • Metadata management
  • Cena
  • Ceny wsparcia posprzedażowego
  • Dostępność lokalnych partnerów
  • itd.

Jeśli potrzebujesz wsparcia w wyborze systemów WCM oraz innych (zobacz ofertę doradczą na systemy ERP, CRM, WMS, itd.) lub wyborze dostawcy zapraszamy do kontaktu.


Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów



Audyt Backend

Audyty aplikacji webowych, sklepów internetowych czy systemów SaaS (Software as a Service) często dzielą się na audyt Frontend, Backend i API (Application Programming Interface). W skład takiego audytu może wchodzić audyt kodu źródłowego, audyt zastosowania najlepszych praktyk kodowania, audyt wydajności, audyt bezpieczeństwa czy audyt RODO.

Zakres audytów backend:

  • Ocena długu technologicznego związanego ze starą technologią, architekturą i konsekwencje wynikające z długu czyli zwiększające się koszty utrzymania systemu, zwiększające się koszty zmian i czasu potrzebnego na wdrożenie zmian, luki w bezpieczeństwie czy problemy wydajnościowe. Zobacz więcej o długu technologicznym
  • Ocena bezpieczeństwa systemu i aplikacji pozwala na ocenę jak nasz system jest odporny lub podatny na ataki z zewnątrz np. DoD (Denial of Service) lub DDoS (Distributed Denial of Service) czyli próby wyłączenia systemu poprzez generowanie dużego ruchu, ataki na bazy danych np. poprzez formularze czy wyciek danych np. danych osobowych. Zobacz więcej Audyt Bezpieczeństwa i Testy Penetracyjne OWASP.
  • Ocena jakości kodu i zgodności z najlepszymi praktykami kodowania. Zobacz szczegóły Audyt Code Review (inspekcji kodu) oraz Audyt Kodu Źródłowego.
  • Ocena zgodności z RODO (GDPR) – Zobacz szczegóły Audytu RODO dla aplikacji.
  • Ocena i rekomendacje w zakresie poprawy wydajności zarówno po stronie kodu źródłowego, konfiguracji serwerów jak i infrastruktury tele-informatycznej (Data Center, Cloud, serwery). Zobacz więcej o Audyt Wydajności (Testy obciążeniowe aplikacji)

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Audyt Front-end, interfejs UI

Audyt dla sklepów internetowych (eCommerce), dedykowanych systemów CRM, ERP, systemów typu Portal, Intranet, Marketplace lub innych dedykowanych rozwiązań tworzonych in-house lub przez zewnętrzny Software House. Jeśli masz system i rozważasz zmianę front-endu zapraszamy do wykonania szybkiego lub kompleksowego audytu i rekomendacji zmian zarówno w obszarach Front-end jak i Back-end.

Celem audytu front-end jest:

  • Ocena istniejącej technologii i rekomendacje zmian np. na PWA (Audyt interfejsu UI) – API, PWA, Mobile Access, itd.
  • Ocena użyteczności interfejsu (Audyt Usability – Audyt Użyteczności Aplikacji)
  • Ocena User Experience (Audyt UX)
  • Ocena bezpieczeństwa interfejsów (Audyt bezpieczeństwa aplikacji, api i interfejsu)
  • Audyt łatwości zmiany interfejsu na PWA (Audyt PWA)
  • Audyt wydajności Front-endu
  • Rekomendacje rozwojów systemów i architektury informatycznej

Audytu Frontend:

Zobacz także doradztwo dla eCommerce, Omnichannel i Retail:

Zapraszamy do kontaktu:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

UX, UI czyli aplikacje, interfejsy i użytkownicy

Projektowanie nowych aplikacji jest lub powinno być skoncentrowane nie tylko na funkcjonalnościach biznesowych czy wydajności a także na dostosowaniu aplikacji do potrzeb danej grupy użytkowników obsługujących te aplikacji. Często firmy zapominają o projektowaniu pod użytkowników (UX designUser Experience) i często można spotkać aplikacje, które ciągle sprawiają użytkownikom końcowym wiele problemów w ich obsłudze. Zdarzają się nawet przypadku, choć już marginalne aplikacji, których interfejs został źle zaprojektowany np. aplikacja dotykowa w kiosku na linii produkcyjnej, gdzie użytkownicy pracują w rękawicach roboczych, co zmusza ich do ciągłego zdejmowania rękawic ochronnych.

UI (User Interface) zatem jest bardzo ważnym elementem aplikacji. Musi być prosty, szybki i dostosowany do środowiska pracy. Nawet najlepsza aplikacja źle zaprojektowanym interfejsem nie spełni oczekiwań biznesowych. Ważny jest dostęp dostosowany dla potrzeb użytkownika np. dostęp mobilny, gdzie aplikacja lub interfejs (responsywny, PWA) musi spełniać oczekiwanie grupy docelowej.

Zapraszamy do naszego zespołu projektującego aplikacje GoSoftware lub do skorzystania z naszych usług doradczych np. w zakresie Audytu UX.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów

Jaki Software House wybrać?

Jaki Software House wybrać do współpracy z naszą firmą? Takie pytanie słyszymy prawie codziennie w naszej pracy doradczej. Projekty klientów są skomplikowane, kluczowe dla biznesu, kosztowne a Software House-ów w Polsce jest kilkaset. Z jakim Software Housem związać się na lata, na projekt, na utrzymanie, a może na zmianę Software House-u na inny?

Rynek Software House w Polsce

W Polsce kilkaset kilkaset małych, średnich, dużych i międzynarodowych Software Housów. Jest też duża ilość spółek oferujących zespoły programistyczne, programistów np. body leasing czy team leasing lub sam usługi np. testowania. Duże zagłębia, gdzie są zlokalizowane Software Hous’y to Warszawa, Wrocław, Gliwice, Katowice, Kraków, Lublin, Poznań czy 3city. Dodatkowo w każdym mniejszym mieście znajdują się zarówno małe Software Hous’y jak i oddziały, filie większych firm informatycznych, często międzynarodowych.

Jakiej usługi potrzebujemy?

Pierwsze pytanie jakie należy sobie zadać to jakiej usługi potrzebujemy. Czy doświadczonej firmy programistycznej, czy pojedynczych programistów, którzy wesprą nasz dział developmentu czy cały zespół na konkretny projekt. A może jesteśmy niezadowoleni z jakości, cen, terminowości obecnego Software House-u? Powodów może być wiele a wybór jest ogromny.

Typy usług oferowanych przez Software Housy:

  • Usługi programistyczne
  • Usługi administracji serwerami
  • Usługi utrzymania serwerów i aplikacji (rozwój, wydajność, bepzieczeństwo)
  • Usługi doradztwa architektury rozwiązań
  • Usługi usability (UX)
  • Usługi graficzne
  • Usługi testowania (testy bezpieczeństwa, testy jakości kodu, testy wydajności, testy UX, etc.)

Doradztwo Software House

Doradzamy naszym klientom jaki Software House wybrać. Kierujemy się wymaganiami klienta, analizą projektu oraz istniejącej architektury, aplikacji, znajomości technologii przez klienta, kosztami produkcji oprogramowania, utrzymania czy licencjnowania.

Typowy proces Doradztwa Software House w GoTechnologies:

  • Analiza potrzeb klienta (projekt, aplikacje, wymagania, harmonogram, budżet, posiadane zasoby, technologii, etc.)
  • Długa lista Software House – wybór wg. przyjętych kryteriów np. bliskość lokalizacji do klienta, etc.
  • Krótka lista Software House (short list) – wybór najbardziej pasujących Software Housów.
  • Sporządzenie zapytania ofertowego dla Software Housów
  • Wysłanie wysłania ofertowego do Software Housów z short listy
  • Analiza otrzymanych ofert
  • Spotkania z oferentami
  • Negocjacje wymagań, cen i harmonogramu
  • Wsparcie przy tworzeniu umowy z dostawcą (produkcja i utrzymanie)

Dodatkowo dla klientów realizujemy:

  • Analiza przygotowanej architektury przez Software House
  • Ustalenie z Software House najlepszych praktyk programowania dla klienta
  • Co miesięczny nadzór nad jakością kodu na przykładzie przesłanego sampla kodu w zakresie code stylingu, bezpieczeństwa, wydajności.

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów