Errores t�cnicos

Hoy he tenido ocasi�n de comer con un par de bloggers “de post�n”, y a lo largo de la comida hemos hablado de algo que yo siempre tengo en mente. Me explico, por formaci�n soy “administrador y director de empresas”. Siempre he tenido la visi�n “de negocio”, por encima de una visi�n t�cnica.

En mi carrera de consultor he conocido a m�s de uno y m�s de dos t�cnicos. Adem�s, t�cnicos cada uno en lo suyo: ingenieros industriales, telecos, inform�ticos… pero tambi�n abogados, especialistas en bolsa… vamos, cada uno de su padre y de su madre.

Sin embargo, en todos (salvo honrosas excepciones) he detectado un signo com�n: la tendencia a admirar la excelencia t�cnica de cualquiera de sus creaciones por encima de la utilidad (en t�rminos absolutos y en t�rminos relativos al coste) de las mismas. Los t�cnicos tienden a enamorarse de las “soluciones perfectas”, y les cuesta quedarse con un “second best” que quiz�s no sea tan extraordinario, pero s� suficientemente �til. Adem�s, no tienden a valorar los costes de aceptaci�n de sus dise�os: pueden llegar a algo super-eficiente, pero si eso genera dificultades en los usuarios… simplemente, no lo usar�n.

Mi formaci�n “generalista” me imposibilita llegar a algunas soluciones que requieran esa excelencia t�cnica. Pero a cambio me permite evitar ese perfeccionismo t�cnico y, creo, ser “contingencialista” y “posibilista” (vamos, que podr�a ser gallego: “todo depende”).

También en

Raúl Hernández González

Soy Raúl, el autor desde 2004 de este blog sobre desarrollo personal y profesional. ¿Te ha resultado interesante el artículo? Explora una selección con lo mejor que he publicado en estos años.

¡Y si te suscribes podrás seguir recibiendo más reflexiones y herramientas útiles para ti!

También en

Latest posts by Raúl Hernández González (see all)

