You are on page 1of 68

La gua para la gestin de productos y el cuerpo de conocimiento de marketing

(ProBok)

Section 1: Understanding Product Management

Chapter 1: Introduction
1.1 What Is The Guide to the Product Management and Marketing Body of Knowledge
(ProdBOK)? A Body of Knowledge
1.2 Introducing a New Standardized....
1.3 The ProdBOKs Audience
1.4 Laying the Groundwork for Certification....
1.5 The ProdBOK Guide Structure in Summary
Chapter 2: Product Management and Product Marketing Management
2.1 The Current State of Product Management
2.2 The History of Product Management
2.3 The Evolution of Brand and Product Management
Chapter 3: What Is a Product?
3.1 Goods and Services
3.1.1 Goods
3.1.2 Services
3.2 Brands
3.3 Product Lines
3.4 Extensions
3.4.1 Brand Extensions
3.4.2 Line Extensions
3.4.3 Category Extensions
Chapter 4: What Is Product Management?
4.1 Internal and External Aspects of Product Management
4.2 Structure of Product Management
4.2.1 The Upstream/Downstream Product Management Model
4.3 Product Management Structure within Organizations
4.4 Product Managements Relationship to General Management
4.5 Managing and Marketing Goods and Services across All Industries and Companies
4.6 Variations by Industry and Maturity
Chapter 5: Common Product Management Roles
5.1 Product Manager
5.1.1 Market-Facing
5.1.2 Internal
5.1.3 Technical
5.1.4 Service
5.2 Product Marketing Manager
5.3 Product Portfolio Manager
5.4 Product Owner Outside of Scrum
5.4.1 The Product Owner and Scrum
Chapter 6: Aligning ProdBOK with Other Existing Processes (and Why It Matters)
6.1 Strategy and Innovation Processes
6.1.1 Strategy
6.1.2 Innovation
6.2 Value Creation Processes
6.2.1 Serial Processes: Waterfall and Phase-Gate
6.2.2 Iterative
6.2.3 Iterative/Incremental ProcessesAgile, Scrum, Extreme Programming (XP), and
Lean The Agile Theory
Chapter 7: Product Managements Relationship with Other Disciplines
7.1 A Closer Look at Project Management Methods and Their Application within the
Product Management Framework
7.2 Core Project Management Methods and Processes
7.2.1 Methods and Processes Used in Project Initiation
7.2.2 Methods and Processes Used in Project Planning
7.2.3 Methods and Processes Used in Project Execution, Monitoring, and Control
7.2.4 Methods and Processes Used in Project Closeout
7.3 Applying Project Management during the Conceive Stage (Fuzzy Front End)
7.4 Applying Project Management during Product Development
7.4.1 Project Management Activities in the Develop Phase
7.5 Project Management in Commercialization/Operations
7.5.1 Potential Projects Related to Product Commercialization
7.5.2 Potential Projects Related to Ongoing Operations
7.6 How Program Management Relates to Product Management
7.6.1 Core Project Management Methods and Processes at the Program Level
7.6.2 Sound Program Management Practices
7.6.3 Dedicated Project Management Personnel (Where Appropriate)
7.7 How Project Portfolio Management Relates to Product Management
7.8 Business Analysis
7.8.1 Business Analysis Governing Organization and Body of Knowledge
7.8.2 Product Management and Business Analyst
7.8.3 Business Analysis Skills and Knowledge
7.8.4 Scenarios for Leveraging Business Analysis
7.8.5 The Role of the Business Analyst in Product Design
7.9 User Experience and Product Management
7.9.1 A Closer Look at User Experience
7.9.2 Product Management and User Experience

Section 2: The Product Management Lifecycle Framework


Chapter 8: Introduction to the Product Management Lifecycle Framework and
Process Groups
8.1 The Advantages of Implementing a Standard Product Management Lifecycle
Framework
8.2 A Common Lexicon
8.3 The Product Management Lifecycle Framework
8.4 Defining Roles within the Product Management Lifecycle Framework
8.5 Mapping a Products Production Process
8.6 Product Management Processes for a Product
Chapter 9: The Fundamentals
9.1 Levels of Product
9.2 Product Lifecycle
9.3 Market Segmentation
9.4 Innovation Types
9.5 Levels of Strategy
9.6 A Closer Look at Product Portfolio Management
9.6.1 Portfolio Analysis
Chapter 10: The Conceive Phase
10.1 Setting the Stage
10.2 Product Concept Identification
10.2.1 External Assessment
10.2.2 Opportunity and Threat Identification
10.2.3 Internal Assessment
10.2.4 Product Strategy Options
10.2.5 Create the Product Concept
10.2.6 Product Concept Approval
10.3 Product Concept Investigation
10.3.1 Document Naming Conventions
10.3.2 Establish a Cross-Functional Product Concept Team
10.3.3 Market Investigation
10.3.6 Create Overall Project Charter
10.3.7 Create Preliminary Business Case
10.4 Exiting the Conceive Phase
Chapter 11: The Plan Phase
11.1 Plan Phase Activity Groups
11.2 Product Definition Activities
11.2.1 Product Requirements User Experience and User Interface
11.2.2 Product Roadmap
11.3 Project Plan Activities
11.3.1 Development Plan
11.3.2 Other Supporting Functional Plans (Preliminary)
11.4 Marketing Plan Activities
11.4.1 Product and Marketing Strategy (Updated)
11.4.2 Launch Strategy (Updated)
11.5 Business Case Activities
11.5.1 Financial Analysis (Detailed)
11.5.2 Business Case (Updated)
11.6 Create Preliminary Product Management Plan
11.7 Exiting the Plan Phase
Chapter 12: The Develop Phase
12.1 Develop Phase Activity Groups
12.2 Product Development Activities
12.2.1 Product Implementation
12.2.2 Product Requirements Refinement
12.2.3 Product Verification Activities Release and Configuration Management
12.3 Market Validation Activities
12.3.1 Beta Plan/Market Plan
12.3.2 Usability Testing
12.4 Launch Planning Activities
12.4.1 Launch Plan (Detailed)
12.4.2 Other Supporting Functional Plans (Detailed)
12.5.1 Review Checkpoints
12.5.2 Business Plan Update
12.6 Exiting the Develop Phase
Chapter 13: The Qualify Phase
13.1 Market Validation Activities
13.1.1 Beta or Market Test
13.2 Launch Preparation
13.2.1 Marketing Launch Preparation
13.2.2 Manufacturing and Operations Launch Preparation
13.2.3 Sales and Channel Launch Preparation
13.2.4 Customer Support Launch Preparation
13.2.5 Product Documentation Delivery
13.3 Launch Readiness Assessment
13.3.1 Business Plan Update (Final)
13.3.2 Launch Decision
13.4 Exiting the Qualify Phase
Chapter 14: The Launch Phase
14.1 The Importance of Market Type in Setting Launch Strategy
14.2 Product Launch Activity Groups
14.2.1 Launch
14.2.2 Post-Launch
14.3 Exiting the Launch Phase
Chapter 15: The Deliver Phase
15.1 Product Deliver Stages
15.1.1 Growth
15.1.2 Maturity
15.1.3 Decline
15.2 Controlling the Length of Product Lifecycle Stages
15.3 Exiting the Deliver Phase
Chapter 16: The Retire Phase
16.1 End-of-Life Plan
16.1.1 External Areas of Impact to Consider in End-of-Life Plan
16.1.2 Internal Areas of Impact to Consider in End-of-Life Plan
16.2 Phase Review

Section 3: Key Product Management Tools by Product Lifecycle Phase

Chapter 17: Product Management Tools


17.1 The Conceive Phase Tools
17.1.1 Product Portfolio Management
17.1.2 Product Concept Identification
17.1.3 Product Concept Investigation
17.2 The Plan Phase Tools
17.2.1 Product Requirements Document (PRD)
17.2.2 Project Planning
17.3 The Develop Phase Tools
17.3.1 Usability Evaluation Methods
17.3.2 Alpha and Beta Plans
17.3.3 Launch Plan
17.4 The Qualify Phase Tools
17.4.1 Launch Readiness Checklist
17.5 The Launch Phase Tools
17.5.1 Product Launch Plan
17.5.2 Messaging and Positioning Platform
17.5.3 Sales and Channel Readiness Plan
17.5.4 Demand Generation Plan
17.5.5 Analyst Relations Plan
17.5.6 Public Relations and Media Plan
17.6 The Deliver Phase Tools
17.6.1 Market Analysis Template
17.6.2 Channel Strategy and Plan
17.6.3 Pricing Comparison Chart
17.6.4 Product Demos
17.6.5 Analyst Strategy and Briefings Plan
17.6.6 Public Relations and Media Plan
17.7 The Retire Phase
17.7.1 End-of-Life Plan

Capitulo 1 Introduccion

En los ltimos 15 aos, la comunidad de gestin de productos ha crecido de un


puado de lderes de pensamiento a docenas. Pero este crecimiento ha hecho
poco para solidificar un cuerpo estndar de conocimiento o conjunto de
habilidades necesarias para tener xito como gerente de producto. Los cuerpos
de conocimiento conducen a una mayor comprensin. Aunque la gestin de
productos se entiende claramente en una empresa como Procter & Gamble,
que defini la gestin de la marca hace dcadas, hay muchas empresas que, al
ser inseguro lo que implica la gestin de productos, contratar a un gerente de
producto "experimentado" para dirigir. No hay un solo curso o programa
universitario que uno puede tomar para convertirse en un gerente de producto
profesional. Por lo tanto, es justo decir que la gestin de productos es una
experiencia en el trabajo. Utilizando la experiencia acumulada a travs de
prueba por fuego o en el trabajo de formacin, un gerente de productos de
carrera pasa de empresa en empresa, con su propia perspectiva de forma
nica. Esta educacin "en el trabajo" de los gerentes de producto ha llevado a
las organizaciones de contratacin a creer que la experiencia del dominio es
necesaria porque los gerentes de contratacin no estn seguros de qu
habilidades son transferibles de la industria a la industria. Y la falta de un
conjunto definido de habilidades fundamentales ha dejado el campo abierto a
la interpretacin y la improvisacin. Los editores de este libro creen que es
importante, por lo tanto, establecer un estndar bsico de conocimiento sobre
la gestin de productos como una profesin.

1.1 Qu es la Gua para el Cuerpo de Conocimientos de Gestin de


Productos y Marketing (ProdBOK)?

Un Cuerpo de Conocimiento (BOK) transmite un estndar comnmente


aceptado de conceptos, definiciones, procesos y actividades que conforman
una profesin, segn lo definido por los lderes de pensamiento participantes,
acadmicos y practicantes en el campo. Un BOK no es una enciclopedia de
todas las cosas de gestin de productos, sino una gua que estimula a los
profesionales a buscar ms conocimientos, recursos y certificacin. La Gua del
Cuerpo de Conocimientos de Gestin de Productos y Marketing (ProdBOK) es
esa suma de conocimientos dentro de la profesin de gestin de productos.
ProdBOK representa el conocimiento y las prcticas que son aplicables a la
mayora de los gerentes de producto, la mayora del tiempo, basado en un
consenso de su valor y utilidad. Este BOK proporciona los conocimientos
fundamentales necesarios para ser un gerente de producto eficaz. Se
desarroll para dar a los gerentes de productos la informacin que les
motivara a profundizar en el tema y la investigacin del cuerpo mucho mayor
de conocimiento que existe dentro del dominio de gestin de productos. Es una
referencia viva que est en constante evolucin.

1.2 Introduccin de un nuevo marco de gestin de productos


estandarizados

Un marco de gestin de productos (PMF) crea un lenguaje consistente que


abarca la innovacin, la creacin, la entrega y la gestin continua de los
productos. Un PMF es aplicable a todos los productos desarrollados y
administrados a lo largo de su ciclo de vida, desde productos de crecimiento
emergentes hasta productos maduros bien establecidos en el mercado. El
objetivo de este PMF es definir las actividades que debe llevar a cabo un
gerente de producto para innovar, disear y administrar un producto que
satisfaga las necesidades y expectativas de los clientes y las empresas y que
pueda gestionarse adecuadamente en trminos de presupuesto, calendario,
alcance, calidad y Recursos. El PMF organiza y gua actividades de desarrollo
multifuncional a travs de varias etapas, e incorpora controles de diseo para
optimizar la ejecucin y la efectividad de los productos resultantes. Es
escalable y se puede mantener, y se puede aplicar a toda la gama de bienes y
servicios. El entorno empresarial de hoy en da es desafiante y complejo. Los
gerentes de productos pueden utilizar un marco para abordar temas como la
gestin de productos, combinaciones integradas de bienes y servicios,
globalizacin, legislacin cambiante y regulaciones cada vez mayores. Un PMF
permite a las organizaciones adoptar un enfoque holstico a nivel de sistema. El
PMF no pretende ser un procedimiento de operacin estndar. Es decir, no se
pretende que sea prescriptivo, donde completar todos los productos dentro del
marco es un requisito. Ms bien, promueve el pensamiento crtico sobre las
actividades necesarias para apoyar cualquier iniciativa de producto. El
pensamiento crtico permite al equipo decidir qu actividades tienen sentido, y
fomenta la agilidad necesaria que los equipos necesitan para entregar en este
entorno rpidamente cambiante y competitivo.

1.3 La Audiencia de ProdBOK

Esta gua proporciona una referencia singular para cualquier persona


interesada en la gestin de productos, desde ejecutivos senior estableciendo
expectativas para sus gerentes de producto a aquellos simplemente
interesados en aprender ms sobre el campo. Esto incluye, pero no se limita a:

Ejecutivos de alto rango

Los gerentes de los profesionales de la gestin de productos

Gerentes de marca

Gestores de producto

Propietarios del producto

Gerentes de marketing de producto

Gestores de cartera

Gerentes de programa

Gerentes de proyecto

Analistas de negocios

Educadores y formadores desarrollando programas educativos y enseando la


gestin de productos o temas relacionados

Consultores y otros especialistas en el campo de la gestin de productos

1.4 Establecer las bases para la certificacin y el aprendizaje


acadmico

Los cuerpos de conocimiento definen un estndar para discutir, escribir y


aplicar un lxico comn a un campo profesional. Proporcionan una excelente
oportunidad para dominios profesionales para estandarizar las comprensiones
fundamentales, el lenguaje y las habilidades necesarias para que individuos y
organizaciones tengan xito. Ganar una certificacin mediante el uso de este
cuerpo estndar de conocimiento demuestra a los compaeros la capacidad
cualitativa y cuantitativa para realizar el trabajo. La certificacin tambin
demuestra una dedicacin para aprender y avanzar las habilidades de gestin
de productos. Este BOK es la base para desarrollar preguntas para el examen
que los individuos deben pasar para convertirse en un gerente de producto
certificado por la Asociacin de Marketing y Gestin de Productos
Internacionales (AIPMM). Los solicitantes de la certificacin AIPMM se someten
a un examen riguroso y completo de sus conocimientos en cada rea. Una
empresa de certificacin profesional y de licencias ayud a construir este
examen. AIPMM sigue la Norma Internacional ISO / IEC 17024, Requisitos
Generales para rganos de Certificacin Operativa de Personas, en la creacin
de los procesos de certificacin y examen.

1.5 La estructura de la Gua ProdBOK en resumen La Gua ProdBOK


est organizada en tres secciones:

Seccin 1: Comprensin de la gestin de productos

Esta seccin proporciona una base bsica para entender la administracin del
producto. Define trminos clave, conceptos, procesos y contexto bsico para el
resto de la Gua ProdBOK. Tambin proporciona puntos clave de integracin
sobre cmo este BOK puede ser utilizado y alineado con otros estndares de la
industria y procesos de mercado.

Seccin 2: El marco del ciclo de vida de la gestin de productos

Esta seccin identifica el marco utilizado para administrar un producto.


Describe las siete fases diferentes de la gestin de productos; Concebir,
planificar, desarrollar, calificar, lanzar, entregar y jubilarse.

Seccin 3: Herramientas clave de gestin de productos por fase del ciclo de


vida del producto
Esta seccin proporciona una descripcin detallada de las principales
herramientas de administracin de productos contenidas en cada fase del ciclo
de vida de la gestin del producto.

Capitulo 2

Gestin de productos y gestin de marketing de productos.

2.1 El estado actual de la gestin de productos

Los retos empresariales actuales estn haciendo que la gestin del producto
evolucione y se vuelva ms estructurada. Estos desafos tambin han creado
una competencia intensa y consumidores sofisticados. Como resultado, las
organizaciones ahora exigen a individuos altamente calificados que pueden
afectar inmediatamente la lnea de fondo, desarrollar el siguiente producto o
servicio "debe tener" y ejecutar un plan ganador. Durante una entrevista con
Harvard Business Review sobre el tema del crecimiento, Jeffrey Immelt, CEO de
General Electric, declar una vez que la compaa no tena "suficientes
gerentes de productos sofisticados e ingenieros de sistemas para encargarse
de los programas de alta visibilidad". Immelt vio esto como una "debilidad
organizacional", General Electric inmediatamente comenz a abordar este
problema. Este aumento de la demanda de profesionales de gestin de
productos ha creado un crecimiento continuo en la formacin de gestin de
productos y la certificacin.

2.2 La historia de la gestin de productos

Para ver dnde va la gestin de productos como una profesin, ayuda a mirar
sus orgenes. La gestin de los productos naci de un ensayo intensivo,
riguroso y riguroso en el departamento de investigacin de mercado de la
gigantesca compaa de bienes de consumo, Procter & Gamble (P & G). En
1931, D. Paul "Doc" Smelser, economista de la Universidad Johns Hopkins y jefe
de la nueva unidad de P & G -el departamento de investigacin de mercado-
contrat a mujeres graduadas universitarias para llevar a cabo el trabajo de
campo. l utiliz un acercamiento antropolgico, enviando a los graduados
puerta a puerta a las amas de casa de la encuesta sobre su uso de todas las
clases de productos del hogar. Dentro de varios aos, el personal del
departamento creci a alrededor de 34, adems de decenas de investigadores
de campo. El primer grupo de productos, comnmente llamado una marca,
para incorporar estos mtodos de investigacin de mercado en el proceso de
diseo del producto fue el jabn Camay. El jabn de Camay fue el catalizador
para definir la gestin de marca, y Neil McElroy de P & G lider el cargo. El bar
de belleza perfumada de Procter & Gamble, el jabn Camay, desafi el
posicionamiento de pureza de otro producto de P & G, el jabn Ivory. Los dos
productos se dirigan a mercados muy diferentes y competan por los recursos
dentro de P & G. Esto convenci a McElroy, entonces un joven administrador de
publicidad, de la necesidad de establecer asignaciones para sus vendedores en
equipos especficos de marca para que esos equipos tuvieran una medida de
autonoma en las campaas de marketing. En una nota de la compaa de P &
G fechada el 13 de mayo de 1931, McElroy describi los deberes y las
responsabilidades de los "hombres de la marca." Se les encarg analizar la
historia de la marca y se les instruy para "estudiar el territorio
personalmente" clientes. Tanto Smelser como McElroy comprendieron la
importancia del trabajo de campo. Ambos abogaron por salir de la oficina y
hablar cara a cara con los clientes. Al igual que los antroplogos, saban que
los datos ms valiosos sobre las personas son cmo se comportan en su propio
entorno. Reconocieron que las encuestas, las entrevistas programadas y los
grupos focales slo dan una imagen parcial. La nota de McElroy sent las bases
para un cambio de una perspectiva de ventas alineada geogrficamente a una
orientacin de marca. El resultado fue una reestructuracin fundamental de P
& G. John Pepper, ex presidente de P & G del directorio, presidente y CEO, dijo
que "la responsabilidad y la responsabilidad de las unidades de negocio
discretas fueron asignadas a organizaciones separadas ... por Neil McElroy,
cuando ayud a crear el sistema de gestin de marcas en los aos treinta". ]
Los gerentes de marca de Procter & Gamble asumieron la responsabilidad de
coordinar todas las actividades y tareas relacionadas con su marca. Mucho ms
que marketing, los gerentes de marca tambin coordinaran el desarrollo de
productos y ventas de campo. Desde McElroy, cada uno de los principales
ejecutivos de P & G ocupara los puestos de gerente de marca asistente y
gerente de marca en su camino hacia la escalera ejecutiva.

