Porozmawiajmy o funkcjonalności

W odcinku 20 opowiem o User Stories. Nie będzie to pieśń chwalebna, ale raczej łyżka dziegciu do beczki miodu. Jakie są grzechy User Stories? Czy są prawidłowo używane? Czy ja w swojej pracy używam User Stories? Zapraszam do słuchania.

W 19 odcinku opowiem wam o naszym nowym pomyśle - malinomacie. Co to jest malinomat, jakie są ekonomiczne, społeczne i technologiczne powody jego powstania. Opowiem o kulisach naszej pracy nad wymaganiami. Zdradzę kolejne tajemnice tworzenia Entity Relationship Diagram. Zapraszam do słuchania.

W 18 odcinku opowiem co to jest użyteczność i czy można ją zmierzyć. Opowiem o testowaniu narzędzi do email marketingu pod kątem użyteczności. Dlaczego firmy nie robią użytecznego oprogramowania? Co zrobić by oprogramowanie było bardziej użyteczne? Zapraszam do słuchania.

W poprzednim odcinku opowiedziałem o najcenniejszym diagramie w świecie IT. W 17 odcinku przedstawię przykład diagramu ERD. Diagram ten pomoże nam rozpocząć pracę nad rozwiązywaniem skomplikowanego problemu. Przedstawię zasady tworzenia diagramu. Po kolei opiszę wszystkie bloczki w diagramie. Zapraszam do słuchania i korzystania z tego przykładu.

W 16 odcinku dowiesz się jakich diagramów używałem w swojej pracy i jakie mają wady. Opowiem jaki diagram według mnie jest najbardziej wartościowy w całej branży IT. Dowiesz się jakie są dwie składowe tego diagramu. Opowiem Ci o prawdziwych historiach, kiedy ten diagram oszczędzał firmie wydatków a nawet uratował projekt od zupełnej porażki.

Wprowadzenie poziomów szczegółowości w wymaganiach: wprowadza porządek ułatwia zrozumienie ułatwia utrzymywanie pomaga określać zakres powoduje, że jesteś ważną osobą w projekcie i programiści nie unikają ciebie w sytuacjach, kiedy trzeba zrozumieć co jest do zrobienia w projekcie Wiem jakie poziomy szczegółowości warto wprowadzić w swojej dokumentacji. Posłuchaj, a dowiesz się jak.

Odziedziczyłeś projekt, rozumiesz kod, ale potrzebujesz dokumentacji dzięki której będziesz mógł porozumieć się z biznesem. Jak napisać dokumentację tak aby nie napracować się, ale jednocześnie ustalić zakres projektu? O tym opowiem w 14 odcinku, a także dlaczego nie robiłem nowych odcinków przez aż 2 miesiące .

Odcinek motywujący dla inżynierów wymagań i analityków biznesowych. Jakie są plusy i minusy naszej pracy. Czy praca inżyniera wymagań jest stresująca? Na koniec dowiecie się czy ja pracując w inżynierii wymagań 15 lat jestem zadowolony ze swojej pracy i czy polecam ją bliskim osobom.

Jak sprawić aby komunikacja w zespole była sprawna? Jak pokierować rozmowami z interesariuszami aby te rozmowy kończyły się konkretnymi ustaleniami? Poznaj pięć ram, według których warto prowadzić komunikację co trzeba zrobić w projekcie. Dzięki temu zaoszczędzisz masę czasu.

W każdym projekcie IT pojawia się masa dodatkowych pomysłów. Z pozoru właściwe i logiczne są one źródłem strat dla firmy. Posłuchaj o tym dlaczego tak się dzieje i jaka jest tutaj rola inżynierii wymagań.

Czemu funkcjonalność, która jest prawie taka sama jak w obecnym systemie, trudno zaimplementować? Czemu funkcjonalność, którą wszyscy rozumieją, nie akceptują klienci? Czemu historyjkę, którą klient tłumaczył już 4 razy, trudno przetestować? Jakie 4 kroki warto zrobić aby testy akceptacyjne przeszły? I na koniec - dlaczego warto pisać głupoty?

Podobno nie da się napisać kompletnej specyfikacji wymagań. Ale czy to prawda, że jesteśmy z góry skazani na porażkę? Na ile możemy się przybliżyć do tworzenia kompletnych wymagań i czy warto to robić? W tym odcinku odpowiem Wam na te pytania.

Co zrobić, żeby ludzie z biznesu mogli posługiwać się swoim branżowym słownictwem w kontaktach z IT? Jak sprawić, żeby IT nie chowało się za technologią? Odcinek opisuje krok po kroku jak pozbyć się barier komunikacyjnych kiedy jedna strona nie rozumie drugiej.

Wyrwij murom zęby krat. Czy warto próbować niszczyć mury między silosami organizacyjnymi? Czy warto pisać dokumentacje? Na pewno warto rozmawiać, ale z kim i o czym - o tym właśnie opowiem w tym odcinku.

Jak przepisać system, którego nie da się przepisać? Jak z trudnej sytuacji zrobić prostą? Kto powinien decydować o kolejności prac w olbrzymich projektach IT? Tego typu rozważania na temat zastosowania inżynierii wymagań do budowania bardzo dużych systemów informatycznych.

Nie rozumiem, ale zaczynam się przyzwyczajać. W tym odcinku o tym co się dzieje jeżeli weźmiemy się za tworzenie systemu informatycznego zanim w pełni zrozumiemy rzeczywistość użytkownika systemu. Dlaczego opracowanie języka jest ważne i co do tego mają płytki ceramiczne, rachunki za prąd oraz podatki od transakcji giełdowych?

Daleko jeszcze? Kierownik projektu jest zmuszony do tego, żeby coś obiecać. No dobra ale co dalej i jak mu w tym wszystkim może pomóc inżynieria wymagań? Manager czuje się jak dziecko w samochodzie jadącym już od dłuższego czasu. Ten odcinek jest o tym jak łatwiej komunikować i monitorować postępy pracy.

Analityk zdobywa przyczółki nagrywając spotkania. Jak sprawić by ludzie chcieli pogadać z Tobą o wymaganiach? Nagrywaj spotkania.

Zakres Analizy Biznesowej zachodzi mocno na zakres User Experience. Co zrobić, żeby sobie pomagać a nie przeszkadzać w pracy?

Murarz, tynkarz, akrobata - czyli kto wpuścił Analityków Biznesowych w maliny? Za co odpowiada Analityk Biznesowy? Analitycy chcą brać na siebie odpowiedzialność za zbyt wiele zaniedbując to co powinno być dla nich najważniejsze.