Praktyczne spojrzenie na projektowanie produktów, tworzenie oprogramowania i decyzje podejmowane po drodze.
Zacznij od ustalenia, jakie interfejsy stary system rzeczywiście obsługuje i kto może go zmieniać. Nowoczesne API może osłonić nowe aplikacje przed starymi szczegółami, ale nie naprawi niewiarygodnego systemu źródłowego.
Duży arkusz kalkulacyjny nie staje się automatycznie projektem oprogramowania.
Proces akceptacji powinien sprawiać, że decyzję można prześledzić, a nie tylko szybciej wysyłać przypomnienia.
Raport nadaje się do automatyzacji, gdy jego definicje są wystarczająco stabilne, aby odtworzyć wynik — nie tylko wtedy, gdy ręczne przygotowanie jest uciążliwe.
System rezerwacji obiecuje więcej niż tylko godzinę w kalendarzu.
Portal ogranicza powtarzalną pracę, gdy klienci mogą ukończyć użyteczne zadanie bez proszenia pracownika o interpretację wyniku.
Wybierz model dostarczania według zadania, które musi działać, a nie według preferencji dotyczącej ikony w sklepie z aplikacjami.
Zacznij od oddzielenia treści publicznych od prywatnej pracy.
Produkt wielojęzyczny potrzebuje stabilnej relacji między treścią, językiem a preferencją użytkownika.
Formularz wyceny powinien zebrać kontekst wystarczający do udzielenia użytecznej odpowiedzi, bez wymagania od odwiedzającego napisania specyfikacji.
Panel biznesowy jest użyteczny, gdy pomaga komuś zauważyć, zrozumieć i wykonać pracę.
Budżet wydajności wyznacza granicę dla określonego doświadczenia użytkownika, a nie wynik wybrany dlatego, że dobrze wygląda.
Pierwszy produkt, trudny proces albo oprogramowanie, które potrzebuje nowego początku. Opowiedz nam, na jakim jesteś etapie.