2.3 La evolucin de la gestin de marcas y productos

"Un producto se fabrica en la fbrica. Una marca se hace en la mente. "[5] Esto
podra ser demasiado simplista, pero s destacar las diferencias entre la marca
y la gestin de productos.
Qu significa exactamente una marca en la mente? Una marca es un nombre,
trmino, diseo o representacin simblica de los bienes o servicios del
vendedor. En otras palabras, una marca es la suma de los factores psicolgicos
y emocionales percibidos que existen en la relacin entre una empresa y sus
clientes. Las marcas tienen significado y ayudan a establecer una conexin
personal y emocional con el cliente. Las empresas construyen bienes y / o
servicios y luego agregan valor creando marcas para transmitir beneficios
funcionales, econmicos y psicolgicos al cliente en trminos de calidad, precio
e imagen. Los productos sirven como mecanismo de entrega de la promesa de
la marca. Esta promesa encapsula la reputacin de una empresa y la propuesta
de valor global y comunica lo que los clientes pueden esperar ms all de lo
que el producto ofrece. Muchas empresas tienen una sola marca y, por lo tanto,
la estructura de la organizacin en torno a los productos. Cuando una empresa
tiene mltiples marcas, como es el caso de P & G, la marca est en el pinculo
de la jerarqua de productos. Un ejemplo excelente es el enfoque de Disney en
la creacin de "mgicas" experiencias de los clientes. En el modelo de gestin
de marca desarrollado por P & G y adoptado por muchas empresas de bienes
empaquetados, la estructura de gestin de la marca fue el centro de la rueda y
la carrera para futuros CEOs de P & G. De hecho, varios gerentes de marcas de
P & G se convirtieron en CEOs lderes en otras industrias, como eBay (Meg
Whitman), Intuit (Scott Cook), Microsoft (Steve Ballmer) y AOL (Steve Case). El
notable xito que result del enfoque de P & G en las marcas y sus productos
subyacentes llev a las organizaciones fuera del segmento de productos de
consumo a adoptar un modelo similar: la gestin de productos. Fue de esta
manera que lo que comenz como la gestin de la marca evolucion en la
profesin distinta llamada gestin de productos y se aclimat ms
cmodamente en una amplia gama de industrias, incluidos los productos de
consumo.

Captulo 3 Qu es el producto?

Los productos son el resultado de un proceso de esfuerzo o pensamiento. En su


ncleo, los productos son la suma de los beneficios que satisfacen la necesidad
o el deseo de un cliente. La palabra "producto" se utiliza comnmente para
describir bienes duraderos o tangibles. Sin embargo, ms correctamente, los
productos pueden ser bienes o servicios y se distinguen por la tangibilidad: los
bienes son tangibles y los servicios son intangibles. Desde el punto de vista del
cliente, el producto es la experiencia global proporcionada por la combinacin
de bienes y servicios para satisfacer las necesidades de los clientes antes de
usarlos, mientras los usan y despus de haber dejado de usarlos.

3.1 Bienes y Servicios

3.1.1 Mercancas Existen varios tipos de productos fsicos, como


sigue. Productos de consumo: artculos que se utilizan diariamente. Los
productos de consumo se identifican comnmente como bienes comprados
para uso personal. Hay cuatro tipos de productos de consumo: Productos de
conveniencia: bienes que se compran inmediatamente y con frecuencia con
poca comparacin o tiempo de decisin. Productos de compras: bienes que
requieren investigacin y anlisis antes de comprar (por ejemplo, oro, plata,
automviles y ropa). Generalmente, cada compra requiere un examen de
precio, calidad, durabilidad y valor de reventa. Productos especializados:
bienes y servicios que son nicos o tienen una identificacin de marca tan clara
que un consumidor est dispuesto a hacer un esfuerzo significativo para
comprarlos. Los ejemplos incluyen artculos de lujo, vacaciones exticas y
artculos de coleccin. Productos no investigados: bienes y servicios que un
consumidor no conoce o no quiere pensar. Los ejemplos incluyen artculos
funerarios, tales como atades, lpidas mortuorias o parcelas
funerarias. Business-to-Business: bienes y servicios utilizados para dirigir un
negocio o para vender directamente a clientes empresariales. Productos
industriales: bienes o servicios utilizados por una industria o negocio, y no por
un individuo. Otros productos: Otras clasificaciones de productos de uso comn
incluyen: Productos perecederos (tambin conocidos como bienes no
duraderos): bienes que pueden ser destruidos fcilmente o que no tienen una
larga vida til. Los buenos ejemplos son frutas, verduras, productos lcteos,
cosmticos, combustible, productos de limpieza y papel. Bienes duraderos: lo
contrario de los productos perecederos, estos bienes estn en uso durante al
menos tres aos. Ejemplos son muebles, equipos electrnicos y hardware. Los
bienes duraderos tambin se clasifican con productos industriales tales como
fotocopiadoras, maquinaria y oficinas. Productos terminados: productos listos
para la venta inmediata. Los productos terminados no requieren procesamiento
adicional.

3.1.2 Servicios

Segn Kotler y Keller (2008) [6], los servicios son "cualquier actividad o
beneficio que una parte puede ofrecer a otra que es esencialmente intangible y
no da lugar a la propiedad de nada". Las cuatro caractersticas de los servicios
son: 1) intangibilidad , 2) perecederos, 3) inseparabilidad, y 4) variabilidad.
[7] Un concepto errneo comn es que los servicios difieren de lo que a
menudo se conoce como "productos". Comprender que los productos son una
mezcla de bienes y servicios en diversos grados es un paso importante en el
proceso de creacin de valor (ver seccin 6.2). Por lo tanto, es importante
entender si un producto sera clasificado como un "bien puro" (algo que no est
acompaado por un servicio, es decir, pasta de dientes) o un producto que
resultara solamente en la entrega de un servicio (es decir, un cita con el
dentista).

Servicios profesionales

Los servicios son asistencia, apoyo o beneficios ofrecidos por una persona a
otra. Ejemplos son proporcionados por profesionales como plomeros,
electricistas, mecnicos, abogados, mdicos y cosmticos.

Servicios de negocios

Servicios de negocios son ofertas que abarcan todas las industrias y


organizaciones. Estos servicios incluyen consultora, servicio al cliente y
tecnologa de la informacin. A veces, los servicios de negocios se combinan
con artculos de cortesa. En estos casos, los servicios estn estrechamente
alineados y pueden ser difciles de separar de los bienes, especialmente
cuando forman parte de beneficios aumentados en el caso de garantas,
acuerdos de servicio y soporte.

Servicios de Soporte Tcnico

Los servicios de asistencia tcnica acompaan a los productos


manufacturados. Estos servicios se ofrecen directamente desde el fabricante
oa travs de un proveedor de terceros.

Servicios financieros

Los servicios financieros son productos ofrecidos por instituciones financieras


para la facilitacin de transacciones financieras y otras actividades
relacionadas. Ejemplos incluyen prstamos, seguros, tarjetas de crdito,
oportunidades de inversin y administracin de dinero.

Garantas de servicio

Una garanta de servicio proporciona proteccin contra el costo de reparacin,


reemplazo o mantenimiento de un producto de consumo a cambio del pago de
una prima. Estos servicios vienen en muchas formas, incluyendo garantas,
garantas, garantas extendidas, garantas extendidas o contratos de servicio
de mantenimiento.

3.2 Marcas

Como se seal anteriormente, los productos son bienes y servicios que


ofrecen un beneficio funcional. Una marca, por otra parte, es un nombre,
smbolo, diseo o marca que realza el valor del producto ms all de su valor
funcional. David Ogilvy, fundador de la agencia de publicidad Ogilvy & Mather,
define una marca como: "Un smbolo complejo. Es la suma intangible de los
atributos de un producto, su nombre, embalaje y precio. Su historia, reputacin
y la forma en que se anuncia. Una marca tambin se define por las impresiones
de los consumidores de las personas que la utilizan, as como por su propia
experiencia ". [8] Una marca tambin puede describirse como un activo
estratgico de una organizacin y la experiencia, la percepcin y la reputacin
de una empresa. Valores y creencias de la organizacin, personalidad y
comportamiento. Tambin comprende el nombre y la marca visual por la cual
una organizacin es reconocida.

3.3 Lneas de Producto

Segn la 12 edicin de Principles of Marketing, "Una lnea de productos es un


grupo de productos [categorizados por una unidad de negocio o empresa] que
estn estrechamente relacionados porque funcionan de manera similar, se
venden a los mismos grupos de clientes, se comercializan A travs de los
mismos tipos de puntos de venta, o caen dentro de rangos de precios dados ".
[9]

3.4 Extensiones

Hay un poco de confusin acerca de la definicin de la marca y las extensiones


del producto. Es til recordar que una marca vive en la mente, y el producto
representa el mecanismo de entrega de la marca. Las siguientes definiciones
pretenden hacer claras las distinciones.

3.4.1 Extensiones de marca

Cuando una empresa utiliza una marca establecida para introducir un nuevo
producto, se denomina extensin de marca. [10] Por ejemplo, cuando las
celebridades usan su marca (su nombre) en la creacin de fragancias, ropa,
restaurantes, joyas, vehculos, etc., estn creando extensiones de
marca. Durante el proceso de creacin, los equipos de desarrollo de estas
categoras estn asumiendo que una identidad de marca en particular
resuenar con las percepciones de los consumidores de la celebridad. El xito
se logra generalmente cuando la marca y la categora estn estrechamente
alineados. Para ilustrar mejor este punto, uno puede mirar en la ltima dcada
en la marca duradera de Harley-Davidson. Harley-Davidson tiene una fuerte
identidad de identidad masculina. Por lo tanto, experiment un fallo de
extensin de la marca cuando introdujo una lnea de perfume. La imagen o
identidad del macho fuerte que vive en la mente de los fans de Harley-
Davidson no encajaba en la lnea de perfumes. Las extensiones de marca se
pueden clasificar en dos tipos: extensiones de lnea y extensiones de categora.
3.4.2 Extensiones de lnea

Las extensiones de lnea de producto crean nuevos productos en la misma


categora utilizando la marca existente. Estos nuevos productos pueden incluir
cosas como diferentes formatos, envases alternativos, nuevos sabores o
ingredientes nuevos o adicionales. Por ejemplo, Cherry COKE es una
extensin de la lnea de productos de la bebida Coca-Cola COKE.

3.4.3 Extensiones de categora Las extensiones de categora son el uso de una


marca existente o primaria para lanzar productos en otras categoras. Por
ejemplo, Harley-Davidson es una motocicleta, pero la marca Harley-Davidson
se utiliza para distinguir un estilo de diseo utilizado en los camiones Ford F-
series.

CAPTULO 4 QU ES GESTIN DEL PRODUCTO?

Dicho simplemente, la gestin de productos es el proceso de concebir,


planificar, desarrollar, probar, lanzar, entregar y retirar productos en el
mercado. Es la funcin organizativa dentro de una empresa que se ocupa de la
gestin reflexiva y proactiva de un producto o grupo de productos a lo largo de
todas las etapas del ciclo de vida del producto.

Como disciplina, la gestin de productos proporciona un enfoque gerencial a


los productos (bienes y servicios) ya las marcas como sistemas generadores de
ganancias dentro del contexto de la organizacin ms grande. Sin una gestin
eficaz del producto, el desarrollo de productos es propenso a conjeturas,
proyectos de desarrollo equivocados y oportunidades perdidas. Con la gestin
de productos de clase mundial, las empresas desarrollan productos con slidos
conocimientos de clientes y mercados, lo que aumenta la probabilidad de xito
en el mercado.

4.1 Aspectos internos y externos de la gestin de productos

La gestin de productos como un proceso tiene dos reas de enfoque distintas:


interna y externa. Interno se define como dentro del entorno de la
organizacin, incluyendo elementos tales como los equipos de productos
actuales, la alta direccin y los procesos requeridos. El entorno externo incluye
elementos como la cadena de suministro, la red de distribucin y los
mercados. La forma en que cada empresa define, desarrolla y entrega
productos ser influenciada por estos factores.

4.2 Estructura de la gestin de productos

En la prctica, no existe un modelo de gestin de producto nico. Sin embargo,


el valor estratgico de una tendencia ha ganado impulso y se ha vuelto cada
vez ms claro: tener la funcin de gestin de productos directamente al CEO o
al presidente de una unidad de negocio estratgica. Esta tendencia es apoyada
por los resultados de una encuesta realizada por Tom Grant de Forrester
Research, que indic un aumento en la eficacia de la organizacin de gestin
de productos cuando la funcin de informes directamente al ejecutivo.

Adems, las organizaciones informan que la gestin de productos funciona


mejor cuando funciona dentro de una serie de controles y equilibrios. En otras
palabras, el proceso funciona mejor cuando la funcin de administracin de
productos equilibra las necesidades a corto plazo de funciones tales como
ventas y atencin al cliente frente a las necesidades a ms largo plazo de la
base de clientes, el mercado y la organizacin. Para lograr este objetivo, la
funcin de gestin de productos necesita la autonoma para tomar la mejor
decisin global en nombre de la organizacin, base de clientes y mercado
objetivo. Cuando estos factores estn en armona intranquila, las
organizaciones reportan un alto grado de xito en el mercado.

4.2.1 El Modelo de Gestin de Producto Upstream / Downstream.

Linda Gorchels, en la edicin 2011 de The Product Manager's Handbook,


describe dos clasificaciones fundamentalmente diferentes, aunque
relacionadas, de las funciones de gestin de productos: aguas arriba y aguas
abajo.

Las funciones de upstream se ocupan de las estrategias de los roadmaps de


productos y los esfuerzos de desarrollo de nuevos productos. Por lo general
incluyen la identificacin de las necesidades crticas de la cartera y luego
proporcionar liderazgo a lo largo del proceso de desarrollo hasta el
lanzamiento. Las funciones downstream se ocupan de la gestin del ciclo de
vida en curso. Algunos fabricantes de dispositivos mdicos y diagnsticos, en
particular, contratan personas separadas para las dos categoras de trabajo. GE
Healthcare, por ejemplo, tiene gerentes de producto upstream responsables de
la estrategia de producto global y el lanzamiento. Sus gerentes de producto
downstream manejan el soporte de marketing y ventas necesario para
administrar las ventas rentables de los productos despus del lanzamiento y
ms all. A veces, los gestores de producto de abajo son responsables de
comercializar los productos en diferentes pases. La empresa de productos y
servicios de salud Beckman Coulter tiene posiciones similares, pero se refiere a
ellos como gerentes de productos estratgicos y tcticos.

La divisin entre la gestin de productos aguas arriba y aguas abajo no es


coherente entre las industrias. Para algunas empresas, particularmente en
campos altamente tcnicos, las actividades de upstream terminan antes de la
comercializacin, con los gerentes de producto downstream asumiendo el
control en el lanzamiento. Y algunas empresas cambian de la corriente
ascendente a la corriente abajo en el inicio de un nuevo proyecto de producto
(en el cambio de I + D al desarrollo). La mejor prctica para una empresa es lo
que funciona mejor para sus circunstancias especficas.

4.3 Estructura de gestin de productos dentro de las organizaciones.

La etapa de crecimiento de cada empresa afecta la estructura organizativa real


de la gestin de productos. En startups y empresas en las primeras etapas de
crecimiento, donde la velocidad al mercado se enfatiza, las organizaciones de
gestin de productos tienden a ser pequeos y giles con un enfoque en la
interaccin directa del cliente. El gerente de producto generalmente est
administrando todos los aspectos de un producto o grupo de productos desde
el inicio hasta el lanzamiento. La estructura organizativa es muy plana, con
bajos grados de especializacin.

Como una puesta en marcha da paso a una empresa mediana de xito, los
recursos cambian a la construccin de escala y la gestin del crecimiento
resultante. Como resultado, la funcin de administracin de productos tiene la
tarea de administrar el crecimiento y la complejidad. Los gerentes de productos
en esta etapa de crecimiento estn a menudo rodeados de talento adicional,
en particular para ayudar a gestionar los requisitos, supervisar las
especificaciones y garantizar niveles adecuados de compromiso con los
equipos de desarrollo y soporte transversal. La organizacin de gestin de
productos se est expandiendo durante esta etapa a medida que se
implementa la implementacin del proceso y la especializacin.

Las organizaciones ms maduras se han movido histricamente y lentamente y


metodolgicamente para proteger su cuota de mercado existente mientras
persiguen el crecimiento tanto orgnicamente como a travs de fusiones y
adquisiciones. A medida que el negocio ha aumentado en escala y
complejidad, las organizaciones de gestin de productos han crecido
significativamente y ahora contienen un alto grado de experiencia a travs de
una gama de habilidades necesarias con mayor especializacin.

Aunque la etapa de crecimiento suele dictar la configuracin de la gestin de


productos, algunas organizaciones construyen culturas que desafan la
convencin y la lgica comn.

La estructura de Google, por ejemplo, se basa en un vicepresidente (VP) de


productos que lidera un equipo de vicepresidentes de productos del sector, que
en ltima instancia depende directamente del CEO. Los informes a los
vicepresidentes de los productos del sector son equipos de gerentes de
productos.

En Microsoft, hay muchas capas de vicepresidentes senior y vicepresidentes de


