Product definition, product vision, product life cycle

Transcription

1 Product definition, product vision, product life cycle Tommi Mikkonen Dept. Computer Science University of Helsinki, Helsinki. Finland

2 Content Product definition, product vision Product creation and product life cycle Software evolution view to products Scaling product management For further reading Summary and conclusions

3 Product management Components - Versioning: Which versions exist, how to find old versions, etc. - Identification: Which component this is? What properties it has? - Production: How to create a particular component (which compiler version, which flags, etc). - Change management: How to prevent simultaneous changes, which changes have been made, Configuration - Versioning: Which versions exist, how to recreate old versions, - Identification: Which configuration this is, which components and component versions are used by client x s installation y - Production: How to build client x s configuration a.b.c - Change management: Which components (and their versions) a certain change will have an effect on? Which configurations (and their versions) a certain change will have an effect on? Practices, processes, etc. - Responsibility and privileges - How phase products move from one system/phase to next? - How new versions are approved and released? - How change proposals and error reports are made, managed and processed? - Archives and backups

4 Software product definition A good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence. - The totality of goods or services that a company makes available -

5 Software product vision For a mid-sized company s marketing and sales departments who need basic CRM functionality, the CRM-Innovator is a Web-based service that provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. Unlike other services or package software products, our product provides very capable services at a moderate cost. - (as proposed by Jim Highsmith Practice Director, Agile Project Management, Cutter Consortium.)

6 Software product vision For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)

7 Product life (US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.)

8 Product life (US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.) Great opportunities to create useless inventories!

9 Product life cycle management

