Lo bueno de haber visto tantos proyectos y empresas de tecnología, después de pasar por 80 empresas, una de las cosas realmente buenas, es que me permite contrastar en mi propia experiencia lo mucho que había leído de múltiples grandes autores de la ingeniería software, de importantes estudios, en grandes libros, etc.
Esta nuestra profesión tiene sus cosas, la mayoría muy buenas y otras curiosas, como que se guía mucho por la opinión, por el “yo creo”, el “digo esto porque me interesa”, la moda y el “esto será bueno porque se escucha mucho por ahí”, pero muchas veces se condena por la falta de rigor en lo que se recomienda.
Aun así, este post no deja de ser mi opinión, eso sí, como te decía al principio, opinión forjada de haber visto muchos proyectos y empresas de tecnología, contrastada con lo mucho que he leído.
Con todo, te quiero dejar en este post veraniego, y compartir contigo, algunos de los que solemos llamar “malos olores”, aquellos que siempre busco cuando llego a un proyecto, a una empresa, cuando alguien me dice “tú cómo lo ves”.
Como buenos “malos olores”, no siempre indican un problema pero rara vez se equivocan. Muchos ya te los había comentado en anteriores post y en este tienes una recopilación de ellos:
1 – Poner apellidos, a una buena práctica de ingeniería software. Es muy común, se suele decir que se utiliza una buena práctica, pero cuando preguntas un poco más la práctica viene con apellidos, por ejemplo: “utilizamos un pseudo Scrum”, “una especie de control de versiones”, “probamos a nuestra particular manera”, etc. No siempre, pero la mayoría de las veces que pasa esto… mala cosa, la buena práctica realmente no es tal.
2 – Añadir personas, a la organización, sin tener una estructura profundamente pensada. Un clásico que ya hemos comentado en varias ocasiones, ocurre normalmente en situaciones complicadas (el proyecto va muy mal) pero también en situaciones en que la empresa va bien, está creciendo, e, igualmente, empieza a entrar gente sin orden no concierto. Rara vez se añade gente bajo una organización pensado para ello, un ejemplo, no el único, es tener equipos multifuncionales.
3 – Justificaciones para la no calidad, del tipo la “presión del cliente” como justificación para no utilizar buenas practicas o “no hacemos las cosas con calidad porque ningún cliente paga la calidad”. Hay quien a esto lo llama “no tenemos tiempo de hacerlo bien pero si de hacerlo dos veces” o “No tenemos tiempo de mejorar y como no mejoramos no tenemos tiempo”.
4- La pruebas, que son una gran fuente, un hilo del que tiras y no sólo te encuentras problemas en las propias pruebas, sino que vas tirando y llegas a problemas en el ciclo de vida, en la infraestructura tecnológica, etc. Ya te comentaba en no se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints), que cuando no se prueba bien el problema viene de más allá, es normalmente un problema de gestión, infraestructura y de ciclo de vida.
5 – Los héroes, y no precisamente del silencio, es decir el número de personas de la organización que si no están olvídate, nadie sabe cómo hacer las cosas, aquellos que se quedan los fines de semana, los únicos que resuelven los problemas en los pasos a producción. En su día te dejé el post de por los héroes.
6 – Los ánimos, llámalo la felicidad, llámalo la rotación, llámalo las caras, llámalo como quieras, ya sabes a lo que me refiero. Algo hablamos en su día en ¿te has parado a pensar cuánto te cuesta que la gente se vaya de tu empresa?, en ¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto? Las personas o más representativamente en ¿Te pondrías una camiseta con el logo de tu empresa? ¿con orgullo o vergüenza? Un equipo sin identidad nunca será un gran equipo y puede, incluso, que no sea ni equipo
7 – El recopilatorio, de aquel Test Garzás, que evalúa en 3 minutos el nivel de tu empresa desarrollando software. Que viene a bajar el nivel de detalle de estos malos olores y trata algunos temas más técnicos, como el control de versiones, etc.
8 – Papeleo y documentación. Cuando hay gente que se pasa más tiempo escribiendo papel que haciendo cosas (véase el ejemplo del testing), cuando se escriben extensos documentos que nadie leé, que luego nadie aplica, mala cosa.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024