[MISC] Desarrolladores y testers despreciables

Muchas veces he presenciado actitudes que rayan con lo inverosímil, actitudes intolerables, actitudes éticamente reprochables.

Gente que simula estar trabajando, gente que no termina con una tarea para que no le asignen una nueva, gente que sobreestima el esfuerzo de sus tareas de una manera descarada, gente que reclama capacitación sobre cualquier trivialidad, gente que sobredimensionada sus asignaciones y las reporta de una manera sumamente compleja, llena de impedimentos, de dificultades técnicas inexistentes y un enorme arsenal de excusas que le permiten ocultar su ineptitud y falta de voluntad a la vez que los hace parecer sumamente profesionales y sacrificados.

¿Cómo es posible’?

Las causas pueden buscarse en la propia gente y en la cultura de la organización, pero fundamentalmente en el control. En mi primer trabajo tuve un jefe muy técnico, era quién sabía que se debía hacer, como debía hacerse, quienes podían hacerlo y cuánto esfuerzo podrían requerir las tareas. Todo el equipo trabajaba junto en una misma oficina por lo que él sabía exactamente qué estaba haciendo cada uno, como lo estaban haciendo, si existía algún problema técnico y si el proyecto se retrasaría o no. Recuerdo que por aquellos días sentía una leve, pero constante, presión sobre mí ya que con frecuencia me preguntaba: “¿y pibe cómo vamos?”, “¿cuánto falta?”, ” ¡ocho horas para esa boludez! ¿o sea que en todo el día de hoy sólo vas a hacer eso?”.

Aparte de todo eso me sabía decir: “¡Por Dios, probá el codigo antes de subirlo a producción!”, y la más dura de todas: “me imagino que habrás hecho un backup… ”. Sí, yo era muy junior y un talibán de los scripts pero lo realmente importante, independientemente del resultado de los proyecto, era que él era el responsable de que el trabajo se llevara a cabo. Además, no sólo presionaba sino que también tiraba del equipo y en mi caso, me enseñaba. Este fue mi modelo de tracking hasta que tuve un jefe puramente administrativo. Entonces descubrí un mundo nuevo, un mundo de descontrol, un mundo donde el gerente estaba indefenso ante las mentiras de los desarrolladores y de los testers.

Scott Adams vio esto antes que yo y creó a Wally y su Wally Report con las mentiras de las que hablo y he sido testigo.

Lucas Ontivero

Sin categoría

