Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Zakładamy Software House (cz.2)

Na początku jest pomysł. Zakładam że masz koncepcję jakiegoś fajnego softu, który zdobędzie użytkowników i w krótkim czasie przyniesie Ci pieniądze albo chwałę. Ewentualnie jedno i drugie. Gorzej jest, jeżeli z pomysłem też jest krucho i posiadasz jedynie umiejętności, które chciałbyś sprzedać. Musisz wówczas poświęcić sporo czasu, by zastanowić się w jakiej branży chcesz pisać aplikację. Nie jest moim celem opisywanie teraz, jak znaleźć pomysł, na którym można zarobić (może zrobię to przy innej okazji). Spróbuj poszukać czegoś, na co jest popyt a konkurencja jest niezbyt duża. Wchodzenie w rozwinięty rynek z czymś innowacyjnym jest oczywiście możliwe, ale wymagane tu jest nieco większe doświadczenie oraz sporo więcej pieniędzy (marketing potrafi pochłonąć ich masę). Na początek możesz spróbować z produktami dla małych przedsiębiorstw. Np. ustawa z 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia nakazuje wszelkim podmiotom medycznym zrezygnować z dokumentacji papierowej i przejść na elektroniczną. Wszelkim, więc także jednoosobowym praktykom lekarskim. Termin graniczny zgodnie z ustawą to 1 sierpnia 2014. Co prawda większe placówki już coś takiego na ogół mają, ale spora część mniejszych działa na zasadzie pani Krysi i kalendarza. I tu pojawia się okazja - napisać software, który będzie takie niewielkie działalności wspierał i udostępnić go online za niewielką kwotę (liczymy na sporo licencji, więc jednostkowy zysk nie musi być duży, a małe opłaty mogą przyciągnąć klientów). To oczywiście tylko przykładowy pomysł, takich nisz jak ta opisana jest sporo więcej, trzeba tylko dobrze poszukać.

Kiedy już wiemy co chcemy robić, możemy kompletować zespół.

Tworzenie zespołu

Zespół ma określony cel - zbudowanie, uruchomienie i utrzymanie oprogramowania opisanego w założeniach. Istotne jest, by już na początku rozdzielić role poszczególnym członkom zespołu. Muszą one być jednoznacznie przypisane, gdyż za tym idzie odpowiedzialność i uprawnienia. Poniżej opisałem kilka podstawowych ról, które musimy komuś przypisać, jeżeli zależny nam w miarę poprawnym przejściu przez cały proces twórczy. Oczywiście nie oznacza to że w naszym zespole musi pracować od razu 10 czy 20 osób. Wiele ról można ze sobą łączyć, na początkowym etapie działania zespołu część z nich pochłania znikome ilości czasu; niemniej ktoś musi zając się tymi sprawami.

Product owner

Jest to osoba, która podejmuje decyzje dotyczące funkcjonalności oraz wyglądu projektowanego systemu. Najlepiej by był to ktoś mający bliski kontakt z potencjalnymi klientami bądź doświadczenie w branży. Najlepiej jedno i drugie. Oczywiście nic nie stoi na przeszkodzie by funkcjonalności omawiać i przyjmować podczas wspólnych zebrań. Każdy w zespole powinien mieć możliwość zgłoszenia propozycji ulepszenia. Jednak, gdy nie będzie kogoś, kto w odpowiednim momencie powie 'Stop' ulepszeniom, to system nie zostanie ukończony w czasie (czasem nawet wcale), gdyż zawsze będzie coś, co programiści chętnie dopiszą. Zawsze. Wierzcie mi - taka już ich natura ;-)

Architekt systemu

Ktoś kto weźmie odpowiedzialność za to, w jaki sposób system zostanie zaprojektowany. Począwszy od języka (bądź języków programowania), poprzez frameworki, bazy danych, etc. Architekt podejmuje decyzje związane z modelem, pakietami, klasami, interfejsami, itd. Innymi słowy, zastanawia się jak zrealizować wymogi, które zdefiniował product owner. W początkowej fazie często jest to jeden z programistów (na ogół ten najbardziej doświadczony). Decyzje przez niego podejmowane powinny być omawiane w gronie developerów

Programista

Człowiek od czarnej roboty. Ktoś kto mając szkielet systemu (czyli wymagania i architekturę) - ubierze to w ciało. W początkowym okresie nie jest wymagane wielkie doświadczenie od wszystkich programistów. Ważne by znali podstawy, byli gotowi się uczyć i ściśle współpracowali z głównym programistą (bądź architektem systemu)

Jakościowec

Jakościowiec - po co w firmie programistycznej? Otóż, jak powszechnie wiadomo, programiści to bardzo kreatywni ludzie. I nic w tym złego, w końcu ich praca to tworzenie nowych rozwiązań. Ale trzeba jeszcze pilnować by te rozwiązania dokładnie pasowały do wymagań klienta. Niekiedy zanadto "upiększone" rozwiązania powodują opór użytkowników. Jakościowiec sprawdza, czy utworzone rozwiązania dokładnie odpowiadają specyfice wymaganej przez klienta (którą zarządza product owner). Jeżeli coś nie pasuje - nie odbiera kolejnego modułu i zgłasza poprawki programistom.

