Jak zbudowaliśmy TickerFlow: system alertów, który pilnuje giełdy za inwestora

Produkt, który postanowiliśmy zbudować

Pilnowanie giełdy zajmuje czas - i to jest problem, od którego zaczyna TickerFlow. Inwestor często ma już odrobioną pracę: wybrał spółki, które uważa za dobre i które chce kupić. Nie chce kupować ich kiedykolwiek, tylko w konkretnym momencie, gdy rynek potwierdzi jego tezę - na przykład gdy na spółce wyraźnie wzrośnie wolumen albo cena przebije ważny poziom. Kłopot w tym, że takich spółek na liście bywają dziesiątki, a instrumentów na rynku tysiące, i nikt nie jest w stanie siedzieć cały dzień, patrząc na wszystkie naraz.

W praktyce oznacza to nużący, codzienny rytuał: przeglądanie notowań, sprawdzanie, czy na którejś z obserwowanych spółek wydarzyło się to, na co się czeka, oraz ciągły niepokój, że przegapiło się dokładnie ten moment, dla którego cała lista powstała. To praca, która pożera uwagę, a większość dni kończy się wnioskiem, że nic się nie stało - co i tak trzeba było sprawdzić, żeby mieć pewność.

Produkt, który postanowiliśmy zbudować, odwraca ten ciężar. Zamiast kazać człowiekowi pilnować rynku, to system pilnuje rynku za niego. Inwestor raz definiuje, na co czeka - które spółki i przy jakim warunku ceny albo wolumenu - a potem może zająć się swoim życiem. Gdy warunek naprawdę zajdzie, dostaje powiadomienie. Co trzeba było zrobić, żeby ta prosta obietnica się utrzymała, i gdzie naprawdę siedziała trudność, opisuje dalsza część tej strony.

Zamiast kazać człowiekowi pilnować rynku, to system pilnuje rynku za niego.

Koszt tego ciągłego pilnowania jest podwójny. Pierwszy to czas - realne godziny tygodniowo spędzone na przeglądaniu notowań, które w większości i tak kończą się niczym. Drugi, mniej widoczny, to koszt przegapienia: pojedynczy dobrze złapany moment potrafi znaczyć więcej niż tygodnie obserwacji, a jego przeoczenie boli długo po tym, jak się wydarzyło. Produkt, który zdejmuje z człowieka pilnowanie, oddaje mu jedno i drugie - odzyskany czas oraz pewność, że nie przegapił tego, na co czekał.

Sygnał, nie ciągłe patrzenie

U podstaw TickerFlow leży założenie starsze niż jakiekolwiek narzędzia giełdowe: dobra decyzja to nie ta podejmowana najczęściej, tylko ta podjęta we właściwym momencie. Jesse Livermore, jeden z najsłynniejszych spekulantów w historii, powtarzał, że akcje warto kupować dopiero wtedy, gdy potwierdza to wolumen - gdy za ruchem ceny stoi realne zainteresowanie, a nie przypadkowe drgnięcie. Idea jest prosta: nie chodzi o to, żeby patrzeć na rynek bez przerwy, tylko o to, żeby zareagować, gdy pojawi się konkretny sygnał.

To rozróżnienie kształtuje cały produkt. TickerFlow nie próbuje być kolejnym ekranem pełnym wykresów, na który trzeba się gapić. Jest odwrotnością takiego ekranu: milczy, dopóki nic istotnego się nie dzieje, a odzywa się dokładnie wtedy, gdy warunek zdefiniowany przez inwestora zostaje spełniony. Wartością nie jest ilość pokazywanych danych, tylko trafność jednego powiadomienia w chwili, gdy naprawdę ma znaczenie.

Dla człowieka, który z tego korzysta, zmiana jest zasadnicza. Zamiast aktywnie szukać sygnału wśród szumu tysięcy instrumentów, opisuje sygnał raz, a szukanie zleca systemowi. To przesunięcie pracy z człowieka na oprogramowanie, dokładnie tam, gdzie oprogramowanie jest lepsze - bo nie męczy się, nie zapomina i patrzy na wszystkie spółki naraz.

Jest w tym też prawda o ludzkiej naturze, nie tylko o rynku. Ekran pełen danych, nawet najlepszy, wymaga, żeby ktoś na niego patrzył - a im dłużej nic się nie dzieje, tym rzadziej się na niego zerka, aż w końcu przestaje się patrzeć akurat w dniu, w którym coś się dzieje. Powiadomienie działa odwrotnie: nie domaga się uwagi, dopóki nie jest potrzebne, a gdy jest, samo się o nią upomina. Dla produktu, którego cała wartość to złapanie właściwego momentu, to różnica między narzędziem, które realnie pomaga, a takim, które ładnie wygląda i bywa ignorowane.

