Menu Zamknij

Sekret Programowania, o Którym Nikt Ci Nie Powie

Najpilniej strzeżony sekret w świecie IT

Brałem kiedyś udział w bardzo ciekawym projekcie dla dużej firmy logistycznej posiadającej kilka magazynów w Polsce. Nie będę wchodził w szczegóły, ale do rozwiązania był problem optymalizacji rozkładu magazynowanych produktów, w celu osiągnięcia jak najniższego czasu rozładunku i załadunku. Projekt okazał się ogromnym sukcesem. Firma, dla której pracowałem zrealizowała finalnie 10% założonego planu sprzedażowego.

Zaraz, zaraz… O żadnym sukcesie mowy nie ma. Firma nie wykonała swojego planu sprzedażowego!

Rzeczywiście, jestem winien wyjaśnienie. Projekt był ogromnym sukcesem, bo klient był bardzo zadowolony z finalnego rezultatu.

Sekret programowania, o którym mówi się niezwykle rzadko

Zacznę od deklaracji, żeby potem nie było, że nie ostrzegałem!

Tym artykułem mam zamiar trochę „pogmerać” w klasycznym rozumieniu działania firmy wytwarzającej oprogramowanie. Spróbuj jednak dotrwać do końca, a przekonasz się, że to podejście może Ci się wydać ciekawe.

Sukces projektu nie powinien być liczony wyłączenie w zarobku. Nie zrozum mnie źle, wiem o tym, że bez pieniędzy żaden biznes długo nie przetrwa. Uważam, jednak, że pieniądze są rezultatem dobrze wykonanej pracy. Co w takim razie można uznać jako sukces projektu i jaki się z tym wiąże sekret programowania?

To wcale nie o pisanie kodu w tym wszystkim chodzi…

Oprogramowanie to wyłącznie narzędzie. Co prawda bardzo potężne, które w ciągu kilkunastu lat zmieniło świat nie do poznania. Nie tak dawno, bo 20 lat temu, nikt nawet nie wyobrażał sobie, jak wygodne może się stać życie dzięki krążącym po świecie linijkom kodu.

Oprogramowanie to „tylko” narzędzie

Jednak pomimo tego ogromnego skoku, jaki oprogramowanie pozwoliło nam zrobić, to wciąż jest to tylko narzędzie. Narzędzie do rozwiązywania problemów.

Jak ma się młotek to wszystko wygląda jak gwóźdź

Autor nieznany

Dobrze wykonana praca to rozwiązanie problemu klienta. Przecież taki jest powód, dla którego siedzisz przy klawiaturze i składasz aplikację z kolejnych linijek! Ktoś stwierdził, że będzie zarabiał więcej, jak wyda pieniądze na rozwiązanie (software), który rozwiąże jego problem (lub problem jego klientów).

A teraz pytanie za 100 punktów. Co powinno się budować z klientem? Oprogramowanie czy relacje?

Nie zawsze oprogramowanie jest odpowiedzią na zapotrzebowanie biznesowe. Przy budowaniu długofalowej współpracy zyskujemy na rozwiązywaniu problemów, a nie na dodawaniu do porfolio firmy kolejnej aplikacji.

Rozwiązywanie problemów, jako cel nadrzędny

Wróćmy do projektu z początku artykułu. Okazał się ogromnym sukcesem, bo w ciągu 3 miesięcy udało się rozwiązać problem w firmie logistycznej używając do tego celu dość prostego, posiadającego niewiele funkcjonalności i łatwego do przeniesienia (łącznie z wymaganym sprzętem) rozwiązania.

Precyzyjne i stosunkowo szybkie rozwązanie problemu było możliwe dzięki bardzo dużemu zaangażowaniu w projekt klienta. Uczestniczył w każdym etapie jego powstawania, stale dając dobre rady i wartościowe informacje zwrotne. Był najdokładniejszym testerem i hamował(!) zapędy, które nie prowadziły w linii prostej do pożądanego rezultatu.

To, jak klient postrzega świat – to Twoja rzeczywistość

Kate Zabrskie

Czy może z czymś Ci się to kojarzy?

Ależ Czarku, mój Drogi Kolego, którego artykuły rozjaśniają mój dzień, przecież to brzmi jak jedna z najważniejszych składowych Agile!

Agile, Agile, wszędzie Agile…

W przypadku projektów rozwojowych (w odróżnieniu do utrzymania) podejście Agile, a dokładniej Scrum jest bardzo, bardzo dobre. Oczywiście jest mnóstwo przykładów, gdy nie jest dobre… Często podejście Waterfall czy (jak to bywa w większości, jak nie we wszystkich projektach) podejście hybrydowe jest lepsze.

