Logrando resultados cuando se es un peón

From The Joel on Software Translation Project

Revision as of 08:29, 20 July 2006 by 62.37.207.160 (Talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Por Joel Spolsky
Martes 25 de Diciembre de 2001
Artículo original: Getting Things Done When You're Only a Grunt
Traducido por: Leonardo Herrera
Editado por: Luis Lara


Este sitio se supone que trata acerca de de la Administracion y Gerencia en el desarrollo de Software. Pero a veces uno no tiene el poder para generar cambios en una organización mediante el mandato ejecutivo. Obviamente, si uno es sólo un programador al pie del palo tótem, no puede largarse a dar órdenes a los demás para que comiencen a crear planificaciones o bases de datos de errores. Es más, incluso siendo gerente, es probable que descubra que manejar desarrolladores es muy similar a pastorear gatos, sólo que no tan divertido. El mero hecho de decir "háganlo" no garantiza que se hara.

Puede ser frustrante cuando uno trabaja en una organización que obtiene bajo puntaje en El Test de Joel. No importa que tan bueno pueda ser el código que uno genere, nuestros pares escribirán código tan malo que hace vergonzoso ser asociado con el proyecto. O la gerencia hace malas decisiones acerca de qué código escribir, y uno está forzado a malgastar su talento depurando la versión para AS/400 de un juego para niños sobre planes de jubilación .

Uno podría sencillamente renunciar, supongo. Pero presumiblemente hay alguna otra razón por la cual uno está atrapado aquí. Las opciones de compra de acciones aún no se materializan, no existe un mejor lugar para trabajar en Podunk, o quizás nuestro jefe ha raptado a alguien que amamos. En cualquier caso, intentar convivir con un mal equipo puede ser desesperante. Pero existen estrategias para mejorar un equipo desde abajo, y me gustaría compartir algunas de ellas.

Estrategia 1 Simplemente, hazlo.

Mucho puede ser hecho para mejorar un proyecto solamente con una persona. ¿No se tiene un servidor con un build diario? Hagamos uno. Configuremos nuestra propia máquina con una tarea programada para construir la aplicación durante la noche y enviar por correo electrónico los resultados. ¿Toma demasiados pasos el construir la aplicación? Escribamos el Makefile. ¿Nadie realiza pruebas de usabilidad? Hagamos nuestras propias pruebas de pasillo con los muchachos encargados del correo, usando un pedazo de papel o un prototipo hecho con Visual Basic.

Estrategia 2 Explota el Poder del marketing Viral

Muchas de las estrategias de El Test de Joel pueden ser implementadas por una sola persona, aún en un equipo indiferente. Algunas de ellas, si son hechas apropiadamente, se esparcirán al resto.

Por ejemplo, supongamos que nadie en nuestro equipo pueda ser persuadido de usar una base de datos de errores. No dejemos que eso nos moleste; sólo mantengamos una propia e ingresaremos los errores que encontramos en nuestro propio código. Si encontramos un error que alguien más debe solucionar, le asignaremos el error en la base de datos; si poseemos un buen programa de seguimiento de errores, éste le enviara un correo electrónico, y ahora podemos seguir enviándole correos si no corrige el error. Eventualmente, verán el valor del seguimiento de errores y comenzarán a usar el sistema como es debido. Si el equipo de Control de Calidad se niega a ingresar los reportes de error en la base de datos, simplemente rechacemos los reportes que provengan de cualquier otro medio. Cerca de la trigésima vez que uno diga "escuche, me gustaría arreglar eso, pero es seguro que lo olvidaré. ¿Podría ingresarlo al sistema de reporte de errores?", ellos comenzarán a usar la base de datos.

¿Nadie en nuestro equipo quiere usar control de versiones? Crearemos nuestro propio repositorio CVS, en nuestro propio disco duro si es necesario. Incluso sin cooperación, uno puede chequear su código independientemente de el resto. Entonces, cuando se encuentren con problemas que el control de versiones puede solucionar (alguien accidentalmente ingresó rm * ~ en vez de rm *~), vendrán por ayuda. Eventualmente se darán cuenta de que ellos también pueden realizar llevar su propio registro en el sistema de control de versiones.

Estrategia 3 Crea un Repertorio de Excelencia

¿El equipo no diseña planificaciones? ¿O no escriben documentos de especificaciones? Escribamos el nuestro. Nadie reclamará si uno se toma un día o dos para escribir un documento de especificaciones mínimo y planifica el trabajo que está por hacer.

Logremos reclutar mejores personas para el equipo. Involucrémonos en las contrataciones y en las [[ La guía de batalla para entrevistar | entrevistas de trabajo]], y reclutemos buenos candidatos para incorporarlos al equipo.

Encontremos la gente que desean mejorar y son capaces de ello, y pongámoslos de nuestro lado. Incluso en equipos mediocres, es probable encontrar alguien listo que simplemente no tiene la experiencia para crear buen código. Ayudémoslos; influyamos en ellos para que estén dispuestos a aprender. Leamos sus contribuciones al código. Si hacen algo estúpido, no les enviaremos un molesto correo explicándoles acerca de sus fallas, pues esto solamente logrará enojarles y ponerles a la defensiva. En vez, inocentemente reportaremos el error que sabemos está siendo causado por su código. Es mejor dejarles y que encuentren por sus medios qué está causando ese error. Cuando encuentren la causa por sí solos, habrán aprendido una lección.

Estrategia 4 Neutraliza a los tarados

Incluso los mejores equipos pueden tener un tarado o dos. La parte frustrante de tener malos programadores en un equipo es cuando su código defectuoso malogra nuestro trabajo, o cuando buenos programadores deben perder tiempo limpiando los desastres dejados por los malos programadores.

Siendo solo un peón, nuestra meta es minimizar los daños, estrategia conocida como contención. En determinado momento, uno de estos genios tardará dos semanas escribiendo un pedazo de código que resulta ser tan increíblemente malo que nunca podrá funcionar. Uno es tentado a gastar los quince minutos que tomaría rescribir eso mismo desde cero; pero debemos resistir la tentación, pues es la oportunidad perfecta para neutralizar a ese idiota por varios meses. Si nos limitamos a reportar errores contra su código, no tendrá más alternativa que mantenerse sudando tinta por meses hasta que no hayan errores. Durante esos meses no podrá dañar ninguna otra cosa.

Estrategia 5 Huye de las Interrupciones

Todos los ambientes de desarrollo felices son iguales (oficinas privadas, condiciones tranquilas para trabajar, excelentes herramientas, poquísimas interrupciones e incluso menos reuniones extensas). Todos los ambientes de trabajo tristes son infelices en su forma particular.

Las malas noticias son que cambiar el entorno de trabajo es casi imposible en virtualmente toda compañía. Arriendos a largo plazo a veces significan que ni siquiera el CEO puede hacer algo. Eso explica el porqué tan pocos desarrolladores de software obtienen oficinas privadas. Esto daña a sus compañías en al menos dos maneras: primero, hace más difícil el reclutar desarrolladores de primera línea, que preferirán a la firma que les entregue mejores condiciones de trabajo (siendo lo todo lo demás igual), y segundo, el nivel de interrupciones puede reducir la productividad de los desarrolladores de forma crítica, quienes encontrarán imposible "alcanzar la zona" y permanecer en ella por cualquier lapso de tiempo.

Busca maneras para salir de este ambiente. Llevar un laptop a la cafetería de la compañía, donde hay muchas mesas y están vacías la mayor parte del día (y donde nadie lo puede encontrar a uno). Reservar una sala de conferencias para todo el día y escribir código ahí, y dejar en claro a través de mucho código registrado en el repositorio CVS que cuando uno está en una habitación privada se es más productivo. La próxima vez que un gerente le pregunte a uno que necesita que este Listo Para Mañana , sabremos que responder. Ellos encontraran una oficina para facilitarnos durante el día. Y pronto comenzarán a preguntarse qué pueden hacer para mantenerle a uno productivo durante todo el año.

Llegar al trabajo tarde e irse tarde. Esas horas después de que el resto de la compañía se va a casa pueden ser las más productivas. O, si uno se encuentra en un equipo donde el resto del equipo usualmente llega tarde, llegaremos a trabajar a las 9 AM. Uno puede realizar más trabajo en las dos horas antes de que otra gente llegue y comience a molestar que lo que uno haría en el resto del día.

No mantener el correo electrónico o la mensajería instantánea corriendo. Se puede chequear el correo cada hora, si se desea, pero no lo mantendremos activo.

Estrategia 6 Vuelvete Invaluable

Ninguna de estas estrategias funciona si uno realmente no es un gran contribuyente. Si uno no escribe buen código, y mucho, será mal visto por andar por ahí jugando con bases de datos de errores cuando deberías estar escribiendo código. No hay nada más peligroso para la carrera de uno que tener la reputación de vivir tan preocupado de los procesos que nunca logra nada.

Una vez, cuando comencé un nuevo trabajo como un peón programador en una nueva compañía, descubrí que la compañía debía estar en un nivel cercano al 2 cuando se le examinaba con El Test de Joel, y estuve determinado en arreglarlo. Pero también sabía que entregar una buena primera impresión era crucial. Así que reservé las primeras siete horas del día en escribir código, como era de esperarse. No hay nada como una miríada de adiciones al código para verse bien ante los ojos del resto de la compañía. Pero reservé otra hora cada tarde antes de irme a casa con el fin de mejorar el proceso. Usé ese tiempo para arreglar cosas que hacían a nuestro producto difícil de depurar. Configuré un build diario y una base de datos de errores. Arreglé todas las molestias que habían durado demasiado tiempo y que hacían el desarrollo difícil. Escribí las especificaciones para el trabajo que estaba haciendo durante el día. Escribí un documento explicando paso por paso cómo crear una máquina de desarrollo desde cero. Cuidadosamente documenté un importante lenguaje interno que estaba indocumentado. Lentamente, el proceso mejoró. Nadie más que yo (y mi equipo, cuando fui puesto a cargo de uno) hizo jamás planificaciones de tareas o documentos de especificaciones, pero aparte de eso, lográbamos cerca del 10 en el Test de Joel.

Uno puede hacer mejorar las cosas, incluso cuando no se está a cargo, pero uno debe lograr ser como la esposa del César: fuera de toda sospecha. De otra forma, se hará de enemigos a medida que se avanza.


The Joel on Software Translation Project - Español

Personal tools