Jedlinski.pl devblog

Czy zastanawialiście się kiedyś jakie są cechy najlepszych programistów? Co sprawia, że jedni osiągają sukces a inni pracują całe życie w małych, nic nie znaczących firemkach, bez perspektyw na rozwój (i podwyżkę)? Jak to się dzieje, że mamy z jednej strony świetne, intuicyjne oprogramowanie, a z drugiej kompletnie beznadziejne śmieci - co prawda z mnóstwem bajerów, ale w gruncie rzeczy bezużyteczne?

Zdawałoby się, że odpowiedź jest prosta - dobry programista to taki, który (niespodzianka!) dobrze programuje, czyli zna na wylot język, w którym to robi i potrafi sprawić, by dana funkcjonalność zadziałała. To jednak nie wystarcza - znam wielu programistów tworzących mnóstwo linii kodu na minutę i dobrych w rozwiązywaniu algorytmów, których bym nie zatrudnił. Opanowanie technologii nie wystarcza.

Poniżej postaram się opisać kilka kluczowych elementów stanowiących o tym, że niezły koder staje się świetnym programistą:

• Pasja - zawsze trudno mi zaufać komuś, kto mówi, że jest programistą a pierwszy program stworzył na studiach informatycznych. Najlepsi programiści piszą swoje pierwsze linie kodu w podstawówce, najpóźniej w gimnazjum. Znają co najmniej kilka języków programowania, nieważne, że wiele z nich słabo - świadczy to raczej o odkrywaniu i poszukiwaniu. Rozumieją i są zainteresowani nowinkami w branży - jeżeli w 2007 roku nie słyszeli o Ruby czy Pythonie, to prawdopodobnie jest coś z nimi nie tak.
• Komunikacja z otoczeniem - programowanie to wbrew pozorom także praca z ludźmi. Bardzo rzadko zdarza się sytuacja, w której otrzymujesz pełną, szczegółową specyfikację i bez szemrania zabierasz się do implementacji. Zwykle najpierw musisz poznać potrzeby osób, dla których tworzone jest oprogramowanie - ich nawyki, typowe problemy, wreszcie cele, które chcą osiągnąć. Programista musi umieć z nimi rozmawiać (czy to bezpośrednio, czy za pośrednictwem project managera), dopytywać o szczegóły, wyjaśniać wątpliwości.
• Samodzielność - pytanie o szczegóły jest ważne, aby poznać potrzeby klienta. Jednak programista, który pyta czy komunikaty o błędach zrobić czerwoną czcionką na białym tle czy odrotnie, to zły znak. Po pierwsze, wystarczy spojrzeć jak to było zrobione w innych projektach czy w innych częściach tego samego projektu. Po drugie, jest to sprawa zupełnie nieistotna - jeżeli uznamy, że trzeba zrobić to na czerwonym tle a zostało zrobione czerwoną czcionką - zmiana tego to kilka sekund. Jeszcze gorzej jeżeli programista dostał w specyfikacji tylko notkę, że w tym a tym miejscu mają się pojawiać błędy i w ogóle nie zastanawia się jak wyróżnić informację o nich - więc po prostu je wyświetla, bez żadnego specjalnego formatowania, bo przecież w specyfikacji nic nie było. Nie myśli, nie proponuje rozwiązań, nie wnika.
• Krytyczne spojrzenie - bardzo często zdarza się, że specyfikacja projektu jest sucha, czy wręcz błędna. Klient pisze w niej co mu ślina na język przyniesie, bez specjalnego zastanowienia. W końcu jest klientem, niekoniecznie ma umysł analityczny i niekoniecznie zastanawia się nad każdą możliwością. Czasami ma dodatkowo własne przyzwyczajenia, które narzucają mu pewne rozwiązania (np. tak to działało w programie, który używał wcześniej). Czasami po prostu nie wie, że jest możliwość zrobienia czegoś lepiej, ponieważ nie zna ograniczeń technologii czy nie zastanawia się nad nimi. Dobry programista powinien takie rzeczy wyłapać - zaznaczyć, że to i to nie będzie działało sensownie (np. będzie wymagało od użytkownika zbyt dużo zachodu, więc zrezygnuje), a tamto można zrobić fajniej, bardziej zautomatyzować proces czy uczynić go bardziej spójnym z pozostałymi. Specyfikacja nie jest święta a klient nie jest wyrocznią… jednak z drugiej strony, wszelkie zmiany i usprawnienia trzeba przedyskutować - wprowadzanie ich bez konsultacji może okazać się zupełną pomyłką.
• Wczucie się w rolę użytkownika - jedną z najbardziej typowych wpadek nawet niezłych programistów jest brak podejścia od strony użytkownika. Mamy dany problem i rozwiązujemy go tak, jak sugeruje struktura bazy danych czy stworzony już kod. Na przykład w naszej strukturze są obiekty typu “zamówienie” i każde z nich przypisane jest do jakiegoś obiektu typu “klient”. Nie da się więc stworzyć “zamówienia” bez “klienta”, ergo nie da się zamawiać bez rejestracji / logowania. Jeżeli więc w specyfikacji nie ma szczegółowych kroków składania zamówienia, nasz programista po prostu zrobi to, co mu narzuca struktura - znienawidzony przez użytkowników formularz rejestracji.