Jeżeli jednak mamy coś z tego tak popularnego teraz podejścia wynieść, to ścisła współpraca z klientem i to co się z tym wiąże, czyli fakt, że zmiana jest nieunikniona.

Skracaj drogę dojścia do rezultatu, czyli jak to się ma (do diaska) do programowania

Jeżeli rozwiązywanie problemu potraktujemy jako cel najważniejszy, to okaże się, że może mieć to bezpośredni wpływ na programowanie.

Każda napisana linijka kodu powinna prowadzić do udostępnienia użytkownikowi sposobu uproszczenia jego pracy przy minimalnym nakładzie zaangażowania z jego strony. Jakie z tego wynikają zasady?

  • projektujemy i tworzymy funkcjonalności -> nie moduły
  • funkcjonalność robi dokładnie to co powinna -> nie przygotowujemy kodu „na zapas”
  • skupiamy uwagę na głównym problemie do rozwiązania -> nie odkrywamy Ameryki na nowo
  • zawsze można zrobić mniej (prościej, lepiej), a kreatywność jest wyzwalana przy ograniczonych zasobach -> nie przeciągamy projektu i nie dokładamy zasobów

Powinno sie pisać oprogramowanie tak, aby odpowiadało na obecne zapotrzebowanie. Zmiana jest nieunikniona, jednak przygotowywanie się na scenariusze na zasadzie przypuszczeń, a nie pewności nie ma sensu. Dobrze napisany kod będzie podatny na rozszerzenia. Wprowadź zmianę, gdy stanie się rzeczywiście niezbędna.

Mierzenie produktywności pracowników

To wszystko prowadzi to poważnego pytania: czy w związku ze wszystkim powyższym powinno się mierzyć czas działu IT w ilości przepracowanych godzin lub ilości napisanych linijek kodu?

Mierzenie postępów w tworzeniu programu ilością kodu jest jak mierzenie postępów budowy samolotu za pomocą wagi. Trzeba wiedzieć nie tylko, co można dodać, ale też, z czego zrezygnować.

Bill Gates

Jeżeli pracujemy nad rozwiązaniem problemu – to nie ma znaczenia ile godzin dziennie programista siedział przy klawiaturze, a już na pewno bez znaczenia jest ilość napisanego kodu.

Jedyne co jest ważne to czy programista dostarcza pełnowartościowe rozwiązanie z zachowaniem, najlepiej wspólnie ustalonego z kierownikiem projektu, terminu.

Co do ilości napisanych linijek kodu… to jakby to nie było już teraz dostatecznie absurdalne, to prawda jest taka, że najlepszy „program” to taki, w którym nie ma ani jednej linijki kodu. Jeżeli problem jest rozwiązany i nie powstał przy tym twór, który trzeba utrzymywać… to same plusy!

Lepiej liczyć dostarczone rozwiązania, a nie godziny pracy

W wielu firmach ilość godzin spędzonych przy ekranie monitora wciąż traktuje się jak najwyższą cnotę. Jest jednak też wiele miejsc, gdzie ważniejsze jest „dowożenie”. Wybór pracodawcy wydaje się być oczywisty.

Podsumowanie

Wydaje mi się, że przyszła najwyższa pora dla wszystkich programistów, aby nie spoglądali na klientów, jak na niezbyt rozgarniętych użytkowników końcowych ich wspaniałych dzieł. Należy wejść „w jego buty” i zastanowić się, jaki jest problem, a następnie go rozwiązać.

Gdy piszemy kod pamiętajmy, jak najbardziej możemy skrócić drogę użytkownika do upragnionego rezultatu. Firma, w której pracujemy oraz firma klienta wyłącznie na tym zyskają.

Być może od zawsze wiedziałeś, że tak właśnie jest, a może wyjawiłem Ci właśnie największy sekret! Jakby nie było, zastanów się nad tym i pomyśl czy nie warto spojrzeć na oprogramowanie z tej strony.

Dzięki, że dotrwałeś/dotrwałaś aż tutaj. Jeżeli temat wydał Ci się ciekawy i chciałbyś o nim podyskutować nie krępuj się! Zostaw komentarz lub napisz do mnie poprzez formularz kontaktowy. Zawszę odpisuję!

Nie zapomnij pobrać dokumentu i zapisać się na newsletter. W ten sposób nie ominie Cię kolejny ciekawy artykuł.