Puede que muchas de las cosas de la lista que te pongo más abajo nunca te las contaran en la universidad o en los estudios técnicos que cursaste. También puede que si te las contaran pero que por lo que fuese tu no te enteraras. Puede incluso que te dediques a la tecnología y no cursases estudios técnicos. Puede que por ello las cosas de la lista de abajo te suenen a chino. O puede que ya te las sepas todas.
Si estás hoy en alguna de las anteriores situaciones (menos en la última), tienes varias opciones. La primera es resignarte, y quejarte de la universidad, de la vida, de la mala suerte, de lo mala que es la profesión del mundo del software, etc. La segunda es aceptar la realidad y ponerte poco a poco, pero sin pausa, a estudiar. La primera opción no lleva a nada y la segunda te ayudará a evolucionar profesionalmente.
Por si acaso eres de los del segundo camino, he cometido el atrevimiento de elegir y dejarte en este post las 10 cosas que, en mi opinión, uno debería conocer mínimamente en gestión y desarrollo software, que debería conocer antes de “salir de casa e ir al trabajo”…
1 – Gestión de configuración y control de versiones.
2 – Diseño software y patrones.
3 – Arquitectura software.
4 – Dibujar y leer un diagrama UML.
5 – Casos de uso, y requisitos.
6 – Ciclos de vida (y no confundirlos con metodologías o con modelos de procesos)
7 – Calidad software, métricas y pruebas (al menos, los tipos de pruebas que existen, y no confundir modelos de procesos con certificaciones, con producto, ocon metodologías, etc.)
8 – El componente humano en el desarrollo software (motivación, efecto de la interrupción, mítico hombre mes, etc.)
9 – Gestión de proyectos y gestión de riesgos.
10 – Modelos de negocio en el mundo del software, tipos de empresas y tipos de contratos.
Nota: Como el ávido lector habrá podido apreciar, he obviado cuestiones más puras y cercanas a la programación, como, por ejemplo, conocer algún lenguaje de programación, saber algorítmica o haber programado algo alguna vez. El motivo de obviarlas viene de que a estas cuestiones, relativas a la programación, les pasa lo que al valor en el ejercito… se dan por supuestas, y, más o menos, son menos raras de encontrar en los profesionales, las difíciles de encontrar son las de la lista.
Ya sé, ya sé. Cada una de esas 10 cosas oculta muchos meses de estudio, lectura, y práctica. Pero para terminar un camino… hay que empezar con un primer paso. Y cuanto antes empieces, poco a poco, sin darte cuenta, antes habrás llegado.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pingback: Bitacoras.com
Hola.
¿Dónde puedo saber más del punto 10?
Me alucina cuando los (potenciales) clientes te agobian con presupuestos y fechas y luego no tienen claro ni de lejos qué es lo que quieren exactamente.
Saludos.
Hola Javier, ¿alguna recomendación de por dónde empezar y libros recomendables en estos puntos? Estoy recien empezando en esto. Muchas gracias!
A mi también me interesaría saber donde buscar más información sobre los temas propuestos. Que libro puedo leer para tener nociones básicas sobre el punto 9, o el 8, o el 7… Se que algunos libros ya los has mencionado en otros post, pero vendría genial alguna bibliografía o similar.
Excelente post.
Hola,
Creo que lo referente a libros, que cubren la lista anterior, están recogidos en estos dos post https://www.javiergarzas.com/2010/12/mejores-libros-ingenieria-software.html y https://www.javiergarzas.com/2013/02/dijkstra-secret.html
Para el punto 8 que me preguntabais, destacaría como imprescindibles Mythical Man Month y Peopleware (la referencia completa está en los post anteriores)
No obstante, ciertamente, el 10 es el que menos podemos encontrar recogido en un libro.
Saludos
¡Buenas!
Por suerte, estoy al tanto de los 10 puntos, no puedo decir ser un experto, pero la verdad que aprender el uso de ciertas herramientas como redmine es algo que facilita mucho el trabajo. Además algo tan simple como leer/diseñar un diagrama UML y que existan tantos «profesionales» que no sean capaces de hacerlo da que pensar acerca de cómo son las cosas aquí…
He visto algún comentario acerca de los puntos 7,8,9 yo recomendaría el libro «Ingeniería de software, un enfoque práctico» de Pressman.
Un saludo