El ciclo de vida de la tecnología en las empresas

CICLO DE DESARROLLO DE CUALQUIER PRODUCTO DE TI:

1. La primer pregunta y la más importante para saber ¿cómo abordar un problema en la empresa con innovación? es:

** Cuando entiendes el ¿por qué?, tomas decisiones distintas.

1. Escribir detalladamente las especificaciones del proyecto: razón por qué se hace y el alcance a dónde quiero llegar.

1. Reunir a todos los interesados y conseguir el SÍ (firmado) de todos en la etapa de especificaciones. (el que paga, el que usa, el que hace el proyecto)

1. Crear el boceto (mockup) = primera versión. Es la idea mental de cómo se va a ver; no cohibir la creatividad del equipo que lo convertirá en realidad.

1. Crear un Wireframe = muestra la forma final de cómo se va a ver el proyecto. Es ambicioso y define el alcance del proyecto.
   
   

• El Wireframe debe ser increible, crear emoción de lo ambicioso que es.

1. Crear el equipo:

• Stakeholder: se beneficia del resultado del proyecto. Es el más interesado, puede ser el que aprueba o no el presupuesto del proyecto.
• Product Owner: es al que se le delega que el proyecto salga bien. No tiene que ser una persona técnicamente especializada. Se conecta con el equipo técnico para garantizar que las cosas se hagan realidad. Es el representante de las necesidades de la empresa. Debe entender tecnología, pero debe entender más el negocio, la idea del proyecto o el problema.
• Product Manager: su objetivo es manejar al equipo técnico que hace realidad la ejecución del proyecto. Debe saber de diseño, programación, tecnología; debe tener el respeto de las personas que construyen el proyecto y lo hacen realidad.

1. Dividir el proyecto en etapas de entrega.
   
   
   ** Los grandes proyectos hace pequeñas mejoras iterativas (lanzamiento por etapas a través de A/B testing para medir la percepción de los usuarios).

SEGUIR DOS GRANDES REGLAS:

1. La tecnología se crea hablando con usuarios y creando productos.
2. (Humildad) Todas las suposiciones que tengo son incorrectas y los usuarios me lo demuestran. Lo que importa es lo que haga mi usuario final con lo que creamos.

_* Es recomendable no lanzar un monolito, sino lanzar etapa por etapa. _

TERMINOLOGIA NUEVA PARA MI
Mockup : boceto , primera versión proyecto
Wireframe: diseño detallado,forma profesional de ver el proyecto
Skateholder: líder del proyecto
Product Owner: mano derecha del skateholder, delegado
Product Manager: Líder equipo técnico, tiene conocimiento
especializado.
QA: control de calidad
Deploy: despliegue lanzamiento del proyecto
UI: Interfaz del usuario
UX: experiencia del usuario
Bug fixing: solucionar problemas de especificacion o desarrollo en
el proceso de iteracion de UI y UX.
Feedback: retroalimentacion de informacion entre los equipos
A/B testing: realizar pruebas con unos usuarios y otros no, para medir comportamiento de los mismos.
INFORMACIÓN IMPORTANTE
-habla con tus usuarios así creas tu producto
-Todas tus suposiciones son incorrectas y los usuarios te lo demuestran.

Idea de proyecto - preguntar 5 veces porqués del proyecto para una mejor definición - generar las especificaciones del proyecto, razón, alcance, etc.

Crear Mockup en base a las Specs, luego crear un Wireframe el cual debe ser MUY AMBICIOSO, crear el equipo que desarrollará tu proyecto.

Crear etapas de entregas basadas en pequeños módulos de funcionalidades.
Diseñar el sistema a desarrollar basado en las etapas definidas.

Después de Desarrollar, se pasa a QA para pruebas y correcciones.
Pasando QA, se debe hacer un Deploy o despliegue a producción, pero se recomienda que sea por parte pequeñas, módulos chicos para que tus usuarios se acostumbren poco a poco y no lo rechacen de golpe.

El ciclo de vida de la tecnología en las empresas

Una Idea implica que estás innovando, creando algo nuevo que no existe, esto es una disrupción. Lo más probable es que tengas un problema y por eso estás creando una idea.

Antes de ponernos a planear cómo solucionar con tecnología tenemos que crear un proceso de especificación. Pasos:

1. ¿Por qué? (el sistema de los 5 ¿Por qué?), pregunta 5 veces por qué vas se tiene que resolver eso
2. Escribir la especificación de forma muy detallada del proyecto como tal
   • La razón por la que se está haciendo
   • Cuál es el alcance de dónde quieres que el proyecto llegue
3. Con las especificaciones claras, ahora reúnes a todos los interesados y te aseguras que todos te digan que sí
   • Persona que paga el proyecto
   • Persona que va a estar usando el proyecto
   • Persona que se beneficia del proyecto
