Ocena systemu powiadomień
Jak oszacować wymagania dotyczące systemu powiadomień: kanały, preferencje, eliminacja duplikatów i gwarancje dostarczenia. Dlaczego „wysłanie wiadomości e-mail” niepostrzeżenie przeradza się w sześciotygodniowy projekt.
Historia, która zaczyna się od jednego e-maila, kończy się jako jedyny projekt, nad którym zespół pracował przez sześć tygodni.
Pierwsze powiadomienie jest proste: wybierz zdarzenie, wygeneruj szablon, wyślij. Drugie również jest proste. Dziesiąte ma miejsce wtedy, gdy zespół uświadamia sobie, że od dwóch miesięcy tworzy system powiadomień, nie przyznając się do tego. Ustawienia, podsumowania, deduplikacja, okna „nie przeszkadzać”, nadpisania dla poszczególnych kanałów — żadna z tych funkcji nie figurowała w pierwotnym zgłoszeniu — stają się niepodważalne w chwili, gdy użytkownik otrzymuje powiadomienie o trzeciej nad ranem.
Proszę oszacować system, a nie samą wiadomość e-mail. Zespół, który opowiada się za rozwiązaniem „wysyłaj wiadomość na Slacku, gdy wystąpi sytuacja X”, nie docenia skali zadania o rząd wielkości, ponieważ szacuje wielkość jednego wiersza w tabeli, która ostatecznie będzie zawierała trzydzieści wierszy.
O czym się mówi w tym pomieszczeniu
Backend: „Wysyłanie wiadomości e-mail to zadanie na jeden dzień”.
PM: „Czy użytkownicy mogą to wyłączyć?”
Backend: „Dla poszczególnych zdarzeń czy globalnie?”
Projektant: „Jak wygląda strona ustawień?”
SRE: „A co, jeśli usługa poczty elektronicznej nie działa? Ponowić próbę? Umieścić w kolejce? Odrzucić?”
Pomoc techniczna: „Jak wyjaśnić użytkownikowi, dlaczego nie otrzymał wiadomości e-mail?”
Pytania, które warto zadać przed oddaniem głosu
- Czy dzisiaj wystarczy jeden kanał, czy też od samego początku powinniśmy zintegrować pocztę elektroniczną, powiadomienia push i Slacka?
- Preferencje użytkownika — opcja ogólna, dla poszczególnych wydarzeń czy dla poszczególnych kanałów?
- Deduplikacja i skróty — czy są potrzebne już teraz, czy „później”?
- Gwarancje dostarczenia — co najmniej raz, co najwyżej raz, dokładnie raz?
- Ścieżka audytu: czy dział pomocy technicznej może wyjaśnić użytkownikowi, dlaczego powiadomienie nie dotarło?
- Szablony: kto tworzy treść, kto ją lokalizuje i gdzie jest przechowywana?
Rzeczywista liczba dotyczy „stołu dla trzydziestu osób”, a nie „pierwszego rzędu”. Jeśli publiczność widzi jedynie pierwszy rząd, przedstawienie nie jest jeszcze gotowe — split wybierz ten jeden kanał, którego obecnie potrzebują Państwo, z systemu, do którego będą Państwo stopniowo dorastać.
Proszę skupić się na skali systemu, a nie na treści wiadomości e-mail. Pierwsze powiadomienie dotyczy jednego dnia; trzydzieste – całego projektu.
Podobnie jak w przypadku szacowania integracji płatności, to, co widać na zewnątrz, nie oddaje w pełni zakresu prac. Proszę zapoznać się z innymi przykładami szacowania lub rozpocząć bezpłatną sesję planowania pokerowego, gdy szkic tabeli będzie już gotowy.