Software house Warszawa - współpraca zdalna z klientem ze stolicy

Software house Warszawa a współpraca zdalna

Software house tworzy oprogramowanie na zamówienie. Analizuje potrzebę klienta i projektuje rozwiązanie, a potem odpowiada za wykonanie i wdrożenie. Firma z Warszawy szukająca takiego partnera zwykle zaczyna od wyszukania wykonawcy w stolicy. Miejsce siedziby ma jednak mniejsze znaczenie niż sposób prowadzenia projektu, bo większość pracy programistycznej da się wykonać na odległość. Ten artykuł opisuje mechanizmy takiej współpracy, na przykładzie zespołu spoza Warszawy pracującego dla klienta ze stolicy.

Opis ma charakter procesowy. Pokazuje, które czynności projektu nie wymagają spotkania, a które wymagają obecności na miejscu. Nie jest to lista referencji ani deklaracja liczby zrealizowanych projektów. Rolę firmy programistycznej w całym cyklu przedstawia strona o software house, a model pracy nad oprogramowaniem przygotowanym pod jednego odbiorcę omawia tekst o producencie oprogramowania na zamówienie.

Reguła: lokalizacja wykonawcy jest kryterium drugorzędnym, jeśli umowa opisuje odbiory, dostęp do środowisk i sposób przekazania kodu.

Analiza wymagań na warsztatach online

Pierwszym etapem jest seria warsztatów, na których klient opisuje proces, a analityk rysuje go na wspólnym ekranie. Uczestnicy widzą ten sam schemat i poprawiają go na bieżąco. Nagranie spotkania i notatki trafiają do wspólnego katalogu, więc osoba, która dołączy do projektu później, nie musi odtwarzać ustaleń z pamięci.

Z warsztatów powstaje specyfikacja. Zawiera ona role użytkowników i słowniki, a także dokumenty ze statusami oraz reguły przejść między nimi. Każda reguła ma numer, aby można było się do niej odwołać w testach odbiorowych. Zasady przygotowania takiej dokumentacji opisuje artykuł o analizie przedwdrożeniowej.

• Schemat procesu - rysunek kroków i decyzji, poprawiany na warsztacie przez obie strony.
• Rejestr założeń - lista ustaleń przyjętych do czasu potwierdzenia. Każde ma datę oraz autora.
• Lista pytań otwartych - pytania do klienta z właścicielem odpowiedzi i terminem.
• Specyfikacja z numerowanymi regułami - podstawa testów odbiorowych i rozliczenia zmian.

Zdalna analiza ma jedno ograniczenie. Gdy proces odbywa się fizycznie, na przykład przy rampie albo na hali, samo opowiadanie nie wystarcza i analityk powinien zobaczyć operację na miejscu. Taka wizyta trwa zwykle krócej niż cała analiza, więc nie zmienia zasadniczo modelu pracy.

Specyfikację uzupełnia lista pytań otwartych z właścicielem po stronie klienta i terminem odpowiedzi. Pytanie bez odpowiedzi w terminie zostaje zapisane jako założenie, które wykonawca przyjmuje do czasu poprawki. Dzięki temu brak decyzji nie zatrzymuje prac, a założenia są jawne dla obu stron.

Dostęp do środowisk i danych klienta

Praca zdalna wymaga uporządkowanego dostępu. Programiści nie powinni pracować na bazie produkcyjnej klienta, więc projekt ma co najmniej dwa środowiska: testowe i produkcyjne. Do środowiska testowego trafia kopia struktury bazy, a w razie potrzeby także zanonimizowana kopia danych.

Dostęp do serwera klienta odbywa się przez sieć prywatną albo zdalny pulpit z uwierzytelnianiem, a konta są imienne. Konto wspólne dla całego zespołu uniemożliwia ustalenie, kto wykonał zmianę. Uprawnienia w bazie SQL Server nadaje się przez role, a nie pojedynczym użytkownikom. Poniższy przykład, z nazwami poglądowymi, tworzy rolę tylko do odczytu dla konta diagnostycznego.

CREATE ROLE rola_diagnostyka;
GRANT SELECT ON SCHEMA::dbo TO rola_diagnostyka;
DENY  SELECT ON dbo.DaneOsobowe TO rola_diagnostyka;

