Gestión de procesosPag. 38

DevOpsPag. 40

Pagos Móviles Pag. 42 No.45

SG

SO

FT

WA

RE

GU

RU

No

.45

|

Ag

ost

o -

Oct

ub

re 2

014

ESPECIAL

LA ERA DE LAS APIS

TUTORIALDesarrolla con

Kinect v2

CONOCIMIENTO EN PRÁCTICAwww.sg.com.mx

TESTINGTENDENCIAS Y PRÁCTICAS

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

EspecialAPIs 18

Las APIs son engranes muy importantes en el mundo del software y por ello es vital

comprender su funcionamiento. Estos engranes están siendo referenciados como el

futuro de muchos negocios en línea. Conoce más de este tema en esta sección espe-

cial que tenemos para ti.

ReseñaSGCE 2014 06

ColumnasTejiendo nuestra red 08Por Hanna Oktaba

Mejora continua 10Por Luis Cuellar

Tendencias en Software 13Por Luis Daniel Soto

Tecno-lógico 46Por Mauricio Angulo

Columnas invitadas:DevOps ¿Qué es? 40Por Ismael Villegas

Análisis de la Situación Actual de los Pagos Móviles, desde la Perspectiva de un Usuario de la Banca 42Por Sergio Bolaños

Implantando Big Data 44Por Victor Pichardo

.CONTENIDO

03

Pág.

18

Emprendiendo¿Por qué todos en tu Startup deberían contestar Correos de Soporte? 11Por Celeste North

PrácticasCalidad 36Por Ana Vazquez

Gestión 38Por Pilar Barrio, Rodrigo Guzmán y Raúl Martínez

Herramientas y NovedadesLo que viene 12Docker 17

Tutorial

Desarrolla apps con Kinect SDK v2 14Por Laura Frías Carrillo

PersonasCarrera 48

Por Pedro Solares

TecnologíaDiagnóstico Físico Utilizando Google Glass y Machine Learning 50Por Jair A. Serrano, Lainy C. Regalado, Victor F. Villa,

y Germán H. Alférez

En Cada NúmeroEditorial 04Noticias 05SG Perfiles 52Gadgets 54Biblioteca 56

38

.PRÁCTICASgestión

Acercando el Productode Software al Negocio

›› Pilar Barrio, Rodrigo Guzmán y Raúl Martínez

Este trabajo resume los pasos seguidos por una empresa en un ambiente híper competitivo

como es el comercio electrónico y las decisiones téc-nicas y organizacionales que tomaron para mejorar su desempeño. Se analizan éstas luego para extraer con-clusiones aplicables a cualquier empresa.

El escenario previoArquitectura técnicaOriginalmente la plataforma de e-commerce fue monolítica y cerrada. Su base de datos y su código estaban centralizados. El diseño de esta arquitectura fue pensado para generar ventajas competitivas, pero con altos costos en pérdida de flexibilidad y riesgos ante cambios.

Impacto de las fallasEn este esquema monolítico, centralizado y cerrado, un defecto producto de un error en el desarrollo, tenía una alta probabilidad de impacto cruzado en distintas partes de la aplicación con su consecuencia directa e importante en el negocio. El riesgo asociado a un defecto latente era muy alto y los efectos no deseados sobre el negocio podían ser significativos. El foco estaba puesto en corregir los defectos.

Procesos de desarrolloLos procesos se diseñaron bajo la premisa de evitar errores resultando en ciclos de desarrollo y pruebas extensos, difíciles de escalar y con un “time-to-market” poco acorde a la industria de e-commerce. Los ciclos de desarrollo-liberación eran extensos, con semanas/meses en pruebas, frecuencia de liberación – “release”- quincenal y en ocasiones mensual.

OrganizaciónSe generó una dinámica organizacional poco toleran-te a los defectos, con incentivos alineados a evitar y prevenir cualquier tipo y magnitud de defecto. Equi-vocarse no era bien visto, por lo tanto la capacidad de innovar e iterar tendió a reducirse.

El concepto de calidad de producto era elemen-tal y estaba definido en términos de cantidad de de-fectos. Las métricas y objetivos a lograr se diseñaron bajo ese concepto y se enfocaban en medir y contro-lar cantidad de fallas en producción.

Este escenario puede visualizarse como a base de una pirámide. En él, el esfuerzo estaba puesto en un producto sin defectos y con el resto de las características

cumplidas. Los indicadores de éxito estaban referidos a un producto con baja tasa de errores. Ver Figura 1

Figura 1. Escenario visto como una pirámide.

