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.

La administración de proyectos en software es más relevante que nunca

La forma en que se desarrolla software en la segunda década del siglo XXI es diferente a como se hacía cuando nació la industria de software. Esto debido a que la base de usuarios creció y las características de ellos son muy distintas a los usuarios iniciales; por tanto, sus demandas y necesidades requieren una atención adecuada a este entorno de entendimiento cambiante.

Es por esto que han surgido prácticas y propuestas para organizar equipos e individuos que hacen software, que están enfocadas en manejar esos cambios: ciclos de desarrollo más cortos, adaptación al cambio, comunicación e interacción constantes y una desaparición, por así decirlo, de un gestor que toma las decisiones importantes. Se dice que el enfoque “tradicional” de gestión de proyectos es inapropiado para las prácticas actuales.

La “administración tradicional” de proyectos

El enfoque que llaman “tradicional” se caracteriza por buscar el control y la predicción del trabajo: se hacen planes detallados para la totalidad del proyecto, aun con duraciones de años, y se pretende seguir rigurosamente ese plan para cumplir con los objetivos y evitar las desviaciones. Generalmente existe la figura del Project Manager, quien mantiene y controla el avance en el proyecto, y los trabajadores pocas o nulas veces se ven involucrados en la definición o corrección de ese plan.

Se ve como una estructura rígida, en la que el objetivo es seguir el plan en vez de buscar la satisfacción del cliente, y usualmente se asocia con la entrega de un producto inadecuado para las necesidades del usuario, que cambiaron significativamente desde que se elaboró el plan la primera vez.

El enfoque “nuevo” para administrar proyectos de software

Algunos dicen que el “enfoque tradicional” no funciona para la ingeniería de software porque el trabajo es distinto al que se hace con las manos o en líneas de producción. En una línea de productos se puede predecir y pronosticar con claridad porque el trabajo y las necesidades están bien comprendidas, algo que rara vez pasa en software.

Además, el desarrollo de software entra en la categoría de “trabajo intelectual”, donde los resultados se obtienen a través del esfuerzo mental en lugar del trabajo manual, y es muy difícil gestionar ideas, particularmente si dejamos que solo una persona lo haga.

La filosofía ágil, que se ha adoptado como el estándar actual en desarrollo de software, se enfoca en generar valor para el negocio y adaptarse al cambio: aprendizaje rápido y una respuesta al entorno cambiante también rápida. Los planes largos y detallados son imposibles porque no se puede predecir el futuro, y el equipo debe estar concentrado en entregar valor en ciclos cortos, no en seguir un plan.

Adiós a los diagramas Gantt, las listas de tareas, los reportes con gráficas del avance frecuentes y otras prácticas llamadas burocráticas. En ocasiones, también significa un “adiós” al Project Manager.

Y en otras ocasiones, también significa lanzar la gestión del proyecto por la ventana.

Ahora, cada ingeniero debe saber administrar proyectos

Detrás de la filosofía ágil y de otros marcos de trabajo para software existe un principio fundamental para que las cosas funcionen:

El equipo debe ser capaz de autoadministrarse

Tom Demarco los llama “jelled teams“, y son equipos que se caracterizan porque todos son partícipes y dueños de las decisiones, y suelen ser altamente efectivos porque cada integrante se hace responsable de su trabajo y sus compromisos.

Esto implica que cada uno es capaz de administrar correctamente un proyecto, que tiene el tamaño de una persona, es decir:

  • Puede estimar el esfuerzo que requiere hacer el trabajo, para saber a qué se puede comprometer.
  • Lleva un seguimiento de su trabajo, para identificar causas concretas de problemas y buenos resultados.
  • Toma decisiones y acciones correctivas con base en mediciones y análisis comparativos entre sus expectativas y resultados.
  • Comunica su estatus continuamente y sabe cuándo levantar alertas oportunamente para evitar problemas

La razón por la cual un equipo no requiere un Project Manager es porque cada ingeniero es su propio Project Manager.

Gestionar proyectos es seguir principios, no llenar documentos

La idea de administración de proyectos se puede asociar con la idea de métodos, procesos y artefactos rígidos: Aplicar algo dogmáticamente (como el PMBOK) al pie de la letra, pero es algo muy distinto.

Gestionar el proyecto significa guiar el proyecto hacia conseguir los objetivos y optimizar los recursos, no llenar documentos y ser el policía del cumplimiento del plan.

Administración de proyectos, antes que un método, es un conjunto de principios. Es muy importante que un Ingeniero de Software actual los conozca y sea capaz de aplicarlos, pues en la práctica actual es imposible que solo una persona lo haga, y si el ingeniero mismo no administra su trabajo, entonces nadie estará haciéndolo.

[siteorigin_widget class=”SiteOrigin_Widget_Cta_Widget”][/siteorigin_widget]

Algunas disciplinas ingenieriles afirman que el desarrollo de software no es una ingeniería, pues basa su trabajo en prácticas artesanales.

Si dedicas 60% o más del tiempo en actividades de escritura de código, pruebas y arreglo del mismo, entonces perteneces a la estadística que refuerza esta creencia.

Los benchmarks internacionales de la buena calidad indican que el esfuerzo para escribir el código y probarlo solamente es del 30% de todo el tiempo.

El Standish Group publica el CHAOS Report cada año. Aquí el resumen de 2015: https://www.infoq.com/articles/standi…

¿Cómo es tu proceso de desarrollo actual?

¿Cuáles resultados te da?

Cuéntame tu experiencia en los comentarios

Suscríbete para continuar viendo el contenido aquí publicado

Ingeniería de requerimientos

Los ingenieros de software solemos decir: “Es que el cliente no sabe lo que quiere” cuando nos referimos a un desarrollo problemático, porque no logramos dar con la solución o nos solicitan infinidad de cambios. Sin embargo, ¿realmente un cliente de software no sabe lo que quiere? Acompáñame para conocer si esto es verdad o se trata de un mito