235개 이상의 프로젝트를 거치며 깨달은 점은, 고통스러운 협업을 예측하는 신호들은 기술 요구사항 (Technical requirements)에 거의 나타나지 않는다는 것입니다. 그 신호들은 단 한 줄의 범위 (Scope)가 작성되기도 전, 첫 대화에서 나타납니다.

"보면 알 것 같아요"라는 말은 취향의 문제가 아니라 예산의 문제입니다. 클라이언트가 이 문구 외에 자신이 원하는 것을 명확히 설명하지 못한다면, 이는 대개 사이트가 무엇을 해야 하는지 실제로 결정하지 못했다는 것을 의미합니다. 즉, "최종" 디자인이 모든 단계에서 계속 재논의될 것이라는 뜻입니다. 이제 저희는 범위 산정 (Scoping)을 시작하기 전에 최소 두 개의 레퍼런스 사이트와 한 문장으로 된 목표를 요구합니다. 클라이언트가 이 중 어느 것도 제시하지 못한다면, 그것이 바로 디자인 브리프 (Design brief)가 아닌 진짜 신호입니다.

모든 가격에 대한 빠른 "네"는 승리가 아니라 경고입니다. 질문 하나 없이 견적에 즉각 동의하는 클라이언트는 종종 예산을 제대로 책정하지 않았을 가능성이 높으며, 프로젝트 중간에 가격을 올리는 대신 범위를 줄이려는 협상을 시작할 것입니다. 무엇이 포함되어 있는지에 대해 까다로운 질문을 던지는 클라이언트가 나중에 함께 일하기 가장 쉬운 경향이 있습니다. 그들은 자신이 무엇을 구매하는지에 대해 실제로 고민했기 때문입니다.

"제 이전 개발자는 사라졌어요"라는 말은 개발자의 문제인 경우가 드뭅니다. 물론 그런 일도 일어납니다. 하지만 동일한 클라이언트가 여러 명의 이전 개발자에 대해 이 문구를 반복해서 말한다면, 그 패턴은 보통 다른 곳을 가리킵니다. 불분명한 범위 (Scope), 끊임없이 변하는 요구사항, 또는 언급되지 않은 미지급 송장 (Unpaid invoices) 같은 것들 말이죠. 단 한 번의 사례는 타인의 문제일 수 있지만, 패턴은 정보입니다.

이유 없는 긴급함은 범위 확장 (Scope creep)의 예측 지표입니다. 아무런 설명 없이(이벤트, 출시, 혹은 그들 측의 마감 기한 등) "금요일까지 라이브해야 해요"라고 말하는 것은 대개 그 긴급함이 운영상의 이유가 아닌 감정적인 이유임을 의미합니다. 그리고 감정적인 긴급함은 마감 기한이 지났다고 해서 사라지지 않습니다. 그저 다음 요청으로 옮겨갈 뿐입니다.

좋은 프로젝트를 예측할 수 있는 가장 좋은 지표는 자신의 아이디어에 대해 '아니오'라고 말할 수 있는 클라이언트입니다. 어떤 기능을 제안했다가도 "사실, 그건 건너뛰죠. 비용을 들일 가치가 없네요"라고 말하는 사람은 트레이드오프 (tradeoffs)를 이해하고 있는 클라이언트입니다. 이는 그들이 프로젝트 시작 단계뿐만 아니라, 나중에 압박을 받는 상황에서도 올바른 결정을 내릴 것임을 의미합니다.

이 중 어떤 것도 프로젝트 관리 (project management) 과정에는 포함되어 있지 않습니다. 하지만 소규모 비즈니스 웹 작업을 충분히 오래 하다 보면, 레드 플래그 (red flags)를 찾기 위해 명세서 (specs)를 읽는 대신 클라이언트를 읽기 시작하게 됩니다.