Warto podkreślić, że to nie jest narzędzie do podejmowania decyzji za inwestora. Nie mówi, co kupić ani kiedy sprzedać - te decyzje zostają po stronie człowieka, bo to jego pieniądze i jego strategia. Rola produktu jest węższa i uczciwsza: dopilnować, żeby moment, na który czeka, nie umknął mu tylko dlatego, że akurat patrzył w inną stronę.

Jak podeszliśmy do budowy

Ryzyko w TickerFlow nigdy nie leżało w interfejsie, tylko w danych. Ekran do ustawiania progów i powiadomienie na maila były najłatwiejszą częścią pracy. Produkt, który wysyła alerty na podstawie danych niekompletnych, spóźnionych albo błędnych, jest gorszy niż brak produktu, bo podważa zaufanie dokładnie tam, gdzie w grę wchodzą pieniądze.

Dlatego zaczęliśmy od najtrudniejszych pytań: skąd brać rzetelne dane o tysiącach instrumentów, jak robić to bez kosztów, które zjedzą sens produktu, oraz jak wykrywać, że dane ze źródła są po prostu złe, zanim zamienią się w fałszywy alert. To były pytania przesądzające, czy produkt ma rację bytu, więc rozstrzygnęliśmy je najpierw, a interfejs i powiadomienia dobudowaliśmy wokół działającego, zaufanego rdzenia danych.

Sekcje poniżej idą w kolejności budowy: najpierw dane, koszty i jakość, potem logika progów i alertów, na końcu to, co realnie widzi użytkownik. Gdy o powodzeniu produktu decyduje to, co siedzi pod spodem, żadna inna kolejność nie ma sensu.

Dane giełdowe: dlaczego z wielu źródeł

Cały TickerFlow stoi na danych rynkowych, a te okazały się najtrudniejszą częścią układanki. Nie istnieje jedno idealne źródło, które podałoby komplet rzetelnych, aktualnych danych o wszystkich instrumentach z GPW oraz rynków amerykańskich na sensownych warunkach. Każde źródło ma swoje mocne strony, swoje luki oraz swój sposób, w jaki czasem się myli.

Dlatego zbudowaliśmy produkt tak, by integrować różne źródła danych, zamiast wiązać się z jednym. Łączenie ich daje pełniejszy i bardziej odporny obraz: to, czego brakuje w jednym miejscu, często jest w drugim, a rozbieżność między źródłami sama w sobie bywa sygnałem, że z którymś zestawem danych jest coś nie tak. Wymaga to jednak pogodzenia informacji, które przychodzą w różnych formatach, z różnymi konwencjami i w różnym czasie - a zrobienie tego spójnie, dla tysięcy instrumentów, każdego dnia, jest znacznie trudniejsze, niż wydaje się z zewnątrz.

Można zapytać, czemu nie oprzeć się po prostu na jednym dobrym, płatnym dostawcy. Odpowiedź jest praktyczna: nawet najlepsze pojedyncze źródło ma dni, w których czegoś brakuje albo coś podaje błędnie, a związanie z nim całego produktu oznacza, że jego gorszy dzień staje się gorszym dniem wszystkich użytkowników. Wiele źródeł to nie ekstrawagancja, tylko ubezpieczenie - i zarazem sposób, by wzajemnie się kontrolowały.

Integracja wielu źródeł to decyzja, która kosztuje więcej pracy z góry, ale jest fundamentem zaufania do produktu. Alert, który TickerFlow wysyła, jest tak dobry jak dane, na których się opiera - a te dane muszą być pełne i sprawdzone, zanim ktokolwiek podejmie na ich podstawie decyzję o pieniądzach.

Pogodzenie źródeł to nie tylko kwestia formatów. Ten sam instrument bywa inaczej oznaczany w różnych miejscach, notowania z GPW i z giełd amerykańskich kończą się o innych porach i w innych strefach czasowych, a to, co jedno źródło podaje jako cenę zamknięcia, drugie może liczyć nieco inaczej. Zbudowanie z tego jednego, spójnego obrazu każdej spółki wymaga zestawu reguł, które godzą te różnice w sposób powtarzalny, a nie od przypadku do przypadku.

Osobnym problemem są zdarzenia korporacyjne: splity, dywidendy, resplity. Dla człowieka jest oczywiste, że po splicie akcji cena spada proporcjonalnie do współczynnika podziału, bez żadnego realnego ruchu; dla systemu liczącego progi to potencjalny fałszywy alarm o gigantycznej skali. Historia musi być spójnie skorygowana o takie zdarzenia, inaczej wczorajszy split zamieni się dziś w setki bezsensownych powiadomień. To jeden z tych szczegółów, które są niewidoczne, dopóki nie zrobi się ich źle.

