Cześć, nazywam się Alexander Maistrenko, jestem dyrektorem ds. technologii w Foxtrot.
W artykule opiszę dwa prawdziwe przypadki. W każdym z przykładów dogłębna wiedza techniczna PM mogłaby uchronić firmę przed stratami finansowymi i innymi problemami. Ze względu na różne okoliczności nie będę podawać nazw firm.
Utrata reputacji
Pierwszy przypadek jest świeżutki. Podczas przesyłania danych z front-endu do back-endu w dużym sklepie internetowym wykryto lukę w zabezpieczeniach. Każdy użytkownik frontendu mógł zmienić identyfikator produktu dodawanego do koszyka, co nie było w żaden sposób weryfikowane podczas backendu.
Grupa osób wykorzystała tę lukę. Dodali do koszyka i zapłacili za Playstation 5 – produkt, którego sklep nie ma na stanie. Odrzucili ofertę sklepu dotyczącą zwrotu pieniędzy i zażądali towarów, za które zapłacili. W związku z tym sklep jest zmuszony dostarczyć Playstation 5, chociaż konsola w rzeczywistości nie jest dostępna. Odpowiednio koszty finansowe spadają w całości na barki firmy.
Tymczasem temu problemowi można było łatwo zapobiec, gdyby PM rozumiał temat bezpieczeństwa i nalegał, aby programiści zastanowili się nad tym problemem, a nie pozwolili JS na wdrożenie. Dowiedz się więcej o tym, jak chronić produkt IT w kursie TechMind.
Utrata czasu
Pewna firma wpadła na pomysł opracowania narzędzia, które pomogłoby pracownikom szybciej i lepiej wykonywać swoją pracę. Tworząc własne rozwiązanie, firma spodziewała się zaoszczędzić pieniądze i nie kupować rozwiązań firm trzecich.
Natomiast, niestety, kierownik nie rozumiał, jakie pytania należy zadać na początku, więc na architekturę wybrano monolit. Powstało rozwiązanie i choć nie zastosowano “best practices”, narzędzie poradziło sobie ze swoim zadaniem. I wszystko byłoby dobrze, gdyby firma nie zdecydowała się sprzedawać narzędzia innym zainteresowanym jako SaaS.
Wraz ze wzrostem liczby klientów i funkcji systemu pojawiły się problemy z odpornością na błędy i wydajnością, a firma zaczęła ponosić straty reputacyjne i finansowe. Aby zrozumieć sytuację, zatrudniliśmy doświadczonego lidera zespołu. Stopniowo monolit zaczęto przenosić na architekturę mikroserwisową, a problemy praktycznie zniknęły. Jednak można było im całkowicie zapobiec, gdyby kierownik znał podstawy rozwiązań architektonicznych.
Jako Chief Technology Officer mogę powiedzieć, że jeśli menedżer ignoruje lub nie zwraca uwagi na kwestie techniczne w projekcie, straty są nieuniknione.
PM to osoba odpowiedzialna za dostarczenie projektu we właściwe miejsce i we właściwym czasie. Ale jak może przejąć pełną kontrolę nad procesem, kiedy nie jest jasne, dlaczego technicy wybierają takie lub inne rozwiązanie? Czy PM będzie w stanie przekonać klienta bez wiedzy technicznej do przeznaczenia środków na bezpieczeństwo, czy będzie możliwe zabezpieczenie zespołu przed klientem bez ciągłej pomocy leada technicznego? Być może uważasz, że menedżer nie powinien w ogóle zagłębiać się w szczegóły techniczne, a po prostu pozostawić planowanie ryzyka architektury, integracji, bezpieczeństwa zespołowi technicznemu? Ty decydujesz.