las unidades de negocio para recorrer antes de encontrar un VP de gestin de
productos. Microsoft tambin tiene un enfoque de gestin de producto de
equipo, utilizando administradores de productos, administradores de
programas y gestores de marketing de productos. Facebook, una empresa
modelo "software como servicio" (SaaS) como Google, tiene un director de
gestin de productos que depende directamente del CEO. Aunque no hay una
frmula mgica, la decisin sobre dnde se encuentra la gestin del producto
en la organizacin se reduce a estas preguntas:

1. Cul es el objetivo general de la gestin del producto?

2. Dnde en la organizacin un gerente de producto puede tener la mejor


posicin estratgica y ser ms efectivo?

3. Dnde est la toma de decisiones financieras para productos ubicados


en la organizacin?

4. Dnde se pueden medir y comparar estas decisiones?

Es evidente que la comprensin de las respuestas a estas preguntas conduce a


disear la estructura de gestin de producto adecuado dentro de una
organizacin. Gerentes de productos generalmente tienen la mejor oportunidad
para tener xito cuando se reportan a un lder de negocios en la empresa o
unidad de negocio que debe equilibrar las necesidades a corto y largo plazo de
los clientes, el mercado y la organizacin.

4. Relacin de la Gerencia de Producto con la Gerencia General

La gestin general abarca la elaboracin de estrategias, la planificacin, la


organizacin, la dotacin de personal, la ejecucin, la prestacin y la provisin
de la infraestructura adecuada asociada con los procesos operativos y de
apoyo. La gestin de productos puede incluir la responsabilidad general de
administrar la estrategia, la planificacin, los ingresos, el costo, el marketing, el
desarrollo del canal de ventas, la entrega del producto, el despliegue
operacional y el soporte de un producto. La gestin del producto es
esencialmente la gestin general de un producto. Pero hay una distincin
clave: los gerentes generales tienen plena responsabilidad por prdidas y
ganancias y tienen lderes funcionales informndoles, mientras que los
gerentes de productos interactan principalmente a travs de la influencia y
apoyndose en objetivos organizacionales compartidos.

5. Gestin y comercializacin de bienes y servicios en todas las industrias y


empresas

Los principales objetivos del marketing son identificar, satisfacer y retener al


cliente. Aunque existen diferencias en las industrias sobre cmo se logra cada
uno de esos objetivos, existen algunos mtodos, habilidades y programas
fundamentales. A menos que se indique lo contrario, los procesos y mtodos
descritos en este conjunto de conocimientos son aplicables a una amplia gama
de industrias y organizaciones, independientemente de su tamao.

4.6 Variaciones por ramas de actividad y vencimientos

Gestin de productos abarca una amplia variedad de industrias. A continuacin


se presentan ejemplos que ilustran el nfasis en un subconjunto especfico de
las habilidades de gestin de productos.

Bienes de consumo envasados

La industria de bienes de consumo envasados requiere una gestin de


productos gil y receptiva. La clave del xito en este mercado es tener
procesos de innovacin eficaces, tiempos de comercializacin ms rpidos,
reconocimiento de marca y costos ms bajos. Hay una lucha constante por la
atencin de los consumidores; Por lo tanto, el foco est en realzar la
experiencia del consumidor con los productos.

Financiero

Las organizaciones que ofrecen servicios financieros (por ejemplo, bancos,


compaas de tarjetas de crdito, agencias de seguros, servicios de
financiacin al consumo, corredores de bolsa, organizaciones de fondos de
inversin y compaas de administracin de patrimonios) suelen separar la
estructura de gestin de productos en unidades de negocios por lneas de
productos y especialidad. Los gerentes de producto son aumentados por
expertos en la materia que pueden centrarse en las regulaciones
gubernamentales y la gobernanza, mientras que el gerente de producto se
centra en las necesidades de los clientes y el mecanismo de entrega de la
organizacin de servicios.

Hospitalidad

La hospitalidad es un modelo de organizacin de servicios que abarca


alojamiento, restaurantes, planificacin de eventos, parques temticos,
transporte, lneas de cruceros y otros campos dentro de la industria del
turismo. Esta industria favorece a los gerentes de producto que tambin tienen
aptitudes comnmente asociadas con la gestin de proyectos debido a su
enfoque en la planificacin y ciclos de vida ms cortos.

Cuidado de la salud

El cuidado de la salud es la amplia industria que abarca los equipos y servicios,


adems de los productos farmacuticos, la biotecnologa y las ciencias de la
vida. Los sectores particulares asociados a estos grupos son la biotecnologa, el
diagnstico, la entrega de frmacos, los fabricantes de frmacos, los
hospitales, los equipos y dispositivos mdicos, los laboratorios de diagnstico,
las residencias de ancianos, los proveedores de planes de atencin de salud y
los servicios de salud en el hogar. Esta amplia gama de productos favorece a
los gerentes de productos que tienen antecedentes cientficos, as como la
capacidad de navegar a travs de cuestiones reglamentarias.

Fabricacin

Los fabricantes actuales se enfrentan a retos globales. Deben crear un


crecimiento rpido, introducir nuevos productos y reducir los costos, todo
dentro de los confines de un mercado a menudo competitivo. Los gerentes de
producto en este ambiente deben entender la demanda creciente en la
innovacin y deben tener la capacidad de trabajar con los equipos de
fabricacin costa afuera y las cadenas de fuente distribuidas. Con tiempos de
desarrollo cortos y habilidades de colaboracin en tiempo real, los gerentes de
productos deben aprender a detectar problemas temprano.

Software

La gestin de productos de software es muy similar a la de otras industrias,


pero tiene algunos problemas que son ms prominentes. Como en la
fabricacin, los resbalones del horario son uno de los problemas ms grandes.

Telecomunicaciones

En el sector de las telecomunicaciones, el tiempo de comercializacin es


crucial; A medida que el mercado se consolida, los principales actores se ven
obligados a lanzar versiones de productos rpidamente. La gestin de
productos en telecomunicaciones debe identificar los requisitos y satisfacer las
necesidades de los clientes con los recursos de software de la empresa y los
activos tecnolgicos para mantenerse competitivos. La fijacin de precios y la
concesin de licencias tambin son cuestiones clave para las
telecomunicaciones.

Industrias Maduras

Las industrias maduras estn casi siempre dominadas por un pequeo nmero
de grandes empresas. Esta dominacin es causada por la consolidacin de la
industria y la sacudida competitiva que acompaa a estas industrias altamente
competitivas durante su crecimiento. La gestin de productos dentro de estas
organizaciones es generalmente ms estructurada. Un ejemplo de una
industria madura sera la industria del tabaco, que ha continuado las ventas,
pero un crecimiento mnimo.

CAPTULO 5: Funciones comunes de administracin de productos


Gerente de producto es el trmino general comnmente utilizado para describir
a los miembros del equipo que son responsables de administrar uno o ms
productos dentro de una organizacin. Para aportar ms claridad y significado
al papel, el ttulo se mejora a menudo para incluir la divisin, los productos
administrados, o la funcin realizada, es decir, gerente de producto, divisin de
bebidas; Gerente de producto, herramientas y mtricas; O gerente de producto
tcnico.

5.1 Gerente de Producto

Independientemente del ttulo, la mayora de los gerentes de productos tienen


la tarea de canalizar las necesidades del mercado en la organizacin y
asegurar que se logre un equilibrio ptimo entre las necesidades de los clientes
y las capacidades de la organizacin. Por lo tanto, los gerentes de producto
desempean un papel importante para maximizar el retorno de la inversin de
una organizacin en bienes y servicios durante todo el ciclo de vida del
producto.

La funcin de gerente de producto es un papel de frontera [11] que se


encuentra en la interseccin del mercado y la organizacin (Figura 5-1). Dentro
de la organizacin, el gerente de producto debe superar las diversas
expectativas de los diversos departamentos con los que deben interactuar. Los
gerentes de producto tambin asumen la responsabilidad de la planificacin
del producto. En esta funcin, el gerente de producto es responsable del
proceso continuo de identificar y articular los requisitos del mercado para un
mercado especfico o la necesidad del cliente.
Para desempear este papel, los gerentes de productos deben actuar como la
voz de los clientes, canalizando sus necesidades no satisfechas. Con esta
responsabilidad, el gerente de producto inicia y participa en visitas al cliente,
organiza paneles asesores de clientes y realiza entrevistas con
clientes. Armados con esta informacin, pueden liderar el proceso de mejorar
los productos en el mercado y desarrollar otros nuevos.

El gerente de producto tambin debe poseer una gran influencia y habilidades


de negociacin. En su artculo The Product Manager como Agente de Influencia,
Gemmill y Willemon declaran: "A pesar de que a los gerentes de productos se
les asigna la responsabilidad total de los beneficios de sus productos, a
menudo informan que estas responsabilidades no se corresponden con la
autoridad correspondiente sobre otras unidades organizativas sobre las que
son Dependientes para las contribuciones en la realizacin de sus programas
de comercializacin; Es decir, las ventas, la investigacin de marketing, la
fabricacin, la investigacin y el desarrollo y la publicidad ". [12] El xito del
gerente de producto suele estar en la capacidad de utilizar mtodos
alternativos de influencia para obtener apoyo para sus esfuerzos.

5.1.1 Orientacin al mercado

El gerente de productos orientado al mercado generalmente administra uno o


ms productos que tienen clientes fuera de su organizacin con los que
trabajan estrechamente para descubrir necesidades no satisfechas. Los
gerentes de productos orientados hacia el mercado realizan estudios de
mercado para descubrir necesidades no satisfechas y articular las necesidades
de un mercado objetivo o de una base de clientes. Esta posicin no debe
confundirse con el rol de marketing del producto, que se cubrir ms
adelante. En esta funcin, el gerente de producto considera elementos como la
demogrfica prevista, las ofertas de los competidores y el ajuste estratgico de
los nuevos productos con el modelo de negocio de la empresa. La informacin
del mercado se utiliza para reunir inteligencia para la construccin de los
productos adecuados.

5.1.2 Interiores

En contraste con los gerentes de productos orientados al mercado, los gerentes


de productos internos a menudo representan productos que son un
componente de un producto orientado al mercado, pero cuyos clientes estn
dentro de la organizacin. Gerentes de productos internos se encuentran
comnmente en la tecnologa o las industrias de datos, donde una plataforma
o base de datos debe ser gestionado de manera eficaz para crear valor para los
productos o servicios que se comercializan a clientes externos a travs de un
gerente de productos orientado al mercado.

5.1.3 Datos tcnicos


Los gerentes tcnicos de producto tienen una comprensin detallada de los
aspectos tecnolgicos de un producto y comnmente se asocian con los
gerentes de productos orientados al mercado para satisfacer las necesidades
del mercado. No es raro que los gerentes tcnicos de productos pasen un
tiempo significativo apoyando las necesidades de los colegas, como el equipo
de ingeniera. Por otro lado, un gerente de producto orientado al mercado se
centra en identificar las necesidades del cliente o del mercado. Los gerentes
tcnicos de productos tambin crean descripciones detalladas de las
caractersticas del producto, la priorizacin de las caractersticas, los casos de
uso, los requisitos del sistema, los requisitos de rendimiento, las ventas y los
requisitos de soporte y, si es necesario, los planes de prueba del mercado.

5.1.4 Servicio

Los gerentes de productos orientados al servicio se encuentran en posiciones


de mercado con la responsabilidad de administrar el alcance de los servicios de
una organizacin en todos los niveles, incluido el posicionamiento, la calidad de
la experiencia, la entrega y los precios.

5.2 Comercializacin de productos

Gerente El rol de gerente de mercadotecnia de productos se deriva a menudo


del deseo de una compaa de aumentar el enfoque en las actividades de "ir al
mercado" dividiendo el ciclo de vida del producto en partes separadas a
medida que la empresa crece. El gerente de producto, que antes de la nueva
funcin era la gestin de todo el ciclo de vida, generalmente mantiene la
responsabilidad de las actividades de pre-lanzamiento en el ciclo de vida del
producto. El gerente de marketing del producto asume la responsabilidad de
las actividades posteriores al lanzamiento. La organizacin espera que el
gerente de mercadeo de productos tenga o desarrolle habilidades slidas para
apoyar la adquisicin de clientes y en las actividades de mercado. Una de las
mejores maneras de hacer una distincin clara es delinear procesos y roles. La
gestin del producto y la comercializacin del producto son procesos. Los
gerentes de productos y los gerentes de marketing de productos son roles. Esta
distincin sita la mayor parte del enfoque en las tareas individuales. El rol de
un gerente de marketing de productos es ayudar a definir y administrar la
imagen de un producto en el mercado. En otras palabras, para anunciar el
producto al mundo, crear conciencia de los clientes y apoyar las ventas para
convertir a los prospectos en clientes rentables. Un gerente de marketing de
producto define el producto "promesa" y asegura su ejecucin exitosa en el
mercado. Eso tambin significa gestionar un lanzamiento exitoso, llevar a cabo
capacitacin en ventas y liderar programas clave a travs de varios canales de
distribucin. Adems de administrar el producto terminado en el mercado, el
gerente de marketing del producto est en una posicin nica para calibrar las
reacciones de los clientes al producto y, por lo tanto, aportar valiosas
contribuciones a los requisitos futuros, incluidas las revisiones o los
lanzamientos importantes.

5.3 Cartera de productos

Gerente El gestor de cartera de productos es un trmino paraguas para un


gerente que es responsable de una agrupacin de productos. Estos productos
se dividen a menudo en portafolios lgicos, organizados por lnea de negocio o
segmento. A diferencia de los gerentes de productos, que estn preocupados
por las especificaciones y detalles de un producto, el gestor de cartera
investiga detalles de nivel superior como inversiones, diversificacin y
riesgos. Los gestores de cartera de productos tambin participan en la gestin
de los activos de propiedad intelectual, patentes y marcas. Por lo general,
estn facultados para hacer compra / venta y transformar, desinvertir o jubilar
decisiones mientras trabajan estrechamente con representantes de la alta
direccin, legales y financieros.

5.4 Product Owner Fuera de Scrum

El rol del propietario del producto es un subconjunto claramente definido de las


responsabilidades de gestin del producto, centrado en representar a las
partes interesadas del negocio y del cliente en el proceso de desarrollo y
asegurar el desarrollo exitoso de un producto. Recogen los requisitos del
mercado y los criterios de aceptacin del cliente para el proyecto. Priorizan los
requisitos del mercado y toman decisiones acerca de las compensaciones de
caractersticas, funciones y tiempo. El propietario del producto trabaja con el
desarrollo para revisar los requisitos del producto y las especificaciones
funcionales e interacta con los clientes durante el desarrollo para asegurar
que el producto satisfaga sus necesidades. En organizaciones con una
estructura de propietario de producto establecida, los propietarios de productos
tambin pueden desarrollar casos de negocio, planes de lanzamiento y hojas
de ruta, elementos que tradicionalmente han sido considerados como el
dominio de los gerentes de producto.

5.4.1 El dueo del producto y Scrum

Scrum es un proceso iterativo, incremental ampliamente utilizado para crear


productos. Se proporciona una descripcin detallada de Scrum en la seccin
6.2.3. Aunque los propietarios de los productos pueden existir
independientemente de la metodologa Scrum, en Scrum, el propietario del
producto es uno de los tres roles claramente definidos (los otros dos son Scrum
master y miembro del equipo). El propietario del producto es responsable de
maximizar el valor comercial de la salida del equipo de desarrollo de Scrum. El
propietario del producto puede ser visto como el defensor de la empresa y el
cliente en el proceso de desarrollo. Scrum faculta a este individuo como "la
nica persona responsable de gestionar la cartera de productos" [13], que es
una lista de requisitos priorizados, usualmente escrita como historias de
usuarios. Esta autoridad impide que el equipo tenga que lidiar con prioridades
conflictivas. Al establecer las prioridades de desarrollo, el propietario del
producto aplica el conocimiento del mercado, el cliente y los objetivos de
negocio. Este individuo colaborar con el equipo de desarrollo para comprender
el costo de desarrollo y el riesgo tcnico de cada caracterstica para que el
rendimiento ajustado al riesgo pueda maximizarse. Adems, el propietario del
producto tiene la responsabilidad de socializar la cartera de productos con el
resto de la organizacin para recabar informacin de cada departamento y
crear consenso en torno al plan. En las organizaciones donde el rol del
propietario del producto ha adquirido raz, el propietario del producto puede
realizar tareas que se han considerado tradicionalmente como parte de la
funcin de administracin del producto, como la visualizacin de productos, el
mapeo de carreteras y la planificacin. Sin embargo, el ncleo de la funcin de
propietario del producto se define por algunas responsabilidades muy
especficas que a menudo son ms detalladas que la mayora de los gerentes
de producto estn acostumbrados a, como:

Priorizar la cartera de productos.

Elaboracin de historias de usuarios: preparacin de historias para un


desarrollo de Sprint, incluyendo la explicacin completa de la razn
empresarial detrs de cada historia y la contribucin a los criterios de
aceptacin.

Colaborar regularmente con el equipo y estar disponible en todo


momento para responder preguntas clarificadoras sobre cualquier requisito e
inspeccionar las historias de usuarios completadas.

Participacin en las reuniones de revisin de Scrum y Scrum.

En el desarrollo de software comercial, el rol de propietario del producto Scrum


suele ser llenado por un gerente de producto o gerente de producto tcnico,
pero es ms probable que sea manejado por un analista de negocios, un
ingeniero de ventas y otros ttulos. Para un proyecto interno de tecnologa de la
informacin, el propietario del producto podra ser un gerente de producto,
pero tambin podra ser un analista de negocios o un jefe de departamento. A
medida que los equipos han escalado a Scrum en la empresa para trabajar en
esfuerzos de desarrollo cada vez mayores, a menudo utilizan una jerarqua de
propietario de producto [14] (Figura 5-2). Esta jerarqua consta de uno o ms
niveles con un propietario principal del producto en la parte superior. El
principal propietario del producto comnmente tiene un director o
vicepresidente de nivel de ttulo y sera responsable de la rentabilidad general
del producto en la inversin y el xito. [15] Cada propietario del producto est
involucrado en supervisar el xito de su producto especfico.

Figura 5-2. Jerarqua del propietario del producto

IMAGENEEENN ---------

En las organizaciones que no utilizan una jerarqua de propietario de producto,


el propietario del producto Scrum puede colaborar con un gestor de
producto. En esta situacin, el propietario del producto trabaja estrechamente
con el equipo de desarrollo y se centra en el nivel de iteracin, mientras que el
responsable del producto se centra en el nivel de lanzamiento y mapa de ruta
(16)

CAPTULO 6

Alinear ProdBOK con otros procesos existentes (y por qu es


importante)

En este cuerpo de conocimiento, el trmino "marco de gestin de productos"