Ktoś może stwierdzić, że większość powyższych cech nie dotyczy programisty - tylko project managera. W końcu to on komunikuje się z klientem, on tworzy wraz z nim specyfikację, wreszcie on mówi grafikowi gdzie co ma się znaleźć. Ale tak naprawdę każdy dobry project manager był kiedyś programistą, tylko przeszedł na wyższy level :)

Już jakiś czas temu na blogu Wojtka Kyciaka ukazał się ciekawy artykuł na temat upadku sklepu SilverTobbaco.pl. Bardzo polecam lekturę, pokazuje ona tylko niektóre z wielu przeciwności na jakie natknąć się można tworząc i prowadząc sklep internetowy - jedną z nich jest gospodarka magazynowa.

Wielokrotnie spotykałem się z opinią, że założenie sklepu internetowego, to super biznes - kupujesz oprogramowanie, wstawiasz produkty i voila!, kręci się samo. Miałem wielu niedoszłych klientów, którzy z takim założeniem pisali z pytaniami o jak najtańszą ofertę. Ba, niektórzy w ogóle nie chcieli nic inwestować, tylko podzielić się ze mną przyszłymi olbrzymimi zyskami… W taki wypadkach proponuję zawsze kredyt i podzielenie się przyszłymi zyskami z bankiem - od tego właśnie są instytucje finansowe, a nie programiści.

Tymczasem prowadzenie sklepu internetowego także wymaga kapitału. Najpierw oprogramowanie i design - to już kilka tysięcy złotych. Potem reklama, o której wielu właścicieli sklepów online w ogóle nie myśli - same kampanie w wyszukiwarkach internetowych to od kilkuset do kilku tysięcy miesięcznie. W przypadku niektórych branż warto postarać się też o reklamę w prasie (min. kilka tysięcy miesięcznie). I tak dalej i tak dalej, teoretycznie każdy o tym wie i każdy się zgadza.

Okazuje się jednak, że często największy kapitał potrzebny jest na zakup towaru, który będziemy mieli na magazynie. W zależności od branży będzie to od minimum kilku tysięcy do kilkunastu czy kilkudziesięciu. To, czego nie będziemy mieli na magazynie - będziemy musieli sprowadzać od dostawcy. Pół biedy jeżeli jest to lokalna hurtownia (wtedy jednak nasze ceny będą raczej mało konkurencyjne), gorzej jeżeli naszym źródłem są producenci czy dystrybutorzy z całej Polski (czy nawet zagranicy). Zamawiając u nich cokolwiek zwykle musimy osiągnąć jakąś kwotę zamówienia hurtowego, często im większe będzie to zamówienie, tym większy otrzymamy rabat. Na początku jednak nie mamy tylu klientów, aby sprzedać im taką ilość towaru, szczególnie jeżeli w naszej branży jest duża różnorodność produktów. Co zrobić gdy jeden z produktów od tego dostawcy skończy się na magazynie - następne duże zamówienie, którego prawdopodobnie nie potrzebujemy?

W sklepach internetowych spotykane są dwa podejścia do tego problemu. Możemy w ofercie dla klientów mieć wyłącznie towary, które mamy na magazynie - pozostałe wyłączać do czasu nowej dostawy. Niestety w wielu branżach właśnie szeroki wybór produktów jest jedną z zalet zakupów online. O ile w sklepie tradycyjnym klient z braku upatrzonego produktu - często kupuje inny, podobny, to w sklepie online jeżeli nie znajdzie wybranego aparatu cyfrowego bądź konkretnego kosmetyku - poszuka po prostu u konkurencji.

