Tipos de programadores.

Es genial la última de Sinergia sin Control. Si algún despistado no se ha suscrito a su feed, que lo haga ya mismo.

De desarrollador a líder de proyecto: desafíos de la gestión para el técnico recién ascendido.

¿Se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos? ¿Son imprescindibles para la gestión, o sólo una ayuda? ¿Los mejores líderes son aquellos que ocuparon puestos técnicos en el pasado? ¿O los mejores son aquellos que han estudiado y ganado experiencia específicamente en la gestión, tal vez en varios rubros? ¿La gestión tiene nada, poco o mucho que ver con lo técnico?

Comencemos por dividir (arbitrariamente, claro está) a los líderes de proyecto en dos grandes grupos: los que llegan al puesto habiendo comenzando su carrera desde el lado técnico y aquellos que llegan comenzando desde del lado de la gestión de proyectos.

Los primeros (digamos "los gestores-técnicos") serían aquellos que comienzan como programadores y progresan naturalmente hacia líderes o referentes de su equipo.

Con el tiempo las funcionalidades bajo su responsabilidad son cada vez más amplias, el equipo cada vez más grande y eventualmente abandonan del todo la programación para dedicarse exclusivamente a la gestión de uno o varios proyectos.

Bajo su responsabilidad pueden caer ya no sólo programadores sino también analistas funcionales, testers, diseñadores, administradores de sistema, de base de datos, personal de mantenimiento, soporte al cliente, etc.

Los segundos (digamos "los gestores de carrera") serían los estudiantes de carreras como Administración o Gestión de Empresas, que comienzan ayudando en la gestión de proyectos (de cualquier tipo) y van progresando hasta alcanzar el liderazgo de uno.

Así que a la pregunta "¿se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos?" yo respondo "sí, absolutamente".

Por supuesto que el gestor de carrera deberá tomar experiencia en el rubro, que como cualquier otro tiene sus particularidades, su jerga, sus recovecos. Dispone para ello de un marco teórico: sabe de métodos de estimación de tiempos, de seguimiento, de ajuste, de administración de recursos, de manejo de personas, de motivación, etc.

Tendrá que aprender cuáles son las diferentes etapas del desarrollo, las muchas posibilidades que existen para recorrerlas, sus ventajas y desventajas, cuáles son los requerimientos, los productos, los tiempos y el personal necesario para cada una de ellas.

Para el gestor técnico el salto es inverso y simétrico: conoce el rubro pero deberá aprender a tratar con personas, a motivar, a liderar, a coordinar más allá de lo técnico, a evaluar y negociar cuestiones económicas, políticas, emocionales.

Desde un lado o de otro se puede llegar a cualquier nivel de excelencia o chapucería.

Pero hay un tema. El conocimiento técnico ayuda, por supuesto, sólo si no se hace abuso de él. Obviamente, el único que puede presentar estas tendencias hacia el abuso del conocimiento técnico es aquel líder con un pasado como desarrollador, ya que tiene que ver justamente con ese origen.

¿A qué me refiero cuando digo tendencias hacia el abuso del conocimiento técnico? Es más fácil dar ejemplos que tratar de definirlo, así que invento algunos:

• Imponer estimaciones de acuerdo a su conocimiento técnico. Pero ya no es él quien ejecuta las tareas (eso era antes), y puede que no acepte que los tiempos de su equipo ya no son necesariamente los que él hubiese presentado.

  Por otro lado, un gestor de carrera confía necesariamente en las estimaciones de su equipo, simplemente porque como él no puede evaluarlas técnicamente no puede discutirlas. Podrá negociarlas, requerir más esfuerzo o más recursos, pero jamás objetarlas en términos de "esto está bien o mal".

  Claro que el gestor de carrera puede imponer estimaciones. Como dije antes, a la chapucería se llega desde cualquier lado.

• Reservarse la resolución de cuestiones técnicas y no transmitir requerimientos funcionales. Es un poco lo que comentaba en Requerimientos: cuando no son asteroides sino sólo polvo cósmico.

  Si el líder no controla su "corazoncito técnico", puede tender a resolver requerimientos y distribuir sólo directivas técnicas ("armar una base de datos así y asá") en vez de directivas funcionales ("hay que hacer un módulo de ventas").

  Pueden seguir la entrada referenciada para ver los problemas que (en mi opinión) ello ocasiona. Por otro lado, el gestor de carrera transmite sólo requerimientos funcionales ya que no conoce de soluciones técnicas.