10 thoughts on “[MISC] Desarrolladores y testers despreciables

  1. Muy bueno!! … entonces aquí asalta la gran duda:
    ¿¿Puede una persona no técnica ser un buen gestor de proyectos??

    – Entonces la respuesta podría ser: Depende del compromiso y honestidad del equipo de trabajo.

    ¿?

  2. Miguel. La respuesta es no. Si el equipo es honesto y comprometidto, y técnicamente bueno, añadiría yo, el proyecto irá bien, pero no tendrá nada que ver con el jefe de proyecto (aunque este intentará llevarse el mérito).
    Es más, un gestor de proyecto que no se un buen técnico, y que además, no dea la liberta necesaría al equipo, echará por tierra los esfuerzos de su equipo por muy bueno que sea este.

  3. No estoy de acuerdo Miguel, hay gestores que saben perfectamente como ejercer la presión suficiente, aunque sí que es mejor que hayan tenido un pasado técnico. Pero un perfil sólo técnico puede no tener esas capacidades de liderazgo… al final depende mucho de la persona.

  4. jajaja que recuerdos, tuve, creo, todos los jefes posibles, siempre aprendí de todos, de unos lo que se debe y de otros lo que no se debe hacer, sin embargo considero es un problema de gerencia y de compromiso con el equipo. Me explico, uno de mis jefes no tenía el conocimiento técnico de un desarrollador o administrador de IT ¿Entonces qué hacía dirigiendo un proyecto de desarrollo de software? Sencillo, era el encargado de motivar al equipo y generar la confianza en el mismo para decirle de manera clara qué y cómo se iban a desarrollar cada uno de los módulos. Adicionalmente el conocimiento de tu equipo de trabajo te permite saber cuándo te están mintiendo o si tienen algún problema o necesidad y así poderla satisfacer.

    Creo que el problema de los “jefes” es precisamente ese, son jefes y no gerentes, saben mandar pero no administrar de manera correcta los recursos de su equipo. Como dice Jesús depende mucho de la persona y de sus cualidades y herramientas adquiridas para saber cómo adecuar a un ritmo y balance de trabajo acorde para todos.

  5. Hola,

    ¿¿Puede una persona no técnica ser un buen gestor de proyectos??

    Estoy con Amoedo.

    De todas formas las clave como siempre está en el equilibrio. Un bues gestor debe tener buenas habilidades ténicas y de liderazgo.
    Por supuesto si lo tiene todo (super-hombre, te habla 20 idiomas y conoce todas las tecnologías existentes a la perfección) pues mejor, pero seguramente, si existe, no esté trabajando en tu proyecto (en la NSA?).

    Si tiene mucho liderazgo pero no tiene ni idea de que va el proyecto técnicamente tendrá que confiar forzosamente en alguien del equipo con esas habilidades (al final siempre tienes que confiar).

    Y si no tiene mucho liderazgo, pero si buenos conocimientos técnicos, que se lea un par de libros y utilice el sentido común, que es algo facil de conseguir (a cierto nivel básico).

    Saludos,
    Fran

  6. Siempre he tenido el concepto de que para ser un buen Ingeniero en Construccion haz debido saber ser albañil, al menos de un grado a otro. Pues me parece que en Proyectos de TI, y mas aun en Proyectos de Desarrollo de Software, no se necesita solamente el criterio y el temple para gestionar al Grupo Humano, sino tambien de saber tecnicamente que se esta haciendo, entender porque se tuvo alguna decision en cuanto al desarrollo y saber “vender” a los patrocinadores que esa fue la mejor opcion y que el producto es el indicado para la necesidad.
    Haciendo una variante a la experiencia de Lucas:

    He trabajado con 2 jefes de proyectos de conocimiento tecnico muy apreciable, pero que no gestionan al grupo humano, esto incluso casi genera conflictos porque conocia mucho de las herramientas pero tenia un caracter dificl, tenias que ver que dia de semana era para ver si ibas a hacerle alguna consulta.
    Del otro lado tuve algun jefe de proyectos con una cualidad humana que hacian que el grupo vaya super bien, pero no sabian una line a de código, que preguntaban si programaria en “c# o en .net” (osea no tenian ni idea de .Net), esto ultimo causaba que le dieran unas fechas no tan acertadas, o que lo que sugerian no era lo que realmente se necesitaba, sino por puro capricho del desarrollador, y efectivamente presionada y gestionaba pero sobre un tiempo no an real, o sobre un producto diseñado de forma “extraña”

    Finalmente, desde mi concepto, que la idea es que para gestionar Proyectos de Desarrollo de Software, se deberia conocer, al menos algo, el tema tecnico. Pero tambien tener la capacidad de Gestionar bajo alguna metodologia. No soy muy partidario de que el Jefe de proyectos sea netamente de gestion, sino una mixtura, alguien con algun pasado tecnico, no extenso pero lo basico indispensable y que el don la “Gestion”.

    Saludos

  7. MMmm…

    @Fran>si tiene mucho liderazgo pero no tiene ni idea de que va el proyecto técnicamente tendrá que confiar forzosamente en alguien del equipo

    No veo donde está el problema… Asociamos que el director de proyecto debe ser quien lidere éste técnicamente, y no veo porque debe ser así. Que debe haber alguien que lidere el proyecto técnicamente es impepinable, pero que éste deba ser el director de proyecto…
    … Para mi no es imprescindible que el director de proyecto sea buen técnico. Lo que debe ser es buen gestor. Y esto implica confiar en el equipo y sobretodo saber negociar la presión que haya sobre el equipo (sea interna o externa).

    @Miguel >Del otro lado tuve algun jefe de proyectos con una cualidad humana que hacian que el grupo vaya super bien, pero no sabian una line a de código, que preguntaban si programaria en “c# o en .net” (osea no tenian ni idea de .Net), esto ultimo causaba que le dieran unas fechas no tan acertadas

    Lo mismo: se está asumiendo que el director de proyecto DECIDE el las fechas y la planificación… pero eso no es obligatorio que sea así. El director del proyecto puede ASUMIR una planificación hecha por el equipo (o por el resonsable técnico del proyecto), porque CONFIA en el equipo y puede defender esta planificación ante el cliente.

    Otra cosa es que haya mucha gente a la que le guste el ordeno y mando… 🙂

    saludos!

  8. Existe un gran problema en la comunicación cuando las personas no tienen experiencias compartidas. Es por eso que no me es facil expresar las grandes diferencia que he observado entre equipos dirigidas por un abogado, por un antropólogo y por un ingeniero de software. Sencillamente no es lo mismo. Crease o no.

Deja un comentario

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