Your SlideShare is downloading. ×

Project Management


Published on

Four different approaches to project management with pros and cons.

Four different approaches to project management with pros and cons.

Published in: Technology, Business

1 Comment
1 Like
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. PROJECT MANAGEMENT제품, 서비스, 기술개발의 방법들 중WaterfallIterative DesignAgile DevelopmentLean Startup MICHAEL SHILMAN KEYWON CHUNG keywonc@gmail.com이렇게 네가지 방법을 소개합니다. 1
  • 2. OUR BACKGROUND Academic Research Iterative Product Development Human-Centered Design Agile & Lean StartupMichael 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, were 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 FRANCISCOUS Innovation Hub #1 in Venture Investments ($5.9B 2010) #1 in Patents (10K+ Patents Registered 2009) Massive regional GDP ($150B 2010) PALO ALTOMature MOUNTAIN VIEW STANFORD 40+ years since HP, Fairchild in 1950’s샌프란시스코에서 산호세까지를 잇는 실리콘밸리 지역은1960년대부터 미국의 기술, 제품, 서비스 혁신을 주도한지역입니다. SAN JOSE 3
  • 5. SILICON VALLEY: PROCESSAlso 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, andmanaging resources to achieve specific goals”This is the wrong way to think about it. 7
  • 8. PROJECT MANAGEMENT다른 사람들과 함께 머릿속의 이상과 목표를 이루어나간다는 인간적인 관점에서 봅시다.From A desire you have: A problem to solve, an idea to realize To Widely used and accepted solutionThis is a better way tothink about it. 8
  • 9. WHY METHODOLOGY?개발하고 디자인하기도 바빠 죽겠는데 웬 방법론? 창문닦는법 1 창문닦는법 2Why should we talk about differentways of doing things? 9 창문닦는법 3
  • 10. PERSONAL DESIRES DRIVECHANGE 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 REASONWE 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 LeanSkyscraper 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
  • 19. DESIGN인터페이스 구성, 주요기능 시나리오와 전후과정, 코드 구조 가시화Sketches & Wireframes Usage Flows Architectural Design
  • 20. IMPLEMENTATION코드와 인터페이스 및 콘텐츠 제작, 중앙서버에 올리기Coding, creating UI and content assets, add new assets to tracking system
  • 21. IMPLEMENTATION예산과 기간설정, 주요 이정표, 우선순위 선정 Gantt ChartScheduling, Milestones, Priority, Triage
  • 22. VERIFICATION작은 코드단위부터 전체적 흐름까지, 기능, 사용성, 견고성 등을 시험Unit / Regression Test Functional Test User TestPerformance Test Load Test Alpha / Beta
  • 23. MAINTENANCE버그 수집, 수정, 수정본 및 업데이트 배포Bug Tracking Deployment
  • 24. WATERFALL EXERCISEReverse-engineer Kickstarter. 24
  • 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, theres a budding graphic designer waiting to get out. And if loyalty, and erode competitive let that happen, youre 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 frontHard to adjust your design mid-streamHard to estimate your schedule, slippageHard 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 DesignImplementation Verification How to build it Maintenance 29
  • 30. ITERATIVE PRODUCTS 박스형 소프트웨어나 게임 및 플랫폼들 1983 1993Microsoft Windows, OfficeAdobe PhotoshopNorton AntivirusNintendo Wii 1996
  • 31. Cooper personas REQUIREMENTS 사용자의 환경과 필요에 관한 조사 및 모델링이 우선시됨 User Research Modeling, PersonasObservation & interview Cultural model POEMS user research
  • 32. DESIGN반복적인 디자인, 프로토타이핑, 평가, 보고, 수정작업을 거침Prototypes, mockups Expert and user feedback
  • 33. ITERATIVE DESIGN EXERCISEWhat information do you need to design Kickstarter? 33
  • 35. BROKEN!개발과정의 애로사항은 여전: 복잡함 증가, 유연성은 부족 Requirements What to build DesignImplementation Verification How to build it Maintenance 35
  • 36. STILL, CANNOT MANAGE RISKS실제 사용자에게 평가받을때까지 길게는 5-6년이 걸리기도 합니다.Not realistic to do a full design up frontHard to adjust your design mid-streamHard to estimate your schedule, slippageHard to wrap up at the endTakes 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 TIMEConfront reality more often Break development into chunks Finish chunks completely Don’t need to release, but you canFiction Reality ... 1-4 weeks Shipping Shipping Shipping Shipping software software software software 제품을 한번에 개발하지 않고, 몇주마다 이렇게 되면 우리제품이 현실적으로 기능하고 특정 부분을 추가 개발, 평가하여 출시/ 사용가능한가, 시험하고 현상황을 언제나 정 저장합니다. 몇주마다 조금씩 추가 개선 확히 파악할 수 있습니다. 42 된 완제품이 만들어지는 것입니다.
  • 43. SCRUM STANDING MEETINGFor 15 minutes every 24 hours:What I did yesterdayWhat am I going to do todayWhat’s blocking me하루에 한번, 15분동안 팀이 모여서 이세가지만 공유해도 큰 도움이 됩니다. 43
  • 44. SCRUM PROCESS 44
  • 45. SCRUM BOARD 45
  • 47. BURNDOWN 47
  • 48. SCRUM EXERCISEBreak up Kickstarter into iterations 48
  • 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 DesignImplementation 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 PHILOSOPHYLearning is a productTest every assumptionMeasure on real users MEASURE! MEASURE! MEASURE! MEASURE! ... 1 week Release Release Release Release software software software software 54
  • 55. LEAN PHILOSOPHYLearn as quickly as possibleBuild only what you needIterate early and often Build Learn Measure
  • 56. EVERY INTERACTION IS A FUNNEL모든 인터랙션을 깔때기 구조로 생각해보세요.You can lead users to behave a certain way byredesigning and optimizing funnels. Arrive at Service Sign up with the Service Create Profile 56
  • 57. WHAT TO MEASURE 4 h"p://
  • 58. HOW TO MEASURE Concept Features OptimizationConversations Frequent releases A/B split testingSketches High-level metricsPrototypes 58
  • 59. LEAN EXERCISEDesign Kickstarter experiments. 59
  • 61. WHAT’S WRONG WITH THIS APPROACH?Experiments can be heavyweightDoesn’t help us synthesizeCan stifle creativity, lead to local optimizationMetrics only offer one type of insight 61
  • 62. FOUR APPROACHES 오늘 소개한 네가지 방법들입니다.Waterfall Iterative Agile LeanSkyscraper Playground Lego House Flower Arrangement전체적 설계 후 일괄적으 여러번의 프로토타이핑을 통해 조각조각 나누어 디자인하고 최소한의 중심부부터 만든 후로 짓기 사용자 중심의 디자인을 정한후 개발하기 점진적으로 채워나가기 개발에 들어가기You should You should You can You shoulddesign design user- design design &before you centered while you measurebuild it before you build it while youall 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 / predictabilityBut 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