A primeira coisa a referir sobre livro “Project to Product” é que ele não era bem aquilo que eu estava a contar, mas ainda bem, porque trouxe muito mais do que eu imaginava.
Eu pensava que seria um livro com um carácter mais operacional, do dia-a-dia na gestão de projetos e com pistas sobre como olhar para os projetos e os transformar em produtos.
Na realidade é, para mim, um livro que olha para todo o processo de desenvolvimento de software e aponta os pontos que ainda é preciso trabalhar para que esta “Época do Software e do Digital” se concretize em pleno, como as outras épocas anteriores (Revolução Industrial, Vapor e Caminho de Ferro, Aço e Engenharia Pesada, Petróleo e Produção em Massa)
Nesse sentido apresenta todo um enquadramento e conceitos que racionalizam o que o autor, Mik Kersten, apresenta como as suas epifanias.
“Epiphany 1 – Productivity declines and waste increases as software scales, due to disconnects between the architecture and the value stream
Epiphany 2 – Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project managament model
Epiphany 3 – Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products”
Mik kersten, Project to Product, pag.23
Pensar em contínuo
Uma das principais mensagens que retirei do livro é olhar para todo este processo como um processo contínuo.
Numa perspetiva de uma empresa que trabalha para os seus clientes, há sempre um fluxo de necessidades ou serviços que queremos atender.
Nesse sentido, continuando a empresa a querer servir o seus clientes, não há propriamente projetos que iniciam e acabam, mas sim serviços que vão sendo disponibilizados ao longo do tempo e que corrigem, mantêm, melhoram, o valor que é entregue ao cliente.
Mais do que um projeto, este processo torna-se assim parte de algo contínuo que é a vida da empresa.
Este enquadramento é também importante porque informa as decisões que os gestores fazem no que diz respeito ao software que querem desenvolver.
In the context of software value stream, the concept of “end-to-end” includes the entire process of value delivery to the customer. It encompasses functions ranging from business strategy and ideation all the way to instrumentation of usage to determine which values were most adopted by the customer base. It is this end-to-end process that we need to understand and find bottlenecks in before considering the optimization of any particular segment of the processe, such as feature design or deployment.”
Mik kersten, Project to Product, pag.39
Project-Oriented Management vs Product-Oriented Management
| Project-Oriented Management | Product-Oriented Management | |
| Budgeting | Funding of milestones, pre-defined at project scope. New budget requires creation of a new project | Funding of product value streams based on business results. New budget allocation based on demand. Incentive to deliver incremental results |
| Time Frames | Term of the project (e.g., one year). Defined end date. Not focused on the maintenance / health after the project ends. | Life cycle of the project (multiple years), includes ongoing health / maintenance activities through end of life |
| Success | Cost center approach. Measure to being on time and on budget. Capitalization of development results in large project. Business incentivised to ask for everything they might need up front. | Proft center approach. Measured in business objectives and outcomes met (e.g. revenue). Focus on incremental value delivery and regular checkpoint |
| Risk | Delivery risks, such as product / market fit, is maximized by forcing all learning, specification, and strategic decision making to occur up front. | Risk is spread accross the time fram and iterations of the project. This creates option value, such as terminating the project if delivery assumptions were incorrect or pivoting if straategic opportunities arise |
| Teams | Bring people to the work: allocated up front, people often span multiple projects, frequent churn and re-assignment. | Bring work to the people: stable, incrementally adjusted, cross-functional teams assigned to one value stream |
| Prioritization | PPM and project plan driven. Focus on requirements delivery. Projects drive waterfall orientation | Roadmap and hypothesis testing driven. Focus on feature and business value delivery. Products drive Agile orientation |
| Visibility | IT is a black box. PMEs create complex mapping and obscurity | Direct mapping to business outcomes, enabling transparency |
Value Stream e Flow Items
A Flow Framework que é apresentada, é o modelo teórico que apoia o que é apresentado no livro e que, na parte da “Value Stream Metrics” apresenta uma configuração que achei muito proveitosa para ajudar a pensar todo este processo.
Embora inicialmente me tivesse parecido um pouco complexo e abstrato é algo que, depois de ler algumas vezes, me faz bastante sentido, até porque toca (e de certeza que não por acaso) outras área que são relevantes como o enquadramento das metodologias agile.
Por um lado começamos por pensar numa Value Stream
“Value stream: The end-to-end set of activities performed to deliver value to a customer through a product or service.”
Mik kersten, Project to Product, pag.70
Ou seja, olhamos para o todo que é necessário para entregar algo ao nosso cliente. E isto leva-me para o foco no cliente logo na definição de estratégia, e também para em que é que consiste o nosso trabalho no dia-a-dia (um percurso para satisfazer o cliente, um propósito) que se enquadra também na questão do output vs outcome (o que queremos atingir vs os meios para chegar lá).
E na medida em que uma value stream corresponde a tudo o que tem de ser feito para entregar valor ao cliente, vai ter de englobar também todas as equipas e pessoas necessárias para o atingir forçando de alguma forma a quebra do silos funcionais que muitas vezes se criam.
“Value streams are composed of all the activities, stakeholders, processes, and tools required to deliver business value to the customer. While this may sound obvious, my second epiphany was all about the fact that instead of creating abstractions around end-to-end value streams, organizations keep creating them within functional silos. For example, if support teams or business stakeholders are excluded from the process, the result is no longer a value stream but a sgment of the value stream.”
Mik kersten, Project to Product, pag.71
Nessa Value Stream vão andar Flow Items
“Flow Item: a unit of business value pulled by a stakeholder through a product’s value stream”
Mik kersten, Project to Product, pag.76
| Flow Items | Delivers | Pulled by | Description | Example Artifacts |
| Features | New business value | Customers | New value added to drive a business result; visible to the customer | Epic, user story, requirement |
| Defects | Quality | Customers | Fixes for quality problems that affect the customer experience | Bug, problem, incident, change |
| Risks | Security, governance, compliance | Security and risk officers | Work to address security, privacy and compliance exposures | Vulnerability, regulatory requirement |
| Debts | Removal of impediments to future delivery | Architects | Improvements of the software architecture and operational architecture | API addition, refactoring, infrastrucure automation |
Esta visão do que circula na value stream é muito interessante porque consegue capturar todo o ciclo de vida deste contínuo. Não é uma abordagem só para o projeto Agile só com aquilo que desenvolver, não é uma abordagem só a vertente ITIL com a assistência do produto, inclui os Riscos e também o “Défice Tecnológico” que os projetos muitas vezes incorrem.
Nesta última vertente, achei interessante, a forma como considera que deve ser abordada
“In using the flow framework, the only technical debt work that should be prioritized is work that increases future flows through the value stream”
Mik kersten, Project to Product, pag.77
Ou seja, a alteração de arquiteturas ou plataformas, sem efeito tangível no futuro não é considerada.
Ao mesmo tempo achei divertida a abordagem à correção de erros
“… treating production software incidents as unplanned investments in a system’s architecture”
Mik kersten, Project to Product, pag.78
Flow Metrics
Esta segmentação do tipo de Flow Items permite depois análises relevantes, sendo que uma que achei interessante foi a da distribuição do tipo de Flow Item por período de tempo.
É óbvio que no início o numero de Items do tipo Feature vai ser maior que os Defects e ainda não há Debt, ao mesmo tempo também temos a percepção de que, quando se aproximam datas importantes, muitas vezes as implementações estão a incorrer “Debt” que depois vão ter de pagar. Ou então após uma determinada Release aumentaram os “Defects”
Muitas destas análises nós já temos como percepção, mas conseguir visualiza-las, ao longo do tempo, e conseguir ver, em conjunto com o gestores o ponto em que estamos e o que nos parece ser o futuro é algo que me parece extremamente valioso.
IMAGEM
Este será talvez o indicador que achei mais interessante. Claro que os restantes são importantes, mas parece-me enquadrar-se mais no tipo de análise habitual (“excepto” claro no facto de estarmos sempre a olhara para algo que está dentro de uma value stream, ou seja o contexto em que estamos a olhar é já muito diferente do simples projeto).
| Flow Metric | Description | Example |
| Flow Distribution | Mutually Exclusive and Comprehensively Exhaustive (MECE) allocation of flow items in a particular flow state across a measure of time | Proportion of each flow unit actively being worked on in a particular sprint. |
| Flow Velocity | Number of flow items done in a given time | Debts resolved for a particular release |
| Flow Time | Time elapsed from when a flow item enters the value stream (flow state = active) to when its released to the customer (flow state = done) | Time it takes to deliver a new feature to a customer from when the feature is accepted |
| Flow Load | Number of flow item with flow state as active or waiting (i.e., work in progress WIP) | Flow load that exceeeds a certain threashold adveersely impacts flow velocity |
| Flow efficiency | The proportion of time flow items are actively worked on to the total time elapsed | Flow efficiency decreases when ependencies cause teams to wait on others. |
Business Result Metrics
| Business Result | Measures | Examples |
| Value | Benefit to the business produced by the value stream | Revenue, monthly recurring revenue, annual contract value, monthly active users |
| Cost | Cost of the value stream to the business | Cost of all staff, operations, and infrastructure supporting the value stream. Staff assigned to the value stream |
| Quality | Quality of the product produced by the value stream as perceived by the customer | Escaped defects, tickets filed, renewal rate, expansion rate, Net Promoter Score (NPS) |
| Happiness | Engagement of the staff working on the value stream | Employee Net Promoter Score (eNPS), employee engagement |
Embora métricas como Valor e Custo poderão ser mais fáceis de obter, outras como Qualidade e Felicidade, sendo mais subjetivas, são mais complexas de obter e calcular.
Nesse sentido parece-me relevante aquilo que é referido sobre a forma como captamos indicadores de qualidade e como eles devem vir o mais diretamente possível dos clientes.
“In addition to escaped deffects, the number of incidents, ticket counts, and other customer-success metrics can populate this bucket. Quality metrics that are not visible to the customer, like defect aging and change success rate, can provide important leading indicators of quality problems. However, they should remain one level down, as the Flow Framework focuses on customer- and business-visible metrics.
Mik kersten, Project to Product, pag.117
Medir para Decidir
“A measure of value is the canonical metric for each value stream. While this may seem obvious, just getting to the point where every product-oriented value stream and its customers are identified across the entire IT portfolio is a critical and missing piece in organizations. Once the product portfolio is defined, measuring cost, quality, and happiness are the other pillars to aligning flow metrics to business results.”
Mik kersten, Project to Product, pag.122
Como referi no inicio, este livro vai muito além daquilo que eu estava a contar, e ao mesmo tempo, neste momento, também ainda está muito além daquilo que eu consigo ver no meu dia-a-dia.
Assim, embora o livro depois continue com a “Part III: Value Stream Network”, as primeiras duas “Part I: The Flow Framework” e “Part II: Value Stream Metrics” foram as mais relevantes para mim.
Destaco somente a análise comparativa entre Produção Industrial e Desenvolvimento de Software.
“… we must more clearly define the key differences between managing the iterative and network based value streams of software development, and managing the linear value streams of manufacturing:
- Variability: Manufacturing has a fixed, well-defined set of variations for what will emerge from the end of the line, whereas the design of software feature is open ended. Manufacturing needs to minimize variability; software development needs to embrace it.
- Repeatability: Manufacturing is about maximizing throughput of the same widget; software is about maximizing the iteration and feedback loops that continually reshape the widget. We need repetability at each stage of software delivery, such as reliable automated deployment, but each end-to-end process needs to be optimized for flow, feedback, and cotinual learning, not just repeatability;
- Design frequency: Manufactured products like cars are designed up front in project-oriented cycles spanning years. Changes in design are infrequent and require altering the production line itself. With software, the shift to product-oriented features increases the frequency of design to match the rate of flow items passing through the value stream. The design happens inside, not outside, the production system;
Creativity: Manufacturing processes aim to achieve the highest feasible level of automation, which is facilitated by removing any creative and nondeterministic work from the production process. In contrast, software delivery focuses on enabiling creativity and collaboration at each step, using automation to support creativity”
Deixe um comentário