Doradztwo w zakresie oprogramowania

Błędne decyzje później drogo kosztują.

Gdy działy biznesowe potrzebują nowych funkcji, a IT musi najpierw wyjaśnić koszty, zależności i ryzyka, tworzymy wspólną podstawę decyzyjną. Przekładamy procesy biznesowe na solidną koncepcję oprogramowania i sprawdzamy, co jest właściwą drogą: zakup, dostosowanie czy budowa własnego rozwiązania.

Zobacz zakres usługi Omówmy przedsięwzięcie

Od sformułowania zadania po udokumentowane przekazanie.

Kiedy ta usługa pomaga

Doradztwo w zakresie oprogramowania: co mogą nam Państwo zlecić.

Przygotowanie decyzji inwestycyjnej
Wybór oprogramowania standardowego lub określenie zakresu własnego rozwiązania
Zrozumienie ryzyk technicznych przed zleceniem

Zanim zaangażują Państwo budżet w prace programistyczne, korzyści i wykonalność techniczna muszą do siebie pasować. Analizujemy Państwa istniejące środowisko systemowe, rozmawiamy z przyszłymi użytkownikami i uwidaczniamy zależności. W ten sposób powstaje solidna podstawa do podjęcia decyzji: z priorytetyzowanymi wymaganiami, uzasadnionymi propozycjami architektury i jasno nazwanymi kwestiami otwartymi.

Co może wchodzić w zakres zlecenia

Warsztaty wymagań z działem biznesowym i IT
Porównanie oprogramowania standardowego, dostosowania i budowy własnego rozwiązania
Analiza przepływów danych, interfejsów i wymagań eksploatacyjnych
Koncepcja architektury i analiza wykonalności technicznej

Konkretny zakres, odbiory i zaangażowanie Państwa strony ustalamy w ofercie.

Powiązania na pierwszy rzut oka

Od niesprecyzowanego przedsięwzięcia do uzasadnionej decyzji.

01
Zrozumienie
Rozpoznanie procesów, użytkowników i granic
02
Porównanie
Rozważenie wariantów rozwiązania i nakładu pracy
03
Wypróbowanie
Zweryfikowanie krytycznych założeń
04
Decyzja
Ustalenie architektury i etapów

Planowanie, realizacja i decyzje

Doradztwo w zakresie oprogramowania: co jest najważniejsze.

Od życzenia do weryfikowalnego wymagania

Lista pożądanych funkcji nie wyjaśnia jeszcze, jaki problem ma zostać rozwiązany. Dlatego wraz z działem biznesowym, IT i przyszłymi użytkownikami analizujemy rzeczywisty przebieg pracy: kto rozpoczyna daną sprawę, jaka decyzja następuje potem, jakich danych brakuje i gdzie dziś konieczne są poprawki? Na podstawie tych rozmów opracowujemy priorytetyzowane przypadki użycia, role i mierzalne kryteria odbioru. Uwzględniamy przy tym również wyjątki, zastępstwa i przypadki błędów.

Rezultatem jest edytowalny backlog z jasno wyznaczonymi granicami. Decyzje biznesowe pozostają po Państwa stronie; założenia techniczne i otwarte kwestie wyraźnie dokumentujemy. Dzięki temu widać, która funkcja jest niezbędna do pierwszego wdrożenia produkcyjnego, a które rozszerzenie może pojawić się później.

Kupić, dostosować czy stworzyć samodzielnie?

Nie każde wymaganie uzasadnia budowę własnego rozwiązania. Porównujemy odpowiednie warianty pod kątem pokrycia procesów, zdolności integracyjnych, bieżących kosztów i możliwości późniejszej zmiany. W przypadku oprogramowania standardowego uwzględniamy również punkty rozszerzeń, możliwości eksportu danych i zależność od producenta. Budowa własnego rozwiązania ma sens tam, gdzie szczególne procesy lub cechy produktu tworzą odrębną wartość.

Materiał decyzyjny przedstawia opcje wraz z warunkami wstępnymi i konsekwencjami. Jednorazowy nakład na realizację oddzielamy od kosztów eksploatacji, licencji i dalszego rozwoju. Nieznane interfejsy traktujemy jako niepewność i w razie potrzeby badamy je za pomocą ograniczonego prototypu technicznego.

Architektura, którą Państwa zespół może eksploatować

Wspólnie planujemy granice systemu, odpowiedzialność za dane, interfejsy i ścieżki dostępu. Modularna budowa nie musi automatycznie oznaczać mikroserwisów: dobrze zorganizowany monolit może być lepszym wyborem dla małego zespołu. O złożoności decydują dostępność, spodziewane obciążenie, przywracanie po awarii oraz możliwości Państwa zespołu odpowiedzialnego za eksploatację.

Decyzje architektoniczne dokumentujemy wraz z uzasadnieniem i odrzuconymi alternatywami. Dla ryzykownych założeń ustalamy sposób weryfikacji, na przykład integrację interfejsów lub test obciążeniowy. Na tej podstawie powstają możliwa do wdrożenia architektura docelowa, priorytetyzowane ryzyka oraz propozycja kolejnych pakietów prac.

