martes, 10 de mayo de 2011

Mis quejas acerca de la Industria de Desarrollo

Acabo de leer una entrada de un blog que me pareció sumamente interesante titulado "Lecciones aprendidas acerca de la Industria de Desarrollo de México" (http://hackerdou.com/?p=553 )

Estoy muy de acuerdo en la mayor parte de los puntos que expone, y en donde tal vez tenga diferencias serán meras cuestiones de percepción o leves matices que no afectan el objetivo principal de su escrito. Por mi parte me gustaría enriquecer esos pensamientos con otras percepciones y lecciones que he aprendido en mis ya varios años de trabajar en esta fascinante, divertida pero también odiosa industria.

Afortunadamente me ha tocado trabajar para muy diversas empresas, desde el sector público, con sus tempestades de programadores, consultores y demás fauna de este ramo, del sector bursátil, donde también hay escuadrones enteros de personal de sistemas, hasta pequeñas empresas donde su "área de sistemas" consiste en un chico que apenas terminó la secundaria y que solo se encarga de conectar las PC's que compran, así que espero que mis lecciones y experiencias ayuden sobretodo a los futuros miembros de esta comunidad a darse una idea de lo que se enfrentan.

Somos un área de tecnología pero nos encanta el papel y la burocracia

Antes de empezar mi lluvia de flamas, debo aclarar que no tengo nada en contra de los procesos, ni del control, así como tampoco reniego el orden, a final de cuentas ese es uno de los tantos objetivos de mi trabajo, traer un poco de orden y control al caos, pero también es un hecho que diversas personas en su afán de llevar un mejor control, exageran en sus propuestas, o de plano se van por caminos equivocados.

Este síntoma se percibe perfectamente en aquellas personas involucradas en la definición de políticas y procedimientos dentro del área de sistemas. Reconozco que en la mayoría de los casos tienen propuestas bastante acertadas en el aspecto de llevar el seguimiento a los procesos de desarrollo y calidad de los productos de software, pero lo que no entiendo es ¿porqué insisten en llevar dichos controles en Word y Excel? incluso me lloran los ojos cuando dichos documentos tienen su control de cambios a manera de tablita en la primer hoja del documento.

Si eres parte de un área de tecnología ¿porqué no aplicar la tecnología para el control de tu propia área? Aunque sea utilizar el control de cambios que ofrece Office (que honestamente dista mucho de ser lo ideal). También es típico que para la documentación de análisis y diseño mucha gente usa la que bajó del correo, sin cerciorarse si es la versión mas actual del documento, o duplicando la información a través de muchos documentos con diferente objetivo, ¿qué resultado tiene? inconsistencias, cada quien maneja su versión, además de que llenas tu PC de cuanta cantidad de archivos, que, seamos honestos, nunca vas a leer con detenimiento, o que te va a complicar la existencia la búsqueda de información, sobretodo si no cuentas con un repositorio de documentos centralizado, y tienes que navegar en toneladas de correos o carpetas para encontrar el documento que necesitas

Y no es necesario invertir una cantidad descomunal de dinero, con un cliente implementamos MediaWiki como una solución para centralizar la información relativa a los proyectos de Software, con los plugins adecuados, tienes control de versiones, acceso por roles, exportación a PDF y hasta embellecedores de sintaxis y generadores de UML sin mayor esfuerzo.

Ahorrar cueste lo que cueste

Hay empresas (y empresarios), que invierten buena lana en tecnología, compran licencias de Oracle (que cuestan algunos miles de dólares), pagan a mandos medios y altos con salarios bastante elevados, tienen unos servidores de ensueño, pero llegas a ver como trabajan los que realmente generan el producto, y también te dan ganas de llorar.

Me ha tocado ver muchos lugares donde a los programadores, líderes técnicos y demás personas que producen el verdadero objetivo del área de tecnología (lo siento, a mi juicio ni los Power points, ni los Gantt bonitos, ni los documentos de arquitectura, ni los diagramas UML los considero fundamentales, son necesarios si, pero no constituyen la finalidad de un área de sistemas) trabajan bajo condiciones precarias, en mesas de trabajo o escritorios con una pésima ergonomía, en sillas que más bien son ideales para estar tomando el sol en un jardín, no para estar sentado de 8 a 12 horas diarias en una misma posición, y lo peor del caso, con los equipos más viejos de toda la organización, siendo que por definición son las personas que más necesitan del poder de cómputo, o ¿a póco el gerente realmente necesita la computadora más poderosa y con la licencia más actual de Office?

Existen excelentes estrategias fiscales para aprovechar al máximo la deducibilidad y la depreciación de los equipos de cómputo, así como está demostrado que en un ambiente propicio, una persona dedicada a actividades intelectuales rinde mucho más que cuando lo tienes bajo el látigo. Pero como indica este subtítulo, a veces la consigna es ahorrar cueste lo que cueste, más vale asegurarse unos centavos extras, aunque pierdas pesos en cuestiones de productividad.

La importancia de las horas nalga

Cuantas veces no hemos visto en muchos lugares, que la persona más respetada es la que permanece más tiempo en el lugar de trabajo y es considerada la más trabajadora, al grado que hay lugares donde contratan recursos "por kilo con taxímetro", donde pagan por la hora de "trabajo" del recurso, no importando la efectividad o el rendimiento del mismo.

Reconozco que es una cuestión muy delicada, ya que definitivamente medir la productividad de una persona puede ser algo extremadamente subjetivo, y aunque a veces he querido determinar matemáticamente alguna fórmula que relacione los conceptos de "remuneración económica", "experiencia" y "trabajo efectivamente realizado", no he encontrado una manera práctica de llevarla a cabo, aunque definitivamente sé que puede haber soluciones que ayuden a mitigar este problema, sin tener que recurrir a llenar timesheets en excel (que más que controlar, siento que afecta más la productividad, además de obligarte a encontrar justificaciones al tiempo invertido), he visto herramientas como Tasktop, donde calcula automáticamente un timesheet de acuerdo al código que modificas dentro de Eclipse, por ejemplo.

Administración de proyectos orientada a los caprichos del cliente

La administración de proyectos es una técnica complicadísima y definitivamente tiene un poco de arte por detrás también, pero también es un hecho que si no eres cuidadoso y como administrador de proyecto no involucras a todas las partes críticas, o simplemente demeritas la opinión de la gente que realmente realiza el trabajo rudo, estás condenando el proyecto a un fracaso rotundo.

Nunca voy a olvidar una experiencia curiosa que me ocurrió en mi primer trabajo, era de tiempo parcial ya que estaba en cuarto o quinto semestre de la carrera, me encontraba a punto de comenzar un cierto proyecto, en donde mi jefe de aquel entonces me pregunta "Necesitamos realizar X, Y y Z requerimientos, ¿como ves? ¿en cuanto tiempo te lo avientas?", como es mi insana costumbre, comencé a realizar algunas anotaciones en papel, echar algunos trazos, dibujar algunas tablas, ideas conectadas por flechas, etc, y le respondí de una manera casi certera "yo considero que en mes y medio aproximadamente podemos tenerlo listo". En seguida, mi jefe se me queda viendo con cara molesta y me responde "pero yo ya me comprometí con el cliente a que queda en quince días", acto seguido podrán imaginar la serie de malos pensamientos y maldiciones que pasaron por mi cabeza.

Concuerdo perfectamente que hay que negociar y en la medida de lo posible satisfacer las necesidades del cliente, finalmente es el que paga y nos da de comer, pero por otro lado, como empresa que brinda soluciones, tenemos que aterrizar al cliente en el terreno de lo que es factible y orientarlo en la mejor solución en cuanto a tiempos y alcances, quemar a tus empleados solo por "ganar" un proyecto solo te conducirá a semanas de retrasos, desveladas y horrores. Nunca menosprecies la opinión de un programador, por mas junior que sea, finalmente, él será el que saque adelante tu proyecto, no importando lo que diga tu perfectísimo y calibradísimo diagrama de Gantt

Juntitis!

Si, a veces me pregunto si el objetivo de los gerentes, administradores de proyecto o similares, es el perder el tiempo en juntas, de igual manera, no satanizo el aspecto de que las juntas sean malas, ni tampoco la cantidad de estas, siempre y cuando tengan un significado tangible, y se planteen metas y compromisos, pero cuantas veces no se han realizado juntas donde tres cuartas partes del tiempo se pierde en justificaciones vanas o en aventar lodo,y la otra cuarta parte en ponerse de acuerdo en lo que verán en la siguiente junta.

Tampoco voy a olvidar otro proyecto, en el que tuvimos una junta con el administrador del proyecto quería a fuerzas recortar los tiempos del proyecto, claro, todo esto a solicitud del cliente (ver punto anterior). Así que nos dedicamos a revisar actividad por actividad, diagramando y explicando el detalle de cada una de éstas, ya que el administrador no tenía mucha experiencia en cuestión de sistemas (pero tenía mil certificaciones de PMP y sus derivados). La junta duró 8 horas, y al final del día, pudimos llegar al acuerdo de recortar algunas actividades, lo cual significó disminuir cuatro horas la longitud del proyecto. Aunque creo que no sirvió de mucho, ya que tuvimos un retraso de ocho horas, al invertirlas en la junta, en lugar de las actividades que ya estaban programadas para ese día.

Ya para rematar, creo que este post me sirvió muy bien para echar un poco de catarsis =P, no quiero decir que todo es malo en este ramo, si fuera así no estaría en él, pero creo que hay muchos puntos de mejora, en una entrada posterior seguramente la llenaré con propuestas y experiencias positivas.

1 comentarios:

Tania dijo...

Interesante tu enfoque, yo soy LAE y te doy la razón, las mas de las veces se termina invirtiendo el doble de tiempo en proyectos, a mi en su momento me pasó estar con el equipo de IT corrigiendo defectos y dando mantenimiento como líder usuario por que a mi colega anterior decidió "prometer concluir en un tiempo irreal el proyecto"..En fin... y compréndanos un poquito no somos ustedes ..alguien tiene que tener la visión de negocio, alguien la de los procesos, alguien la mercadotecnia, lo importante es hacer sinergia... Saludos.

Publicar un comentario