Arquitecto de Soluciones

[jaiment]

Hola @chamodev.

Propongo el tema Arquitecto de Soluciones.

Tiene algo de relación con el issue 3 pero no es exclusivo del aprendizaje orientado a productos.

¿Qué no es un Arquitecto de Soluciones?

• Business Architecture: Función enfocada en el desarrollo de ideas para generar nuevos productos/servicios, cómo llevarlos al mercado y el pricing.
• Software Architecture: Enfocado en seleccionar las tecnologías, infraestructura, plataformas y demás temas técnicos para desarrollar un producto cuyas especificaciones funcionales ya están dadas.
• User Experience: Funciones que abarcan la usabilidad, engagement, diseño gráfico y velocidad de la aplicación, entre otros.

¿Qué es un Arquitecto de Soluciones?

• Desempeña un papel muy similar al arquitecto en una obra de ingeniería civil (por ejemplo para construir una casa, edificio, centro comercial, parque recreacional, etc.).
• Se reúne con los sponsors y decision makers de una empresa/institución para entender de manera profunda sus necesidades, problemas, cadena de dolor, hábitos y costumbres.
• Tiene un gran nivel de empatía con el usuario final, y llega a conocer su contexto social, educativo y más importante aún: su situación laboral, el nivel de estrés y urgencia al ejecutar tareas con el software que le vamos a dar.
• Entiende las fortalezas y debilidades (FODA) de la institución/empresa y del usuario final.
• Entiende bien qué espera el cliente del usuario final (siempre existen clientes internos y externos).
• Analiza todo lo anterior y propone un plano arquitectónico de la solución con: (a) un pitch de cómo se resolverá el problema; (b) diagramas de proceso en BPMN, (c) bosquejos de pantallas y tal vez un dummy.
• Valida la solución técnicamente con un Software Architect, para proponer las mejores tecnologías, plataformas, integraciones, etc.

Customer Obsession

El Arquitecto de Soluciones tiene una obsesión por resolver los problemas de su cliente, de los usuarios finales y de los clientes de su cliente. Dicho de otra forma, se enfoca en el customer obsession en vez del product obsession. Por ejemplo Amazon tiene el customer obsession en su No. 1 de principios de liderazgo. Por el otro lado tal vez Apple tiene un product obsession (les debo el link).

¿Por qué este tema?

Me ha tocado ver proyectos donde se desarrolla algo que el cliente termina no usando. Existen muchas razones por las cuales esto sucede, pero principalmente es por no entender con profundidad cuáles son los problemas a resolver.
También está el technology obsession donde los desarrolladores eligen funcionalidad y tecnologías sólo por estar a la moda, e.g. ES6 vs CoffeeScript.

Tópicos sugeridos

• Enfoque en entender el problema y cadena de dolor (chain pain).
• Identifica a tus key players: Sponsor, Decision Maker, End User.
• FODA
• Empatía con el usuario final y su cliente.
• Análisis técnico.
• Viabilidad económica.
• Propuesta de Solución: Pitch de la solución, Diagramas de Proceso, Bosquejo de Pantallas.
• Anexo técnico.
• Puente entre el team técnico y el team funcional (analistas expertos en su materia, e.g. nómina, inventarios, compras, impuestos, etc.).

Bibliografía

• The Elements of User Experience, Jesse James Garrett. Muy buen libro aunque sólo abarca un tema muy específico del Solutions Architect.

[chamodev]

¡Hola @jaiment!

Gracias por la propuesta. Me parece genial el tópico. A lo largo de los años también he visto que se desarrollan productos que nadie utiliza. Así que estamos completamente alineados en la necesidad de crear experiencias educativas alrededor de este tema. Muy interesante también el "customer obsession" vs. "product obsession". Me encantaría aprender más :)

