흔한 개발자가 짱나는 경우

1. 스펙에 요구사항을 애매하게 써놓음

여기서 선택을 해야됨

2-1. 애매한거를 확실히 하기 위해 대화를 시도해서 모든 엣지케이스를 완벽하게 잡는다.

2-2. 대화하기 귀찮아서 그냥 써놓은 고대로~ 만 구현한다.

2-3. 대화하기 귀찮아서 내 임의로 부족한 엣지케이스에 대한 경우에 이렇게 처리한다고 단정후 작업 이어서함

2-1. 대화를 한다

장점: 대화가 빨리 끝나고 요구사항 확립이 빨리되면 가장 이상적임.

단점: 하지만 현실의 대부분이 짧게는 하루. 길게는 몇일. 심지어 까먹기도 해서. 스프린트 후반에 야근 이나 주말근무로 빡세게 일해야댐.

2-2. 써놓은 고대로~ 만든다.

장점: 대화가 필요없으니 빠르게 구현가능. 고로 야근 안함

단점: PM의 남탄 시전. 왜 이렇게 만들었냐? 난 써놓은 그대로 만든거다. 유연하게 니가 알아서 만들거나(2-3) 나한테 물어봤어야 되는거 아니냐(2-1) 시전. 무한반복. 당연히 일정은 늦춰짐.

2-3. 모자른 케이스는 내 맘대로 만든다

장점: 대화가 필요없으니 빠르게 구현가능. 고로 야근 안함. 단 내가 요구사항을 내 짱구 굴려서 만드니 골이 좀 더 아픔.

단점: 모 아니면 도. 테스팅 돌려서 PM이 맘에 들면 모. 이거 누가 이렇게 만들었냐고 싸우면 빽도. 현실은 대부분 빽도. 뺵도 걸리면 일정은 늦춰짐.

결론은 싸우거나 내가 야근 하거나 인데

쪼렙때는 대화를 했지만 지금은 당연히 싸우는걸 택함

오늘도 싸우다가 빡쳐서 글 하나 남기네요

전 CTO가 그립네요. 왠만하면 모든 엣지케이스가 스펙에 적혀있는 유일했던 사람