(PMF) se define como el proceso de gestin de todo el ciclo de vida de un
producto desde la concepcin, pasando por el desarrollo y la produccin, hasta
la jubilacin. Este PMF es una estructura completa de extremo a extremo para
la gestin de un producto de xito, e incluye personas, procesos, datos,
negocios / objetivos de la organizacin y, en ltima instancia, la satisfaccin del
cliente. El PMF tiene la intencin de centrarse no slo en documentos del
producto, sino en el acto de administrar el producto en s mismo para lograr un
resultado deseado. La gestin, en este contexto, es entender cules son los
objetivos y poner un plan en conjunto para alcanzar dichos objetivos, al tratar
eficazmente el cambio que pueda ocurrir en el camino. Ese objetivo, en
relacin con el PMF, abarca la satisfaccin del cliente, los objetivos de
desempeo de la organizacin, y el xito global de mercado en toda la vida del
producto. Es importante definir claramente el proceso de FMP, porque cuando
se trata de desarrollo de productos, especialmente para los nuevos productos,
hay una serie de procesos de negocio que aluden a la gestin de productos,
pero en realidad se centran nicamente en una parte del ciclo de vida del
producto.

Gestin de productos, como modelado en este conjunto de conocimientos,


naturalmente, est relacionada con otros procesos. Es vital que estos procesos
trabajan juntos de manera eficiente para lograr los objetivos del producto.
Algunos de los procesos y estndares ms comunes en la industria que se
centran en la gestin y la entrega y suelen ser causa de confusin para un
gerente de producto son la Direccin de Proyectos del Conocimiento, Anlisis
de Negocio Conjunto de conocimientos, y el Manifiesto gil (Agile Software
Development) . Es importante entender estos procesos diferentes y cuerpos de
conocimiento para asegurar la alineacin apropiada y aumentar las
posibilidades de lograr los resultados deseados en el mercado. Una simple
representacin de esa relacin es capturado en la Figura 6-1.

Figura 6-1. Los procesos comunes y Cuerpos de conocimiento que


operan dentro del marco de gestin de producto

Para obtener resultados ptimos, estos procesos deben estar alineados. Sin
alineacin, los engranajes de la figura 6-1 se muelen y finalmente se detendr,
causando la falla del producto y del proyecto. Cuando se ponen en el contexto
adecuado, estos procesos pueden existir simbiticamente, lo que permite el
xito del producto. Esto no quiere decir que el PMF es simplemente una
coleccin de otros procesos. Por el contrario, el PMF se ha diseado para
capturar todas las actividades y los resultados finales de un gerente de
producto y lder de negocios necesitan para gestionar una lnea de productos, a
partir de una idea del producto indefinido "fuzzy" todo el camino hasta la
maduracin y el retiro del producto despus de aos en el mercado. El PMF es
donde los procesos de apoyo necesitan para alinear y crear valor. Las
siguientes secciones proporcionan un contexto adicional con respecto a estos
otros tipos de procesos y el valor de alinendolos con el PMF.

6.1 Estrategia y Procesos de Innovacin

6.1.1 Estrategia

La estrategia es sobre la previsin de un resultado deseado, trazando un curso


eficaz para lograr este objetivo, y la alineacin de ese curso de accin, siempre
y cuando tenga sentido hacerlo. Michael E. Porter, profesor de la Escuela de
Negocios de Harvard, aade que, "La estrategia competitiva se trata de ser
diferente. Significa elegir deliberadamente un conjunto diferente de actividades
para ofrecer una combinacin nica de valores ". [17] En la prctica, los
gerentes de producto dividen su tiempo entre el desarrollo y la implementacin
de la estrategia de producto y conducir la ejecucin tctica. Muchos gerentes
de producto utilizan un conjunto de herramientas de estrategia de Michael
Porter "Cinco Fuerzas" [18] modelo para ayudar a evaluar el atractivo del
mercado y la ayuda en la toma de decisiones y planificacin. Esas fuerzas son:

1. Entrada. Qu tan fcil ser para entrar en el mercado? Los nuevos


competidores se ven obstaculizados por barreras sustanciales y pueden sufrir
represalias por parte de los competidores existentes. Para el participante,
algunas de las barreras ms comunes son las economas de escala, grandes
requerimientos de capital, el acceso limitado a los canales de distribucin, y las
regulaciones gubernamentales o subsidios.

2. Amenaza de sustitucin. Hay otros productos y servicios que pueden


ser fcilmente sustituidos por el producto en cuestin? Si es as, y si hay poca
diferencia entre los productos, los clientes pueden cambiar
fcilmente. Adems, en el caso de aumento de precios, un consumidor puede
decidir sustituirlo por otro producto.

3. El poder de negociacin de los compradores. Hacer un pequeo nmero


de compradores afecta una gran parte de las ventas? No adquirir un cliente de
un gran porcentaje de los productos de las compaas? Se cambia entre
competidores relativamente fciles? Estos factores dan a los compradores una
gran cantidad de energa, sobre todo si el producto no es extremadamente
importante para los compradores o si se puede prescindir de l durante un
tiempo.

4. El poder de negociacion de los proveedores. Hay una presin


significativa de los proveedores? Si hay muy pocos proveedores o que no es
fcil de cambiar de proveedor, que puede controlar el volumen y los precios, lo
que puede obstaculizar la capacidad de una empresa para funcionar de forma
competitiva.

5. Rivalidad entre los competidores actuales. En los mercados llenos de


gente con poca diferenciacin entre los productos, la competencia tendr un
impacto en la capacidad de una empresa para mantener las ganancias y el
crecimiento a largo plazo.

Para gestionar con eficacia los productos y hacer frente a estas cinco fuerzas
de Porter sugiere que los gerentes de producto utilizan uno de los tres
siguientes estrategias:

1. La direccin general de costo. Mantener el costo ms bajo en el mercado.


2. Diferenciacin. Entregar los productos que los clientes creen que tienen una
posicin distinta o nica en el mercado. Esto se puede lograr mediante la
combinacin de varios otros factores, tales como la diferenciacin de marcas,
caractersticas nicas, garantas, o la calidad. Atencin.

3. Centrarse en nichos o segmentos limitados de servir eficientemente a las


necesidades de los clientes.

Es crtico que los gerentes de producto a tomar decisiones claras y estratgicas


en sus procesos de planificacin y desarrollo de productos para evitar ser
"atrapados en el medio" sin el liderazgo de precios clara, un producto
claramente diferenciado, o un enfoque distinto.

6.1.2 Innovacin

La innovacin es la ejecucin de un producto nuevo o mejorado, proceso,


mtodo de comercializacin, o mtodo organizativo en las prcticas
comerciales, la organizacin del lugar de trabajo, o las relaciones exteriores. El
Manual de Oslo [19] define cuatro tipos de innovacin:

1. Innovacin de producto. La introduccin de un bien o servicio con


caractersticas o usos previstos que sean nuevos o significativamente
mejorado, incluyendo mejoras significativas en el rendimiento o caractersticas,
componentes y materiales, software incorporado, facilidad de uso, u otras
caractersticas funcionales.

2. Proceso de innovacin. La implementacin de un mtodo de produccin


o suministro nuevo o significativamente mejorado. Esto incluye cambios
significativos en las tcnicas, equipo, y / o software. El cliente no suele pagar
directamente por este proceso, pero la novedad puede ser obligado a entregar
un producto o servicio y para gestionar las relaciones con las distintas partes
interesadas.

3. innovacin de marketing. La aplicacin de un nuevo mtodo de


comercializacin que implica cambios significativos en el diseo del producto o
en el envase, la colocacin de productos, la promocin del producto, o de
precio.

4. la innovacin organizativa. La ejecucin de nuevos mtodos en las


prcticas comerciales de la empresa, la organizacin del lugar de trabajo, o las
relaciones exteriores.

Es importante sealar que cualquiera de los tipos de innovacin lista de arriba


pueden dar lugar a una innovacin disruptiva, [20] un trmino acuado por
Clayton Christensen. Disruptiva se refiere al proceso de innovacin que
desplaza los productos arraigados en mercados establecidos para ofrecer un
valor dramtico a los interesados. Un ejemplo de una innovacin disruptiva ha
sido la aparicin de los medios digitales, que ha reemplazado a los CDs en la
industria de la msica y est transformando la industria del libro.

Independientemente de la industria, la innovacin consiste en proceso de


cambio de entrada y en el pensamiento. Y se trata de producir los resultados
que pueden ser ya sea radical o gradual, pero aparentemente darn lugar a
cambios en los procesos, productos, pensar, o modelos de negocio dentro de
las empresas.

El ciclo de vida de gestin de productos de gua en el proceso de cmo se


gestionan los productos en fases, desde la cuna hasta la tumba. Usando esto
como el proceso de base y la adicin de un embudo de la innovacin para
evaluar, calificar, y dar prioridad a las ideas produce resultados. El enfoque se
centra en la recoleccin, la categorizacin, priorizacin, la combinacin, y la
deteccin de ideas, y en la identificacin de opciones viables para poner en
prctica estas ideas.

La alineacin de los procesos de innovacin y gestin del producto es


esencial. Al alinear el proceso de la FMP, un gerente de producto puede
integrar las actividades de innovacin en el flujo de trabajo dentro de un
proceso de gestin de producto existente. Para recoger ideas, gerentes de
producto deben usar todas sus herramientas disponibles. Las empresas ms
exitosas e innovadoras utilizan mtodos antropolgicos para descubrir las
necesidades del cliente no articuladas y ganar puntos de vista penetrantes del
cliente. Estas necesidades deben ser bien comprendidos antes de cualquier
producto especfico puede ser construida. Todo el proceso se puede resumir en
cinco fases:

1. Puesta en escena. El grupo de innovacin estratgica es nominado, se


identifican los roles, los objetivos son determinados, y un proceso est
documentado.

2. Alinear. Esto es crtico. El equipo de la innovacin y la alta direccin


alinear el enfoque y el alcance de la iniciativa prevista.

3. Explorador. Esto es cuando se desencadena el proceso. Dependiendo


de las ideas generadas y su alcance, el equipo va a descubrir nuevas reas
para iniciar los cambios necesarios para la innovacin.

4. Creacin. Despus de la captura de puntos de vista, el equipo comienza


a perfilar los modelos de negocio o cambios de innovacin que se llevarn a
cabo.
5. Cartografa. Esta fase requiere la confeccin de itinerarios calendarios
detallados que documentan cundo se implementarn las ideas.

6.2 Procesos de Creacin de Valor

Un proceso de creacin de valor [21] es la forma en que el director de producto


y el equipo del proyecto se organizan en torno al trabajo que necesita ser
completado. Este proceso es cuando el equipo elige el proceso general para
definir las necesidades del mercado, que luego se rompen al mismo tiempo
hacia abajo en las especificaciones funcionales, diseo, desarrollo y
pruebas. Algunas de estas prestaciones puedan crearse en fases o
iteraciones. El plan podra usar una fase de diseo formal o una evolucin de la
arquitectura y el diseo de alto nivel. Las pruebas se puede hacer como parte
del proceso o se guarda para el final. La eleccin podra hacerse al prototipo
por un tiempo y luego disear las caractersticas, o la aplicacin podra hacerse
mediante la funcin, observando cmo evoluciona la arquitectura. [22] Por lo
general, los ingenieros llaman a estos ciclos de vida de desarrollo. Sin
embargo, desde una perspectiva de gestin de productos, la palabra "ciclo de
vida" puede ser confuso. Por lo tanto, lo mejor es nombrar estos procesos
basados en lo que hacen-crean valor para los clientes y
organizaciones. Histricamente, los gerentes de producto no han participado
en la eleccin de lo que se necesita proceso de creacin de valor para ofrecer
sus productos y ofrece al mercado; ms bien, por lo general dejan en manos de
los ingenieros o el departamento de calidad para decidir.

Cuando el gerente de producto no elige, el proceso de creacin de valor se


puede llenar de cambio, los retrasos y confusin en cuanto las demandas del
mercado y los compromisos de la fuerza de ventas limitaciones externas de un
proyecto que los equipos de desarrollo ms amplios, no eran conscientes de,
pero el gerente de producto esperado todo a lo largo. La forma de cambiar este
comportamiento es que el gerente de producto para definir mejor los criterios
de xito por adelantado y luego entender las limitaciones asociadas o
controladores (alcance frente programacin frente a los costos). Dicho de otra
manera, un gerente de producto debe definir por adelantado lo que hara que
el producto sea un xito en base tanto del mercado y objetivos de la
organizacin. Una vez definidos los criterios de xito, las limitaciones en el
gerente de producto y el equipo pueden ser entendidos. Slo entonces puede
una decisin basada en riesgos o negocio se har en lo proceso de creacin de
valor es el adecuado para la iniciativa.

Una palabra de advertencia: esto no est aconsejando a los gerentes de


producto para contar los ingenieros de cmo hacer su trabajo o ingenieros de
software de la forma de cdigo. Por el contrario, el propsito es entender el
contexto del proceso o procesos que estn siendo considerados para entregar
ese valor, y para tener un equipo de colaboracin decidir qu proceso que
tiene ms sentido. Tener todo el equipo a comprender mejor el contexto para el
proyecto y el producto final puede hacer toda la diferencia. Por ejemplo, el
proceso de creacin de valor elegido para un entorno de desarrollo de producto
sera diferente a la elegida para un entorno de fabricacin debido a que el tipo
de trabajo y las limitaciones son diferentes. Tabla 6-2 tablas de estas
diferencias y muestra cmo la eleccin de forma incorrecta podra llevar al
fracaso.

Tabla 6-1. La comparacin de fabricacin y desarrollo de productos


Consideraciones

Cada proceso de creacin de valor para el riesgo optimiza de forma


diferente. Hay tres tipos principales de procesos de creacin de valor: ". gil"
de serie, iterativos, e iterativos / incrementales, que la comunidad de software
normalmente llama [23] Sin embargo, se debe tener cuidado de no categorizar
todos los procesos iterativos incrementales / tan gil. En el desarrollo de
productos de software, gil se ha convertido en un cajn de sastre para el ciclo
de vida de las descripciones-y por lo tanto se puede usar mal o se aplica de
forma inadecuada. La tabla 6-2 muestra los diferentes procesos de creacin de
valor y cmo una prioridad de restricciones puede ayudar a elegir un gerente
de producto de un proceso.
Value Creation Engineering or Necessary
Process Type development Conditions for
name process success

Las siguientes secciones explicarn an ms los diferentes tipos de procesos


de creacin de valor, proporcionando los conocimientos previos necesarios
para elegir el ms adecuado.

6.2.1 Procesos de serie: Cascada y Fase-Gate

En un proceso de creacin de valor de serie, el equipo de producto se mueve a


travs de los pasos secuencialmente. El progreso se ve como que fluye
constantemente hacia abajo (como una cascada) a travs de las fases de
requisitos, diseo, desarrollo, verificacin, y de lanzamiento. La idea general es
que el equipo desarrolla u obtiene las exigencias del mercado en primer
lugar. Sobre la base de las necesidades del mercado, el equipo desarrolla los
requisitos del producto y realiza anlisis y diseo para determinar el sistema, o
"cuadro grande". Una vez que todos estn de acuerdo en el cuadro grande, el
equipo se inicia el desarrollo. Una vez completado el desarrollo, el equipo
integra todas las piezas y comienza la prueba final. Aunque no es necesario
para una fase para terminar antes de que comience la siguiente fase, la de una
sola phaseat- un tiempo de mentalidad es comn en la industria. El "modelo de
cascada" no modificado (Figura 6-2) muestra el progreso que fluye de arriba a
abajo.
Figura 6-2. De serie (o Cascada) Modelo

La serie o cascada, el proceso se origin en los entornos fsicos industrias de


manufactura y construccin altamente estructurados en la que despus de los
cambios de hecho son prohibitivamente costoso, si no imposible. procesos en
serie tambin se pueden encontrar en las industrias de dispositivos mdicos y
farmacuticos, en los procesos claros y ordenados deben ser documentados y
siguientes, y la trazabilidad clara se pueden asignar a garantizar la calidad y la
proteccin contra las auditoras de regulacin externa.

Para que quede claro, un proceso en serie no es un proceso de gestin de


proyectos. En cambio, es un proceso de desarrollo del producto y se debe
considerar una serie de pasos o tcnicas usadas para entregar el producto de
una manera en serie. Por lo general, los procesos de serie llevan ms tiempo,
ya que estn diseados para ser capaces de predecir cunto tiempo va a tomar
para implementar caractersticas, encontrar y corregir defectos, integrar piezas
del sistema, o para manejar los cambios de requisitos-actividades que son
inherentemente impredecibles. Sin una bola de cristal de trabajo, es imposible
predecir todo lo que necesita saber sobre el futuro.

En un proceso en serie, lo que tiene que dar ms tiempo para las tareas, como
una prueba del sistema final al trmino del proyecto, para compensar los
riesgos y problemas que no poda predecir el transcurso del proyecto.
[24] Podra tener sentido para permitir que este tiempo extra en el desarrollo,
en funcin del producto y de la situacin. Un proceso en serie puede ser
ventajoso desde el punto de vista de calidad, donde existen auditoras
externas. Porque permite para las lneas de demarcacin claras en el proceso
de desarrollo, se puede mostrar un auditor externo que un proceso paso a paso
de salida pensado claramente fue seguido antes de pasar a la fase de
desarrollo. El proceso en serie puede ser percibido como teniendo ms tiempo
en el desarrollo. Pero puede ahorrar tiempo total si acelera los procesos de
auditora y aprobacin externa.

Este proceso podra ser til en la industria de dispositivos mdicos, por


