Zakładamy Software House (cz.1)

…czyli od pomysłu do przemysłu.

W sieci (w tym na dobreprogramy.pl) można znaleźć wiele poradników, jak napisać fajny soft. Znajdziemy wiele tutoriali dotyczących języków programowania, frameworków, serwerów na których to można uruchomić, etc. Niestety, na ogół na tym część poradnikowa się kończy. Zatem bazując na tej wiedzy możemy samodzielnie utworzyć program, który nadaje się do uruchomienia i udostępnienia użytkownikom.

W cyklu, który dzisiaj zaczynam, chciałbym pokazać, jak może wyglądać ten proces z (nieco) większej perspektywy. Po pierwsze nie kodujemy sami tylko robimy to w grupie. Po drugie założenia projektu się zmieniają, więc na bieżąco trzeba uwzględniać zmiany (im większa grupa tym trudniej nad tym zapanować). Po trzecie uwzględniamy błędy, które popełniliśmy kodując – jak zatem sprawnie je usuwać? Po czwarte – produkt udostępniamy użytkownikom – warto zapewnić wsparcie.

Innymi słowy – w jaki sposób z programisty stać się wytwórcą i dostawcą oprogramowania. Sam jeszcze nie tak dawno stanąłem przed tego rodzaju problemem. Miałem pomysł, umiałem (trochę) kodować. Co dalej? Zebrałem team i zaczęliśmy pisać program. Niestety szybko trafiliśmy na problemy, które mocno pokrzyżowały nam szyki. Bazując na swoich, trudnych, doświadczeniach, postanowiłem udzielić kilku podpowiedzi innym zapaleńcom, którzy mogliby mieć ochotę „zmonetyzować” swoją wiedzę i umiejętności programistyczne.

Kolejne wpisy będą opisywały problemy, z którymi przyszło nam się zmierzyć oraz sposoby w jaki sobie z tymi problemami poradziliśmy. Rozwiązania software’owe które wykorzystaliśmy są albo open-source’owe albo darmowe dla niewielkich teamów. Dzięki temu uniknęliśmy sporych inwestycji już na początku.

Założenia programu oraz zarządzanie projektem

Tylko w teorii od początku jest wiadomo jak pisane oprogramowanie ma wyglądać, jakie funkcje realizować, jakie są kluczowe cechy. W praktyce zarówno wybór funkcjonalności jak i ich priorytetyzacja może nastręczać sporo trudności. Dlatego tak ważny jest wybór sposobu zarządzania tymi zagadnieniami jak i metody zarządzania projektem w ogóle.

Kodowanie

Samo kodowanie to chyba najprzyjemniejsza część pracy. Ale kodowanie w zespole nieco „utrudnia” tę pracę. W jaki sposób zarządzać tą pracą? Jaki sposób testowania przyjąć? Kto i w jaki sposób powinien oceniać jakość wytworzonego produktu. Te zagadnienia są na porządku dziennym w każdym software house, postaram się opisać jak my sobie z tym poradziliśmy i jakich rozwiązań użyliśmy.

Udostępnienie w sieci i support

Po trudach kodowania czas na spijanie śmietanki – czyli udostępniamy ludziom i cieszymy się że wszystko działa jak należy a pieniądze płyną szerokim strumieniem. Heh. Tyle teoria. Praktyka mówi, że po Go Live pracy nie ubywa, wręcz przeciwnie. Jak zatem poradzić sobie z natłokiem uwag ze strony klientów? Jak zapewnić stabilność oferowanego rozwiązania? Które tematy są krytyczne a które mogą poczekać?

Jeżeli tematy, które zasygnalizowałem, wydają Wam się ciekawe, czekajcie na kolejne wpisy. Jeżeli chcecie, bym poruszył jakieś dodatkowe aspekty – dajcie znać w komentarzach.