1. LA CARRERA PROFESIONAL DEL DESARROLLADOR DE SOFTWARE
EN VENEZUELA
Prof. Dr. Jorge Domínguez Chávez
Coordinador de la Especialización en Sistemas
RESUMEN
En este trabajo se exponen las características que debe tener
un desarrollador de software, los niveles de acenso en su carrera
profesional y se discuten algunos puntos como las metodologías de
desarrollo, la visión actual del mercado de trabajo.
Descriptores: desarrollo, software, metodologías, métrica V3. CMM
La carrera profesional del desarrollador de software en
Venezuela, al igual que en muchos países, está marcada directamente
por la oferta y demanda laboral. Si bien el mercado primordialmente
ha estado basado en la consultoría (alquiler de mano de obra) y ha
sido una enorme fuente de negocio y beneficios para muchas empresas y
empresarios, también ha generado una distorsión en el mismo mercado,
donde la calidad y el talento son factores secundarios, a favor de
los años de experiencia que son “vendibles”, y por ende, imputables a
un proyecto.
¿Qué hacen en realidad los desarrolladores y/o programadores
de software? Son las mentes creativas detrás de los programas
informáticos. Algunos de estos programadores desarrollan aplicaciones
para que otras personas ejecuten tareas específicas en la computadora
u otro dispositivo informático. Otros, desarrollan los sistemas
operativos que gestionan el hardware y controlan las redes
informáticas.

2. ¿Cuál es el entorno de trabajo? Muchos de los desarrolladores
de software trabajan para empresas que diseñan sistemas de
computación, aplicaciones web o software a la medida. Otros, trabajan
en la industria desarrollando aplicaciones industriales, como el
petroleo, la minería, la robótica o la medicina. Pero la mayoría de
estos programadores trabajan por su cuenta (profesional libre) 40
horas a la semana y otros, en el peor de los casos, trabajan más de
esas 40 horas por semana, desarrollando aplicaciones bajo demanda.
¿Cómo llegar a ser desarrollador de software? Normalmente,
este profesional tiene una licenciatura o ingeniería en computación y
sólidas habilidades en la programación de computadoras.
¿Cuál es la tendencia laboral? Los empleos en desarrollo de
software tienen una proyección de crecimiento de 13% anual, más que
la media en otras profesiones. La razón de esto es la demanda
incremental en software de aplicaciones.
Los escalafones profesionales del desarrollador son:
• Becario o pasante. Figura poco utilizada ya que representa un
costo importante en formación y tiene el riesgo de no aportar
ningún beneficio. A los más competentes se les integra a la
plantilla, o tienden a irse a otro trabajo mejor pagado porque
ya tienen práctica laboral.
• Programador junior. Prácticamente un becario en plantilla y
pagado. El sueldo es bajo y no se debiera esperar que sea muy
productivo. Se le introduce en equipos o trabajos para que se
vaya formando.
• Programador. A partir de uno o dos años de experiencia. Para
muchas empresas debe ser productivo e integrarse en equipos.
• Programador senior. A partir de los tres años, se considera que
sabe enfrentarse a prácticamente cualquier problema y sacar un
proyecto adelante.
• Analista programador. Un programador senior, con cinco años de
experiencia, es capaz de realizar análisis funcionales, tomar
decisiones por si mismo o, incluso, ser el líder de un equipo.
• Analista. Un profesional con amplia experiencia para elaborar
los análisis funcionales de las aplicaciones. Es el primer paso
hacia el abandono del “picar código”, es imprescindible un
amplio bagaje técnico.
• Arquitecto. Personaje que se utiliza en grandes proyectos que se
ocupa de la descripción y análisis arquitectónico del proyecto.

3. Elabora documentación técnica, toma decisiones y basa su
conocimiento no sólo en la experiencia empírica sino en el
estudio de la ciencia de la computación.
• Jefe de Proyectos (no técnicos). Es responsable del departamento
técnico o su Director y gestiona la productividad del equipo y
reporta a la Dirección o gerencia.
Vemos que el desarrollo de software es una labor compleja,
intelectual, profesional basada en el estudio, el esfuerzo, el
talento y la capacidad.
Así, tenemos que un programador con talento puede hacer
labores de Analista o arquitecto teniendo tres años de experiencia; o
sí tiene un título universitario desde hace un año puede ser analista
funcional. También, hay programadores sin talento para el desarrollo,
pero con la titulación exigida para el puesto.
Cuando empezamos a “picar código” tenemos en cuenta que, en
la mayoría de los casos, que el desarrollo de software es un trabajo
en equipo. Y que en cuanto hay más de tres personas en el equipo,
hablamos de una multitud. Por lo cual nuestra propia condición nos
conduce a buscar un líder natural que ponga orden al caos que se
puede generar.
Para ello, se eligen a los mejores profesionales o los más
reconocidos (que no es lo mismo) para gestionar los equipos. Estos
son llamados líderes de equipo y jefes de proyectos técnicos. Ambos,
pican código. Quizá no todos los días, pero son parte de la
construcción del software. La diferencia principal es que el primero
gestiona al equipo desde un punto de vista técnico puro y el segundo
hace labores de gestión y reporta a la gerencia o dirección.
Estos cargos requieren de una motivación especial por el
trabajo. El profesional debe tener talento para gestionar, coordinar
y liderar personas y proyectos. Además, tener el conocimiento y la
experiencia para que el equipo lo respete técnicamente. En este
escalón el poder de autoridad es muy pequeño y no se puede ocultar la
ignorancia técnica detrás de la burocracia de la gestión.
Al pasar a Gestión de proyectos, el profesional deja de ser
un desarrollador de software, aunque conserve esa habilidad por
afición o por estudio. Pienso que el camino más completo para
alcanzar estos puestos es viniendo del desarrollo, incluso más que
provenir de Tecnología de Información.

