#42474 los amores de oficina de sexo consentuado* y fuera de horario laboral** no lleva a nada
#42475 o en el crossfit, hace unos dias me he enmone de una bebita tremenda.
los amores de piwi con imigrantes ilegales* casadas por papeles** en tramites de divorcio*** terminan mal
siguiendo con mi libro, el tema de tratar el producto como tangencial vs ortogonal como lo veis? esta seria una vision tangencial
como podeis ver añado un factor de politica, que es el de negocio, que segun mi teoria NO esta relacionado con producto. "hacer ver" que esta relacionado es parte del a politica. el otro dia publique al respecto en el blog.
(podeis ver como no encaja del todo bien la parte tecnica con el producto, el hecho de que algo sea end user o front end depende del producto... esto me hace decantarme por la vision ortogonal donde producto se aplica a TODO)
(y sin entrar mucho podeis ver como de la izquierda hacia la derecha salen todos los puestos de trabajo que hay en un equipo, em (politica), pm (producto), user seria frontend, movile o apis publicas, backend que sirve el frontend, backend que interactua con el os como devops, y infra que seria provisionamiento.)
mi idea es que sobre cada uno de los campos, nos centramos en 3 hard skills/factores:
- implementacion
- troubleshooting
- reliability
estos 3 factores cubren todo el ciclo de vida de una entidad en mi teoria. Entidades como pueden ser: equipo, producto, software.
Y los valores posibles que un fpero puede tener para cada campo son [-1, 0, 1]. donde -1 significa que perjudica, 0 no hace nada, 1 contribuye. Donde serian las componentes.
Entonces las dudas las tengo en como componer los resultados para obtener algo parecido a esto:
Pero multidimensional y que se pueda realizar operaciones con los resultados. por ejemplo, comparar dos equipos, maximizar/minimzar areas. Y que sea una vision o proyeccion como la de arriba para que la gente pueda visualizar y entender los resultados de manera facil.
Algunos factores que estareis pensando como la comunicacion y demas soft skills estan dentro de los hard skills. Implementacion, troubleshooting y reliablity ya considera estos factores para cada campo.
Otros factores como "tech debt", realizar MVP vs trabajo a largo plazo escalable, en la vision tangencial de la teoria no encajan muy bien. Deberian ser weights que aplicas desde producto al resto de skills... Y esto no me termina de gustar. Prefiero tener una teoria donde defines un contexto temporal y espacial. Es decir, tener variables globales en lugar de multplicadores.
En la vision ortogonal donde producto esta fuera del sistema y sirve para definir el contexto y propiedades de este, creo que encaja mucho mejor.
