3️⃣ características de un buen equipo de producto según #Inspired:

1️⃣ Los riesgos se abordan antes de decidir construir algo.

Los riesgos pueden ser sobre el valor, usabilidad, viabilidad o de negocio.
Se trata de construir lo correcto y evitar desperdicios
2️⃣ Los productos se definen y diseñan de forma colaborativa en lugar de secuencial.

Se acabó esa división entre los que piensan y los que construyen. Todos piensan. Todos colaboran para lograr el mejor producto
3️⃣ Se centran en resolver problemas y no en implementar funcionalidades.

No siguen el roadmap a ciegas. Entienden el problema y se aseguran de que la solución realmente resuelve el problema.

Su objetivo es resolver el problema y dar valor al usuario

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Julio César Pérez

Julio César Pérez Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jcesarperez

Dec 4
🧵 A nivel de controlador, debería usar test unitarios o de integración?

La respuesta es los 2
Escribe tests de integración sobre tus controladores para los happy paths.

Serán tests que aporten mucha confianza por ser de aceptación o e2e.

Al ser happy paths no te costará mucho inicializar el contexto para que no sean frágiles y merezca la pena el coste
Escribe tests unitarios sobre tus controladores para lo que no sean happy paths con ayuda de mocks.

Lo que no son happy paths pueden ser casos de error o también casos raros o extremos que no estaban cubiertos.
Read 9 tweets
Oct 1
🧵 Conoces la ley de las abstracciones débiles?

"Todas las abstracciones no triviales son, hasta cierto punto, débiles."

Las abstracciones no triviales tienen fallos. Tienen huecos en su intento de abstraernos de la complejidad. A veces son pequeños, a veces más grandes
El ejemplo típico de abstracción débil (no trivial) es ese framework o librería de buen tamaño que usas todos los días. Llámalo Angular, React, Spring, Entity Manager, Django o el que sea.

Ese framework lleno de magia que te permite ser súper productivo en el día a día
Aunque esa magia del framework, la abstracción, tiene fallos.

Es maravillosa para resolver problemas sencillos.

Pero luego hay problemas que se convierten en un infierno de resolver. E incluso llega un punto que te das cuenta que no se pueden resolver con el framework
Read 8 tweets
May 21
🧵 Uno de los primeros objetivos que se le ponen a un junior es ser autónomo.

Ser autónomo no es hacerlo todo solo, sin necesidad de ayuda.

Todos necesitamos ayuda. Junior y no juniors. Porque hacer software es difícil

Entonces qué queremos decir con ser autónomo?
Ser autónomo es tener un mínimo de capacidad. Pero no es sólo eso.

Es obvio que necesitas tener un mínimo de dominio en al menos:

- Programación
- Lenguajes y frameworks
- IDE y otras herramientas
- Arquitectura y Diseño
- Negocio
- Buenas prácticas

Pero hay más
Cuando tengas ese mínimo, vas a seguir necesitando ayuda. Vas a necesitar hacer preguntas.

Nunca serás buen dev si no haces preguntas y tus fallos se descubren en una review. O peor aun, en Producción.

Ser autónomo también es saber cuándo hacer preguntas y qué preguntas hacer
Read 7 tweets
Apr 2
🧵 Hace ya unos meses que hemos cambiado el formato de nuestra Daily y no puedo estar más satisfecho con el resultado.

Os lo cuento 👇
Antes, usábamos el clásico formato de las 3 preguntas: qué hiciste ayer? qué vas a hacer hoy? qué problemas tienes?

Este formato convierte la daily en una reunión de reporting al poner el foco en ir interrogando persona a persona para informar al PO
Cada persona espera su turno y contesta las preguntas, pero ofrece poca información útil al resto del equipo.

Se le da demasiada importancia a justificar el trabajo realizado ayer.

Cuando no es tu turno, pasas a ser más un espectador. Tu participación y atención es escasa
Read 10 tweets
Aug 28, 2021
TDD no es una receta. El hilo 🧵
La teoría de TDD es fácil. Rojo, Verde, Refactoring.

Lo dificil es hacerlo bien y dominarlo. Para ello se requiere habilidad pero sobre todo, mucha práctica
Es como montar en bici. La teoría es fácil. Montarte, sujetar el manillar, pedalear, girar, frenar, etc.

Dominarlo te va a llevar tiempo y varias caídas
Read 8 tweets
May 4, 2021
🧵Cuáles son las skills que considero básicas para llegar a ser senior?

Disclaimer: esto sólo es mi opinión basada en mi experiencia y blablabla
👇
1️⃣ Comunicación
La comunicación es esencial en todo trabajo en equipo.
Un senior tiene que comunicar más y mejor. Con todo el mundo.
Su comunicación debe ser efectiva. Elige bien el cuándo, el canal, el modo, las palabras y el tono
2️⃣ Iniciativa
De un senior se espera que resuelva impedimentos, que haga preguntas, que opine, que tomes decisiones, que ayude a sus compañeros, que sea curioso, que diga No cuando toque.
Y sobre todo, que no se quede parado esperando que le digan lo que tiene que hacer
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(