Współpraca z software house – jak ocenić kompetencje przed podpisaniem umowy?
- Magdalena Buda
- 6 maj 2024
- 4 minut(y) czytania
Większość firm poszukujących partnera IT skupia się przede wszystkim na weryfikacji doświadczenia, portfolio projektów i referencji. Oczywiście, są to ważne dane wskazujące na jakość pracy, ale nie zawsze dostarczają pełnego obrazu kompetencji technicznych potencjalnego wykonawcy. Zdarza się, że świetnie przygotowana prezentacja czy nawet spora liczba zrealizowanych projektów nie idą w parze z wysoką jakością kodu lub przemyślaną architekturą.
Z perspektywy biznesowej może to oznaczać dodatkowe koszty i ryzyka. Niska jakość kodu będzie generować częste błędy na produkcji, co może skutkować utratą klientów, wyciekiem danych osobowych, problemami prawnymi, a w rezultacie zniszczeniem reputacji. Z kolei niewłaściwa architektura może utrudnić rozwój nowych funkcjonalności, wydłużyć time-to-market i zmniejszyć konkurencyjność produktu.
W związku z tym rekomendujemy rozszerzyć klasyczny proces weryfikacji dostawcy o:
· sprawdzenie standardów kodowania
· zrozumienia podejścia do architektury
· weryfikację referencji wystawionych w pewnym odstępie czasu od wdrożenia. Dlaczego? Sam fakt dostarczenia działającej aplikacji nie gwarantuje łatwego rozwoju i utrzymania. Warto zweryfikować opinie Klientów po dłuższym korzystaniu z systemu.
przed podpisaniem umowy. Pozwala to zminimalizować ryzyko współpracy z zespołem, który „ładnie mówi”, ale ostatecznie dostarcza oprogramowanie trudne w utrzymaniu i rozwoju. W dalszej części tekstu przedstawiono konkretne obszary i narzędzia, na które warto zwrócić uwagę już na etapie wstępnych rozmów.
Jakie certyfikaty weryfikować?
Warto zwrócić uwagę nie tylko na certyfikaty stricte techniczne (takie jak np. AWS Certified Solutions Architect, Microsoft Certified: Azure Developer Associate, Oracle Certified Professional Java Programmer etc.), ale także na te związane z prowadzeniem projektów informatycznych i szeroko pojętym zarządzaniem.
W kontekście metodologii warto sprawdzić, czy członkowie zespołu posiadają certyfikaty z zakresu Agile, takie jak Scrum Master czy Product Owner, a także potwierdzenia kompetencji w ramach standardów zarządzania projektami, np. PMP (Project Management Professional) czy PRINCE2. Dodatkowo, przy rozbudowanych projektach kluczowa może być weryfikacja umiejętności w obszarze DevOps (np. certyfikaty Kubernetes lub Docker).
Posiadanie odpowiednich certyfikatów nie jest oczywiście gwarancją wysokiej jakości usług, ale jest sygnałem, że zespół inwestuje w podnoszenie kompetencji i rozumie najnowsze trendy oraz dobre praktyki rynkowe. W połączeniu z analizą kodu, architektury i referencji pozwala to na pełniejszą ocenę, czy potencjalny partner faktycznie dysponuje zespołem o potrzebnych kwalifikacjach – zarówno od strony technicznej, jak i w zakresie sprawnej realizacji przedsięwzięć IT.
Jak zweryfikować podejście architektoniczne?
Skalowalność i odporność na awarie
Jednym z kluczowych pytań, jakie warto zadać potencjalnemu partnerowi, jest to, jakich rozwiązań i wzorców używa, aby zapewnić:
Skalowalność aplikacji (np. wykorzystanie wzorców projektowych typu Microservices, CQRS czy architektur opartych na zdarzeniach).
Mikroserwisy ułatwiają skalowanie poszczególnych elementów systemu, ale wymagają rozbudowanej infrastruktury i zaawansowanej koordynacji wdrożeń (deploymentów).
Monolit jest często prostszy w realizacji przez niedoświadczone zespoły, jednak skalowanie aplikacji tego typu to staje się trudne i kosztowne.
Odporność na awarie (np. wdrożenie mechanizmów automatycznego restartu usług, load balancingu, monitoringu przy pomocy narzędzi typu Prometheus czy New Relic).
Warto również spytać o bezpieczeństwo (np. czy software house ma doświadczenie w stosowaniu protokołów uwierzytelniania typu OAuth2, JWT), doświadczenia w budowaniu aplikacji zgodnych z OWASP, w testach penetracyjnych oraz zgodność z przepisami (np. RODO). Zaniedbania w tych obszarach mogą wiązać się z karami finansowymi i utratą reputacji.
Technologiczne stacki i zgodność ze standardami
Warto przyjrzeć się stosowanym przez zespół językom programowania, frameworkom i bibliotekom. Oczywiście, nie chodzi o to, by na siłę naciskać na określoną technologię, ale raczej o zrozumienie czy software house sięga po rozwiązania:
Powszechnie uznane za niezawodne i dojrzałe (np. Java, .NET, Node.js, Python).
Aktualizowane i mające silne wsparcie społeczności (w przypadku frameworków np. React, Angular, Django, Spring). W wymaganiach na projekt powinno znaleźć się informacja o możliwości wykorzystywania tylko wspieranych bibliotek (nie mylić z opensource!). Chodzi o to, aby ostatnia aktualizacja bibliotek była nie starsza niż np. 6 miesiecy czy rok).
Firmy, które stosują zdezaktualizowane rozwiązania lub nie potrafią uzasadnić swojego wyboru technologii, mogą generować dodatkowe koszty w przyszłości, związane z migracją do nowszych platform.
Rola DevOps i ciągłego utrzymania
Nawet najlepszej jakości kod i przemyślana architektura nie wystarczą, jeśli zabraknie solidnego wsparcia w obszarze DevOps i utrzymania:
DevOps łączy kompetencje deweloperskie z doświadczeniem w obszarze wdrażania i zarządzania infrastrukturą.
CI/CD (Continuous Integration/Continuous Delivery) umożliwia szybkie wdrażanie nowych wersji aplikacji i automatyzację testów. Pozwala to minimalizować ryzyko błędów i szybko reagować na zmieniające się potrzeby rynku.
Monitoring i alertowanie (np. Prometheus, ELK Stack, New Relic) są kluczowe dla szybkiego wykrywania awarii i przewidywania problemów z wydajnością
Statyczna analiza kodu wraz z dependency check!!
Podsumowanie i kolejne kroki
Współpraca z software house powinna rozpocząć się od świadomej weryfikacji kompetencji. Weryfikacja certyfikatów oraz rozmowa o podejściu do testów, dokumentacji i dobrych praktyk pozwalają wypracować podstawę do dalszej, świadomej współpracy.
Dodatkowo, zrozumienie podejścia architektonicznego potencjalnego partnera — szczególnie w kontekście skalowalności, bezpieczeństwa i odporności na awarie — pomoże w uniknięciu problemów związanych z szybkimi zmianami rynkowymi czy wzrostem ruchu użytkowników. Warto też zweryfikować, czy firma posiada kompetencje DevOps i dba o odpowiednie wdrożenia (CI/CD), dzięki czemu projekt będzie się rozwijał bez zbędnych opóźnień i awarii. Dzięki temu proces wyboru software house’u nie ograniczy się do oceny powierzchownych kryteriów, lecz stanie się inwestycją w długoterminową stabilność i rozwój oprogramowania – zarówno od strony technicznej, jak i biznesowej.