ejemplo, donde se requiere la aprobacin de la FDA. Para llegar a Go / No-Go
decisiones, un proceso conocido como serie formal de revisin phasegate
pueden interponerse en el plazo de una organizacin. El proceso de eliminacin
de la puerta normalmente revisar las prestaciones y los logros del proyecto
durante la fase de proceso relevante y colectivamente determinar si se debe
proceder a la siguiente fase. Las consideraciones sobre el ajuste estratgico, la
viabilidad tcnica, el riesgo, el atractivo del mercado y el posicionamiento
competitivo se van a utilizar sistemticamente en la toma de decisiones. Los
criterios de decisin representan los estndares de juicio la gestin y la toma
de decisiones y proporcionar orientacin en apoyo de su evaluacin del
contenido, la calidad y la coherencia en la toma de decisiones. Cuando una
revisin de la fase-puerta es completa, los miembros de los equipos
participantes recomiendan que el empresario tome una de las cuatro medidas
posibles: 1) continuar con la siguiente fase (GO), 2) cancelar el proyecto (no ir),
3) redirigir la proyecto basado en los cambios estratgicos o lagunas discutido
durante la revisin (reproceso), o 4) aplazar una decisin (espera). opiniones
de eliminacin de compuerta no son los mismos que los exmenes tcnicos,
arquitectnicos, o entregar, y no reemplazarlos, como exmenes tcnicos y
otros deben llevarse a cabo antes de la fase opiniones de puerta. Durante el
proceso de revisin de la fase-gate, los tomadores de decisiones hacen una
serie de preguntas clave, y examinan los elementos clave para pasar a la
siguiente puerta. Aqu hay unos ejemplos. El alineamiento estratgico - el
proyecto y el producto se ajustan a la estrategia de negocio. Mercado de un
tamao mnimo existe y seguir existiendo al momento del
lanzamiento. viabilidad tcnica es razonablemente probable - las zonas de
riesgo han sido identificados y las soluciones estn disponibles que pueden ser
razonablemente adquiridos por el proyecto. Existe una propuesta de valor del
producto o ventaja. Un plan de marketing existe para evitar los productos de
construccin o las capacidades del producto que carecen de un "ir al mercado"
estrategia y un plan. existe un retorno de la inversin aceptable de riesgo
ponderado. Medida en que el nuevo producto ofrece ventajas nicas, cumple
con las necesidades del cliente mejor que los productos competitivos, o
proporciona un valor superior para el dinero invertido existe. Estas
estimaciones deben surgir de pruebas reales con los clientes. Cmo fueron los
clientes involucrados con la evaluacin del producto? Cul fue su
reaccin? Qu criterios se utilizan para seleccionar el mejor
concepto? recursos relativos y experiencia del equipo en los proyectos de la
escala, complejidad y tecnologas suficientes para apoyar el esfuerzo de
desarrollo estn disponibles. La prueba ha sido completa y slida, lo que
garantiza un producto de calidad. No existen problemas de "show-tapn". Si lo
hacen, pueden ser mitigados? Y si es as, cul es el plan de mitigacin? Todos
los riesgos del proyecto y del producto se han comunicado con los planes de
mitigacin y contingencia apropiados. Todas las partes se han comunicado con,
y todas las partes estn de acuerdo con el plan y el enfoque para su
ejecucin. Puerta de revisin no estn destinados a ser discusiones
informales. Son reuniones de toma de decisiones de negocio crticos utilizados
para optimizar el rendimiento / cartera de productos, escrutar las inversiones
en desarrollo, y aumentar la calidad de la ejecucin del
desarrollo. Normalmente, es habitual que todos los materiales para el examen
de eliminacin de la puerta para ser distribuidos al menos una semana antes
de una reunin de revisin de puerta para permitir la revisin y consultas
adecuadas. Este material debe ser enviado desde el director del proyecto a los
miembros del comit de fase-gate. los

los miembros del comit de eliminacin de compuerta, como mnimo, deben


tener los siguientes representantes de funciones cruzadas: Calidad de
Fabricacin Ventas Legal Marketing Operaciones de Ingeniera Gestin de
proyectos de implementacin de gestin de producto Durante la reunin, el
equipo presentar el material y la informacin al comit de eliminacin de la
puerta, lo que demuestra que el equipo ha completado todos los entregables y
el trabajo necesarios y est listo para pasar a la siguiente fase. 6.2.2 iterativo
La idea bsica detrs del proceso iterativo es desarrollar un sistema de ciclos
repetidos (iterativo) en porciones ms pequeas (incremental). Con este
proceso, el desarrollador puede tomar ventaja de lo que se ha aprendido
durante el desarrollo de las versiones anteriores. En cada iteracin, el equipo
modifica el diseo y aade nuevas funciones. La mayora de los procesos
iterativos no requieren que las piezas del producto ser terminado al final de
cada ciclo de iteracin. Asimismo, no se requieren pruebas e integracin
concurrente. El objetivo general, desde una perspectiva de gestin de
productos, es obtener retroalimentacin de los clientes / usuarios con mayor
rapidez mediante la creacin y la obtencin de informacin sobre porciones del
producto en menos tiempo en lugar de esperar hasta que todo el sistema es
completo. La parte del producto que se muestra a un cliente debe poner de
relieve el problema y proporcionar una solucin que pueda ser entendido y fcil
de implementar. [25] Para guiar el proceso de iteracin, el gerente de producto
debe crear una lista de control de proyecto que contiene un registro de todas
las tareas que deben realizarse. Esta lista debe incluir elementos tales como
nuevas caractersticas para ser implementadas y las reas de la solucin
existente para ser rediseados. Durante el anlisis, el gerente de producto est
constantemente revisando la lista de control. Sin embargo, es posible que la
lista de control tambin puede estar administrado por un analista de negocio o
el director del proyecto en algunas organizaciones. El diseo e implementacin
de cualquier iteracin debe ser simple, sencillo, y modular, apoyando rediseo
en esa etapa o como se agrega una tarea a la lista de control de proyectos. El
Rational Unified Process (RUP) es un marco de software iterativo proceso de
desarrollo creado por el Rational Software Corporation, una divisin de IBM
desde 2003. RUP no es un solo proceso prescriptivo concreto, sino ms bien un
proceso de adaptacin destinada a ser adaptada por las organizaciones de
desarrollo y equipos de proyectos software que va a seleccionar los elementos
del proceso adecuado para sus necesidades. RUP se basa en un conjunto de
bloques de construccin, o elementos de contenido, que describen lo que se
produce, las habilidades necesarias requeridas, y la explicacin paso a paso
que describe cmo se lograrn los objetivos de desarrollo especficos. Los
principales bloques de construccin, o elementos de contenido, son los
siguientes: Roles (OMS) - conjuntos de habilidades relacionadas, competencias
y responsabilidades. Productos de trabajo (lo) - los resultados de una tarea,
incluyendo todos los documentos y modelos producidos mientras se trabaja a
travs del proceso. Tareas (cmo) - una unidad de trabajo asignada a una
funcin que proporcione un resultado significativo. Dentro de cada iteracin,
las tareas se clasifican en nueve disciplinas: seis disciplinas de ingeniera
(modelado de negocio, requisitos, anlisis y diseo, implementacin, prueba y
despliegue) y tres disciplinas de apoyo (configuracin y gestin del cambio,
gestin de proyectos, y medio ambiente). El proceso RUP tiene cuatro fases:
creacin, elaboracin, construccin y transicin. Estas fases permiten que el
proceso que se presentar en un nivel alto, similar a un proyecto de estilo de la
cascada, aunque la clave para el proceso se encuentra en las iteraciones de
desarrollo que se encuentran dentro de cada una de las fases. Adems, cada
fase tiene un objetivo clave y un hito en el extremo que denota el objetivo. En
la fase inicial, el gerente de producto establece un modelo de negocio que
incluye el contexto empresarial, factores de xito (ingresos era de esperar, el
reconocimiento del mercado, etc.), y una previsin financiera. Para
complementar el modelo de negocio, el gerente de producto, tambin genera
un modelo bsico de casos de uso, el plan del proyecto, la evaluacin inicial de
riesgos, y la descripcin del proyecto (los requisitos del proyecto bsico, las
restricciones y las caractersticas clave). Despus de que stos han concluido,
el proyecto est marcada por los interesados contra los siguientes criterios: la
definicin del alcance y de las estimaciones de costo / horario. la comprensin
de los requisitos del producto como lo demuestra la fidelidad de los casos de
uso principales. La credibilidad de las estimaciones de costo / horario,
prioridades, riesgos y proceso de desarrollo. Profundidad y amplitud de
cualquier prototipo arquitectnico que se desarroll. establecer la lnea de
base, para comparar los gastos reales y previstos. Si el proyecto no pasa este
hito, ya sea que se puede cancelar ni examinada de nuevo despus de haber
sido rediseada para satisfacer mejor los criterios. La fase de elaboracin es
donde el proyecto comienza a tomar forma. En esta fase, el equipo analiza el
dominio del problema y la arquitectura del proyecto toma su forma bsica. Esta
fase debe pasar el hito al cumplir con los siguientes resultados: Un modelo de
casos de uso completado 80% en los que se han identificado los casos de uso y
los actores y la mayora de las descripciones de casos de uso se desarroll. Una
descripcin de la arquitectura de software en un proceso de desarrollo del
sistema de software. Una arquitectura ejecutable que se da cuenta de casos de
uso de gran importancia arquitectnica. Revisado caso de negocios y listas de
riesgo. Un plan de desarrollo de todo el proyecto. Los prototipos que
demuestren que mitiguen cada riesgo identificado tcnica. Si el proyecto no
puede pasar este hito, todava hay tiempo para que pueda ser cancelado o
rediseado. Pero despus de salir de esta fase, el proyecto de transicin a una
operacin de alto riesgo donde los cambios son mucho ms difciles y pueden
ser perjudiciales. En la fase de construccin, la atencin se centra en los
componentes de desarrollo y otras caractersticas del sistema. Esta es la fase
en la mayor parte de la codificacin se lleva a cabo. En proyectos ms grandes,
varias iteraciones de construccin pueden ser desarrollados en un esfuerzo por
dividir los casos de uso en segmentos manejables que producen prototipos
demostrables. Las actividades de la fase de transicin incluyen la capacitacin
del equipo de los usuarios finales y las pruebas beta de apoyo y el sistema
para validarlo frente a las expectativas de los usuarios finales. El producto
tambin se compara con el nivel de calidad establecido en la fase inicial.

6.2.3 / Procesos giles incrementales iterativos, Scrum, Extreme Programming


(XP), y Lean

El concepto bsico detrs de los procesos / de tipo incremental de iterativo es


el desarrollo de un producto a travs de ciclos repetidos (iterativo) y en
porciones pequeas a la vez (incremental), permitiendo que el equipo para
tomar ventaja de lo que han aprendido durante el desarrollo partes anteriores o
versiones del sistema. El proceso se inicia mediante la entrega de un
subconjunto ms pequeo de los requisitos. Posteriormente, el equipo mejora
iterativa el producto basado en el cliente, las partes interesadas, y comentarios
de los usuarios y evoluciona las caractersticas y la funcionalidad completa
hasta que el sistema se implementa. Ms pequeas, versiones ms frecuentes
permiten a los equipos para entregar valor de negocio para el cliente con ms
frecuencia. Este proceso de la sonda-y-aprender tambin permite al equipo
para responder a entornos en los que los requisitos estn en constante
cambio. Cuando se habla de desarrollo iterativo e incremental, la iteracin
trminos de la subasta y no deben utilizarse como sinnimos. La iteracin se
refiere a la naturaleza cclica de un proceso en el que las actividades se repiten
de una manera estructurada. Incremento refiere al resultado cuantificable de
cada iteracin. Iteraciones pueden ofrecer un proceso de desarrollo de
refinamiento cclica, donde el proceso de mejora en lo que ya se ha hecho. El
desarrollo incremental va un paso ms all, donde los rendimientos del proceso
progresos en relacin con los objetivos globales de productos de la prxima
versin o una nueva versin del producto. Agile es un trmino genrico
utilizado para describir una serie de metodologas de desarrollo que comparten
principios comunes asociados con los procesos iterativos incrementales / y que
corresponden al Manifiesto de desarrollo de software gil. [26] Los mtodos
giles se centran en la satisfaccin del cliente y objetivos de la empresa, la
colaboracin en equipo, la comunicacin, la inspeccin frecuente, pequeas y
auto-organizacin de los equipos, la rendicin de cuentas, la transparencia, la
gestin visual, y la mejora continua. Como se mencion en la seccin 6.2, gil
puede ser utilizado de forma incorrecta a agrupar a un nmero de diferentes
procesos incrementales o hbridos juntos que no son verdaderamente
gil. Algunos procesos giles comunes incluyen Scrum, Extreme Programming
(XP), y el desarrollo de funciones-Driven. Este texto describir primero gil
desde una perspectiva de gestin de productos, a continuacin, describe cmo
se diferencia de otros procesos como Lean o verdadero
incrementales. enfoques giles asumen que el cambio es un fenmeno
generalizado y que la capacidad de un gerente de producto para predecir
correctamente en detalle cul es la mejor para hacer frente a las necesidades
del cliente es limitado. Por lo tanto, agilistas basan en el uso de un enfoque de
sonda-y-aprender que incorpora frecuente comentarios de los clientes. Como
resultado, los gerentes de producto que trabajan con equipos giles bien
dirigido disfrutan de una mayor visibilidad en el progreso de sus productos, una
mayor flexibilidad para ajustar el plan de producto sobre la base de nuevos
requisitos de informacin y emergentes, y de una calidad extremadamente
alta, cuando la unidad de pruebas automatizado se aplique plenamente. Los
que favorecen gil sienten que ofrece a los administradores la opcin de
productos para liberar pequeos incrementos de valor con mayor frecuencia y
les permite ejercer esta opcin si al hacerlo proporciona una ventaja
competitiva o un mejor retorno de la inversin. Dependiendo de cmo se
reparten los roles y responsabilidades, trabajando con un equipo gil puede
requerir ms profunda colaboracin y disciplina. profesionales giles creen que
el beneficio de hacer este compromiso de tiempo adicional es menos
sorpresas, desajustes, problemas de comunicacin,

y los retrasos en el extremo del ciclo de desarrollo. Las metodologas de


software gil Teora giles se construyen de manera diferente que los mtodos
secuenciales, tales como las que se encuentran en la industria
manufacturera. La industria manufacturera es adecuado para un modelo de
proceso definido: entradas definidas producen salidas definidas. Fabricacin
sobresale en repetir los mismos pasos para producir cerca de artculos
idnticos. metodologas de desarrollo de software tradicionales como la
cascada intenta asignar el desarrollo de software a un proceso definido,
secuencial (Figura 6-3).

Figura 6-3: Desarrollo de software tradicional supone un proceso secuencial


Definido

Los mtodos giles asumen escribir nuevo software es ms parecido a la


trayectoria no lineal que se encuentra en el desarrollo de productos nuevos
que el camino predecible de fabricacin. Desarrollo de nuevos productos
requiere la investigacin y la creatividad ambas actividades relativamente
impredecibles. desarrollo de nuevos productos por lo tanto se considera un
proceso emprico, con el equipo de ciclismo entre la creacin de conocimiento
y la identificacin de problemas (Figura 6-3). La mejor manera de manejar un
proceso emprico es a travs de la inspeccin y ajustarse con frecuencia.
[27] Agilistas creen que el desarrollo de software, que incluye la operacin de
gestin de producto de la recopilacin y validacin de requisitos, es el ms
adecuado para un modelo emprico.

Figura 6-4: Desarrollo de software sigue un proceso emprico

Requisitos

A travs del proceso gil, los requisitos funcionales se suelen escribir las
historias de usuario. Un formato comn para las historias de usuario es:.

Como <tipo de usuario>, quiero <hacer algo>, de modo que pueda derivar <a
benefit> [28]

La historia de usuario capta los aspectos ms importantes de un requisito: a


quin va dirigido, lo que estn tratando de lograr, por qu es importante para
ellos. La historia de usuario tambin acta como un marcador de posicin para
una conversacin ms profunda sobre el requisito. Durante esta conversacin
se aaden detalles a la historia. La historia de usuario no es una especificacin
de requisitos en el sentido tradicional del trmino. Esto apoya la creencia de
que Agilist la comunicacin cara a cara es la forma ms eficaz para crear una
comprensin compartida de un requisito entre el equipo de desarrollo y
accionistas de la empresa.

Estimacin y Planificacin

Una vez que una organizacin crea una visin para el producto, el equipo
desarrolla una lista de las necesidades del mercado y de producto. La lista se
prioriza comnmente por el valor del negocio, el riesgo y dependencias. La lista
priorizada de requisitos se suele llamar una pila de producto. El equipo de
desarrollo estima el esfuerzo relativo de cada requisito de la cartera de
productos. La mtrica habitual es un punto de la historia, pero en realidad
puede ser cualquier cosa. Por lo tanto, se espera que un rasgo estimado en 10
puntos de la historia para tomar el doble de tiempo para desarrollarse como
una caracterstica estimada en 5 puntos de la historia. [29]
Despus de cada iteracin, el equipo cuenta cuntos puntos de historia
complet. sta es la velocidad del equipo y una medida de su rendimiento. La
velocidad ahora se puede usar para estimar hasta qu punto el backlog del
producto estar en cada iteracin, as como cuntos puntos de historia el
equipo debe comprometerse a completar para la prxima iteracin.

Al saber cuntos puntos de la historia de la funcionalidad se planean para una


liberacin, el gerente del producto puede seguir el progreso en cada iteracin y
juzgar si la liberacin est en el horario usando un grfico de la quemadura
(una representacin grfica del trabajo que se deja hacer contra tiempo) .
Debido a que cada iteracin produce software de trabajo, el gerente de
producto puede ver el progreso real y detectar cualquier falta de comunicacin
al principio del proceso. Adems, cada iteracin permite al gerente de producto
ajustar el plan basado en el mejor conocimiento disponible. Por ejemplo, se
puede reducir el alcance para asegurar que se cumpla una fecha de
lanzamiento, se pueden agregar nuevos requisitos (Figura 6-7) y / o los
requisitos de la cartera de productos se pueden re-priorizar, ajustar,
reemplazar o eliminar.

Figura 6-5. Grfico de degradacin de lanzamiento gil

Esto ilustra que el alcance agregado en la iteracin tres requerir ajustar el


nmero de iteraciones necesarias para completar la liberacin y, en ltima
instancia, la fecha de lanzamiento.

Desarrollo Iterativo

Los equipos giles desarrollan software en iteraciones que generalmente van


de una a cuatro semanas. La iteracin abarca todas las fases del ciclo de
desarrollo, incluyendo la definicin, anlisis, diseo, cdigo y prueba del
producto. Cada iteracin produce una parte funcional del software que
normalmente se prueba y documenta. Al final de cada iteracin, se revisa el
progreso basado en el software creado en la iteracin y se actualizan el
backlog del producto y la liberacin de la versin.

Como se indic anteriormente, los equipos giles prefieren desarrollar software


en rodajas funcionales. Un corte funcional corta todas las capas del producto,
desde la interfaz hasta los niveles de lgica y datos. Un equipo de producto
que pasa un mes creando el nivel de datos, un mes creando el nivel lgico y
luego un mes creando la interfaz no se desarrollara de una manera gil. Sin
embargo, cada iteracin no puede producir cdigo rico y completo. Las
iteraciones tempranas slo pueden producir una pantalla de inicio de sesin o
la capacidad de crear un documento pero no editar o eliminar el documento.
Con el tiempo, con cada iteracin sucesiva, ms capacidad y pulido se acumula
en el producto hasta que est listo para ser lanzado al mercado.

Manejo visual

A menudo llamados radiadores de informacin, Agile hace hincapi en la


gestin visual para que los miembros del equipo y la administracin puedan
ver cmo progresan los proyectos y actuar rpidamente cuando sea necesario.
Adems de las listas de burndown, muchos equipos usan backlogs de
productos fsicos o electrnicos y tablas de tareas (Figura 6-6).

Figura 6-6. Un tablero simple de la tarea

En el tablero de tareas, las tareas comienzan a la izquierda. Cuando un


