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