Za mały projekt na software house? Co mieści się w 10, 20 i 30 godzinach, a gdzie aplikacja przestaje być mała

Jest taka kategoria pomysłów, z którymi właściciele firm nigdzie nie dzwonią. Formularz zleceń, który zastąpiłby maile i telefony. Kalkulator wyceny dla handlowców, żeby nikt nie liczył rabatów w głowie. Wniosek urlopowy, który nie ginie w skrzynce kierownika. Każdy z nich rozwiązuje realny problem, ale wydaje się za mały na software house: głupio zawracać komuś głowę, skoro firmy programistyczne mówią o projektach za setki tysięcy.

Ta obawa ma podstawy. Klasyczny software house często zaczyna rozmowę od minimum rzędu 150–300 tys. zł i wyceny, która trwa tygodniami. Przy takim progu jeden formularz nie ma gdzie się zmieścić, więc zostaje w Excelu, w zeszycie albo w czyjejś głowie. U nas dolny próg to jedna godzina, czyli 300 zł netto, a typowy mały projekt zamyka się w 10–30 godzinach.

Ten wpis rozpisuje, co konkretnie mieści się w 10, 20 i 30 godzinach, i, co równie ważne, po czym poznać, że mała aplikacja przestała być mała. Bo pomysł „na jeden problem” rzadko bywa za mały. Znacznie częściej po cichu rośnie, zanim ktokolwiek policzy godziny.

Co to znaczy „aplikacja na jeden problem”

Mała aplikacja nie jest okrojonym systemem. To narzędzie, które robi jedną rzecz od początku do końca: przyjmuje dane, przepuszcza je przez Wasze reguły i oddaje wynik tam, gdzie jest potrzebny. Dobry kandydat ma cztery cechy:

• Jeden proces z jasnym początkiem i końcem – „klient zgłasza zlecenie, biuro je przyjmuje”, a nie „cała obsługa klienta”.
• Jedna, najwyżej dwie role – na przykład pracownik, który składa wniosek, i kierownik, który go zatwierdza.
• Dane, które już macie – cennik, lista usług, lista pracowników. Nie trzeba ich dopiero wymyślać ani zbierać po działach.
• Wynik, który widać od razu – mniej telefonów, mniej przepisywania, koniec szukania wniosku w skrzynce.

Jeśli Twój pomysł spełnia te cztery warunki, nie jest za mały. Jest dobrze przycięty, a to najczęstsza cecha projektów, które kończą się w terminie i w budżecie.

Co mieści się w 10, 20 i 30 godzinach

Poniżej trzy progi z przykładami. To orientacyjne zakresy, a nie cennik funkcji: dokładną liczbę godzin podaje inżynier po rozmowie, na piśmie, zanim ruszy praca. Stawka jest jedna, 300 zł netto za godzinę, więc każdą pozycję przeliczysz sam.

• Około 10 h · 3 000 zł netto. Klikalna makieta całego narzędzia albo jedna prosta funkcja dołożona do aplikacji, która już działa. Przykłady: formularz zgłoszenia, który zamiast luźnego maila dostarcza komplet pól do jednego miejsca; kalkulator wyceny według Waszego cennika, wysyłany klientowi linkiem; diagnoza i naprawa formularza, który się sypie. Za 10 opłaconych godzin na saldzie masz 10,25 h.
• Około 20 h · 6 000 zł netto. Małe narzędzie wewnętrzne z logowaniem i jednym obiegiem. Przykłady: wniosek urlopowy z akceptacją kierownika, listą nieobecności i powiadomieniem e-mail albo formularz zleceń z listą, statusem i przypisaniem do osoby. Za 20 opłaconych godzin na saldzie masz 21 h.
• Około 30 h · 9 000 zł netto. Pierwsza pełna wersja małej aplikacji: prawdziwa baza danych, osobne konta dla zespołu, kilka statusów, historia zmian z autorem, eksport do arkusza i uruchomienie na Waszej domenie. To sufit dla „aplikacji na jeden problem”. Za 30 opłaconych godzin na saldzie masz 31,75 h.

śr · −2,5 h · wniosek urlopowy: akceptacja kierownika i powiadomienie e-mail – wniosek nie ginie w skrzynce, pracownik widzi status

Gdzie mała aplikacja przestaje być mała

Mała aplikacja rzadko przekracza budżet przez jedną dużą decyzję. Przekracza go przez kilka zdań dopowiedzianych w trakcie, zaczynających się od „a jeszcze żeby”. Każde brzmi niewinnie, a niektóre zmieniają rodzaj projektu. Pięć sygnałów, że pomysł urósł:

• Więcej niż dwie role z różnymi uprawnieniami. Pracownik i kierownik to prosty układ. Pracownik, kierownik działu, kadry, księgowość i zarząd, każdy z innym widokiem i innym zakresem edycji, to już system uprawnień, który trzeba zaprojektować i przetestować.
• Połączenia z programami, których używacie. Wysłanie e-maila to drobiazg. Dwustronna wymiana danych z programem kadrowym, księgowym albo magazynowym to osobne zadanie: trzeba sprawdzić, co ten program w ogóle udostępnia na zewnątrz, i obsłużyć sytuacje, w których dane nie dojdą.
• Płatności. Przyjmowanie pieniędzy przez BLIK albo kartę to nie tylko przycisk „zapłać”. Dochodzą zwroty, nieudane transakcje i zgodność kwot z fakturami. W naszych kotwicach płatności pojawiają się dopiero w wariancie 60 h i nie bez powodu.
• Klienci z zewnątrz zamiast własnego zespołu. Narzędzie dla dziesięciu pracowników można poprawiać w biegu, bo każdy zadzwoni, gdy coś nie działa. Narzędzie dla klientów musi wybaczać każdy błąd wpisu, być czytelne na każdym telefonie i działać wtedy, gdy klient ma czas, a nie biuro.
• Raporty „na wszystko”. Jeden eksport do arkusza to zwykle godzina albo dwie. Panel z wykresami, filtrami i porównaniami rok do roku to osobny mały projekt.