El nuevo escenarioArquitectura técnicaSe produjo un cambio radical cuando la plataforma dejó de ser un sitio web para convertirse en una pla-taforma abierta de e-commerce. Se rediseñó la arqui-tectura para abrir la plataforma y descentralizar tanto la base de datos como el código fuente, permitiendo distribuir la aplicación en distintos departamentos de la organización.

Impacto de las fallasLa nueva arquitectura eliminó fricciones y depen-dencias funcionales y técnicas existentes entre los módulos en el modelo monolítico. El riesgo se dis-tribuyó y esto obró como factor de cambio en la or-ganización y en el negocio.

Procesos de desarrolloSe establecieron procesos ágiles de desarrollo y prue-ba permitiendo aumentar la frecuencia de pruebas, cantidad y paralelismo de los cambios, mejorando la velocidad de implementación y corrección de de-fectos. Se pasó de tener una única implementación quincenal a tener casos de más de ochenta pasajes a producción en un mismo día.

OrganizaciónLa nueva perspectiva introdujo un cambio radical en la dinámica organizacional, enfocando y alineando a los equipos de trabajo con la mejora continua y el cambio constante, no tratando de prevenir todos los

defectos, sino de lograr un producto con la calidad suficiente para no afectar los indicadores del negocio.

El impacto de los defectos en el producto no es ya la fricción principal en el negocio: Esto permite manifestarse al resto de las variables que afectan al negocio y que antes no formaban parte explícita de la definición interna de la calidad del producto.

Los nuevos indicadores e incentivos definidos requieren un comentario adicional.

Ya no es suficiente evitar errores en el producto, o asegurar el funcionamiento y la disponibilidad de la plataforma; se trata de dar a los usuarios lo que necesi-tan y como lo necesiten, satisfaciendo sus expectativas y logrando una experiencia que diferencie a la empresa de la competencia. Hay espacio para equivocaciones, pero existen mecanismos sensibles de alertas y proce-sos de cambios y corrección muy agilizados.

Para monitorear el comportamiento de las nuevas variables se consideraron varios niveles de indicadores, como muestra la pirámide de la Figura 2. Este escenario puede visualizarse completando la pirámide de la Figu-ra 1 con otros dos niveles: producto útil para el usuario y, si esto se cumple, producto exitoso para el negocio. Los indicadores de éxito se relacionan en la base con la baja tasa de errores, y hacia el vértice, se definen en rela-ción a los KPI’s que interesan al negocio, no olvidando además la satisfacción de los clientes.

Nivel 1 (base) - EscalabilidadNivel 2 (base) - Funcionamiento CoreNivel 3 (base) - UsabilidadNivel 4 (medio) - Customer SatisfactionNivel 5 (vértice) - RentabilidadNivel 6 (vértice) - Competitividad

Figura 2. Pirámide completa

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.PRÁCTICASgestión

Análisis del casoTratando de interpretar las decisiones más importan-tes tomadas surge: Interesados y sus expectativas.

Los siguientes aparecen como interesados principales:

La Empresa, que requiere un producto ágil y amplia-ble, competitivo en funcionalidad, con costos acep-tables de desarrollo y operativos, medido mediante indicadores que relacionen el comportamiento del producto y el del negocio.

El Visitante/usuario, que requiere un producto con-fiable y maduro, completo en funcionalidad, sencillo de utilizar, seguro y de buena performance.

El Grupo de Desarrollo que requiere un producto cons-truido de modo tal que les permita satisfacer el Time-to-market, mantenible, posible de ser probado y auditable.

Para satisfacer al universo de interesados, la Em-presa encaró cambios radicales en la arquitectura del producto, los procesos de negocio y técnicos, y la or-ganización que los soporta.

Analicemos los cambiosArquitecturaEl cambio tuvo como finalidad que ésta no fuera una traba para cumplir las expectativas de la Dirección y gru-pos responsables del producto en cuanto a agilidad en los cambios y clara responsabilidad de los intervinientes. Los visitantes/usuarios observan un comportamiento estable y similar en el producto, o mejorado en algunas funcio-nes. El costo de lograr este comportamiento es menor, algo no visible al visitante, pero sí a la Organización.

Procesos de desarrolloEl proceso convencional de desarrollo y manteni-miento, adecuado para un producto monolítico y altamente acoplado, se cambió por prácticas ágiles.

OrganizaciónLa organización original evolucionó en paralelo con los nuevos procesos, para satisfacer expectativas de ti-me-to-market, responsabilidades, costo de cambios, e indicadores de comportamiento producto / negocio.

Se formaron equipos pequeños, descentralizados y multifuncionales responsables desde la definición

