소프트웨어의 숨은 변경 비용과 끝없는 선택지가 조직을 과열시킨다는 주장

팬데믹 뒤로 화장실이나 식사 전뿐 아니라 공용 표면을 만진 뒤에도 손을 자주 씻는데, 그 뒤로는 거의 아프지 않더라. 30분마다 씻는 건 아니어도 손 씻기 자체를 강박 사례로 들긴 애매함.

Cochrane의 호흡기 바이러스 전파 차단 물리적 개입 검토는 마스크에서는 유의미한 효과를 못 찾았지만, 손 씻기에서는 유의미한 효과를 찾았음.

나도 팬데믹 때부터 사무실 건물로 돌아오면 손을 씻고, 화장실에서 사무실까지 문손잡이는 수건으로 잡음. 병에 덜 걸리는 느낌이 있음.

사람이 손댄 문손잡이를 피하는 건 과한 반응이 아님. 지금은 인류 역사상 병원체가 가장 적은 시대이기도 하고.

개발자가 고객과 떨어져 있을 때 글에서 말한 폭주가 심해짐. 고객을 정기적으로 만나면 현실 감각이 생기는데, 프로젝트 매니저가 쪽지만 전달하는 구조는 그걸 없앰.

고객과 일하는 게 재밌음. 지루한 산업에도 아직 수작업으로 하거나 형편없는 소프트웨어로 하는 일이 엄청 많지만, 직접 보러 가려는 사람은 드물더라.

개발자와 프로젝트 매니저 모두 1차 헬프데스크를 정기적으로 해봐야 함. 사용자 문제를 직접 받으면 백로그 문장만 보고 일할 때와 판단이 달라짐.

분석 지표에 과하게 기대는 것도 현실과 거리를 만듦. 관리자가 사용자 연구 대신 지표를 자기 편견에 맞춰 읽으면, 숫자만 보고 방향을 정하게 됨.

사용자가 실제로 소프트웨어로 뭘 하려는지 보여주면 불확실성이 크게 줄어듦. 사용자는 대개 목표까지의 마찰을 줄이는 작은 변경과, 동작을 믿을 수 있는 상태를 원함.

개발자와 사용자가 직접 대화하면 사용자도 버그와 요구를 더 잘 설명하게 됨. 고객 요구가 프로젝트 매니저 언어와 백로그 항목으로 여러 번 번역되면 정보가 빠짐.

반대로 개발자 본인이 사용자 대응을 싫어해서 분리를 요구하는 경우도 많음. 사용자와 이야기하는 일을 '진짜 일'을 방해하는 일로 보는 개발자를 여럿 봤음.

사용자를 직접 만나 프로토타입을 쓰게 해보면, 원한다고 하던 기능도 실제로는 필요 없다는 걸 금방 알게 됨. 안 쓸 기능을 몇 달 동안 만들 일을 피했음.

B2B에서는 사용자와 대화할수록 각자 특수한 업무 관행에 맞춘 기능이나 낡은 방화벽용 보안 완화를 요구할 때가 있음. 품질 기준을 모르는 사용자 요구를 그대로 받는 것도 문제임.

이해관계자에게 새 기능 아이디어를 물으면 대체로 좋다고 함. 그런데 본인이 쓸지, 어떻게 도움이 될지를 물으면 대답이 없어지는 경우가 많더라.

기술 리더가 어떤 도메인의 한 부분을 추상화해 시장 보상을 받으면, 도메인 전체를 정복했다고 착각하는 걸 봄. 일정 관리 앱을 만들고 상업용 부동산이나 사회의 미래를 바꿨다고 여기는 식임.