Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Wartość hardcodingu w Twoim projekcie

Allen Helton Software Engineering Manager / Tyler Technologies
Poznaj sposób na sprawniejsze dostarczanie oprogramowania i zbieranie feedbacku od użytkowników.
Wartość hardcodingu w Twoim projekcie

Wierzę w dwie rzeczy: w czas wprowadzenia produktu na rynek jest kluczem do sukcesu oraz w wartość iteracji ponad wszystko. Firmy wciąż zostają wciągane w wir przygotowywania się na każdą ewentualność przed wydaniem. Nie wiem jak wy, ale dla mnie to brzmi jak waterfall. A myślałem, że to już minęło. Czy byliście kiedykolwiek w sytuacji, w której Wasz zespół zobowiązał się do wykonania projektu w ciągu określonej liczby godzin, ale wyszło dłużej, bo część konfiguracji była nieco bardziej skomplikowana niż oczekiwano? A potem okazuje się, że Twoi klienci nawet jej nie używają?

Jest to frustrujące dla Ciebie, ponieważ spędzasz cały ten czas na opracowywaniu elastycznej konfiguracji, której nikt nie używa. Jest to również frustrujące dla klientów, ponieważ dostarczenie spóźnia się, przez opcje, których nie potrzebują.


Co należy zmienić?

Wykorzystaj hardcoding (lub sztywne kodowanie). Na początek zakoduj jak najwięcej rzeczy na sztywno, o ile nie jest wprost wymagane inne podejście. Szybko dostarcz produkt konsumentowi. Pokaż, co im się podoba, a co nie. Zdziwisz się, jak wiele osób obejdzie się bez konfiguracji, której rzekomo potrzebują. Spójrzmy na następujący przykład.

Twój zespół jest odpowiedzialny za stworzenie aplikacji do zamawiania kanapek. Aplikacja przedstawia użytkownikom listę składników, które mogą wybrać przed wysłaniem. Po złożeniu zamówienia trafia ono do kucharzy, którzy następnie je przetwarzają i dostarczają do Ciebie jedzenie na rowerze. Bardzo w stylu 2019. Ktoś z Twojego zespołu wpadł na pomysł wprowadzenia „zwykłej” koncepcji. Użytkownik loguje się, ustawia składniki na zamówioną kanapkę i zapisuje. Aplikacja pozwala teraz zamówić jedzenie jednym kliknięciem.

Ktoś inny sugeruje dodanie konfiguracji dla kucharzy, aby zaznaczyć, kiedy dany składnik jest niedostępny. Wydaje się to konieczne, aby nie mieć w zamówieniu brakujących składników. Inna osoba mówi, że potrzebujesz członkostwa priorytetowego. Ludzie mogą za nie płacić, aby ich zamówienia automatycznie trafiały na górę kolejki. Płać więcej, czekaj mniej.

Nie mija dużo czasu, a masz listę funkcji i konfiguracji, które podwoiły lub potroiły czas wprowadzenia apki na rynek. Co robisz? Opóźniasz wydanie?

Nie.

Zakoduj na stałe to, co możesz. Pomiń niepotrzebne funkcje. Przed przystąpieniem do tworzenia wszystkich funkcji przeprowadź testy wśród prawdziwych użytkowników.


Zasada build, measure, learn

W książce Lean Startup jej autor mówi o zasadzie build, measure, learn. Krótko mówiąc, jest to feedback loop, który pomaga iterować i ulepszać produkt.


Diagram pochodzi z Ries, E. (2011) „The Lean Startup”, New York: Crown Business.


Zbuduj coś małego. Zbieraj opinie klientów. Ucz się na podstawie ich potrzeb. Następnie ponownie rozpocznij cykl. Zbuduj funkcję na podstawie jednej z potrzeb, o których właśnie się dowiedziałeś. Oceń, w jakim stopniu spełniono ich potrzebę. Dowiedz się, jak można to poprawić.

W naszej aplikacji kanapkowej wystarczy wyświetlić listę składników i dokonać płatności. Wyświetla ona kolejność zamówień dla kucharzy. Kucharze zaznaczają dane zamówienie jako zakończone. Rowerzysta dostarcza zamówienie. Iteracja 1 zostaje zakończona.

Zaprezentuj to swoim klientom. Zbierz opinie. Okazuje się, że potrzebują też możliwości oznaczania brakujących składników. Dowiedz się, gdzie są ich priorytety.

Może nigdy nie poruszają idei „tego, co zwykle”. Oszczędzasz czas, w którym możesz wprowadzać innowacje. Pomijając lub zakodowując na sztywno funkcje, które mogłyby być konfigurowalne, pozwalamy sobie poświęcić czas na tworzenie tego, czego naprawdę chce klient.


Ludzie naprawdę tego potrzebują?

Tak! Obecnie wiele firm zmienia świat, tworząc produkty i usługi, których faktycznie potrzebujemy. W rzeczywistości, jeśli spojrzysz na GitHub flow, zobaczysz, że jest to model, za którym wszyscy podążają.


Github Flow


GitHub Flow proponuje wdrożenie nowej funkcji w środowisku produkcyjnym przed scaleniem jej z masterem. Dlatego dobrym pomysłem jest tutaj pokazanie nowej funkcji użytkownikom, zanim zdecydujesz czy faktycznie spełnia ona wszystkie wymagania. Dzięki temu możesz zweryfikować, czy funkcja ta będzie używana przez klientów. 

Jak określisz oprogramowanie, z którego Twoi klienci chętnie korzystają? Sukcesem rynkowym.

To strategia, którą stosuje wiele startupów. Dołączysz do tysięcy innych firm, które mają tysiące zadowolonych klientów, ponieważ szybko stworzysz oprogramowanie, którego potrzebują.


Podsumowanie

Nie myśl o tym wszystkim za dużo. Tworzenie oprogramowania nie musi być trudne. Najlepsi architekci tworzą proste rozwiązania złożonych problemów. Jak? Przez hardcoding. Nie psuje to projektu niepotrzebną konfiguracją. 

Rozwiązują problem najszybciej, jak potrafią, żeby się pokazać. Mierzą swój sukces na podstawie opinii klientów. Dowiadują się od nich o ich potrzebach.

Nie mówię, że musisz zarzucić wszystko, co obecnie robisz, ale rozważ bycie bardziej zwinnym i zachęcaj klientów do zapoznania się z Twoimi pomysłami na wcześniejszym etapie procesu. Doceniaj iterację, prostotę i celuj w sukces rynkowy.


Oryginał tekstu w języku angielskim możesz przeczytać tutaj.

Nie przegap treści Bulldogjob
Subskrybuj artykuły

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej