Este artículo es para ti, un empresario valiente con una idea para una aplicación en tu corazón y un poco de dinero en el banco. Los diagramas que has garabateado en servilletas interrumpirán en el mundo entero, y camiones llenos de dinero ya han sido enviados a su casa. Para asegurar que lleguen a tiempo, aquí hay algunos sencillos consejos para hacer que tu ciclo de producción funcione sin problemas.
La Razón por la que Necesitas un Gestor de Proyectos
“Los programas de computadoras son las cosas más complejas que los seres humanos crean”, dice Douglas Crockford. Puede que no hayas oído ese nombre antes, pero para un programador es bastante famoso. Él es actualmente arquitecto de software senior de PayPal, y ha sido pionero en todo tipo de tecnología de vanguardia que está más allá del alcance de este artículo. Es alguien que tiene mucho conocimiento acerca de cómo trabajar en grandes proyectos.
En cuanto a mí, he estado programando desde hace 13 años y todavía hay momentos en que cada proyecto me lleva a un territorio desconocido. Hay muchas tecnologías diferentes, al igual que nuevas técnicas que se están diseñando a un ritmo tan alarmante, que nunca siento que estoy completamente al tanto de lo que está pasando. Mientras que cada proyecto tiene sus desafíos únicos, hay algunas constantes:
- El proyecto cuenta con la presión del tiempo.
- El presupuesto es más pequeño de lo que quisiera.
- Mis cuotas son más caras de lo que el cliente desea.
- No escucho tan perfectamente como el cliente desea.
- El cliente no explica las cosas tan perfectamente cómo me gustaría.
Obviamente, necesitamos una niñera. Alguien tiene que intervenir para establecer las reglas de juego, mantener a todos honestos y asegurarse de que no estamos olvidando algo importante. Alguien tiene que facilitar la comunicación entre todas las partes.
Esta persona, este héroe, es el Gestor de Proyectos (Project Manager).
Toptal no ofrecía contratos con gestores de proyectos cuando empecé a escribir este artículo, pero ahora si lo hacen (Toptal Projects). ¡Sinergia! Sólo puedo imaginar el poder que trajo el leer los siguientes consejos y se dieron cuenta que estaban perdiendo una gran oportunidad.
La Razón por la que un Programador no es un buen Gestor de Proyectos
Poniendo de lado la Certificación por el Instituto de Gestión de Proyectos (Project Management Institute), lo más importante que un Gestor de Proyectos puede traer a la mesa es la experiencia. Como resultado, muchos programadores serían gestores de proyectos bastante decentes; tenemos más experiencia que nadie con proyectos técnicos y nuestras mentes analíticas son expertas en la catalogación de información y el establecimiento de objetivos concretos.
Claramente nos estás pagando suficiente por lo que es razonable esperar que nos podamos gestionar nosotros mismos diferentes tareas en lugar de forzarte a pagar por el tiempo de otra persona también, ¿verdad?
Bueno, para empezar, nos estás pagando para codificar.
Cuando salimos de nuestro estupor de programación para tomar decisiones sobre qué priorizar, o para discutir sobre la cantidad de trabajo que en realidad se hará ésta semana, el código se deja de escribir. Después de esto, toma al menos 10 minutos para volver a “la zona”, sobre todo si estamos estresados por la conversación que acabamos de tener, que es probable, sobre todo si estamos discutiendo sobre la prioridad de las funciones. No es gran cosa, lo sé, pero todo esto se hace para lograr hacer un uso más eficiente de los recursos costosos.
Lo más importante es que enfocarse en los detalles no permite apreciar el entorno general. Si este artículo no te deja nada, solo trata de entender esto: Cuando me paso todo el día mirando algunos bugs específicos, mi cerebro pierde de vista el panorama más grande.
Mi cerebro me recompensa cuando arreglo esos bugs, y supongo que he hecho grandes cosas y ahora puedo ir a jugar videojuegos. Cuando alguien me recuerda que la página de inicio todavía no funciona, llega como una completa sorpresa porque he pasado todo el día llenando mi cerebro con un conocimiento muy detallado de una pieza muy pequeña del conjunto del proyecto, y me olvide de lo demás. Así es como funciona mi cerebro, y muchos otros programadores tienen una estructura psicológica similar.
La Razón por la que el Cliente no es buen Gestor de Proyectos
Pues bien, si nosotros los programadores no queremos tomar la responsabilidad de hacer cosas de gestión de proyectos, entonces la responsabilidad te queda a ti, el cliente. Es tú dinero. Es tú visión. De todas formas, tú eres el responsable de todo esto.
Sin embargo, también tienes mucho qué hacer.
Muchos clientes son simples mortales con trabajos diarios, como el resto de nosotros, y algunos incluso sufren de procrastinación u olvido. Aunque esto ciertamente no te describe a ti, por favor, considera la idea de tener un Professional Rememberer (Recordador Profesional) alrededor, de modo que puedas regresar a la importante labor de mantener el proyecto con vida.
Si has trabajado en, o supervisado, un proyecto técnico de alcance similar, tal vez sí seas un buen gestor para tu proyecto. Si no es así, por favor, no subestimes el valor de alguien que puede predecir los problemas que puedan surgir. Las estimaciones de tiempo son siempre sólo estimaciones y los bugs tienden a aparecer en los momentos menos oportunos. Vale la pena el costo de otro (aunque sólo sea a tiempo parcial) empleado, alguien que sepa qué partes del proceso necesitan, o pueden llegar a necesitar, la mayor atención.
Haz control de calidad, por ejemplo. Un control de calidad adecuado es esencial para conseguir lo que quieres de cualquier proyecto, y esto nunca recibe la atención que merece. Un buen Gestor de Proyectos sacará lo mejor de los recursos limitados de un control de calidad y también asegura la calidad de tus programadores para tu seguridad. A veces salimos de nuestra profundidad y a veces cometemos errores. Se necesita una persona técnicamente competente en un papel de supervisión para determinar si tu programador está teniendo un mal día, o si él o ella son, de hecho, una mala adición para el proyecto. Corregir problemas de personal desde el comienzo podría hacer la diferencia entre la vida y la muerte para tu proyecto.
Por último, incluso tú, oh glorioso cliente, a veces necesitas un poco de verificación y / o equilibrio. Eso es difícil para mí de escribir, ya que nosotros, los programadores no somos bien conocidos por nuestra franqueza al hablar. Basta con decir que he trabajado en muchos proyectos en los que el cliente estaba convencido de que todo era de primera prioridad y absolutamente todo era necesario que se lograra. Aunque no tengo ninguna duda de que esto era absolutamente cierto, estos clientes, por desgracia, no tenían control sobre el número de horas en un día. Ellos no obtuvieron el resultado positivo que deseaban y/o merecían, y siento que este resultado pudo haber sido evitado si el cliente hubiese dado a un Gestor de Proyectos la autoridad para evaluar la carga de trabajo y con mucho tacto, pero con firmeza, mantener las cosas bajo control. Es difícil tomar las desafortunadas decisiones a juicio personal que requieren la mayoría de los proyectos técnicos, cuando es tu idea y tu dinero en juego y a la computadora no le importa si tú o yo lloramos y le gritamos a ella. (Sé que esto es cierto porque lo he intentado muchas veces).
Una Lista Incompleta de Técnicas para la Gestión de un Proyecto Técnico
Ya sea que hayas decidido hacer caso omiso a las más de 1.000 palabras anteriores y quieres gestionar tu proyecto por ti mismo, o si vas a contratar a alguien, pero deseas tener más conocimientos sobre el proceso, ésta lista te ayudará. Nunca he (oficialmente) sido Gestor de Proyectos, así que no puedo decir qué herramientas utilizaría cualquier Gestor de Proyectos, pero he tenido buen éxito con todas estas técnicas:
Milestones
Al comenzar un nuevo proyecto, la mayoría de las personas saben intuitivamente que es importante dividir el proyecto en trozos ligeramente más manejables, cada trozo podría ir desde un par de semanas a un par de meses en términos de trabajo. Al comienzo del proyecto, es bueno tener una reunión inicial para establecer estas milestones o puntos específicos. Está bien ser un poco vago en cómo se va a llegar a alcanzarlas, lo más importante es supervisar después de cada etapa, con el fin de beneficiarse de la comprensión del proyecto, mejorada, de todo el mundo y para asegurarse de que las etapas del proyecto son todavía (más o menos) del mismo tamaño que inicialmente se creía.
Las Estimaciones de Tiempo
Nosotros los programadores detestamos absolutamente las estimaciones, porque sabemos que van a salir mal y que serán utilizadas en nuestra contra. Está bien que estén mal, ya que, por definición, están basadas en un puñado de enigmas. También está bien que se usen en nuestra contra, porque nuestro trabajo es bastante cómodo y no se pierde nada con sentir algo de presión de vez en cuando.
Así que no dudes en preguntar por las estimaciones cada vez que se comienza el trabajo de una nueva etapa. Debes esperar una explicación de una o dos líneas por cada característica importante, junto con una estimación aproximada de cuánto tiempo tomará esa característica. Normalmente suelo hacer una estimación optimista, para después duplicarla. Muchas veces, este tiempo extra se le dedica a los obstáculos invisibles.
Historias de Usuario
Las historias de usuario son breves descripciones de una sola pieza de funcionalidad dentro de la aplicación. Son útiles como un registro de las características importantes y deben ser del tamaño de un bocado, capaz de encajar en una ficha y, a menudo, acompañado de un pequeño dibujo. Más importante aún, sirven como un puente entre lo que el cliente quiere y lo que el programador tiene que decirle a la computadora. Las historias son lo suficientemente simples para que tú, el cliente, puedas entender en un par de minutos, pero lo suficientemente detalladas para que nosotros, los programadores, podamos sacarle el mejor provecho.
Para alguna información rápida en historias de usuario, me pareció que estos tutoriales de Mountain Goat Software y Roman Pichler, son de alta calidad y concisos. Para obtener más información sobre toda la filosofía de “Agile Project Management”, prueba este blog post de Toptal The Ultimate Introduction To Agile Project Management, de Paul Barnes.
Composiciones (Mock-ups)
Esto no es un artículo sobre por qué necesitas un diseñador, porque siento que la mayoría de los clientes ya entienden eso, pero vale la pena repetirlo porque verás enormes ganancias de productividad si le muestras a tus programadores un diseño bien planeado y concreto. Cada vez que tenemos que tomar una decisión de diseño tenemos que salir de “la zona”, y cada vez que tenemos que regresar y cambiar algo, porque no se nos proporcionó el borrador final, bueno, saca la cuenta… no me estoy quejando, porque el diseño es divertido, pero en mi experiencia, esta es la fuente Nº 1 de horas facturables adicionales que se pueden evitar.
La mayoría de los diseñadores proporcionan composiciones, también conocidas como “comps” en Adobe Photoshop, Adobe Illustrator o Sketch. Si lo estás haciendo tú mismo, puedes utilizar una de las innumerables herramientas en línea como Balsamiq o InVision. El comp no tiene que tener los mismos colores y estilos como el producto terminado (ya que estos se pueden cambiar fácilmente más adelante), pero por favor toma un tiempo extra para asegurarte de que todos los elementos de interfaz de usuario están presentes y verificados.
Reuniones Stand-Up
Las reuniones largas a veces son inevitables, pero no sobrecargues a tus programadores ni tomes más tiempo del que sea necesario. He tenido clientes que parecían esperar que me acordara de todo lo que se dijo durante una reunión de dos horas y media; estaban muy decepcionados. Una reunión stand-up se limita generalmente a 15 minutos, y se acostumbra a estar de pie durante ésta. El hecho de estar de pie se supone que debe garantizar que todo el mundo participe, así como para mantener la reunión corta.
Durante stand-ups, todo el mundo se mueve en un círculo para proporcionar un breve informe sobre la situación, manteniendo a todos los miembros del equipo al día sobre el progreso de los demás. Puedes encontrar más información sobre soporte de UPS en ExtremeProgramming.Org. Si todos trabajan a distancia y no quieres reunirte en Skype todos los días, podrías usar una herramienta divertida como 15Five, como una alternativa a stand-ups. 15Five permite a los miembros del equipo proporcionar su opinión siempre que sea conveniente para ellos, y les hará preguntas de encuesta para generar respuestas más profundas.
Ticketing System
Si bien cualquier persona puede mantener un sistema de notas adhesivas y Google Docs (con las tareas de cada uno resaltadas en diferentes colores), no es realmente necesario. Muchas personas han tratado de resolver este problema por ti. Basecamp y Trello son famosos por su facilidad de uso, mientras que Pivotal intenta encapsular toda la filosofía “ágil” en un paquete muy sofisticado. Sea cual sea tu elección, un buen ticketing system te permitirá, como mínimo:
- Crear tareas
- Asignar prioridad y fecha de entrega
- Tareas de enlace y subtareas
- Asignar diferentes resoluciones como “completado” o “prueba fallida”
- Mostrar todas las tareas asignadas a un determinado usuario
Cuando un Gestor de Proyectos te muestra 40 tickets de máxima prioridad de color rojo brillante que se deben entregar en el mismo día, realmente vas a entender el valor de esta visión del proyecto.
Control de Versiones
Tal vez ni siquiera llegues a mirar el código en el sistema de control de versiones de tu proyecto, pero el control de versiones (o versionado) es una de las herramientas más importantes de las cuales disponemos, el mayor sistema de copia de seguridad imaginable.
La mayoría de los proyectos modernos usan Git, aunque a veces te encontrarás con Subversion (SVN) cuando trabajes en proyectos que han salido al público desde hace un tiempo. Github permite alojar un número ilimitado de repositorios públicos de forma gratuita (además, contiene la mayor parte de los proyectos de código abierto del mundo), mientras que Bitbucket permite alojar repositorios privados ilimitados y por lo tanto es la opción favorita para los proyectos comerciales.
Cualquiera que sea el sistema de control de versiones a elegir, éste almacena nuestro código de forma remota en caso de que algo suceda, además de un seguimiento cada vez que “comprometemos” el código, al mismo tiempo que nos obliga a escribir un pequeño mensaje que describe en que estábamos trabajando. Esto evita que distintos desarrolladores sobrescriban el código de cada uno, nos permite ver todos los cambios que se realizaron durante un período de tiempo determinado, y nos permite crear nuevas ramas de código para almacenar características que no van a salir en vivo de forma inmediata. Incluso tiene un comando llamado “culpa” que muestra quien fue responsable de una determinada línea de código, y cuando se cometió.
Control de Versiones es lo mejor.
Desarrollo basado en pruebas
Esta es una práctica relativamente cara, lo cual significa que no se emplea con frecuencia en los proyectos donde el presupuesto se limita a un par de trabajadores freelance. Así que para comenzar, no deberías sentirte muy mal por no hacer esto, pero tengo que presentarte la idea, ya que ofrece la mejor defensa contra los bugs. Básicamente, tus programadores pasan preciadas horas adicionales escribiendo pruebas (pequeños bloques de código) para asegurar que ciertas partes de la aplicación se comporten de manera específica, predecible y repetible. Por ejemplo, podría escribir una prueba asegurando que cuando se hace clic en el botón de “inicio de sesión”, una ventana emergente se abre con un campo de nombre de usuario en el mismo.
La belleza de las pruebas es que una vez que las he escrito, puedo ejecutarlas a todas con un solo comando. Si tengo 200 pruebas escritas, las puedo ejecutar después de lanzar una nueva versión de la aplicación para asegurarme de que ningún bug se ha introducido en cualquiera de las 200 características. No es perfecto, pero es lo más cercano que podemos llegar a garantizar aplicaciones libres de bugs (bug-lite, por lo menos).
Para Cerrar
Eso es todo lo que sé acerca de la gestión de proyectos. No estoy seguro de cuánto de esto pasaría el examen en el Instituto de Gestión de Proyectos, pero es todo el material que he recogido mediante el trabajo en proyectos web en el transcurso de la última década. Por supuesto, recomiendo que contrates a alguien con el fin de obtener el beneficio de su experiencia, pero espero que esta información sea útil aunque no sea algo que tengas la oportunidad de hacer. Serás la máxima autoridad en este proyecto, así que cuanto más sepas acerca de su funcionamiento interno, más probabilidades hay de que lo lleves a la victoria.
About the author
Ethan James, United States
MEMBER SINCE NOVEMBER 2, 2015
Ethan has worked on many different stacks, but always returns to his first love: JavaScript. He delights in connecting RESTful APIs to painstakingly-engineered front-ends using AngularJS, or whichever other framework provides the best user experience for the project. He writes clean, semantic HTML5 and CSS3 and is as responsive as the sites he builds. He is pleasant and diligent. [click to continue...]
No hay comentarios:
Publicar un comentario