Pracują w typowo biznesowym środowisku - czyli standardy typu wypracowanie jakiegoś procesu, uzgodnienie go z różnymi interesarjuszami, przekazanie ustaleń developerom itd. W takim środowisku umiejętność mapowania procesów i rozrysowania ich w taki sposób, że zarówno dla developerów i biznesu są one zrozumiałem jest w moim odczuciu krytyczną umiejętnością. Często mi się zdarza, że dopiero po rozrysowaniu ludzie maja taki aha moment, że o czymś zapomnieli, czegoś nie przewidzieli o czymś nie pomyśleli i mimo, że im to słownie staram się wyjaśnić to dopiero odpowiedni obrazek/diagram pozwala to zrozumieć.
W mniejszych zespołach też jest to użyteczne np. często mi się zdarza, że po X czasu moje diagramy są jedyną sensowną dokumentacja w projekcie i jak wchodzi nowy developer albo wracamy do jakiegoś zagadnienia po czasie, to są one wyciągane aby "odświeżyć" temat, ale im prostszy/bardziej powtarzalny problem do rozwiązania tym mniej przydatne są techniki modelowania, bo wszyscy "mniej-więcej" wiedzą co robić. Także w takich sytuacjach modelowania używam tylko dla nietypowych procesów albo tych, które maja potencjał na dużo edge-casów, a klient tego nie potrafi zobaczyć bez obrazka (czyli np. taki bardziej rozbudowany FSM).
Korzystam najczęściej z BPMN (prosty do tworzenia, a jeszcze prostszy do czytania - nawet osoba bez znajomości tej notacji potrafi odczytać 80% takiego diagramu), sequence diagram z UML (używałbym nawet częściej niż obecnie, ale jest dość upierdliwy w rysowaniu), proste wireframy, Na spotkaniach używam też często jakichś ad-hoc diagramów bez konkretnej notacji aby łatwiej komunikować się z biznesem.
