Hay algunos tipos de personalidad con los que he luchado en el pasado, y he visto que otros Gerentes de Producto luchan con … cada uno de estos tiene la intención de ser un ejemplo extremo, pero muchos de ellos se basan en personas reales con las que he trabajado u oído cuentos de…
- El Sabelotodo : este desarrollador es realmente bueno en lo que hacen, y lo saben. Ellos dominan este conocimiento sobre cualquier otra persona con la que interactúan, siempre que pueden, con un desprecio insensible por los sentimientos de los demás o la propiedad social en general. Afirman conocer a los usuarios mejor que los usuarios, conocer el mercado mejor que las personas que interactúan con él a diario y conocer la tecnología mejor que cualquier otra persona dentro o fuera de la empresa. Son ciegos a sus prejuicios cognitivos y les gusta mantener el poder y el control al ser el único depósito de información clave sobre el producto y su arquitectura y tecnología subyacentes.
- The Ticket-Puncher : este desarrollador es casi exactamente lo contrario del primero; Este es un desarrollador que solo quiere que todo esté claramente enunciado en una especificación de cien páginas que puedan asimilar, comenzar a trabajar, marcar las casillas a medida que avanzan y devolverlo mientras se quitan las manos de cualquier responsabilidad de tomar decisiones o decisiones que realmente mejorarán el producto, la tecnología o la experiencia. También pueden ser autómatas, ya que ejercen la misma cantidad de pensamiento crítico y resolución de problemas que las computadoras que están destruyendo día tras día.
- Este es MI producto : por lo general, es uno de los fundadores o uno de los primeros contratistas de tecnología que sentó el marco y la base de todo sobre lo que se basa el producto. Debido a esto, han entrelazado su propio ego con el éxito del producto que construyeron, y se enfrentan personalmente a la idea de que el producto tiene que evolucionar y cambiar más allá de lo muy centrado que originalmente construyeron. Se aferran a la tecnología vieja y moribunda no porque piensen que es lo correcto, sino porque la idea de abandonar su antiguo trabajo implica que su propia utilidad para la empresa podría verse amenazada de alguna manera sustancial.
- El tipo “El código es lo único que importa” : este tipo está desenfrenado en las organizaciones centradas en la tecnología y orientadas a la ingeniería hoy en día, y cree que lo único que los desarrolladores deberían hacer es el código, y cualquier otra consideración que no sea la tecnología en sí es ridícula e innecesaria . Se oponen a cualquier forma de proceso o medida de eficiencia, y consideran que el “negocio” frena a los equipos tecnológicos, en lugar de proporcionar cosas importantes como cheques de pago y beneficios a las personas que están haciendo el trabajo. Cuando no quieren hacer algo, simplemente no lo hacen en absoluto o eligen y hacen preguntas que realmente no les interesan, simplemente les gusta ver bailar a los PM y Analistas de Negocios.
- El “Peter Gibbons” : robé el nombre de Office Space (una de mis películas favoritas de todos los tiempos), pero Peter es el tipo que hace lo suficiente para no ser despedido. No es incompetente, pero no es un artista estrella. Cuando las cosas empiecen a parecer un poco peligrosas, se aplicará un poco más de sí mismo para eliminar el calor de su espalda, pero dos semanas después vuelve a sus trucos habituales, haciendo lo suficiente para que las cosas se vean bien, pero nunca aplicando más esfuerzo. o creatividad que es absolutamente necesaria.
Habiendo dicho lo negativo, siento que le debo algo de crédito a mis equipos de desarrollo, ya que he trabajado con algunos equipos realmente increíbles … para ese fin, esto es lo que busco en un equipo de desarrollo:
- Autoconducción : no quiero que esperen a que haga una pregunta o les dé instrucciones antes de que experimenten y prueben cosas; Quiero que se sientan y actúen como si fueran miembros independientes y valorados del equipo del producto, y que se involucren sin que se les solicite.
- Competente : esto debería ser obvio, pero cualquier desarrollador debe ser competente con el lenguaje y las herramientas que utilizan a diario para hacer su trabajo; No debería tener que ayudarlos a descubrir TFS o Jira o lo que sea, deberían tomarse el tiempo para aprenderlo. Al mismo tiempo, deben pedir ayuda cuando la necesiten, para que no nos demoremos innecesariamente por otra consideración que no sea el producto.
- Solucionadores de problemas : quiero desarrolladores que puedan tomar una historia de usuario, comprender la declaración del problema que contiene y proponer ideas sobre cómo resolver ese problema. A veces será exactamente lo que está en mi cabeza, otras veces será algo increíblemente mejor, y de vez en cuando es solo una mala idea. Pero que el equipo pueda realizar ese ejercicio es esencial para su éxito.
- Impulsado por el equipo : el desarrollo no es una experiencia en solitario; tienes otras personas dependiendo de ti desde arriba, abajo y a un lado. Por lo tanto, debe adoptar estas relaciones, trabajar dentro de ellas y ayudar a todos a ser mejores en su trabajo. Si eso significa que un desarrollador ayuda a una persona de control de calidad a aprender más sobre las pruebas automatizadas, entonces debe hacerlo. Si eso significa que un desarrollador tiene que dar una demostración a Marketing, entonces debes hacerlo. Todos estamos trabajando para lograr el mismo objetivo, y todos necesitamos ayudarnos mutuamente en ocasiones.
De acuerdo, he continuado el tiempo suficiente … estas son algunas de las cosas que busco y que evito en los equipos de desarrollo.
- ¿Por qué los programadores se jactan de cuántas líneas de código, siendo más grande 'mejor', cuando en realidad los mejores programas son a menudo bastante pequeños para lo que hacen?
- Cómo conseguir un buen trabajo (ingeniero de software)
- ¿Cómo se calcula la bonificación anual basada en el rendimiento para los ingenieros de software de Facebook?
- ¿Qué necesito aprender para ser ingeniero de software desde cero?
- ¿Qué habilidades se esperan de un ingeniero de software experimentado de 1 año?