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

Como ex ingeniero y actual persona productora, los términos que comunican los conceptos más profundos y rápidos se refieren al modelado de datos. Estos términos / conceptos se remontan al Análisis Orientado a Objetos y serán válidos en cualquier lenguaje de programación o plataforma tecnológica. Estoy hablando de:

  1. Términos de relación de entidad: uno a uno, uno a muchos, muchos a muchos, cero a muchos. Para cualquier fenómeno del mundo real en el que esté trabajando, debe articular las entidades y sus relaciones con los ingenieros y las relaciones con los objetos afectan profundamente cómo se construyen el código, la base de datos y la experiencia de usuario.
  2. Claves de datos: unicidad, clasificación, requerido. Personalmente, no creo que sea importante para una persona de Producto saber cómo se almacena una lista de entidades (tabla hash vs. lista vinculada), pero una persona de producto necesita saber cómo se debe acceder a los datos. ¿Está bien comenzar con algún artículo en una lista o el código debe buscar el primer artículo en el momento de la compra? ¿Cómo debe / puede identificarse un registro de manera única? Ejemplo: ¿Es un usuario único por nombre? ¿nombre y dirección? SSN? ¿Algo más?
  3. “niveles” – ¿Con qué entidad se debe almacenar un dato? Esto surge a menudo si está trabajando en la funcionalidad para recuperar / usar / almacenar un dato y necesita saber dónde está. Ejemplo: su sistema de comercio electrónico tiene pedidos que tienen líneas de pedido: desea agregar una política de devolución, pero ¿se aplica a todo el pedido o a una línea de pedido específica?

Otros términos más que son útiles:

  • bucle: no creo que necesite saber el bucle “for” vs. el bucle “do while”, pero es útil poder articular lo que quiere recorrer y cuando haya terminado.
  • capa: es útil saber que hay una “pila” y que diferentes personas trabajan en diferentes capas y que suceden cosas diferentes en cada capa.
  • tronco contra rama
  • datos dinámicos vs. estáticos

Último comentario: tuve que buscar qué era “Big O”. Supongo que te refieres a la notación grande. Eso no es algo que necesite saber, pero su empresa y sus ingenieros pueden esperar que conozca los términos relevantes para su producto. La gente de Quora no podrá ayudarte con eso.

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
  • migraciones
  • relleno
  • Interfaz
    • Reaccionar
    • html
    • css
    • js
    • chart.js
  • plataforma
    • django
    • matraz
  • integración
    • Servicios de descanso
    • servicios web
  • desarrollo impulsado por pruebas
  • despliegue
  • ambientes
    • desarrollo
    • puesta en escena
    • producción
  • programación orientada a objetos / objetos
    • clases
    • puntos de vista
    • MVC: modelo – vista – controlador
  • relleno
  • seguridad
    • 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