El producto es el equipo!
He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:
Equipos = Software
Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.
Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.
Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.
Mi producto es el equipo
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.
Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)
Mi Twitter
"Software for your Head" es mi libro favorito sobre ingeniería de software. Cada vez que lo releo descubro cosas nuevas en él. Cuenta qué opinas.
ResponderEliminarEpa! No dejes de traerlo por Iruña cuando acabes, me has despertado las ganas de leerlo! (Pensándolo mejor... ¿por qué no preparas una presentación para ver con el grupo de mandos intermedios? ¿hay webs? :p)
ResponderEliminarEl buen mecánico, siempre ha terminado haciendo de jefe de taller y ... no necesariamente es un buen jefe de taller.
ResponderEliminarEste es el mayor mito moderno, el principio de incompetencia, ... de Peter, que demostró ser muy competente.
¡Salud!
Cesar, ya lo comentaré más adelante,... el principio prometía, y sin embargo ahora no me acaba de convencer.
ResponderEliminarBabu! Hay que mejorar esa biblioteca!
µßio, es que lo que no nos damos cuenta es que no hacemos el mismo trabajo con mas responsabilidad, la idea es que es otro trabajo diferente!
La estructura de un producto de software es isomorfa a la del equipo que lo creó.
ResponderEliminarSi el producto original lo desarrollaron dos hermanos en su casa, entonces el resultado es un ejecutable ultracompacto muy eficiente pero que ni Dios puede extender y modificar.
Si el producto lo desarrolló una Comunidad, el resultado son unos miles de módulo débilmente acoplados cada uno de su padre y de su madre.
Si el producto lo desarrollaron 4 grupos de trabajo en una gran empresa, entonces el resultado son los 4 grandes programas de Office interconectados mediante OLE.
Si el producto lo desarrollaron 20 programadores en body shop de 5 empresas diferentes, dirigidos por un master MBA-NBA y del Universo preocupado sólo por cumplir los hitos formales y ponerse medallas, entonces el resultado no es software, se llama Código Mantente Mientras Cobro :-D)
Joserra, lamento que el libro, una vez que has avanzado en su lectura, no te acabe de convencer. Es cierto que hace tiempo que no lo retomo, pero en su momento y en las circunstancias en las que hice uso de él, para mí fue una verdadera revelación. Espero impaciente tus comentarios.
ResponderEliminarPor cierto que todo esto sirve para confirmarme que la relación entre un lector y un libro es una cuestión tan "de química" como la relación entre dos personas - lo que para uno es un flechazo, para otro pasa desapercibido o es un horror :-)
Por cierto, buenísimo el comentario de Sergio :-)
ResponderEliminarBueno, Mario, a ver si retomo el libro que ultimamnete no tengo tiempo para leer. Ya comentaré cuando lo termine.
ResponderEliminarSergio, totalmente de acuerdo con lo que dices.
Este comentario ha sido eliminado por el autor.
ResponderEliminar"Mi producto es el equipo".
ResponderEliminarCreo que ésa es la clave: no olvidando nunca que ese 'mi' no indica posesión sino pertenencia a.
Una frase citada por Barandiarán siempre me ronda en la cabeza cuando se habla de liderar personas: "Un árbol, cuanto más fruto da, más humilla".
¿Cuántos jefes, mandos intermedios, líderes... la asumirían como propia y la llevarían a la práctica?
Muy bueno el ejemplo de Sergio.. tan real como la vida misma.. Saludos.
ResponderEliminar