Przejmowanie systemu w rozwój i utrzymanie to trochę niewdzięczne zajęcie. Oczywiście, z jednej strony cieszy, że klient obdarzył Ciebie, czy Twoją firmę zaufaniem, że dasz radę przejąć system, bo oznacza to przekonanie ze strony klienta, że:

• rozumiesz jakie są jego zadania biznesowe,
• wiesz jak system technicznie te zadania realizuje (znasz technologię, koncepcje architektoniczne, rozumiesz integracje, przepływy danych, etc.)
• zapewnisz oczekiwany poziom dostępności,
• będziesz w stanie zaimplementować w nim nowe funkcje, jeśli zajdzie potrzeba
• naprawisz ew. błędy, które pojawią się w trakcie użytkowania

Ale oprócz tego, że klient obdarzył Cię takim zaufaniem jest jeszcze ta niewdzięczna robota oceny czyjejś pracy (np. w formie audytu przed przejęciem). Bardzo nie lubię tego robić i brzmieć jak glazurnik, który przychodzi położyć terakotę w przedpokoju, ale przy okazji wizyty w łazience nie omieszka powiedzieć co myśli o tym „patałachu” co kładł płytki („panie, to zaraz odpadnie”). Za długo już zajmuję się dostarczaniem oprogramowania na zamówienie, żeby nie wiedzieć, że jakość produktu końcowego jest pochodną wielu aspektów, m.in.:

• organizacji pracy na projekcie
• jakości analizy przedwdrożeniowej
• zaangażowania klienta w prace projektowe
• testów
• czasu na realizację
• dynamiki zmian na projekcie i tego jak sprawnie prowadzone jest zarządzanie zmianą
• wiedzy i doświadczenia programistów tworzących oprogramowanie (trochę celowo nie na pierwszym miejscu)

Jakość finalnego produktu jakim jest wdrożone oprogramowanie (czy to pisane na zamówienie, czy to dostosowywane pod danego klienta) jest sumą wielu czynników (głównymi będą te wymienione wyżej, ale lista ta nie jest zamknięta).

Jak zatem przejmować kod / aplikację, żeby nie wyjść na buca, a jednocześnie zaprezentować swój profesjonalizm?

Co w takim wypadku zrobić? Dokładnie to samo w przypadku, gdy ktoś spyta: „czy ta kiełbasa jest smaczna”? Nie wnikamy w to w jaki sposób kiełbasa powstawała, ale oceniamy jej smak. Nie robimy wycieczek ad personam typu: „co za debil to pisał”, bo generalnie to niewiele wnosi do sprawy (tamtego dostawcy już ze smutkiem lub radością klient pożegnał i nie ma co do tego wracać). Należy skupić się na tym, nad czym pracujemy i rzetelnie ocenić stan zastany, a nie opisywać własne imaginacje odnośnie tego, w jaki sposób do tego stanu doszło. Przykładowe wyniki takiego audytu wobec przejmowanej aplikacji mogą wyglądać następująco:

• kod jest nieczytelny – będą problemy w dalszym rozwoju aplikacji, a koszty i ryzyko będą rosły z każdą wdrażaną zmianą • aplikacja ma w sobie dziury bezpieczeństwa – korzystanie z niej może narażać użytkowników na utratę danych, a Twojego klienta na poważne konsekwencje
• brakuje dokumentacji biznesowej – nie do końca jest jasne jakie były cele poszczególnych modułów / fragmentów kodu, bo brak jest dokumentacji, która by te cele wyjaśniała; czasami absurdalność pewnych rozwiązań technicznych ma swój początek w „suboptymalnych” założeniach / wymaganiach biznesowych;
• brakuje dokumentacji technicznej – „kod jest najlepszą dokumentacją” – niby tak, ale jeśli kod jest nieczytelny, a brakuje nawet dokumentacji biznesowej, to przy wprowadzaniu zmian będzie sporo zaskoczeń
• aplikacja korzysta z przeterminowanych wersji języków programowania, frameworków, platform, etc. – brak aktualizacji może powodować dłuższe i kosztowniejsze cykle developerskie (brak np. kompatybilnych wersji bibliotek, które zarzuciły wsparcie dla starszych platform), ale też potencjalne ryzyka związane z bezpieczeństwem (np. twórcy platformy nie wypuszczają już aktualizacji bezpieczeństwa dla starszych rozwiązań)
• brak automatycznych testów – konieczność przeprowadzania manualnych testów regresji (potencjalnie całej aplikacji lub jej dużych obszarów) przy wprowadzaniu zmian w oprogramowaniu

Są to oczywiście tylko wybrane zagadnienia, czy problemy, które mogą pojawiać się w przejmowanej aplikacji. Dlatego, pomimo niechęci do recenzowania czyjejś pracy, audytowanie przejmowanej aplikacji jest oczywiście niezbędnym zadaniem z szeregu względów:

• uświadomienie klienta (jeśli nie jest jeszcze świadomy) odnośnie stanu bieżącego rozwiązania
• umożliwienie prawidłowej oceny ryzyka z Twojej strony, jako przejmującego rozwiązanie w rozwój i / lub utrzymanie (szczególnie ważne, jeśli podejmujesz zobowiązania związane z poziomem dostępności aplikacji, czy też odpowiedzialności np. za dane osobowe przetwarzane przez aplikację)
• ustalenie potencjalnego planu naprawczego i rozwojowego dla aplikacji
• podjęcie decyzji odnośnie tego, czy podejmiesz się zadania przejęcia aplikacji w utrzymanie na oczekiwanych przez klienta warunkach (czasami może się okazać, że jedyna możliwość to podejście „best effort”, bo przy zastanym stanie dziedziczonego rozwiązania jedyne czego mogą dotyczyć gwarancje to dostępności odpowiednich specjalistów ze strony Twojej / Twojej firmy)

Podsumowanie

Podsumowując, o ile sama czynność audytowania przejmowanej aplikacji może nie należeć do najprzyjemniejszych należy do niej podchodzić w taki sposób, aby recenzować jakość "produktu" i nie odnosić się do ludzi, czy procesu jaki doprowadził do powstania tegoż produktu. W ten sposób można zaprezentować swój profesjonalizm bez zbędnego "januszowania", które może zatrzeć wrażenie i przyćmić merytoryczną jakość argumentów. Oczywiście możliwe jest również audytowanie procesu, ale to już opowieść na osobną notkę (i inne zamówienie od klienta ;).