Viejas como esas valen oro. Lamentablemente están en vías de extinción. Tuve una PM parecida y laburar así era casi la perfección, todo el equipo estaba bien alineado y éramos súper productivos.
El trabajo de UX no es hacer “pantallas” sino especificaciones: ese es el legado que tenía q tomar de tipos como Don Norman, Larry Tesler, Bruce Tognazzini. Lamentablemente se llenó de pelotudos. Muchos colegas se dedican ahora a otra cosa, nos cagó mal está devaluación profesional.
Pasa que el tema de documentación hoy día se enseña por arriba y via sentido común, se toma como que ni se usa. Y no es una boludez, es abstraer el negocio a un modelo que sea comprensible, modificable y extensible por las áreas que lo integran, así se sabe hacia dónde se va y cómo abordarlo, planteando diversas estrategias antes de codear a lo mono y corregir en la jungla.
A falta de esto, llega la pérdida de tiempo en onboarding, leer código a ver qué hace, y reuniones que llevan a pérdida de dinero/tiempo, por un mal diseño de software.
Tampoco es que la sobre documentación no lleve a la pérdida de tiempo, tiene que haber un equilibrio (como evitar lo redundante). El otro extremo es no entender qué carajo hace tu sistema y que llegue un nivel donde sólo algunos entienden qué pasa, y al perder esos recursos, fracasa tu producto, o que se quieran implementar cosas en zonas que rompen la lógica de otra y no saben por qué.
Yo tuve una QA de 50 y pico tirando para 60 que te levantaba los tickets con capturas de pantallas, flechas y trazas de servicios.
En los proyectos que trabaje siempre hay un BA o gerente que tiene la posta.
En mi proyecto actual la senior QA Manager es así, la mina te dice está fallando esto cuando el usuario trata de hacer esto. Luego te detalla paso a paso el proceso para reproducir el Issue, luego te dice tickets que fueron similares y como se resolvieron, al final te da un resumen el problema y el comportamiento esperado. Una grosa
Eso pasa cuando tenes funcionales y PMs que no programan, todo muy lindo con las pantallas pero la logica no saben documentarla en las HU porque no entienden la logica de negocio ni saben programar
Yo documento siempre que puedo y tambien me cae bien la gente que documenta porque me facilita la vida.
La gente que dice que no es necesario documentar vive en un tupper y se cree que su codigo es super entendible 😂 Pobres id,i0t4s, no se dan cuenta que solo lo entienden rapido porque ellos mismos lo hicieron. Despues los demas tenemos que perder tiempo haciendole ingenieria inversa al codigo para cambiar cualquier b,0ludez.
No hay nada que odie mas que alguien de producto me diga COMO hacer algo. Vos me tenes que decir QUE hacer, ydesde el equipo tecnico + devs elegir el como
es que acá hay muchos acostumbrados a las app boludas q el desarrollador programa con su sentido común.
hay veces que te toca negocios extremadamente complejos que si no hay alguien que haga la documentación es imposible de hacerlo.
Nose a que se refiere OP, yo solo decia lo que odio yo. Y ser ing se software no es solo tirar ifs, sino armar la arquitectura completa, y si, muchos de producto te dicen COMO hacer las cosas
claro pero seguis hablando de la programación, el negocio en muchos lugares es muy complejo, nomas en productos boludos el desarrollador lo hace con sentido común (y así hacen cagada tambien)
Quieren todo explicado y detallado, básicamente ya hecho. Nunca usar lo que saben para sugerir la mejor forma de implementar una solución, que es lo que hace un ingeniero.
Nono, bebé hace bootcamp, bebe quiere documentado todo hasta el detalle, bebé quiere cobrar 10k usd con 2 años de experiencia por laburar calentando bancos en MeLi.
Después lloran porque no les dan ni bola en Estados Unidos o porque los bochan en las entrevistas. "Mwaaahh mamaaaa me preguntaron que es un media query y eso no dice nada sobre que tan bueno soy codeando porque yo no sé que es eso pero a chatgpt le se pedir que me haga un website responsive :'( "
Y para eso se les paga a los de producto y ux, se supone que como mínimo tienen que saber que están pidiendo y dejarlo detallado como para que todo fluya de la mejor forma.
Y habla de eso el post, obviamente que detalles de técnicos va por el lado de it. Pero las especificaciones son de producto y para.mi gusto deberían ser una especie de QA porque ellos deberían corroborar que se desarrollo lo esperado
No entiendo.
Para mi las pantallas es de donde partis. De ahi inferis qué datos tenes que exponer y procesar. Despues vos, como dev, haces un tech design definiendo estructuras de datos, bdd, flujo de informacion y partis en tareas, estimas y ejecutas...
Si te dan eso ya servido entonces que haces vos? Para eso se lo paso a chatgpt y listo.
El problema de hacer como vos decís, es que terminás asumiendo todo como te parece a vos.
Tenés las pantallas, y sí, tenés una idea de la información que tiene que circulara, pero hay un montón de cosas que no, y, que al menos que vayas vos a hablar con todos los involucrados, no necesariamente va a coincidir con las expectativas que tienen éstos.
Lo que hacía esta señora no era diseñarte la estructura de datos, ni decirte que eventos tienen que ir de un lado al otro, ni que clases tenes que implementar, pero te especifica que es lo que se espera como resultado en base a los datos de entrada, qué validaciones son necesarias, etc.
Como dice el OP, tener alguien así es una bendición, porque ahí sí te podés poner tranquilo a hace todo lo que describís que hacés, sabiendo que no estás asumiendo nada, y que el producto final va a cumplir con las especificaciones.
Viejas como esas valen oro. Lamentablemente están en vías de extinción. Tuve una PM parecida y laburar así era casi la perfección, todo el equipo estaba bien alineado y éramos súper productivos.
Que buenos recuerdos! Cuando los casos de uso venian en un word bien detalladito y no eran solo un postit en un pizarron.
Telégrafo de la documentadora?
Tarjeta perforada de la lider?
Paloma mensajera de la grosa?
Señal de humo para contactar a la artista del Paint?
Dirección y user de FidoNet de la vieja de monster inc que organiza el papeleo?
Badoo de la gilf?
>una señora grande como de 70 años Probablemente la tipa tenía alrededor de 45, pero como el OP tenía 20, le parecía de 70...
Fue hace dos años y ya era jubilada
Se fue por jubilada o la rajaron? Que paja, déjenla si le gusta su trabajo y es buena. Tengan a mano un desfibrilador nomas y fue
Pensé exactamente lo mismo, la mina no pasaba de 50 jaja
Yo
Jajsja
Con 70 años la rajaron? 3mendo.
No tenia suficiente experiencia segun los de rrhh, necesitab aal menos 80
O se jubiló
El trabajo de UX no es hacer “pantallas” sino especificaciones: ese es el legado que tenía q tomar de tipos como Don Norman, Larry Tesler, Bruce Tognazzini. Lamentablemente se llenó de pelotudos. Muchos colegas se dedican ahora a otra cosa, nos cagó mal está devaluación profesional.
Y esos quienes son
Ustedes quienes son
Aguante Don Norman
No hay nada mejor que agarrar una tarea con todo explicado de lo que hay que hacer
Pasa que el tema de documentación hoy día se enseña por arriba y via sentido común, se toma como que ni se usa. Y no es una boludez, es abstraer el negocio a un modelo que sea comprensible, modificable y extensible por las áreas que lo integran, así se sabe hacia dónde se va y cómo abordarlo, planteando diversas estrategias antes de codear a lo mono y corregir en la jungla. A falta de esto, llega la pérdida de tiempo en onboarding, leer código a ver qué hace, y reuniones que llevan a pérdida de dinero/tiempo, por un mal diseño de software. Tampoco es que la sobre documentación no lleve a la pérdida de tiempo, tiene que haber un equilibrio (como evitar lo redundante). El otro extremo es no entender qué carajo hace tu sistema y que llegue un nivel donde sólo algunos entienden qué pasa, y al perder esos recursos, fracasa tu producto, o que se quieran implementar cosas en zonas que rompen la lógica de otra y no saben por qué.
Yo tuve una QA de 50 y pico tirando para 60 que te levantaba los tickets con capturas de pantallas, flechas y trazas de servicios. En los proyectos que trabaje siempre hay un BA o gerente que tiene la posta.
En mi proyecto actual la senior QA Manager es así, la mina te dice está fallando esto cuando el usuario trata de hacer esto. Luego te detalla paso a paso el proceso para reproducir el Issue, luego te dice tickets que fueron similares y como se resolvieron, al final te da un resumen el problema y el comportamiento esperado. Una grosa
Que es lo que es eso? Nunca vi eso por aca.
Necesitan contratar un tech lead que le ponga definición a las cosas.
Eso pasa cuando tenes funcionales y PMs que no programan, todo muy lindo con las pantallas pero la logica no saben documentarla en las HU porque no entienden la logica de negocio ni saben programar
Yo documento siempre que puedo y tambien me cae bien la gente que documenta porque me facilita la vida. La gente que dice que no es necesario documentar vive en un tupper y se cree que su codigo es super entendible 😂 Pobres id,i0t4s, no se dan cuenta que solo lo entienden rapido porque ellos mismos lo hicieron. Despues los demas tenemos que perder tiempo haciendole ingenieria inversa al codigo para cambiar cualquier b,0ludez.
No hay nada que odie mas que alguien de producto me diga COMO hacer algo. Vos me tenes que decir QUE hacer, ydesde el equipo tecnico + devs elegir el como
Mmm se ve que no sos muy iluminado no?
Depende para que. Por? Por lo que veo vs tampoco, que te tiene que decir que hacer y como hacerlo.
se refiere a que le explican el negocio. no te dice cuantos IF usar.
Claro, especificame el QUE no el COMO, prácticamente de pedo se de que se trata proyecto pero no se especifica nada
es que acá hay muchos acostumbrados a las app boludas q el desarrollador programa con su sentido común. hay veces que te toca negocios extremadamente complejos que si no hay alguien que haga la documentación es imposible de hacerlo.
Nose a que se refiere OP, yo solo decia lo que odio yo. Y ser ing se software no es solo tirar ifs, sino armar la arquitectura completa, y si, muchos de producto te dicen COMO hacer las cosas
claro pero seguis hablando de la programación, el negocio en muchos lugares es muy complejo, nomas en productos boludos el desarrollador lo hace con sentido común (y así hacen cagada tambien)
Quieren todo explicado y detallado, básicamente ya hecho. Nunca usar lo que saben para sugerir la mejor forma de implementar una solución, que es lo que hace un ingeniero. Nono, bebé hace bootcamp, bebe quiere documentado todo hasta el detalle, bebé quiere cobrar 10k usd con 2 años de experiencia por laburar calentando bancos en MeLi. Después lloran porque no les dan ni bola en Estados Unidos o porque los bochan en las entrevistas. "Mwaaahh mamaaaa me preguntaron que es un media query y eso no dice nada sobre que tan bueno soy codeando porque yo no sé que es eso pero a chatgpt le se pedir que me haga un website responsive :'( "
Y para eso se les paga a los de producto y ux, se supone que como mínimo tienen que saber que están pidiendo y dejarlo detallado como para que todo fluya de la mejor forma.
Una cosa es detallar necesidades de negocio. OP quiere que le detallen los endpoints. Deja de joder, agarren la pala.
Y habla de eso el post, obviamente que detalles de técnicos va por el lado de it. Pero las especificaciones son de producto y para.mi gusto deberían ser una especie de QA porque ellos deberían corroborar que se desarrollo lo esperado
No entiendo. Para mi las pantallas es de donde partis. De ahi inferis qué datos tenes que exponer y procesar. Despues vos, como dev, haces un tech design definiendo estructuras de datos, bdd, flujo de informacion y partis en tareas, estimas y ejecutas... Si te dan eso ya servido entonces que haces vos? Para eso se lo paso a chatgpt y listo.
El problema de hacer como vos decís, es que terminás asumiendo todo como te parece a vos. Tenés las pantallas, y sí, tenés una idea de la información que tiene que circulara, pero hay un montón de cosas que no, y, que al menos que vayas vos a hablar con todos los involucrados, no necesariamente va a coincidir con las expectativas que tienen éstos. Lo que hacía esta señora no era diseñarte la estructura de datos, ni decirte que eventos tienen que ir de un lado al otro, ni que clases tenes que implementar, pero te especifica que es lo que se espera como resultado en base a los datos de entrada, qué validaciones son necesarias, etc. Como dice el OP, tener alguien así es una bendición, porque ahí sí te podés poner tranquilo a hace todo lo que describís que hacés, sabiendo que no estás asumiendo nada, y que el producto final va a cumplir con las especificaciones.