Four different approaches to project management with pros and cons.

1. PROJECT MANAGEMENT
제품, 서비스, 기술개발의 방법들 중
Waterfall
Iterative Design
Agile Development
Lean Startup
MICHAEL SHILMAN
michael@shilman.net
KEYWON CHUNG
keywonc@gmail.com
이렇게 네가지 방법을 소개합니다.
1

2. OUR BACKGROUND
Academic Research
Iterative Product Development
Human-Centered Design
Agile & Lean Startup
Michael Keywon
UC Microsoft Startup MIT IDEO Microsoft
Berkeley Research Media Lab Office
우리 두사람은 디자인, 컴퓨터 공학연구, 아트, 소프트웨어와 하드웨어 개발, We have very different backgrounds in design, academic and corporate
그리고 벤처투자를 받는 스타트업을 비롯 다양한 경험을 쌓아왔습니다. research, interactive media, and venture-backed startups.
몇년간 다른 방식으로 일하다 함께 동업자로 시작하려 하니, 함께 효과적으로 After working separately for years, we're starting a new project together
일하는 방법이 참 고민이 됩니다. 우리가 경험해본 세가지 방식에 대해서 소개 and one of the most difficult parts has been figuring out how to work
해드리고 장단점을 논의해보도록 하겠습니다.
together most effectively. 2

3. SILICON VALLEY BERKELEY
SAN FRANCISCO
US Innovation Hub
#1 in Venture Investments ($5.9B 2010)
#1 in Patents (10K+ Patents Registered 2009)
Massive regional GDP ($150B 2010)
PALO ALTO
Mature MOUNTAIN VIEW
STANFORD
40+ years since HP, Fairchild in 1950’s
샌프란시스코에서 산호세까지를 잇는 실리콘밸리 지역은
1960년대부터 미국의 기술, 제품, 서비스 혁신을 주도한
지역입니다.
SAN JOSE
3

4. SILICON VALLEY: PRODUCTS
4

5. SILICON VALLEY: PROCESS
Also produces:
Tools
Techniques
Methodology
How to Build It
What to Build
실리콘 밸리는 제품개발 자체 뿐 아니라 개발 방법론과
담론에 대한 새로운 시도와 혁신을 주도하고 있습니다.
5

6. BY ‘PROJECT MANAGEMENT’ WE MEAN:
프로젝트관리 = 세상을 바꿔나가는 제품, 서비스 및 기술을 개발하는 방법
Ways to develop products,
services, and technologies that
change the world.
즉 오늘의 강의에서 프로젝트 방법론이라 함은, 세상에 크
고작은 변화를 가져오는 제품, 서비스 및 기술을 개발하는
방법을 뜻하는 것으로 전제합니다.
6

7. PROJECT MANAGEMENT
특정 목표를 이루기 위한 물적/인적 자원의 활용... 이라는 기계적인 관점이 아니라,
Wikipedia: “planning, organizing, securing, and
managing resources to achieve specific goals”
This is the wrong way to think about it.
7
http://en.wikipedia.org/wiki/Project_management

8. PROJECT MANAGEMENT
다른 사람들과 함께 머릿속의 이상과 목표를 이루어나간다는 인간적인 관점에서 봅시다.
From
A desire you
have: A problem
to solve, an idea
to realize
To
Widely used and
accepted solution
This is a better way to
think about it.
8

9. WHY METHODOLOGY?
개발하고 디자인하기도 바빠 죽겠는데 웬 방법론?
창문닦는법 1
창문닦는법 2
Why should we talk about different
ways of doing things?
9
창문닦는법 3

10. PERSONAL DESIRES DRIVE
CHANGE AND INNOVATION.
We want to turn the desires into reality.
개인의 갈망과 불만으로부터 세상의 모든 변화와 혁 Peter Jackson is touted as the mastermind, a
신이 시작됩니다. visionary who turned the “unfilmmable” LOTR
trilogy into Oscar-winning films.
Peter Jackson
10

