1 / 47

Product Planning

Product Planning. #2 reason for project failure: Incomplete requirements. Cost of a bug in requirements. Data from the Late 70 th. Modern environment. Rapid Application Development Tools Cost of development < Cost of Planning

jontae
Download Presentation

Product Planning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Product Planning #2 reason for project failure: Incomplete requirements

  2. Cost of a bug in requirements Data from the Late 70th

  3. Modern environment • Rapid Application Development Tools • Cost of development < Cost of Planning • Extreme case: Throw-away prototypes instead of document updates (Agile Approach) • New Deployment Models • SaaS, Automatic Updates • Reduced cost of update deployment

  4. Can the planning phase be skipped? • Still have old models around • Large scale projects: Plane throwaway prototyping? • Desktop Software: cost of a bug in MS Office? • Requirements and specifications are captured in • In the Code and UI screens • In head of a developer/CEO • Product Lifecycle Management Systems • Word documents, Excel tables, Visio diagrams

  5. Waterfall vs. Agile • Waterfall • Complete specifications/design before coding • eXtreme Programming(XP) • Short User Stories • Myriad of approaches in-between

  6. A word on methodologies • No methodology is perfect • “The list of tricks and common situations for which these tricks were found to be helpful for some(many) people” • Special case: methodology imposed by your organization

  7. This course • Create 3 requirements documents • What user need? (Problem) • What system should do to meet user need? (features) • How system should behave? (implement features) • MRD,PRD,FRD • Short, Informative • Will be updated during the course

  8. Good requirements are: • Correct • Necessary • Prioritized • Unambiguous • Verifiable • Feasible • Complete

  9. Every Document is a Proposal • You want(propose to) somebody to take actions on your documents • Customer :Sign the contract • User: Provide you with a feedback • Developers: Commit on it • Manager: Praise you

  10. Crash Course on Proposal Writing • Proposal should be ( in that order) • Convincing • Correct • Complete • 100% of real life could not be put on paper • People have short attention span • Short informative documents capturing the essence of the requirements/specifications

  11. Short informative documents “I have made this letter longer than usual, because I lack the time to make it short” Blaise Pascal,(1657) 

  12. Simplified Product Planning Process

  13. Problem->Feature->Behavior • MRD/CRS • A user needs… • In terms of the problem • Try to keep solution out • PRD • A system should…. • In terms of the solution/features • Try to keep behavior/technology out • FRD/SRS • A system will…. • In terms of UI, actions sequences, data flows • Try to keep inner working(classes, architecture) out Strict boundaries are not always realistic: “A user needs a large green button in the middle of the screen”

  14. Example • Customer: last month our system is crashed and we lost all of our data. It was terrible, we lost $1M in revenues • Business Analysts: A user needs to be able to retain following data (D1,D2) in XXX time frame in case of systems failures: F1,F2,F3. This a critical requirements • Product Manager: A system should automatically periodically backup data at remote site according the policies P1,P2. The maximal data capacity is Z. The configuration options are O1, O2,O3. A system should be restored using saved data and following procedures…. • Program Manager: A system will perform following actions when backup event is triggered (S1,S2,S3) The following screenswill be presented to a user for data backup policies configuration

  15. A Problem Have Many Solution • Program Manager: The system will continuously synchronize following data with standby reserve (“shadow”) copy of the system. In case of the failure the system automatically switch to the reserve copy

  16. A feature may be supported by different system behavior • Program Manager: the configuration of the system will be performed using configurations files F1, F2

  17. Example #2 • Problem: • A user should be able to verify that the text is in correct English • Solution: • Automatically correct spelling mistakes as user types • Indicate suspected spelling mistakes • A proofing tool to run on whole documents • Behavior • Red underlying of suspected misspelling after user put a separator character at the end of the word • Yellow highlighting of misspelled words • Separate window with suggested correction for current paragraph

  18. Managing Change Requests • Unique characteristic of Software Engineering is rate and dimension of changes • Software change is inevitable • Anticipating changes is in the core of almost every software engineering activities • Traceability is a key technique for coping with changes during the planning phase

  19. Traceability • Keep track on connection between market ,product and functional requirements • Unique labels of requirements/specification • Tractability of: bugs, releases, test cases ,project work items • Traceability Matrix

  20. Traceability Matrix: Safety Tool • Make sure all requirements (new and old) are covered • Make sure obsolete requirements /changed is not implemented • Make sure all critical bugs are fixed • Make sure all scenarios are tested • Track project progress (% of requirements covered by currently implemented features)

  21. Sample traceability matrix A traceably matrix

  22. Role: Business Analyst

  23. Simplified Product Planning Process

  24. Business Analyst • Other names: Outbound Product manager, Marketing Product Manager • Represent customer, users or other stakeholders (e.g. customer partners) • Expert in the problem domain • Major information channel (bi-directional) to customer

  25. Customer requirements • A Customer often speaks in terms of current bad solution and not the business problem • Different people at customer organization have different views(priorities) on the problem • Customer often assumes some facts are common knowledge while they are not

  26. Market requirements • None or little customer feedback • Changing business environment • Requirements to support: • Creating value for potential customers • What do customer want? (problem definition) • Delivering value • Fabulous web site that nobody use • Capture value • Generate revenues to pay programmers’ wages

  27. The Essence of Market Requirements • Short problem description • Lists/Tables of • Stakeholders(Actors) • Scenarios/Tasks • Requirements • What actor should be able to do in order to complete a task?

  28. Stakeholders • External • Users (e.g. HR, Management) • Buying Decision Maker • IT • Internal • Sales • Marketing • Support • Integrators • Stakeholder description • Skills and Background (e.g. technical, management) • Goals (save time, increase control etc.)

  29. Tasks and requirements • Tasks an actors need to perform • IT: Backup the system • HR: Create new employee • Requirements • Id • Short catchy name • Actor • Directive: A user should be able… • Priority • Tasks • Other: source, constrains etc.

  30. Example • ID: R1 • Actors: HR, employee • Name: User Authentication • Directive: A user should be able to be authenticated by the system • Tasks: T1(HR creates new employee record) , T2(an employee change his address)

  31. Assignment #2 • Each group plays Business Analyst for the assigned project • Short presentation on market requirements (15 minutes) • Consult “customer” during the preparation • Discussion and brainstorming in the class (15 minutes) • A “customer” is expected to provide most of the feedback • Product Planning team produces MRD based on obtained feedback • MRD(version 1.0) submission deadline: a week after the presentation

  32. MRD • Keep it short: 2-3 pages • Choose format, order of presentation which is most appropriate for the problem • Check Google for MRD templates • Expect changes, keep change log

  33. Document Change Log

  34. Good requirements are: • Correct • Necessary • Prioritized • Unambiguous • Verifiable • Feasible • Complete

  35. Product Planning Team • Product Planning Team(PPT) is an owner of the project and responsible for delivering the product to customer satisfaction • PPT should open Google Group for a project • Upload presentation, documents • Try to perform all further communications about the project with other groups through the Google group postings • Send me URL for Google Group

  36. Product Manager

  37. Simplified Product Planning Process

  38. Product Manager • Other names: Technical/Inbound Product Manager • Good knowledge of the problem domain • Solution expert • Aware of other solutions for the problem • Technological background, understand approximate cost and feasibility of the features • Communicate with Business Analyst and Engineering to find best trade-off between scope and cost

  39. Project triangle

  40. More formal view

  41. Practical view

  42. Course Project • Duration is fixed : 1 semester • Cost(Effort) is fixed: team size and amount of time each member can dedicated to the project • Choose scope wisely!

  43. Product Requirements Document • Feature requirements • Compatibility requirements • Performance/Capacity requirements • Internationalization requirements • Documentation requirements • Deployment requirements • Support and training requirements

  44. Our focus • Feature requirements • ID: P1 • Directive: System should support user authentication • Constrains: Some cellular providers block all protocols besides HTTP, so system should support authentication via HTTP protocol (no SSL) • Source Market Requirements ID: M3,M4 • Priority: Critical/High/Nice-to-Have

  45. Assignment #3 • Planning team makes a presentation on product requirements (15 minutes, 10 slides) • In class discussion, brainstorming (15 minutes) • “Customer” is expected to ask questions • Submit PRD ver 1.0 in a week after the presentation • Upload to Google Group • Keep it short (1-3 pages) • Don’t forget change log • Google for PRD templates/examples • Choose your own format/order

  46. Good requirements are: • Correct • Necessary • Prioritized • Unambiguous • Verifiable • Feasible • Complete

More Related