Od pomysłu do implementacji, czyli jak projektować, krok po kroku – DSP#01

To był długi dzień. Wraca człowiek do domu, bierze prysznic i *ding* – do głowy wpada kolejny świetny pomysł. Nie ważne, czy to aplikacja, czy strona internetowa, czy może jakieś urządzenie wyposażone w rapsberry pi. Jest myśl, tak to genialne, pewnie zarobię na tym miliony, a na pewno – przynajmniej – zrealizuję. A jeśli nie zrealizuję, to chociaż schowam do szufladki oznaczonej jako „pomysły do wykonania kiedyś”. Komu zdarzają się takie sytuacje?

Od pomysłu do implementacji
Mam pomysł!

tl;dr Od pomysłu do implementacji powinniśmy wykonać 7 kroków projektując aplikację: pomysł, przeczekanie entuzjazmu (pozwolenie pomysłowi na zweryfikowanie się), memory dump, mind mapping, wymagania funkcjonalne i scenariusze użytkowania, wybór technologii, implementacja.

Pół biedy kiedy aktualnie mamy na głowie inne rzeczy i pomysł wpadnie do szufladki i przeczeka tam kilka miesięcy. Wtedy wszystko w głowie zaczyna się układać. Człowiek dostrzega cienie, ale i możliwości rozwoju projektu, o których nie pomyślał wcześniej. Dzieje się tak ponieważ sen wyewoluował do formy w której pomaga nam rozwiązać problemy z którymi zmagaliśmy się w ciągu dnia. Autorem tej teorii jest Deirdre Barrett i osobiście – wydaje mi się ona (teoria) przynajmniej prawdopodobna. Bo ile razy było tak, że człowiek zasypiał z problemem, a budził się z rozwiązaniem?

A co się dzieje, jeśli akurat mamy czas? Cóż, jesteśmy programistami, więc – implementacja. Już widzimy w głowie ten kodzik, jak będziemy klepać, jakie wzorce, i ten nowy framework! Co ciekawe ten mechanizm zachodzi również w pracy, podczas rozmowy z klientem tylko usłyszymy o tym co mamy zrobić, już nasz mózg przystępuje do rozwiązywania problemów implementacyjnych. To nic, że spotkanie jeszcze trwa, że nie znamy prawie żadnych szczegółów – my już wiemy jak trzeba będzie to naklepać. A to najgorsze co można zrobić. Rozmyślanie nad pomysłem powinno być abstrakcyjne, a wtrącające się w tym momencie myśli o implementacji tylko porządkują, tzn wpychają w sztywne ramy nasze rozmyślania. A to zdecydowanie nie jest dobre.

Od pomysłu do implementacji
Mózg programisty

Więc jak to robić? Tutaj bardzo przydaje się czas, a co za tym idzie sen. U siebie nie widzę problemu, nigdy nie mam czasu 😉 Tzn cokolwiek wymyślę ląduje w szufladce „na później”. Podobnie jest z moim projektem na konkurs, notatka o nim pojawiła się 22.08.2016 w moim Evernote. Czyli blisko 5 miesięcy przed startem konkursu, teraz jest idealny czas, żeby pomysł zaimplementować.

Noo dobrze, wpadłem na pomysł odczekałem te kilka dni, znam już plusy i minusy, wiem co może się udać a co nie, jaki jest następny krok? Tak naprawdę już odczekując te kilka dni, warto wszystkie myśli o projekcie sobie zapisywać. Tak luźno, zwykły memory dump, cokolwiek nowego się pojawi. A potem z tego bałaganu, tworzymy inny bałagan, czyli mapę myśli. Ja korzystam z narzędzia xMind, ale to nie ma znaczenia. Pokrótce czym są mapy myśli? Ważne, żeby na środku był zapisany, albo narysowany główny cel, a na gałęziach wszystkie rzeczy które się z nim wiążą. W formie odrobinę uporządkowanej, tzn tylko tematycznie. Taki jest mój przepis, ale w mapach myśli chodzi o to, żeby każdy miał tak naprawdę swój 😉

Od pomysłu do implementacji
Mapa myśli obrazująca jak tworzyć mapy myśli – rekurencja

Jaki jest następny krok? Wymagania funkcjonalne oraz scenariusze użytkowania. Oczywiście chodzi o to, żeby było sprecyzowane co takiego ma robić aplikacja, oraz w jaki sposób się z niej korzysta, do czego może się przydać, kto może zostać potencjalnym klientem i ewentualnie, jak za nią zapłaci.

Kolejny to dopiero projektowanie interfejsu, oraz wreszcie nasz ulubiony wybór technologii, frameworków, kolorów w edytorze, czyli to co misie lubią najbardziej 😉 i nareszcie przechodzimy do implementacji.

Reasumując, można wymyślić projekt, usiąść i zacząć go klepać. Ale na dłuższą metę to trochę mi ja się z celem, ponieważ po głębokiej analizie może się okazać, że ten nikomu się nie przyda, albo tylko nam będzie się podobał. Nie przeczę, że po przeprowadzeniu kilku kroków powyższego procesu czasem szczerze, samemu przed sobą trzeba będzie przyznać, że nie – ten pomysł jednak był słaby. Ale czy nie lepiej powiedzieć to sobie na początku, niż stracić czas na implementację, z której nic nie wyniknie, zamiast realizować coś naprawdę fajnego?

  • Ja powoli uczę się tej trudnej sztuki. Na razie częściej działam wg świętej zasady Króla Juliana: Szybko, zanim do nas dojdzie, że to jest bez sensu. Ale widzę już progres, a wpis bardzo ciekawy.

    • migellal

      Dzięki, króla Juliana również szanuję, ale tutaj się z nim nie zgadzam 😉 Przemyślane rozwiązanie, to jednak przemyślane rozwiązanie 🙂

  • Dawid Loranc

    Korekta: „bezsensu”.

    Ja sobie spisuję luźne przemyślenia na temat projektów w OneNote. W ramach DSP2017 myślę, że warto także sobie część myśli spisywać od razu w draftach postów.

    • migellal

      W ramach pisania wpisów tak, jak najbardziej 😉 Ale o tym napiszę osobno 😉 Wywaliłem bezsensu, bo słownik był dla mnie niejednoznaczny 😉 http://sjp.pl/bezsensu

  • Omen

    No zawsze można sobie strzelić jakiś projekt tak dla sportu, bo tak, bo chce i tyle:) Wtedy opłacalność i sensowność projektu zschodza na dalszy plan:D Ja w sumie od lat się noszę z przepisaniem pewnej gierki i poprawą części jej bebechów… obecnie całość nabiera mocy:D

    • migellal

      Noo tak, tylko, że podczas strzelania tego projektu może się okazać, że chcemy coś zmienić. Bo coś wpadło nam do głowy. A implementacja już zrobiona i żeby rozwiązać to dobrze, trzeba ją wywalić. I piszę to z własnego doświadczenia, z wcześniejszych „strzelanych projektów” 😉

      • Omen

        Dlatego mój dojrzewa już jakiś czas. Opłacalność i sensowność to miałem na myśli tylko rynkową pod kątem czerpania z tego zysków. Zgadzam się w 100% że nawet projekty robione dla siebie powinny być robione z głową.

  • Pingback: ()