4. Ahora con las especificaciones, hay que crear una primera versión para mostrársela a los interesados, o sea un Mockup
5. Luego de tener un mockup construido sigue hacer un wireframe define el alcance del proyecto y qué tan grande va a hacer este, por ende este debe ser ambisioso
6. Con el wireframe listo, da paso a que podamos construir un equipo, las 3 personas más importantes en un equipo son:
   • Stakeholder → Es la persona que se beneficia del resultado del proyecto, la persona más interesa y quién aprueba el presupuesto del proyecto
   • Product Owner → Es la persona que le delegas que el proyecto salga bien, es quién se conecta con el equipo técnico para que las cosas se hagan realidad (Ej. Directora del área), entiende:
     • Un poco de tecnología
     • La idea
     • El negocio
     • El problema que se está resolviendo
   • Product Manager → Es la persona cuyo objetivo es manejar al equipo técnico que hace esto realidad. Esta tiene que saber de:
     • Diseño
     • Programación
     • Tecnología
     • Tener el respecto del equipo técnico✨
7. Para crear las etapas de entrega, tomas el proyecto y lo divides en las etapas mínimas entregables.
8. Después empiezas diseñar el diseño de la etapa 1, apenas el diseño de la etapa 1 este listo puede pasar a desarrollo.
9. En el proceso de desarrollo mientras uno va construyecto pasa a ser probador por el usuario y aquí se ve qué funciona y que no, y pasa a iterar y ajustar el proyecto.
10. Después tenemos que asegurarnos del control de calidad. Este proceso lo hacen los product owners + product manager, pero no lo ejecuta el product manager, aquí se comienza a probar el proyecto con usuarios reales con pequeñas entregas y se le daba feedback al equipo de desarrollo
11. Y por último el Deploy, la etapa de lanzamiento, este se debe de hacer por etapas, y debe hacer A/B Testing de los usuarios, de esto analizamos las métricas para ver la diferencia de comportamiento entre los usuarios que están usando lo nuevo y los que no

‼ Solo debes de seguir dos grandes reglas:

#1. La tecnología se crea hablando con los usuarios y creando producto
#2. Todas las suposiciones que tienes son incorrectas y los usuarios te lo demostrarán

Todas tus suposiciones son incorrectas y los usuarios te lo demuestran.

Habla con tus usuarios y creas producto.

Resumen de la clase

1. Pregunta 5 veces por qué vas a implementar este proyecto.
2. Escribe especificaciones y alcance detallado de lo que quieres lograr. Este documento debe ser aprobado por todas las partes implicadas y firmado.
3. Crea un mockUp o boceto básico en papel.
4. Crea un wireframe (diseño detallado, forma profesional de ver el proyecto). Mega ambicioso.
5. Construye un equipo: Stakeholder (líder del proyecto), product owner (mano derecha del skateholder delegado)
6. y product manager (Líder equipo técnico, tiene conocimiento especializados).
7. Crea un cronograma de entregas con fases de diseño y fases de desarrollo que se puedan ejecutar en paralelo.
8. Haz pruebas de UI (Interfaz de usuario) y UX (experiencia de usuario) con una muestra de pocos usuarios. También testea posibles bugs con un equipo interno (Feedback: retroalimentación de información entre los equipos).
   TODO LO ANTERIOR A PARTIR DE SEGUIR DOS GRANDES REGLAS:
9. La tecnología se crea hablando con usuarios y creando productos.
10. Todas las suposiciones que tengo son incorrectas y los usuarios me lo demuestran. Lo que importa es lo que haga el usuario final con lo que creamos.

chicos, algunos programas y aplicaciones para crear Wireframes:

• Mockflow
• Balsamiq Mockups

Mockflow te permite crear una cuenta gratuita y Balsamiq Mockups te da 30 dias de prueba gratis de sus productos.

También hay como esqueletos de pagina web que los puedes imprimir y hacerlo a mano. todo vale, pero hay que atrevernos a diseñar 😃

Me hizo acordar en la serie Silicon Valley cuando desarrollan su programa de compresión y prueban el Beta solamente con otros programadores, cuando lo lanzan al público en general no lo entienden y dejan de usarlo al poco tiempo.

##Dos grandes reglas para el desarrollo de cualquier producto de tecnología:

1. La tecnología se crea hablando con usuarios y creando producto.
2. Todas las suposiciones son incorrectas y los usuarios te lo demuestran.
   "Es mejor lanzar etapa por etapa un Gran Proyecto que lanzar un monolito."

💡 La comunicación constante y entrega continua e iterativa es la clave para tener buenos productos o servicios.

En el ciclo de desarrollo de tecnología, se debe seguir 2 grandes reglas:
Regla #1
La tecnología se crea hablando con usuarios y creando producto.
Regla #2
Todas tus suposiciones son incorrectas y los usuarios te lo demuestran. Market always win!

Diagrama de Ishikawa (o de pescado)

Me gustaría aprender mas de QA, creo que es de los temas más complicados hoy, porque las empresas de desarrollo quieren desplegar sin las pruebas o la calidad requerida.

Con este cursos encontrè que he estado en un cargo laborar completamente incorrecto 😃

Hola!

Los términos mockups y wireframes se están usando al contrario:

• Los wireframes son la representación de baja fidelidad de un diseño. Su objetivo es comunicar la estructura general de la solución.
• Los mockups son la representación en alta fidelidad de un diseño. Su objetivo es comunicar de forma más detallada y estática la estructura, el contenido, las funcionalidades básicas de una solución.

Saludos!

Creo que no es solo irse por ser el mejor desarrollador sino investigar más sobre la empresa que voy a contratar, si cumple con los criterios necesarios que yo necesito como contratante.

PASO A PASO DE COMO REALIZAR UN PROYECTO:
1-Tenemos una idea ---->2-Tenemos los 5 por que ----> 3-hacemos las especificaciones—>
-----> 4-Mockup------> 5- wireframe---------> 6-Creacion de un equipo-----> 7-Etapas de entrega
Especificaciones: las especificaciones deben ser super detalladas, que es lo que queremos hacer, quienes se benefician, hasta donde queremos llegar. Etc. Cada persona dentro de ese proyecto debe saber de las especificaciones para que entienda realmente que es lo que se esta haciendo y que impacto tiene. ES MUY IMPORTANTE QUE TODOS ENTIENDAN LAS ESPECIFICACIONES Y FIRMEN QUE LO ENTENDIERON.
Mockup: es un boceto de como luce el proyecto, no tiene alto nivel de detalle así no se cohíbe al equipo de desarrollo para hacer el proyecto ni se lo limita. Esto es solo un esquema.
Wireframe: esto es un plano detallado del proyecto que muestra como se vera, como será la distribución, pero sin grandes detalles. Esto en un auto seria la forma del auto, pero sin especificar materiales, etc. Define el alcance del proyecto, debe ser muy ambicioso, uno se tiene que emocionar cuando lo vea.
Equipo: despues del wireframe se tiene que crear un equipo para llevar adelante el proyecto. Las personas mas importantes son:
o Stakeholder: persona que se beneficia del resultado del proyecto. Es el que aprueba el proyecto.
o Product Owner: es al que se delega el desarrollo del proyecto. Es el que hace que las cosas se hagan realidad. Personas que ve el dia a dia. Es el que esta en contacto con el equipo técnico. No necesariamente tiene que saber todo de tecnología no es una persona técnicamente especializado, seria el equivalente director del área, persona encargada de contrataciones, tiene que entender el negocio y el problema.
o Product Manager: este tiene que ser un crack en tecnología, es el que lidera al equipo técnico por lo que se tiene que ganar el respeto del mismo sabiendo mas que nadie sobre todo! Este es el líder del equipo técnico.
Etapa de entregas: no necesariamente se tiene que entregar todo el proyecto entero, podes entregarlo por etapas, e ir actualizándolo. Dentro de la parte de etapa de entregas tenemos tres procesos:
• Desarrollo : aca se desarrolla el proyecto en si, se ven conceptos como: iteraciones de UI/UX, Gub Fixing, ajuste de expectativas. Aca quizás se dan cuenta que el proyecto no es asi como nos lo imaginábamo o que quizás haya que cambiar ciertas cosas
• QA: Tenemos el análisis de calidad. Se hace entre el product Owner y el Product Manager, pero no lo realiza el product manager. Se recibe las entregas pequeñas y se prueba en una cuota muy pequeña de usuarios reales donde ellos dan su feedback y asi se mejora el producto comprueban que asi como esta funciona bien, es un proceso de counicacion constante y cíclica entre usuarios y desarrolladores.
• Deploy(lanzamiento): esto se tiene que hacer pore tapas. Siempre va por etapas. FIjemnosnos el caso de Facebook o Instagram. No cambian toda la interfaz de un dia para el otro, sino que van cambiando de a poco cositas chiquitas, entonces prácticamente uno no se da cuenta cuando fue la ultima vez que se realizo un cambio. Haciendo los lanzamientos de a poco vas testeando, tomando métricas, vas viendo que sirve y que no, etc. Por otro lado si cambias todo de una, el usuario se va a enfadar porque no encuentra los botones o tiene que aprender a usar tooooda la interfaz de vuelta. Se hace un A/B testing que es probar nuestro producto anterior con clientes y probar el producto mejorado con clientes entonces vemos en cada caso cual es mejor, en cual los clientes hacen lo que queremos, en cual se sienten mas comodos, cual les sirve mas, etc.
REGLA 1: hablar siempre con el cliente
REGLA 2: Todas las suposiciones son incorrectas, los clientes son los que deciden si estan bien o estan mal.

Idea o problema: analizar con los cinco ¿por qué?
Escribir las especificaciones claras del alcance del proyecto
Reunir a todos los interesados y tener el SI de todos los interesados que entendieron y están de acuerdo
Mockup (boceto)
Wireframe - define el alcance del proyecto - como se va a ver - debe ser ambicioso
Se recluta al equipo:
Stakeholder
Product owner
Product manager
Se crean etapas de entrega (mínimos entregables)
Se crean etapas de diseño de cada etapa
Desarrollo
iterar interfaz del usuario UI/UX
bug fixing
ajuste de expectativas
Product Manager/Product Owner hace QA+
Pequeñas entregas
Pruebas de usuario
Feedback
Deploy
Un cambio por etapa
A/B testing
Métricas