Drugim sposobem jest podawanie czasu realizacji dla każdego produktu. Jeżeli mamy go na magazynie, to realizacja będzie natychmiastowa (zwykle do 24 godzin), jeżeli nie, odpowiednio dłuższa (np. do 7 dni). Takie podejście ma dwie poważne wady. Po pierwsze klienci często nie czytają tego co jest napisane na ekranie, nawet kilka razy powtórzona informacja o czasie realizacji np. “do 14 dni” daje nam co najmniej kilka procent osób, które po dwóch dniach i tak zadzwonią z pretensją, że nie otrzymali jeszcze paczki. Po drugie danego produktu może z różnych przyczyn nie być już u naszego dostawcy - przyjęliśmy zamówienie, czasami także płatność za nie, a nie możemy go zrealizować - wpadka.

Drugi sposób jest preferowany przez większość sklepów i uważam, że w 9 na 10 przypadków będzie zdecydowanie lepszy. Należy jednak pamiętać, że aby go sensownie zrealizować potrzebujemy porządnego oprogramowania magazynowego - możliwości ustawiania stanów minimalnych, określania dostawców, automatycznego ustawiania dostępności (w zależności od tego, czy produkt jest na magazynie czy nie), generowania raportów (np. listy produktów zamówionych od jednego dostawcy z uwzględnieniem stanów minimalnych), itp. Większość gotowych silników sklepowych nie ma tego typu rozwiązań - dobrze, jeżeli możemy wpisać przynajmniej liczbę produktów na magazynie. Możemy skorzystać z zewnętrznego oprogramowania - typu Symfonia, Subiekt, WF-Mag, jednak wtedy dochodzi koszt jakiejś synchronizacji danych między nim a sklepem…

W REBEL.pl mieliśmy to szczęście, że w momencie startu (XI 2003) w branży gier towarzyskich było zaledwie kilku poważnych graczy i około 200-300 produktów w sumie. Jednak poza nimi - w ofercie mieliśmy także puzzle i gry komputerowe. Te ostatnie bardzo szybko okazały się niewypałem - na rynku była już silna konkurencja, tytułów było mnóstwo, ceny wysokie a klienci straszliwi (to temat na osobny wpis :)). Puzzle natomiast spotkały się z podobnymi problemami jakie miał Maciek w SilverTobbaco.pl - jest bardzo wiele wzorów i nie ma wśród nich wyraźnych “hitów”. Klienci wybierali bardzo konkretne puzzle - chociaż zdawałoby się, że co za różnica - takie czy takie ujęcie gór… Po kilku miesiącach zdecydowaliśmy się na wydzielenie nowego sklepu - PUZEL.pl, ponieważ grupy docelowe gier towarzyskich i puzzli pokrywały się w zbyt małym zakresie. Postawiliśmy na serię zachęt do kupowania puzzli, które mamy na stanie. Na stronie głównej pojawiały się jako polecane / nowości / itp. wyłącznie produkty będące na magazynie a w wyszukiwarce jako domyślną opcję daliśmy “dostępność do 48 godzin”. To w dużej mierze pomogło, jednak niewystarczająco - więc wszystkim puzzlom, których nie mieliśmy na magazynie ustawiliśmy czas realizacji “do miesiąca” (najbardziej zniechęcający). Te zabiegi w końcu zdały egzamin, zamówienia stały się bardziej przewidywalne (oczywiście kosztem ich liczby) a od dostawców mogliśmy brać większe dostawy 1-2 razy w miesiącu. Oczywiście taka strategia - mimo, że łączy dwa podejścia opisane powyżej, nadal wymaga sporego magazynu. W branżach, w których konkurencja cenowa ma duże znaczenie (w przypadku puzzli akurat niewielkie) można pokusić się także o automatyczne podnoszenie i obniżanie cen w zależności od tego, czy mamy produkt na stanie - dla produktów na magazynie cena byłaby niższa, aby zachęcić do wyboru właśnie tych pozycji.

Niestety, mimo rozwiązania problemu magazynu, PUZEL.pl zmaga się z zupełnie innymi przeciwnościami, które spowodowały, że parę dni temu rozpoczęliśmy proces jego zawieszania. Prawdopodobnie zaraz po Nowym Roku sklep w obecnej formie przestanie istnieć i chociaż mam nadzieję, że jeszcze wróci, to na pewno nie szybciej niż za kilka miesięcy.