Narzędzia dobrane do zadania

Technologia dopasowana do Państwa środowiska.

Model procesu
Decyzje architektoniczne
Prototyp techniczny

Wybór zależy od istniejących systemów, Państwa zespołu i późniejszej eksploatacji. Nie każdy projekt wymaga wszystkich wymienionych technologii.

Dla osób odpowiedzialnych merytorycznie i zespołów technicznych

Decyzje stojące za realizacją.

Przełożenie celów jakościowych na weryfikowalną architekturę

Określenia „szybkie”, „bezpieczne” i „skalowalne” nie wystarczą jako wymagania. Dla procesu wyszukiwania potrzebujemy na przykład oczekiwanej ilości danych, liczby jednoczesnych użytkowników i akceptowalnego czasu odpowiedzi. W przypadku zatwierdzania zleceń muszą być dodatkowo ustalone uprawnienia, rejestrowanie zdarzeń i zachowanie w razie awarii. Takie scenariusze jakościowe opisujemy, podając wyzwalacz, stan eksploatacyjny i oczekiwaną reakcję. Na tej podstawie można podjąć decyzje techniczne i zaplanować późniejsze testy.

Cele mogą być ze sobą sprzeczne: pracochłonna weryfikacja każdego zapytania zwiększa obciążenie przetwarzania, a szczególnie aktualny widok danych może wymagać dodatkowego powiązania komponentów. Ujawniamy takie konflikty celów i ustalamy ich priorytety razem z osobami odpowiedzialnymi. Dlatego architektura zawiera nie tylko komponenty, lecz także założenia, granice i dowody. Prototyp obciążeniowy odpowiada na inne pytanie niż klikalny projekt interfejsu. Każdy z nich otrzymuje konkretne zadanie weryfikacyjne i określony koniec.

Granice systemów, własność danych i zakresy odpowiedzialności

Jeśli zlecenie, faktura i dane podstawowe klienta występują w kilku aplikacjach, musi być jasne, kto może zmieniać którą informację. Wyznaczamy granice obszarów odpowiedzialności biznesowej i rozróżniamy ich pojęcia. „Klient” może oznaczać inne dane i reguły dla sprzedaży, księgowości i wsparcia. Wspólny model bazy danych dla wszystkich obszarów początkowo upraszcza implementację, ale może silnie powiązać ze sobą późniejsze zmiany.

Sprawdzamy granice modułów, zależności i przekazania zadań między zespołami. Osobne wdrożenie opłaca się dopiero wtedy, gdy uzyskana niezależność uzasadnia dodatkowy nakład na interfejsy, monitorowanie i obsługę błędów. Wybór między aplikacją modularną a usługami rozproszonymi zależy więc również od wielkości zespołu, odpowiedzialności za wydania i zdolności eksploatacyjnych. Macierz odpowiedzialności, kontekst systemu i udokumentowane decyzje architektoniczne określają, kto może zmienić daną granicę i które inne zespoły trzeba w to zaangażować.

Inwestycja, dług techniczny i realistyczna mapa drogowa

Koncepcja architektury musi być możliwa do sfinansowania i do wprowadzenia w bieżącej eksploatacji. Łącznie analizujemy nakład na prace programistyczne, licencje, migrację danych, infrastrukturę i długoterminowe utrzymanie. Istniejący już dług techniczny oceniamy pod kątem tego, jakie zmiany utrudnia i jakim awariom sprzyja. Nie każdy przestarzały komponent trzeba od razu wymieniać; mały, stabilny komponent może być mniej ryzykowny niż jego źle przygotowana wymiana.

Mapa drogowa łączy etapy biznesowe z warunkami technicznymi. Przed uruchomieniem nowego portalu partnerskiego może być na przykład konieczne najpierw wyjaśnienie zarządzania uprawnieniami. Dla każdego etapu określamy rezultat, punkty decyzyjne i wskazane zależności. Przy szacowaniu kosztów stosujemy przejrzyste założenia i przedziały, dopóki istnieją istotne niewiadome. Dzięki temu mogą Państwo porównywać oferty i decydować, czy dodatkowa analiza jest bardziej sensowna niż pochopne zlecenie realizacji.

Przejrzyste rezultaty prac

Co trafia w Państwa ręce.

Rezultat 01

Wymagania i priorytetyzowany backlog

Rezultat 02

Przegląd architektury i przepływów danych

Rezultat 03

Materiał decyzyjny z opcjami i czynnikami pracochłonności

Przykładowy przebieg projektu

Tak może wyglądać realizacja.

Dział biznesowy chce mieć własną platformę zamówień. Przed rozpoczęciem prac programistycznych porównujemy rozbudowę istniejącego systemu ERP z uzupełniającym portalem. Prototyp weryfikuje krytyczną integrację z ERP; następnie zamawiający decyduje o wyodrębnionym pierwszym etapie rozbudowy.

