Jedna osoba kontaktowa
Po naszej stronie zawsze wiecie, do kogo dzwonić. Ta sama osoba zna projekt od warsztatu.
ul. Rzemieślnicza 96 · Warszawa
Zanim ktokolwiek z nas napisze pierwszą linijkę kodu, chcemy zrozumieć, kto będzie trzymał telefon w ręku, w jakiej sytuacji i po co w ogóle otworzy aplikację. Technologię wybieramy dopiero potem.
Natywnie albo z jednego kodu we Flutterze — decyzja zapada po warsztacie, nie na pierwszym telefonie.
Kolejność kroków nie wzięła się z podręcznika, tylko z tego, gdzie w poprzednich projektach najczęściej coś się sypało. Każdy etap ma więc jeden cel: złapać problem wcześniej, niż zrobi się drogi.
Pierwsze spotkanie trwa około dwóch godzin i najlepiej, żeby odbyło się tam, gdzie aplikacja będzie używana, bo patrząc na ludzi przy pracy, dowiadujemy się więcej niż z maili. Wychodzimy z listą funkcji podzieloną na „musi być” i „może poczekać”.
Makiety pokazujemy na prawdziwym telefonie, a nie na slajdzie, żeby od razu było widać, czy przycisk da się trafić kciukiem jedną ręką w autobusie. Poprawka na tym etapie to godzina pracy, w gotowym kodzie już dzień albo dwa.
Co dwa tygodnie dostajecie wersję testową przez TestFlight albo ścieżkę testów wewnętrznych w Google Play, razem z krótką listą zmian napisaną zwykłym językiem. Bez żargonu.
Sprawdzamy na starszych i nowszych telefonach z naszej półki, ponieważ emulator nie pokaże, jak aplikacja zachowuje się przy słabym zasięgu w metrze albo przy powiększonej czcionce systemowej. Błędy lądują na wspólnej tablicy, którą widzicie.
Przygotowujemy opisy i zrzuty do sklepów, przeprowadzamy aplikację przez recenzję Apple i Google, a potem zostajemy przy projekcie. Nowe wersje systemów wychodzą co roku i ktoś musi tego pilnować.
Jeśli aplikacja intensywnie korzysta z aparatu, Bluetooth albo pracy w tle, kod natywny oszczędza później wielu obejść i nerwów przy aktualizacjach systemu. Przy typowym panelu klienta, formularzach i liście zamówień Flutter wystarcza i kosztuje mniej, bo piszemy jedną bazę kodu zamiast dwóch.
To zależy głównie od tego, ile systemów trzeba połączyć, a nie od liczby ekranów, bo to integracje z istniejącym ERP czy płatnościami zjadają najwięcej czasu. Prosta aplikacja to zwykle kwestia miesięcy, nie tygodni. Konkretny harmonogram dostajecie po warsztacie.
Repozytorium zakładamy od razu na waszym koncie, a autorskie prawa majątkowe przechodzą na zamawiającego wraz z rozliczeniem etapu, co zapisujemy w umowie. Dzięki temu w każdej chwili możecie zmienić wykonawcę.
Tak, ale zaczynamy od płatnego przeglądu kodu, bo bez niego każda wycena byłaby zgadywaniem. Po przeglądzie wiecie, co da się naprawić, a co taniej napisać od nowa.
Nie trzeba, bo większość spotkań odbywa się zdalnie, a wersje testowe trafiają prosto na telefon. Warsztat na żywo bywa jednak szybszy.
Zdarza się to częściej, niż się wydaje, zwykle z powodu opisu uprawnień albo braku konta testowego dla recenzenta, dlatego przygotowujemy jedno i drugie z wyprzedzeniem. Jeśli mimo to przyjdzie odmowa, poprawka i ponowne zgłoszenie są po naszej stronie. Trwa to zwykle dzień lub dwa.
Duży zespół wygląda dobrze w ofercie, ale każda dodatkowa osoba między klientem a programistą to kolejne miejsce, w którym prośba zmienia znaczenie, zanim dotrze do kodu. U nas osoba, która prowadzi z wami warsztat, siedzi dwa biurka od tej, która pisze ekran logowania. To skraca drogę.
Bierzemy przez to mniej projektów naraz i czasem mówimy „dopiero za miesiąc”, co bywa niewygodne dla obu stron. Wolimy jednak uczciwie przesunąć start, niż prowadzić trzy aplikacje po łebkach, bo takie skróty zawsze wracają przy pierwszej aktualizacji. Klient, który poczeka, dostaje potem całą naszą uwagę.
Po naszej stronie zawsze wiecie, do kogo dzwonić. Ta sama osoba zna projekt od warsztatu.
Każdy odcinek pracy ma zakres i kwotę, zanim ruszy. Zmiany zakresu wyceniamy osobno, na piśmie.
Repozytorium, konta deweloperskie w sklepach i klucze podpisu należą do was od pierwszego dnia.
Jeśli czegoś nie da się ocenić bez próby, robimy krótki prototyp techniczny zamiast zgadywać.
M&A GROUP SOFTWARE ENGINEERING Sp. z o.o.
ul. Rzemieślnicza 96, 00-844 Warszawa
+48 22 834 60 26
kontakt@appkora.live
Wejście jest od podwórza, przez drewnianą bramę; na domofonie szukajcie nazwy Appkora. Z przystanku komunikacji miejskiej idzie się kilka minut, więc jeśli jedziecie z centrum, tramwaj albo autobus zwykle wygrywa z samochodem.
W dni robocze ulica leży w strefie płatnego parkowania i o wolne miejsce bywa trudno przed dziesiątą. Na podwórzu trzymamy jedno miejsce dla gości — wystarczy dać znać dzień wcześniej. Rowerem? Stojak jest tuż przy bramie.
Jeśli jedziecie pierwszy raz, zadzwońcie spod bramy, a ktoś zejdzie, bo numer 96 łatwo pomylić z sąsiednim wejściem.
| Poniedziałek–czwartek | 9:00–17:30 |
|---|---|
| Piątek | 9:00–15:00 |
| Sobota, niedziela | nieczynne |
Telefon odbieramy od 9:30, bo wcześniej trwa poranne spotkanie zespołu. Na wizytę w biurze umawiamy się telefonicznie, żeby sala była wolna.
W piątki po południu biuro bywa puste, bo część zespołu pracuje wtedy z domu. Jeśli chcecie przywieźć urządzenie albo dokumenty, lepiej wybrać wtorek lub środę przed południem.
Strona zapisuje w przeglądarce jeden wpis, żeby zapamiętać, że ten komunikat został zamknięty. Więcej w zasadach przechowywania.