Pages Menu
Categories Menu

Posted by on Nov 3, 2016 in General | 1 comment

Cómo un Dpto. de compras puede matar a su propio Dpto. de TI (e incluso a toda la empresa) (2/2)

Está es la segunda parte del post que empezamos ayer, que puedes encontrar aquí

como-compras-mata-a-tecnologia

2 – Pedir documentación en los contratos y quedarte con la conciencia tranquila 

Lo que pides es lo que obtienes. Quieres papel… te darán papel. Pero realmente…  ¿para que le pides documentos al desarrollador? ¿para no depender de él? ¿para que te deje por escrito lo que hizo? ¿en un papel? ¿para que luego alguien después lo lea y supuestamente… pueda continuar el trabajo?

Pero piénsalo por un momento… ¿crees que lo que alguien te escribe en un word coincide con lo que te han programado? ¿crees que por tener un montón de pdfs controlas la situación? ¿crees que pedir comentarios en el código es buena idea?

Querido Dto. de compras… Con todo esto estás dándole a malos programadores la mejor excusa para en vez de programar bien, y que así realmente el desarrollo sea mantenible, programen mal y te lo intenten explicar en un papel. Y habiendote entregado el papel… han cumplido. 

No pidas papeles… pide buenos desarrollos, con buenos test, con integración continua, código limpio, etc., eso si que te ayudará a mantener y no un pdf.

3 – Fechas imposibles

Si piensas que apretar fechas, y así reducir costes, sale gratis estás equivocado. De hecho te puede salir muy caro.

Si eliges a tu proveedor en función de aquel que te dice menos tiempo… el proveedor te dará lo que quieras oír con tal de llevarse el proyecto, y entrarás en proyectos de tiempos rozando lo imposible. Y con tiempos imposibles… te van a crear un software tan penoso, aunque posiblemente funcional y en fecha, que sólo podrá evolucionar aquel que lo toco, decisión de la que pagarás sobre costes de mantenimiento el resto de tu vida, que frenará la velocidad de tu negocio. deuda técnica le llaman.

4 – Pagar por horas

¿Aún pagas por horas? ¿horas silla? ¿pagas por personas sentadas? ¿bolsas de horas? ¿crees que en un trabajo intelectual, de ideas, estar sentado en una silla implica estar pensando en aportar valor e ideas? Horas en la oficina vs ideas y conocimiento aportado.

Además, de nuevo, pagar por horas premia a malos desarrolladores, si cumplo con el horario… “he hecho bien mi trabajo” y si encima quiero quedar mejor que el resto… “echo más horas” (aunque esté viendo el Marca)

Pero… ¿qué fue del valor aportado? ¿del trabajo bien hecho y realizado? Hacer trabajo que vale tiene algo que ver con las horas, pero no directamente, y en cualquier caso… ¿no deberías premiar más el valor aportado a negocio, el trabajo bien hecho terminado… que las horas sentado?

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. Hola Javier,

    muy buen post, según mi experiencia refleja muy bien el modus operandi de la manera de comprar de las empresas medias y especialmente las grandes.

    Yo no le “echaría la culpa” principalmente al departamento de compras, porque muchas veces estos piden requisitos formales (p.e. estar homologado, firmar NDAs, etc.) y quienes escriben los pliegos (o la metodología a cumplir) son los propios departamentos de informática, muchas veces influidos por alguna consultora que les ha hecho el proyecto de Gobiertno IT, calidad, riesgos…

    Sí que es responsabilidad de compras los ciclos de venta tan largos y farragosos, la obsesión por pagar a tropecientos días (hoy en día el interés está casi al 0%) y negociar con servicios de altísimo valor añadido la consultoría o la integración de sistemas como si lo hicieses con proveedores de materia prima.

    Quizás el punto donde sí influyen más los departamentos financieros y de compras es en el modelo de contrato cerrado y en las “subastas de horas”, bien de programadores o bien del precio completo del proyecto. Es un modelo funesto, porque aunque “contablemente” parece que ofrece ventajas al cliente (riesgo de presupuesto, penalizaciones, hacer la mejor compra objetiva, presionar a los proveedores…) al final como bien dices, la deuda técnica (y metodológica) que dejan estos proyectos hace que el dinero perdido en mantenimientos ineficientes del sistema entregado suela superar con creces el supuesto dinero ahorrado.

    A esto hay que sumar el enfoque funcional exagerado de muchas empresas (cada departamento se ocupa de “lo suyo”), así que incluso si alguien dentro de IT dice que esta manera de comprar proyectos es ridícula, mover toda la “maquinaria corporativa” es casi imposible.

    En fin, así les luce a este tipo de empresas. Poco innovadoras y con unos costes internos enormes que acaban compensando con su dominio del mercado.

    Alex @ http://www.itnove.com

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This