• Evaluar técnicamente al equipo de acuerdo a parámetros propios. Estos parámetros pueden estar obsoletos o no ser objetivos.

  Es el caso del líder de proyecto "del ciclo de vida" que evalúa "cantidad de líneas de código escritas".

  El gestor de carrera no cuenta con criterios propios para evaluar técnicamente al equipo por lo que deberá buscar parámetros objetivos: una opinión externa, una auditoría de código o similar.

  Buen momento para recalcar nuevamente lo de la chapucería: el gestor de carrera también puede confiar ciegamente en las capacidades técnicas de su equipo, o no preocuparse por ellas y evaluar sólo los resultados... hasta que todo colapsa como una cáscara vacía.

• Desestimar nuevas herramientas, nuevos lenguajes, nuevas tecnologías. Tal vez por rechazo a perder del todo el control: si se adoptan nuevas tecnologías su conocimiento previo ya no se aplicaría al proyecto, por lo que perderá cierto grado de poder de decisión.

  Un gestor de carrera no tiene pretensiones de control técnico del proyecto. Sólo le interesará el rumbo funcional o de negocio, que es lo que cae bajo su responsabilidad.

• Desestimar herramientas metodológicas o mejores prácticas de la gestión de proyectos, por considerarlas demasiado formales o informales, demasiado simples o complicadas, o simplemente inútiles.

  Una suerte de desprecio por la teoría del campo de la gestión de proyectos (que no es el propio), sobrevalorando las cuestiones técnicas frente a las administrativas.

  Al revés también se da: muchos gestores de carrera desprecian las tareas de codificación. Pero lejos de dañar al proyecto esto lo beneficia: cada uno a su trabajo.

Verán que todos los puntos tienen una raíz en común. En el fondo está mi propia visión del líder de proyecto: un profesional entre profesionales, un profesional de la gestión.

Una cuestión cultural, una estructura (tal vez en decadencia pero de todas maneras) muy extendida, ubica al líder de proyecto "por encima" de otros profesionales: programadores, técnicos en hardware, administradores de base de datos, etc.

Eso hace que a veces se olvide que el trabajo del líder es obtener y administrar a las personas y a los recursos, coordinar el trabajo en equipo y llevar las riendas de las negociaciones y gestiones necesarias entre el equipo y el exterior... (entre otros, claro).

El tema es, ningún profesional debería decidir en el campo del otro. Pensemos en estas situaciones: programadores decidiendo funcionalidades, líderes de proyecto imponiendo fechas en las que "tiene que estar todo", clientes requiriendo (caprichosamente) determinada tecnología, programadores haciendo testing, analistas funcionales diseñando reportes en SQL.

Son todas situaciones en las que un actor de esta comedia a la que llamamos "desarrollo" invade el terreno del otro. Es allí donde se originan los problemas.

Recordemos que el tema de este post fue: las tendencias, los sesgos que debe afrontar un técnico que deviene en líder de proyecto. No creo que ningún pasado X impida ser buen líder o que el mejor líder es aquel que estudió la teoría en una facultad. Otra vez: ambos caminos pueden conducir tanto a la chapucería como a la excelencia.

Patos criollos: 20 desastres relacionados con el software.

En cuatro post de VariableNotFound... ¡y con más referencias al final!

Ideales para esgrimir como excusa cuando metemos la pata: "Mire, si le puede pasar a la NASA..."

• Primera parte.

• Segunda parte.

• Tercera parte.

• Cuarta parte.

Ah, por las dudas que algún despistado no entienda. Pato criollo = "cada paso una cag...".

Juegos de viernes: Jelly Towers.

"¡Hoy es viernes! ¿Dónde estuvo mi juego? Eran las tres de la tarde y yo trabajando."

Qué costumbrista que es la gente... perdón, la verdad que lo tenía agendado y me olvidé de postearlo.

Tarde pero seguro, acá les dejo Jelly Towers, que tiene un objetivo bastante original: tenemos que alimentar a... no sé, unos gusanos, con gelatina.

Se complica que da calambre.

Frases: reciprocidad.

"No te trataré como una prioridad cuando me tratas como a una opción"

Visto en El pito doble por Cerebrado.

Guía para perplejos: primera vista al código en un nuevo trabajo y... ¡ups!

La anécdota es común, casi una leyenda urbana... cosas que a nadie le pasó pero a todo el mundo le contaron, y reza casi siempre en variaciones del siguiente tema:

"Durante las entrevistas de trabajo todo me pareció perfecto... se habló de implementar las últimas tecnologías y mejores prácticas, de innovación, de una rueda interminable de nuevos y desafiantes productos a implementar.

La gente con la que hablé me pareció de mucha experiencia en el rubro, sin miedo a admitir errores y con ganas de corregirlos a futuro, así que no dudé en cambiar de trabajo.

Ya en el primer día de trabajo, al bajar a detalle, a ver el código... ¡Horror..."

Luego viene una gran lista de WTF's vinculados al desarrollo de software (pueden buscar ejemplos divertidos en The Daily WTF): que tal cosa estaba horriblemente mal, que tal otra era directamente un delirio, que esto no se usa así y que lo otro no se usa asá, o que el jefe esto y el jefe lo otro... La historia en general finaliza con el protagonista huyendo despavorido sin mirar atrás.

Sin exagerar, creo que todos los que entran a un nuevo ambiente de trabajo o a un nuevo proyecto se encuentran con alguna que otra cuestión extraña, no del todo clara, o directamente... digamos... que está mal. Esto es normal, todo equipo tiene sus vicios o errores.

La situación puede ubicarse en una escala que va desde lo divertido a graves errores (siempre desde el punto de vista del ingresante) no ya puntuales, sino de concepto, tanto en el código como en el proceso, pasando por cuestiones que pueden llamarse "de criterio" donde se acepta una visión diferente a la propia sin estar de acuerdo, pero reconociendo sus razones.

La pregunta que propongo es ¿cómo actuar en un caso extremo? Lo que sigue a continuación es lo que yo hice (no "hice correctamente" sino simplemente "hice") e intentaría hacer, aclarando desde el vamos que nunca me vi en una situación así, extrema, donde "está todo mal" y "esta gente no sabe lo que hace y no entiende de razones".

Creo que lo primero y principal es ubicarse y bajarse del caballo, sobre todo si nos integramos a un desarrollo que ya está funcionando.

Es decir, desacelerar, bajar un cambio, no hacer declaraciones rimbombantes, explosivas ni mucho menos agudas o que puedan resultar hirientes para el autor o responsable de lo que se objeta. Creo que podría ser más absoluto: en principio, lo mejor es no decir ni dar a entender absolutamente nada.

¿Por qué? Vamos, reconozcamos que sería poco profesional de nuestra parte entrar a un equipo y declarar, luego de dos o tres días de trabajo "esto está todo mal". ¿Qué análisis pudimos realizar en ese tiempo? ¿Qué tanto pudimos saber en un par de días de las personas que lo hicieron, de cuándo fue y en qué circunstancias?

Así que el segundo paso es, simplemente, recabar información, conocer a las personas que nos rodean y entender cómo llegaron a eso. Todo, absolutamente todo en un desarrollo tiene su razón de ser. Obviamente los orígenes pueden no ser técnicos, pueden ser... digamos "históricos": tienen que ver con una historia que no conocemos y en la cual todavía no escribimos ni una coma.

Esta actitud pone a prueba el respeto al trabajo ajeno: podemos criticar, pero es una falta de respeto hacerlo sin conocer no sólo el problema (que puede que sólo nosotros estemos viendo) sino aunque sea un poco de su historia.

Después de un tiempo (que dependerá también de las urgencias del caso) sin que nos hayan preguntado explícitamente, se puede tantear a ver si una recomendación encuentra algún oído atento. Más que decir "esto está mal", es mejor enfocar las cosas por el lado de "se me ocurrió que podríamos cambiar esto y..."

Pueden pasar dos cosas: que seamos escuchados o que no. En el primer caso es un buen comienzo, independientemente de si "nos hacen caso" o no. Es decir, si alguien escucha y defiende "ese delirio", está bien. Es lo lógico. De a poco, cada vez con más confianza, se puede debatir o incluso pelear. Pero hay que tener en claro que para pelear hay que ganar cierta confianza.

Digresión (está bien escrito, ver RAE): en general no me peleo "mal" con mis compañeros de equipo, pero a veces pasa. Y pasa porque hay cierta confianza que permite pelearse de vez en cuando sin que eso sea catastrófico. Hasta diría que un equipo en el que no hay peleas es algo sospechoso. Si uno tiene una idea, la defiende. Y hay veces en que a uno o a otro se le suelta un tornillo o lo toma a personal (o era personal)... la vida sigue.

Está el tema del tiro por elevación: ¿qué pasa si sentimos que el problema está en una persona en particular? Puede ser un compañero, un líder de proyecto, un analista, un gestor, lo que sea. ¿Hablamos con su superior? Puede ser, nunca sin haber intentado por todos los medios debatir con él primero, y teniendo en cuenta que puede "salir mal", por lo que se vuelve más importante que nunca tener un planteo coherente, no agresivo, y una propuesta de solución.

Ahora, ¿qué pasa si realmente no vemos posibilidades de cambiar las cosas, o sentimos que no queremos hacer semejante esfuerzo? Bueno, nada. Alejarse. Buscar otro trabajo, cumpliendo lo mejor posible con la tarea que se nos asigna mientras tanto. Sin escándalos, y sobre todo, sin "tirar basura" a los que quedan para irse con un portazo, eso sólo habla mal de uno mismo.