Scenariusz poglądowy, nie referencja klienta ani gwarancja rezultatu.

To ułatwia start

Istniejące opisy procesów i przegląd systemów
Dostęp do osób odpowiedzialnych merytorycznie i do architektury IT
Ramy budżetowe, cele czasowe i znane ograniczenia

Brak dokumentów nie wyklucza rozpoczęcia współpracy. Wspólnie ustalamy, jakie informacje należy pozyskać w pierwszej kolejności.

Państwa przedsięwzięcie w szczegółach

Podstawa decyzyjna, dzięki której mogą Państwo sterować projektem.

Z pomysłu na produkt lub niejasnej potrzeby modernizacji tworzymy uzasadnione zlecenie prac. Cele biznesowe, ryzyka techniczne i ograniczenia ekonomiczne są przy tym rozpatrywane łącznie.

Najpierw ograniczanie niepewności tam, gdzie może okazać się kosztowna

Nie każde otwarte pytanie musi zostać w pełni wyjaśnione przed rozpoczęciem projektu. Odróżniamy decyzje o dużym znaczeniu od szczegółów, które można doprecyzować w trakcie realizacji. Kwestię nieznanego interfejsu lub systemu starszego typu, którego nie da się sprawdzić, może wyjaśnić wstępny test techniczny; sam kolejny warsztat często nie daje na to wiarygodnej odpowiedzi.

Wyniki są oznaczane jako założenia, potwierdzone fakty i pozostałe ryzyka. Dla różnych wariantów rozwiązania analizujemy nakład na wdrożenie, bieżące utrzymanie oraz zależność od konkretnych produktów lub dostawców. Niski koszt początkowy nie oznacza automatycznie najbardziej opłacalnego rozwiązania w całym wymaganym okresie użytkowania.

Od koncepcji do etapów gotowych do zlecenia

Dzielimy przedsięwzięcie na wyniki zrozumiałe z biznesowego punktu widzenia. Pierwszy etap powinien potwierdzić użyteczny proces lub kluczowe założenie techniczne. Dla każdego etapu określane są zależności, wymagany udział Państwa zespołu i niezbędne zatwierdzenia, aby harmonogram nie opierał się na nierozpoznanych warunkach wstępnych.

Przekazanie obejmuje uzasadnienia decyzji oraz odrzucone warianty wraz z ich kontekstem. Pomaga to Państwa zespołowi wdrożeniowemu świadomie oceniać późniejsze zmiany. Dokument architektury nie jest niezmienną obietnicą; zmiany są na bieżąco dokumentowane w sposób możliwy do prześledzenia i oceniane pod kątem ich wpływu na eksploatację, nakład pracy oraz korzyści biznesowe.

Poglądowy scenariusz projektu

Jak usługa pomaga w codziennej pracy.

Przykład: dedykowany system zarządzania zleceniami ma zastąpić rozwiązanie oparte na arkuszu kalkulacyjnym. Najpierw analizujemy rzeczywisty proces zatwierdzania oraz istniejącą integrację z systemem ERP. Następnie porównujemy dostosowanie gotowego rozwiązania i budowę własnego według tych samych kryteriów, zamiast pochopnie wybierać technologię.

Ten przykład opisuje możliwy przebieg i nie jest referencją klienta.

Przed zleceniem

Doradztwo w zakresie oprogramowania: Państwa pytania.

Czy potrzebujemy już gotowej specyfikacji wymagań?

Nie. Do rozpoczęcia wystarczą przebiegi pracy, istniejące dokumenty i konkretne problemy. Wymagania opracowujemy wspólnie i oznaczamy otwarte decyzje. Pełna specyfikacja wymagań może być rezultatem doradztwa, ale nie jest jego warunkiem.

Czy doradztwo jest możliwe również bez późniejszych prac programistycznych?

Tak. Doradztwo można zlecić jako samodzielny pakiet prac. Materiał decyzyjny, architektura i priorytetyzowane wymagania mają być użyteczne dla Państwa wewnętrznych zespołów lub innego partnera wdrożeniowego. Zakres i prawa użytkowania ustalamy w zleceniu.

Jak wiarygodny jest szacunek kosztów?

Pierwszy przedział zależy od przyjętych założeń. Nazywamy te założenia, rozdzielamy znane zadania od otwartych ryzyk i doprecyzowujemy szacunek po prototypie lub sprawdzeniu interfejsów. Pozornie dokładna liczba bez wystarczającej inwentaryzacji dawałaby fałszywe poczucie pewności.

Kolejny krok

Prosimy powiedzieć nam, gdzie dziś pojawiają się trudności.

Do rozpoczęcia wystarczy krótki opis Państwa aplikacji, problemu i celu. Wybrana usługa zostanie uwzględniona w Państwa zapytaniu kontaktowym.

Zapytaj o tę usługę

Menu

Błędne decyzje później drogo kosztują.