Ocena systemu powiadomień

Historia, która zaczyna się od jednego e-maila, kończy się jako jedyne dzieło, 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ć” oraz nadpisania dla poszczególnych kanałów (z których żadne nie figurowało w pierwotnym zgłoszeniu) stają się kwestiami niepodlegającymi negocjacjom 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ść w 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 jednodniowe”.

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 miejsc odnosi się do „stołu dla trzydziestu osób”, a nie do „pierwszego rzędu”. Jeśli widownia ma widok jedynie na pierwszy rząd, przedstawienie nie jest jeszcze gotowe, dlatego należy wyodrębnić ten jeden kanał, którego Państwo obecnie potrzebują, z systemu, który będzie się rozbudowywał w przyszłości.

Proszę skupić się na skali systemu, a nie na treści wiadomości e-mail. Pierwsze powiadomienie dotyczy jednego dnia; trzydzieste dotyczy całego projektu.

Podobnie jak w przypadku szacowania integracji płatności, widoczna część projektu nie oddaje w pełni zakresu prac. Proszę zapoznać się z innymi przykładami opracowanych szacunków lub rozpocząć bezpłatną sesję „planning poker”, gdy schemat zostanie naszkicowany.