El generar suposiciones, es un pecado que solemos cometer, pero que es parte de la experiencia en el desarrollo de un proyecto. El usuario final siempre sera el ente más importantes, de quien recibimos el feedback y de quienes tomamos las sugerencias, para cualquier tipo de proyecto y/o producto.

Creo que algo que también debemos aplicar a las decisiones de nuestra vida diaria son los 5 ¿por qué?.

Nos volverá mas cocientes y podremos tomar mejores decisiones que nos potencien 😄

Hasta que punto se considera una falla del SW un bug? Es decir, cuál es el nivel de tolerancia permitido en cada fase. Hay SW en el mercado que tiene bugs pero se amparan en cosas como “la tecnología tiene un margen de error” y pareciera que siempre estamos en lanzamientos Beta… en fin hay muchas justificaciones.

Interesante lo de lanzar etapa por etapa, siempre creí que era mejor hacer un cambio radical. Pero realmente para el AB testing es clave.

Me encanto la analogía del porqué y como Toyota plantea futuros desarrollos. Además me quedo clarísimo el proceso del ciclo de vida de la tecnologia en las empresas.

Para elaborar un proyecto de software es necesario conocer los 5 por qués por el cual es necesario su creación. Una vez contestados, es imprescindible reunir a todas las personas que de alguna manera u otra están relacionadas con el proyecto para identificar las especificaciones de lo que debe incluir, hasta obtener la aprobación de cada uno de ellos.

Luego, se requiere crear un Mockup que es una versión sencilla (boceto) de lo que será el proyecto para comprensión de los involucrados, esto permite que no se cohíba la creatividad del equipo que estará llevando a cabo el proyecto.

Después, se construye el Wireframe que es una forma mas profesional de como se verá el proyecto. Define el alcance del proyecto y debe ser ambicioso.

Una vez creado el Wireframe se crea un equipo compuesto por el Skateholder, Product Owner y Product Manager.

“Toyota redefinió por completo su proceso de desarrollo haciendo 5 Por qués”.

A continuación, un ejercicio sobre cómo Toyota logró desarrollar el automóvil híbrido Prius:

• ¿Por qué Toyota pudo fabricar el auto híbrido Prius? Porque Toyota tiene poder de innovación.

• ¿Por qué Toyota tiene poder de innovación? Porque tiene poder para pensar en la innovación.

• ¿Por qué tiene poder para pensar en la innovación? Porque los empleados de Toyota saben cómo pensar para encontrar la causa raíz de cualquier problema y saben cómo solucionarlo.

• ¿Por qué los empleados de Toyota saben cómo pensar para encontrar cualquier problema y saben cómo solucionarlo? Porque todos los procesos de la compañía están estandarizados.

Si quieren saber más, les dejo un post que escribí en mi blog. Cómo Solucionar cualquier problema con los 8 pasos del método TOYOTA

• Entender la problemática que se desea solucionar y los beneficios que se esperan del proyecto.

• Identificar los requerimientos de alto nivel con el objetivo de tener una visión global del proyecto.
  Identificar a los interesados los cuales serán afectados de manera positiva o negativa por el resultado del proyecto.

• Recopilar los requisitos y definir el alcance por cada una de las etapas o iteraciones del proyecto.

• Verificar que los entregables cumplan los requerimientos.
  Durante todo el proyecto se tiene que validar y controlar los alcances para evitar caer en algo llamado Corrupción del alcance.

No importa si el ciclo de desarrollo es ágil o predictivo siempre tienes que planear, ejecutar, monitorear y controlar el trabajo del proyecto y por último cerrar el proyecto o cada una de las fases o iteraciones

Mockup (Maqueta).

Pueden quitar esa oferta con el segundero que cambia. Es un distractor de la clase

Creo que una de las cosas más explícitas de un jefe (de repente, de un mal jefe) es creer que se las sabe todas.
La falta de humildad quiebra negocios, despide gente y puede hasta acabar vidas.

Mockup : boceto , primera versión proyecto

Como me encantan los cursos instruidos por Freddy cada segundo es contenido es valioso conocimiento!

REGLAS BASICAS:
Interactúa con los usuarios
Todas las suposiciones no importan, los usuarios tienen la ultima palabras

No importa quienes seamos, las suposiciones que tengamos son incorrectas. Solo los usuarios son quienes nos dirán.

Algo que no me quedo muy claro fue que en la parte de desarrollo UI y UX BUG FIXING, también ¿ya se escribe código verdad? o es antes en la parte de diseño cuando ya se tiene listo los wireframes y ya se va escribiendo codigo y se empalma con los diseños de interfaces de usuario y la experiencia.

En el caso de Hertz y Accenture, querían comprar la tecnología especifica, que solventara todas sus necesidades, pero realmente tenían que hacerlo de la mano, no delegarlo. Ya que iba a hacer una VENTAJA COMPETITIVA, que se usaria para capturar mercado otra vez (o dejar de perder), pero trataron a Accenture mas como un proveedor que un equipo in-house, lo cual se necesitaba para este proyecto,

En mi experiencia el éxito de un proyecto se basa en:
1. La comunicación con el usuario
2. Las entregas tempranas y en iterar para asegurar que las necesidades del usuario sean resueltas.

