Carnet de programador

5 Junio, 2009

Tecnología

En respuesta al artículo de Rodolfo Carnet de Programador he preferido responder algo más aquí, por que es un tema que me gusta mucho, y del cual, puedo hablar largo y tendido.

Aunque mucha gente le hecha la culpa a la forma de actuar de las grandes consultoras, hay más factores que determinan el resultado de un proyecto.

1. Gestión & Planificación

Gestionar un proyecto conlleva muchas cosas:

  • Elegir la tecnología adecuada; Herramientas, Frameworks, entornos, etc.
  • Elegir el equipo de personas adecuados y manejarlos durante todo el proyecto.
  • Reutilizar el know-how de proyectos anteriores.
  • Negociar con el cliente.
  • Negociar con la dirección de la empresa.
  • Vigilar la calidad del producto.
  • Etc.

No es una tarea fácil, y el problema es que no se aprende en la facultad de informática, otras carreras como telecomunicaciones, ingenieros, etc.. tienen asignaturas específicas, pero el informático, aprende de su jefe, y los que hemos tenido la suerte de tener un jefe ingeniero de la rama de planificación, hemos aprendido mucho.
En 1998 llegó a mis manos el libro Desarrollo Y Gestión de Proyectos Informaticos de Steve McConnell, para mí el mejor libro de informática que he leído hasta el momento. Este libro basado en ejemplos reales de como NO llevar un proyecto, me abrió los ojos, y desde entonces he intentado seguirlo.Este libro contenía una lista bastante amplia de los errores más comunes en proyectos informáticos. En el 2003, en un proyecto en el que participaba y tenía problemas de planificación, comprobamos cuantos errores de esa lista cumpliamos, el resultado fue el 90%.
Cuando enseñé la lista, y los ejemplos que venían en el libro al jefe de proyecto y al gerente, la respuesta fue clara:
1. Nos pagan por horas
2. El libro es muy antigüo
3. Son teorías americanas, no aplicables
4. No estamos de acuerdo con el libro

Por su puesto, el proyecto fue un desastre….

2. El cliente
Todo los informáticos decimos lo mismo; el cliente no sabe lo que quiere, pero la realidad es que el cliente sí sabe lo que quiere, lo que pasa es que no sabe como expresarlo, tenemos que empezar a pensar en eso. Ellos no son consultores, tienen un problema y quieren una solución, pero siempre nos perdemos en el proceso intermedio. Existen algunas aproximaciones, como el Domain Driven Design, pero requiere cierta capacidad de comprensión por parte del cliente.

Así, pues, la culpa no es tanto del cliente, como la comunicación entre cliente y consultora. Sobre todo, cuando te llega el cliente un lunes, y te dice que ha visto el especial del Domingo del periódico que con RoR se desarrolla 10 veces más rápido, e intenta convencerte para que cambies todo el proyecto y le hagas una rebaja.

3. Las consultoras

Las consultoras, ufff, uno de los altos cargos de mi antigua empresa nos decía, nuestro valor, son las personas, sólo invertimos en personas, en lo demás no invertimos nada. Eso lo decía cuando éramos 90 empleados, y lo siguió diciendo cuando éramos más de 1.000. Mientras al principio nos matabamos por hacer que la empresa creciera, con 1.000 empleados, nos matabamos por salir los primeros a la hora de comer para no coger tráfico………

Otras consultoras, como Accenture, su valor radica en la capacidad de gestión de grandes proyectos, capacidad para tratar con el cliente, pero sin embargo, en el aspecto técnico dejan que desear.

El problema, es que hacer las cosas bien cuesta mucho dinero, justificar antes una dirección 200.000€/año en I+D+I para ser más productivos no es algo que pocas empresas quieren aceptar.

Así que las consultoras siguen como hace años, y para ser mas competitivos, hacen cosas como gastar menos en teléfono, viajar en turista, y utilizar la videoconferencia en lugar de reuniones.  Y en todo caso, trasladan la perdida de competitividad a las subcontratas, ajustándoles más los precios.

4. El informático

Uno de cada diez informáticos, es un espécimen raro,  se desvía de las tareas que le han encomendado, por que ha encontrado el PlugIn XXX5.6beta para la herramienta XXX6.Prerelease, y se le ocurre reestructurar la mitad del proyecto por que supuestamente es más bonito, o más rápido, o simplemente está aburrido.

Si algo funciona bien, usaló, no lo cambies, y si te gusta trastear, busca un departamento de I+D o similar. Investigar dentro de los proyectos no es bueno, por experiencia propia.

5. Reutilización

¿Cuantas aplicaciones conocéis que usen fechas? Casi todas!!!

Pues en uno de los proyectos, hacer una clase para manejar fechas, costó unos 4.000€. Simplemente, el programador decidió que podía hacerlo mejor que nadie, y que prefería hacerlo de nuevo en lugar de utilizar algo que ya existiera.

Las empresas no reutilizan nada, de nada, vuelve a inventar la rueda. Te puedes encontrar a dos personas evaluando el mismo producto, probando la misma herramienta, o mirando como se hace una clase para manejar fechas.

6. Formación

La formación, actualmente es muy deficitaria, trabajo a menudo con becarios, de informática y de módulos de F.P., los becarios de F.P. está mucho mejor preparados, los que han estudiado informática, no han hecho una aplicación con base de datos en su vida, no sabe lo que es una transacción, sólo especificaciones de lenguajes y algún que otro algoritmo tonto.

Y parte, la formación continua de las empresas, ha bajado muchísimo de calidad con la formación a distancia, te sueltan un powerpoint, y un cuestionario online, y a eso lo llaman curso online.

7. Los tiempos cambian, la burocracia aumenta

Todo el mundo es consciente de que a la hora de llevar un proyecto, hay que documentar, seguir unos pasos, unas fases, pero no podemos llegar a mera burocracia, donde más del 50% del documento es Copy&Paste de otro, que se hace para “cumplir con calidad”.

Los tiempos cambian, nacen formas de trabajar más rápidas, como la programación agil. Nacen herramientas que agilizan el trabajo, como el uso de Wikis en los proyectos, foros, etc…

Conclusión

Quizás las ideas no están muy ordenadas, pero prometo otro artículo, donde explique como se hacen bien las cosas, pero esto es fácil de encontrar, podemos leer sobre CMMi, Microsoft Solution FrameWork, etc…

Subscribe

Subscribe to our e-mail newsletter to receive updates.

One Response to “Carnet de programador”

  1. christian Says:

    Muy interesante y certera explicación del como nos equivocamos. De acuerdo al 99% y totalmente en cuanto a lo de innovar dentro de proyectos. A mi juicio, origen de muchos de los problemas técnicos, retrasos, etc

    Directamente enviado a mis colegas CTO para aporten sus experiencias.

    Saludos,

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies