Para este artículo hacemos
referencia a tres “invitados” de lujo.
Steve jobs, Henry Ford y Sun Tzu.
Las áreas de negocio
están conformadas por varias industrias, empresas o corporaciones que
constantemente compiten entre si para captar mas clientes y lanzar nuevos
productos basados en tecnologías de última generación.
Hay períodos
cruciales cuando es necesario que los desarrolladores produzcan programas más
rápido de lo normal porque hay que evitar que la competencia lance el mismo
producto al mercado antes que nosotros.
Hay un dicho que
reza: El que pega primero pega dos veces.
Ciertamente tiene una
gran ventaja quién primero lanza una oferta al mercado pero también es
necesario no perder de vista que no solo es importante salir de primero sino
mantenerse en esa posición.
En general, la
solución que se adopta para superar la brecha entre los desarrolladores
disponibles y el tiempo limitado de desarrollo es contratar más
desarrolladores.
Estos desarrolladores
temporales o contratados traen su
experiencia y metodología de trabajo que puede ser igual mejor o peor a la metodología disponible
en la empresa que los recibe; si es que la empresa tiene metodología alguna.
Cuando mencionamos la
palabra metodología inmediatamente la gente se orienta a metodologías como
Agile, Rup o cualquier otra orientada al
desarrollo de proyectos.
No se piensa en
metodologías que estén relacionadas con el proceso de programación en si mismo.
El método de desarrollo se deja al arbitrio y experiencia de cada desarrollador.
La palabra
metodología, en general, produce rechazo a la gente de TI.
Eso de metodología
suena a lento, limitado, incómodo porque parece restrictivo y además da la impresión de queno permite generar espacios creativos.
Lo que en realidad se
oculta detrás de este concepto es un rechazo intenso al cambio.
La metodología genera
cierta ansiedad ante la necesidad de adaptarse a otras maneras de trabajar que
no coinciden con la experiencia profesional del desarrollador aunque esa otra
manera de trabajar sea más eficiente.
Henry Ford se hizo
invencible creando un sistema de ensamblaje de automóviles que requería menos
trabajadores y producía más autos en menos tiempo.
Las ruedas, los frenos, el tren delantero, el
volante y los demás componentes del auto ya están listos para ser ensamblados.
No hay que fabricar cada componente una y otra vez.
Si extrapolamos este
ejemplo de Henry Ford a metodologías para el desarrollo de software, podemos
establecer como meta construir un línea
base tecnológica contentiva de programas, prototipos, procedimientos, módulos,
enlaces y componentes que han sido previamente fabricados, probados y
codificados y sobretodo 'enlazados entre sí ' en forma eficiente y efectiva. Esta
base tecnológica no es contraria a la creatividad; todo lo contrario.
Los desarrolladores
no tendrían que ocuparse de buscar códigos estándar y repetitivos para desarrollar sus programas.
El tiempo que se
ahorra con esta base tecnológica crea un espacio para la propuesta, el ingenio
y la creatividad.
Nuestra línea base tecnológica debe ser actualizada cada cierto tiempo y ademas documentada con un mínimo de
contenido para dar idea al programador del uso que se le puede dar a cada
elemento que la integra.
Para aquellos que les
disgusta documentar, la documentación
puede ser sustituida por la creación de prototipos que pueden ser ejecutados para que el
desarrollador pruebe su funcionalidad y decida cómo utilizar el prototipo que
está evaluando.
Alrededor del año
2011 me tocó trabajar con un desarrollador Hindú. Cabe destacar que, se
considera a los hindues los mejores programadores del mundo.
Los prototipos sobre
los cuales se basaba el estilo de programación de este compañero hindú fueron modernos,
dinámicos y fáciles de entender. Eso me permitió en esa época trabajar a una
mayor velocidad. Incluso se me ocurrió
un desarrollo que generaba información en forma dinámica para generar un pdf en
windows.
El tiempo que me hubiese gastado en
desarrollar por mi cuenta, sin contar con el soporte de un propotipo eficiente, no hubiese
dado cabida para generar ideas y propuestas en el desarrollo de otras aplicaciones
para ofertar en el mercado.
Una vez aceptado el
hecho de que se necesita una linea de ensamblaje de programas, hay otro
problema que solucionar: Quién, cómo donde y
cuando se desarrollará esta repositorio tecnológico que será la plataforma de despegue para la línea
de ensamblaje. Este asunto puede
verse sencillo pero no lo es.
Por una parte, los
programadores están dotados de un ego extraordinario con el cual cada uno
piensa que su estilo de programación es el mejor para desarrollar software.
Por otro lado, el
asunto tiene que ver con la aceptación de que algunas veces los trabajadores temporales
o consultores contratados que vienen a ayudarnos tienen mas y mejores recursos
para montar una línea de ensamblaje mucho mejor que la nuestra.
El ego es,
definitivamente un obstáculo intangible pero real. El territorio del
programador es sagrado y cualquiera que demuestre intencionalmente o no, una calidad superior de desempeño es
generalmente atacado y dejado de lado.
Se contrata a los mejores programadores del
mundo para que se adapten a nuestra metodología de trabajo (si es que la
tenemos) cuyos estandares no son tan optimos, ni por asomo, a la que nos traen
nuestros huespedes.
Esto genera un
inmenso desperdicio de talento, y no genera ningún valor agregado en nuestra
fábrica de software. Además, estos consultores o desarrolladores nos abandonan
mas temprano que tarde al verse forzadamente sumergidos en una dinámica de trabajo
inferior al estándar óptimo al cual están acostumbrados.
Como dijo Steve Jobs:
Una solución
salomónica a este asunto, dado el poco tiempo que se tiene para lanzar el
producto y a la vez integrar ambos metodologías (o para mejorar la que tenemos)
es dejar a nuestros huespedes trabajar
con su metodología para aprender algo de ellos y quedarnos con sus códigos.
Nuestra
base tecnologica debe ser actualizada posteriormente con estos modelo mas eficientes
integrandolos con los nuestros. Antes de derrotar a
la competencia hay que derrotarse a si mismo.
Como dice Sun Tzu en
su manual El arte de la guerra:
"Cada Batalla se gana antes de haber peleado"
Otra frase de Sun Tzu para recordar:
“La invencibilidad
está en uno mismo; la vulnerabilidad en el adversario”.
Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.
Autor: Ing. Liliana Suárez