y planificación de nueva funcionalidad o cambio, hasta su puesta en Producción y posterior evolución.

Se disolvió el QA centralizado reasignando sus integrantes a los nuevos equipos.

Se implementó la función de Business Assuran-ce, que controla el producto en operación y analiza el impacto de su comportamiento en el negocio me-diante indicadores.

IndicadoresEl producto y organización originales, no mostraban cómo los indicadores técnicos se relacionaban con los del negocio (ver Figura 1). No existía una relación directa entre las acciones a tomar en el producto para corregir o potenciar situaciones de negocio.

Los distintos niveles de indicadores (ver Figura 2), permiten ahora detectar la calidad en uso del producto para los interesados y efectuar mediciones que delimitan sobre qué parte del producto accionar si fuera necesario. Estos indicadores accionables, en forma indirecta, estable-cen si se cumplen los objetivos de negocio dependientes del producto, posibilitando dar incentivos a los responsa-bles de las distintas partes de la plataforma de la Empresa en función al cumplimiento de dichos objetivos.

Próximos pasosInteresadosContinuar la detección de interesados, además de los vi-sitantes y comerciantes, ampliando a otros con expecta-tivas sobre el producto: comunidad de desarrollo exter-na, auditores, seguridad informática, etc. Entendiendo la influencia y comunicación con cada uno.

Detección y priorización de expectativasRealizar encuestas o consultas instantáneas a los visi-tantes/compradores y comerciantes para entender sus expectativas. Utilizar herramientas como el Modelo Kano y los Mapas de Empatía para detectar y priori-zar requerimientos y expectativas.

Modelo de calidad y evangelizaciónFormalizar en la medida necesaria y posible, el co-nocimiento tácito de calidad para la Organización y transmitirlo a los equipos propios, a terceros y a otros interesados mediante reuniones y eventos. Ejemplo, al desarrollador que amplía el producto de la Em-presa mediante APIs, la formalización le permitirá comprender la calidad esperada, y a la Empresa, eva-

luar la calidad ofrecida. El software será visto enton-ces como homogéneo, ya sea el producto base o sus extensiones.

Aquí resultan aplicables los modelos establecidos en la industria de calidad de sistemas y de productos de software.

KPIs del negocioContinuar midiendo “features” del producto por los resultados sobre el negocio. Las medidas deben ser accionables, y se debe poder relacionar el KPI del ne-gocio con el producto, para intervenir si es necesario.

KPIs del productoDesarrollar nuevos KPIs que midan la calidad técnica del producto, para pronosticar su calidad final. Como se mencionó anteriormente, aquí aplican los modelos de calidad de software y las métricas que proponen.

Mejora continuaCompenetrar al personal técnico del producto cada vez más en el negocio, ya que el negocio se basa en el pro-ducto, completando así un ciclo para mejorar la calidad del producto haciéndolo más competitivo y exitoso.

ConclusionesSe mostró cómo esta Empresa:

• Colocó en el centro al cliente y al producto y no a la tecnología.• Relacionó el negocio con el producto de soft-ware y el éxito en el negocio con la calidad de dicho producto.• Cambió su organización y modelos de trabajo para adecuarlos a los tiempos y necesidades que demandaba su mercado.• Dio, intuitivamente, los pasos necesarios para considerar todo el contexto en el que el producto de software estaba inserto y reaccionó ante ese contexto.• Los próximos pasos propuestos intentan hacer más visibles y analizables estas decisiones conso-lidando aún más la calidad del producto que se está logrando.

Si bien este análisis es de un caso en particular, permite extraer conclusiones aplicables a otras or-ganizaciones que quieran lograr una mayor y mejor relación entre sus productos de software y el negocio en el que se aplican.

.BIO

Pilar Barrio la Iglesia fue docente universitaria en distintas materias relacionadas con la tecnología informática. Socia fundadora de RMyA S.R.L., especializada en consultoría sobre aseguramiento de calidad y testing. pbarrio@rmya.com.ar

Rodrigo Guzmán es Gerente Senior de Desarrollo de Producto en MercadoLibre empresa líder de comercio electrónico. Responsable de varios proyectos de desarrollo de producto, principalmente la verticalización de la plataforma para las principales categorías. Lic. en Admón de Empresas, postgrado en Calidad y Gestión y Certified Scrum Master. rodrigo.guzman@mercadolibre.com

Raúl Martínez se especializa en Gestión de Proyectos de TI y calidad de productos de software. Docente de la Facultad de Ingeniería (UBA). Socio fundador de RMyA SRL interesado en mejora de procesos, gestión de proyectos, gestión de la calidad. rmartinez@rmya.com.ar

39