CREATE USER jkowalski_diag FOR LOGIN jkowalski_diag;
ALTER ROLE rola_diagnostyka ADD MEMBER jkowalski_diag;

Polecenie DENY ma pierwszeństwo przed GRANT, więc konto diagnostyczne odczyta strukturę i dane techniczne, ale nie tabelę z danymi osobowymi. Model uprawnień opisuje dokumentacja uprawnień silnika bazy danych w Microsoft Learn. Przed przekazaniem danych osobowych zespołowi zewnętrznemu klient powinien uzgodnić zasady ich powierzenia w umowie.

Cykl wydań i odbiory na odległość

Projekt dzieli się na krótkie iteracje, z których każda kończy się działającą funkcją do obejrzenia. Pokaz odbywa się na spotkaniu online: wykonawca uruchamia funkcję w środowisku testowym, a klient sprawdza ją na uzgodnionych przypadkach. Odbiór zapisuje się w krótkim protokole z numerami reguł ze specyfikacji, które funkcja spełnia.

Sposób prowadzenia projektów opisuje artykuł o programowaniu aplikacji biznesowych. Zmiany wymagań w trakcie prac są normalne, lecz każda z nich trafia do rejestru z oceną wpływu na termin i koszt. Aplikacje przeglądarkowe, które zwykle powstają w takim cyklu, przedstawia tekst o tworzeniu aplikacji webowych.

Reguła: funkcja jest odebrana dopiero wtedy, gdy klient sprawdził ją sam na środowisku testowym. Pokaz wykonawcy nie zastępuje tego testu.

Komunikacja i rytm pracy zespołu rozproszonego

Zespół, który nie siedzi w jednym biurze z klientem, potrzebuje jasnych kanałów. Zgłoszenia i decyzje trafiają do jednego rejestru, a rozmowy w komunikatorze służą do szybkich pytań i nie zastępują dokumentacji. Ustalenie podjęte w rozmowie ma znaczenie dopiero wtedy, gdy zostanie zapisane w rejestrze zadań z datą.

Po stronie wykonawcy klient ma jedną osobę odpowiedzialną za kontakt. Po stronie klienta również powinien istnieć właściciel biznesowy, który może zatwierdzić zmianę zakresu. Gdy takich osób brakuje, decyzje wracają w kółko między działami, a projekt traci tygodnie. Strefa czasowa nie tworzy problemu, bo obie strony pracują w tym samym kraju i w podobnych godzinach.

Eskalacja ma własną ścieżkę. Jeżeli zgłoszenie nie zostaje obsłużone w terminie, trafia do osoby wyżej po obu stronach, co skraca czas oczekiwania na decyzję. Taką ścieżkę spisuje się w umowie razem z danymi kontaktowymi, w tym z numerem telefonu do zgłoszeń awaryjnych.

Stos technologiczny i systemy partnerskie

SoftwareStudio Group Sp. z o.o. tworzy oprogramowanie w technologii Microsoft. Aplikacje pracują na serwerze IIS w ASP.NET, kod powstaje w C#, a dane leżą w SQL Server i są przetwarzane w T-SQL. Taki stos pozwala budować zarówno aplikacje dla systemu Microsoft Windows, jak i aplikacje webowe dostępne przez przeglądarkę.

Infrastrukturę można oprzeć na wirtualizacji, na przykład na platformach VMware albo Windows Azure. Wirtualne serwery ułatwiają dostosowanie zasobów do potrzeb firmy. Pamięć i moc obliczeniową zwiększa się bez wymiany sprzętu. Model rozwiązań aplikacji na zamówienie porządkuje artykuł o dedykowanym oprogramowaniu na zamówienie.

W opisie oferty SoftwareStudio pojawiają się także systemy dostawców partnerskich: klasy ERP, Helpdesk OTRS, serwer poczty Kerio oraz oprogramowanie bezpieczeństwa Safetica. Są to produkty osób trzecich, więc zakres ich funkcji określają producenci. Wykonawca zajmuje się ich wdrożeniem i integracją z aplikacją klienta.

Kopie zapasowe i wdrożenie na serwer klienta