Leyendo la descripción preliminar me surge una duda en relación al nombre que utilizas: "Arquitecto de Soluciones". ¿Cómo se diferencia al rol de Product Manager (PM)? El PM se reúne con los stakeholders, empatiza con el usuario final, entiende las fortalezas y debilidades del equipo, hace el pitch, el product roadmap, analiza la viabilidad técnica, establece las prioridades, remueve barreras y, en definitiva, es el responsable de crear un producto que la gente use. Es importante destacar que Product Manager no es igual a Product Owner (que viene de SCRUM y tiene una descripción muy específica para equipos que corren SCRUM). Un par de buenas referencias sobre cómo entendemos el rol del PM son:

• https://medium.com/swlh/the-role-of-a-product-manager-e0354b4b6845
• https://medium.com/all-things-product-management/product-manager-you-are-664d83ee702e

Me parece interesante coordinar con @claudiaalf, quien está liderando el desarrollo de varios cursos alrededor de Product Management para ver si unificamos esfuerzos. Una opción puede ser incluir este contenido dentro de uno de los cursos ya establecidos. La otra sería tener este curso de "Arquitecto de Soluciones" como una pieza más del mapa de conocimientos del desarrollo de productos. Estoy copiando a @claudia para que coordine contigo. Lo que sí está claro es que el contenido descrito en la sección de tópicos sugeridos (chain pain, FODA, viabilidad, etc.) es de gran valor y deberíamos hacer lo posible por desarrollar material de clase mundial y en español que sea público y accesible para toda la comunidad. :)

@claudiaalf: porfa sigamos esta conversación. Quizás puedan hablar 1:1 en un call y definir el plan de acción correcto. ¡¡Mil gracias!!

@lupomontero @coloradomarin @diegovelezg: ¿qué opinan?

Gracias @jaiment por la iniciativa y me alegra que empecemos este camino de colaboración abierta, de todos y para todos.

PD: disculpa la demora en responder. Estuve de viaje y recién me he podido conectar.

[jaiment]

Hola @chamodev.

El Arquitecto de Soluciones conoce muy bien y seguramente ha desempeñado las funciones de un Product Manager.

Estas son las diferencias que veo (muy a mi criterio y súper discutibles).

Funciones del Product Manager

• Sacar un proyecto en el tiempo estimado y con el presupuesto que se estableció.
• Nota: puse proyecto porque hay actividades de éste que tienen poca relación con el producto per se, como son: capacitación, go live, roll out, soporte y documentación.
• Planear los sprints junto con los desarrolladores y apoyarse del Scrum Master (que no he tenido la fortuna de ver un caso exitoso de Scrum Master pero es otra historia).
• Entregar informes de avance del proyecto a la alta dirección.

Siguiendo tus observaciones, el Arquitecto de Soluciones lo veo más cercano a un Product Owner y éstas son algunas de las tareas que desempeña que veo que no existen en el Product Manager:

• Tiene a su cargo analistas funcionales (functional analysts) que no necesariamente saben de software pero que entienden y traducen de manera muy clara las necesidades de un cierto tema, por ejemplo: contabilidad, impuestos, nómina, compras-inventarios, manufactura, retail, ventas, etc.
• Aporta alto valor al R&D (investigación y desarrollo).
• Propone y tal vez hasta administra Roadmaps de varios años del producto.
• Vé más halla del siguiente release, se preocupa profundamente por cimentar unas bases sólidas junto con el Arquitecto de Software.
• Analiza FODA contra otras marcas y productos disponibles del mercado, y posiblemente participa en benchmarking.
• Entiende los conceptos básicos del pricing de un producto y los modelos de comercialización, e.g. SaaS, licencia por usuario/procesador/funcionalidad, In-App Purchases, por API request, etc.
• Participa en las estrategias y la innovación de productos de la organización.
• Puede realizar tareas de due diligence técnico.

En resumen, creo que el Arquitecto de Soluciones tiene una visión mucho más 360 del negocio y el impacto tienen los productos en el éxito o fracaso de la organización.

Aquí unos links útiles que hablan sobre estos temas:

• Breaking down the software development roles
• Solutions Architect wikipedia
• Solutions Architect en AWS.

Saludos : )