Adicional, asegurar la calidad del software es un proceso vital que no debe falta en el ciclo de vida del desarrollo de ninguna empresa, esto evitará grandes dolores de cabeza y gastos adicionales en el momento de utilizar la herramienta

Delegar en un tercero una competencia estrategica sin la supervision de un equipo interno que asegurara su ajuste al mercado. Faltó integración del software al negocio. Faltaron pruebas en ciudades y entregas parciales que validaran los requerimientos de los usuarios.

Resumen del ciclo:

1. Pregunta 5 veces el porqué vas a implementar este proyecto.
2. Escribe especificaciones y alcance detallado de lo que quieres lograr. Este documento debe ser aprorobado por todas las partes implicadas.
3. Crea un mockUp o boceto básico en papel.
4. Crea un wireframe detallado digital.
5. Construye un equipo: Stakeholder, product owner y product manager.
6. Crea un cronograma de entregas con fases de diseño y fases de desarrollo que se puedan ejecutar en paralelo.
7. Haz pruebas de UI (Interfaz de usuario) y UX (experiencia de usuario) con una muestra de pocos usuarios. También testea posibles bugs con un equipo interno.

1. ¿POR QUÉ? 5 ¿POR QUÉ? – De esta manera nosotros podemos hallar la realidad de los problemas. Cuando entendemos el por qué, tomamos decisiones distintas.
2. ESPECIFICACIONES DEL PROYECTO: Descripción del proyecto y detallar el alcance de qué es lo que queremos lograr. Debe ser tan detallado que las personas entiendan todo lo que vamos a necesitar. TODOS deben entenderlo.
3. REALIZACIÓN DE MOKCUP: Primera idea mental del proyecto. –
4. WIREFRAME: Cómo se va a ver el proyecto finalizado. Define el alcance del proyecto. – Debe ser ambicioso, debe ser increíble!
5. EQUIPO:

• Stakeholder: Quien aprueba PPTO
• Product Owner: El encargado de revisar el proyecto y que salga bien
• Product Manager: Persona encargada de manejar el equipo para hacerlo realidad.

1. ETAPAS DE ENTREGA: Se divide el proyecto por etapas de entrega.

• Etapas de diseño: 1, 2, 3, 4.

1. DESARROLLO: Iterar en la interfaz del usuario UI/UX – Ajuste del proyecto
2. QA: Revisión de procesos de calidad - Se reciben las entregas pequeñas y se da retroalimentación .
3. DEPLOY: Lanzar poco a poco para etapas: A/B Testing, comportamiento de lo nuevo vs lo viejo.
   REGLA 1: La tecnología se crea hablando con usuarios y creando productos
   REGLA 2: Todas las suposiciones que tengamos son incorrectas, lo único que importa es lo que el usuario final nos da.

Mis apuntes con flechas y supremamente abreviados:

Specs --> Mockup --> Wireframes [ Alcance de proyecto] --> Equipo requerido [Stake Holder, Product Owner, Product Manager] --> ETAPAS DE ENTREGA --> (Parciales por mejora It’s better) —> a.etapa 1 b. etapa 2 c. etapa 3, etc… > Desarrollo —> UX, UI <—> [Bug Fixing, Ajuste de expectativas] <-------> QA [Pequeñas entregas, Pruebas de usuario, Feed back] <—> Deploy (Uno x etapa [ Pequeños cambios], A/B Testing [métricas de usuario a vs b])
Regla 1 La tecnología se crea hablando con los usuarios
Regla 2 Todas mis suposiciones son falsas
😃

Nunca me imaginé el papel preponderante de los 5 porqués, el mockup y el wireframe para guiar la construcción de un producto de software.

Con respecto a la regla N° 2: Podría aportar que la plataforma de platzi, es perfecta en velocidad de carga en la forma en como te enseña, pero en su interfaz y experiencia de usuario no es del todo bueno. ya que te carga con demasiada información, en la parte de tus cursos, cuando tu solamente quieres ver el porcentaje de tu progreso, cuantos subcursos te falta para acabar el curso total, y llevar todo la parte de comentarios y los cursos adicionales a otro modulo, con botones y no mostrarte todo en la cara. 😃

Me gustó mucho aprender sobre el concepto 5W de Toyota (5 por qués).
De repente empiezas a tener un profundo conocimiento sobre las razones de por qué algo debe suceder.
Pero más importante CUANDO ENTIENDES EL PORQUÉ, TOMAS DECISIONES DISTINTAS.

El vehículo no arranca. (El problema)
¿Por qué? - La batería está muerta. (Primer ¿por qué?)
¿Por qué? - El alternador no está funcionando. (Segundo ¿por qué?)
¿Por qué? - La correa del alternador se ha roto. (Tercer ¿por qué?)
¿Por qué? - La correa del alternador fue mucho más allá de su vida de servicio útil y no se ha sustituido. (Cuarto ¿por qué?)
¿Por qué? - El vehículo no se mantiene de acuerdo al recomendado programa de servicio. (Quinto ¿Por qué?, una de las causas)

No me quedo tan claro que hace el product owner, pero yo lo definiría de esta manera:
Persona encargada de que el proyecto se desarrolle correctamente y que se cumpla. No sabe mucho de habilidades técnicas como lo es el product manager.
Quisiera saber qué más hace un product manager más a detalle y les agradecería sus respuestas.
Gracias 😃

Ojo allí, enfoque de desarrollo desde el usuario. Hay algo incluso adicional que está luego del Deploy que está en la mejora continua… también un proceso desde el inicio hasta el final que mientras se desarrolla entrega y mide, también se mide el valor de esta (value realization, muy pero muy compleja)

De parte de Hertz falto supervisión, involucrarse en los procesos y revisar continuamente los avances, al entregar el control del proyecto a Accenture estos se perdieron al no tener exigencia en avances y tiempos de entrega.

Identificar a los dueños del proceso que se desea automatizar, es una técnica que usamos en la firma y es con ellos con quien hemos construido las soluciones, pero como dice Freddy Los usuarios finales tienen un poder increíble de hacer cosas que Jamas se le ocurren al equipo de desarrollo de ahí la importancia de escalar y entregar por etapas, pues así evitamos la famosa frase “y como hago x cosa? en el programa?” y la típica respuesta "Nadie nos dijo que necesitaban eso "

impresionante la forma en que se estructura el desarrollo de estos proyectos justo en este momento me llego una fantastica idea que espero una vez termine la pandemia tenga un buen impacto en mi pueblo

Esta clase me ayudó mucho a diferenciar y entender máslos roles del Product Owner y el Product Manager

1.- Habla con tus usuarios:
Tú puedes tener una idea de como se usará el software que creaste o de cómo crees que va a interactuar el usuario pero cuando validas con el usuario el proyecto suele pasar que este lo usa de una forma distinta, o sigue caminos que no contemplabas que usará. Es como que construyes un camino que se divide en 2 y el usuario decide ir por el pasto, es una interacción que no esperabas, pero para el usuario es valido porque igual cumple su objetivo de llegar a su destino.
2.- Tus suposiciones nunca serán correctas:
Esto se complementa con el primer punto porque al desarrollar el proyecto según tus criterios y sin consulta previa del usuario, puede darse el caso que al momento de la entrega ocurra conflicto de ideas.

Ahora entiendo lo que hemos vivido como usuarios de Platzi con el desarrollo del nuevo home.

Muy interesante e increíble conectar los puntos de mi perspectiva como usuario y tratar de imaginar como debió ser tras bambalinas (con el team Platzi).

Regla 1. La tecnología se crea hablando con usuarios y creando producto.
Regla 2. Todas mis suposiciones son incorrectas. Los usuarios lo demuestran, no importa cuantos años lleve en la industria.

Definitivmaente tenía que hacer este curso antes, tengo muchísimas ideas sobre mi proyecto que me surgen y de como llevarlo a cabo.

Proceso de especificación.

Antes de dar una solución con tecnología, tenemos que crear un proceso de especificación.Preguntemos ¿EL POR QUE?

Esta clase es super importante y es una bomba de información. Lo repase tres veces jaja

Es interesante este dato del ciclo de las tecnologias. Nunca pense que el usuario siempre va a tener la razon con respecto al desarrollo de las aplicaciones. Es un dato muy interesante. Uno pensando que siempre es el desarrollador pero al final son ellos que van a consumirlo. Es mejor escucharlos y de ahi sacar las ideas y si hay algun acuerdo. El producto sera exitoso.

Que buenísima explicación,

El ciclo de vida de la tecnología en las empresas

