¿Te ves como un verdadero profesional?

Tanto se los he dicho que ya están empezando a darse cuenta de que realmente no entienden las necesidades del negocio. Al parecer ellos se meten en la programación desde chiquitos y el mundo se les achica tanto que no comprenden que hay compromisos asumidos y que el cliente está esperando el producto. Pero bueno, yo sigo explicándoles y varios lo entienden bien pero hay un par que verdaderamente no parecen estar muy convencidos.

Lo peor de todo este asunto es que cada vez trabajan más lento y cada vez peor. Yo no sé que les pasa. Justamente la semana pasada los reuní para hablar de este y otros temas pero no pude lograr mucho. Yo quería entender que era lo que les estaba pasando y en lugar de eso volvieron a salir los mismos temas de siempre; sobre todo el que “el código es un asco”.

Yo les dije: señores, al código lo escribieron Uds. no sé que puedo hacer yo al respecto. Es más, me dicen que aquello por lo que les he estado pagando todos estos meses, es un asco?  Fue entonces cuando uno de los programadores me dice que en gran medida los problemas se deben la falta de tiempo para hacer las cosas bien y que esa falta de tiempo era debido a la cada vez mayor presión que yo ejercía sobre los plazos para entregar o mostrarle resultados al cliente.

Si si, parece increíble pero eso fue exactamente lo que me dijo. Y parecía existir cierto consenso por parte del resto en cuanto a ese parecer. Nuevamente les dije: señores, yo no sé cuanto tiempo requiere hacer tal o cual cosa y es justamente por eso que les pido una estimación para presentarle a los clientes. Lo que sucede es que una vez que se lo presento a un cliente, deja de ser una estimación para convertirse en un compromiso.

“Claro!” dijo Carlos, “lo que pasa es que muchas veces para cumplir con un compromiso uno tiene que resignar algo y ese algo se llama calidad”. Miren muchachos! –les dije – ¿qué pensarían Uds. si contrataran a un albañil para que les construyera una pared y él, para terminarla en plazo, la hiciese sin cimientos, cruzada, inclinada y llena de orificios?. Seria verdaderamente inadmisible ¿cierto?. Pero si es inadmisible en el caso de un albañil, en el caso de los programadores debería de ser mucho más aún. ¿No les parece? – pregunté.

———————————-  Fin.

Sin categoría