Optymalizacja kosztów: każde zapytanie kosztuje

Jest w tym haczyk, który potrafi wywrócić ekonomię całego produktu: dostęp do danych giełdowych kosztuje, a agregatorzy danych naliczają opłaty za zapytania. Przy jednej spółce to nieistotne. Przy tysiącach instrumentów, sprawdzanych regularnie, naiwne podejście - po prostu pytaj o wszystko, kiedy trzeba - generuje rachunek rosnący szybciej niż jakakolwiek wartość, którą produkt mógłby dostarczyć.

Optymalizacja kosztów nie była więc dodatkiem, tylko warunkiem istnienia. Trzeba było zaprojektować, o co, kiedy i jak często system w ogóle pyta - tak, żeby pobierać to, co naprawdę potrzebne, nie płacić dwa razy za to samo oraz nie odpytywać źródeł częściej, niż wymaga tego sens danych, które i tak aktualizują się w określonym rytmie. To ciągła gra między kompletnością a kosztem: dane muszą być wystarczająco świeże, żeby alert miał wartość, ale pobierane wystarczająco oszczędnie, żeby produkt się spinał.

To jeden z tych obszarów, w których o powodzeniu decyduje inżynieria niewidoczna dla użytkownika. Nikt, kto dostaje trafne powiadomienie, nie myśli o tym, ile zapytań i do ilu źródeł musiało się za nim wydarzyć, ani ile pracy włożono w to, żeby ta liczba była jak najmniejsza. A to właśnie ta praca sprawia, że produkt w ogóle ma sens biznesowy.

W praktyce oznacza to sporo pracy nad tym, żeby nie pobierać dwa razy tego, co już się ma, i nie pytać o dane, które i tak nie mogły się zmienić. Raz pobrana historia się nie starzeje, więc nie ma powodu sięgać po nią ponownie; interesuje nas głównie to, co dołożyła ostatnia sesja. Brzmi to banalnie, a przy tysiącach instrumentów oraz wielu źródłach decyduje o tym, czy miesięczny rachunek za dane jest ułamkiem, czy wielokrotnością tego, co produkt jest w stanie zarobić.

Optymalizacja kosztu zmienia też, co w ogóle jest wykonalne. Gdy każde zapytanie jest tanie lub darmowe, można sprawdzać wszystko, cały czas, bez namysłu. Gdy każde kosztuje, projekt produktu oraz projekt jego ekonomii stają się tym samym zadaniem: to, jak często i o co pytamy, wynika zarówno z tego, czego potrzebuje użytkownik, jak i z tego, na co produkt może sobie pozwolić. Pogodzenie jednego z drugim jest częścią inżynierii, nie osobną tabelką w arkuszu.

Ta sama dyscyplina ma jeszcze jedną zaletę: skalowalność. Produkt, który od początku pyta oszczędnie, rośnie taniej - dołożenie kolejnych spółek czy użytkowników nie mnoży rachunku w tym samym tempie, co przy podejściu naiwnym. Koszt, zamiast być hamulcem wzrostu, przestaje być problemem, o którym trzeba stale myśleć.

Wysoki standard jakości danych

Skoro alerty dotyczą pieniędzy, poprzeczka jakości danych musi być wysoka - i to był jeden z twardszych wymogów całego projektu. Dane ze źródeł zewnętrznych bywają błędne na wiele sposobów: brakujący dzień notowań, wartość oczywiście nierealna, cena skorygowana w jednym źródle, a w drugim nie, wolumen zerowy tam, gdzie po prostu zabrakło danych, a nie handlu. Każdy z tych przypadków, potraktowany bezkrytycznie, zamienia się w fałszywy alert albo w milczenie tam, gdzie alert powinien paść.

Dlatego wbudowaliśmy warstwę, która traktuje dane źródłowe z zasady nieufnie. Wartości są sprawdzane pod kątem sensowności, porównywane między źródłami tam, gdzie się da, oraz oznaczane, gdy coś odstaje na tyle, że bardziej prawdopodobny jest błąd danych niż realne zdarzenie na rynku. Lepiej wstrzymać się z alertem opartym na podejrzanej wartości, niż wysłać powiadomienie, które okaże się skutkiem literówki w danych.

Samą jakość też trzeba umieć sprawdzić, a nie tylko zadeklarować. Dane porównujemy między źródłami, zestawiamy z historią i obserwujemy, jak często warstwa kontroli coś wyłapuje - bo nagły wzrost liczby oznaczonych anomalii sam w sobie jest sygnałem, że któreś źródło zaczęło dostarczać śmieci. Bez takiego pomiaru „dbamy o jakość danych" jest tylko deklaracją, a przy produkcie dotyczącym pieniędzy deklaracja nie wystarcza.

To rozróżnienie - między prawdziwym zdarzeniem a artefaktem złych danych - jest sednem tego, czy produktowi można ufać. Alert to obietnica, że stało się dokładnie to, na co inwestor czekał. Jeśli ta obietnica choć raz okaże się skutkiem śmiecia w danych, użytkownik przestaje traktować powiadomienia poważnie - a wtedy cały produkt traci sens, niezależnie od tego, jak ładnie wygląda.

Warto nazwać rodzaje błędów, bo każdy wymaga innej reakcji. Wartość skrajnie nierealna - cena dziesięć razy za wysoka, wolumen z dodatkowym zerem - jest łatwa do złapania regułą sensowności. Trudniejsze są błędy subtelne: kurs różniący się o kilka procent między źródłami albo dzień, którego brakuje w jednym zestawie, a jest w drugim. Najgroźniejsze są te, które wyglądają zupełnie normalnie, a są po prostu nieprawdziwe - i tu jedyną obroną jest porównanie źródeł oraz kontekst historyczny, który podpowiada, co dla danej spółki jest prawdopodobne.

Jest też cichszy wariant problemu: nie błędna dana, lecz jej brak. Źródło, które danego wieczoru nie dostarczy notowań części spółek, nie zgłasza błędu - po prostu milczy. Bez świadomej obsługi takiej luki produkt uzna, że na tych spółkach nic się nie działo, i nie wyśle alertów, które powinien. Dlatego kompletność traktujemy równie poważnie jak poprawność: brak danych musi zostać wykryty oraz odróżniony od realnego braku ruchu.

Codzienny proces po zamknięciu sesji

TickerFlow działa w rytmie giełdy. Po zamknięciu sesji uruchamia się codzienny proces, który pobiera dane danego dnia, przetwarza je i sprawdza względem warunków ustawionych przez wszystkich użytkowników. To świadomy wybór modelu: produkt opiera się na danych sesyjnych, na tym, co wydarzyło się w ciągu dnia handlowego, a nie na śledzeniu każdego drgnięcia ceny w czasie rzeczywistym, które byłoby zarazem dużo droższe i dużo bardziej podatne na szum.

Taki wsadowy przebieg brzmi prosto, a kryje sporo inżynierii. Musi przetworzyć dane dla tysięcy instrumentów w rozsądnym oknie czasu po sesji, tak żeby powiadomienia dotarły, zanim staną się nieaktualne. Musi poradzić sobie z tym, że część źródeł bywa danego wieczoru wolna albo niekompletna. Musi też robić to samo, niezawodnie, każdego dnia handlowego, bo pominięty przebieg oznacza pominięte sygnały - a użytkownik, który raz nie dostał alertu, o którym wie, że powinien paść, słusznie traci zaufanie.

Zbudowanie procesu, który liczy dużo, liczy poprawnie i mieści się w czasie, dzień po dniu, to klasyczny przykład pracy, której nie znajdziesz w żadnym zestawieniu możliwości, a która przesądza, czy produkt w ogóle spełnia swoją obietnicę.

Presja czasu jest tu realna. Okno po zamknięciu sesji, w którym powiadomienie ma jeszcze wartość, nie jest nieograniczone - alert o sygnale z wczoraj, który przychodzi w środku kolejnej sesji, jest już spóźniony. To znaczy, że cały przebieg, od pobrania danych ze wszystkich źródeł po wysłanie ostatniego maila, musi zmieścić się w napiętym budżecie czasu, nawet w wieczory, gdy któreś ze źródeł zwleka. Dlatego kolejność i równoległość pracy nie są przypadkowe: to, co można policzyć wcześnie, liczy się wcześnie, żeby na końcu została jak najmniejsza część zależna od najwolniejszego źródła.

Taki przebieg musi być też odporny na powtórzenie. Jeśli coś padnie w połowie i trzeba go uruchomić ponownie, nie może wysłać tych samych alertów drugi raz ani policzyć części danych podwójnie. Zaprojektowanie go tak, żeby dało się go bezpiecznie wznowić, a wynik był zawsze taki sam niezależnie od tego, ile razy się wykonał, to jedna z tych rzeczy, które odróżniają proces, któremu można zaufać, od skryptu, który zwykle działa.

Skala: tysiące instrumentów, miliony rekordów

Skala robi z tego osobne wyzwanie. TickerFlow obejmuje blisko siedem tysięcy instrumentów z NASDAQ, NYSE i GPW oraz ponad milion rekordów historycznych - a to właśnie na tle historii wiele warunków w ogóle nabiera sensu. „Wyraźny wzrost wolumenu" nie znaczy nic bez punktu odniesienia: trzeba wiedzieć, jaki wolumen jest dla danej spółki normalny, żeby ocenić, że dzisiejszy jest nietypowy.

