(애자일) 팀원들과 플로우 차트 함께 그려보기

배경

이전 회사에서 프로젝트를 시작할 때, 디자이너 + PO + 클라이언트 개발자 + 서버 개발자들이 같이 모여서 화이트 보드에 플로우를 그려본적이 있다. 

다 같이 플로우를 그리고 논의하는 미팅은 시간이 오래 소요된다. 당시에 한 제품에 대한 플로우를 그리는 데에 몇시간씩 여러번의 회의를 했었다. 그럼에도 의미가 있는 시간이었다. 

와이어프레임, UI, 유저스토리 등.. 제품 분석/설계가 확정지어지지 않은 상황에서 이 방법을 사용하면 유용했다. 

 

장점 

1. 팀원들이 같은 제품을 생각하는 데에 도움이 된다.

팀원들이 기능을 서로 다르게 생각할 수 있다. 그런데 플로우를 그려나가면서, 각자가 상상한 것들을 이야기하면서 점점 싱크가 맞아진다. 

   

2. 예외 케이스들을 사전에 빠르게 파악할 수 있다.

집단 지성의 힘 같은거다. 플로우를 그리면서 서로 알고있는 의견들을 공유하면서, 리스크들을 사전에 파악하는데 도움이 된다. 

3. 커뮤니케이션 비용이 줄어든다. 

만약 누군가 혼자서 이걸 그린다면, 이게 맞는지 고민하고, 물어보고, 리뷰하는 데에 시간이 걸릴거다.  

다 같이 모여서 이야기하고 결정하고, 고민을 공유하면 의사결정이 빨라진다. 

4. 과제를 구체화할 수 있다. 

방법

1. 제품을 같이 만들어야하는 팀원들을 모은다. 

2. 플로우를 그려야하는 기능들을 잘게 쪼개서, 플로우를 그려나간다. 

    네모 박스 ( 화면 or 유저 스토리 or ETC ) + 다이어몬드 ( 선택지 ) + 화살표 ( 다음 방향성 )

    이렇게 세가지만 가져다가 쓰면 된다. 

    이전 회사에서는 네모 박스는 하나의 UI 화면을 의미했었고, 여기서 보여져야 하는 정보들을 네모 박스 옆에 적어뒀었다. 

    ( 이렇게 하면 디자이너는 그대로 이 정보들을 화면에 보여주면 되고, 개발자들은 이 정보를 바탕으로 DB 설계를 하면 된다. ) 

3. 1개의 유저 플로우를 그리는 게 끝나면, 사진으로 찍어둔다. 그리고 다음 플로우를 그린다. 

4. 찍어둔 플로우 차트 사진은 위키에 올려둔다. 

   이 과정의 목적은 "플로우 차트" 자체가 아니다. 

   팀원들이 생각하는 것을 도와주고, 이슈 사항을 논의하고, 결정하는게 이 과정의 목적이다. 

참고 

Agile Modeling - Flow Charts: An Agile Introduction