¿Qué términos de programación debe conocer un gerente de producto?

Bien, antes de responder qué términos de programación debe conocer un gerente de producto, intentemos averiguar por qué necesitarían conocerlos en primer lugar.

La comprensión técnica ayuda al gerente de producto a comprender lo que es posible frente a lo que no es posible .

En otras palabras, un gerente de producto necesita tener un conocimiento íntimo de cómo funcionan las cosas .

(Por otro lado, para ser completamente honesto, creo que esto se aplica a cualquier función de producto, proyecto o proceso. Sin entender cómo funcionan las cosas, difícilmente puede administrar un proyecto en cualquier industria, ya sea petroquímica, construcción o web de consumo).

Aquí hay una simple prueba de fuego para usted:> ¿puede explicarle a un niño de 5 años cómo funciona el servidor web, es decir, qué sucede cuando abre una página web? Si no, entonces seguramente no posee suficiente conocimiento de alto nivel sobre TCP / IP, HTTP y DNS – cómo funcionan las cosas 🙂

Dicho esto, no discutiría los términos de programación que un gerente de producto necesita saber, prefiero enmarcar su competencia técnica en torno a lo siguiente:

1. Conceptos de programación : ¿comprende la diferencia entre la ejecución del lado del servidor o del lado del cliente? Si un desarrollador dice ” podemos hacer paginación en el back-end “, ¿podría argumentar los beneficios de eso?
2. Bases de datos y estructuras de datos : realmente, realmente, realmente necesita saber cómo manejar esto. No digo que para su producto necesite saber dónde están todos los datos, o cómo (si) se pueden obtener (sería bueno si lo hiciera), pero debe ser capaz de comprender los conceptos de almacenar y recuperar datos, para saber (allí vamos de nuevo) lo que se puede o no se puede hacer. Imagine que un ingeniero le dice ” tenemos que buscar ID de productos de JSON preconfiguración “. Si lo miras con la cara en blanco, estás en problemas.
3. Arquitectura moderna de aplicaciones web : como gerente de productos, debe poder explicar su aplicación / servicio / pila de productos (en un alto nivel, por supuesto) a cualquiera que pregunte ” ¿cómo funciona esto? “. Si tu no entiendo la diferencia entre Redis y MongoDB, todo lo que sucede después del uso de la interfaz y las características del producto es un cuadro negro para usted. Y esa no es una opción.
4. Jerga : si expresiones como ” PUBLICAR hasta el punto final ” o ” usemos la carga diferida ” no significan mucho para usted, tendrá dificultades para discutir las cosas a nivel cotidiano con los ingenieros de su equipo.

Entonces, ¿hasta qué punto necesita comprender los conceptos de programación, las bases de datos y la arquitectura de software?

Bueno, es bastante simple: hasta un nivel en el que puedas comprender lo que es posible frente a lo que no es posible. Lo que a su vez lo hará sentir cómodo discutiendo problemas y entendiendo las consecuencias de ciertas compensaciones para priorizar adecuadamente y lograr sus objetivos, lo que a su vez lo capacitará para administrar realmente su producto.

Aquí hay algunas frases que escuché que los ingenieros usaron en una conversación informal, posiblemente sin darse cuenta de que no todos saben lo que significan:

• SECO – “No te repitas”: el código seco es bueno. Un concepto dado solo debe representarse en su código una vez, una fuente de verdad. Esto se usa comúnmente como un verbo, por ejemplo, “probablemente deberíamos secar un poco este código”
• WET – “Write Everything Twice”: el código húmedo es malo. Si tiene código húmedo y necesita hacer un cambio en cómo funciona algo, necesitaría hacer ese cambio en varios lugares. El código húmedo es más difícil de mantener.
• No-Op : significa “no operación”, lo que significa no hacer nada. Algo es un “no operativo” si no requiere ningún trabajo adicional, como una función que obtienes de forma gratuita porque la funcionalidad ya se ocupó en otra historia.
• YAGNI – “No lo vas a necesitar”: No desarrolles una complejidad adicional solo porque podrías necesitar algo algún día.
• Código de autodocumentación : código que se escribe con tanta elegancia que no necesita documentación o comentarios solo para descubrir cómo funciona. Las especificaciones (pruebas) realmente buenas también ayudan a los ingenieros a comprender lo que se supone que debe hacer una determinada sección de código.
• Olor de código : código con ciertas propiedades que posiblemente refleja un problema más profundo. Hay algunas características del código que pueden indicar un mayor riesgo de errores o problemas futuros. Código mojado? ¿Código que necesita documentación solo para entenderlo? Esos son olores.
• Dogfooding : ser un usuario de su propio producto para ayudar a probar y promover ese producto. Por ejemplo, los ingenieros que trabajan en Quora podrían usar Quora para publicar preguntas y respuestas a los problemas que están resolviendo. A Paul Maritz se le atribuye haber acuñado la frase “Comiendo su propia comida para perros”.

Como la cantidad de nuevas tecnologías y plataformas que se desarrollan, la cantidad de términos con los que un gerente de producto debe estar familiarizado puede ser infinita y puede quedar desactualizada en años.

Creo que estos son algunos conceptos de programación que los gerentes de producto deben entender:

• back-end

• Bases de datos

• PostgreSQL
• MongoDB
• servidor SQL
• MySQL
• MariaDB

• Reaccionar
• html
• css
• js
• chart.js

• django
• matraz

• Servicios de descanso
• servicios web

• desarrollo
• puesta en escena
• producción

• clases
• puntos de vista
• MVC: modelo – vista – controlador

• SAML
• OAuth
• SSO

En realidad, no hay mucho de lo que enumeraste.

Un gerente de producto puede beneficiarse al conocer estos términos relacionados con la programación, pero hay más en el diseño de software que el conocimiento algorítmico.
Un gerente de producto puede beneficiarse al conocer

Gestión de dependencias
Modularidad de código
Opciones de implementación
embalaje
Plataformas soportadas por el software
Metodologías de gestión de proyectos: Agile Scrum, etc.
Gestión de requerimientos
Manejo de errores

0. Ninguno de los ejemplos proporcionados.
1. Deuda técnica (para que puedan priorizar reducirla)
2. Especificación (Muy pocos PM entienden este término)
3. Error, característica
4. Flujo de desarrollo / lanzamiento del producto y el equipo (Aquí hay algunos términos que el primer ministro debe conocer, pero todos dependen del equipo)

Como mínimo, diría que debería estar familiarizado con los conceptos cubiertos en este curso: Aprenda los conceptos básicos de programación de computadoras en línea

(No sé si necesita necesariamente tomar el curso, pero todo lo que cubre es un concepto fundamental con el que debe estar familiarizado. El curso en sí es, por los videos que he visto, muy atractivo para un curso en línea, y es de $ 49. (Por mes, pero son 6 horas, por lo que debería poder completarlo en menos de un mes).

1. Diseño de respuesta
2. Degradación elegante
3. Posicionamiento en buscadores (SEO)
4. Marketing en buscadores (SEM)
5. Semántica
6. Asincrónico
7. Duplicación de píxeles
8. Examen de la unidad
9. Ágil
10. Sprint