0 comentarios en “Errores t�cnicos

  1. Recomiendo leer una entrada muy interesante (y sus comentarios) en ESTRATEgA . El fondo de la cuesti�n tratada es de �mbito m�s gen�rico pero creo que podr�a aplicarse perfectamente a este caso particular: La adopci�n de la tecnolog�a no debe hacerse “porque s�” sino que deber�a justificarse en base a su necesidad real

  2. La descripci�n de la profesi�n de ingeniero es la de dar la mejor soluci�n t�cnica posible adaptada al presupuesto y al plazo disponible.

    El problema es que no se desarrollan las tres patas (excelencia t�cnica, eficiencia en plazo, eficacia en el uso del presupuesto), ni en la universidad, ni luego en el trabajo desp�es, donde lo normal es que te toque una funci�n sesgada, o de t�cnico, o de administrador, o de gestor de proyecto.

    Yo estoy contento, comenc� en consultor�a, luego cambi� el rumbo y he vuelto a ella tras un paso por la ingenier�a, participando en temas t�cnicos y de gesti�n de proyecto indistintamente, lo que ciertamente me da una visi�n distinta, m�s global de las necesidades del cliente a la hora de hacer consultor�a.

    Volviendo al tema, como dec�a Alexander G. Bell (y han olvidado sus descendientes operadores telef�nicos) lo importante es el servicio: dar al cliente lo que necesita, ni m�s, ni menos.

    Ni complicaci�n innecesaria, ni negar posibilidades.

  3. Es cierto. A mi por ejemplo, me ha servido mucho la mezcla de falta de tiempo y de vagancia, para simplificar varios de nuestros servicios o procesos.

    Si pasa por el filtro mio y de mi padre, es que es f�cil y �til.

    Tengo un smartphone de 400 euros, y sin embargo siempre llevo 2 folios en los que est� toda mi agenda semanal y mensual. Para esto, las aplicaciones del movil no me sirven, aunque si para muchas otras claro.

  4. Es cierto lo que dices y creo que el fallo en el desarrollo de esos proyectos que al final no son �tiles, es la elecci�n del equipo. Cada cual tiene que aportar su granito de arena y conjugar todos los perfiles en una sola persona es crear un super(man-woman). As� que creo que la labor del t�cnico es crear una soluci�n �ptima y la labor de otros la de definir los requisitos que ha de cumplir para que sea v�lida. Y tan importante es una labor como la otra.

  5. Vale, Yabu, touch�. Aunque a veces, hay formas de hacer dinero que son un verdadero arte…

    Fernando, me gusta mucho tu enfoque equilibrado. Creo que no podr�a estar m�s de acuerdo. Quiz�s, como dice trex, no es f�cil que una misma persona tenga la visi�n global, as� que un equipo compensado posiblemente llegue al punto medio, que es el de la virtud.

  6. Como decirlo sin ofender, bueno la parabola del coche.
    El cliente quiere un coche, me dice el precio, por ese precio se le promete un mercedes, un camion, un deportivo, … un pasaje de por vida en el puente aereo …
    Ahora ponte a hacer el coche, tienes un quimico, un biologo, un informatico, un teleco recien salido, y un tio que lleva mucho tiempo en la empresa que va a ser el que haga el coche. No contratamos a un Ingeniero porque estan caros y total nosotros podemos hemos hecho muchos coches.
    Bueno resulta que tengo un bicicleta que la extiendo poniedole dos ruedas, que le pongo un motor el que sea si total en mi casa puede con el peso, le pongo el telefono de una agencia de viajes, un abono transporte, bueno ha compilado, funciona.
    Ostras lo ve el cliente, donde esta su descapotable y su camion, bueno pero sirve para andar, pero no es un coche, da igual no necesita el mercedes, ni el camion y total anda, pero hay que comprar una grua con 600 caballos, bueno no va mal es que al final queria mas de lo que dijo, la grua es un poco ancha, aumentemos la carretera, hay que tocar los tuneles del Pardo, bueno si no se pueden tocar es porque lo dice el cliente, no ha funcionado bien porque el cliente lo ha asumido.
    Que bien vende fulano, que proyecto mas guapo mengano, el tio de teleco y el informatico todo el dia diciendo que eran una chapuza, esos no interesan, contratemos a los otros dos para el mantenimiento que sale barato, total ya hay una fase B en la que con todo el dinero que nos dan seguro que podemos hacer un aeropuerto para Barajas, estacion de Chamartin, la M30, la M40 , y funcionara …
    Con lo bien que compilaba …

  7. desde luego consultor, que �cido eres…este chiste es el del escarnio de los analistas…

    Vamos a veryo creo que una muy buena aproximacion al problema es la famosa regla de pareto: 80-20

    La idea es invertir el esfuerzo en el 20 % de los ‘requisitos’ (y permitirme que los entrecomille, porque segun de quien vengan, muchas veces el ingeniero se los tiene que traducir del arameo) que hacen que el 80% de las necesidades estan cubiertas

    Puede ser una regla simplista, pero en la pr�ctica, creo que ayuda a aunar necesidades y recursos necesarios

  8. Que cachondo le haces el 80% del coche, por mi vale.
    Pero resulta que para que este el 80% hay que contratar a un Arquitecto que te haga el 20 % que te permite hacer el 80 % sin problemas.
    De todas formas, es poco serio hacer el 80 % de lo que paga un cliente.
    Cuando empeze me dedicaba a hacer diagramas de proyectos en una Consultoria (servicios) al principio los intentaba hacer adaptandome al personal y requisitos, pero mi jefe me dijo muy bien pero ponemos 3 meses en vez de 9 nueve, muy bien pero en vez de hacer primero la parte de Arquitectura empezamos por algo que pueda ver el cliente, no pasa nada aunque fulano no sepa con lo que va a cobrar que se compre algunos libros y que llame por telefono.
    Y esto solo los jefes luego estaban los programadores, cuanto vas a tardar 5 minutos, a los dos dias cuanto te queda 5 minutos …
    No puede ser tan dificil poner una � en una pagina Web, si porque quiero hacerme una interfaz para que en funcion del idioma …
    Vamos que si a eso le a�adimos que yo tambien tengo lo mio, mas nos vale hacer el programa de BuenaFuente

  9. Barbyware, no me he explicado bien…

    En principio, lo del 80% del coche no me parece mal, aunque no de la forma en que tu implicitamente lo estableces…

    lo que quiero decir es que si tus requisitos de coche te dicen 150CV y 4 ltrs/100Km, y sabes de antemano que eso te va a disparar los costes del proyecto-coche…pues un buen compromiso (suponiendo que necesites llegar a un compromiso), yo que se, es proponer 135CV y consumo de 5 l/100Km? la verdad es que ese no es mi campo, pero seguro que el esfuerzo es bastante menor que con las especificaciones anteriores. Y te ayuda ademas a manejar el riesgo de fallar totalmente el proyecto en plazo, margen, calidad, o las tres a la vez…mejor un 80% de coche que funcione, que la bicicleta de consultor anonimo :)

    El que si es mi campo es el desarrollo de sw, y si, alli esta regla aplica y bastante bien, al menos en mi experiencia. Por supuesto, necesitas de la aceptacion del cliente, pero como puedes ver por el post inicial de consultor anonimo, ese no es precisamente el problema.

    Ahora, en mi opinion, en tu caso el que deberia permanecer m�s enfocado es tu jefe, que es el responsable del proyecto. Al final muchas de esas funcionalidades a�adidas no las usa nadie, y, si el cliente hubiera podido elegir entre precio/plazo y funcionalidad, hubiera elegido lo primero

  10. No estoy hablando de un caso personal, por suerte. Sino de lo que veo a mi alrededor y en mi entorno que tambien es la informatica. Y por desgracia para los informaticos, a todos los clientes se le vende el coche de Fernando Alonso y se les entrega el “Hibrido del desierto” (cuatro ruedas tiradas por un burro). No hemos hablado de los jefes que se las traen tambien, y creo que me podria interesar vuestra opinion en este tema. Y tampoco hemos hablado de los programadores que vaya tela tienen, con su en 5 mnutos te lo tengo. Y como no tenemos a los analisistas, a los arquitectos, a los filosofos del software y demas fauna que hay en este mundillo. Y luego terminamos en el tema que nos implica, la tecnologia usada por que si. La propia definicion de tecnologia implica que no es utilizada porque si. Ya que la tecnologia es la ciencia aplicada a la resolucion de problemas, sino resuelve problemas que es la “tecnologia”, pues algo asi como “ciencia” e investigacion.

Deja un comentario