Utrzymywanie i przetwarzanie takiej historii, bez rozdmuchania kosztów oraz czasu przebiegu, to kolejna warstwa tej samej układanki danych. Historia musi być kompletna i spójna, bo próg liczony na dziurawych danych daje albo fałszywe alarmy, albo ciszę w złym momencie. A im dłuższa i bogatsza historia, tym lepsze punkty odniesienia - i tym więcej pracy, żeby liczyć to wszystko szybko i tanio każdego wieczoru.

Punkt odniesienia trzeba przy tym liczyć osobno dla każdej spółki, bo „normalny wolumen" płynnego giganta z NASDAQ i cienkiego waloru z GPW to dwa zupełnie różne światy. Ten sam warunek - „wyraźny wzrost" - musi znaczyć co innego w każdym z tych przypadków, a to znaczenie bierze się właśnie z historii danego instrumentu. Utrzymanie tych indywidualnych punktów odniesienia aktualnymi, dla tysięcy spółek, to część pracy, która sprawia, że jeden prosty warunek działa sensownie w całym spektrum rynku.

Progi definiowane przez inwestora

Sercem produktu od strony użytkownika są progi. Inwestor opisuje, na co czeka: które spółki go interesują i jaki warunek ma je wyzwolić - przekroczenie poziomu ceny, nietypowy wzrost wolumenu, kombinacja jednego z drugim. To on wie, jaka jest jego teza i jaki sygnał ją potwierdza; zadaniem produktu jest wiernie pilnować dokładnie tego, o co poprosił.

Prostota z zewnątrz kryje decyzje projektowe pod spodem. Warunki muszą być na tyle elastyczne, żeby oddać realne strategie, a zarazem na tyle zrozumiałe, żeby ktoś, kto nie jest programistą, potrafił je ustawić bez instrukcji obsługi. Trzeba też jednoznacznie zdefiniować, kiedy warunek uznaje się za spełniony - bo „wzrost wolumenu" brzmi oczywiście, dopóki nie trzeba zamienić go w precyzyjną regułę, która działa tak samo dla płynnej spółki z NYSE i dla cienkiego waloru z GPW.

Zanim warunek zacznie działać na żywo, warto wiedzieć, jak zachowałby się w przeszłości. Możliwość sprawdzenia progu na danych historycznych - ile razy by się uruchomił, na których spółkach, w jakich momentach - zamienia ustawianie alertu ze zgadywania w świadomą decyzję. To także najlepsza obrona przed warunkiem zbyt czułym: jeśli na historii odpalałby się codziennie, prawdopodobnie odpali się i teraz zbyt często, żeby ktokolwiek go słuchał.

Dobrze zaprojektowany próg to taki, przy którym użytkownik dostaje dokładnie te alerty, o które prosił - nie więcej i nie mniej. Zbyt czułe warunki zalewają go szumem i uczą ignorować powiadomienia; zbyt sztywne przepuszczają dokładnie te ruchy, dla których produkt powstał. Trafienie w tę równowagę jest tyleż projektowaniem interfejsu, co rozumieniem, jak ludzie naprawdę handlują.

W praktyce strategie bywają różne: jeden inwestor czeka na przebicie rocznego szczytu przy podwyższonym wolumenie, inny na spokojną akumulację poniżej pewnego poziomu, jeszcze inny na sam nietypowy ruch obrotu, niezależnie od ceny. Produkt musi umieć oddać te różne intencje, nie zmuszając nikogo do myślenia jak programista. Im wierniej warunek odpowiada temu, co inwestor ma naprawdę w głowie, tym bardziej ufa powiadomieniom - a zaufanie do alertów jest tu jedyną walutą, która się liczy.

Alerty, które można traktować poważnie

Cała wartość TickerFlow zbiega się w jednym momencie: gdy przychodzi powiadomienie. Wszystko inne - dane, koszty, jakość, przebieg - istnieje po to, żeby ten jeden moment był wiarygodny. Alert, który przychodzi za późno, jest bezużyteczny; alert, który przychodzi bez pokrycia w rzeczywistości, jest gorszy niż bezużyteczny, bo szkodzi. Punktualność i prawdziwość to więc miejsca, w które poszła większość wysiłku.

Punktualność wynika z rytmu przebiegu: proces po sesji jest tak ułożony, żeby sygnał trafił do inwestora, gdy jeszcze ma znaczenie dla decyzji na kolejną sesję. Prawdziwość wynika z warstwy jakości danych: alert pada tylko wtedy, gdy warunek został spełniony na danych, którym można zaufać, a nie na podejrzanej wartości ze zbłąkanego źródła. Te dwie rzeczy razem sprawiają, że powiadomienie coś znaczy.