10 World does not stand still at maintenance: iterations, versions, etc. (

11 Methodologial vs. ad-hoc feedback loops Prototyping Incremental development Sprints Lean startup

12 Prototyping (& partly also demos) Goals Figuring out what is technically doable Validating designs and predicting large problems Communication, assuring management and other stakeholders Attributes Cycle length: From hours to months Team size: From one developer to a team of developers Termination condition: Full stop once a technological solution is proven to be feasible.

13 Incremental development Goals Provide value to the customers already during the project. Taking advantage of new technology. Assuring users that the development is continuous and on-going. Attributes Cycle length: Any given time that is needed to get a new increment done..? Team size: Software team (and the related stakeholders) Termination condition: When the new software asset/increment is considered done.

14 Sprints Goals Responding to emerging user needs Helping in execution and coordination of the work Improving the ways of working Guiding to frequent evaluations of new parts of the system Attributes Cycle length: One to four weeks Team size: Software team Termination condition: Calendar deadline (1-4 weeks)

15 Lean startup Goals Gathering justifiable evidence if profitable, scalable user needs exist. Evaluating if a hypothesized business model is feasible to satisfy the user needs. Learning by creating MVPs. Attributes Cycle length: From days to weeks Team size: From a single developer to a whole software team. Termination condition: Once the learning goal can be validated with statistically significant results.

16 Focus Motivation Goal Staff Prototyping Feasibility and implementability Almost always technical in nature Explore design space for a particular solution individual developer, team of developers Incremental development Scoping the technical work feature-wise Mix between business and technical aspects Organize company operations as a whole in releases Affects the whole organization Sprints Scoping the technical work time wise Liberate developers from constant changes to a fixed set of features Considers mostly development aspects. Executed by a Scrum team up to 12 people; variations exist Lean startup Learning and experimenting Business oriented in nature. validate a business hypothesis with minimum effort Usually executed only by a minimal team

17 More is better? v. 1.0 v

18 Software evolution view to products Process of developing software, then repeatedly updating it for various reasons Over 90% of the costs of a typical system arise in the maintenance phase, and that any successful piece of software will inevitably be maintained - Fred Brooks Agile methods stem from maintenance-like activities (originally in and around web based technologies) - Wikipedia

19 Lehman s laws of software evolution ( S-type programs are those that can be specified formally; P-type programs cannot be specified but an iterative process or procedure is used to find a working solution; E-type programs are embedded in the real world and become part of it thereby changing it, and requiring a feedback system where the program and its environment evolve in coordinated fashion. Algorithms, e.g. sorting Process control, e.g. maintaining correct temperature Systems that interact with people and other parts of their environment

20 Characteristics of an E-type system Continuing Change. All E-type systems need continuous adaptation or they become progressively less satisfactory. Increasing Complexity. Because all E-type systems evolve, their complexity increases unless work is done to reduce it. Self-Regulation. E-type system evolution process is self-regulating with distribution of product and process measures close to normal. Conservation of Organizational Stability. The average effective global activity rate in an evolving E-type system is invariant over a product lifetime. Continuing Growth. The functional content of an E-type system must be continually increased to maintain user satisfaction.

21 Characteristics of an E-type system Conservation of Familiarity. As an E-type system makes everything associated with it evolve, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. Because too rapid growth diminishes that mastery, the average incremental growth remains invariant as the system evolves. Declining Quality. The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. Feedback System. E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

22 Types of upgrades ( Corrective diagnosing and fixing errors, possibly ones found by users Adaptive modifying the system to cope with changes in the software environment (DBMS, OS) Perfective implementing new or changed user requirements which concern functional enhancements to the software Preventive increasing software maintainability or reliability to prevent problems in the future

23 Types of upgrades (ISO/IEC 14764) Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems. Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

24 Maintenance factors (for/against success) Maintenance specialists 35% High staff experience 34% Table-driven variables and data 33% Low complexity of base code 32% Y2K and special search engine 30% Code restructuring tools 29% Re-engineering tools 27% High level programming languages 25% Reverse engineering tools 23% Complexity analysis tools 20% Defect tracking tools 20% Y2K mass update specialists 20% Automated change control tools 18% Unpaid overtime 18% Quality measurements 16% Error prone modules -50% Embedded variables and data -45% Staff inexperience -40% High code complexity -30% No Y2K of special search engines -28% Manual change control methods -27% Low level programming languages -25% No defect tracking tools -24% No Y2K mass update specialists -22% Poor ease of use -18% No quality measurements -18% No maintenance specialists -18% Poor response time -16% No code inspections -15% No regression test libraries -15%

25 Vote: Does PO role scale?

26 Example: Mozilla connected devices process (

27

28 Example: The Long Tail (

29

30 Scoping product management in the large Product Owner vs. Product management Product Managers -> overall market success of their products, not just delivery of software Product Owner (agile/sw term) -> Small subset of the Product Management Option #1: Product management picks up additional, tactical responsibilities of the Scrum product owner Does not scale: agile teams require intense, daily tactical support. Product managers usually not interested in the technical part Option #2: Product owners assume some of the responsibilities of the product managers Overlapping responsibilities; Who decides what the product is supposed to do? POs are unlikely to be trained or skilled in the other aspects of the traditional product manager role

31 Scoping product management in the large Option #3: Dual agile roles market/customer-facing product managers. continue in their role along with most of their existing responsibilities, adopt agile practices, including taking on a tighter relationship with the development teams. solution/product/technology-facing product owners are either technically inclined product managers or business analysts, or development team members who are interested in that new role assume the agile team product owner responsibilities but also take on a tighter relationship with product management

32 PO vs. PM: An agile interpretation Agile product owner Technology/team facing Co-located (and also reports to) development or technology Focus on product and implementation technology Owns the implementation Drives iterations Agile product manager Market /customer facing Co-located (and reports to) marketing or business Focus on market segments, product portfolio, return on investment (ROI) Owns the the vision and product roadmap Drives the release

33 For further reading Product vision: Iterative cycles: Software inventory (and how Trello was ideated): Lehman s laws (of software evolution): Scrum anti-patterns (as requested in the class):

34 Summary and conclusions Product vision needed to guide the development towards new versions To whom, why better than competition, why specia Iterative approach is a practical must to learn & scope things as you go Software evolution driving towards more and more complex designs Scaling PO role up is practical, but requires discipline