11. TO CREATE A NEW REALITY,
WE WORK IN A GROUP.
Even “geniuses” don’t work alone.
그리고 이런 개개인의 욕망을 현실에 반영하기 위해 To turn the desires into reality, we work with
서, 우린 다른 사람들과 함께 일하게 됩니다. 혼자 others.
모든일을 다 할수 없다는 것이 첫번째 이유이죠. Peter Jackson did not work alone. In fact, he
피터잭슨이 대단한 감독이지만 혼자 반지제왕을 만 created and executed a vision with thousands
들지는 않은것과 마찬가지입니다. 웨타 워크샵, 디 of people. Steve Jobs, and Edison are all
지털, 배우들, 기술자들, 단역들, 무려 수천명의 힘 master teamworkers in disguise.
이 모여서 그 비전이 완성된 것이죠.
Weta Workshop (2000) Peter Jackson
11

12. BUT THE REAL REASON
WE WORK IN A GROUP IS...
We want to create something valuable to others.
VALUE
하지만 진짜 중요한 이유는, 나 한사람만 이해하고
좋아하는 것을 만들고 싶지 않기 때문입니다.
But the real reason is because you don’t just
want to create something that only you need
RISK
and understand.
다른사람들에게도 가치있는 것을 만들어내기 위해
서는 나혼자 일하는것이 아니라 여러 사람( )의 In order to create something valued by others,
능력과 의견을 활용하여 리스크는 낮추고, 가치는 you need to employ multiple talents and
높이는 과정이 필요합니다. 결국 다양한 갈망을 가 perspectives ( ) to lower risks and increase
진 개인들이 모여서 일하게 되죠. the proposed value.
IDEO Crit
12

13. THAT’S WHY WE NEED...
Point of View
자신의 관점을 알기 + 남의 관점을 이해하기
Methodology
자신의 방법론을 자각하기 + 남의 방법론에 관심을 갖기
Communication Experimentation
설명하기 + 설득하기 + 종합하기 배우기 + 시도하기 + 기록하기 + 진보하기
이 전제에 동의하지 않으신다면, 안녕히 가세요.
If you disagree with this premise, please leave the room now.
13

14. FOUR APPROACHES
오늘 소개할 네가지 방법들입니다.
Waterfall Iterative Agile Lean
Skyscraper Playground Lego House Flower Arrangement
전체적 설계 후 일괄적으 여러번의 프로토타이핑을 통해 조각조각 나누어 디자인하고 최소한의 중심부부터 만든 후
로 짓기 사용자 중심의 디자인을 정한후 개발하기 점진적으로 채워나가기
개발에 들어가기
14

15. WATERFALL
전체적 설계 후 한번에 개발, 완성하기
You should design
before you build it
all at once.
15

16. WATERFALL PROCESS
디자인하고 나서 한번에 개발, 완성하기
Requirements
What to build
Design
Implementation
Verification How to build it
Maintenance 16

17. WATERFALL PRODUCTS
크고 복잡한 시스템 제작, 인력과 자원을 정량적으로 배열
IBM 360 (1964)
SAGE aircraft monitoring system (1983)
The Mythical Man-Month (1975)
Matrix Organizations
17

18. REQUIREMENTS
필요한 기능과 전체구조, 유지 및 보수에 관한 정보 수집 및 정리
Brainstorming Specification Document
http://en.wikipedia.org/wiki/Software_testing

19. DESIGN
인터페이스 구성, 주요기능 시나리오와 전후과정, 코드 구조 가시화
Sketches & Wireframes Usage Flows Architectural Design
http://en.wikipedia.org/wiki/Software_testing

20. IMPLEMENTATION
코드와 인터페이스 및 콘텐츠 제작, 중앙서버에 올리기
Coding, creating UI and content assets, add new assets to tracking system

21. IMPLEMENTATION
예산과 기간설정, 주요 이정표, 우선순위 선정 Gantt Chart
Scheduling, Milestones, Priority, Triage

22. VERIFICATION
작은 코드단위부터 전체적 흐름까지, 기능, 사용성, 견고성 등을 시험
Unit / Regression Test Functional Test User Test
Performance Test Load Test Alpha / Beta

23. MAINTENANCE
버그 수집, 수정, 수정본 및 업데이트 배포
Bug Tracking Deployment

24. WATERFALL EXERCISE
Reverse-engineer Kickstarter.
24

25. WHAT’S WRONG WITH THIS APPROACH?
25

