A la hora de tomar un proyecto nuevo se nos ocurren muchas preguntas para hacer, pero ¿cuáles son críticas para comenzar sin contratiempos? ¿Cuáles nos darán el mejor entendimiento del proyecto desde el día 1? En este artículo veremos las preguntas que creemos que son imprescindibles para comenzar un proyecto (en orden de importancia) y qué pasa si no las hacemos.

1) ¿Dónde se versiona el código? ¿Cómo consigo acceso?

No podemos comenzar a trabajar en ningún proyecto de software sin el código. Seguramente tendremos que gestionar accesos, VPN, etcétera, y todo este tema burocrático puede demorarnos semanas. Existe la posibilidad de que no se cuente con una herramienta de versionado, y por ejemplo que el código esté en un Drive o una carpeta, y sería una oportunidad para analizar los riesgos de eso y proponer alternativas, como Git o SVN.

2) ¿Qué medio de comunicación inmediata usaremos, y en qué horario?

Durante un proyecto siempre nos surgirán muchas dudas. Necesitamos lo antes posible pactar un canal de comunicación inmediata y a qué horario podemos hacer consultas, así podremos resolver rápido temas urgentes o temas que creemos que no ameriten un email, además de poder tener mayor cercanía con los demás equipos de trabajo. También evitamos las cadenas de mails confusas, nunca contestadas o que sólo terminan llegando a parte de nuestro equipo. 

3) ¿Cómo registro el trabajo hecho? (facturación) 

El momento de facturar es el peor para que nos surjan malentendidos respecto al trabajo que se hizo. Por eso debemos conocer qué herramienta utilizan en el proyecto para informar el trabajo incurrido (JIRA, por ejemplo) y tratar de mantenerlo actualizado, para evitar disgustos cuando ya sea muy tarde.

4) ¿Qué fechas de entrega conocen? 

Prestar atención a las fechas de entrega nos dará la previsibilidad necesaria para tomar mejores decisiones y evitar apuros o desarrollos de última hora. Gracias a esto podemos estimar, planificar y negociar cambios de planes que entreguen el mejor producto posible dentro de término.

5) ¿Dónde se despliega y quién lo hace? ¿Qué tecnologías utiliza el proyecto?

Si en el proyecto no tenemos control sobre la infraestructura, lo más probable es que tengamos que avisarle a alguien o seguir algún procedimiento para desplegar nuestro código. Tenemos que saber sobre qué plataforma se despliega para poder hacer el desarrollo que mejor se adapte a la plataforma. Por ejemplo, si hacemos una página web pero ésta se va a desplegar en un gestor de contenido, ¿tenemos en claro cómo se verá nuestro desarrollo en el producto final?

6) ¿Qué otras partes desarrollan el proyecto?

Existen proyectos donde trabajan muchos equipos, y a cada uno se le asigna una parte del flujo de desarrollo. Más allá de encargarnos de nuestra tarea particular, deberíamos entender cómo se une con las demás tareas, ya que todo lo que hacemos afecta a todo lo que viene después. Conocer el flujo completo de desarrollo nos permite proponer mejoras, y evitarle el retrabajo al resto de las partes.

7) ¿Cada cuánto el cliente nos dará feedback del producto?

Como mencionamos en el post de Cómo administrar un proyecto y dormir tranquilo, obtener feedback del cliente de manera frecuente puede determinar si nuestro proyecto tiene éxito o fracasa: debemos estar seguros de que entregamos el valor que el cliente espera. Cuanto más tiempo pasemos sin mostrarle al cliente nuestro producto, más nos desviaremos de su visión y más lejos estaremos de darle el valor que necesita.

8) ¿Se utiliza un gestor de tareas?

Un gestor de tareas nos sirve para que el cliente/project manager visualice rápidamente el progreso de cada equipo con el proyecto y pueda tomar mejores decisiones, para evitar tomar una tarea que ya está en progreso y poder ver en retrospectiva el trabajo que terminamos. Existen herramientas que ya nos resuelven este problema como Trello o Jira.

9) ¿Qué estándares de calidad vamos a manejar?

Al comenzar un proyecto debemos pactar la calidad que va a tener nuestro producto con el cliente de la manera más explícita posible para establecer el alcance de lo que se va a hacer y evitar reclamos del cliente inesperados. Es importante que ambas partes conozcan este estándar y es esperable que se vaya modificando a lo largo del proyecto, y es importante conocer las consecuencias de cada cambio sobre los tiempos de desarrollo.