4. Hay profesionales que vienen de otras áreas y llegan a los
puestos de gestión por una certificación PMI1, PMP2, Prince23, etc.,
los cuales, si no han tenido conocimiento técnico sobre el desarrollo
de software, tienen un gran riesgo de verse abocados al fracaso a
causa de las singularidades de los proyectos informáticos.
Nota. Curiosamente estas certificaciones NO mencionan la
palabra software o desarrollo de software.
Al llegar a Jefe de Proyecto (no técnico), el principal
objetivo es el conseguir que la productividad de los equipos se
mantenga o mejore. Debe reportar de forma entendible a la Dirección.
Esto último (reportar a la dirección), que parece trivial, no
lo es. Ya que la diferencia de terminología y de conceptos entre los
que hacen las cosas y los que dirigen es, simplemente, abismal.
Explico, durante el desarrollo de software debemos estar
centrados en los procesos, las metodologías, en las métricas, en la
trazabilidad y en la madurez de los equipos. Olvidándote, por falta
de tiempo, del liderazgo técnico y priorizando el departamento.
Es frecuente que la palabra proceso en diferentes ámbitos se
entienda como “gestión por procesos”, “mejora de procesos”,
“automatización de procesos”, etc., “proceso” lleva a pensar en
entornos industriales pero también existen procesos en empresas de
servicios.
Entonces ¿Qué es un “proceso”? ¿En qué consiste? ¿Hay
procesos en nuestra empresa? Si vamos al Diccionario de la Real
Academia de la Lengua Española, vemos que proceso es: “Conjunto de
las fases sucesivas de un fenómeno natural o de una operación
artificial “, en otras palabras, un proceso es una serie de tareas,
que tienen como origen unas entradas y como fin unas salidas. El
objetivo del proceso es aportar valor en cada etapa. Pero… ¿Valor a
quién, a qué? Fácil, valor para el cliente. Si un proceso no añade
valor, lo eliminamos, siempre que sea posible. Además, el proceso
tiene propósitos, objetivos e indicadores para mejorar el desempeño.
1 Es un estándar desarrollado en los Estados Unidos de Norteamérica, con el mercado americano en mente,
PMI desarrolló su metodología denominada PMBOK la cual va en su cuarta versión y cuenta con esquemas
de capacitación y certificación.
2 PMP (Project Management Professional) es un must que todo gerente de proyecto debe tener si quiere
ascender en su carrera y gestionar proyectos cada vez más importantes, y debe enfocarse en obtener la
referida certificación, como un requisito para aquello.
3 Estándar desarrollado en Gran Bretaña, por OGC, oficina del gobierno británico, su foco original fue el
sector público, y ha sido adoptada en otras industrias, tiene una fuerte presencia en Europa y en las zonas
de influencia del Reino Unido.

5. Un proceso informático puede entenderse como un programa en
ejecución. Formalmente, un proceso es "Una unidad de actividad que se
caracteriza por la ejecución de una secuencia de instrucciones, un
estado actual, y un conjunto de recursos asociados del sistema" 4. Es
decir, hay una entrada de datos, un proceso y una salida.
Fundamentalmente es lo siguiente: Análisis + Diseño + Programación.
También consideramos Capacidad + Deseos superación + Aprendizaje
constante + Trabajo inteligente + Lugar y Momento adecuado. Los
cuales son buenos elementos para lograr objetivos. NOTA: mencioné
trabajo inteligente, porque trabajar duro (como burro) es otra cosa.
Para desarrollar un software o programa empleamos una
metodología. Aquí, podríamos iniciar un debate sobre la metodología
de desarrollo a seguir ­ cascada, ágil, delgado, espiral extremo,
unificado, etc. En este momento, suponemos que el método que usamos
es el correcto y que los otros, sin importar su experiencia previa,
están equivocados. Algunos, tienen una caja de herramientas de
métodos para recurrir a ella, otros dicen que el mundo debe adaptarse
a un nuevo estado del arte de la técnica.
Pero, ¿Hay una forma práctica de construir un buen software
sin este debate? No hay respuesta corta ni fácil. Usa la metodología
que te haga sentir bien y cuando no sea útil para el equipo en su
conjunto, la cambias sin debatir el tema, y regresas sobre el proceso
en su contexto. En un proyecto de software el reloj siempre está
corriendo y el debatir sobre un meta­tema que no tiene una respuesta
correcta, ni única, no es la mejor manera de usarlo. No existe una
metodología adecuada, como tampoco existe un convenio para la
codificación correcta, el lenguaje de programación correcto, o un
diseño de interfaz de usuario correcto. El contexto marca la pauta.
Hablamos de experimentar con el código (o con los
requerimientos); toma algunas decisiones rápidas sobre cómo construir
el software que necesitas y ajustate a ellas. Ajusta el método al
obtener los resultados del proyecto en el espectro de tu equipo y de
negocios para sustentar los cambios. No discutas el meta­debate sobre
la forma de hacer el trabajo que tienes que hacer, consumes tiempo.
Desde los primeros tiempos del desarrollo de software, los
profesionales del estado del arte han creado métodos formales para
especificar e implementar software y convertirse en ingenieros. Estos
métodos fueron influenciados por la naturaleza física de los grandes
proyectos de ingeniería como planos de construcción, puentes o los
propios computadores (procesos de ingeniería maduros).
4 Stallings 5º edición pag. 109

6. El software desarrollado según estos métodos puso en claro
para muchos que la parte blanda (soft) de la ingeniería de software
potencialmente perdería su enfoque flexible, el desarrollo se volvió
burocrático. La industria del software, como cualquier otra
industria, requiere de productos de calidad, de buen precio y a
tiempo. Las empresas requieren de software rápido. Con tan increíble
demanda de software, no es de extrañar que a muchos les gustaría
hacer más cosas en menos tiempo y mirar hacia un enfoque metodológico
flexible y versátil para hacerlo. La oportunidad de una recompensa
para la construcción de un gran software como parte de un gran
negocio está mejor que nunca. La flexibilidad y versatilidad del
desarrollo de software es un regalo que a los ingenieros de otras
disciplinas le encantaría tener, así que hay muchas razones para que
el desarrollo de software sea menos burocrático y rígido.
¿Qué metodología usar para el desarrollo de un Software?
¿estructurado? ¿orientado a objetos? ¿rup? ¿xp? ¿cascada? ¿ágil?
¿scrum? Sí realizamos un software de manera rígida, según los
requerimientos inicialmente solicitados, y en la etapa final (etapa
de prueba), se solicita un cambio, se hace difícil realizarlo, pues
al hacerlo, altera muchas cosas que no habíamos previsto, siendo
éste, uno de los factores que retrasa un proyecto y por tanto, el no
cumplir con el cambio solicitado y el malestar del cliente por no
tomar en cuenta su pedido.
Por inexperiencia los usuarios dejan de mencionar cosas, pese
a que se mostró un prototipo del software en la etapa inicial del
proyecto, y lo hacen en la etapa de prueba.
Los proyectos en problemas salen del presupuesto, tienen
importantes retrasos, o simplemente no cumplen con las expectativas
del cliente.
Limitemos nuestro enfoque a los extremos del espectro de este
diálogo, aunque no necesariamente sea así en la práctica. Vamos a
llamar a los extremos cascada y ágil.
Los métodos cascada son mal vistos, son lentos, burocráticos,
micro administrados, incrementales, alejado de clientes y mercados,
entre otros. Por el contrario, los métodos ágiles son la manera
positiva de comenzar un proyecto, implican rapidez, creatividad,
energía, activista, unido a los clientes y mercados, y más. En cada
extremo existen defensores de implementar uno de esos métodos. Las
implementaciones incluyen plantillas de documentos, funciones y
responsabilidades, agendas de reuniones y con frecuencia herramientas
de software específicas para soportar el flujo de trabajo.

