😀가장 기대가 되기도 한편으론 걱정이 되기도 했던 한주가 지나갔다!!
실제로 개발자와 디자이너가 협업하여 실제 서비스를 런칭을 시작했고 구글폼으로 사용자들의 여러 피드백을 받았으며
전혀 생각치도 못했던 피드백들을 받았다
피드백중엔 정말 사소한 것들 그리고 당장 고칠 수 있는 부분들부터
아직 어떻게 구현해야할지 감히 안잡히는 여러가지 의견들이 있었다
최대한 의견을 수렴해서 해결할 수 있는 문제들은 당장해결했지만
역시 좀 더 일찍 배포할껄이라는 아쉬움이 남았다.....
덜 다듬어 졌더라도 프로젝트 런칭을 일찍했으면 좋았겠었다라는 생각을 가지게 됐다.
역시 아무리 서로 고객지향적으로 사고한다고 하지만
직접 사용자의 피드백을 수용받고 개선해나가는 것이 진짜 고객지향적인 방법이란걸 깨닫게 됐다
"개발자가 구현하고 싶은 기능"과 "사용자가 진정으로 원하는 기능"은
생각보다 많이 달랐으며 완성작을 배포한다는 마음보다 훨씬 더 빠른시기에 미완성 프로젝트를
배포하고 실행함으로써 얻는 피드백이 정말 더 좋은 방법이란 것을 깨닫는 한주였다 ㅎㅎ
그리고 어떡하면 좀 더 고객지향적인 개발자로써 성장할 수 있을까? 라고 곰곰히 생각해봤고 이터레이션이란 단어를 알게되었다
이터레이션이란
개발 매 단계마다 "잘 되고 있는 건가요?" 라고 실제 고객에게 질문할 수 있는 방법을 제공한다.
이터레이션은 소프트웨어에 대해 자주 점검하는 것과 같아서 항상 어떻게 일이 진행되는지 알 수 있다.
오래된 빅뱅 방식으로 소프트웨어를 개발하면, 프로젝트가 끝날 때까지 어떤 소프트웨어도 준비될 수 없다.
일이 잘못되었다는 것을 깨닫게 되는 최악의 시간.
이터레이션을 하게 되면, 올바른 방향으로 가고 있는지 매 단계마다 확인한다. 이는 소프트웨어가 제대로 개발되고 있는지 거의 매일 확인함을 의미한다. 작은 기능에 대해서라면 코드가 동작하지 않거나 완료될 때까지 오랜 시간이 걸리지 않을 것 이다.
그러고 나면 고객에게 이 작은 기능을 보여주고, 크지는 않겠지만 고객으로부터 '좋다'라는 의견은 충분히 받을 수 있다.
-
한번에 사이트 전부를 만드는 대신에 기능을 작은 부분으로 나눠서 문제를 세분화한다.
-
각 덩어리는 고객에게 나누어서 보여줄 수 있고 피드백을 받을수 있다.
-
고객은 동작하는 소프트웨어를 보고 즉시 중요한 조언을 주고 싶어한다.
Q : 프로젝트 초기에 고객이 원하는 것을 확실하게 알고 있다고 가정해 볼까요? 그래도 여전히 이터레이션이 필요할까요?
A : 당연합니다, 고객의 피드백은 당신이 중요한 모든 것을 알고 있다고 생각할 때 더 중요합니다. 아주 쉽고 단순해 보이는 소프트웨어도 고객과 같이 검토하는 것은 항상 중요합니다. 만약 고객이 잘 진행하고 있다고 말해주고 실제로 모든 요구사항에 맞게 일을 시작했다 하더라도 이터레이션은 여전히 제대로 진행되고 있다는 확신을 줍니다. 그리고 고객의 생각은 항상 변한다는 것을 잊어버리지 마세요.
Q : 프로젝트 기간이 겨우 두 달밖에 안됩니다. 이렇게 짧은 프로젝트에서도 가치가 있을까요?
A : 예, 이터레이션은 아주 짧은 프로젝트에서도 정말 유용합니다. 두 달은 고객의 이상적인 소프트웨어에서 빗나가거나 고객 요구사항에 대한 오해가 생길 수 있는 기회가 60일이나 되는 긴 기간입니다. 이터레이션은 어떤 잠재 문제가 프로젝트에 발생하기 전에 알 수 있게 해줍니다. 더 좋은건 고객 앞에서 바보가 되기 전이라는 거죠.
Q : 중간에 항상 고객이 생각을 바꾸도록 하기 보다는 정말 고객이 원하는 것을 파악하는데 시간을더 사용해서 요구사항을 정말 확실하게 받는 것이 낫지 않을까요?
A : 그렇게 생각할 수 있습니다만 이는 재앙으로 가는 방법입니다. 오래 전 나쁜 시기에 개발자들은 프로젝트 초기에 한 줄의 코드나 설계 결정을 내리지 않고 모든 고객의 요구사항에 대해 확실히 하기 위해 몇 년씩 허비하고는 했습니다. 불행히 이런 접근은 실패했습니다. 만약 초기에 고객이 필요로 하는 것을 완벽히 이해했다 하더라도 고객도 가끔 이해를 못하기도 합니다. 그래서 고객도 당신만큼이나 이해하고 싶어합니다. 개발할 소프트웨어에 대한 팀과 고객의 이해를 높일 수 있는 방법이 필요한데 빅뱅이나 모든 사항이 매일 돌처럼 굳어지기를 바라는 초반에 요구사항을 받는 방법으로는 이렇게 할 수 없습니다.
Q : 누가 이터레이션에 참여해야 하나요?
A : 소프트웨어가 요구사항에 맞아야 한다고 이야기하거나 이 요구사항 미팅과 관련 있는 모든 사람입니다. 최소한으로 한정한다면 보통 고객, 당신, 이 프로젝트에서 일하는 다른 개발자입니다.
Q : 팀에 저 혼자 뿐인데 그래도 여전히 이터레이션은 필요한가요?
A : 좋은 질문입니다. 그리고 대답은 예입니다. (여기서 다루는 주제를 눈치채기 시작했나요?) 개발팀이 당신 한 명이라 하더라도 소프트웨어를 성공적으로 개발하기 위해서는 프로젝트에 최소한 두 명이 있어야 합니다. 즉, 고객과 당신!
소프트웨어가 제대로 개발되고 있는지 확인하고 싶을 때 여전히 두 가지 관점에서 이해해야 하며 이터레이션은 여전히 최소한의 팀에서도 도움이 됩니다.
Q : 프로젝트에서 얼마나 일찍 이터레이션을 시작해야 하나요?
A : 고객과 토론할 수 있는 실행 가능한 소프트웨어를 가질 수 있을 만큼 빨리 하면 됩니다. 보통 작업일수로 20일 정도를 추천합니다. 달력 기준으로 한 달에 이터레이션 한 번 정도지만 확실히 더 빨리 할 수도 있습니다. 한 주나 두 주 이터레이션을 거의 들어보지 못했습니다. 만약 2일째 되는 날부터 고객이 원하는 것을 확신하지 못하겠으면 고객을 부르세요. 잘 진행되고 있는지에 대해 알아보기 위해 기다릴 이유는 없지 않을까요?
Q : 고객이 나쁜 소식을 갖고 와서 지금 개발중인 게 잘못됐다고 이야기합니다. 어떻게 해야 하나요?
A : 좋은 질문입니다. 잘못이 일어나면 이터레이션 동안에 잘못되었다는 것을 알게 되고 다음 이터레이션 과정에서 되돌아 볼 필요가 있습니다.
이터레이션 관련글 출처:https://m.blog.naver.com/PostView.naver?blogId=guh98&logNo=110144626992&proxyReferer=https:%2F%2Fwww.google.com%2F
애자일 방법론!
http://www.incodom.kr/%EC%95%A0%EC%9E%90%EC%9D%BC_%EB%B0%A9%EB%B2%95%EB%A1%A0