[claudiaalf]

Hola @jaiment ! Sorry por la tardanza en responder.
Como te dice el Chamo, nosotros tenemos una visión de Product Manager que se separa del Project Manager y está más alineado a lo que tu nos indicas. Sería ideal que podamos compartir más ideas ¿Qué te parece si coordinamos un hangout para el viernes 8, a las 11am hora Perú?

estamos trabajando en una currícula que te compartiré y creemos se puede alinear.

Me avisas!

[jaiment]

Hola @claudiaalf sí por fa envíame el meeting a jaime@factorbi.com

Saludos!

[chamodev]

¡Excelente @jaiment y @claudiaalf! Gracias. Lo ven y luego nos cuentan :)

[lupomontero]

Hola todxs,

Antes que nada gracias @jaiment por la propuesta 👍

Me parece un tema super interesante que podría tener cabida tanto en el programa de educación continua para egresadas de nuestro bootcamp como en la malla en la que está trabajando @claudiaalf. En el contexto de la malla de Full Stack JavaScript quizás sería chévere incluir algún curso sobre este tipo de temas para no quedarnos puramente en el plano técnico y hablar de roles comunes, metodologías de trabajo, ...

Qué opinan?

Saludos,

L

[claudiaalf]

Hola @jaiment
Gracias por la llamada el día viernes, creo que podemos colaborar de varias formas.
Como quedamos:

1. Te invito a participar de la currícula que tenemos de "Lean Product Management", este curso en realidad está más dirigido a Product Managers actuales que trabajan en conjunto con el equipo de desarrollo, o ya pueden tener un equipo más completo de desarrollo. Si deseas puedes crear un fork y poner tus sugerencias.
   https://github.com/Laboratoria/executive-training/tree/03-lean-product-management/03-lean-product-management

2. Como indica @lupomontero sería genial poder crear un curso para la currícula de Laboratoria, porque según todo lo que conversamos, estas ocasiones donde los desarrolladores no entienden la verdadera necesidad del cliente son muy comunes en la industria. Por favor, necesitamos tu confirmación si quisieras participar en el desarrollo de la currícula, así @chamodev podrá crear un README donde puedas colaborar.

Muchas gracias!
Claudia

[chamodev]

¡Excelente! Gracias @claudiaalf

@jaiment: me confirmas y creamos el README para arrancar el desarrollo del contenido. :)

[jaiment]

Sí @chamodev inicia el proyecto y me avisas.
P.D. @claudiaalf no veo el repo executive-training

[chamodev]

¡Hola @jaiment!

Listo. He creado la estructura base para el curso en el branch 25-solutions-architecture.

Estoy sugiriendo agregar una parte inicial del curso sobre los diferentes roles para conversar sobre quién es quién :) i.e. Product Manager vs Product Owner vs. Project Manager vs. Solutions Architect vs. ... También creo importante incluir nuestra perspectiva sobre la diferencia entre Productos y Proyectos. Mi recomendación es trabajar esto de la mano con @claudiaalf, quien ya tiene ese contenido.

¿Te parece si le das una mirada y nos juntamos a conversar próximos pasos?

¡¡Gracias!!

[jaiment]

Hola @chamodev.

Listo he revisando la estructura del curso y lo veo bien.
Lo único que me sigue causando dudas es que veo demasiados roles que, por lo menos en mi experiencia, nunca me ha tocado ver en un equipo real y creo que pueden confundir (más que ayudar) a generar claridad en cómo organizar un equipo de trabajo con el objetivo de generar un producto de valor al usuario final.

Los roles que me generan ruido son: Product Manager vs Arquitecto de Soluciones.

La única diferencia natural que observo es que, el Arquitecto crea soluciones que no existen y "dibuja los planos de la obra" antes que ésta se construya.
Mientras que, me suena a que el Product Manager administra un producto que ya está fabricado, como si fuera el administrador de un bien inmueble.

No sé que opines ... ¿?

[lupomontero]

Cerrando issue por inactividad.