Desarrollo de software. Especialistas en testing y en integración

Dentro de la mediocridad generalizada existente en el desarrollo de software (afortunadamente existen excepciones y cada vez son más) en la que la mentalidad que predomina es ejecutar trabajo sea como sea (de manera real o virtual, es tan doloroso como habitual lo de virtual) para facturar cuanto antes el importe del proyecto y pedir una ampliación, dejando en un segundo o tercer plano (cuando no aparcadas) las expectativas del cliente o del usuario, resulta normal que muchas organizaciones no tengan en su plantilla especialistas en testing y en integración para los proyectos que desarrollan para terceros (aunque paradójicamente ofrezcan en muchos casos esos servicios a terceros).

Es cierto que hay equipos de proyectos de alto nivel y con gran experiencia en determinados tipos de desarrollos que si tienen buenos hábitos podrían ser autosuficientes pero, ¿es eso lo normal?, ¿podrían tener estos equipos más rendimiento con un especialista en testing y en integración que colaborase con ellos?.

Como es bastante frecuente que los propios errores en los productos que se entregan vuelvan a ser imputados al cliente (de alguna u otra forma), los que miran el proyecto desde una hoja de cálculo y no a los ojos de los usuarios no terminan de darle la importancia que tiene que te devuelvan una entrega o que te entreguen un listado interminable de incidencias.

Sin embargo, los clientes están evolucionando y más en una circunstancia de crisis como esta y ya no se muestran tan flexibles y generosos en las negociaciones, lo que provocará un impacto económico en el proveedor que si además no responde bien (que no lo hará si tiene grabada en su cabeza una actitud contable y no una actitud responsable) terminará por perder el cliente.

Tener este tipo de especialistas tiene un coste, también unos beneficios (si se integran bien en el proceso de producción) pero es necesario antes de afrontar este tipo de contrataciones, las características de los proyectos con los que vas a trabajar, su duración y la evolución prevista del negocio.

Anuncios
1 comentario
  1. jes dijo:

    Gran verdad lo que cuentas. Pero tb hay q destacar que normalmente no se planifica tiempo para pruebas (junit) pq las pruebas con el navegador no las veo útiles. Lo bueno de junit es que te garantiza que el core funciona, y cuando ha funcionado y cuando no. Revisable, fiscalizable, accountable.

    Respecto a las prisas por entregar, y que las modificaciones las “pague el cliente”, la verdad pocos casos he visto. Otra cosa es que haya una mala definición de requisitos. En ese caso, ambas partes son culpables.

    Cuando hablas de una lista interminable de incidencias, creo que esto implica un fracaso por todas las partes. Primero pq no ha habido un seguimiento por ninguna parte: cliente, proveedor e integración (me gusta la llamar a esta gente ITIL).
    Cliente: ha pasado del producto hasta su implantación… (si yo como cliente pago, y no le doy la importancia que tiene… soy responsble del error: tiro el dinero de mi organización a la basura, mi responsable de tirará de las orejas…)
    Proveedor: si tengo que realizar algo por lo que me pagan, y lo entrego mal… soy responsable. (mi jefe me dirá que qué coño estoy haciendo…)
    ITIL: Si no soy capaz de saber las necesidades del cliente, y no tengo apoyo del proveedor… y mis incidencias son de risa, pues tb lo soy, pq tiro el dinero que no es mío. (el cliene me dirá que porqué me enciendo lo cigarrillos con sus billetes de 50€…)

    Moraleja, en tiempo de crisis hay q potenciar las entregas decentes. Por lo tanto hay que:
    1. Implicar al cliente (delegando en un responsable) en un detalle de requisitos
    2. Apoyar al proveedor, con un seguimiento constante (para evitar, A: esto así no me sirve, B: Pues es lo qu epone en los requisitos)
    3. Implicar a ITIL: usar como PKI el número de incidencias, pero a la baja. Esto implica que cada vez se hacen mejor las cosas.
    4. Para implicar a ITIL, hay que involucrarlo en los proyectos. Para ello está el FSA (forward schedule action creo), de forma que en el handover (entrega) vayan de la mano ITIL y proveedor.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: