Zmiana dostawcy oprogramowania

Często zdarza się, że oprogramowanie w trakcie rozwoju musi zostać przeniesione pomiędzy dwoma zespołami programistów lub nawet między dwoma, różnymi firmami. Zazwyczaj zawsze istnieją jakieś formy motywacji dla tej zmiany. Przekazanie rozwoju oprogramowania może być spowodowane przyczynami biznesowymi i technicznymi, takimi jak słabe wyniki, powolne tempo rozwoju oprogramowania lub inne motywy.

Różne części oprogramowania mogą wymagać różnych typów ekspertów, stąd potrzeba różnych zespołów.

Może to skutkować outsourcingiem części projektu, budową MVP (Minimum Viable Product) lub PoC (proof of Conctpt) z partnerem w rozwoju oprogramowania, utrzymaniem kodu, skalowaniem aplikacji, aktualizacją lub po prostu dopracowaniem.

Czy byłoby dobrze, gdybyśmy zignorowali tak ważną dyskusję, wiedząc doskonale, że czy to teraz, czy w przyszłości, może zaistnieć potrzeba dokonania zmian w projekcie rozwoju oprogramowania? Oczywiście, że nie. Dlatego w dzisiejszym artykule przyjrzymy się najlepszemu podejściu do płynnego przejścia projektu rozwoju oprogramowania.

Poznaj powody zmiany zespołu programistów

Niezależnie od częstotliwości występowania zmian, największym pytaniem jest "Czynnik Dlaczego". W końcu bardzo ważne jest, aby dokładnie określić, dlaczego istnieje potrzeba zmiany zespołu programistów.

Dla właścicieli produktów, którzy nie mają wiedzy technicznej, wciąż jest dylematem, jakie wymagania są najbardziej potrzebne, aby przekazać kolejnemu zespołowi projektu rozwoju oprogramowania. Może to powodować wiele opóźnień, a w zamian wywoływać irytację, wywierać presję na osoby zaangażowane w projekt i powodować możliwą utratę zainteresowania.

Pytanie o przyczyny rzuci światło na główny powód przejścia i najlepszy sposób, w jaki można to zrobić. Pozwoli to określić, jakie będą oczekiwania właściciela projektu, jakiej wielkości będzie nowy zespół i jakich pułapek należy stąd unikać.

Kilka najczęstszych powodów zmiany firmy zajmującej się tworzeniem oprogramowania:

Niedostateczna wydajność. Czasami Twoje oczekiwania nie zostaną spełnione po rozpoczęciu pracy z konkretnym dostawcą. Lub, być może, problemy pojawiają się w połowie drogi rozwoju oprogramowania i zdajesz sobie sprawę, że twój partner rozwoju nie może dostarczyć tego, co zostało uzgodnione. W takiej sytuacji, może warto zmienić dostawcę oprogramowania.

Problemy z zaufaniem. Jeśli Twój dostawca nie jest z Tobą szczery i ukrywa błędy, które popełnił lub nalicza niespodziewane opłaty, być może nadszedł czas, aby rozważyć zmianę firmy programistycznej, z którą pracujesz. W końcu brak zaufania i otwartej komunikacji może całkowicie zatrzymać Twój projekt rozwoju oprogramowania.

Twój projekt nie jest priorytetem. Po zakończeniu negocjacji i podpisaniu umowy, niedoświadczeni sprzedawcy mogą przestać nadawać priorytet twojemu projektowi i ponownie skupić się na pozyskiwaniu nowych klientów. Jeśli więc zauważysz, że terminy wciąż się przesuwają, jest słaba koordynacja i nieporządek w pracy, być może nadszedł czas, aby zmienić swojego partnera w dziedzinie rozwoju oprogramowania.

Potrzeba mikrozarządzanie. Zatrudniasz zewnętrzny zespół programistów, ponieważ albo brakuje Ci możliwości wewnętrznych, albo nie chcesz poświęcać zbyt wiele czasu na pracę nad nowym rozwiązaniem. Oczywiście, Twoje zaangażowanie jest konieczne, ale kiedy widzisz, że wynajęty zespół działa dobrze tylko wtedy, kiedy Ty go mikrozarządzasz - jest problem.

Wypowiedzenie umowy. Jeśli twój dedykowany dostawca oprogramowania powiadomił cię, że chce zakończyć umowę przedwcześnie, może nie mieć innego wyjścia, jak szukać nowego partnera.

Jak zmienić dostawcę oprogramowania?

Teraz, gdy zidentyfikowaliśmy, dlaczego możesz być zmuszony do zmiany dostawcy dla następnego projektu oprogramowania, nadszedł czas, aby omówić kluczowe rzeczy, które trzeba będzie pamiętać, aby przygotować się do przejścia i zapewnić, że rozwój oprogramowania idzie gładko.

Planowanie jest kluczowe

Plan przejścia zespołu programistów

Po określeniu, dlaczego istnieje potrzeba przejścia, pierwszą rzeczą, której potrzebujesz, jest odpowiednie planowanie. Na tym etapie ważne jest podkreślenie następujących kwestii, aby rozpocząć proces transformacji.

Cel przejścia: Lista tego, czego można się spodziewać częściowo i w całości, co dokładnie zostanie zrobione i jak, czy to debugowanie, upscaling, konserwacja lub integracja różnych części projektu.

Mapa drogowa: Ważne jest, aby określić etapy rozwoju oprogramowania i ogólny zakres zadań. Należy zająć się backlogiem, bieżącym wsparciem, priorytetyzacją i wizjami funkcji, które mają być rozwijane.

Organizacja: Wszystko zaczyna się od otwartej agendy, jednak wszystko zależy od rodzaju projektu. Do typowego potrzebujesz zespołu składającego się z kierownika projektu, analityka biznesowego, inżyniera QA, starszego programisty i architekta. Będziesz również potrzebował DevOps do i rozwoju. Oczywiście, konieczne jest samodzielne zaangażowanie, jak również aktywne podejmowanie decyzji przez właściciela projektu.

Poznaj produkt

Poznaj projekt oprogramowania

Jako właściciel produktu, powinieneś być dobrze poinformowany o podstawowych technologiach zaangażowanych w projekt. Jesteś winien sobie obowiązek posiadania pewnego know-how, nawet jeśli nie jesteś osobą obeznaną z technologią. Powinieneś rozumieć, jak działa twoja aplikacja.

Oto lista rzeczy, o których powinieneś być w stanie mówić, nawet jeśli dopiero dołączyłeś do zespołu:

Metoda zarządzania projektami. Jest ich kilka, a trzy najlepsze to Agile, Scrum i Kanban. Niezależnie od wyboru, który został dokonany, aby był wykorzystany w Twoim projekcie, musisz znać jego relatywność do procesu produkcji i wiedzieć, jak bardzo jest korzystny.

Stos technologiczny. Nawet jeśli masz pomysł, zrozumienie stosu technologicznego projektu to poważna sprawa. Ze wszystkich wspólnych i zwykłych frameworków dla back-end i front-end, powinieneś wiedzieć, które z nich są używane w Twoim projekcie.

Dowiedz się, jak wybrać odpowiedni stos technologiczny dla swojego projektu. Zapoznając się z mocnymi i słabymi stronami swojego stosu technologicznego, będziesz miał lepszy pomysł na to, jak działa aplikacja i jak będzie się zachowywać w przyszłości. Ta wiedza może znacznie ułatwić proces wyboru firmy do rozwoju oprogramowania, ułatwić komunikację z zespołem programistów i pozwolić Ci być na tej samej stronie z nimi podczas rozwiązywania problemów.

Usługi stron trzecich. Musisz być w stanie powiedzieć, czy Twoja aplikacja jest zbudowana na niektórych usługach stron trzecich, które są powszechnie wykorzystywane. W niektórych przypadkach możesz nawet potrzebować więcej niż jednego rozwiązania firm trzecich, w zależności od tego, jak duży jest projekt rozwoju oprogramowania.

Platformy. Informacje o platformach, na których może działać Twoja aplikacja, muszą być na wyciągnięcie ręki. Powinieneś wiedzieć, czy jest to aplikacja mobilna lub webowa, rozwiązanie desktopowe, czy tylko responsywna strona internetowa; czy działa na jednej czy wielu platformach. Musisz być świadomy mocnych i słabych stron każdej z platform. Skup się na tej, która ma największy priorytet w oparciu o Twoje cele. W przypadku aplikacji mobilnych, jeszcze ważniejsze jest rozróżnienie, czy jest to aplikacja międzyplatformowa, natywne rozwiązanie dla systemu iOS, czy natywne narzędzie dla systemu Android.

Host. Technologia chmury jest obecnie modna, jeśli chodzi o hosting. Jednak zarówno nowe, jak i ortodoksyjne hosty mają różne metody wdrażania, a doświadczenie jest w tym przypadku kluczowe. Musisz wiedzieć, jaki host używasz i co spowodowało twój wybór.

Proces rozwoju. Informacje o twoim narzędziu do zarządzania źródłem aplikacji jest bardzo istotne. Jeśli używasz na przykład Git, powinieneś znać proces tworzenia, testowania, zatwierdzania i wdrażania nowych funkcji. Wszystko musi być zgodne ze standardowymi wymaganiami.

Przygotuj szczegółową dokumentację

Przygotuj szczegółową dokumentację oprogramowania

Z chęci do zaimponowania swojemu klientowi, większość freelancerów i niezależnych programistów rozpoczyna pracę nad istniejącymi kodami niemal od razu. Robią to bez intensywnego przeglądu kodu z zamiarem zaimponowania klientowi.

Dobrze opracowana dokumentacja jest głównym czynnikiem wpływającym na szybkość procesu transformacji. Zapewnia ona wgląd, pomaga uniknąć luk i upraszcza cały proces rozwoju oprogramowania.

Przejdźmy teraz do kolejnych pytań. Jakie są cechy dobrej dokumentacji płynnej zmiany dostawcy oprogramowania? Jakie atrybuty powinniśmy brać pod uwagę i na co zwracać uwagę?

Dobra dokumentacja oprogramowania powinna obejmować zagadnienia:

Jak skonfigurować środowisko programistyczne. Pierwszą rzeczą do zrobienia w projekcie dla każdego nowego członka zespołu jest upewnienie się, że aplikacja jest uruchomiona na ich komputerach. Proces ten może być różny w zależności od technologii. Zazwyczaj potrzebny jest do tego kod źródłowy, a także zainstalowane zależności, baza danych, import przykładowych danych, ustawienie kluczy API i innych poświadczeń. Programiści są dobrze poinformowani o tym procesie.

Uruchom automatyczny zestaw testów. Przejście testów aplikacji pokazuje, że aplikacja została skonfigurowana prawidłowo i wszelkie dalsze zmiany nie będą miały wpływu na stare funkcje.

Wdrożenie aplikacji mobilnej na serwer testowy i produkcyjny. Serwer testowy jest ostatnim krokiem prowadzącym do wdrożenia aplikacji na serwer produkcyjny. Dzięki niemu programiści mogą przetestować swój kod, aby wiedzieć, czy aplikacja będzie działać z innymi częściami aplikacji. Ważne jest, aby sprawdzić proces krok po kroku z najwyższymi szczegółami. To sprawdzenie powinno zawierać aktualizacje aplikacji na żywo, ostatnie zmiany i kolejność działań.

Dodatkowe szczegóły dla nowych członków zespołu

Udokumentowanie błędów popełnionych przez poprzedni zespół pomoże nowym członkom zespołu zaoszczędzić czas na powtarzających się problemach i wiedzieć, jak sobie z nimi radzić.

Procesem dokumentacji powinien zajmować się programista, który ma duże doświadczenie w tworzeniu aplikacji i ma znaczący wkład w tworzenie kodu aplikacji. Punktem odniesienia dla każdej szczegółowej dokumentacji projektu jest to, jak szybko programista może ją wykorzystać do skonfigurowania działającej aplikacji w oparciu o jego środowisko programistyczne.

Istnieją przypadki, w których programista może nie posiadać wymaganych umiejętności pisania. W takim przypadku może on nagrać screencasty, aby pokazać konfigurację środowiska programistycznego, wdrożenie aplikacji mobilnej i tak dalej.

Przejmij kontrolę nad zarządzaniem dostępem

Odpowiedzialność i własność

To jest bardzo wrażliwa część procesu przejęcia rozwoju oprogramowania. Podczas podpisywania umowy deweloperskiej z dowolnym zespołem, upewnij się, że umowa upoważnia Cię do ochrony, aby zapewnić łatwe przejście w przypadku konieczności zmiany zespołu. Istnieje długa lista usług i narzędzi stron trzecich używanych w różnych projektach, nie ma prawie żadnego projektu, który jest z tego zwolniony.

Niektóre zespoły w imieniu właścicieli projektów zakładają konta, aby korzystać z potrzebnych usług lub narzędzi. W niektórych przypadkach korzystają z własnych kont. Funkcjonalność aplikacji zależy od tych narzędzi i usług. Stąd właściciel projektu musi przejąć kontrolę i własność.

Poprzednie zespoły odpowiadające za rozwój oprogramowania powinny zostać poinstruowane, aby stwierdzić stosowne narzędzia i usługi stron trzecich i przenieść własność. Inną alternatywą jest stworzenie nowych kont użytkowników dla Ciebie, aby zastąpić ich. W tym przypadku należy przełączyć ustawienia konfiguracyjne dla aplikacji.

Nadawanie dostępu nowemu zespołowi odpowiadającemu za rozwój oprogramowania

Istnieje potrzeba, abyś zapewnił łatwy dostęp i przepływ komunikacji między zespołem odchodzący oraz przejmującym rozwój oprogramowania. Może to być zarządzane bezpośrednio lub przez Ciebie w fazie przejściowej lub w miarę potrzeb.

Musisz również przekazać nowym programistom wszystkie dostępy do różnych narzędzi i usług używanych w Twojej aplikacji. Możesz być sceptycznie nastawiony do przekazywania dostępu do narzędzi i usług stron trzecich. To dlatego, że możesz nie posiadać pełnej wiedzy, co może sprawić, że przejście będzie trudne.

Aby być pewnym wszystkiego, możesz aktywować konto współpracownika lub częściowy poziom dostępu. Większość właścicieli projektów, zwłaszcza osób prywatnych, zwykle daje pełny dostęp. Jest to powszechne, ale wybór nadal należy do Ciebie.

Wprowadzanie nowego zespołu deweloperskiego

Istnieje pewien model elementów, które pomagają właścicielom projektów w przygotowaniu się do zmiany zespołu deweloperskiego, co mogliśmy zaobserwować do tej pory. Po zapoznaniu się ze wszystkimi szczegółami projektu i mając pojęcie o wszystkich usługach i technologiach, które wchodzą w skład tworzenia oprogramowania, wprowadzenie nowego zespołu odpowiedzialnego za rozwój oprogramowania staje się łatwe.

"Co mam zrobić, jeśli tylko częściowo wymieniam zespół?", możesz zadać sobie pytanie.

Istnieje możliwość, że będziesz chciał zatrzymać niektórych kluczowych graczy ze starego zespołu. Nie jest to jednak gwarancja, że będą oni posiadać wszystkie kluczowe informacje dla płynnego przejścia. Mogą być odpowiedzialni za pewną formę ciągłości i przekazywania istotnych informacji między zespołami, ale to właściciel projektu powinien być głównym facylitatorem przejścia.

Jako właściciel projektu rozwoju oprogramowania musisz unikać tarć między starym i nowym zespołem, koordynować zadania, unikać opóźnień w rozwiązywaniu zadań i kilku innych kwestii.

Nawet jeśli niektórzy członkowie starego zespołu nie zostaną zmienieni, mogą być zbędni w procesie transformacji. Jednak nadal mogą dzielić się pewnym doświadczeniem i mogą być dobrym punktem odniesienia dla niektórych szybkich konsultacji. Tak czy inaczej, nie zawracaj im głowy niczym, co możesz zrobić sam.