26. UNUSABLE PRODUCTS
개발자가 자의적으로 디자인하면 사용자와 경영진이 고생이죠.
“Despite appearances, business executives
are simply not the ones in control of the high-
tech industry. They have inadvertently put
programmers and engineers in charge,
leading to products and processes that waste
huge amounts of money, squander customer
“Deep down inside every software developer, there's a budding graphic designer waiting to get out. And if loyalty, and erode competitive advantage.
you let that happen, you're in trouble. Or at least your users will be, anyway” They have let the inmates run the asylum.”
26

27. CANNOT MANAGE RISKS
진행중엔 상황 파악이 힘들고, 막판에 시간이 모자르고, 도중에 개선하기가 불가능해집니다.
Not realistic to do a full design up front
Hard to adjust your design mid-stream
Hard to estimate your schedule, slippage
Hard to wrap up at the end
27

28. ITERATIVE
사용자 중심으로 디자인하고 나서 한번에 개발, 완성하기
You should design
user-centered
before you build it
all at once.
28

29. ITERATIVE PROCESS
초기 디자인 과정에 투자 후 폭포수 방식으로 개발
Requirements
What to build
Design
Implementation
Verification How to build it
Maintenance 29

30. ITERATIVE PRODUCTS
박스형 소프트웨어나 게임 및 플랫폼들
1983
1993
Microsoft Windows, Office
Adobe Photoshop
Norton Antivirus
Nintendo Wii
1996

31. Cooper personas
REQUIREMENTS
사용자의 환경과 필요에 관한 조사 및 모델링이 우선시됨
User Research Modeling, Personas
Observation & interview
Cultural model
POEMS user research

32. DESIGN
반복적인 디자인, 프로토타이핑, 평가, 보고, 수정작업을 거침
Prototypes, mockups Expert and user feedback

33. ITERATIVE DESIGN EXERCISE
What information do you need to design Kickstarter?
33

34. WHAT’S WRONG WITH THIS APPROACH?
34

35. BROKEN!
개발과정의 애로사항은 여전: 복잡함 증가, 유연성은 부족
Requirements
What to build
Design
Implementation
Verification How to build it
Maintenance 35

36. STILL, CANNOT MANAGE RISKS
실제 사용자에게 평가받을때까지 길게는 5-6년이 걸리기도 합니다.
Not realistic to do a full design up front
Hard to adjust your design mid-stream
Hard to estimate your schedule, slippage
Hard to wrap up at the end
Takes too long before real-world validation.
36

37. NEW ERA: INTERNET!
그런데 여기서 극적인 환경의 변화가 생겼으니...
37

38. CONTINUAL ITERATION
인터넷을 통해 끝없이 제품을 업데이트하고 개선하는 새로운 시대 도래!
1999 2011
38

39. NEVER-ENDING CYCLE
이전에는 제품을 출시하면 끝
이었는데, 이제는 출시 후에
도 계속하여 반복적으로 개선
Requirements 을 하게 되었습니다.
What to build Now you are not done after shipping
the product. You can release new
Design version of your product as many
times a day or a week as you like. No
one waits for another 5 years for a
new version anymore.
Implementation
Verification How to build it
Maintenance
39

40. AGILE
조각조각 디자인하고 개발하여 합체하기
You can design
while you build it
incrementally.
40

41. AGILE DEVELOPMENT, e.g. “SCRUM”
How can we make development more “real”?
“Fiction” “Reality”
기존의 폭포수 방식에서는 80프로 이
상의 과정동안 실제 제품의 윤곽을 볼
수가 없었습니다. 막판에 가서야
Build (개발중인 제품의 임시버전들)
를 볼 수 있고, 작동이 안되고 버그가
충만한 경우가 대부분입니다. 모자른
컨텐츠를 그때 가서야 비상이 걸려서
채워나가게 됩니다.
애자일 방법론은 개발과정 전체에 걸
쳐서 그순간의 제품 상태를 정확히 알
고 있어야 한다는 위기감에 기반하고
있습니다.
41

