En esta ocasión te presento las razones por qué hablo de lo que hablo en este canal.

Visita mi web:
https://www.edgarfernandez.com
https://www.aprend-is.net

Aprende a estimar proyectos de software:
http://bit.ly/estimacionpromo

Videos mencionados:
Mi experiencia con Rambo: https://www.youtube.com/watch?v=qllc56_uR6c
¿Qué hace un Ing. de Software?: https://www.youtube.com/watch?v=uRiXseiYOUQ
¿Cómo quebré mi empresa? https://www.youtube.com/watch?v=LjZYZbVKJMQ

Música
De fondo: “Hard Boiled”, por Kevin MacLeod (https://incompetech.com)
Intro: Virus, por Dzynek

Watts S. Humphrey es el padre de la calidad del software. Él tenía un compromiso inquebrantable con la disciplina y la calidad. Emprendió una misión, con la que inspiró a muchos; entre ellos, a mí. Quiero hablarles de las razones por las que es mi role model profesional.

Mi curso en Udemy: http://bit.ly/estimacion

Contacto
Web: https://www.edgarfernandez.com
Facebook: https://www.facebook.com/SoftwareEngineeringCoach/
Twitter: https://twitter.com/edfrz1
LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Todo trabajo que se haga en un período de tiempo y que tenga un objetivo debe ser monitoreado regularmente, para asegurar que se camina en rumbo a ese objetivo y tomar decisiones para corregir desviaciones.
Entender el estatus de tu proyecto requiere que reunas información que te permita contestar estas seis preguntas.

Mi curso en Udemy: https://www.udemy.com/estimacion-de-proyectos-de-software-d…

Envíame un mensaje, y si eres de los primeros, gánate un cupón de descuento.

Varias personas me han pedido que les diga cómo crear una startup o empresa exitosa. He sido emprendedor, y mi empresa más grande quebró.

Quiero compartirte esa experiencia y los errores que nos condujeron al fracaso, esperando que puedas aprender de ellos, y lo que te recomendaría hicieras en lugar de lo que nosotros hicimos esa vez.

Recuerda suscribirte al canal para recibir las notificaciones cuando publicamos nuevos videos y compartirlo con quien creas necesite ver este video.

Visita mis redes:
Web: www.edgarfernandez.com
FB: https://www.facebook.com/SoftwareEngineeringCoach/
Twitter: https://twitter.com/edfrz1
LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Créditos de imágenes y recursos:
Photo by Tyler Nix on Unsplash (Cochera)
Photo by Hack Capital on Unsplash
Photo by Stefan Steinbauer on Unsplash
Photo by rawpixel on Unsplash
Photo by Tim Gouw on Unsplash
Photo by Ambreen Hasan on Unsplash
“Designed by kues1 / Freepik”

Quienes hemos tenido la oportunidad de liderar equipos de trabajo nos hemos encontrado, en ocasiones, a un personaje conflictivo. Hay varios tipos de ellos: el Rockstar, la Diva, el Inconforme, pero en este video trato de uno muy peculiar. Yo le llamo “Rambo”.

Sugerencias de Libros:
Willet, Alan. Leading the Unleadable: How to Manage Mavericks, Cynics, Divas, and Other Difficult People. Amacom, 2016
Patterson, Kerry. Crucial Conversations Tools for Talking When Stakes Are High. McGraw-Hill Education; Edición: 2nd ed. (9 de septiembre de 2011)

Visita mi sitio web para conocer mi experiencia: https://www.edgarfernandez.com
Sígueme en Facebook: https://facebook.com/SoftwareEngineeringCoach

Modelar el sistema pemite una mejor visualización de la situación que se quiere resolver y encontrar la solución más adecuada. Además de que nos evita problemas comunes en el desarrollo de software.

En este video te digo qué es System Testing, los tipos de pruebas de sistema y qué buscar en cada una.

Libros de consulta:

  • Lewis, William E. “Software Testing and Continuous Quality Improvement”. Third Edition. Taylor & Francis Groupi, 2009

  • The art of software testing / Glenford J. Myers, Corey Sandler, Tom Badgett. — 3rd ed.

Herramientas

La forma de publicar ofertas de trabajo está mal

La demanda por Ingenieros de Software en el mundo está a la alza. De acuerdo a IDC, en 2014 existían 18.5 millones de ellos en el mundo (11 millones profesionales). En 2017, Evans Data Corporation reportó en su estudio demográfico que hay 22 millones de ingenieros en el mundo. TechTarget menciona que para 2020 habrá una escasez de 1.4 millones de ingenieros en el mundo, y la Academia solamente podrá graduar a un tercio de ellos para ese entonces.

Las empresas de TI, o que cuentan con equipos de TI dentro de ellas, constantemente están en la búsqueda de profesionistas que cubran vacantes para trabajos relacionados con desarrollo y mantenimiento de software. Sin embargo, la forma en que lo hacen desvía y desvirtúa grandemente lo que es hacer software.

Todos piden programadores; pocos piden ingenieros

Las personas que publican ofertas de trabajo para ingenieros de software suelen pedir personas con conocimientos muy espécificos. A veces son listas con un número grande de tecnologías o prácticas (en ocasiones sin relación entre sí)…

… muchos años de experiencia en tecnologías cuya existencia es muy joven…

… o un perfil de ingeniería o “afín” (lo que sea que eso signifique)

Díganme ustedes, ¿cuándo han visto una vacante para un representante de comunicación empresarial con un texto como el que sigue?

Se solicita Representante de Comunicación. Requisitos:
- Licenciatura en comunicación, Ingeniería, Medicina o Afín
- Dominio de los diccionarios Larousse, RAE y Oxford.
- Conocimiento avanzado de todos los Procesadores de Palabras.
- Experiencia de 15 años en Microsoft Word y Google Docs.
- Deseable: Pasión por la lectura de obras de finanzas y administración

Parece que la misma industria no entiende qué es lo que hace

Entiendo que puedo parecer injusto con los reclutadores, headhunters y responsables de recursos humanos, pues ellos solo pasan las solicitudes que les hace la operación. Sin embargo, la proliferación de estas ofertas deja ver una cosa:

La industria del desarrollo de software no entiende bien de qué se trata su trabajo

La razón por la que no veremos una publicación de vacante en otras áreas con enfoque en las herramientas es porque en esas tienen bien entendido qué trabajo hacen.

En software, al parecer, lo más importante es el dominio de la herramienta. Esto ocasiona que haya cada vez más profesionistas interesados en dominar herramientas, y cada vez menos interesados en aprender a hacer software correctamente.

La herramienta debe estar al servicio del Ingeniero, y no el Ingeniero al servicio de la herramienta por una razón sencilla: La tecnología cambia con el tiempo.

Si un desarrollador se concentra solamente en saber usar herramientas, adquirirá todos los trucos y vicios contenidos en ella; pronto se volverá obsoleto, pues al cambiar la tecnología tendrá que aprender todo desde el principio y se volverá experto en aprendizaje, y posiblemente experto en generar los problemas que este modo de trabajo implica.

Definamos bien el trabajo que hacemos

El Ingeniero de Software no es un experto en herramientas. Los que definen un perfil de “ingeniero de software” en las vacantes y solo le piden dominio de herramientas no están buscando solucionar problemas de software, sino mantener activos algunos productos emproblemados porque su construcción fue inadecuada, hecha por “expertos” en la herramienta, más no en la Ingeniería.

El Ingeniero de Software usa sus habilidades para entender una necesidad, proponer una solución e implementarla. Elegirá los métodos y herramientas adecuados y los usará, pero no iniciará con “tengo JAVA, ahora no importa cuál es el problema, usaremos JAVA”.

Si en tu organización regularmente publican vacantes con estas características, haz una revisión de la definición del trabajo que hacen, para que busques Ingenieros, si es lo que necesitas, y no programadores en una herramienta en específico.

Ayúdanos a que las buenas prácticas de ingeniería se arraiguen en los presentes y futuros Ingenieros de Software, en vez de promover la creencia de que la herramienta es y será siempre lo más importante.