Tworzenie produktów: jak powstają nowoczesne produkty IT

1. „Ludzie już się nie rodzą, ich wychowują”

No cóż, skoro nadal tu jesteś, to kontynuujmy. „A ja pokażę Ci, jak głęboka jest królicza nora” © 🐇

Pozwól, że opowiem Ci, jak wygląda proces development produktu — przejdziemy przez kroki od najbardziej ogólnego poziomu do samego kodu. Myślę, że czekają Cię ciekawe odkrycia…

Nowoczesne produkty IT nie są już „pisane”, one są „tworzone”. Składa się je z bibliotek, frameworków, zewnętrznych programów i produktów albo korzysta się z zdalnych płatnych lub darmowych internetowych usług 🧩.

Nowoczesny produkt to cały zoo technologii, usług, rozwiązań i procesów. Część pracy wykonują ludzie, część jest zautomatyzowana, a reszta 90% jest obsługiwana przez chmury w data-centers ☁️. Świat już nie jest taki jak kiedyś.

Ale pierwszą rzeczą, na którą zwrócisz uwagę — to ciągłe zmiany. Już nie piszesz programów, wprowadzasz w nie zmiany.

2. Ciągłe zmiany

Przyjdziesz do pracy i dołączysz do zespołu z 20 osób, które od 5 lat pracują nad produktem. Obecnie użytkownicy mają dostęp do jego 7. wersji. Twoim zadaniem będzie wprowadzanie zmian do tego produktu. Małych, żeby nie odstraszyć obecnych aktywnych użytkowników.

I to nie będzie łatwe, bo produkt już działa. Ma klientów, którzy płacą 💰. Więc niczego nie można zepsuć. Wprowadzanie zmian do już działającego produktu jest kilka razy trudniejsze niż do nowego. Do tego służą specjalne standardy, protokoły migracji i narzędzia. Od razu przypomina się anegdota:

Spotykają się dwaj starzy znajomi: jeden został mechanikiem, drugi - chirurgiem... Każdy ma swoje życie, troski, radości... Opowiadają sobie wszystko, aż nagle zaczyna się rozmowa o zarobkach. Mechanik mówi: "No, ja dostaję 30 na miesiąc i jestem z tego bardzo zadowolony, a ty ile?". Chirurg mówi: "No, około 100K za operację...". W tym momencie mechanik zainteresował się: "Dziwne, czemu taka duża różnica? Przecież robimy to samo - wymieniamy części". A chirurg mu mówi: "No, chodźmy do samochodu, zapal silnik...". Mechanik odpala samochód, chirurg otwiera maskę i mówi mechanikowi: "Widzisz, silnik działa? Wymień go!" 😂

Nawet jeśli zdarzy się cud i Twój zespół przez cały rok pisał produkt od zera i dopiero potem go wypuścił, wiesz, co się stanie dalej? Jeśli Twój produkt odniesie sukces, właściciel produktu będzie chciał go rozwijać. Wypuścić nową wersję, dodać funkcjonalność. Albo chociaż przeprowadzić kilka eksperymentów. I co za tym pójdzie? Zmiany 🙈

3. Wartość produktu

Z punktu widzenia nowoczesnego developmentu, wartość ma tylko ten kod, który już jest wdrożony, oraz funkcja, z której korzystają użytkownicy. Jeśli napisałeś kod, on gdzieś jest przechowywany, działa, ale nie korzystają z niego ludzie, to jego wartość jest bliska zeru. Dlatego cały kod musi jak najszybciej trafić na production 🚀

Twój kod musi przejść przez takie etapy:

• ✔️ Napisałeś go i upewniłeś się, że działa.
• 🔍 Twój TeamLead go przejrzał i dodał do głównej gałęzi w Git.
• 🧪 Testy podczas builda pokazały, że nic ważnego nie zepsułeś.
• 🧩 Testy integracyjne pokazały, że produkt działa jak trzeba.
• 🛡️ Tester zatwierdził ten kod do release'u.
• 📦 Następnie trzeba zbudować nową wersję produktu i wypuścić ją na serwer.
• 🐳 Nową wersję trzeba spakować w Docker Images i wypuścić.
• 🗄️ Może trzeba uruchomić migracyjne skrypty i zmienić bazę danych lub inne zewnętrzne rozwiązania.
• 📊 Potem trzeba zebrać logi na serwerze, żeby upewnić się, że wszystko działa jak trzeba.
• ⏪ W razie awarii, jeśli coś się zepsuje, trzeba cofnąć build, przywrócić poprzedni stan bazy danych i nie stracić działań użytkowników, którzy korzystali z niestabilnej wersji produktu.

W większości firm te zadania są już rozwiązane: wypracowano nowe procesy, zatrudniono specjalistów, wprowadzono protokoły bezpieczeństwa i standardy kontroli jakości. Im większa firma, tym krócej od napisania kodu do momentu, gdy trafi na production i zacznie przynosić wartość — pomagać ludziom.

W większości firm kod przechodzi tę drogę w ciągu dwóch tygodni. Są też firmy, które robią release co tydzień albo nawet codziennie. Wyjątkowe jednostki — kilka razy dziennie.

Napisany kod nic nie znaczy. Wartość przynosi tylko kod działający na production.