Tester

Testerzy ściśle współpracują z jakościowcem. Nie muszą należeć do ścisłego zespołu projektowego - mogą to być znajomi, rodzina, potencjalni użytkownicy, którzy wyrażą wolę uczestniczyć w projekcie. Ich zadaniem jest wyłapywanie błędów w programie (logicznych oraz systemowych). Ich uwagi zbiera jakościowiec i przekazuje zespołowi programistów. Generalnie każdy program musi być solidnie przetestowany. Lepiej żeby robili to pod kontrolą testerzy niż użytkownicy, którzy szybko sobie wyrobią opinię dotyczącą jakości naszej oferty ;-)

Marketingowiec

Nie robimy tego systemu dla siebie tylko dla innych. Więc trzeba się zastanowić, jak to sprzedać. Oczywistą kwestią jest utworzenie strony www przedstawiającej to, co tworzymy. Trzeba zastanowić się nad pozycjonowaniem, ewentualną kampanią reklamową. Jeżeli nasz system będzie miał stopniowo wprowadzane nowe moduły, warto, by marketingowiec wraz z product ownerem przedyskutowali kolejność wydawania kolejnych modułów. Tak powstałą road mapę trzeba opublikować i regularnie aktualizować

Administrator systemów

W naszej organizacji pojawi się sporo systemów. Gdzieś trzeba trzymać stronę www, repozytorium kodu, wersję testową aplikacji (później - produkcyjną), narzędzia współpracy w projekcie, etc. Administrator jest osobą odpowiedzialną za utrzymanie serwerów, backup, tunning, itd. Nawet jeżeli nie będziemy sami administrować serwerami, tylko wszystko będzie w "chmurze", to i tak ktoś musi tym zarządzać. Tym kimś jest właśnie administrator.

Finansista

Serwery, SEO, marketing, praca grafików - to wszystko kosztuje. Należy wyznaczyć jedną osobę, która przyjmie na siebie obowiązek ewidencjonowania kosztów (ewentualnie też płacenia). Bez tego szybko zrobi się bałagan a jak wiadomo nic tak ludzi nie dzieli, jak pieniądze. W przyszłości będzie to osoba, która zajmie się również ewidencją zysków (to ta przyjemniejsza część jego pracy ;-)

Jak widać sporo ról powinno się pojawić w naszym zespole, by móc sprawnie zrealizować założony cel. Tak jak już wspomniałem nie oznacza to, że w zespole musi pracować minimum kilkanaście osób. My zaczynaliśmy w trójkę. Chodzi o to, by każde zadanie było komuś przypisane. Dzięki temu jasno będą rozpisane odpowiedzialności i tematy nie będą nam umykać (albo przynajmniej będzie wiadomo kogo się należy czepiać). Łatwiej też o podjęcie decyzji - wiadomo kto powinien i może to zrobić.

Po utworzeniu zespołu trzeba przyjąć założenia dotyczące sposobu zarządzania całym projektem. Warto też wybrać narzędzia z których będziemy chcieli korzystać. O tym etapie będzie więcej w części 3. Zapraszam 

internet programowanie serwery

Komentarze

0 nowych
Shaki81 MODERATOR BLOGA  37 #1 17.01.2014 19:05

Sporo tych zadań. Zastanawia mnie jednak ten tester i jakościowiec - nie sa to jakby nie patrzeć bardzo zbliżone zadania?

  #2 17.01.2014 20:06

Tak zdefiniowany tester to raczej mało przydatna rola, rodzina i znajomi nie są dość skrupulatni i konsekwentni, żeby "klikać" dany moduł aż do znudzenia, tak żeby naprawdę nie zawierał błędów (przynajmniej tych krytycznych i istotnych). Z mojego doświadczenia wynika, że Tester i Jakościowiec to ta sama osoba, znana jako QA (Quality Assurance, po polsku to jest chyba inżynier jakości ?!). To bardzo istotna (i żmudna) rola, to często pierwsza i ostatnia linia obrony dla oprogramowania, to Ci ludzie właśnie powodują, że programy na ogół działają :). Programiści to fajni ludzie (sam nim jestem), ale mają tendencję do przeceniania swojego "dziecka" (kodu) i niezauważania w nim oczywistych błędów, do wymaganiami jest prościej, bo dojrzały zespół i dojrzali programiści zazwyczaj oddają oprogramowanie naprawdę zgodne z wymaganiami.
Co do PO, to powinna być zdecydowanie jedna osoba i najlepiej jeżeli nie rozumie dlaczego programiści czegoś nie chcą zrobić, ona powinna rozumieć biznes i wtedy jest OK. PO będący jednocześnie programistą to w 9/10 przypadków porażka.

  #3 17.01.2014 20:17

To powinna być jedna osoba (tester i jakościowiec) a ze sposobu rozpisania widać że czerpie wzorce z programowania ekstremalnego oraz SCRUM-a

dzikiwiepsz   11 #4 17.01.2014 23:06

fajny wpis, dość ciekawie to opisane.

  #5 17.01.2014 23:21

Tak zdefiniowany tester to raczej mało przydatna rola, rodzina i znajomi nie są dość skrupulatni i konsekwentni, żeby "klikać" dany moduł aż do znudzenia, tak żeby naprawdę nie zawierał błędów (przynajmniej tych krytycznych i istotnych). Z mojego doświadczenia wynika, że Tester i Jakościowiec to ta sama osoba, znana jako QA (Quality Assurance, po polsku to jest chyba inżynier jakości ?!). To bardzo istotna (i żmudna) rola, to często pierwsza i ostatnia linia obrony dla oprogramowania, to Ci ludzie właśnie powodują, że programy na ogół działają :). Programiści to fajni ludzie (sam nim jestem), ale mają tendencję do przeceniania swojego "dziecka" (kodu) i niezauważania w nim oczywistych błędów, do wymaganiami jest prościej, bo dojrzały zespół i dojrzali programiści zazwyczaj oddają oprogramowanie naprawdę zgodne z wymaganiami.
Co do PO, to powinna być zdecydowanie jedna osoba i najlepiej jeżeli nie rozumie dlaczego programiści czegoś nie chcą zrobić, ona powinna rozumieć biznes i wtedy jest OK. PO będący jednocześnie programistą to w 9/10 przypadków porażka.

ZetIks   2 #6 20.01.2014 08:35

@Matt89 - masz racje biorąc pod uwagę typową firmę software'ową, która ma budżet na te wszystkie etaty, wówczas można ustawić to jak opisałeś. Ja w swoim opisie kierowałem się własnym doświadczeniem, które dotyczyło utworzenia firmy, gdzie na początku było kilku (3) zapaleńców, trochę umiejętności i nieco finansów. Dlatego nie mogliśmy zatrudnić osobnego PO (oraz PM) i jeden z nas musiał wziąć to na klatę.

Co do jakościowiec/tester. Może niezbyt szczególnie do uwypukliłem, ale testerzy nie należą do zespołu projektowego. Jest to ekipa wspomagająca jakościowca. Dlatego napisałem o rodzinie i znajomych. My zrobiliśmy to tak, że znaleźliśmy potencjalnych klientów i za roczny abonament poprosiliśmy o pracę z systemem testowy. Dostali platformę do logowania błędów - dzięki temu wyszło sporo bugów. Zresztą o testowaniu będzie jeszcze jeden wpis

koneton   6 #7 20.01.2014 10:35

Tak jak już napisali poprzednicy - jakościowiec i tester to jest ta sama osoba. Przydają się również testy automatyczne, do klikania aplikacji. Brakuje mi jednak analityka! Programista ma napisać zgodnie z wymaganiami, ale kto te wymagania napisze? Tak samo osoba odpowiedzialna za jakość - ona musi znać wymagania. To jest miejsce dla analityka. W mniejszych projektach, często łączy się funkcję analityka i QA.

ZetIks   2 #8 20.01.2014 13:28

Próbowałem odpisać, ale komentarz się nie wyświetlił.
W tym co pisałem - jakościowiec to ktoś będący w zespole, natomiast testerzy są spoza zespołu. Np. mogą to być użytkownicy systemu beta (tak zrobiliśmy u siebie - w zamian za roczny abonament pozyskaliśmy grono testerów).

Specyfikację wymagań to obowiązek product ownera - jest osobą decyzyjną w zakresie wyglądu, funkcjonalności i innych zagadnień związanych z produkowanym oprogramowaniem.

Wpisy w tej serii mają na celu pokazanie, co zrobić, by mając pomysł, trochę umiejętności i zapału, nieco pieniędzy - uruchomić system, na którym da się zarabiać. Nie jest to przegląd technik używanych w dużych domach software'owych. Bardziej dokumentują drogę, jaką musiałem wraz z moimi współpracownikami (łączenie na początku było nas trzech) przebyć. Przypisaliśmy (częsciowo też wypracowaliśmy) sobie opisane role i one pozwoliły pchnąć nam projekt do szczęśliwego końca :-)

  #9 09.03.2014 21:25

Ciekawe, czy beda kolejne artykuly serii...?

ZetIks   2 #10 13.03.2014 11:11

Artykuły będą, zgodnie z obietnicą. Niestety nawał pracy nieco przesunął termin kolejnego artykułu. Wkrótce pojawi się coś nowego.

  #11 05.09.2015 21:51

Ewidentnie brakuje analityka.
I ktoś pomylił pojęcia, testerem powinien byź ktoś z zapleczem technicznym, żeby to był tester qa, a nie ktoś kto "przeklika". XXI wiek wita.
Artykuł raczej tak sobie napisany.