Caso de EStudio
Caso de EStudio
Caso de EStudio
DE DESARROLLO DE PRODUCTOS
"Complacency Kills" fue marcado con un círculo y subrayado en las notas de Greg Adams-
Woodford. Era la imagen de esas palabras que se habían quedado con él durante el fin de
semana. Ahora era lunes y, como vicepresidente de gestión de productos, llegó el momento de
determinar el plan de desarrollo del producto para los próximos cinco años.
Para Adams-Woodford era difícil creer que solo había pasado un año desde que se unió a
Pearson por primera vez. Estaba orgulloso del impacto positivo que su trabajo tuvo en mejorar
la posición de mercado de la versión más nueva del producto SuccessMaker en tan poco
tiempo.
Cuando Adams-Woodford se unió por primera vez a Pearson, toda la división de aprendizaje
digital estaba en medio de la primera gran actualización de su producto SuccessMaker.
SuccessMaker fue el principal producto de software de Pearson para ayudar a los estudiantes
de primaria y secundaria a mejorar sus habilidades matemáticas y de lectura, por lo que esta
actualización fue un proyecto estratégicamente importante para la empresa. La actualización
implicó cambios significativos en la tecnología básica del producto, desde un modelo de cliente-
servidor anterior a un nuevo Internet.
ot entregado modelo - y una completa renovación de todo el contenido de instrucción en el
producto. A pesar de los mejores esfuerzos de los involucrados, las nuevas versiones de
SuccessMaker no cumplían con los objetivos internos de Pearson y las necesidades de sus
clientes más importantes. La dificultad de la situación quedó ilustrada dolorosamente en una
carta no solicitada de un cliente estratégico entregada al principio de la gestión de Adam-
Woodford. En esta carta, el cliente se quejó amargamente de las promesas incumplidas y las
expectativas perdidas desde que comenzó a trabajar en la nueva versión 18 meses antes. Esta
carta finalmente se convirtió en el grito de batalla para una reingeniería completa del proceso
de desarrollo de productos de SuccessMaker. Adams-Woodford y su equipo llevaron a cabo un
corte de flash completo 1
desde un proceso de desarrollo más tradicional y establecido (cascada) hasta una nueva (y no
probada dentro de Pearson) metodología de desarrollo (Agile) (ver Anexos 1 y 2). El enfoque de
Agile en las iteraciones cortas de desarrollo y la comunicación sobre la documentación era
fundamentalmente diferente del enfoque de cascada que habían utilizado previamente, que
enfatizaba la documentación completa y detallada antes de que comenzara el desarrollo.
Ahora, un año después, muchos de los desafíos anteriores estuvieron detrás de ellos. Tanto los
clientes clave de Adams-Woodford como los grupos internos acordaron que SuccessMaker
había pasado por una transformación completamente positiva. Adams-Woodford estaba
complacido de que su visión clara para el futuro haya superado muchos de los problemas más
importantes con el desarrollo de SuccessMaker.
Cotiza en las bolsas de valores de Londres y Nueva York (LSE: PSON, NYSE: PSO), Pearson tenía
tres unidades de negocio principales. La unidad de educación de Pearson se centró en el
mercado de la educación y fue una de
las empresas líderes que desarrollaron productos de aprendizaje para maestros y estudiantes.
El grupo Financial Times brindó servicios de publicación de noticias comerciales y financieras y
servicios en línea. El grupo Penguin publicó libros en una amplia gama de géneros bajo la marca
Penguin.
Pearson reportó $ 8,7 mil millones en ingresos en 2010 (ver Anexo 4). El grupo Pearson
Education fue la mayor de las tres divisiones y representó el 80 por ciento de las ganancias de la
empresa. El mercado educativo de América del Norte fue el segmento de negocios más grande
para Pearson y representó el 46 por ciento de los ingresos mundiales de la empresa.2
La empresa mantuvo su crecimiento incluso durante la profunda recesión de 2007-2008.
MyLab de Pearson - un servicio digital de aprendizaje, tarea y evaluación - creció a más de 7.3
millones de estudiantes registrados en 2010. Un conjunto de tecnologías de administración del
aprendizaje recientemente presentado dirigido al mercado de educación superior - eCollege y
Fronter - también tuvo inscripción en línea de estudiantes de más de 8.3 millones . Pearson
Digital Learning se enfocó en productos suplementarios digitales, vistos como un segmento de
mercado con gran potencial de crecimiento.
A pesar de un récord general de crecimiento sólido, Pearson Education enfrentó algunos
obstáculos en su camino hacia 2011.
El lento crecimiento económico continuo ejerció una presión considerable sobre los
presupuestos de educación en los Estados Unidos. La crisis presupuestaria tuvo un efecto
directo en los presupuestos de educación en todos los niveles. Pearson intentó abordar estos
dificultades del mercado con un enfoque en proporcionar productos y servicios premium.
Además, buscaron aprovechar el cambio de las escuelas al currículo digital y en línea, en lugar
de depender exclusivamente de la demanda de libros de texto tradicionales. Pearson también
realizó algunas adquisiciones clave para seguir ofreciendo una amplia gama de servicios para el
mercado educativo. La firma reconoció los cambios tecnológicos como el mayor riesgo para
todos
sus líneas de productos y servicios. Debido a estos cambios, la transformación de los productos
y servicios de Pearson Education para canales digitales fue un elemento clave de la estrategia
de crecimiento de la empresa.
2 www.pearson.com/investor/ar2010/performance/education/north-american-education.html
visitado el 12 de enero de 2012.
SUCCESSMAKER
SuccessMaker fue uno de los productos de Pearson Digital Learning (PDL) enfocados en ayudar
a los estudiantes de primaria y secundaria a aprender a leer y matemáticas a su propio ritmo.
SuccessMaker fue un producto totalmente digital y fue muy popular entre los estudiantes que
lo usaron. El software también proporcionó a los docentes valiosos datos de evaluación, lo que
permitió intervenciones específicas y entrenamiento. SuccessMaker se personalizó para
mercados individuales para cumplir con los estándares establecidos por el estado en cada nivel
de grado.
El producto SuccessMaker se derivó de uno de los primeros trabajos de investigación sobre
aprendizaje asistido por computadora. Los investigadores Patrick Suppes y Richard Atkinson
lideran el desarrollo de una teoría de decisión
basado en el programa de instrucción en la década de 1960 que finalmente fue comercializado
por Computer Curriculum Corporation. En 1990, Simon & Schuster adquirió Computer
Curriculum Corporation. Pearson hizo una oferta exitosa por las operaciones educativas de
Simon & Schuster (incluido el producto SuccessMaker) y
creó la unidad de negocios digitales de Pearson en 1998.
El enfoque subyacente al diseño de SuccessMaker se mantuvo sin cambios desde su creación.
Los estudiantes recibieron asignaciones específicas para completar por el profesor en el
programa SuccessMaker (ver Anexo 5). En función de cómo respondieron los estudiantes a
estas asignaciones, el software utilizó un algoritmo sofisticado y predictivo para mover a los
estudiantes a través de múltiples niveles de habilidades del plan de estudios. Los estudiantes
que dominan rápidamente las habilidades pueden avanzar más rápido que los estudiantes que
requieren asistencia adicional. El software fue lo suficientemente inteligente como para saber
no solo dónde ubicar inicialmente a los estudiantes en un conjunto determinado de currículos,
sino también la forma óptima de guiarlos a través del mismo. Mediante el uso diario de
SuccessMaker,
los estudiantes a menudo lograron resultados significativamente mejores en las pruebas
estandarizadas en comparación con los estudiantes que utilizan otras metodologías o
productos de instrucción.
Si bien SuccessMaker experimentó muchas mejoras a lo largo de los años, la versión más
reciente formó parte de una importante actualización de tecnología y contenido que comenzó
en 2005. Esta nueva versión, con el nombre en código SuccessMaker: Next Generation,
pretendía ofrecer a los clientes una plataforma más sólida y escalable. como un plan de
estudios más moderno. Este nuevo plan de estudios utilizó una variedad de nuevas
herramientas de instrucción que incluyen animación 3D y un avatar interactivo para guiar al
alumno a través del programa.
Si bien la intención del nuevo lanzamiento era abordar problemas críticos del mercado, la
realidad era que le faltaba la marca. Cuando Greg se unió a Pearson en 2007, le dijo al
vicepresidente senior de gestión de productos: "Hemos gastado $ 30 millones en el nuevo
desarrollo de SuccessMaker e incluso de seis a ocho.
meses después de lanzar la primera versión, no ha sido bien adoptado por el mercado. Los
primeros adoptantes se quejaron de que no cumplía con ninguno de sus requisitos ".
Una de las primeras ideas de Greg sobre la causa raíz de los problemas de SuccessMaker fue
que el equipo de desarrollo impulsaba todas las decisiones en lugar de la gestión de productos.
Como resultado, hubo poca comunicación directa entre el equipo de desarrollo y los clientes, lo
que provocó que muchas características bien intencionadas pasasen completamente por alto
cuando se lanzaron. El equipo de SuccessMaker utilizó la metodología de desarrollo de cascada
(ver Anexo 1), enfatizando el congelamiento de los requisitos del producto al comienzo de
un ciclo de desarrollo a través de documentación formal. Con una porción importante de
software que se desarrolla en alta mar en la India, la falta de comunicación entre los equipos de
desarrollo en la India y los Estados Unidos era una ocurrencia común. Debido a restricciones
contractuales, los cambios en las características del producto a mitad de camino durante el
ciclo de desarrollo fueron costosos o imposibles.
El proceso de cascada también requirió que la organización se comprometiera con un mapa de
varios años de características que no permitían cambios significativos en el alcance. Estas
características se presupuestaron individualmente y se comprometieron en el plan estratégico
de la unidad de negocios. Cualquier cambio en el mapa de ruta fue generalmente visto
negativamente. El equipo se refirió a tales cambios usando el término peyorativo de la industria
"scope creep". El proceso de cascada hizo más fácil la planificación interna ya que el alcance se
congeló esencialmente por varios años.
También significó poco esfuerzo para confirmar que las características comprometidas
satisfagan las necesidades de los clientes o que exploren características alternativas e
imprevistas una vez que se estableció el mapa de ruta.
EL PULSO PARA LA METODOLOGÍA ÁGIL
Adams-Woodford utilizó con éxito metodologías de software Agile en dos empresas en etapa
inicial antes de unirse a Pearson. La metodología ágil de desarrollo de software abogó por un
enfoque iterativo y evolutivo
al software en comparación con el modelo de escenario formal del enfoque de cascada. La
metodología ágil impuso un enfoque de desarrollo impulsado por el cliente con ciclos cortos de
desarrollo, típicamente dos "sprints" de dos semanas que entregan un pequeño subconjunto de
características del producto utilizando muy poca documentación formal. En resumen, las
"historias de usuario" escritas en una sola tarjeta de índice reemplazaron los documentos de
requisitos de más de 100 páginas del pasado.
No hubo compromiso con los sprints futuros hasta que se completó el anterior. Este enfoque
de compromiso diferido permitió a los equipos adaptar, diseñar y priorizar las características
del producto a través de la retroalimentación constante de los gerentes de productos y clientes.
Una suposición clave de la metodología fue que la gestión del producto era propiedad del
producto, no de los desarrolladores. Adams-Woodford dio una conferencia al equipo de
desarrollo sobre el papel de un gerente de producto: "Los clientes no le pagan por crear
documentos; ellos quieren que crees un producto. Gestión del producto
debe entender el mercado, competencia distintiva, escuchar a sus clientes y priorizar las
características que crean el mayor valor para sus clientes ".
La primera tarea de Adams-Woodford fue cambiar la estructura básica y la cultura de la
organización, empezando por el equipo de desarrollo de software, incluidos los desarrolladores,
los ingenieros de control de calidad (QA) y los gerentes de producto. El equipo general de
desarrollo de productos estaba compuesto por un grupo diverso de personas con experiencia
en diferentes áreas dentro de Pearson: gerentes de producto, desarrolladores de software,
expertos en control de calidad, analistas de negocios, expertos en contenido / currículo,
diseñadores instruccionales, animadores y artistas. Antes del cambio formal a Agile, Adams-
Woodford hizo la transición de todo el desarrollo de software offshore a la propia empresa
mediante la contratación de varios nuevos desarrolladores de software en Arizona. La
metodología ágil requería una estrecha cooperación entre los miembros del equipo casi a
diario. La comunicación con el equipo extraterritorial había sido un punto constante de disputa
tanto con el equipo de Pearson como con su proveedor. Adams-Woodford se dio cuenta de que
tenía que crear un diálogo más productivo centrado en construir un mejor producto.
EL MOVIMIENTO A AGILE
La transición se ejecutó como un flash-cut del proceso de cascada anterior a la nueva
metodología ágil. El viernes, los equipos de desarrollo de software habían estado siguiendo el
proceso de cascada y cuando regresaron el lunes siguiente, eran 100% ágiles. El movimiento se
programó justo después de que la segunda versión principal del producto se lanzó a la
fabricación (grabación en DVD / CD). Este cambio dramático se encontró con el escepticismo de
un subconjunto vocal de los miembros del equipo. Adams-Woodford destacó
la transición fue tanto un cambio cultural como un cambio en los procesos. Algunos miembros
renunciaron cuando se realizaron los cambios.
Tan pronto como se realizó el corte, se entregó capacitación a todos los desarrolladores de
software, ingenieros de control de calidad y gerentes de producto, detallando la nueva
metodología y el rol de cada uno dentro de ella. Adams-Woodford trajo un entrenador ágil
independiente para enseñar al equipo sobre la nueva metodología de desarrollo. Todos los
equipos pasaron dos días completos con el entrenador y el entrenamiento se llevó a cabo en
tres fases. La primera fase se centró en explicar la lógica subyacente de un enfoque ágil para
asegurar que todos entendieran
osthe core Principios ágiles. La segunda fase abordó el trabajo dentro de un marco de
desarrollo ágil, discutiendo las prácticas de trabajo específicas requeridas. La fase final se
centró en el equipo de SuccessMaker, pidiendo a los miembros que analicen por qué Agile no
trabajaría en su entorno. El entrenador de Agile sugirió abordar de forma proactiva estas
inquietudes, ya que había observado preocupaciones persistentes sobre Agile que a menudo se
manifestaban en el comportamiento del equipo semanas o incluso meses después de pasar de
procesos más tradicionales.
Como todos los equipos y su alta dirección estuvieron presentes en las sesiones de
capacitación, los equipos exploraron conjuntamente la solución de la mayoría de los problemas
que surgieron. Gastaron una cantidad considerable
de tiempo discutiendo cómo algunos grupos que no iban a estar en modo Agile interactuarían
con desarrolladores y grupos de administración de productos dado que todavía eran parte
integral del esfuerzo de desarrollo más grande. Otro tema que se debatió fue que los equipos
de desarrollo y QA habían trabajado por separado
y grupos mayormente autónomos previamente. Se acordó que los dos equipos tenían que
combinarse en un entorno Ágil, con un amplio entrenamiento cruzado en sus respectivas
especialidades. Bajo este nuevo sistema, el cambio más importante implicó cómo la gestión de
productos se relacionaría con el desarrollo. La gestión del producto ahora impulsaría todos los
esfuerzos de desarrollo y la priorización de nuevas características. La gestión de productos
debería priorizar las historias de los usuarios de acuerdo con las necesidades del mercado de
forma continua, un cambio incómodo tanto para el desarrollo como para los grupos de
productos. Adams-Woodford y Eric Wagner, el vicepresidente de los equipos de desarrollo
recientemente contratados, trataron de ayudar al equipo de SuccessMaker con esta transición
al asegurar que ambos fueran consistentes e inquebrantables en su aplicación del proceso ágil.
Los equipos de desarrollo se reorganizaron para SuccessMaker Release 3 cuando finalizaban su
trabajo relacionado con el desarrollo para la Versión 2. Después de algunas experimentaciones
iniciales con diferentes tamaños de equipo, el equipo de desarrollo se dividió en cuatro grupos.
Dos equipos fueron responsables del trabajo de desarrollo
involucrando el lenguaje de programación Java. Un equipo fue responsable de manejar la
codificación de informes y la lógica del currículo. Otro equipo creó todas las animaciones
basadas en Adobe Flash requeridas para el producto. Además de estos equipos, se designó un
maestro de scrum en cada equipo para ayudar al equipo a eliminar cualquier obstáculo.
enfoque. Los líderes de equipo en el equipo de software también reconocieron una serie de
problemas que requieren atención inmediata más allá de las preocupaciones de los ingenieros
de control de calidad sobre sus roles y pruebas de software. Las pruebas de integración de
extremo a extremo y la automatización completa de los procedimientos de prueba todavía
estaban en proceso. Hubo una tendencia a seguir un enfoque de mini cascada cuando se
requirieron estas pruebas. Los equipos querían evitar esta tendencia en el futuro.
Más allá de la planificación de los sprints, las actividades dentro de un sprint individual tenían
margen de mejora.
David Foster, arquitecto jefe de la división, destacó los equipos de desarrollo de productos
involucrados en el cambio de contexto. En otras palabras, los equipos de desarrollo a menudo
cambian de una función a otra característica distinta dentro de la misma iteración de
desarrollo. Esto dio como resultado una velocidad reducida, ya que los desarrolladores tenían
que revisar y familiarizarse con los aspectos técnicos de los componentes del sistema cada vez
que pasaban de una función a otra. Para eliminar el cambio de contexto, Foster señaló la
necesidad de que los equipos de productos y desarrollo reconozcan el mapeo entre las
características y los componentes del sistema.
Foster también observó: "No hemos llegado a ser muy eficientes en las versiones de
mantenimiento. Con Scrum, no debería importar, pero aún no nos sentimos cómodos con ellos.
Ese sigue siendo un punto difícil ".
"Bueno", pensó Adams-Woodford para sí mismo. "Si Agile trabaja para el desarrollo, tal vez
funcione para mí". Adams-Woodford fue al área de planificación de los desarrolladores y trajo
un paquete de fichas a su oficina. Adams-Woodford comenzó a delinear las historias de los
usuarios sobre cómo implementaría el mapa de ruta del producto, su lugar dentro de él y el
esfuerzo Agile más amplio en Pearson.
Exhibición 1
RESUMEN DEL ENFOQUE DE DESARROLLO DE SOFTWARE DE CASCADA
Los equipos de software tradicionalmente han seguido un enfoque por etapas cuando
construyen sistemas. El término "cascada" se refiere a la rigidez inherente en el ciclo de vida del
desarrollo donde se supone que una fase comienza solo después de la finalización de una fase
previa. Sin embargo, es común ver que los equipos de software iteran entre fases. Las fases
principales en el ciclo de vida de desarrollo de software (SDLC) incluyen: (1) análisis de
requisitos, (2) diseño, (3) desarrollo, (4) pruebas, (5) implementación y (6) mantenimiento.
Los gerentes hacen hincapié en la necesidad de analizar y documentar de forma exhaustiva los
requisitos del usuario, ya que consideran que los cambios realizados en los requisitos y el
diseño durante las últimas etapas del ciclo de vida del desarrollo son muy costosos y
perjudiciales. Como resultado, los modelos de desarrollo por etapas requieren mucha
documentación.
Una suposición clave de un enfoque por fases es que la dependencia entre fases es lineal y
unidireccional. Sin embargo, en la mayoría de los proyectos de software, las dependencias
entre los componentes son complejas y bidireccionales. Para abordar esta complejidad, los
gerentes intentan dividir los proyectos en módulos relativamente independientes e integrar los
módulos hacia el final del ciclo de vida del proyecto.
Kanban como una metodología de desarrollo de software es una adaptación más reciente de la
aplicación de fabricación tradicional. Kanban en este contexto a menudo se asocia con procesos
de desarrollo de software Lean. En software, Kanban adopta la filosofía de la implementación
de fabricación y la aplica a varios pasos para desarrollar un producto o aplicación. Estos pasos a
menudo incluyen creación, desarrollo, prueba e implementación de historias de usuarios. A
diferencia de los procesos ágiles más tradicionales como Scrum, Kanban no utiliza un cuadro de
tiempo para cada sprint de desarrollo. En cambio, Kanban impone límites de trabajo en
progreso
para cada paso de desarrollo. El proceso general puede optimizarse imponiendo y ajustando
estos límites.
Los miembros del equipo se concentran en los cuellos de botella del sistema para reducir el
tiempo total de rendimiento de las funciones al eliminar el desperdicio (muda) durante todo el
proceso. A diferencia de otros procesos ágiles que usan la velocidad como su métrica clave,
Kanban utiliza el rendimiento para las características individuales como su métrica clave.
Kanban tiene algunas similitudes con los procesos ágiles más tradicionales, lo que incluye
permitir a los propietarios de negocios posponer los compromisos de las funciones hasta que la
característica ingrese al desarrollo y buscar permitir que los equipos trabajen juntos de manera
más colaborativa al hacer
el flujo de trabajo, que puede ser físico o componentes de una aplicación de software, visible
en la placa Kanban.
Fuente: D. Anderson, Kanban: Cambio evolutivo exitoso para su negocio tecnológico, Blue Hole
Press, Sequim,
2010, pp. 11-16.
PREGUNTAS DE TAREA