Liczy się też, co powiadomienie zawiera. Alert, który mówi tylko, że coś się wydarzyło, zmusza inwestora do samodzielnego dochodzenia, co i dlaczego - czyli częściowo wraca ten sam wysiłek, który produkt miał zdjąć. Dlatego powiadomienie od razu niesie kontekst: która spółka, jaki warunek, jakie wartości go spełniły. Chodzi o to, żeby po przeczytaniu jednego maila człowiek wiedział dość, by zdecydować, czy w ogóle warto zajmować się sprawą dalej.

Bo ostatecznie produkt taki jak ten sprzedaje jedno: zaufanie do własnego milczenia. Użytkownik musi móc założyć, że skoro TickerFlow nic nie przysłał, to nic istotnego się nie wydarzyło - i że jeśli przysłał, to warto spojrzeć. Zbudowanie czegoś, na czym da się polegać w ten sposób, jest znacznie trudniejsze niż samo wysyłanie maili, gdy jedna liczba przekroczy drugą.

Największym wrogiem takiego produktu jest zmęczenie alertami. Wystarczy kilka powiadomień, które okazały się nieistotne, żeby użytkownik zaczął je odruchowo ignorować - a wtedy przegapi również to jedno ważne. Dlatego świadomie stawiamy na mniej, ale trafniej: lepiej, żeby TickerFlow odzywał się rzadziej, a każde odezwanie miało wagę, niż żeby był gadatliwy i przez to niesłuchany. To decyzja produktowa równie ważna jak każda reguła w silniku.

Powiadomienia, które docierają na czas

Kanałem, którym docierają sygnały, jest e-mail - i to również wybór, nie przypadek. Powiadomienie o okazji na rynku musi dotrzeć tam, gdzie inwestor i tak zagląda, bez zmuszania go do trzymania otwartej kolejnej aplikacji czy pilnowania osobnego ekranu. E-mail jest wszędzie, jest trwały i łatwo wraca się do niego później.

Dostarczalność jest tu jednak osobnym problemem inżynierskim. Powiadomienie, które wyląduje w spamie albo dotrze z opóźnieniem, jest tak samo bezwartościowe jak niewysłane. Zadbanie o to, żeby maile wychodziły punktualnie po sesji i realnie trafiały do skrzynki odbiorczej, to praca, o której nikt nie myśli, dopóki nie zawiedzie - a przy produkcie, którego cała obietnica brzmi „damy znać w odpowiednim momencie", zawieść nie może.

Aplikacja webowa

Poza powiadomieniami TickerFlow ma aplikację webową, w której dzieje się reszta: definiowanie i porządkowanie progów, przegląd obserwowanych spółek, sprawdzenie, co i dlaczego wywołało dany alert. Wybór weba, a nie aplikacji mobilnej, wynika z tego, jak ludzie faktycznie pracują z takim narzędziem - konfigurację strategii wygodniej robić przy większym ekranie, na spokojnie, a nie w biegu na telefonie.

Interfejs jest zaprojektowany tak, żeby konfiguracja była zrozumiała dla inwestora, a nie tylko dla inżyniera. Ustawienie warunku, przypisanie go do spółek, zobaczenie, jak zadziałałby na danych - wszystko to ma prowadzić człowieka za rękę, bo próg ustawiony przez pomyłkę to albo przegapiona okazja, albo fałszywy alarm. Produkt jest tak dobry, jak łatwo poprawnie powiedzieć mu, na co ma uważać.

Ważną częścią aplikacji jest możliwość sprawdzenia, dlaczego dany alert się pojawił. Zaufanie do powiadomień rośnie, gdy da się je zweryfikować: zobaczyć, jaki warunek został spełniony, na jakich danych i w którym momencie. Przejrzystość jest tu funkcją zaufania - inwestor, który raz sprawdzi, że alert był słuszny, następnym razem zareaguje bez wahania, bo wie, że produkt nie strzela na oślep.

Baza wiedzy

Do produktu dołączyliśmy też bazę wiedzy liczącą ponad pięćdziesiąt rozdziałów. Nie jest to dodatek marketingowy, tylko część tego samego pomysłu: narzędzie, które pomaga reagować na sygnały, jest warte tyle, ile rozumienie, dlaczego dany sygnał ma znaczenie. Inwestor, który wie, skąd wzięła się zasada patrzenia na wolumen albo jak interpretować przebicie poziomu, ustawia lepsze progi i podejmuje lepsze decyzje niż ktoś, kto tylko klika w interfejsie.