15 thoughts on “¿Te ves como un verdadero profesional?

  1. Eso es lo que yo llamo madures laboral. Para muchas personas programar es un hobby, pero no una profesión. Aun no entienden el mundo real ni la «responsabilidad».

    Este fin de semana llevamos acabo una actualización de un sistema en los servidores de una empresa. Terminamos el día domingo en la noche (hace unas horas). No había la opción de que sea el día lunes y decirle a la empresa: «disculpen, hubo un problema y no van a poder trabajar ni atender a ninguna persona todo el día de hoy, mejor cierren la empresa y esperemos que para mañana este listo»

    Esa opción NO EXISTE, si o si, no valen las escusas, no importa si algún familiar mio muere, alguien tiene que hacer ese trabajo. Podría sonar exagerado, pero no lo es. El mundo laboral es así, y así tiene que ser.

    Lamentablemente ese conocimiento no te lo dan la universidad y así lo leas, no lo entiendes; la única forma de tener esa «actitud» es tener experiencia en la «responsabilidad».

    Se tiene que entender, que lo que tu haces es producir beneficio a las personas y la sociedad te retribuye por eso. Entender que las personas se organizan para vivir juntas, cada quien se especializa en algo que produce beneficio a otras personas; y lo que tu tienes que hacer es PRODUCIR BENEFICIO A LAS PERSONAS.

    No se tiene que buscar escusas para protegerse, se tiene que ver porque YO ME EQUIVOQUE, porque diablos no calculo bien mi tiempo, porque no soy consiente realmente de todo lo que significaba programar eso exactamente, como puedo mejorar, que cosas puedo aprender de lo que paso. Porque lo mas importante es, que las personas que te contratan y te van a retribuir por brindar un beneficio, no son tus victimas, son personas a las que tienes que brindar un beneficio.

    Saludos

  2. Bueno.. lo intento, pero ahora mismo, desde febrero, que no me asignan a ningun proyecto (soy desarrollador de .NET), pero dentro de lo que cabe, estoy mirando, preparando y haciendo cosas de .NET.. si, abarco todo lo posible e intento hacer lo mejor posible.. pero mi empresa.. no me ve como tal.. me quieren meter en un proyecto de un lenguaje tageado de terceros (unico y simple), de manera que para mi es una «degradacion» a mi preparacion y conocimientos (he de trabajar con ese lenguaje, que funciona en servidor, con javascript y html), cuando en realidad, desarrollo aplicaciones asp.net, Entity framewrowk, silverlight etc..
    ¿me veo como profesional?.. no.. para la empresa soy un informatico… la «chacha» para todo…

  3. Compañero de fatigas, el problema es tuyo. Ni del equipo, ni de la calidad. Es tu responsabilidad el comprender lo antes posible, por el bien del poryecto, que las estimaciones que te están dando son eso: estimaciones.

    Quien lo está convirtiendo en compromiso eres tu ante el cliente. Lo cual es una práctica erronea sin el colchon o margen necesario en la elaboración de software.

    El desarrollo NO ES ARQUITECTURA. No puedes contar x mil ladrillos por x horas por persona y realizar una estimación. El desarrollo debe y tiene un enorme margen de error en sus estimaciones. Y, siguiendo el simil arquitectonico, se cuentan con los dedos de una mano las grandes obras que se realizan en plazo y presupuesto.

    Perdoname, pero en tu post lo que se destila es un serio problema de gestión del proyecto. Tal vez te sea interesante empaparete y empapar a tu cliente de procedimientos Agiles de desarrollo, en donde el cambio es parte integrante de una evolución mucho más natural del producto.

    Por último, señalarte que en las reuniones pones al equipo en un dilema indisoluble: 1. El desarrollo cada vez es más lento. 2. Las cosas son más lentas porque la calidad es mala. 3. La calidad es mala por la presión de los plazos. 4. La presión de los plazos es por estimaciones erroneas echas compromiso con el cliente. 5. Las estimaciones son erroneas por… (volvemos al punto 1). El único sitio para romper el circulo vicioso es impedir que se convierta en compromiso una estimación erronea.

  4. 100% de acuerdo con Juan.

    Y muy en desacuerdo con ese extraño sentido de la autocrítica que asume como error personal las desviaciones en la estimación. Todos los desarrolladores que conozco son profesionales, algunos excelentes, la mayoría con un elevado sentido de la responsabilidad (que ya quisiera yo ver en otras profesiones)…y del primero al último erran sus estimaciones.

    La cuestión es cómo se canaliza esta desviación internamente y en la comunicación con el cliente, y quienes gestionan esto bien son quienes finalmente entregan los productos mejor acabados. Acaban produciendo el valor que el cliente espera. En cambio, los lugares (y algunos los he sufrido personalmente) que no admiten esta visión degeneran en entornos laborales altamente hostiles, gastan más recursos y entregan productos faltos de calidad.

    Es sólo un apunte, felicidades por tu blog.

  5. Si bien no creo que haga falta, debo aclarar, o mejor dicho, debí aclarar que el personaje que relata la historia no soy yo sino un hombre de negocios realmente preocupado por lo que sucede con el proyecto. No es un cuento propiamente dicho sino una especie de ejercicio mental de pararse del otro lado del mostrador y ver que pasa.

    Cometí el error de hacerlo por demás sobervio e insultante en el primer párrafo pero no me extrañaría encontrar un comentario similar en la vida real.

    Bueno, la verdad es que no perseguí nada mas que reproducir una situación muy cotideana y hacer una autocrítica encubierta, no como individuo sino como comunidad. Pero la verdad es que las respuestas no las esperaba, o al menos no como surgieron. Veo varia cosas:

    – Autocrítica 0 (cero). No hacemos nada mal y por lo tanto somos perfectos por lo que no podriamos nunca mejorar.

    – Los problemas son exógenos. Los culpables pueden encontrarse en todas partes salvo en los espejos.

    – La extraña falacia: mala estimacione => mala calidad. El ejemplo del albañil es claro, si no le da el tiempo no la termina pero no levanta la pared sin cimientos, ni cruzada, ni inclinada ni llena de orificios.

    – La creencia, y el absurdo e insostenible discurso, que dice que para llegar a tiempo es necesario hacer las cosas mal. Y el que hacer las cosas mal sea algo que nos lo pide el negocio. Ridículo!. Ridículo!. Ridículo!

    – Decirle a quien invierte su dinero que después de varios meses, y después de mucho dinero, se tiene un asco!?. ¿Puede esto estar bien?

    Cuando se hace algo de manera «poco» profesional por pedido de alguién, se deja de ser un profesional para ese alguien. Y cuando se deja de ser un profesional, se convierte en uno m’as de los tantos no-profesionales de la empresa, como las personas de seguridad, los de limpieza o como cualquier otro y es ahí cuando «para la empresa sos un informatico… la «chacha» para todo…». Esa es nuestra herencia y nuestro desafio.

  6. Yo creo que si me piden que realice X funcion en 3 horas respondo: no puedo, no es tiempo suficiente, pero si me replican: «Es que no te lo estoy pidiendo», respondo «Si señor» y hago el codigo con la calidad de 3 horas de desarrollo… es asi de sencillo.

  7. Los gerentes de proyecto solo escuchan lo que quieren escuchar, me ha sucedido que «Eduardo, cuanto te demoras en hacer el reporte», respondo «10 horas», me replican «Porque tanto», respondo «Tal vez me demore 8 pero es mejor tener un par de horas de beneficio», me replican «Le voy a decir al cliente que lo tendremos listo mañana en la tarde (8 horas despues)». ahi esta la típica situacion de presión para entregas, como se puede asegurar la calidad del software con una situacion asi??

  8. @Proco: a eso mismo me refiero cuando digo que falta profesionalismo. Imaginate si un profesional de otra rama actuara así. Imaginate si el dueño de los consultorios de odontología les dijera a los odontólogos: Muchachos, las ondodoncias las van a hacer en no mas de 30 minutos! ¿Que sucedería?

    Tampoco entiendo por qué cada vez que te preguntan cuanto tardas, vos tardas menos. La primera vez le decis que tardas 10 horas y un segundo después le decis 8!!! ¿Le estabas mintiendo la primera vez? ¿y si te preguntaba si no lo podes hacer en 6? ¿que le contentabas? ¿que sí?. Yo también te seguiría preguntando.

    Si ese es el caso, ni te molestes en calcular nada y simplemente hace así:

    – Eduardo, ¿cuanto te demoras en hacer el reporte?
    – ¿Cuanto quiere que tarde seños?

    Existen mil respuestas mejores en el caso que planteas. Por ejemplo:

    – ¿Eduardo, cuanto te demoras en hacer el reporte?
    – 10 horas
    – ¿Porque tanto?

    R1: Porque eso es lo mínimo que hemos tardado para hacer los resportes anteriores.

    R2: Porque es lo que calculo que puede llevarme el terminarlo.

    R3: Si no tiene que funcionar, lo puedo hacer en 15 minutos… pero hacer que funcione me va a tomar aproximadamente ese tiempo.

    R4: Realmente no sé si me va a llevar exactamente 10 horas. Esa es solo una estimación que Ud. me pidió. Probablemente lleve un poco menos o probablemente un poco más.

    R5: Si quiere puedo hacer un reporte menos complejo. Seguramente llevará menos esfurzo.  

    R6: ¿por qué dice que es mucho?.

    Ante un sinsentido como ese cualquier respuesta es buena. Después de todo, si el supiese realmente cuanto consume esa tarea no te lo preguntaría. Te pregunta porque sabe que no sos muy profesional y que le vas a seguir diciendo un número más y más bajo cada vez.

    ¿Te das cuenta que es tu falta?    

  9. De todos modos, esto de la estimación es complicado.

    Yo lo que opino es que hay que hacerle entender al cliente que la estimación siempre es aproximada. Si la persona responsable del proyecto no es capaz de transmitir esto, no está cumpliendo su función.

    Para los proyectos en los que se parte con una fecha cerrada, lo que yo suelo hacer es priorizar requisitos. Y en función a una estimación, dar una idea de los requisitos que serán implementados para esa fecha.

    Si aún así se requiere una fecha cerrada, hay que agregar un gran porcentaje de margen «por si acaso».

    Si lo que ocurre es que tienes que decir que sí, porque sino no te asignan el proyecto, es un riesgo que estás asumiendo. Porsupuesto que no puedes pedir a los «albañiles» que paguen el coste de un riesgo que tú has asumido.

    Otra cosa importante, es desarrollar herramientas, procedimientos, políticas, basadas en experiencias anteriores, para estimar de forma más segura. No dejar toda la responsabilidad de la estimación al programador.

    No olvidar tampoco, que la ley Parkinson siempre se cumple: «el trabajo se expande hasta llenar el tiempo disponible para que se termine», por lo que un poco de presión nunca viene mal.

  10. Ah, olvidaba otra cosa: La calidad es un parámetro más que siempre puede ser negociado. Puedes decirle al cliente: La pared, con cimientos, cuesta X.
    Sin cimientos y con agujeros, X-N. A lo mejor, la seguna opción es suficiente.

  11. Cuantas cosas! bueno, en principio creo que el resumen sería: No, no me veo como profesional.
    Por alguna extraña razón esto derivó en el tema de las estimaciones y parece que no hay nada que pueda hacer al respecto.

    Por otro lado, la idea de negociar los cimientos me ha dejado pensando en cuanta gente estaría dispuesta a ahorrarse unas monedas evitando hacer cimientos. Realmente no sé si vería casas sin cimientos o si por el contrario, habría millones de idiotas con casas rajadas y undidas por esas monedas. Aunque para mi es absurdo, no dudo que habría casa sin cimientos.

    Este tema me lleva a pensar además en si la calidad es o no algo negociable. Mucha gente que responde mis post siempre usa la frase «La calidad no es negociable», algo que todos escuchamos muchas veces, ahora vos decis que «La calidad es un parámetro más que siempre puede ser negociado». Es interesante repensar esto.

    Por último, el tema (que ya apareció antes) sobre los «colchones» o «buffers», me generan algunas dudas. Yo no creo en ellos ya que son tiempos no justificables bajo otras formas mas que el «por si acaso». Prefiero la negociación franca y frecuente pero es una práctica muy común, es cierto.

    Tampoco creo mucho en la «ley de parkinson», recuerda que este señor era un comediante que quizo hacer una broma sobre las burocracias de su tiempo y no una ley real. La creencia en ley de Parkinson es una evidencia de la falta de profesionalidad contra la que debemos luchar.

  12. Pues yo sí me veo como un profesional. Y no porque haga un trabajo perfecto, ni porque las cosas me salgan siempre bien, sino porque intento hacer mi trabajo lo mejor que puedo, y apuesto por ello, y me comprometo siempre al máximo.

    Yo creo que esto se ha ido por la rama de las estimaciones porque es una parte muy crítica de nuestro trabajo. Si fallas ahí, comprometes muchas cosas; por ejemplo la calidad.

    La calidad es negociable en el software de la misma manera que lo es en un coche, o en una casa, pero con la diferencia de que no existe legislación que establezca unos mínimos, ni especifique responsabilidades ante incumplimientos. Yo puedo elegir comprar un ferrari, o un peugeot. Y la calidad se verá reflejada en el precio.

    El tema de los colchones es necesario porque si no, ¿cómo resuelves la incertidumbre en la estimación? lo más lógico es pensar que será una proporción del total de horas.

    Y el tal Parkinson, sería un humorista, pero chico, ha acertado de lleno. Ahora mismo no se me ocurre situación, no ya del mundo informático, sino de la vida en general, en la que no se cumpla el postulado.

  13. wow no leí todos los comentarios, me quedé en el de @Proco porque me pasó con un PME de Microsoft directamente que hacía de gerente de proyecto con un cliente, si te digo que tardo mil años respétame mis mil años que por algo te digo ese tiempo, eso no lo entiende quien no desarrolla.

    En cuanto al comentario de Juan, no puedo estar de acuerdo, perdón me causó demasiado ruido el tema de que las estimaciones son solo estimaciones. Los equipos de desarrollo per se, dependen de una cohesión nada sencilla para poder ser eso, un equipo. Y no estoy contando al líder del proyecto, el gerente del área o el que sea que le tiene que entregar los números, tiempos, avances y retrasos al cliente o responsable.

    Me preocupa el que un equipo sacrifique calidad por tiempo, pero es tan común que hasta lo ví en una entrevista de trabajo que me hicieron, al final el entrevistador termino siendo el entrevistado y no me contrataron por no tener un título universitario.

    Considero importante que a los desarrolladores, como a todos los demás profesionales, les debe gustar su trabajo, debes disfrutar lo que haces porque hay un tema de motivación, investigación y entusiasmo que no aprendes en la universidad, ni en ninguna academia, es algo propio, sale de ti mismo y no importa si te sientes o no profesional, es allí donde juega un papel vital tu superior para darte la orientación que desea la empresa, puedes ser excelente, cumplir los tiempos y no tener un código entendible por otros, entonces allí entra tu superior y te enfoca en el poder escribir código legible según la lógica aplicada en la empresa, pues cada cual tiene una distinta aunque algunas puedan ser similares.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *