En andalucía se oscila mucho las unidades de medida propias. Vienen a ser: el pelín, la mijilla, er peazo, la jartá, la pechá y el huevo.
Muchos proyectos de software se comportan de
igual manera, de repente se transforman en un huevo de tediosas (tiempos y
costes se disparan, incidencias de todo tipo, incluir una nueva y simple
funcionalidad conllevan una jartá de esfuerzos, etc.), e igualmente,
muchas veces, nos ofrecen, o buscamos, sugerentes vías de escape que, con apenas esfuerzo, nos solucionen el problema (bastaría pasar
por algunos foros de software),
tecnologías que de manera casi inmediata prometen acabar con la intensidad de un proyecto de software gigante.
El tiempo ha dado lugar a la creación de un amplio cuerpo de conocimiento en ingeniería de software que nos
ha enseñado la mejor manera de trabajar, afrontar o resolver problemas
asociados a la naturaleza del software, como, por ejemplo, a no utilizar el “go to”, la importancia de la ocultación de la información,
el diseño orientado a objetos, las arquitecturas en capas, cómo estimar
proyectos, el valor de las mejoras, economia software, patrones, etc, etc, etc.
Pero éstos, en más ocasiones de las que nos gustaría, se olvidan, o desconocen, y se
buscan soluciones desde lo accidental
(una determinada herramienta, entorno automático o CASE, cambiar a un lenguaje de programación, utilizar otro modelo de procesos, etc.).
Como experiencia personal, la mayoría de los
problemas del software parten de obviar los principios esenciales, y se
incrementan al intentar solucionarlos exclusivamente desde la vía
accidental. Como profesional deberíamos cuidar más el conocimiento
esencial, la educación y formación en el mismo. El conocimiento
accidental es necesario para poder trabajar, pero el esencial es
necesario para además hacer un buen trabajo. El difundir y aprender el
cómo trabajar correctamente con la parte esencial del software, esa jartá de conocimiento que existe y se ha ido creando a lo largo de la cronología del software, es quizás uno de
los principales retos de nuestra profesión y muchos deberían aprender a apreciarlo en su justa medida. Muchos han sido los partífices en estableces esas bases.
Totalmento de acuerdo desde el punto de vista tecnico-manager. Desde el punto de vista manager-direccion-recursos humanos, a los encargados de liderar y llevar a buen termino el proyecto, y que les importase "un huevo" la calidad del producto a entregar, asi como la "pecha" de currar y la "harta" de presion que ha inyectado al equipo de trabajo, opino que la direccion no deberia tardar ni "pelin" en decirle a recursos humanos que no tardase ni una "mijita" en echarlo a la p... calle, para dejar paso a algun "peaso" de profesional cualificado que sepa lo que esta haciendo, y no sea un mero relaciones publicas empresarial. Dicho todo sin acritud, of course.
ResponderEliminar