Wiele osób oceniło mnie negatywnie ze względu na przekaz treści ( braku treści?!?) Oraz że temat względnie nie jest związany z informatyką ( tym bardziej, że w haśle jest CodeCamp). Wiele razy zmuszałem się, aby napisać ten tekst, który WYJAŚNI tym, co uważają, że WÓGLE nie nadaję się na prelegenta oraz że to, co wykonałem nie jest wartościowe.
Rozumiem krytykę, czystką, konkretną i motywującą, ale zamykanie się tylko na tematy związane z czystym kodem na konferencji jest błędne. Wspólnie z Grzegorzem ( po jego namowach) uznaliśmy, że mogę coś takiego przedstawić. Prosił mnie abym nie uogólniał oraz aby temat był zrozumiały dla każdego. Proszę też nie piętnować, dał mi rękę – nie ingerował w to co ma się znajdować na slajdach. Po konferencji , jako jedyny nie krytykował mnie a powiedział że mogło być lepiej – choć i tak jest zadowolony że wystąpiłem( mogłem przecież nie przyjechać).
Dlaczego takie słabe przygotowanie – mogę rzec że, w tym czasie zbiegło się parę nie fortunych rzeczy. Sesja na Uniwersytecie Przyrodniczym – Podkreślam PRZYRODNICZYM ( fakt ten mówi że co to robię , jest dla mnie poza zajęciami odskocznią od tego czego mnie uczą ), kolega z USA przyjechał akurat w dzień konferencji( a ja obiecałem że go odbiorę) oraz parę innych drobnostek które mimo że nie powinny być utrudnieniem – przecież temat jaki mówię wiedziałem od samego startu , to faktem jest że z czasem różnie to bywało Nie zapomnę jak dostawałem odpowiedzi od Grzegorza o 3:00 czy 4:00 w nocy ( u niego widzę też )
Kwestia wystąpienia oraz przygody z pogodą pozostawiam sobie - mam swoje wady wrodzone ( pogodo nie odporność oraz stres przed wystąpieniami), ale staram się je pokonywać. Im więcej ćwiczymy tym lepiej nam dla NAS, ale pewnych rzeczy nie uda się "przeciążyć”, aby program działał lepiej. Kto był i pamięta, co się działo wówczas z pogodą ( podpowiem, słońce i wichura, potem cisza przed deszczem, która zamieniła się w ulewę i słoneczko)
Ale meritum jest temat oraz tytuł. To czego nie udało się przekazać( w pełni ) , przekaże na piśmie.
Designer + Programista = Aplikacja - Z tym pojęciem każdy się zgodzi, że każda firma posiada w swoim zespole kogoś od kodu(logiki) oraz grafiki(design). Ja z racji tego, że programowaniem zajmuje się okazyjnie ( projekty, konkursy Imagine Cup oraz to, co Uczelnia mnie nauczy( 1/10 z zajęć to coś powiązane z informatyką ) stałem się bardziej designerem albo jak to woli projektantem ( nazwa ta bardziej trafia, bo głownie korzystam z narzędzi BLEND, Photoshop, Ilustrator), które w połączeniu z Visual Studio + QT dają ciekawy efekt. Ktoś powiedział , że nie liczy się szkoła a upór , aby być informatykiem.
Pomysł + Problem = Produkt
Obecnie panujący kryzys powoduje duże redukcje kadry, jednostki wybitne ze względu na swoje wymagania finansowe są zwalniane ( tutaj kwestia sporna, bo niby ludzi się ceni, za jakość ale jak nie ma, z czego zapłacić to się tnie i zatrudnia 3 średniej klasy niż 1 wybitnego - autentyk z rozmowy)
Ile razy zadawałeś sobie pytanie, a może te czasy ONE MAN ARMY nie do końca minęły, ile się słyszy o produktach mały programików pisanych przez ludzi z pasją i doświadczeniem, tworzących super rozwiązania. Zagadnienie te można rozbić na 2 słowa: Tworzy się Pomysł na Zadany Problem i tworzymy Produkt w postaci Aplikacji.
Nalewno uda mi się - Tutaj głownie myślę o blogu Macieja "Procenta”.. Który zrezygnował z pracy stałej i jest freelancerem - interesujący blog oraz ciekawa osobowość?
Posiadający Pomysł na Problem nie odraz uświadczymy sukcesów. Braki jakie często widzę u ludzi kreujących oprogramowanie jest na tyle duże że problem Start Up'a staje się problem braku finansowania. Problemem jest brak koncepcji.
Początkowo przedstawiłem założenia Koncepcji 4P i 4C - założenie niby oczywiste a czasami w trakcie tworzenia czy oddania produktu(aplikacji) do klienta okazuje się problemem. Zwrócenie uwagi na te aspekty wydaje mi się kluczowe - stąd wzięła się cała ekonomia obrotu towarem - stąd też narodził się biznes, jaki znamy nie tylko w informatyce, ale i innych dziedzinach gospodarki.
Kolejny błąd, jaki zauważyłem to tworzenie oprogramowania z jednej perspektywy - Ja Programista, Ty Klienta.
JA - Wiem, czego chcesz, bo też jestem klientem i wiem, czego klient oczekuje po produkcie.
Ty - Produkt nie spełnia moich oczekiwań, bo.....( najwcześniej interface jest za mało elegancki – tutaj designer ma pole do popisu )
Morał - Tworząc oprogramowanie nie można...
To, co poruszył pewna osoba ( oceniająca wydarzenie), że temat oraz aktualny slajd pokazujący Software
Proces tworzenia oprogramowania - good design is a good biznes - posiada pewnie etapy, które rzadko, kiedy są przestrzegane. Aby lepiej zobrazować , o co chodzi , przedstawię schemat graficzny – jeden obraz zastępuje tysiąc słów.
Przedstawiłem też mapkę jak należy postrzegać problem
Aby sprzedać naszą aplikację potrzebny jest Klient które ma Potrzeby. Potrzeby najwcześniej są spowodowane jakimiś problemami z już istniejącymi produktami bądź szuka Rozwiązania na zadany Problem. Do informatycznych rozwiązań mamy Aplikację czyli nasz Produkt. Dostarczamy produkt do Klienta i tutaj zaczyna się gorączka. Jego wcześniejsze wymagania zostały spełnione( które umieścił w pliku wymagania ) ale dalej nie jest zadowolony. Wiedza użytkownika to X czynników , niektóre biorą się z tego iż ktoś nauczył się pewnych Standarów i wprowadzenie czegoś nowego jest wręcz nie możliwe np. Produkt Microsoft Office w roku 2007 przyniósł ogromne zmiany w interface’ie , wielu stałych użytkowników ( w tym JA ) nie mogło się przemóc do tych , niby polepszających pracę zmian.
Zadaniem firmy było aby wyglądała jak na najnowoszczśnie , aby spełniała kryteria bezpieczeństwa , szybka i prosta w nawigacji oraz uzyskaniu przez nas pożądanego efektu. Również schemat kolejności rozwiązywania problemu pozostał nie zmieniany.
Dobrym przykładem , z mojej strony jest , zmianę pasku rozwijania MENU START. Pomyślcie sobie że zamiast paska Start który wyjeżdża w górę , macie oto przykład mojego design na konkurs IC:
Pomysł mimo dobrej woli został , nie chętnie przyjęty przez jury – ostrzegano mnie ( nawet w książkach o projektowaniu design jest mowa o standardach nabytych, które są najgorsze do zmiany).
Ale i też konkurencja ma tutaj duże znaczenie – na pytanie „ A nie może Pan tego zrobić tak jak jest w Programie XY , wie Pan pracuje już od 5 lat na nim ale brakuje mi paru funkcji oraz dobrze gdyby Pan mi je dopisał w tym naszym programie „
Teraz wywód , czym jest Experinace Design – tutaj slajd który dogłębnie opisuje co chciałem przekazać.
Potem rzuciłem się na produkty , które są częściowo autorstwa mojego a niektóre w pełni które powstały na konkurs Imagine Cup ( parę edycji). Nim przejdę do konkretnego produktu , chciałem pokazać jakie błędy są popełniane przez drużyny developerskie.
Produkt budujemy w oparciu od Informacje( dane , instrukcje , schematy itd.) , wybierając odpowiednie narzędzie ( Visual studio ) w naszym przypadku oraz platformę domyślną
Pierwszym krokiem jest Brainstorming – niby najlepsza metoda aby działać w grupie – rzucać pomysły i je realizować. Ja odbyłem już po występie szkolenie z NLP i powiem , wytwórzcie Synenergię , a projekt będzie jeszcze lepszy. Dużo by mówić , ale szkolenie pokazało że osoby które mają super pomysł , nie potrafią go przeforsować a forum innych ludzi, demokracja jest złym wyborem danego rozwiązania.
Budując produkt najcześciej , mamy już rekonesans , mamy przykładowego klienta i prawie gotowy program. Wychodzimy z założenia że jak zaprojektuje rozwiązania na zadany problem , rozwiązujący część potrzeb użytkowników to zyskam klienta. Tutaj jest duża rozbieżność , czasami się uda ale w miażdżącej liczbie przypadków , start up’ów pada. Bo finansowanie naszej aplikacji kosztuje.
Dlatego przedstawiłem coś co jest powiązane z ekonomią , czyli Strategia Błękitnego Oceanu. Na slajdach jest.
Kolejny problem to wspomniany przez mnie interface design. Pytanie czego użytkownik oczekuje , czy super warstwy prezentacji ( wodotryski , najnowsze funkcje przenikania , przeźroczystości czy innych cudów). Skrótem RIA, High-End User Experiance co można nazwać klientem „bogatym”. Spotyka się też aplikacje dla klienta „ubogiego”. Zwykłe winforms , bez zbytecznego WPF’a który wymaga potężnego systemu.
Kilka technologii. Sam korzystam z WPF , Java Fx oraz Flash’a
Slajd mówiący o tym jaka technologia , do jakiego klienta się nadaje.
Mówiąc o WPF , warto wspomnieć o XAML.
Teraz mając idee , czas omówić projekty ( tutaj ominę , każdy kto chce więcej informacji – chętnie się podzielę )
Przed ostatni slajd , jest to takie podsumowanie – wiedzy która jest lekko chaotyczna ale daje rozpoznanie tematu oraz najważniejsze założenia prelekcji.
Never ending story – ile by kto nie napisał książek , ile razy bym JA nie wystąpił i tak każdy ( nawet JA ) często zapomniam o tym wszystkim o osiągam taki rezultat
Dziękuje , liczę że rozjaśniłem trochę.