Aclaro otra vez: que no conozco la verdad revelada, y que lo que creo o recomiendo surge más de mis errores que de mis aciertos. En el papel (o la pantalla) es todo muy fácil, pero la vida real es otra cosa. Supongo que lo único que se puede hacer en este tipo de situaciones muy complicadas es hacer el mayor esfuerzo posible.

De la falta de visión del desarrollo profesional en las pymes.

Siempre trabajé en pequeñas y medianas empresas o emprendimientos de uno o dos socios. Aunque conozco de oídas la experiencia de la "gran consultora o empresa" por compañeros de facultad, trabajo y amigos, no es la mía. Tengo que aclararlo porque mis impresiones deben estar necesariamente sesgadas por esto.

Aclarado el punto, entramos en tema.

Es difícil que exista un Plan de Carrera institucionalizdo en una pyme. Es común que para programadores, analistas o integrantes de la rama de gestión el desarrollo profesional debe transitar otros caminos, más personales.

Esto implica estudios universitarios o cursos y certificaciones a los que la empresa puede aportar, por ejemplo brindando días para estudio o financieramente, pero la tracción tendrá que estar en cada uno. Quiero decir que no habrán ofertas institucionales, más bien hay que pedir, suplicar o exigir de acuerdo al caso. Y algunas veces la empresa entorpece más que ayuda al avance profesional.

Por otro lado, el desarrollo de software es un rubro que por su dinámica depende mucho del aprendizaje. Cuando no se aprende, cuando no se mejora o no se está al corriente de las tendencias y tecnologías, el estancamiento lleva al fracaso.

Esto es así en cualquier industria, por supuesto. Pero los cambios tecnológicos impactan más rápidamente en el desarrollo de software, por lo que el aprendizaje debe ser continuo. Actualmente es imposible decir que un producto, por más completo (funcionalmente) que esté, está "cerrado". La tecnología avanza a paso acelerado, los clientes y usuarios demandan funcionalidades impensadas hace apenas un par de años, y la competencia es feroz.

Así que las pymes tienen el difícil compromiso de crecer junto a los profesionales que la integran. Es esto o la rotación constante, o el estancamiento. En mi experiencia, la norma ha sido la rotación o el estancamiento.

Por rotación se entiende que alcanzado un punto, se percibe que:

• No hay espacio para crecer: la estructura institucional es pequeña y los puestos escasos.

• No hay recursos: el día a día no da tregua y no hay presupuesto para más personal que alivie la carga de trabajo dando espacio a la investigación y experimentación.

  Los profesionales son constantemente tentados con ofertas de otros proyectos y la empresa no puede retenerlos.

• No hay una visión que dé importancia al aprendizaje y la innovación: en realidad, éste punto está en el origen de los otros dos, porque cuando existe una clara visión de aprender e innovar se buscan los medios, y usualmente aparecen.

  Pero de todas maneras, con o sin visión institucional, los profesionales del área crecen. Y cuando no hay una visión se encontrarán con que han crecido más que la empresa, o que para crecer tienen que buscar otros destinos.

Aunque parezca contradictorio, creo que en una pyme la rotación ayuda. Evita el estancamiento. Obliga a la empresa a depender un poco menos de las personas y apoyarse un poco más en los procesos... o morir. Es bueno apoyarse en las personas, pero me parece que la norma en una pyme es el completo desbalance en este sentido. Es la clásica imagen del trabajo descordinado, desordenado e ineficiente (aunque muchas veces creativo) de estas empresas.

La partida de un socio, gerente o trabajador estrella en una pyme es un momento de crisis. Habrá que ver si los procesos (los que existan) soportan la pérdida de conocimiento que ello implica y si se logran captar profesionales que logren cubrir el espacio y mejorar.

Es decir, si la empresa sobrevive a la rotación, se verá fortalecida. Habrá superado una etapa en la que muchas fracasan.

En todo caso, obliga a la empresa a hacer lo que por falta de visión no hace de manera ordenada: cambiar, mejorar, mantenerse al día con la tecnología.

Decía al principio, rotación (con aprendizaje o muerte) o estancamiento. El estancamiento se da cuando la falta de visión hace que los profesionales que crecen se alejen, quedando siempre los más conservadores y reacios a los cambios. Si la sangre nueva no logra cambiar las cosas la rotación continuará en un proceso de selección natural en el que queden sólo los más conservadores, fortaleciendo la tendencia. El mercado decidirá cuánto puede durar esta situación.

Imagino que por aquí está la clave del conflicto constante en las pymes. El desarrollo, el aprendizaje, no es parejo, no es ordenado, se da aleatoriamente. Programadores estancos en una tecnología determinada, un un líder de proyecto "del ciclo de vida", un gerente conservador, pueden asfixiar lenta y discretamente a una pyme. Cuanto más arriba más difícil el cambio, pero no importa dónde, el conflicto será permanente.