Wdrożenie nowej wersji na serwer klienta wykonuje się skryptem, a nie ręcznym kopiowaniem plików. Skrypt zatrzymuje aplikację, tworzy kopię poprzedniej wersji, wgrywa nowe pliki i uruchamia migrację bazy. Ten sam skrypt działa zdalnie przez pulpit, więc wdrożenie nie wymaga wizyty. Przed każdą zmianą schematu wykonuje się kopię bazy, której poprawność sprawdza się osobnym poleceniem.

BACKUP DATABASE Aplikacja
  TO DISK = N'D:\Kopie\Aplikacja_przed_wdrozeniem.bak'
  WITH COMPRESSION, CHECKSUM, INIT;

RESTORE VERIFYONLY
  FROM DISK = N'D:\Kopie\Aplikacja_przed_wdrozeniem.bak'
  WITH CHECKSUM;

Opcja CHECKSUM sprawdza spójność stron w trakcie zapisu, a VERIFYONLY potwierdza, że plik da się odczytać. Nie zastępuje to próbnego odtworzenia na osobnym serwerze, które jest jedynym pełnym dowodem, że kopia działa. Zasady tworzenia i odtwarzania kopii opisuje dokumentacja kopii zapasowych SQL Server w Microsoft Learn.

Reguła: wdrożenie bez zapisanej kopii bazy i planu wycofania nie rozpoczyna się, nawet gdy zmiana wydaje się drobna.

Wycofanie polega na przywróceniu poprzedniego pakietu aplikacji i kopii bazy. Dlatego migracje schematu projektuje się tak, aby dało się je cofnąć albo aby poprzednia wersja aplikacji działała na nowym schemacie przez okres przejściowy. Takie podejście zmniejsza ryzyko, że błąd po wdrożeniu zatrzyma pracę klienta na dłużej niż kilkanaście minut.

Oprogramowanie na zamówienie a gotowy WMS

Klient z branży logistycznej często stoi przed wyborem: napisać aplikację od zera albo skonfigurować gotowy system. W magazynie pytanie brzmi, czy potrzebny jest w ogóle WMS, czyli system zarządzania magazynem. System taki pozwala zautomatyzować kompletację, wskazywać pracownikom zadania i śledzić stany na bieżąco. Argumenty za wdrożeniem zebrano na stronie producenta w materiale czy WMS jest potrzebny w magazynie.

Gotowy system jest sensowny, gdy proces mieści się w typowym modelu magazynowym. Oprogramowanie na zamówienie zyskuje przewagę tam, gdzie procesy są nietypowe albo gdy trzeba połączyć kilka systemów w jedną ścieżkę pracy. Szczegóły produktu opisuje artykuł o systemie zarządzania magazynem WMS, a podejście producenta do wdrożeń przedstawia tekst o programie magazynowym SoftwareStudio.

Skalowalność ma w obu przypadkach ten sam sens: system powinien obsłużyć większą liczbę użytkowników i dokumentów bez przebudowy. Osiąga się to przez indeksy w bazie i krótkie transakcje, a nie przez samo dołożenie sprzętu. Przy dedykowanym oprogramowaniu te elementy projektuje się od początku, a przy gotowym sprawdza się je w teście wydajności przed startem.

Wsparcie po wdrożeniu na odległość

Po uruchomieniu zgłoszenia trafiają do systemu obsługi zgłoszeń, w którym każde ma numer i priorytet oraz historię. Klient opisuje problem, dołącza zrzut ekranu i godzinę zdarzenia. Wykonawca łączy się z serwerem przez uzgodniony kanał, odczytuje dziennik błędów aplikacji i odtwarza sytuację na środowisku testowym, zamiast zgadywać przyczynę.

Umowa serwisowa powinna określać dwie wartości: czas reakcji na zgłoszenie i czas usunięcia usterki, osobno dla awarii i dla drobnych uwag. Awaria zatrzymująca pracę magazynu ma wyższy priorytet niż literówka w raporcie. Osobno ustala się dopuszczalny okres utraty danych oraz czas przywrócenia usługi, co wynika z częstotliwości kopii zapasowych.

Wizyta na miejscu bywa potrzebna przy sprzęcie. Terminale mobilne oraz drukarki etykiet i czytniki wymagają fizycznej konfiguracji, a aplikacja na terminalu musi zostać sprawdzona w warunkach hali. Wybór urządzeń i zarządzanie ich flotą opisują artykuły o aplikacji magazynowej na Androidzie oraz o wdrożeniu programu z systemem MDM.