.
Antes de plantearnos solucionar una idea o problema con tecnología debemos crear un proceso de especificación empezando por un ¿por qué? Hacer estas preguntas es muy importante porque nos dan una visión más profunda de la idea o problema que estamos abordando. Responde por lo menos 5 por qué para entender la realidad y razones por las cuales vale la pena solucionar algo. Cuando entiendes el porqué de las cosas, tiendes a tomar decisiones más consientes y razonables para solucionar un problema.
.
El siguiente paso es escribir muy detalladamente las especificaciones del proyecto y hacia dónde quieres que llegue. Esto, para que el equipo encargado de desarrollar tu proyecto tenga muy claro lo que debe hacer y lo que no.
.
Luego, debes reunir a las partes interesadas e implicadas en el proyecto para asegurarte de que todos estén conformes con lo planeado y las especificaciones dadas, para luego tener una aprobación de todos.
.
Después, con las especificaciones aprobadas, el dueño o administrador del proyecto, que sabe como crearlo, debe hacer una **primera versión muy primitiva (mockup) **de cómo se vería el proyecto. Esta versión debe ser una especie de boceto muy abstracto que plasma las descripciones de tu proyecto en la vida real.
.
Una vez construido este boceto, se construye un wireframe que es una vista previa más profesional de cómo se vería el proyecto final. Esto define el alcance del proyecto, que tan grande o pequeño puede resultar. El wireframe debe ser ambicioso porque debe reflejar la idea en su máxima expresión de desarrollo.
.
El paso siguiente es construir el quipo que se encargara del desarrollo del producto. Este equipo debe tener un Stakeholder (persona que se beneficia directamente del proyecto), un Product Owner (persona a la que le delegas que el proyecto salga bien) y un Product Manager (persona que administra al equipo).
.
Ahora, se crean las etapas de entrega a partir de dividir el proyecto en pequeños “hitos” o pedazos que demuestren el avance del proyecto. Por este motivo, el wireframe debe ser ambicioso, porque un buen proyecto mejora y despliega rápido pequeñas funcionalidades sin esperar que el resultado final sea perfecto.
.
Con las etapas de entrega creadas, se empieza el proceso de diseño de cada etapa. Con el diseño de la primera etapa, puedes empezar a trabajar en el desarrollo o programación de esa etapa, e ir trabajando en el diseño de la próxima etapa.
.
En la etapa de desarrollo, debes iterar entre la interfaz del usuario o UI y en la experiencia del usuario o UX para identificar errores, corregirlos, mejorar la experiencia, y seguir iterando. A medida que el proyecto avance, se deben ajustar las expectativas, esto es, porque en la realidad, ahí ideas que no funcionan tan bien.
.
Lo siguiente, es asegurarnos de que exista un control de calidad o Quality Assurance que normalmente son realizados por el Product Owner en alianza con el Product Manager. En este proceso, se reciben las pequeñas entregas que son probadas con un pequeño porcentaje de usuarios, quienes darán retroalimentación o feedback que se le da al equipo de desarrollo para mejorar el producto final. Esto es un proceso cíclico y constante de mejora y comunicación continua.
.
Por último, está la etapa de despliegue o depoly que se debe hacer en etapas pequeñas. Acá se hace A/B testing, que significa lanzar para unos usuarios, y para otros no con el fin de recopilar datos, hacer mediciones y análisis que mostrarán el comportamiento de las nuevas implementaciones y que tan aceptadas son por los usuarios.
.
Esto es todo, lo único que hay que hacer es seguir dos reglas fundamentales:
.

• Regla #1: Hablar con usuarios constantemente y crear producto.
  .
• Regla #2: Todas las suposiciones que tú tienes, son incorrectas y los usuarios te lo demuestran.

PASOS DEL CICLO DE DESARROLLO DE LA TECNOLOGÍA
Start with “WHY”

Especificaciones del proyecto, razón por la que hace y alcance de donde querés que el proyecto llegue

Reúnes a los interesados y te asegurás que te den el sí TODOS -->

1. MOCKUP: BOCETO. PARA IDEA MENTAL. ABIERTO A EDICION DE LOS DISEÑADORES

• Luego…

1. WIREFRAME: FORMA FINAL DE PROYECTO ANTE EL DISEÑO DEFINITIVO. ÁREAS INTERACTIVAS, BOTONES, ÉTC. ALTA RESOLUCIÓN. DEFINE EL ALCANCE DEL PROYECTO. DEBE SER MUY AMBICIOSO

• Luego, con el wireframe listo construis el equipo

Stakeholder: beneficiado del resultado del proyecto. persona mas interesada, quien aprueba o no el resultado del proyecto. Suelen ser los gerentes/directores
Product Owner: persona en tu empresa a la que le delegas que el proyecto salga bien. Se conecta con el equipo técnico, ve el día a día de las necesidades de la empresa. Suele ser el director del área, contrataciones, entiende negocio, idea y problema
Product manager: persona cuyo objetivo es manejar el equipo técnico que hace eso realidad: diseño ,programación, tecnología y tener el respeto de los ingenieros y diseñadores que se encargan.

• ETAPAS DE ENTREGA

Un buen proyecto va iterando. Por eso etapas de entrega. Con cada uno de los wireframes de cada etapa. Divergencia -->Convergencia

• DESARROLLO
  Iteraciones de UI /UX
  UI: parte visual como se ve
  UX: forma en la que el usuario final del proyecto lo usa. arreglás errores con el contacto con el cliente(bug fixing y ajuste expectativas)

• QA(Quality Assurance)
  Lo suele hacer el product owner en alianza al product manager pero el manager no interfiere.
  Se prueba con usuarios reales(innovadores) y se da feedback al equipo de desarrollo.

• DEPLOY

A/B testing: Los grandes proyectos se hacen con pequeñas mejoras iterativas. Poco a poco por etapas. Se lanza para algunos y para otro no. Y con eso se arman métricas.

REGLAS TECH
1)HABLAR CON USUARIOS MIENTRAS VAS CREANDO EL PRODUCTO
2) TODAS LAS SUPOSICIONES SON INCORRECTAS Y LOS USUARIOS TE LO DEMUESTRAN

Conformar un equipo.

idea/problema -> 5 por que -> especificaciones -> boceto(Mocup) -> wireframe -> stakeholder(product owner, product manager) -> etapas de entrega -> Diseño 1,2,3,4 -> Desarrollo (pruebas de usuario UI/UX), bug fixing, ajuaste expectativas -> QA feedback -> Deploy

regla 1 - habla con usuarios / crea producto

regla 2 - todas las suposiciones son incorrectas y los usuarios de lo demuestran