desarrollador empieza a trabajar en una tarea, aaden sus iniciales a la tarea y
la mueven a la columna "En curso". Cuando se completa la tarea, la mueven a
la columna "Listo". Las juntas pueden incluir columnas adicionales como
diseo, prueba, firma, etc.

Aunque el objetivo principal de la junta de tareas es ayudar al equipo a auto-


administrar el trabajo, tambin proporciona una visin rpida del estado de
cada requisito. El gerente de producto sabe qu requisitos estn en la cola, que
estn siendo trabajados, y que se han completado. Cuando aparece un
requisito en la columna "Hecho", el gerente de producto puede verificar
rpidamente que cumple con su intencin y plantea cualquier problema.

Scrum es un proceso gil que fue desarrollado a mediados de los aos 90 por
Jeff Sutherland, Ken Schwaber, Mike Beedle y otros. No especifica ninguna
prctica de desarrollo, pero para hacer que funcione para ellos, los equipos han
integrado de manera rutinaria algunas prcticas de XP como pruebas de
unidades automatizadas e integracin continua. Un equipo de scrum se
compone de lo siguiente:

Scrum Master - Asegura que la prctica del scrum es seguida y facilita para que
el equipo pueda identificar reas de mejora y eliminar los obstculos a su
progreso.

Product Owner - Responsable del xito del producto. El propietario del producto
gestiona y prioriza los requisitos de la cartera de productos para maximizar el
valor de los esfuerzos del equipo.

Equipo - Responsable de desarrollar el producto y hacerlo bien. El equipo est


compuesto por uno o ms desarrolladores y puede incluir otros roles (por
ejemplo, administradores de bases de datos, ingenieros de interaccin de
usuarios, ingenieros de garanta de calidad) necesarios para construir el
producto.

Los equipos contienen entre cinco y nueve personas. El equipo debe tener una
funcionalidad cruzada y tener todas las habilidades necesarias para
transformar los requisitos en la cartera de productos en software de trabajo.
Con Scrum, cuando se necesitan ms de nueve miembros del equipo, se
agrega un nuevo equipo en lugar de agregar al equipo existente. Equipos
menores de cinco tambin pueden trabajar. Pero debido a que la comunicacin
interpersonal tiende a dividirse en equipos mayores de nueve, es prudente
prestar atencin al lmite superior.

El desarrollo se produce en iteraciones, que en Scrum se conocen como sprints.


Los Sprints se definen como iteraciones con tiempo y protegidas que no duran
ms de 30 das.

Antes del primer sprint, se lleva a cabo una reunin de planificacin de


lanzamientos para establecer las metas y prioridades del producto para el
lanzamiento (que probablemente requerir varios sprints). Cada sprint se
estructura en torno a cuatro tipos de reuniones: planificacin, desarrollo,
revisin y retrospectiva:

Planificacin: decidir qu crear y crear requisitos (la lista de tareas necesarias


para completar las historias de usuarios que el equipo ha aceptado en el
sprint).

Desarrollo - la codificacin y las pruebas reales del producto. Esta es la fase


ms larga del sprint y representa aproximadamente el 85% de la iteracin.
Revisin - demostrar a los interesados lo que se construy en el ltimo sprint
para obtener retroalimentacin para la prxima reunin de planificacin (usted
necesita saber dnde debe saber qu construir a continuacin).

Retrospectiva - reflexionar sobre lo que funciona bien y lo que podra


mejorarse.

Figura 6-7. Scrum Diagrama de Proceso

Durante la fase de desarrollo, el equipo tiene una reunin diaria de pie de 15


minutos conocida como el Scrum diario. Durante el Daily Scrum, los miembros
del equipo comparten lo que hicieron desde la ltima reunin, lo que planean
hacer antes de la prxima reunin, y si algo est bloqueando su progreso. El
equipo tambin mantiene un grfico de Sprint burndown en horas para rastrear
y planificar su trabajo. Esto es similar al grfico de eliminacin de liberacin de
la Figura 6-7, excepto que incluye las horas de tarea restantes dentro de la
iteracin despus de cada da.

Programacin Extrema (XP)

Extreme Programming (XP) fue desarrollado por Kent Beck en 1996 mientras
trabajaba en un sistema de nmina de Chrysler. Describe a XP como una
"metodologa ligera para equipos de pequeo a mediano tamao que
desarrollan software frente a requisitos vagos o que cambian rpidamente".
[30] XP recibe su nombre al llevar los principios de desarrollo del sentido
comn a un nivel extremo. Si las revisiones de cdigo se consideran buenas
prcticas, XP recomienda realizar una revisin continua del cdigo
programando en parejas. Si las pruebas ayudan a producir cdigo sin errores,
XP aboga por escribir pruebas de unidad automatizadas que se ejecutan varias
veces durante el da y realizan frecuentes pruebas de usuario final y
funcionales. Si la refactorizacin ayuda a mejorar el cdigo, XP dicta que los
desarrolladores siempre buscan oportunidades para hacerlo. Si las pruebas de
integracin ayudan a descubrir problemas, el software completo de los
seguidores XP se compila una vez o varias veces al da.

XP comparte muchas similitudes con Scrum, pero no tiene roles formales como
el dueo del scrum y el propietario del producto. XP especifica prcticas de
desarrollo que abarcan pruebas, refactorizacin, integracin continua,
programacin de pares, diseo simple y normas de codificacin. Los equipos de
XP no descomponen las historias en tareas durante su fase de planificacin. Por
lo tanto, los equipos mantienen un punto de historia (en lugar de hora de la
tarea) grfico de burndown durante la iteracin.

Lean Development Los mtodos Lean derivan de los principios utilizados en el


Sistema de Produccin Toyota tcnico-tcnico integrado. James Womack, autor
del libro Lean Thinking, define a Lean como "creando cada vez ms valor para
los clientes con cada vez menos recursos". [31] Adems de la fabricacin, Lean
se ha aplicado a muchos otros campos, incluyendo servicios, desarrollo de
productos.

Similar a los mtodos Agile descritos en esta seccin, Lean aboga por un
enfoque en el cliente, la colaboracin, los equipos potenciados, la mejora
continua y los controles visuales. Los equipos lean se enfocan en el flujo
eficiente de valor a travs del sistema. De esta manera, Lean difiere de otros
mtodos Agile. Lean no utiliza una iteracin en tiempo para establecer la
cadencia del proceso de desarrollo.

El desarrollo Lean se centra en el flujo rpido y flexible, que busca optimizar la


entrega de valores reduciendo al mnimo las colas. Las colas se minimizan
trabajando en pequeos lotes. Los lotes pequeos se gestionan limitando la
cantidad de trabajo que puede fluir a travs del sistema a la vez (tambin
conocido como trabajo en curso, o WIP). Debido a que el equipo de desarrollo
no se extiende a travs de mltiples proyectos o grandes bloques de trabajo,
este enfoque crea tiempos de ciclo cortos. A medida que los tiempos de ciclo
se acortan, el sistema se aproxima al flujo de una sola pieza - el estado ideal
donde las partes se fabrican una a la vez y fluyen a lo largo de la cadena de
fabricacin y de suministro como una sola unidad.

Lean aborda muchos de los desafos del desarrollo tradicional de la cascada.


Uno de estos problemas es el desarrollo prolongado. Los defensores lean creen
que los ciclos de desarrollo largos ocurren porque todo trabajo para una
liberacin debe ser completamente definido o completado antes de pasarlo a la
siguiente fase. Cascada estimula grandes lotes de trabajo, generalmente
representando meses de desarrollo, gestionados a travs del sistema, lo que
puede crear grandes colas en cada etapa. En un entorno en el que los
requisitos estn cambiando rpidamente, el tpico mtodo de serie / cascada
puede reducir significativamente la capacidad del gerente de producto para
responder a nuevas oportunidades e informacin [33]. En estos entornos, Lean
puede ser un proceso que vale la pena considerar.

Lean tambin enfoca al equipo en la optimizacin de todo el sistema en lugar


de reas en el sistema. Debido a que es costoso, los planes de muchas
compaas estn diseados para asegurar el 100% de utilizacin de talento de
ingeniera. Los grandes lotes de trabajo estn en cola para los ingenieros.
Debido a que no hay holgura en este sistema, cualquier desviacin del plan
retrasa el proyecto y todos los proyectos detrs de l. Como resultado, las
fechas de lanzamiento varan ampliamente de un plan. Adems, la
retroalimentacin puede demorarse en este sistema. Un error en un requisito
no puede ser detectado hasta muchos meses despus durante el
aseguramiento de la calidad. Lo que habra sido una solucin rpida si se
detecta de inmediato puede convertirse en un proceso largo y complicado que
requiere reuniones, actualizaciones de documentos, cambios de cdigo y
reevaluacin.

Los equipos Lean emplean un tablero kanban [35], [36] en lugar de un tablero
de tareas. Las tablas de tarea y kanban parecen similares, pero donde el
tablero de tarea es para rastrear tareas, el tablero kanban se utiliza para
visualizar el flujo a travs del sistema y hacer cumplir los lmites de WIP. Del
mismo modo, los equipos Lean utilizan un diagrama de flujo acumulativo en
lugar de un grfico de burndown para seguir el progreso. El diagrama de flujo
acumulativo destaca la relacin entre WIP (cuntos elementos se estn
trabajando en cada momento), el tiempo de ciclo (cunto tiempo se tarda en
completar un artculo una vez que se inicia el trabajo) y el rendimiento
(cuntos artculos por semana O la unidad de tiempo se completan).

Hay muchos ms procesos iterativos e incrementales que los discutidos en este


breve tratamiento. Los gerentes de producto deben trabajar con sus equipos
para evaluar qu mtodo o mtodos funcionara mejor dada la cultura del
negocio, la naturaleza de los productos y la habilidad del equipo. La transicin
a gil requiere aprender y practicar nuevas habilidades para llegar a ser
competentes. Aunque el entrenamiento y el entrenamiento pueden acortar la
curva de aprendizaje y mejorar las posibilidades de xito, el equipo debe
decidir si los beneficios superan el tiempo necesario para aprender, practicar y
entrenar. Adems, la organizacin debe considerar si el costo de la transicin a
Agile para productos ms maduros con una esperanza de vida limitada justifica
el costo.

Captulo 7

Relacin de la Gerencia de Producto con Otras Disciplinas

El proceso de gestin de productos interacta naturalmente con varios otros


procesos. En la medida en que cada uno de ellos se involucre adecuadamente
en el ciclo de vida de la administracin del producto, es vital que todos
trabajen juntos para asegurar el resultado ptimo de la gestin del producto.
Aunque estas relaciones pueden entrar en juego en momentos especficos, los
mtodos y procesos de gestin de proyectos centrales se basan en todo el ciclo
de vida de la gestin del producto ya menudo proporcionan la plataforma de
ejecucin necesaria para llevar los productos al mercado. La Seccin 7.2
describe estos mtodos y procesos bsicos con mayor detalle y muestra cmo
integrarlos efectivamente en el marco de administracin del producto.

La gestin de programas y la gestin de carteras son dos procesos de gestin


relacionados con la gestin de proyectos con atributos y valor nicos cuando se
aplican al marco de gestin de productos. Las interrelaciones entre el proyecto,
el programa y la gestin de la cartera se describen en las secciones 7.6 y 7.7.

7.1 Una mirada ms cercana a los mtodos de gestin de proyectos y su


aplicacin dentro del marco de gestin de productos

La gestin de proyectos es la disciplina de planificacin, organizacin y gestin


de recursos para completar con xito las metas y objetivos especficos del
proyecto. As como este ProdBOK introduce un marco, existen marcos similares
en el mundo de la gestin de proyectos. Dos de los marcos ms destacados
son la Gua del Conocimiento de la Gestin de Proyectos (PMBOK),
desarrollada por el Project Management Institute (PMI) y una metodologa
conocida como PRINCE2 (PRojects IN Controlled Environments), desarrollada
por la Oficina de Comercio Gubernamental , Una oficina independiente del
Tesoro de Su Majestad del Reino Unido. El examen de cualquiera de estos
marcos es una forma til de entender los detalles de la gestin de proyectos: la
estructura, los mtodos y los procesos de sus componentes que comprenden la
disciplina general de la gestin de proyectos.

Dentro de casi cualquier marco de gestin de proyectos existen una serie de


mtodos y procesos individuales. El ms comn de stos, los mtodos y
procesos centrales de gestin de proyectos, se identifican y se describen
brevemente en la seccin 7.2. Las secciones 7.3 a 7.5 identifican maneras en
que estos mtodos y procesos pueden ser usados o adaptados para soportar
las tres etapas principales del desarrollo exitoso de productos: concepcin (la
parte delantera difusa), desarrollo de producto y comercializacin /
operaciones.

La Gua PMBOK y PRINCE2 se utilizan comnmente para apoyar los esfuerzos


de gestin de proyectos dentro de una organizacin o para gestionar el ciclo de
vida de un proyecto. Estos dos documentos abordan la gestin de proyectos
desde diferentes perspectivas. A pesar de algunas diferencias en terminologa,
tienen un hilo comn en trminos de mtodos y procesos. Los mtodos y
procesos de gestin de proyectos permanecen relativamente constantes. Sin
embargo, no todos los proyectos necesitarn ejecutar la gama completa de
procesos en cada grupo de procesos. Al identificar los mtodos y procesos
centrales, independientemente del enfoque, se puede establecer una base
para usar la gestin de proyectos de manera eficaz en el ciclo de vida de la
gestin de productos.

El tipo de proyecto, producto y cultura de una organizacin determinar el tipo


de proceso que se utilizar, pero los grupos de procesos bsicos de iniciacin,
planificacin, ejecucin, control y cierre son comunes en muchos estndares de
gestin de proyectos. La aplicacin de la gestin de proyectos en el proceso de
gestin de productos puede aumentar la productividad, mejorar la calidad de
produccin, crear un uso eficiente de los recursos y acelerar el tiempo de
comercializacin.

La gestin de proyectos se compone de un conjunto de procesos relacionados


que pueden aplicarse eficazmente al ciclo de vida de la gestin de productos.
La aplicacin lgica de la gestin de proyectos y los niveles de rigor adecuados
dentro del ciclo de vida de la gestin del producto pueden producir resultados
muy positivos y mejorar los esfuerzos de un gerente de producto. Un enfoque
bien pensado para utilizar las herramientas y tcnicas de gestin de proyectos
ayudar a un gerente de producto a utilizar eficazmente los recursos de la
organizacin y agregar estructura, estandarizacin y previsibilidad a los
proyectos de desarrollo y mejora de productos.

De acuerdo con PMBOK, PRINCE2 y otros estndares de gestin de proyectos,


[37] el director del proyecto tiene la responsabilidad general del proyecto. Para
lograr el xito, el director del proyecto debe trabajar estrechamente con el
patrocinador del proyecto en cuanto a los requisitos de personal y la
disponibilidad de fondos. El director del proyecto es responsable de completar
el proyecto a tiempo, dentro del presupuesto y cumplir con los requisitos
predefinidos, incluido el rendimiento y la calidad.

El director del proyecto debe ser asignado lo ms pronto posible en el ciclo de


vida, idealmente al inicio del proyecto, para establecer la responsabilidad del
proyecto y la gestin y comenzar a desarrollar los requisitos del proyecto. A
menudo hay un beneficio aadido en la asignacin de dominios de productos
especficos a un administrador de proyectos: puede permitir que el
administrador del proyecto acumular conocimientos adicionales sobre un
producto o grupo de productos en particular y aumentar tanto la experiencia
del dominio y la eficiencia del equipo durante su participacin.

7.2 Mtodos y procesos bsicos de gestin de proyectos

La gestin de proyectos, ya sea siguiendo PMBOK o PRINCE2, utiliza un


conjunto comn de procesos, herramientas y tcnicas para alcanzar los
objetivos de un proyecto. Esta seccin describe brevemente estos mtodos y
procesos.
En el nivel general del proyecto, los mtodos y procesos se subdividen en cinco
categoras de alto nivel, o grupos de procesos principales. Los grupos de
procesos son iniciacin, planificacin, ejecucin, control y cierre. Estos procesos
se asocian generalmente con las actividades que se encuentran en cada fase
del ciclo de vida de un proyecto. Por ejemplo, independientemente del nmero
de fases que se encuentren dentro del ciclo de vida de un proyecto, cada fase
se inicia, planea, ejecuta, controla y cierra. Esta aplicacin de los procesos de
gestin de proyectos bsicos proporciona un nivel de coherencia a lo largo del
ciclo de vida del proyecto.

7.2.1 Mtodos y procesos utilizados en la iniciacin del proyecto

El trmino iniciacin generalmente se refiere a las actividades asociadas con la


definicin y aprobacin de un nuevo proyecto o la determinacin de si un
proyecto debe continuar en la fase / etapa siguiente, ya que la fase actual est
a punto de finalizar. Tpicamente, los mtodos y procesos centrales incluyen:

Identificar el patrocinador del proyecto - Determinar la fuente de


financiamiento para el proyecto.

Revisar el caso de negocios - Revisar el desempeo financiero proyectado, la


factibilidad del proyecto y la conexin con la estrategia empresarial.

Elaborar una carta de proyecto - Preparar un documento de alto nivel que


describa el proyecto, los riesgos previstos, las principales partes interesadas,
los principales hitos, las limitaciones y los lmites.

Realizar una reunin inicial - Proporcionar al equipo del proyecto informacin


sobre el proyecto y prepararse para desarrollar planes detallados.

Establecer lneas de base del proyecto - Las lneas de base asociadas con el
costo, el cronograma, el tiempo y la calidad (rendimiento) del proyecto se
utilizan para medir la efectividad de la ejecucin de un proyecto. Como
resultado del desempeo de la unidad en comparacin con estas lneas de
base, el equipo del proyecto puede proponer contingencias aceptables y
tampones para asegurar que el cambio pueda ser manejado con xito dentro
de las limitaciones generales del proyecto.

Aprobar el siguiente plan de fase - La iniciacin tambin se refiere a la decisin


de permitir que un proyecto contine en la siguiente fase. Las revisiones
generalmente se programan en o cerca de la terminacin de una fase del
proyecto. La revisin es una evaluacin del desempeo del proyecto. Las
revisiones de rendimiento incluyen una comparacin entre los resultados reales
y las lneas de base aprobadas. La variacin del plan, la variacin del costo, los
cambios de alcance, las variaciones de calidad, el riesgo, la realizacin de
beneficios y otros factores se consideran para determinar si la organizacin
debe continuar apoyando el proyecto.

-----

7.2.2 Mtodos y procesos utilizados en la planificacin del proyecto

La planificacin del proyecto incluye un conjunto de procesos que detallarn


cmo se implementar el proyecto y quin realizar las actividades. La
planificacin del proyecto consiste en definir el alcance del proyecto y las
acciones que deben realizarse para alcanzar los objetivos establecidos. Los
procesos de planificacin bsicos suelen incluir:

Definir el alcance del proyecto - Crear una descripcin detallada del trabajo que
debe completarse para producir el producto deseado y desarrollar una
declaracin de alcance del proyecto o una declaracin de trabajo. Este
documento proporciona una base para una planificacin ms detallada.

Implementar una estructura de desglose de trabajo - Desglosar el alcance


definido del proyecto de trabajo en ms detalle, asegurando que el proyecto se
presenta de forma clara y completa. Esto proporciona la base para determinar
las estimaciones de costo y duracin de la actividad del proyecto. Tambin se
utiliza para controlar los cambios en el alcance del proyecto.

Desarrollar el calendario - Colocar las actividades del proyecto definidas en la


estructura de desglose del trabajo en una secuencia lgica, determinar las
necesidades de recursos, estimar las duraciones de las actividades, identificar
la ruta crtica del proyecto, refinar el calendario para cumplir con los requisitos
e identificar dnde hay flojedad del proyecto.

Determinar el presupuesto del proyecto - Producir un costo total estimado para


el proyecto determinando los costos de cada actividad y agregando todos los
costos para crear una lnea de base.

Calidad del plan - El nivel de calidad asociado con el proyecto afectar el costo,
el calendario y las decisiones sobre el tipo de recursos que se pueden utilizar.
La calidad (rendimiento del proyecto) debe planificarse al principio. El producto
asociado con el proceso se denomina plan de calidad. Este plan se basa en los
requisitos del proyecto y en los criterios de xito y describe cmo se validar la
conformidad con los requisitos y cmo se evitarn los errores del producto y
del proyecto.

Plan de comunicaciones - A medida que los proyectos se ejecutan y los


resultados se informan, los interesados del proyecto requieren informacin
actualizada sobre cmo el proyecto est realizando. La planificacin de las
comunicaciones del proyecto generalmente incluye: Identificar y analizar a los
interesados del proyecto Determinar las necesidades de informacin de cada
interesado Decidir los mtodos para recopilar y distribuir informacin
Establecer qu informacin se proporcionar a los interesados del proyecto y el
detalle y la frecuencia con la que se proporcionar la informacin

Implementacin de la gestin de riesgos - Un proceso que es paralelo a todos


los dems procesos de planificacin. La gestin de riesgos cuantifica la
incertidumbre. Durante la planificacin del proyecto, el equipo del proyecto
debe considerar las incertidumbres asociadas con todas las facetas del
proyecto, tales como:

-Decidir los mtodos para recopilar y distribuir informacin

- Inexactitudes en la estimacin de la duracin de la actividad y los costos

-La cultura (s) asociada con la entrega del proyecto

-Cambios en los procesos organizativos

-Factores externos, como el potencial de cambios regulatorios

-La utilizacin de recursos internos versus externos y el impacto relacionado en


los gastos de capital

-La economa

La gestin de riesgos incluye la identificacin de posibles eventos de riesgo, la


priorizacin de eventos de riesgo mediante un anlisis detallado, la
planificacin de estrategias de respuesta y la determinacin de cmo controlar
el riesgo durante todo el ciclo de vida del proyecto.

7.2.3 Mtodos y procesos utilizados en la ejecucin, supervisin y control del


proyecto

La ejecucin, el monitoreo y el control del proyecto consisten en asegurarse de


que el calendario del proyecto y otras medidas de xito de lnea de base, como
costo, alcance y calidad, cumplan los requisitos. Los principales mtodos y
procesos de ejecucin y control de proyectos incluyen:
Verificacin del trabajo completado - A medida que se completa el trabajo y se
producen los resultados, se realiza una evaluacin para determinar si el trabajo
y la entrega son aceptables.

Gestin de solicitudes de cambio - Se establece un proceso de control de


cambios durante la planificacin detallada del proyecto. Es necesario
administrar el cambio para evitar agregar trabajo al plan del proyecto, creando
una situacin desfavorable conocida como "fluencia del alcance". Un proceso
de control de cambios ayudar a minimizar los costos asociados con el cambio
y mantendr al equipo del proyecto enfocado en los objetivos.

Realizacin de revisiones de garanta de calidad - Se realizan revisiones de


calidad o auditoras de calidad peridicamente durante el ciclo de vida del
proyecto para identificar reas de desempeo que muestren variaciones o
desviaciones de las lneas de base originales establecidas durante la iniciacin
y planificacin. Estas auditoras y revisiones son mecanismos de
retroalimentacin diseados para ayudar a que los proyectos vuelvan a estar
dentro de parmetros de desempeo aceptables.

Adquisicin de recursos del proyecto - A medida que se ejecuta el plan del


proyecto, el administrador del proyecto y el equipo obtendrn los recursos
identificados en el plan. Los recursos pueden incluir personas, mquinas,
herramientas y equipo. Adquisicin de bienes y servicios - A menudo es
necesario obtener servicios

Adquisicin de bienes y servicios - A menudo es necesario obtener servicios y


recursos de proveedores externos. La adquisicin puede incluir decisiones de
compra o de compra, solicitudes de propuestas y negociaciones para
determinar los trminos y condiciones del contrato.

Gestin de variaciones - Durante la ejecucin del plan, se analizan las mtricas


del proyecto y los resultados del trabajo y se descubren desviaciones en todos
los proyectos, excepto en los ms triviales. Estas desviaciones se pueden
interpretar como favorables (por ejemplo, antes de lo previsto) o desfavorables
(por ejemplo, sobre el presupuesto). Una excelente tcnica para medir la
varianza, aunque no se utiliza comnmente, es la gestin del valor ganado. La
gestin del valor acumulado compara los resultados planificados y los reales
para determinar si existen variaciones y la magnitud de su magnitud. Las
acciones correctivas se toman sobre la base del anlisis de la varianza.
Gestin de las expectativas de las partes interesadas - Las necesidades de
informacin de las partes interesadas del proyecto variarn en funcin del
inters de las partes interesadas en el proyecto y de su autoridad. Durante la
planificacin, el gerente de proyecto y el equipo generalmente desarrollan un
plan de comunicaciones para difundir informacin de misin crtica a todos los
interesados apropiados.

Seguimiento y gestin del riesgo - El riesgo del proyecto est presente desde el
inicio del proyecto hasta su finalizacin. La gestin del riesgo es un proceso
que incluye la identificacin de posibles eventos de riesgo, la identificacin de
los sntomas de riesgo o desencadenantes, la priorizacin de los riesgos, la
determinacin de la respuesta ms eficaz a una situacin de riesgo y el control
y control de nuevos riesgos que puedan surgir. El control de riesgos tambin
aborda los riesgos que se han mitigado pero que pueden reaparecer Como una
amenaza para el proyecto. Esta es la fase en que se usan comnmente los
planes de contingencia y las estrategias de mitigacin.

7.2.4 Mtodos y procesos usados en el cierre del proyecto

Los procesos de cierre llevan la fase del proyecto o del proyecto a una
conclusin organizada y bien planificada. Los mtodos y procesos centrales
incluyen:

-Conduccin de las revisiones finales del proyecto - Una vez completado el


proyecto y todos los resultados, el director del proyecto lleva a cabo una
revisin posterior al proyecto para analizar el desempeo general del proyecto
y los entregables, as como los proveedores y contratistas involucrados.
Aunque es comn que el equipo documente las lecciones aprendidas e
identifique reas de mejora en este momento, es preferible documentarlas e
identificarlas con ms frecuencia a lo largo de las fases del proyecto ya medida
que se ejecutan los procesos. Esto es aconsejable porque si el equipo espera
hasta el cierre:

-Puede olvidar informacin importante desde el principio del proyecto.

-Los beneficios de la mejora de procesos pueden realizarse inmediatamente y


no en el prximo proyecto.
- El personal clave, que puede tener un conocimiento importante del proyecto,
puede no estar con el proyecto durante la fase de cierre.

Cierre de todas las cuentas financieras - En algunos casos, los proyectos


tendrn un sistema de contabilidad que identifique la fuente de financiamiento
y cmo se procesan los cargos. Al finalizar el proyecto, se realiza una
contabilidad final y las cuentas asociadas al proyecto se cierran para evitar
cargos adicionales a las cuentas.

-Completar y cerrar todas las adquisiciones. Muchos proyectos incluyen


contratistas y subcontratistas. El trabajo es a menudo subcontratado y las
rdenes de trabajo son procesadas. La adquisicin tambin incluye la compra
de materiales y el pago de cuentas. Al finalizar el proyecto, el gerente de
proyecto y el equipo revisan todas las compras, servicios contratados, rdenes
de trabajo y otros artculos de adquisicin, incluyendo trminos y condiciones
del contrato, y arreglan la terminacin de acuerdo con los procedimientos de la
organizacin.

7.3 Aplicacin de la gestin de proyectos durante la fase de


concepcin ("Fuzzy Front End")

La gestin de proyectos puede utilizarse eficazmente en lo que comnmente se


conoce como la etapa de concepcin o ideacin de un proyecto - el "fuzzy front
end" del proceso de gestin de productos. La gestin de proyectos se considera
generalmente un proceso regido y lgico. Si esta naturaleza regulada se inclina
hacia la inflexibilidad, podra haber problemas si se implementa
incorrectamente en el front-end dinmico de la administracin del producto.
An as, hay muchas ventajas en el uso de los procesos centrales de gestin de
proyectos a principios del ciclo de vida de la gestin del producto.

En la mayora de las organizaciones, la administracin del producto es


responsable de crear un nuevo producto o mejorar un producto o servicio y
llevar mejoras al mercado. Hay dos caminos paralelos implicados en este
proceso. El primero implica la generacin de ideas, el diseo de productos, la
ingeniera detallada, el desarrollo, las pruebas y la entrega o despliegue. El
segundo implica la investigacin de mercado y el anlisis de la
comercializacin. Cada uno de estos caminos es importante y puede
beneficiarse del enfoque estructurado de la gestin de proyectos. El desarrollo
de nuevos productos y el proceso de gestin de productos son fundamentales
para el crecimiento de una organizacin y en realidad forman parte de los
procesos estratgicos de alto nivel de la gestin del ciclo de vida del producto.
La comunicacin de las partes interesadas, las frecuentes revisiones
interdisciplinarias y las aprobaciones importantes del proceso de gestin del
proyecto pueden mejorar la calidad del producto, aumentar la rentabilidad,
mejorar el tiempo de comercializacin y aumentar la eficiencia del uso de los
recursos de la organizacin. El extremo delantero difuso es el punto de partida
a menudo desorganizado, a veces desordenado o perodo de arranque del
proceso de desarrollo de nuevos productos. Es el momento en que una
organizacin desarrolla ideas para nuevos productos, formula un concepto del
producto o productos a desarrollar, y decide si invertir en el desarrollo de la
idea.

Durante este tiempo, cuando las ideas fluyen y las interpretaciones de los
diseos, las necesidades del cliente y las necesidades del negocio varan,
puede ser difcil utilizar un conjunto de herramientas y tcnicas definidas. Pero
sin ellos, el extremo delantero borroso puede ser prolongado y
extremadamente costoso. En la mayora de las organizaciones, hay recursos
limitados, tiempo y dinero disponibles; Por lo tanto, es necesario un proceso
para mantener al equipo enfocado en generar un resultado significativo. El
extremo delantero borroso termina realmente cuando una organizacin
aprueba y comienza el desarrollo formal del concepto.

Normalmente, un proyecto se organiza en fases. Cada fase tiene actividades


especficas, resultados y entregables. Involucrar a los directores de proyectos
temprano en el ciclo de vida puede ayudar a identificar las actividades crticas,
los resultados y los resultados antes y puede maximizar la eficacia del proyecto
global y hacer que la entrega del producto al cliente sea ms eficiente.

1. Establecer objetivos - Determinar o definir criterios de xito


mensurables, establecer objetivos y comunicar objetivos estratgicos
para mejorar la eficiencia de los recursos involucrados, proporcionando
informacin sobre cmo las acciones afectan a todo el negocio.
2. Gestin del mbito - En el extremo frontal difuso, se estn generando
ideas. La gestin del alcance puede ayudar a administrar la generacin
de ideas o la conceptualizacin manteniendo al equipo centrado en las
prioridades y minimizando el potencial para ir ms all del problema
definido o el rea de oportunidad.
3. Gestin de riesgos - El desarrollo de ideas y la conceptualizacin pueden
verse obstaculizados por reglas y restricciones, pero la creatividad sin
algunos elementos de control podra conducir a un desastre. La gestin
de riesgos puede minimizar el desperdicio, eliminar situaciones
inseguras y prevenir acciones que podran poner en peligro las
operaciones.
4. Proceso de informe de estado - Mantener a todas las partes interesadas
involucradas y en sincrona con las actividades del equipo y el progreso.
En el extremo delantero borroso, puede parecer difcil aplicar las tcnicas
bsicas de gestin de proyectos. El entorno nico de la parte delantera
borrosa, donde la estructura y la disciplina parecen fuera de lugar, puede
dificultar la aplicacin de herramientas y tcnicas. Sin embargo, las personas
involucradas en esta etapa deben darse cuenta de que los recursos no son
ilimitados y hay objetivos estratgicos especficos asociados con la gestin y el
desarrollo de un producto.

Tambin hay un tremendo valor en tener al gerente del proyecto involucrado


desde el principio para asegurarse de que el plan es realista y que tienen una
comprensin completa del resultado deseado. Las organizaciones a menudo
asumen que ciertos aspectos crticos de un proyecto son bien conocidos, pero
esto no es frecuente. Estas suposiciones pueden retrasar el impulso del equipo
mientras que el encargado de proyecto que llega tarde llega a la curva de
aprendizaje. Un gerente de proyecto que se ha comprometido desde el
principio tambin puede ayudar a proporcionar la continuidad de la
comunicacin a medida que el proyecto cambia de la concepcin a la
ejecucin.

7.4 Aplicacin de la gestin de proyectos durante el desarrollo de


productos

El desarrollo de productos puede tener definiciones diferentes dependiendo de


la industria y los procesos internos utilizados por una organizacin. Despus de
la fuzzy front-end, el ciclo de vida del producto incluye las siguientes fases:
Planificar, Desarrollar, Calificar, Lanzar, Entregar y Retirarse. El uso de procesos
de gestin de proyectos durante las fases de Desarrollo y Lanzamiento puede
mejorar significativamente la probabilidad de entregar un producto que
funcione como se planific y de introducirlo con xito en el mercado. Durante la
fase de Desarrollo, el producto se somete a revisiones, verificacin de
requisitos y cambios introducidos a travs de nuevas oportunidades y cambios
en las condiciones del mercado o las solicitudes de los clientes.

Los mtodos y procesos de gestin de proyectos ayudarn al gerente de


producto a travs de esta fase, asegurando que las tareas planificadas se
completan y estableciendo un proceso aprobado para gestionar el cambio. A
medida que el producto se desplaza a travs del ciclo, entrar en el ciclo de
vida del proyecto y estar sujeto y beneficiar de las herramientas, tcnicas y
procesos descritos anteriormente en esta seccin.

La aplicacin de mtodos y procesos de gestin de proyectos suele ser esencial


para el xito de la entrega de un nuevo producto.

Durante la fase de Desarrollo se pueden realizar las siguientes actividades:


Prototipado rpido
Diseos speros y prototipos finales
Diseo mecanico
Planificacin de diseo y montaje de ingeniera
Planificacin para la fabricacin de componentes del producto
Montaje y prueba del producto
Cumplimiento de los estndares
Optimizacin de costes
Revisiones de calidad
Publicar documentos del producto
Planificacin de contingencias

La administracin del proyecto proporciona mtodos para administrar cada


una de estas actividades a travs del proceso bsico descrito en 7.2.

Otra variable en los esfuerzos de desarrollo de productos es el nivel de


desafo tecnolgico, que a veces se expresa en trminos de "probabilidad
de xito tcnico". A medida que crece el desafo tecnolgico, aumenta el
nivel de incertidumbre. Muchos de los principios descritos anteriormente se
aplican aqu, con respecto a la eleccin de los mtodos y enfoques de
gestin de proyectos. Por ejemplo, en proyectos que requieren una cantidad
sustancial de avance (tambin llamado descubrimiento), es comn
reconocer que pueden ser necesarios varios ensayos para lograr el objetivo.
En este caso, el desarrollo de un programa de proyecto requiere el uso de
un nmero de iteraciones para modelar adecuadamente la realidad
prevista.

7.4.1 Actividades de Gestin de Proyectos en la Fase de Desarrollo

Cada fase de un proyecto tiene un conjunto distinto de actividades y


procesos aplicados para asegurar que siga avanzando. Los procesos o
actividades tpicas realizadas durante esta fase incluyen:

Desarrollar actualizaciones y reportes de estado


Realizar reuniones y conferencias telefnicas para revisar el progreso
e identificar problemas
Creacin de actas de reuniones y otra documentacin del proyecto
Implementacin del proceso de control de cambios
Gestin de los recursos del proyecto, incluida la reasignacin
Realizacin de revisiones de presupuesto de proyectos y reportes de
desviaciones
Calendario de monitoreo y eficiencia en el uso del tiempo
Uso de una aplicacin de software de gestin de proyectos
empresariales para el seguimiento de proyectos
La fase de desarrollo del ciclo de vida de la gestin de productos
proporciona el entorno ms natural para aplicar los procesos y mtodos de
gestin de proyectos. El equipo ha definido el producto, identificado los
recursos, establecido un presupuesto y definido los requisitos. Habr
cambios y problemas, y surgirn nuevos riesgos. La gestin de proyectos
proporciona la gobernanza que mantiene el flujo de trabajo y los procesos
para determinar el rendimiento del proyecto y del producto.

7.5 Gestin de Proyectos en Comercializacin / Operaciones

La gestin de proyectos tambin puede desempear un papel valioso


despus del desarrollo del producto, en la comercializacin del producto y
en las operaciones en curso. La clave para desarrollar una apreciacin del
papel til de la gestin de proyectos en estos dos mundos es reconocer que
muchos de los elementos de proceso encontrados en esas etapas del marco
de gestin de productos pueden configurarse como proyectos.

7.5.1 Potenciales "Proyectos" Relacionados con la Comercializacin


de Productos

Los gerentes de producto deben prepararse adecuadamente para el


lanzamiento eventual de su producto y para el nmero significativo de
actividades que ocurren despus. Algunas de estas actividades son tan
grandes y complejas que pueden caracterizarse legtimamente como
proyectos. Algunos ejemplos notables son:

Seguimiento y medicin de las mtricas de rendimiento reales


relacionadas con el (los) producto (s)
Creacin de un plan para gestionar la futura cadena de suministro
Desarrollar un plan que coordina todos los aspectos del lanzamiento
de un producto
Tratar la implementacin del marketing mix como un proyecto
Planes de construccin para abordar el servicio relacionado con el
producto y el trabajo de garanta
Formacin inicial de socios de canal y personal de ventas

