Traducción por Frost en
CE.
1- Como productores tenéis la oportunidad de echar un vistazo en profundidad al juego y a la gente que trabaja en sus diversos sistemas. ¿Hay algo que siempre quisisteis hacer (u os gustaría poder hacer) si tuvieseis las habilidades apropiadas? ¿En qué os gustaría trabajar?Eric Kieron Davies: Si habéis visto el Meet the Devs, mi trasfondo estaba en animación y cuando salí de la Facultad quería ser animador. Conseguí el grado de Animador e Interpretación... todo lo que necesitaba para obtener una sólida animación de un personaje. Y ese era el camino que yo seguía... Así que para mi, me gustaría meterme en el lado de animación de interpretación y personajes para transmitir una historia. Me encanta contar una historia.
Darian Vorlick: Así que este es tu Papel Protagonista como Productor Senior... (risas)
Eric Kieron Davies: (risas) Supongo...
Darian Vorlick: Te has entregado a ti mismo el papel de Productor Senior y ese es tu guión... (risas)
Eric Kieron Davies: Si, por supuesto. ¿Y tú?
Darian Vorlick: Probablemente el aspecto de escritor y de la ficción del proyecto. Dada mi trayectoria como editor me encantaría ser un Administrador de Proyecto vigilando como se desarrolla la escritura. Crear una mitología es algo que me parece muy interesante. Tengo un amor muy arraigado por las publicaciones impresas tradicionales. Hay algo romántico y clásico en sujetar un libro entre tus manos y saber que tú tuviste algo que ver en su creación. Pero... bueno, me gusta en realidad lo que hago, interactuar con los desarrolladores e ingenieros. Es diferente de cualquier otra cosa que haya hecho y me gustan las cosas nuevas.
Eric Kieron Davies: Ahí tenéis nuestra respuesta.
2- Como productores supervisáis el desarrollo del proyecto y coordináis las diferentes disciplinas (Arte, Diseño etc) para unificarlo en un producto acabado para el juego (una nave, localización, etc); pero para hacer esto debéis poneros al nivel de detalles del proyecto. ¿Cómo hacéis para mantener las distancias y el objetivo final frente a perderos en la "conejera" de los detalles? Dadnos un ejemplo.Darian Vorlick: Hemos estado esperando y preparándonos para responder a esta pregunta.
Eric Kieron Davies: Es muy difícil. Más adelante hablaremos sobre esto; pero la idea es contratar a nivel de producción a gente con diferentes especialidades y gustos para que te proporcionen diferentes perspectivas. Si es algo técnico es mejor tener a algún productor que controle en esos aspectos para darte las respuestas. Como Darian dijo en un mensaje: "conoce lo suficiente para ser peligroso".
Darian Vorlick: Si. En realidad esa cita es de Jason Hutchins.
Eric Kieron Davies: Totalmente cierta. En general, depende en lo que te tengas que meter. Es bueno tener un plan general y un calendario que haces con tus jefes de departamento, pero en cierto sentido tienes que meterte en los detalles para profundizar. No deberías hacer sólo una de las cosas, si no ambas en el momento apropiado.
Darian Vorlick: Cuando empecé aquí yo no era un programador o un ingeniero, por lo que había una sensación de estar fuera de lugar al llegar. No estaba seguro de que podría hablar al nivel necesario para comunicarme con los diseñadores y los ingenieros; pero a base de pura saturación siento que puedo tener una conversación semi-inteligente sin tener que utilizar señales y gruñidos. Ser capaz de tener una conversación sobre el sistema de objetos o el sistema de tokens de identidades. Debemos ser capaz de hacer preguntas sobre cómo va el progreso de algo y saber cuando algo nos está, en cierto sentido, engañándonos para poder anticipar las necesidades de esa disciplina. No hay que ser expertos en ella para poder tener una conversación sobre ellas y administrarlas.
Eric Kieron Davies: Para daros un ejemplo, tenemos el sistema de tokens de identidades. ¿Cómo lo administraste?
Darian Vorlick: Tuvimos una conversación esta mañana con el programador de Reino Unido, Stephen Humphries, que está escribiendo la secuela de GOST: el sistema de tokens de identidades. Yo no se hablar gráfico de flujos en CryEngine; pero como sé lo suficiente sobre lo que quieren lograr con este nuevo sistema puedo prever sus necesidades o si alguien abandonase esta parte del proyecto qué podemos hacer para solucionarlo. Saber quien tiene qué habilidades es útil para llenar ese vacío.
Eric Kieron Davies: Saber equilibrar vista general y detalle es la propia razón por la que existen los productores. Somos la perspectiva externa del proyecto y por lo tanto, de manera intrínseca, esto nos permite tener esta vista de pájaro que nos permite entenderlo.
Darian Vorlick: A veces tener conocimientos técnicos es una hoja de doble filo, porque te puedes poner sin darte cuenta a corregir errores del código o diseño en vez de administrar y coordinar a los programadores y diseñadores que se deberían dedicar a ello.
3- ¿Cómo hacéis estimaciones de tiempo en situaciones en las que aparecen "bloqueadores técnicos"?Darian Vorlick: No es un problema especial respecto a otros problemas de desarrollo. Simplemente preguntamos al experto cuanto tiempo creen que les llevará respecto a cosas similares que ya han hecho en el pasado y nosotros como productores miramos la escala de lo que hacen para hacer el ajuste proporcional.
Eric Kieron Davies: Si.
Darian Vorlick: Cuando aparecen problemas técnicos... bueno, es lo de siempre. Cuando publicas un calendario de fechas interno se convierte instantáneamente en algo obsoleto porque las fechas y el tiempo de una tarea cambia cada día. A veces algo que podría llevar poco tiempo se alarga porque necesitamos a una persona esencial para resolver rápidamente otro bloqueador técnico que se ha presentado. Debido a que tenemos una cantidad limitada de recursos el tiempo que un desarrollador entrega a una tarea es todavía más valioso. Ser capaz de de planear el tiempo que va a llevar algo así es muy difícil.
Eric Kieron Davies: Al final siempre se añade un tiempo extra adicional del 5 o 10%. Si lleva 2 semanas te daré dos semanas y media, por ejemplo. En general la producción real suele extender un poco más que ese búfer que has creado pero se hace para proteger al equipo, porque no sólo quieres cumplir si no impresionar con lo que entregas.
Darian Vorlick: También hay que entender la diferencia entre 5 días de trabajo y 5 días hábiles. Si durante esos 5 días hábiles Mark Abent ha estado trabajando en otras cosas el tiempo de finalización se puede extender.
Eric Kieron Davies: Estar en producción de un juego ya lanzado (ndt: la pre-alpha), más desarrollo, más pre-producción y producción tienes que añadir tiempo adicional porque a veces tiene que resolver bugs aquí y allá. Es una buena pregunta, pero al final es conocer el equipo y hacer una buena estimación.
4- Se ha comentado varias veces que CIG está reuniendo sus recursos en distintas partes del mundo, poniendo a gente con el mismo tipo de habilidades en el mismo lugar y de esa manera evitando los problemas de trabajar con gente en distintas franjas horarias. Desde un punto de producción, ¿Cómo ha mejorado esto la eficiencia del proyecto? ¿Ha afectado, por ejemplo, a la velocidad en que se está remodelando la Freelancer?Darian Vorlick: ¡Ese es un ejemplo sospechosamente específico!
Eric Kieron Davies: ¡Si! No sé por qué nos habrá puesto la Freelancer de ejemplo... Chris explicó esto en su carta y a la gente le gusta mucho leer entre líneas; pero en realidad no hay nada que ver entre ellas. Simplemente estábamos mirando cómo hacer lo mejor para el proyecto. Cómo hacerlo de manera más rápida y eficiente. Y hacemos esto constantemente. Verás cambios de este tipo en el desarrollo de cualquier videojuego, rehaciendo el equipo de desarrollo. En mis viejos empleos reorganizábamos el equipo cada año o cada seis meses (ndt. Blizzard): es muy común. Si sabes que puedes hacer una nave más rápidamente no necesitas tanta gente en el equipo. O necesitas más gente para acabar antes. Sea cual sea el caso, así es la industria.
Este cambio está en marcha en estos mismos momentos y nos estamos moviendo para terminarlo cuanto antes. Un ejemplo de por qué esto será bueno es nuestro equipo de Sonido en Reino Unido, dirigido por Lee Banyard: trabajan bien y rápido, entregando materiales cuando se solicitan. ¿Por qué son tan buenos? ¡Por que están todos juntos en el mismo sitio! Cuando algo pasa, se giran y trabajan en equipo para arreglarlo. No tienen que esperar 24 horas para que llegue un email. Todavía tenemos múltiples estudios porque tiene sentido tenerlo así, pero estamos unificando disciplinas y veréis sus efectos durante los siguientes meses.
Respecto a la Freelancer... ¿Darian?
Darian Vorlick: No tengo nada que comentar al respecto.
Eric Kieron Davies: Muy bien. (sonrisa maligna) Investigaremos al respecto y ya te informaremos.
5- Como productores hacéis de Administradores del Proyecto y por lo tanto tenéis un enorme papel vigilando el desarrollo del juego. ¿En qué momento juzgáis oportuno intervenir cuando veis que una persona o una subcontrata está teniendo problemas con la tarea que se les asignó? ¿Qué acciones habéis tomado en esos casos? Adicionalmente, ¿Los equipos están formados por individuos trabajando en tareas solitarias o en equipos pequeños dirigidos por un líder más experimentado?Darian Vorlick: En nuestra jerarquía de equipos tenemos un Líder para cada equipo: Diseño, Ingeniería, Arte. Estos Líderes dirigen esos equipos. Cuando creamos una tarea para alguien son generadas en colaboración con los líderes del equipo, de manera que estos siempre estén al tanto de lo que hacen sus subordinados. Y nosotros como producción tenemos una vista general de lo que debe ser hecho.
Si por ejemplo vamos a añadir unas características para el siguiente parche nos sentamos con los líderes de equipo y averiguamos que hace falta para que sean terminados. Las dividimos en tareas individuales y las empezamos a mirar qué desarrolladores con las habilidades apropiadas están libres.
Eric Kieron Davies: Respecto a qué acciones hemos tomado cuando algo es díficil...
Darian Vorlick: Hablamos con ellos.
Eric Kieron Davies: Cualquier cosa. Evaluamos si la tarea fue increíblemente mal planeada y en vez de dos días hacen falta tres meses. Un gran error y tenemos que reunirnos con los líderes. Quizá tenemos problemas informáticos o quizá les hemos retirado demasiado tiempo de sus tareas para resolver bugs. Quizás no funciona en nuestra estructura actual. Un ejemplo de esto es mover cadenas de montaje enteras a distintas localizaciones de nuestros estudios porque tenemos la gente apropiada para hacerlo allí, no porque la gente estaba fracasando en su trabajo y queríamos deshacernos de ellos. Hacemos lo que tiene más sentido y se evalúa constantemente mediante nuestras prácticas de contratación.
6- ¿Qué desafíos aparecen cuando hay cambios de trabajadores en un departamento? ¿Qué pasa cuando se cambian productores? ¿Hay que reasignar algunas responsabilidades? ¿Tenéis responsabilidades divididas entre vosotros o todos tenéis una vista general de lo que sucede? ¿Tenéis problemas de comunicación por tener idiomas o culturas distintas?Eric Kieron Davies: En esta industria, especialmente en las del entretenimiento, la gente cambia de trabajo. Es algo normal. Consiguen otro trabajo, se les promociona, se casan, tienen que mudarse a otro país, tienen hijos que van a la escuela... La gente va y viene. Es algo muy fluido y no tiene nada de nuevo.
Para nosotros es una cuestión de tener planes de contingencia y saber quien puede dominar algo en el entorno presente de desarrollo. Cuando alguien se va nunca hay, para nada, la expectación de que todos los productores lo sepan todo. No hay manera de hacer esto, sería algo que superaría a cualquiera con el nivel de producción de esta compañía. Así que si, lo dividimos en responsabilidades. Darian por ejemplo trabaja con el equipo de Ingeniería de Santa Mónica, con los lanzamientos públicos y también vas a hacer X, Y y Z. Probablemente estarás implicadas en estas tres cosas y también oirás de otras cosas porque estás en ese mismo estudio; pero no se te requiere saberlo todo. De hecho, tenemos que confiar los unos en los otros.
Así que cuando alguien me dice: hey, he conseguido un fantástico trabajo, mi mujer tiene que hacer tal cosa, o mi marido esto, no pasa nada: tenemos el plan de contingencia. O se reparte sus responsabilidades y trabajo o miramos si es posible contratar a alguien nuevo y filtramos eso de nuevo. Por muy mal que suene, tenemos un plan de contingencia para cualquiera aunque "les atropelle un bus". Si. Queremos asegurarnos de que la gente sepa lo suficiente de los demás para que puedan echar una mano si es necesario.
Darian Vorlick: Siempre es una buena señal de que estás haciendo buenas prácticas cuando la compañía no se desmorona cuando alguien se va. Si eres tan esencial y central que si te vas las cosas se van al garete.. eso recalca las ineficiencias de la prácticas de vuestro estudio. Como Administrador del Proyecto tengo que asegurarme de que si yo me voy las cosas sigan funcionando como un mecanismo de relojería.
Eric Kieron Davies: Sobre las barreras de cultura e idioma, somos personas adecuadas a las que preguntar esto. En anteriores trabajos tuve que hacer negocios en China por múltiples razones, poner en marcha ciertas operaciones y para mi esto fue un desafío, sea por frases que utilizas, terminología o jerga de email o poner ejemplos de deportes que no conozco como el fútbol. ¡Usa términos de beisbol o algo así! Son ejemplos de un poco tontos, porque nuestra oficina de Frankfurt habla perfectamente en inglés y trabajan muy bien; pero hay desafíos.
Darian Vorlick: Ricky Jutley de Reino Unido estuvo por aquí y viceversa, por lo que estamos creando algo de intercambio cultural y hace que la compañía sea mucho más homogénea.
Eric Kieron Davies: Siempre consideramos que las cosas se hacen por un esfuerzo de equipo y no queremos andar por ahí diciendo a la gente que "es culpa tuya". Echar la culpa a los demás no funciona, ni en tu familia ni en los negocios.
Darian Vorlick: Crea animosidad y toxicidad. Es una reacción innata señalar con el dedo y decir: "Es culpa vuestra".
Eric Kieron Davies: Si, se trata más de encontrar la raíz del problema y solucionarlo a gran escala. Por supuesto, si alguien ES un problema se toman las apropiadas decisiones de negocios al respecto.
7- ¿Cómo hacéis para tener múltiples versiones de desarrollo al mismo tiempo? Ejemplo: 1.3, 2.0 y Star Marine. Además, ¿podríais explicarnos la importancia de unificar el código en 1.3 para el proyecto y si hace que sea más fácil desarrollar?Eric Kieron Davies: El 1.3 y su unificación del código ayudó inmensamente porque todo el mundo, a nivel global, usamos el mismo código. Rompió algunas cosas unificar todo esto; pero ahora estamos todos mirando la misma versión y trabajando en la misma. Queremos mantener este conjunto unificado de desarrollo.
Darian Vorlick: Eso y que además queremos poner mucho énfasis en la estabilidad del sistema y puede que os hayáis dado cuenta de que ha mejorado mucho últimamente desde que hacemos esto.
Respecto a tener varias versiones del juego al mismo tiempo en desarrollo... ¡Esa es la razón por la que tenemos múltiples equipos! Una persona puede estar trabajando en una versión propia, mientras otros trabajan en una versión más pública y esto reside en tener un buen equipo de Control de Calidad que detecte los bugs que van a apareciendo en el parche 1.3 y que podrían afectar a la versión principal de desarrollo. Hay que estar atentos a lo que sucede en cada versión, vigilar los hitos del proyecto que deben ser alcanzados y utilizar Jira de manera muy eficiente. Tenemos una interfaz que nos permite saber qué tareas y bugs tenemos en cada versión en desarrollo, qué bugs bloqueadores, críticos y triviales hay allí y hablamos diariamente sobre qué tareas o bugs deben ser atacados el día siguiente.
Eric Kieron Davies: Si. Respecto a cómo nos ayuda: enormemente. Esto permite trabajar en la versión pública 1.3 que ya tenéis mientras se automatiza sus arreglos que se añaden a la versión principal para que no haga falta orquestar esos arreglos en la versión principal cuando tengan que sacar otra versión pública.
Thomas Henessy (Cámara): ¡En el programa de hoy, Darian y Eric discuten las ventajas de cruzar los streams! (Ndt: juego de palabras en referencia a "nunca cruzar los rayos" en Ghostbusters y a cruzar otro tipo de chorros fisiológicos XD)
Eric Kieron Davies: ¡Me gusta!! Asegúrate de editarlo de manera que no sea muy pervertida.... ¡Siguiente pregunta!
8- ¿Si algo se vuelve muy complicado para ser finalmente implementado en el juego se elimina o se simplifica? Y además, ¿Qué métodos utilizáis para criticar el trabajo ajeno, fechas de entrega etc? ¿Palo o Zanahoria?Darian Vorlick: Respecto a la primera pregunta, ahora mismo cuando se usa el Flowgraph (Como en la conversación de esta mañana con Humphries sobre el sistema de tokens de identidades) tenemos un ping en la red y eso hace que se saturen mucho las líneas, así que una de las cosas que estamos decidiendo es si es bueno diseñar cosas de las naves usando Flowgraph. De esto sale una conversación entre diseñadores sobre si es mejor programarlo a mano o usar flowgraphs de todas formas o usar los tokens de identidad. Todo esto se planea por adelantado y se hace I+D para ver si es posible, haciendo pruebas de concepto y prototipos y cual de ellos funciona mejor.
Eric Kieron Davies: Si. Sobre la siguiente pregunta sobre palo o zanahoria.. Yo no creo en esas dos opciones, porque este viejo adagio te lleva a nunca conseguir esa zanahoria y eso acaba cansando. Es mejor trabajar a través de los líderes de departamento, presentando pequeños objetivos fáciles de lograr y motivar de manera consistente y constante diariamente. Amenazar o sobornar no lleva a ninguna parte, sobre todo trabajando en un ambiente tan creativo como este en el que se crea entretenimiento y experiencias divertidas. No estamos haciendo un engranaje o un coche, algo probado y hecho millones de veces: estamos haciendo algo nuevo y vamos improvisando sobre la marcha como hacerlo. Requiere de mucha más sutilidad que ese tipo de viejas prácticas.
Darian Vorlick: Es cierto. En los estudios en los que se gobierna con puño de hierro... es algo anticuado y que al final es contraproducente porque nadie aporta sus propias ideas. Es mejor usar un esfuerzo colaborativo, un toma y un daca, conversando diariamente con nuestros compañeros locales e internacionales sobre los bloqueadores y problemas que tienen y qué ideas pueden aportar.
Eric Kieron Davies: Además, si estás usando el método de la zanahoria y el palo es que estás forzando a alguien a hacer algo que odia.
Darian Vorlick: Y no queremos compulsar a nadie.
Eric Kieron Davies: ¡Nos encanta trabajar en esto y nuestra pasión nos lleva a trabajar cada día en este proyecto! No hace falta usar esos métodos forzosos. Respecto a la crítica positiva y negativa... ¡queremos ambas cosas! Es cierto que siempre queremos hacer las cosas mejor y las miramos de manera negativa y crítica para hacerlas mejor, pero tenemos que motivarnos señalando lo que nos gusta y lo que ha salido bien para ir hacia delante. Las críticas negativas están bien, como en los foros, porque nos señalan lo que creen que hicimos mal y las buenas nos indican qué puntos fuertes tuvimos y en qué tuvimos éxito. Eso nos ayuda a mejorar las cosas.
Darian Vorlick: Y si, a veces tenemos que poner el pie en el suelo y trazar una línea. Sé que te encantaría añadir esta nueva característica a la nueva versión pero no podemos porque no tenemos ni tiempo ni recursos para hacerlo bien. Mejor esperar al siguiente parche y mientras tanto ajustarlo y pulirlo más.
9- ¿Qué proporción de vuestro trabajo no veremos en mucho tiempo comparando con cosas que veremos a corto plazo? ¿Estamos viendo lo último recién salido del horno o estamos disfrutando de viejo contenido ya pulido? ¿Qué estilo de desarrollo tenéis: en cascada o ágil? ¿El entorno de trabajo se parece más a Mad Max o a Jurassic Park?Eric Kieron Davies: (risas)
Darian Vorlick: Bromeamos sobre que a veces pinchamos al equipo para conseguir lo que queremos, pero siempre lo decimos en broma. ¡Muy raramente tenemos que obligarles a hacer algo, por eso tengo una gran espada en mi oficina!
Eric Kieron Davies: (risas)
Darian Vorlick: Es una pregunta interesante porque una gran parte de lo que hacemos ha sido planeado hace muchos meses, pero muchas veces mientras trabajamos para un evento hasta el último momento. Hay cosas que intentamos arreglar y meter en el juego hasta el último día que entran en el parche o tenemos una mecánica nueva que lleva mucho tiempo en desarrollo pero que no se mostrará hasta que llegue un evento. Realmente vemos la versión terminada de nuestro trabajo cuando lo veis vosotros en directo.
Eric Kieron Davies: Si.
Darian Vorlick: Esto es parecido a trabajar en una película. Los actores sólo ven sus líneas y se las aprenden. No ven la película acabada hasta que van a una presentación privada previa al estreno. A menudo lo vemos unido días antes o a veces en directo. Si nos veis en los vídeos estamos animando tanto como vosotros por lo que vemos, porque es fantástico, podemos ver el resultado de lo que hemos estado haciendo los últimos meses.
Eric Kieron Davies: Si, mantenemos la cabeza gacha y a veces es difícil ver cómo de gran somos. Tenemos una mezcla de ambas cosas: una lista maestra en el calendario y constantemente nos aprovechamos de ella para hacerla realidad. Las cosas que os mostramos es gran parte de lo que tenemos, lo hacemos tan a menudo como podemos y a menos que sea una gran revelación como el Discurso de Bishop, que queremos que sea excitante cuando llegue, intentamos mostrar todo lo que tenemos pero todo esto son partes de lo que todavía está en construcción de un gran universo. Por eso Chris lo dividió en módulos, para que vieseis su partes.
Darian Vorlick: Cuando enseñamos en Around the Verse un Sneak Peak de una nave o concept art es porque estamos trabajando de manera activa en ese arte, por lo que para cuando llegue el momento de lanzarlo en Arena Commander será la culminación de meses de trabajo que vosotros habréis visto antes gracias a la transparencia que tenemos con nuestro desarrollo. Respecto a metodología de desarrollo..
Eric Kieron Davies: ... es bastante ágil, si. No es 100% ágil, hardcore, pero al mismo tiempo tomamos cosas de la cascada alcanzando ciertos objetivos y se unifican entre ellos. La agilidad es la micro en la macro de la cascada.
Darian Vorlick: Yo uso la metodología de mi hermano, la metodología Dwit: Do Whatever It Takes (haz lo que sea necesario).
Eric Kieron Davies: Hazlo.
Darian Vorlick: Respecto a si es Mad Max o Jurassic Park (risas), voy a hacer un chop de la cara de Eric sobre la de Chris Pratt de Jurassic World y pondré las caras del resto de los desarrolladores sobre las de los raptors cuando está en el pozo de estos dinosaurios (risas).
Eric Kieron Davies: Es una pregunta dura. Una expresión habitual es "pastorear gatos", porque cuando tienes gente tan creativa mantenerles unidos es un desafío.
10- ¿Cómo usáis Jira? ¿Es la fuente de la verdad, modificada y ajustada para llevar vuestro desarrollo al día, o usáis tablas de cálculo para llevar el día a día?Eric Kieron Davies: Tenemos una metodología más que implementada a estas alturas y Jira es una de nuestras herramientas de producción y estamos animando a la gente a mantener su estado al día para mejorar comunicación y trabajo entre estudios y saber qué trabajo queda por hacer. Gracias a esto y hacer buenos calendarios te puedes hacer una idea del tiempo, recursos y tareas que quedan por hacer para completar tus objetivos. Jira sirve para recolectar toda la información y ver qué lo bloquea para quitarlo del medio y llegar a la siguiente versión. "Si no está en Jira, no existe": ese es nuestro mantra.
Darian Vorlick: También sirve para tener responsabilidades. Cuando alguien inicia una tarea en Jira tenemos un registro sobre el tiempo invertido en una tarea, qué gente está en ello y cuanto tiempo falta. Esto es lo que nos permite acelerar las cosas, hacer reuniones de coordinación más eficientes.
Eric Kieron Davies: Cualquier herramienta de producción es tan buena como la gente que la use y que la mantenga al día. Saber que Calyx está trabajando en algo y ha terminado otras cosas nos permite asignar otras tareas que ya son posibles o allanar el camino a la que tiene en marcha. Así se toman decisiones más rápidas.
Darian Vorlick: Si Zane decide un día hacer un HUD de interfaz para naves de tipo capital y no está en su lista le decimos que esto está genial, lo metemos en el calendario, pero le conminamos a que haga las tareas que necesite el proyecto en este momento. Respecto al flujo del trabajo y tablas de cálculo: yo soy un hombre Excel. Lo he usado mucho y lo amo.
Eric Kieron Davies: No creo que nunca dejemos de usarlo, porque es una gran herramienta para planear escenarios y situaciones. Puedes mover las cosas con rapidez hasta que tengas todos los datos. Jira necesita datos reales.
Darian Vorlick: Hemos usado también Microsoft Project, Shotgun... todos trabajan simultáneamente en el proyecto a su manera.