Przekazanie "stanu przejściowego"

Sprowadzenie nowego zespołu odpowiedzialnego za rozwój oprogramowania

Po rozważeniu wszystkiego, co wymieniliśmy i omówiliśmy powyżej, musisz skoordynować ostateczne przejście ze starego zespołu do nowego. Stąd warto rozważyć następujące kwestie:

• Wszystkie kody źródłowe muszą znajdować się w głównym repozytorium. Znajomość aktualnego stanu kodu i tego, co zostało wdrożone, jest niezbędna. Pomoże Ci to uniknąć duplikatów pracy, błędów i innych wąskich gardeł. Lista defektów i błędów powinna być pod ręką.
• Bądź dyplomatyczny ze starym zespołem, unikaj konfrontacji. Staraj się rozstać na dobrych warunkach, utrzymuj komunikację i łatwy dostęp, ponieważ możesz potrzebować konsultacji lub wyjaśnienia niektórych rzeczy nawet po przejściu. Podziękuj im za ich pracę i doświadczenie, a także ureguluj wszystkie zaległe płatności.
• Ustal cele i zadania dla nowego zespołu, aby znali Twoje oczekiwania i posiadali taki sam obraz potrzeb jak ty, założenia mogą być fatalnym błędem w tym przypadku.
• Upewnij się, że dajesz nowemu zespołowi trochę czasu na zbadanie projektu, przegląd kodu i testowanie. Nie oczekuj od nich, że od razu napiszą nowy kod. Ten krótki onboarding pomoże uniknąć wielu pułapek w przyszłości.
• Zarządzaj nowymi deweloperami z cierpliwością. Świetne aplikacje nie są budowane z dnia na dzień. Bądź hojny w stosunku do potrzeb projektu, włączając w to pozytywne emocje i wsparcie, jednocześnie unikając wywierania niepotrzebnej presji.

Ostatnie kluczowe punkty dotyczące przekazania projektu

Unikaj niepokoju i strachu przed porażką poprzez odpowiednie planowanie w miarę zdobywania bardzo dobrej wiedzy o swoim produkcie. Dodatkowo, nie zapominaj o motywowaniu swoich nowych programistów do przestrzegania wysokich standardów. Pamiętaj, że Twoim zamiarem w przypadku idealnego przejścia jest zaoszczędzenie czasu, wysiłku, zasobów i finansów.

Jeszcze raz, przejdźmy do najważniejszych kwestii związanych z przejściem projektu rozwoju oprogramowania:

• Musi istnieć konkretny powód przejścia, w przeciwnym razie cel może zostać nieosiągnięty.
• Musisz mieć mapę drogową projektu, wiedzieć dokładnie, jak chcesz, aby proces przebiegał i mieć jasną wizję tego, jaki powinien być efekt końcowy.
• Ogólna, ale dość szczegółowa wiedza o Twoim produkcie rozwoju oprogramowania jest niezbędna, takie rzeczy jak stos technologiczny, usługi stron trzecich, hosty itp.
• Nie można uciec od potrzeby dokumentacji i zaoszczędziłoby to wiele czasu i wysiłku, gdyby była ona dobrze sprecyzowana, obejmując wszystkie najważniejsze elementy.
• Powinieneś mieć dostęp do wszystkich usług stron trzecich, przekazać je do nowego zespołu wraz z każdą inną potrzebą dla projektu.
• Poproś nowy zespół o regularne raporty i spotkania, daj im potrzebne wsparcie, odpowiedni czas i utrzymać dobrą komunikację.

Przy przestrzeganiu wszystkich uwag zawartych w tym artykule, transformacja każdego projektu będzie udana bez większych wad, o ile wchodzący zespół jest kompetentny.

Doświadczony zespół może znacząco ułatwić proces transformacji i z powodzeniem doprowadzić projekt do końca. W Commint jesteśmy zawsze chętni do pomocy. Sprawdź więc nasze usługi w zakresie rozwoju aplikacji dedykowanych.