7.5.2 Potenciales "proyectos" relacionados con las operaciones en


curso

A veces, los gerentes de producto deben asegurarse de que la etapa de


operaciones en curso despus del lanzamiento del producto ha sido
planeada adecuadamente, o que han desarrollado un plan de gestin
operacional a largo plazo y lo han implementado en el momento adecuado.
Al igual que con la comercializacin de productos, muchas de estas
actividades podran ser bastante complejas y, por consiguiente, podran
configurarse como proyectos. Es importante aclarar que la parte del
proyecto es la implementacin de estas actividades, en oposicin a
cualquier operacin en curso de cada actividad.

Los ejemplos pueden incluir:

Elaboracin de metodologas just-in-time o lean manufacturing


Implementacin de esfuerzos de mejora de valor, como ingeniera de
valor, anlisis de valor y correlacin de flujo de valor
Considerando la disponibilidad operativa como un proyecto
Trabajar para optimizar la cadena de suministro
Desarrollo e implementacin de un plan de mantenimiento para
equipos operativos
Tratar la formacin del personal de operaciones (operadores, personal
de mantenimiento, etc.) como proyecto
Creacin e implementacin de un sistema o proceso de gestin de
inventario

7.6 Cmo se relaciona la gestin del programa con la gestin de


productos

La mayora de las organizaciones identifican y gestionan los programas


como parte de la actividad empresarial. Un tipo de programa es un grupo
de proyectos relacionados coordinados para lograr beneficios y control que
no podran surgir de la gestin de cada proyecto por separado.

Los programas se producen con frecuencia en la gestin de productos. Una


manifestacin comn de un programa es toda una coleccin de proyectos
orientados al producto. Aqu, es probable que el programa sea una
combinacin de investigacin y desarrollo, preparacin operativa,
comercializacin y otros proyectos relacionados relacionados con uno o ms
productos. Muchas empresas, por ejemplo, han sabido introducir un
conjunto de productos dentro de una sola iniciativa coordinada, un
programa.

Entre los desafos ms grandes en el manejo exitoso de programas de esta


naturaleza est la coordinacin efectiva simultnea de proyectos
individuales. La duplicacin del esfuerzo, los descuidos, el fracaso en la
gestin de las interacciones y el fracaso en aprovechar las economas de
escala son desafos comunes. De hecho, estos desafos son muy probables
que ocurran en situaciones donde mltiples gerentes de producto y / o
mltiples unidades de negocios estn participando.
Estos problemas pueden ser abordados efectivamente para prcticamente
cualquier programa mediante la introduccin de estos tres elementos
relacionados con la disciplina de la gestin de proyectos:

Principales mtodos y procesos de gestin de proyectos a nivel de


programa
Prcticas de gestin de programas de sonido
Personal dedicado a la gestin de programas

7.6.1 Mtodos y procesos bsicos de gestin de proyectos a nivel de


programa

Mediante la aplicacin de los mtodos y procesos detallados en la Seccin 7.2,


los gerentes de producto pueden agregar estructura, organizacin y control a
una coleccin de proyectos interrelacionados, obtenindose a menudo un
resultado de programa ms exitoso.

Durante la planificacin del programa, los mtodos y procesos de gestin de


proyectos pueden utilizarse para:

-Identificar las interacciones de proyecto a proyecto (a nivel de tarea)

-Desarrollar el programa general del programa Estimacin del costo total del
programa

-Identificar y evaluar los riesgos e incertidumbres de los programas

Durante la ejecucin del programa, los mtodos y procesos centrales de


gestin de proyectos pueden utilizarse para:

- Seguimiento del progreso general del programa

-Monitorizar y gestionar el riesgo del programa y la incertidumbre

-Comunicar entre proyectos

Compartir datos e informacin entre proyectos

-Conduccin de reuniones de equipo a nivel de programa

-Gestin de las partes interesadas

- Reportar el estado del programa a la alta direccin ya los principales


interesados
7.6.2 Prcticas de gestin de programas de sonido

Mientras que los mtodos clsicos de gestin de proyectos se centran en


iniciativas individuales, la gestin de programas tiende a centrarse en la
gestin de las interfaces entre mltiples iniciativas y aprovechar los elementos
comunes entre ellas. Algunos beneficios de valor aadido que los gerentes de
productos pueden esperar de la aplicacin de metodologas de administracin
de programas son:

Un enfoque de negocio (es decir, evaluacin de la rentabilidad, tasa de


rentabilidad econmica, etc.)

Un enfoque estratgico (es decir, la satisfaccin de los objetivos y objetivos de


la organizacin)

Coordinacin efectiva a travs de:

-Productos

- Lmites de organizacin

-Gente

- Responsabilidades funcionales

-Actividades del proyecto

-Programa entregables

Un enfoque coherente de la gobernanza y supervisin del proyecto

Priorizacin y secuenciacin entre proyectos

Asignacin y gestin continua de recursos entre proyectos

La agrupacin y / o colaboracin de esfuerzos de trabajo similares entre


proyectos

7.6.3 Personal dedicado a la administracin del proyecto (donde sea apropiado)

Al considerar todos los mtodos y procesos de gestin de proyectos y


programas descritos anteriormente, surge una pregunta crtica: Quin va a ser
responsable de su implementacin efectiva a nivel de programa?
Aunque un gerente de producto podra ser nombrado para llenar el papel de
administrador del programa -y por lo tanto se le encarga introducir la
administracin del proyecto- hay dos desafos significativos asociados con ese
enfoque: la competencia de gestin de proyectos y el sndrome de "dos
sombreros".

Competencia de gestin de proyectos

Aunque algunos sostienen que "cualquiera puede hacer gestin de proyectos",


subestimar el valor aadido por un individuo con un alto grado de
conocimiento y competencia de gestin de proyectos puede tener
consecuencias negativas significativas para las iniciativas de productos
organizacionales.

El sndrome de dos sombreros

Tratar de gestionar un proyecto mientras acta como un experto tcnico o un


experto en el mercado (en este caso, un gerente de producto) es visto como
uno de los puestos de trabajo ms difciles en el mundo de los proyectos.
Requiere que las personas dividan continuamente su atencin entre sus
funciones de gestin de productos y de gestin de proyectos. El riesgo de
sobrecarga es considerable.

Estos retos sugieren que el uso de un especialista dedicado a la gestin de


proyectos debe ser fuertemente considerado al manejar programas orientados
a productos, incluso si esa persona no conoce bien los productos especficos.
Esto a menudo toma la forma de un gerente de producto que trabaja en
concierto con un individuo que es altamente competente en la coordinacin de
iniciativas complejas. La clave para hacer que este enfoque funcione es definir
claramente las funciones y responsabilidades de cada contribuyente, as como
la relacin de presentacin de informes.

En estas situaciones, es comn que el especialista en gestin de proyectos sea


visto como un recurso bajo demanda, actuando en un servicio y funcin de
apoyo. Se considera ampliamente que un director de programa que est
involucrado muy temprano en el ciclo de vida general del programa est en
una posicin mucho mejor para tomar decisiones de programa de alta calidad
que uno que es asignado despus de que muchas decisiones cruciales del
programa ya se han hecho.

Algunos de los beneficios especficos del uso de especialistas en gestin de


proyectos son:

- Falta de sesgo personal, poltico, producto y tecnologa


-Conocimiento del enfoque de manejo ms apropiado para situaciones dadas

-Una apreciacin de los efectos ms all de los lmites del programa (es decir,
los impactos en las operaciones, ingeniera, legal, etc.)

- Mantener el proceso de desarrollo enfocado y avanzar

-Focalizar el logro de los objetivos y resultados del producto

7.7 Cmo se relaciona la gestin de la cartera de proyectos con la gestin de


productos

Dentro de la gestin de productos, es comn el uso de un enfoque de gestin


de cartera para coordinar las diversas interacciones e interrelaciones de
productos y lneas de productos. En la gestin de proyectos existe una prctica
similar, si no algo superpuesta.

Debido a que ambas tcnicas implican la coordinacin de una coleccin de


proyectos, existen muchas similitudes entre la administracin del programa
(descrita anteriormente en la Seccin 7.6) y la gestin de la cartera de
proyectos. Quizs la mayor similitud viene en las formas en que se pueden
aplicar mtodos y procesos de gestin de proyectos centrales.

Pero hay algunas diferencias crticas entre los dos tipos de gestin. Por
ejemplo, aunque la gestin del programa se centra en la coordinacin entre
proyectos que a menudo estn interrelacionados, la gestin de la cartera de
proyectos se centra en seleccionar y priorizar una coleccin de proyectos que
no necesariamente estn relacionados.

Y aunque la gestin de programas a menudo se centra en el cumplimiento final


de objetivos de alto nivel, orientados y orientados a la entrega, la gestin de
cartera normalmente se centra en llevar a cabo una serie de iniciativas de
proyectos que, colectivamente, cumplir con las metas y los objetivos
estratgicos y operacionales de una organizacin a largo plazo. El impacto, la
efectividad y el xito de una cartera de proyectos suelen estar vinculados a, y
expresados a travs de evaluaciones, juicios y mtricas relacionadas con la
intencin estratgica, las metas estratgicas, los factores clave de valor, los
indicadores clave de rendimiento, etc. La misin principal de la gestin de
cartera de proyectos es identificar, seleccionar y ejecutar la combinacin
especfica de proyectos que se espera tenga el mayor impacto financiero y
estratgico positivo en la organizacin, equilibrando los riesgos asociados y
conduciendo a la ms alta probabilidad organizativa de xito.
No es sorprendente que la mayor interaccin entre la gestin de la cartera de
proyectos y la gestin de productos se produzca en situaciones en las que la
cartera incluya muchos proyectos orientados a productos, especficamente
carteras que se centren en una lnea de productos o una familia de productos
funcionalmente relacionados.

Para entender mejor cmo los gerentes de producto pueden optimizar la


aplicacin de un enfoque general de gestin de cartera, es til considerar en
mayor detalle los objetivos crticos del enfoque de gestin de cartera en
general. Los objetivos clave de la gestin de cartera son:

Perseguir slo aquellos proyectos necesarios para cumplir con los objetivos de
la organizacin

Asegurar un fuerte vnculo entre la estrategia de la empresa y los proyectos

Habilitar al propietario de la cartera para obtener el mejor "bang for the buck"

Desarrollar un panorama general y promover una comprensin amplia del


volumen de trabajo del proyecto, tanto en proceso como planeado

Facilitar un enfoque diversificado y equilibrado de los proyectos. Algunas


dimensiones comunes del equilibrio son:

-Mercados servidos (diversificados)

- Regiones geogrficas atendidas (diversificadas)

- Horizonte horizontal (largo plazo vs. corto plazo)

-Risk (negocio, tcnica, financiera, imagen corporativa, etc.)

-Aplicacin de la tecnologa

-Utilizacin de recursos

- Tamao del proyecto (dinero, tiempo, cantidad de recursos)

-Ventaja competitiva

- Mandato del gobierno

- Retorno de la inversin previsto

Cuando se considera el papel de la gestin de proyectos en la gestin de


carteras y en apoyo a las iniciativas de producto, normalmente surgen
preguntas, entre ellas: Cundo se debe introducir la gestin del proyecto en el
ciclo y cmo?
Las secciones 7.2 a 7.4 describen dnde y cmo se puede aplicar eficazmente
la gestin de proyectos dentro del marco de gestin del producto. Sin embargo,
el tipo de actividades necesarias para apoyar el logro exitoso de los objetivos
del producto de gestin de cartera -como los identificados en la lista con
vietas anterior- suele tener lugar antes de iniciar el desarrollo de cualquier
producto especfico (y, por tanto, antes de iniciar cualquier ciclo del proyecto).
Este perodo se nombra a menudo para su objetivo funcional principal -
desarrollo de la lista.

Durante el desarrollo de la cartera, existen proyectos candidatos y la


organizacin est evaluando activamente en cules invertir. Como resultado, el
papel de la gestin de proyectos en el proceso es a veces subestimado y, a
veces, completamente descontado. Hay, sin embargo, una serie de beneficios
de valor agregado que se pueden lograr al incluir especialistas en gestin de
proyectos durante el desarrollo de la cartera. Su funcin suele ser de carcter
consultivo y puede aportar algunos aportes importantes a lo largo del proceso
de desarrollo de la cartera, como por ejemplo:

- Permitir que el dueo de la cartera obtenga el mejor "bang for the buck"

Reconocimiento de mtodos y enfoques alternativos para resolver un


problema, atender una necesidad o explotar una oportunidad

-Introduccin de cualquier tecnologa apropiada y disponible

-Estimar los recursos necesarios para un proyecto potencial

-Identificar los grupos funcionales que deben participar en un determinado


estudio

-Corregir un estudio o un anlisis de alternativas

-Ayudar a preparar casos de negocios del proyecto

-Identificar proyectos ms alineados con los objetivos de negocio

-Determinar la combinacin ms eficiente de proyectos, en relacin con el


conjunto de habilidades disponibles, para ofrecer el mximo valor

Al igual que con los gerentes de programas, los gerentes de productos que
lideran o participan en actividades de gestin de cartera es probable que se
beneficien de la participacin de sus compaeros colegas de gestin de
proyectos en el proceso.
7.8 Anlisis de Negocio

El anlisis de negocios es un conjunto de actividades, herramientas y tcnicas


que un analista utiliza con las partes interesadas para comprender la
estructura, las polticas, los procesos y las operaciones de una organizacin.
Los analistas de negocios utilizan estas actividades, herramientas y tcnicas
para analizar las necesidades y recomendar soluciones para ayudar a una
organizacin a alcanzar sus objetivos. Cuando se combina con un gerente de
producto, el analista de negocios (BA) puede ser un experto colaborador que
facilita, comunica, analiza y recomienda soluciones empresariales.

El anlisis de los negocios se ha vuelto ms prominente desde finales de los


aos ochenta, que ha creado un enfoque en la formalizacin de la BA como un
facilitador clave del cambio de negocio dentro de las organizaciones. Este
mayor enfoque se ha visto impulsado por la demanda de una mayor capacidad
de respuesta del mercado, una oferta de productos ms sofisticada, una mayor
dependencia de las aplicaciones de tecnologa de la informacin (TI),
tendencias de subcontratacin y requisitos regulatorios cada vez ms estrictos.

A medida que las organizaciones evolucionan para enfrentar estos retos, estn
trabajando para mejorar sus capacidades de anlisis de negocios. Los BAs que
estn debidamente capacitados y cuentan con la capacidad y experiencia
apropiadas pueden ayudar a definir soluciones, comunicarse con las partes
interesadas, analizar problemas e informacin y obtener requisitos
(comnmente denominados caractersticas del producto). Por ltimo, pero no
por ello menos importante, el BA es bien conocido por ser un intrprete entre
las partes interesadas y los equipos de TI.

Adems, los BA ahora estn desempeando papeles clave ayudando a


especificar el "comportamiento empresarial" que permite ofrecer productos.
Este comportamiento empresarial es un nivel superior al diseo tcnico real y
las capacidades de implementacin que a menudo consideramos como
aplicaciones de software de TI. El diseo de la conducta empresarial se centra
intensamente en la realizacin de la intencin de los objetivos de un producto,
al mismo tiempo que equilibra las restricciones y las compensaciones
organizacionales y tecnolgicas.

Dentro de organizaciones complejas donde mltiples y diversas estrategias,


capacidades, grupos de inters y audiencias de clientes son una realidad,
contar con un analista de negocios capaz de ayudar con las iniciativas de
desarrollo de productos puede minimizar el riesgo al tiempo que aumenta la
probabilidad de xito de una iniciativa.

7.8.1 Anlisis de Negocio Organizacin Gobernante y Cuerpo de Conocimientos


En octubre de 2003, se cre el Instituto Internacional de Anlisis de Negocios
(IIBA) para mantener estndares para la prctica del anlisis de negocios.
Desde su formacin, el IIBA se ha convertido en la asociacin lder en el mundo
del anlisis de negocios. En colaboracin con expertos de la industria, el IIBA
fue el autor del Business Analysis Body of Knowledge (BABOK). El BABOK es
una coleccin de conocimientos que refleja las prcticas generalmente
aceptadas en el anlisis de negocios. Al igual que el PMBOK de PMI y el
ProdBOK, el BABOK da a las organizaciones un entendimiento de donde las
actividades y tcnicas de anlisis de negocios pueden ser aprovechadas en sus
negocios.

7.8.2 Gerencia de productos y analista de negocios

Aunque no todas las organizaciones utilizan los BAs en su gestin de productos


y en sus esfuerzos de desarrollo de productos, los que a menudo encuentran
que los BAs juegan un papel valioso. La lluvia de ideas, la captura de la voz del
cliente, el anlisis de los requisitos y el escrutinio del comportamiento
empresarial son una serie de actividades en las que la BA aporta valor al ciclo
de vida de la gestin del producto. Existen numerosas oportunidades en este
ciclo de vida donde el gerente de producto puede trabajar estrechamente con
uno o ms BAs para colaborar en entregas y logros y alcanzar metas
relacionadas con el producto. Al involucrar a los BAs en el inicio del ciclo de
vida y durante las actividades de planificacin, los gerentes de producto
pueden determinar dnde pueden incorporarse actividades y tcnicas de
anlisis de negocios para maximizar la efectividad.

La siguiente seccin presenta tres elementos que pueden ayudar al gerente de


producto a comprender cundo y cmo aprovechar el anlisis de negocios
durante todo el ciclo de vida de la administracin del producto:

1) Habilidades y conocimientos de BA

2) Escenarios para aprovechar el anlisis de negocios

3) El papel del BA en el diseo del producto

7.8.3 Habilidades y conocimientos de anlisis de negocios

Los gerentes de producto tienen numerosos desafos al planificar, planificar,


disear y lanzar productos. Estos desafos incluyen:

-Comptacin de la atencin de recursos esenciales (es decir, recursos clave de


diferentes reas funcionales)
- Satisfacer las expectativas de mltiples partes interesadas (diferentes
patrocinadores y segmentos de clientes)

-Organizar grandes cantidades de requisitos diferentes (es decir, requisitos


contradictorios y ambiguos)

- Enfoques alternativos para alcanzar las metas del producto (mltiples


soluciones a un problema con varios trade-offs)

-Levantar las capacidades existentes de organizacin y plataforma (utilizando


los procesos y la infraestructura existentes y ajustndose a las hojas de ruta de
los productos de la organizacin)

-Las limitaciones organizativas y tecnolgicas (reas funcionales agrupadas y


procesos y sistemas complejos heredados)

Al aprovechar la habilidad y el conocimiento de la BA en momentos claves en


el ciclo de vida, los gerentes de producto pueden mitigar algunos de los riesgos
asociados a menudo con la administracin y el desarrollo del producto. A
continuacin, se resumen algunas de estas reas de habilidades y
conocimientos.

Comunicacin y habilidades de facilitacin

You might also like