Etiqueta: producto

Libro Recomendado: Getting Real

Hace un par de días que terminé de leer Getting Real. Me parece que no es un libro demasiado conocido a pesar de tener casi 20 años. Yo lo tenía en mi lista de pendientes desde hace un tiempo porque uno de sus autores es David Heinemeier Hansson (conocido como «DHH», creador de Ruby on Rails).

La lectura me resultó muy amena, en parte por sus capítulos cortos (1 o 2 páginas) y en parte por ser contenido muy práctico: en cierto modo cada capítulo es un consejo sobre algún tema concreto sobre el desarrollo de productos web.

Creo que este libro es una lectura obligatoria para todo aquel que pretenda crear productos online/digitales.

Debo admitir que no estoy de acuerdo con todo lo que dice pero sí estoy totalmente de acuerdo con la mayoría de las cuestiones que plantea.

Es importante destacar que varias de las cuestiones que proponen los autores son, a mi parecer», de aplicación «universal» pero algunas otras claramente aplican puntualmente a escenarios de «startups».

El Equipo Quirúrgico

(en idioma original «The Surgical Team«) Este es el título de uno de los artículos del clásico libro de Fred Brooks The Mythical Man-Month. A diferencia de otros artículos de ese libro, como The Mythical Man-Month y No Silver Bullet, este artículo no ha cobrado tanta fama pero eso no significa que sea menos genial.

En este artículo Fred Brooks desarrolla una idea previamente esbozada por Harlan Mills: resulta conveniente que los proyectos de software sean desarrollados por equipos pequeños de no más de 10 personas. Al mismo tiempo esos equipos deberían estar organizados como un equipo quirúrgico, eso es: opera una sola persona, el cirujano, que es asistido por un conjunto de especialistas (anestesista, instrumentista, etc, etc). Llevado esto al desarrollo de software, se propone que todo el diseño, desarrollo e implementación lo haga una única persona: el programador jefe (cirujano). Este programador es asistido por un conjunto de especialistas (tester, admin, toolsmith, etc).

Una versión actualizada de esta propuesta (tengamos presente que la propuesta inicial es de los ’70), podría tener un Senior Developer / Architect en el lugar del cirujano, asistido por un tester, un especialista en frontend, un especialista en backend, un dba, un sysadmin, un especialista UX, etc.

En muchos contextos esta idea puede resultar muy polémica pero al mismo tiempo en algunos otros contextos puede tener mucho sentido. Más aún, si a esta idea de cómo organizar un equipo la extrapolamos a nivel organización terminaremos con una propuesta del estilo de Team Topologies donde los equipos de producto (stream-aligned teams) toman todas las decisiones asistidos por otros equipos de especialistas (platform & enabling teams).

No deja de resultar curioso como algunas de ideas del siglo pasado vuelven a tomar vigencia luego de ser olvidadas por generaciones.