Napisanie i uporządkowanie takiej bazy to osobny kawał pracy, ale wpisuje się w tę samą filozofię co reszta produktu: przenieść ciężar z użytkownika na narzędzie. Tam, gdzie się da, robi to automatyzacja i dane; tam, gdzie potrzebna jest ludzka decyzja, robi to wiedza podana w zrozumiałej formie, w miejscu, w którym akurat jest potrzebna.

Zasada Livermore'a o wolumenie jest tu dobrym przykładem: sam alert powie, że wolumen wzrósł, ale to rozdział bazy wiedzy tłumaczy, dlaczego akurat na to warto patrzeć i jak nie pomylić potwierdzenia z pułapką. Narzędzie oraz wiedza działają razem - jedno wychwytuje moment, drugie pomaga go zrozumieć. Produkt, który daje sygnał bez kontekstu, uczy klikać; produkt, który daje jedno i drugie, uczy podejmować lepsze decyzje.

Baza wiedzy pełni też rolę przy pierwszym kontakcie z produktem. Ktoś, kto dopiero zaczyna, nie zawsze wie, jaki warunek ma sens ustawić - a wtedy krótki rozdział tłumaczący daną strategię jest różnicą między świadomym pierwszym progiem a przypadkowym klikaniem. Dobra dokumentacja skraca drogę od rejestracji do pierwszego trafnego alertu, a to właśnie ten pierwszy trafny alert przekonuje, że warto zostać.

Niezawodność: proces, który nie może po cichu zawieść

Jest jeden rodzaj awarii, na który produkt taki jak TickerFlow nie może sobie pozwolić: awaria cicha, o której nikt się nie dowiaduje. Jeśli codzienny przebieg się nie wykona albo wykona się na niekompletnych danych, a nikt tego nie zauważy, użytkownicy po prostu nie dostaną alertów, które powinni dostać - i nawet się o tym nie dowiedzą. Brak powiadomienia wygląda identycznie, gdy nic się nie wydarzyło, i gdy system zawiódł. To najgroźniejszy scenariusz, bo podważa zaufanie do milczenia produktu, które jest jego istotą.

Gdy coś już zawiedzie, liczy się, jak szybko da się to naprawić bez szkody. Przebieg, który da się bezpiecznie powtórzyć na brakujących danych, gdy tylko źródło wróci, oznacza, że wieczorna usterka nie musi zamienić się w stracony dzień sygnałów. Zdolność do spokojnego nadrobienia zaległości jest równie ważna jak unikanie awarii - bo awarie i tak się zdarzają, a różnicę robi to, czy zostają po nich trwałe luki.

Dlatego niezawodność potraktowaliśmy jako funkcję, a nie założenie. Przebieg musi wykonać się każdego dnia handlowego, a jeśli coś pójdzie nie tak - padnie źródło, dane przyjdą niekompletne, przetwarzanie się wywali - to trzeba o tym wiedzieć i zareagować, zamiast pozwolić, żeby cisza udawała normalność. Pilnowanie samego pilnującego jest tu równie ważne jak pilnowanie rynku.

W praktyce oznacza to, że pilnujemy nie tylko rynku, ale i samego przebiegu: czy wykonał się w oczekiwanym oknie, czy pobrał dane ze wszystkich źródeł, czy liczby na wyjściu mieszczą się w rozsądnych granicach. Gdy coś odstaje, sygnał trafia do zespołu, zanim trafi - albo raczej nie trafi - do użytkownika. Cisza wobec użytkownika jest w porządku tylko wtedy, gdy jest zamierzona; cisza wynikająca z niezauważonej awarii jest dokładnie tym, przed czym ten monitoring ma chronić.

Co ten projekt mówi o tym, jak pracujemy

Wysłać maila, gdy jedna liczba przekroczy drugą, potrafi każdy w popołudnie. Robić to każdego dnia sesyjnego na tysiącach instrumentów, na danych, których nikt nie kontroluje, z rachunkiem mniejszym niż przychód i z warstwą wyłapującą śmieci, zanim zamienią się w fałszywy alert - tam idą miesiące.

Dwa pytania rozstrzygnęliśmy, zanim powstała pierwsza linijka kodu: ile realnie kosztują dane przy siedmiu tysiącach instrumentów i co się dzieje w wieczór, w którym źródło po cichu kłamie. Oba zagrażały ekonomii produktu, a nie harmonogramowi, i dlatego żadne nie mogło poczekać do połowy prac. Sprawdzanie trafiło potem do kogoś, kto nie pisał pipeline'u, bo w produkcie danowym usterki siedzą dokładnie tam, gdzie autor był pewny, że nic nie może pójść źle.