7. No todo es negativo o positivo en cada extremo. Un proyecto
de cascada es reflexivo, una arquitectura planificada, y procede,
desde la planificación hasta la ejecución final como un ballet. Por
otro lado, los proyectos ágiles son capaces de sustituir el caos y la
actividad en cualquier forma de progreso "que enviamos cada semana",
incluso se mueve hacia adelante o hacia atrás y con los clientes.
Por supuesto que estos extremos no son universales, ni
necesariamente, ciertos. Así que es mejor centrarse en la realidad
del código escrito, la prueba, el despliegue / envío y no depurar el
proceso ... prematuramente.
¿Has dedicado tiempo y esfuerzo a revisar y profundizar en la
metodología MÉTRICA V3? La cual, según la Wikipedia es “..Métrica v3
es una metodología de planificación, desarrollo y mantenimiento de
sistemas de información. Promovida por Ministerio de Administraciones
Públicas del Gobierno de España para sistematización de actividades
del ciclo de vida de los proyectos software en el ámbito de las
administraciones públicas...”
Y lo leemos, lo dice la Wiki y lo creemos. En el mundo real,
esta metodología no existe, no se utiliza. De hecho, pocas personas
conocen qué va, cómo se implementa, cómo funciona. Para ser sinceros,
el hecho de que no se utilice, es algo que agradecemos, porque está
desfasada con respecto a las ágiles. Lo que no entendemos es cómo
grandes proyectos de implantación a nivel nacional, no posean
documentación alguna: entre amigos, para saber qué es lo que hace una
determinada aplicación, tenemos que leernos su código fuente.
Ninguna empresa tiene completamente documentadas sus
aplicaciones, ni IBM, ni Oracle, ni Microsoft que disponen de
recursos humanos, tiempo y dinero lo hacen. Siempre los
documentadores van detrás de los desarrolladores.
Trazabilidad. En la gestión de requerimientos (REQM) se
pretende el control sobre los mismos. Los requerimientos deben estar
bien identificados y ser comprensibles para las partes que tengan
relación con ellos. Además, en cualquier momento, saber de donde
provienen los requisitos y la relación entre los de alto y bajo
nivel. También, los requisitos pueden ser entrada de otras áreas de
proceso. Es recomendable disponer de trazabilidad entre necesidades
de información y los objetivos asociados. Pretendemos responder a
¿Para qué vamos a medir esto? O ¿Qué se mide con esto?
Otro beneficio es que los cambios efectuados sobre los
requisitos sean controlados y no afecten a la integridad de lo ya
definido.

8. Realizamos la trazabilidad con una simple tabla donde en un
eje tenemos las necesidades de información y por en el otro, los
objetivos. así, rápido, sabemos la trazabilidad entre ambas cosas.
Madurez de los equipos. Está compuesta por:
Habilidades de equipo. El equipo puede estar formado por
profesionales experimentados que trabajan en territorio familiar.
Podrían estar haciendo su enésimo proyecto juntos o éste podría ser
el momento de una n­ésima construcción de un proyecto similar o
actualización. Pero deben recordar que ningún proyecto de desarrollo
de software es igual.
Número de ingenieros / tamaño del equipo. El número de
personas en un equipo influye en la evolución del desarrollo. No
debe incluir ingenieros por "tradición" o "convención". Cuestionar al
personal calificado es bueno, pero también debe hacerlo teniendo en
cuenta el contexto del equipo. Algún recién llegado puede sentirse
restringido, si proviene de un equipo pequeño. En un equipo grande
hay probablemente menos uniformidad de la que se pueda pensar, y esta
diversidad es una parte importante.
Debes delegar completamente en el equipo la responsabilidad
de decidir la mejor manera de trabajar para ser lo más productivos
posibles y darle protagonismo a las reuniones que realicen a lo largo
del proyecto.
realidad
La
Como experiencia personal, siempre echaras de menos el hacer
“magia”. Por ello recomiendo mantener la programación aunque sea como
un “hobby”, estarás al día sobre las herramientas y evolución de
nuestra profesión.
Así mismo, es imprescindible comunicarte en ingles, tener
conocimientos formales de gestión de proyectos y utilizar traje y
corbata. Saber hablar en público, escribir sin errores de ortografía,
saber redactar en lenguaje técnico; así motivar a las personas y
percibir cuando hay que sacar el látigo y cuando hay que tener mano
izquierda.
Crece según tu ambición
Una de las fuerzas más potentes de motivación laboral es el
sueldo. Bueno, realmente esto es una generalidad tosca que da para
escribir uno o más artículos relacionados con el tema de la
motivación.

9. Sí tuviese que dar un consejo a un becario o a un profesional
que no sabe si merece la pena el esfuerzo de aprendizaje para escalar
en su carrera profesional le diría: sigue tu ambición.
Vivimos una realidad cambiante, que ahora mismo te dice algo
tan simple como que si quieres ganar más dinero debes ir pasando de
funciones técnicas a funciones de gestión. Para, finalmente,
olvidarte de escribir código.
También ten en cuenta que no todos podemos dirigir/gestionar,
lo cual significa que tarde o temprano se dará el valor que tiene el
conocimiento y experiencia de un desarrollador de, por ejemplo, 20 o
25 años picando código. Y termina siendo una carrera profesional
desligada a la gestión.
En cualquier caso, cuando has tenido la experiencia de
desarrollar aplicaciones de software, la gestión de equipos o
departamentos de programación te brinda grandes satisfacciones
profesionales y personales.