개발자와 대화시나 프로젝트에 대해서 이야기할때에 어떤 것이 안된다고 단정하지 말아야 합니다.
오히려 부정적인 것에 매몰되도록 개발자들을 내버려 두어서도 안됩니다.
소프트웨어 개발의 대부분은 문제를 해결하기 보다는...
문제 해결을 위한 행위에서 인간과 소통하거나 타 시스템과 소통하기 위한 오류를 대응하기 위해서 대부분의 일정과 리소스를 소모하게 됩니다.
개발자와 의사소통하고, 개발 속도를 높이려면...
긍정적인 요소와 매우 당연하게 되어야하는 것들에 대해서 먼저 해결하거,
부정적인 인터페이스나 요소, 모델, 에러, 특이한 상태에 대해서는 개발자 책임으로 하지 않고, 기획이나 비즈니스 조직에서 오류가 발생해도 괜찮다는 시그널을 계속 보내야 합니다.
대부분의 새로운 비즈니스 모델들은 긍정적인 요소들만 나열해서 동작하는 실험을 빠르게 해야만, 실 비즈니스의 성립여부를 체크할 수 있습니다.
개발자가 MVP에 집중하고, 비즈니스에 집중하려면... 프로토타입이거나 첫번째 서비스 개발시에 부정적인 부분들에 대해서 신경쓰지 않도록, 긍정적인 부분들만 최대한 도출해서 이야기해야합니다.
에러나 오류, 개발자 실수에 매몰되거나 해당 부분을 문제로 삼는 순간, 개발의 분위기는 부정적인 요소들로 가득차게 되고, 개발자들은 실제 비즈니스 이외의 것들에 매몰되게 됩니다.
개발자와 의사소통시에 긍정적인 부분들을 즐겁게 이야기 나누시고...
실 서비스 개발 이전에 비즈니스의 가능성을 빠르게 타진하는 것이 좋습니다.
그리고 나서, 개발자들이 원하는 환경, 성능, 유지보수등을 고려한 일정을 최소한 2~3단계로 나누어서 받는 것이 맞습니다.
개발자와 의사소통하고,
개발속도를 높히려면.. 긍정적인 부분부터 이야기하시고,
긍정적인 부분부터 만드셔야 합니다.