Uogólniają się tu nie alerty giełdowe, tylko dyscyplina budowania na danych, których się nie posiada: pobieranie ich z więcej niż jednego źródła, świadome płacenie za nie, nieufność wobec nich z założenia i wychwycenie chwili, w której system zamilkł z niewłaściwego powodu. Każdy produkt czerpiący wartość z zewnętrznych danych stoi albo upada na tych czterech rzeczach.

Produkty oparte na danych są przy tym notorycznie niedoszacowywane, bo z zewnątrz wyglądają na proste. „To tylko alerty, gdy cena przekroczy poziom" brzmi jak weekend pracy - dopóki nie dołoży się do tego wielu źródeł, kosztów, jakości, korekt o zdarzenia korporacyjne, skali oraz niezawodności. Umiejętność zobaczenia tej ukrytej trudności z góry, a nie w połowie projektu, jest częścią tego, co odróżnia dowiezienie takiego produktu od utknięcia w nim.

Co powiedzielibyśmy innemu zespołowi

Jeśli myślisz o zbudowaniu produktu, którego wartość opiera się na danych z zewnątrz - alertów, monitoringu, czegokolwiek, co reaguje na to, co dzieje się w świecie - te pięć punktów warto znać przed startem.

• Traktuj dane jak produkt, nie jak wejście. Jeśli pomysł opiera się na danych z zewnątrz, ich kompletność, koszt i jakość są projektem samym w sobie. Zaplanuj je od pierwszego dnia, nie na końcu.
• Policz koszt zapytań, zanim zbudujesz. Przy skali to, co działa dla jednej spółki, potrafi zrujnować ekonomię przy tysiącach. Model kosztowy musi się spinać, zanim napiszesz pierwszą regułę alertu.
• Zakładaj, że źródła się mylą. Dane zewnętrzne bywają błędne, a produkt na nich oparty jest tak wiarygodny jak jego warstwa wychwytująca śmieci. Buduj ją wcześnie i nie ufaj żadnemu źródłu na słowo.
• Cisza musi być wiarygodna. Jeśli produkt komunikuje się przez brak powiadomień, cicha awaria jest najgroźniejszym błędem. Pilnuj pilnującego.
• Trafność ważniejsza niż ilość. Alert, któremu nie można ufać, jest gorszy niż jego brak. Lepiej wysłać mniej powiadomień, ale takich, które coś znaczą.

Te pięć punktów to powód, dla którego produkt danowy kosztuje więcej, niż na to wygląda. Żaden z nich nie jest widoczny w demie, wszystkie są widoczne na fakturze i w skrzynce wsparcia, a każdy jest tańszy do zaprojektowania niż do odkrycia.

Najczęstsze pytania klientów

Czy TickerFlow to Wasz własny produkt, czy zbudowaliście go dla klienta?

To nasz własny. Sami go wymyśliliśmy, zaprojektowaliśmy, zbudowaliśmy i wydaliśmy. Pokazujemy go, bo to dowód tego, co dowozimy, a dla klientów budujemy tak samo.

Czy zbudowalibyście dla nas produkt oparty na danych z zewnętrznych źródeł?

Tak. TickerFlow łączy wiele źródeł danych giełdowych, pilnuje ich kosztu i jakości, a to samo podejście działa dla dowolnego produktu, w którym o wartości decydują dane z zewnątrz.

Jak radzicie sobie z kosztami odpytywania płatnych źródeł danych?

Projektujemy, o co, kiedy i jak często system w ogóle pyta, żeby pobierać tylko to, co potrzebne, nie płacić dwa razy za to samo i nie odpytywać źródeł częściej, niż wymaga tego sens danych. Przy skali tysięcy instrumentów to warunek istnienia produktu, nie dodatek.

Jak zapewniacie, że produkt nie działa na błędnych danych?

Budujemy warstwę, która traktuje dane źródłowe nieufnie: sprawdza ich sensowność, porównuje między źródłami i oznacza anomalie. Wolimy wstrzymać alert oparty na podejrzanej wartości, niż wysłać powiadomienie będące skutkiem błędu w danych.

Czy budujecie codzienne przetwarzanie wsadowe na dużą skalę?

Tak. TickerFlow codziennie po sesji przetwarza dane dla blisko siedmiu tysięcy instrumentów i ponad miliona rekordów historycznych, w oknie czasu, w którym powiadomienia wciąż mają wartość.

Czy to my jesteśmy właścicielem kodu i kont?

Tak. Wy jesteście właścicielem kodu, repozytoriów i kont. Możemy przekazać wszystko Waszemu wewnętrznemu zespołowi, kiedy tylko zajdzie potrzeba, bez uzależniania od nas.