Żaden z tych sygnałów nie jest zakazem. Oznacza tylko, że rachunek przesuwa się z 10–30 godzin w stronę 60 godzin, czyli 18 000 zł netto, gdzie mieszczą się płatności, panel administracyjny i integracje. Lepiej wiedzieć to przed startem niż w połowie salda.

Jak przyciąć pomysł, żeby się zmieścił

Najlepsze małe projekty powstają przez odejmowanie. Zamiast pytać, co jeszcze by się przydało, zadaj trzy pytania:

• Bez czego narzędzie nadal rozwiązuje problem? Wniosek urlopowy bez kalendarza całego zespołu i tak kończy z mailami. Kalendarz można dołożyć za miesiąc, jeśli okaże się potrzebny.
• Co może zostać ręczne przez pierwsze tygodnie? Jeśli raport miesięczny ktoś dziś składa w godzinę, niech składa go dalej, tylko z czystego eksportu. Automatyczny raport zamówisz, gdy będzie wiadomo, czego naprawdę w nim brakuje.
• Kto będzie tego używał od pierwszego dnia? Jeśli odpowiedź brzmi „na razie biuro”, wersja dla klientów może poczekać do drugiego etapu.

Handlowcy liczą wyceny w Excelu, każdy ma swoją wersję cennika i rabaty z głowy. Chcemy jeden kalkulator w przeglądarce: wybierasz usługę i ilość, widzisz cenę z rabatem według progu, wysyłasz klientowi PDF. Bez logowania klientów i bez połączenia z fakturami, na razie.

Taka wiadomość zawiera wszystko, czego inżynier potrzebuje do oszacowania godzin: jeden proces, jedną grupę użytkowników i wprost wymienione rzeczy, których ma nie być. Kalkulator tego typu to orientacyjnie 10–20 h, zależnie od tego, jak skomplikowane są progi rabatowe i jak ma wyglądać dokument dla klienta.

Jak wygląda mały projekt u nas, krok po kroku

Mały projekt przechodzi tę samą drogę co duży, tylko krótszą. Nie ma osobnej ścieżki „dla drobnych klientów” z mniej doświadczonym inżynierem czy dłuższą kolejką.

• Rozmowa przed płatnością. Opisujesz problem, a my mówimy uczciwie, czy to zadanie na kilka godzin, czy na pełny pakiet. Jeśli coś da się załatwić gotowym narzędziem za kilkadziesiąt złotych miesięcznie, też to usłyszysz.
• Zakup godzin i start do 24 h. Po płatności odzywa się inżynier prowadzący, ten sam, który potem buduje. Na 30-minutowej rozmowie ustalacie zakres, który od razu trafia do Twojego panelu.
• Estymata na piśmie i mini-akceptacje. Zanim zejdzie pierwsza godzina, widzisz szacunek. Postęp akceptujesz w małych krokach, co kilka godzin pracy, więc korekta kursu kosztuje kwadrans, a nie przebudowę.
• Saldo jak wyciąg z konta. Każda godzina ma w logu opis i efekt do kliknięcia. Przy budżecie 3 000 czy 6 000 zł widzisz dokładnie, na co poszła każda złotówka.

Formalności są te same co przy dużych projektach. Poufność obowiązuje od pierwszej wiadomości, wprost z regulaminu, więc nawet trzyzdaniowy opis Waszego procesu jest objęty NDA. Pokazy i piloty jadą na danych syntetycznych. Kod i pełne prawa majątkowe są w 100% Twoje, a fakturę VAT wystawia aveneo, software house działający od 2008 roku, którego marką jest uncrn.

Kiedy mimo wszystko nie budować

Uczciwie: część małych problemów nie potrzebuje żadnej aplikacji. Jeśli formularz wypełnia pięć osób raz w miesiącu, wystarczy darmowy formularz online i arkusz. Jeśli zadanie zajmuje godzinę w kwartale, spisana instrukcja da więcej niż jakikolwiek kod.

Prosty test: godziny tygodniowo, które dziś zjada problem, razy koszt godziny pracownika razy 48 tygodni. Przy dwóch godzinach tygodniowo i 50 zł za godzinę wychodzi 4 800 zł rocznie, więc narzędzie za 3 000 zł netto zwraca się po około 30 tygodniach. Przy dwudziestu minutach tygodniowo nie zwróci się nigdy i to też usłyszysz na pierwszej rozmowie.

Pomysł na jeden problem nie jest więc ani za mały, ani wstydliwy. Jest dokładnie tak duży jak problem, który rozwiązuje. Policz go, przytnij do pierwszego etapu i dopiero wtedy kup godziny, ani jednej więcej.

← wszystkie wpisy