42. SHORTEN CYCLE TIME
Confront reality more often Break development into chunks
Finish chunks completely
Don’t need to release, but you can
Fiction Reality
...
1-4 weeks
Shipping Shipping Shipping Shipping
software software software software
제품을 한번에 개발하지 않고, 몇주마다 이렇게 되면 우리제품이 현실적으로 기능하고
특정 부분을 추가 개발, 평가하여 출시/ 사용가능한가, 시험하고 현상황을 언제나 정
저장합니다. 몇주마다 조금씩 추가 개선 확히 파악할 수 있습니다. 42
된 완제품이 만들어지는 것입니다.

43. SCRUM STANDING MEETING
For 15 minutes every 24 hours:
What I did yesterday
What am I going to do today
What’s blocking me
하루에 한번, 15분동안 팀이 모여서 이
세가지만 공유해도 큰 도움이 됩니다.
43

44. SCRUM PROCESS
44

45. SCRUM BOARD
45

46. ESTIMATION: PLANNING POKER
4

47. BURNDOWN
47

48. SCRUM EXERCISE
Break up Kickstarter into iterations
48

49. WHAT’S WRONG WITH THIS APPROACH?
49

50. WHAT TO BUILD AND WHY?
How does iterative design fit with this?
Is our product actually desirable?
Is our product actually usable?
Are we meeting our business goals?
50

51. LEAN
중심부터 먼저 세우고 주변을 계속하여 채워나가기
You should
design and measure
while you build it
incrementally.
51

52. LEAN PROCESS
계속하여 제품의 이용도를 측정하고 개선하기
Requirements
What to build
Design
Implementation
Verification How to build it
Measurement 52

53. HOW DO YOU MANAGE PERFORMANCE?
측정하지 않는것을 관리할수는 없어요!
You can’t
manage what
you don’t
measure.
53

54. LEAN PHILOSOPHY
Learning is a product
Test every assumption
Measure on real users
MEASURE! MEASURE! MEASURE! MEASURE!
...
1 week
Release Release Release Release
software software software software
54

55. LEAN PHILOSOPHY
Learn as quickly as possible
Build only what you need
Iterate early and often
Build
Learn Measure

56. EVERY INTERACTION IS A FUNNEL
모든 인터랙션을 깔때기 구조로 생각해보세요.
You can lead users to behave a certain way by
redesigning and optimizing funnels.
Arrive at Service
Sign up with the Service
Create Profile
56

57. WHAT TO MEASURE
4
h"p://500hats.typepad.com/2

58. HOW TO MEASURE
Concept Features Optimization
Conversations Frequent releases A/B split testing
Sketches High-level metrics
Prototypes
58

59. LEAN EXERCISE
Design Kickstarter experiments.
59

60. WHAT’S WRONG WITH THIS APPROACH?
60

61. WHAT’S WRONG WITH THIS APPROACH?
Experiments can be heavyweight
Doesn’t help us synthesize
Can stifle creativity, lead to local optimization
Metrics only offer one type of insight
61

62. FOUR APPROACHES
오늘 소개한 네가지 방법들입니다.
Waterfall Iterative Agile Lean
Skyscraper Playground Lego House Flower Arrangement
전체적 설계 후 일괄적으 여러번의 프로토타이핑을 통해 조각조각 나누어 디자인하고 최소한의 중심부부터 만든 후
로 짓기 사용자 중심의 디자인을 정한후 개발하기 점진적으로 채워나가기
개발에 들어가기
You should You should You can You should
design design user- design design &
before you centered while you measure
build it before you build it while you
all at once. build it incrementally. build it
all at once. incrementally.

63. PROJECT MANAGEMENT IS IMPORTANT.
Using the right approach leads to: 프로젝트 방법론을 잘 사용하면 큰 효과의 차이를 볼 수 있습니다.
Creativity / insight Structure / constraints
Experimentation Speed / predictability
But no approach is perfect, so: 하지만 자신만의 방법을 찾는것이 중요합니다.
Mix it up and experiment to find your own flavor.
Iterate and iterate until successful.
Measure and understand user behaviors,
and influence them with every redesign.
63

64. BUT MORE IMPORTANT IS...
What you’re building
Love your product.
Keep your raw skills sharp.
64

65. BUT MORE IMPORTANT IS...
Who you’re building it for
Know your users.
Know your domain.
65

66. BUT MORE IMPORTANT IS...
Who you’re building it with
Bond with your team.
Have a lot of fun together.
66

67. Q&A
THE END