Publicado por
el
a las
Tuve el honor de ser invitado a participar en el meetup de Perú .NET Development. Hablé sobre cómo los Soft Skills me ayudaron a convertirme en un mejor developer, y aquí está la grabación de mi participación.
Mil gracias a Julissa por la invitación.
Publicado por
el
a las
De acuerdo con failory, la razón #1 por la que fallan los startups es porque nunca encontraron product-market fit. 34 % de los emprendimientos fallidos son un resultado de no haber identificardo el problema correcto a resolver. Las segunda y tercera razón, marketing y problemas de administración del personal, representan el 22 % y 18 %, respectivamente.
En otras palabras, en 34 % de los startups que fallan, los Product Managers fallaron en
- identificar un problema crítico de sus usuarios
- y diseñar un producto que lo arregle
Si bien el rol de Product Manager existe porque no se puede esperar que todo mundo tenga visión de producto, eso no significa que ellos son los únicos que pueden aportar a la evolución y dirección del mismo. Y es ahí donde todos tenemos que poner de nuestra parte: los contribuidores individuales (diseñadores, programadores, etc.) aportando sus ideas basadas en la construcción del día a día del producto, y los Product Managers tomando esas ideas y convirtiéndolas en hipótesis comprobables.
Lane menciona:
En mi experiencia, las ideas basadas en asunciones que vienen de gente de producto, rara vez son mucho mejores que las que vienen de ingenieros. La diferencia es que un buen Product Manager tiene una necesidad imparable de validar o recahzar cada idea que llega a su cabeza.
De acuerdo.
Creo que el rol del Product Manager no es dictar hacia donde debería de ir el producto, sino funcionar como un catalizador de ideas — moldearlas en hipótesis y validarlas en función de la misión y visión que guían la construcción del producto.
Publicado por
el
a las
El Gobierno de Reino Unido publicó una guía de diseño para agregar “ninguna de las anteriores” como opción a las formas que usen checkboxes en sitios oficiales.
Frankie Roberto explica por qué en el blog de diseño:
A veces, está bien contestar una pregunta dejando todas los checkboxes vacíos. Sin embargo, algunos equipos en el gobierno han encontrado algunos problemas con esto.
Observaron que:
- los usuarios podrían estar inseguros si pueden hacer esto — lo cual puede resolverse usando elementos de guía, pero no todos los usuarios los van a ver
- algunas veces, los usuarios quieren dar una respuesta concreta, especialmente si les preocupa contestar las preguntas con confianza y con la verdad
- dejar los checkboxes desmarcados significa que los usuarios podrían pasar la pregunta por accidente, tal vez pensando que podrían regresar a ella después
Tengo varios comentarios respecto a esto.
Primero, el hecho de que el Gobierno de Reino Unido tenga un blog dedicado a compartir notas de diseño para sus sistemas internos me voló la cabeza.
Segundo, todos podemos aprender de su razonamiento para resolver este tipo de problemas. Cuando se trata de sistemas internos, o en este caso, de gobierno, los que los producimos debemos de tener en cuenta que el 90 % de las veces, las personas que los van a utilizar quisieran no tener que hacerlo. ¿Cuándo fue la última vez que te dio gusto emplear un sistema de gobierno? Aquí, claramente están poniendo como prioridad crear soluciones que realmente le ayuden a su usuario a reducir su carga cognitiva y, por ende, ayudarles a hacer lo que quieren hacer de una manera más confiable.
Un programador podría argumentar, lógicamente, que la ausencia de un valor podría considerarse como una opción válida. Después de todo, no contestar es, en sí mismo, una respuesta. Por otro lado, el usuario argumenta que un no es en sí también una respuesta explícita, y debería de poder usarla.
Qué bueno que ganó la empatía por el usuario, y no los tecnicismos.
Publicado por
el
a las
Un poco de investigación revela que la barra de carga de Gmail no es una barra de carga en absoluto! De hecho, el progreso que se muestra es controlado por una animación de CSS que hace que inicie lento, y luego se quede quieta hasta que Gmail termina de cargar. Esto vence el propósito de una barra de carga: dar un estimado del progreso, no llenarse de manera arbitraria.
Este tipo de problemas es donde muchos programadores pueden “meter el pie”. El impulso inicial de las personas técnicas es hacer las cosas técnicamente correctas, aunque no agreguen tanto valor al producto final o aporten a mejorar la experiencia del usuario.
Tomando en cuenta el caso de uso más obvio de una barra de progreso, comunicar progreso, ¿qué debería hacer Gmail para ofrecer información técnicamente correcta? Sin lujo de detalle, y vagamente en el orden adecuado:
Suena relativamente sencillo; son pocos pasos. Pero toma en cuenta a) la escala a la que opera Gmail, y b) el objetivo real de presentar una barra de navegación, que es darle seguridad a tu usuario de que estás haciendo algo. Considera las implicaciones de hacer un cambio “sencillo” a la escala de Google. Además, la idea de que realmente lo que importa es la experiencia de usuario, y no necesariamente la exactitud de la barra del progreso. Te das cuenta de que implementar una barra de progreso que muestre información técnicamente correcta, realmente no vale la pena.
Por si no te habías dado cuenta, muchas de las barras de carga que encuentras en tu día a día son completamente falsas. Hoy en día, los sistemas son tan complejos, impredecibles y con tanta entropía, que hacer una barra de carga que muestre progreso requeriría una inversión de tiempo que muy pronto deja de ser rentable para el producto.
Publicado por
el
a las
Stephanie Taylor, escribiendo en el el blog de Summer of Code:
Durante los 17 años de GSoC, el ecosistema del código abierto ha crecido y evolucionado, y nos dimos cuenta de que el programa necesita evolucionar también. Con eso en mente, tenemos algunos cambio smayores para la edición de 2022, diseñados para poder servir mejor a la comunidad de las comunidades de código abierto, y dar un poco más de flexibidilidad a los proyectos y contribuidores, para que cualquier presona puede unirse y contribuir a grandes comunidades de código abierto.
Acá están los cambios resumidos:
Tip: Si quieres un crash course de cómo trabajar con personas con diferentes perspectivas, pariticpar en proyectos de código abierto es tu solución.
Ayudo a personas que trabajan con software a mejorar sus carreras profesionales.
Los miembros tienen acceso a Pathways, pueden comentar en las publicaciones, interactuar con la comunidad, y muchos otros beneficios. Conoce más.
Agrégame a tu lector RSS, o suscríbete a mi newsletter para recibir los nuevos artículos que publique.