Desde un tiempo antes de comenzar a publicar esta página ayudo en un proyecto muy interesante: la traducción de los artículos de Joel Spolsky. Iniciativa comenzada por unos pocos mucho tiempo atrás cuya posta ahora tomó el mismo autor y ofreció un wiki para poder centralizar todo el trabajo.
En mi opinión, Joel es uno de los mejores escritores sobre desarrollo de software. Él escribió el 25 de Diciembre de 2001 un artículo sobre cómo lograr cambios en el lugar de trabajo cuando no se tiene la autoridad para hacerlo y aquí está mi versión traducida.
Notas de Traducción
- Esta es mi versión, existe otra versión del artículo en español en el wiki que fue traducida antes que esta pero que yo no vi :s
- A diferencia de todos los artículos anteriores, la mayoría de los vínculos de esta traducción apuntan a las versiones en español de otros artículos de Joel y no a las versiones originales
- El artículo original: Getting Things Done When You’re Only a Grunt
- El permiso de publicación de este artículo está en trámite por lo que puede ser removido en caso de no conseguirse
La traducción
Se supone que este sitio es sobre manejo de software. Por a veces no se tiene el poder de generar un cambio en la organización por orden ejecutiva. Obviamente, si sólo eres un peón programador en el fondo del tarro no puedes exactamente ordenarle a la gente que comience a crear agendas o bases de datos de errores. Y, de hecho, inclusive siendo un gerente probablemente hayas descubierto que ser jefe de un grupo de desarrolladores es como intentar meter un grupo de caballos al corral sólo que menos divertido. Sólo decir que se haga de una forma no lo hace de esa forma.
Puede ser frustante cuando se trabaja en una organización que no le vaya bien en el Test de Joel. Sin importar cuán bueno sea tu código, tus compañeros de trabajo escriben código tan malo que te da vergüenza que te vean cerca del proyecto. O la gerencia toma tan malas decisiones sobre qué código escribir que eres forzado a desperdiciar tu talento depurando la versión AS/400 para un juego de niños que simula un plan de jubilación.
Supongo que simplemente podrías irte. Pero, seguramente, existe alguna razón que te retiene allí. Las acciones aún no son accesible, no hay mejor lugar para trabajar en la ciudad más cercana o simplemente tu jefe secuestró a algún ser amado. En cualquier caso, enfrentar la vida con un mal equipo puede ser irritante. Pero existen estrategias para mejorar el equipo desde el fondo, y quisiera compartira algunas de ellas.
Estrategia 1: Simplemente hazlo.
Se puede hacer mucho para mejorar un proyecto simplemente con una persona haciéndolo. ¿Necesitan un servidor de compilación diaria? Configura tu propia máquina para que compile todas las noches y envíe los resultados por mail. ¿Toma demasiado tiempo compilar todo? Escribe un makefile. ¿Nadie corre los tests de usabilidad? Haz los tuyos propios en el pasillo con los cadetes, lápiz y papel o un prototipo en Visual Basic.
Estrategia 2: Utiliza el poder del mercadeo viral.
Mucha de las estrategias del Test de Joel pueden ser implementadas por una sola persona en un grupo que no coopera. Si se lo hace bien, un par de ellos lo esparcirán en el resto del grupo.
Por ejemplo, supongamos que no se puede convencer a nadie en el equipo para utilizar una base de datos de errores. No dejes que te moleste. Sólo mantiene la tuya propia. Ingresa en ella los errores que encuentres en tu propio código. Si encuentras un error que alguien más debería arreglar, asígnale el error a esa persona utilizado la base de datos. Si posees una buena aplicación de seguimiento de errores, le enviará un e-mail. Pero ahora, puede seguir enviándoles e-mails si no lo solucionan. Eventualmente, verán el valor de un sistema de contabilidad de errores y comenzarán a utilizar el sistema como se deseaba. Si el equipo de calidad se niega a agregar los errores en el sistema, simplemente niégate a aceptar reportes de errores por cualquier otro canal. Luego de la millonésima vez que le digas “me encantaría arreglar eso, pero mo voy a olvidar. ¿Por qué no lo agregas al sistema de errores?” comenzarán a utilizar la base de datos.
¿Nadie quiere utilizar control de fuentes? Crea tu propio repositorios CVS, en tu propio disco duro de ser necesario. Aún sin cooperación, puedes controlar tu código independientemente del de todo el resto. Cuando surja un problema que el control de fuentes pueda solucionar (alguien tipea accidentalmente rm * ~ en lugar de rm *~), llegarán corriendo a por auxilio. Eventualmente se darán cuenta que pueden tener acceso al repositorio ellos también.
Estrategia 3: Crea un rincón de exelencia.
¿Tu equipo no crea una agenda? ¿Ni especificaciones? Escribe las tuyas propias. Nadie se quejará si te tomas uno o dos días en escribir una especificación mínima y planeas el trabajo que están a punto de comenzar.
Consigue mejor gente para el equipo. Involúcrate con la contratación y las entrevistas y consigue los buenos candidatos para tu equipo.
Encuentra la gente que están dispuestos a mejorar y son capaces de hacerlo y alístalos de tu lado. Aún en equipos malos, seguramente encontrarás a gente inteligente que simplemente no tiene la experiencia necesaria para crear buen código. Ayúdalos. Prepáralos para que aprendan. Lee sus cambios. Si hacen algo estúpido no envíes un e-mail snob explicando qué es lo que hicieron mal. Eso sólo los enojará y los pondrá a la defensiva. En su lugar, inocentemente reporta el error que resulta del cambio propuesto. Déjalos que descubran qué es lo que lo causa. Cuando encuentren el error ellos mismos, recordarán mucho mejor la lección.
Estrategia 4: Neutraliza los zonzos.
Aún los mejores equipos pueden tener un zonzo o dos. La parte frustante de tener malos programadores en tu equipo es cuando su mal código rompe el buen código o cuando los buenos programadores tienen que desperdiciar tiempo limpiando los rastros de los malos programadores.
Como un peón, tu objetivo es minimizar el daño, es decir: contención. En algún punto, uno de estos genios tardará dos semanas escribiendo un par de líneas de código que son tan increíblemente malas que jamás funcionarán. Estás tentado de gastar los 15 minutos que tomará re-escribir todo correctamente desde la nada. Resiste la tentación. Tienes una perfecta oportunidad para neutralizar a este idiota por varios meses. Simplemente sigue reportando errores en el código. No tendrán más opción que arrastrarse por meses hasta que no puedas encontrar ningún otro error. Esos son meses en los que no podrán hacer daño en ningún otro lado.
Estrategia 5: Huye a las interrupciones.
Todos los ambientes felices de trabajo se parecen (oficinas privadas, condiciones relajadas de trabajo, herramientas excelentes, pocas interrupciones y aún menos reuniones). Todos los ambientes tristes de trabajo son tristes en su propia manera.
Las malas noticias son que cambiar un ambiente de trabajo es prácticamente imposible en casi cualquier compañía. Los alquileres a largo plazo pueden significar que aún el presidente de la compañía no pueda hacer algo al respecto. Esto es por lo que tan pocos desarrolladores consiguen una oficina privada. Esto hiere a las compañías en, al menos, dos formas. Primero, dificulta aún más el contratar desarrolladores en la cresta de la ola que preferirán la compañía que les de las condiciones más cómodas (a igualdad del resto de las condiciones). Segundo, el nivel de interrupciones puede reducir dramáticamente la productividad de los desarrolladores que encuentran imposible concentrarse y mantenerse concentrados por un tiempo (por más corto que éste sea).
Consigue una forma de salirte de ese ambiente. Toma una laptop al bar de la compañía donde hay muchas mesas disponibles la mayor parte del día (y nadie te puede encontrar). Reserva una sala de reuniones para el día completo y escribe código allí dejando en claro, mediante la cantidad de cambios, cuánto más trabajo puedes lograr cuando tienes un cuarto para tí solo. La próxima vez que haya que apurar el paso y tu jefe pregunte qué es lo que necesitas para tener esto listo para mañana, ya sabrás qué decir. Te encontrarán una oficina para el día. Y al poco tiempo se preguntarán qué podrían hacer para mantener esa productividad durante todo el año.
Llega tarde a trabajar pero también vete tarde. Esas horas después de que el resto de la compañía se fue a su casa pueden ser las más productivas. O, si tu equipo siempre llegará tarde, llega temprano. Conseguirás terminan más trabajo en esas dos horas antes que el resto llegue y comience a molestar que lo que podrás hacer en lo que resta del día.
No mantengas tu cliente de correo y/o mensajería instantánea abierto. Chequea tus e-mails una vez por hora si lo necesitas, pero no lo dejes corriendo.
Estrategia 6: Tórnate invaluable.
Ninguna de estas estrategias funcionará si no eres, realmente, un excelente contribuyente. Si no escribes buen código, y mucho de eso, simplemente conseguirás una reprimenda por perder el tiempo con bases de datos de errores cuando “deberías de haber” estado escribiendo código. No hay nada más fatal para tu carrera que tener una reputación de estar tan concentrado en el camino que nunca llegar a la meta.
Una vez, cuando comencé un nuevo trabajo como peón de programación en una nueva compañía descubrí que la compañía estaba trabajando en un nivel 2 del Test de Joel, y estaba obsesionado con arreglar eso. Pero también sabía que conseguir una buena primera impresión era crucial. Por lo que dediqué las primeras siete horas de todos los días sólo a escribir código, tal como se esperaba de mí. No hay nada como una montaña de cambios que te hagan ver bien para con el resto del equipo de desarrollo. Pero también reservaba una hora todas las tardes antes de volver a casa para mejorar el proceso. Utilizaba esa hora para corregir lo que complicaba la depuración del producto. Monté una base de datos de errores y una compilación diaria. Corregí todas las molestias de siempre que hacían difícil el desarrollo . Escribí especificaciones para el trabajo que hacía durante el día. Escribía documentos explicando paso por paso cómo crear una máquina de desarrollo desde la nada. Documenté detalladamente cualquier lenguaje interno importante que no había sido documentado. Lentamente, el proceso se hizo cada vez mejor. Nadie salvo yo (y mi equipo cuando me pusieron a cargo del mismo) tenía agendas o especificaciones, pero salvo por eso teníamos 10 en el Test de Joel.
Puedes hacer las cosas mejor, aún cuando no se está a cargo, pero tienes que ser como la esposa del muerto: más allá de las sospechas. De otra forma harás muchos enemigos en el camino.
¿Alguna otra idea?