No entiendo por que no habló de los que hacemos QA, no los PO, somos normalmente los testers, quienes hacemos esta parte de control de Calidad… Pareciera que por aquí no quieren a los QA… 😒

Hay una tema que yo llamo falla de origen que es si no tienes claro que es lo que el usuario final vera (desde su pc hasta su tlf) y no está bien documentado en el contrato ya desde el inicio cualquier proyecto comienza con una falla, estos proyectos complejos que casi siempre terminan en litigios deben estar blandas las expectativas del cliente.

Una idea nueva es una creación

El creador debe estar consiente que puede ser mejorada su idea eso son los 5 porques !!

cuidado en creer que es lo ultimo y lo mejor

Hay como mejorarlo SIEMPRE

👉 El ciclo de vida del software es importante porque divide este proceso complejo en diferentes fases. Así es más fácil evaluar cada parte y simplifica el trabajo simultáneo de los programadores en cada una de ellas.

Erroreres Hertz:
Falta de definición de entregables claros, y una ingeniería de requerimientos especificada.
Falta de auditoría y controles tempranos.
Falta de clausulas de salida por incumplimiento de las partes.
Ceder el control total del proyecto

CICLOS O ETAPAS DEL DESARROLLO DE UN PROYECTO DIGITAL

Cuando entiendes el porque, tomas decisiones distintas.

El error de Hertz no fue exigir que los Product Owner no fueran ellos, que son los especialistas del negocio. No se tuvo en cuenta en fases tempranas del proyecto la integración de la plataforma BackEnd.

n

El tema no es crearle al producto e idea, problemas que no existen o que justifiquen su existencia. Fracasa y terminan perdiendo dinero y tiempo.
Entender el por que, hace que estamos yendo por el camino correcto, pudiendo tomar decisiones mas certeras.

Entender el contexto, para comprender al usuario, y como resultado plasmar lo que hace la solución para el usuario y como hace match con el problema o idea

mg

######Specs:

Explicar las especificaciones, que todos entiendan el problema y que todos acepten la solución.

#####Mockup:

Especie de boceto, primera idea de como se verá el proyecto.

#####Wireframe:

Te muestra la forma final del proyecto pero no especificamente el diseño.

#####Equipo:

• StakeHolder: Sale beneficiado del proyecto, entiende muy bien la idea.

• Product Owner: A la que delega que el proyecto salga bien, entiende el negocio.
• Product Manager: La que maneja el equipo, debe saber de diseño y desarrollo.

#####Etapas de entrega:

No debe estar todo el proyecto para entregarlo,

######Desarrollo:

Iterar UI/UX (interfaz de usuario y experiencia del usuario).

#####QA:

Pruebas de usuario y dar feedBack al rquipo de desarrollo (Product Owner).

#####Deploy:

• Por etapa: Evita el rechazo de los usuarios.

• A/B testing: Lanza la prueba para algunos usuarios y ver si es beneficioso el cambio.

Yo hubiera especificado en el contrato todos los detalles y resultados esperados.
Hubiese asignado un product manager para supervisar el proceso y lo hubiese incluido en el contrato.
Al parecer el contrato no estuvo bien claro por lo que Acenture pidió dinero adicional de lo acordado.

Product Owner y Product Manager diferencias

El ceder el control a un tercero del 100% del producto que buscaba ser un elemento clave de su estrategia, si un involucramiento correcto y activo de parte del board de Hertz y de su equipo tecnico genero una situacion donde pone en riesgo la estabilidad de la empresa y su futuro.

Hay elementos donde se debe tener un involucramiento directo y claro de todos los niveles de la organizacion y de la conciencia que debe haber en realizar un elemento que objetivo estrategico cumplo o respondo al realizar este proyecto.

Directo y Sencillo!

¿Cómo abordar un problema en la empresa con innovación?

Tal cual como lo indica Freddy, así se lanzan los productos, por experiencia puedo decir que para entregar el proyecto y que este no se convierta en un ciclo infinito de iteraciones, se debe seccionar en etapas y definir entregables claro. Esto tiene un efecto mayormente psicológico, ya que cada meta o hito se siente más cerca, más alcanzable y el equipo puede probablemente llegar al final de una semana sintiendose bien de haber entregado o logrado la meta de la semana, en vez de probablemente relajarse con una meta que tiene para dentro de dos meses.

Equipo par aprobar la etapa de Wireframe

Muy interesante lo del A/B testing, en mi caso me gustaba mucho más el anterior home de platzi, creo que era mucho mas facil de interactuar y visualizar.

escuchar al usuario, crear, no suponer a veces es inevitable. ser humilde para aceptar la supociones que no fueron correctas.

Los stakeholder no son todos los involucrados? Saludos

Entonces la frase: “El cliente no sabe lo que quiere hasta que lo tiene”, no aplica en estas situaciones.

https://mosaic.uoc.edu/2015/09/15/proceso-de-desarrollo-de-un-proyecto-digital/

Entender el porqué.

Obtener el Sí de todos los interesados.

Iterar en
UI -> Interfaz del usuario y
UX -> experiencia de usuario …

Los cinco ¿por qué?.

Comunicacion constante y entrega continua e iterativa es la clave

Stakeholder.