Sobre mover desarrolladores a otros proyectos

En otro hilo BSHAFTOE decia:

Mi posición es una mezcla de ellas. Esta es mi teoría:

En estos 4 años, Frontier ha tenido según momentos a un porcentaje del equipo original (no voy a atreverme a ponerle un número como si fuera la verdad, pero a efectos de poner un ejemplo, pongamos un que durante algunos momentos el equipo habrá bajado a un 40% o 50% del equipo de desarrollo, repito, no cómo algo real, porque no tengo de donde sacarlo, si no sólo para ilustrar mi teoría).

A veces (cuanto más cerca del release original, más fácil estar en este caso) han tenido a un porcentaje mucho más alto del equipo (90 o 100%), a veces han tenido a menos (cuanto más lejos del release y más cerca de este último año de la Beyond Horizons, más fácil estar en este segundo caso, con sólo un 40 o 50%).

Puede que tal vez haya habido parches o momentos puntuales y concretos que hayan sacado a gente de otros equipos para reforzar el equipo de Elite para uno o dos parches en concreto, y sólo en los últimos meses tras finalizar los otros dos juegos, han empezado a recuperar gente de forma más constante y permanente (poco probable por el overhead que habría entre tener a gente seis meses en un proyecto y otros seis en otro, pero para mi, entra dentro de lo posible aunque no sea probable).

Es decir, ha habido rotaciones, y disminuciones y ampliaciones de vez en cuando en el equipo según las necesidades de la empresa, y no necesariamente pequeña. Esto es práctica común en la industria del desarrollo del software... y lo sabes. Más cuando las tecnologías en los juegos son las mismas, cuando tienes un proceso de producción optimizado y cuando además las fechas de release las marcas tú mismo muchas veces y el juego te sigue dando beneficios.

Dado que durante algunos parches, tenían menos gente, no podían meterse en demasiadas aventuras nuevas, porque les sale mucho más rentable a nivel de productividad explotar los puntos "fuertes" del juego (forja estelar, combate, etc...) que meterse en novedades que son territorio inexplorado. Además, en 2015 y 2016... estás vendiendo el juego bien o muy bien. Desde el punto de vista económico... ¿para qué hacer cambios?. Con el producto que tienes, estás vendiendo bien y teniendo beneficios. Tiene poco sentido meterse en cambios cuya rentabilidad no está del todo clara, porque el juego se sigue vendiendo en ese momento BIEN (si un jugador se va, dado que no paga al mes, te da igual, ya le has vendido juego y expansión, aunque se aburre y se largue, ya volverá cuando saques una expansión de más enjundia dentro de dos o tres años, todos lo hacemos).

De ahí los pocos cambios, y que estuviesen tan centrados en las áreas que digamos, ya eran fuertes o sólidas. De ahí declaraciones de Sandro con el powerplay, viniendo a decir que sólo las nuevas features que tuviesen aceptación amplia seguirían siendo trabajadas en el tiempo. Sencillamente, tenían un poco menos de manpower, sin ganas de probar cosas nuevas, porque desde el punto de vista de ventas (y tú haces el juego para vender), esas cosas nuevas.... no eran necesarias.

Ahora es distinto. Han sacado los otros dos juegos, tienen más manpower disponible, y además aunque todavía no se vea el horizonte del final del juego, obviamente, si se sigue sin hacer cambios sin enjundia, éste se irá acercando (por eso no he participado en el hilo de funeral anticipado del juego que abrió avecandido, porque leches, todavía le queda cuerda a esto... MUCHA, en mi opinión). Conclusión: supondremos que AHORA es cuando probablemente empecemos a ver cosas heavy en materia de cambios.

Esto es mi teoría. Quizás sea errónea, pero es la mía. Me parece demasiada coincidencia que durante cuatro años que no haya cambios profundos en áreas que a mi juicio (y creo que el de muchos) son fundamentales, como comercio minería y exploración, y de repente, unos poquitos meses después de por fin finalizar/lanzar los otros dos proyectos que en teoría no habían detraído manpower de Elite, empiecen a pillar velocidad, y a anunciar cambios MOLONES (porque los cambios de exploración son MOLONES, eso sin discusión por mi parte) en la 3.3 y lo que venga detrás.

Es que además me parece un plan de negocios completamente legítimo. Una compañía como Frontier que además quiera crecer y expandirse NO puede centrarse en un producto como Elite, y tiene que diversificar. Es lógico y normal. Es que es más, yo puedo hasta sonar "indignado" por el tema de las iteraciones de 4 años cuando te contesté antes. Y un poquito lo estoy (porque hubiera deseado estos cambios cuando no tenía un crío y podía jugar horas y horas al Elite, lol). Pero a mi, me dicen que esto es así, que la gente que tenemos es la que tenemos, los proyectos que tenemos son estos, y esto es así 4 años, y lo veo normal (hubiera intentado que dedicasen tiempo a otras cosas más interesantes, pero vaya, al final del final es su decisión). Pero la política de cuasi-no-comunicación de Frontier no ayuda. Están en su derecho obviamente de decir poco y sólo en el último momento, como yo de patalear por ella.

Pero por Dios, aybkamen. No nos hagáis comulgar con ruedas de molino diciendo que no, que bueno, que en realidad sólo hemos esperado por estos cambios un año, cuando llevamos cuatro y que en todo este tiempo no han sacado ni a un alma del equipo de Frontier. El mismo COO explica como esto es algo que hacen, y la salida de Michael Brookes en 2017 es un ejemplo de como la gente rota de proyectos y se les saca de Frontier sin mayor problema. Han rotado y sacado gente (no sabemos cuanta), eso es un hecho, y esto ha tenido su influencia en los tiempos de desarrollo. No pasa nada por admitirlo, es hasta mejor (también a mi me ayudaría a verlo de esta forma que yo sólo pagué 50 o 60 pavos por el LEP, no como beltza y otros, pero en fin...). Muchos no llevamos un año pataleando. Yo tampoco es que lleve 4, porque si revisas mis mensajes en el foro (dudo que lo hagas, pero si alguna vez lo hicieses), yo estaba en tu posición hasta la 2.1 o la 2.2, que fue donde dije "pero esto sigue sin cambiar exploración, minería y comercio, seguimos como estábamos". Pero desde entonces.
 
Primero un poco de contexto sobre mi, porque yo lo valgo.

Tengo experiencia de primera mano sobre como funcionan los movimientos internos de desarrolladores en empresas grandes. Ya sabeis que trabajo (excepto hoy que estoy muy perro) como desarrollador de software en una empresa tecnologica grande en UK(mas grande que Frontier) y, cuando el proyecto al que nos dedicabamos entro en fase de mantenimiento y se empezo el proyecto nuevo, nuestra seccion se fue reduciendo desde unos 100 hasta que eramos 9, y a medida que el otro proyecto se ha ido acabando y se daban cuenta que el nuestro necesitaba mas gente para poder reducir el coste de mantenimiento, hemos ido creciendo de nuevo hasta que nuestra seccion es de unas 30 personas. Asi que claro que existe el movimiento interno de desarrolladores, es logico.

Ahora bien, nuestro descenso de 100 a 9 y ascenso de 9 a 30 ha ocurrido en el transcurso de 5 años, fuimos 9 durante solo 2 meses, hace 2 años. El proyecto nuevo se empezo hace 4 años y medio y se ha acabado hace menos de 1 año. Con esto quiero decir que los movimientos migratorios internos ocurren con calma y de forma planificada.

Lo que niego no es que haya movimientos migratorios dentro de una empresa grande, que los hay, sino que estos se hagan rapidamente para cubrir una necesidad puntual de unos pocos meses. Si se hace un cambio, se hace con mas de un año de planificacion.

Otra cosa que niego es que una plantilla reducida (de 9 personas o de hasta 20) pueda hacer algo mas que soporte vital en un proyecto vivo. Para desarrollar todo lo que se desarrollo en Horizons no basta con un equipo de mantenimiento de soporte vital, de hecho, evaluandolo a posteriori, me parece que 100 desarrolladores tienen que currar bastante para hacer todo eso en 2 años.

La historia del desarrollo de Elite, desde mi punto de vista inventado, pero basado en mi experiencia personal es:

2013-2014 : El equipo crece hasta que logran una fuerza de trabajo considerable (100 desarrolladores?) logran sacar ED en un estado basico sin florituras, aun asi se les va de tiempo las wings, que saldran unos meses despues. Los equipos de trabajo tienes movimiento de gente que se va de la empresa y es reemplazada por otros, juniors o seniors que entran en el equipo. Este flujo de gente que se va y gente que viene seguira durante toda la vida del proyecto porque es lo que ocurre en un mundo laboral donde a un Senior le pagan unas £60000 al año por trabajar programando para la banca en Londres. Se empieza Planet Coaster.

2015: Se continua trabajando en ED para sacar 1.1 - 1.5. Algunos desarrolladores de ED se mueven al nuevo proyecto de Planet Coester. Ya sea porque les interesa mas, porque se necesitan sus conocimientos alli o porque tienen una promocion a un puesto de liderazgo que ya esta ocupado en ED, pero libre en PC. Las vacantes en el equipo de ED se suplen con juniors que ascienden a seniors, seniors que ascienden a puestos de liderazgo o nuevas incorporaciones de juniors y seniors. Se presenta Horizons y se muestra una tecnologia de planetas espectacular para el momento. Se empieza a trabajar en Jurassic World a finales de año.

2016: El impacto de Jurassic World sobre ED es el mismo que el que tuvo PC, gente se mueve pero al final se reemplazan y se sigue desarrollando ED. Se dan cuenta que el enfoque de Horizons en nuevas mecanicas esta heciendo de las mecanicas que han quedado "abandonadas" en su modo mas basico. Powerplay no funciona como se esperaba, la comunidad empieza a tener criticas hacia el desarrollo del juego.

2017: Intentan poner parches menores mientras siguen desarrollando, esto hace que el avance se ralentice. La gente percibe que estan tardando mucho en entregar lo que falta de Horizons. El equipo es igual de grande que siempre pero una parte importante (20 o 30 personas?) estan dedicados a hacer mejoras de "calidad de vida" y a rehacer cosas que no han funcionado como se esperaba. La gente se impacienta. Deciden que a continuacion haran Beyond, enfocandose en avanzar las funcionalidades que han quedado desfasadas y de las que mas se queja la gente (exploracion, mineria, guilds) y otras funcionalidades menores (crimen y castigo, ingenieros 2.0), pero primero tienen que acabar Horizons.

2018: A pesar de que han explicado claramente que en vez de hacer 4 entregas normales haran una fuerte a final de año y algo por enmedio con actualizaciones menores y de emergencia, la gente se impacienta porque no han entregado "nada" y ya es septiembre (perdon, perdon, no lo usare mas). Algunos deciden que como que no estan entregando nada, deben estar bajo minimos de personal y proyectan esta sensacion hacia el pasado, suponiendo que la gente se ha ido a Jurassic World y Planet Coaster, cuando hace 3 años que estan en marcha.

Hoy: Aybkamen esta vago y se dedica a estar de chachara sobre el Elite.
 
Primero un poco de contexto sobre mi, porque yo lo valgo.

Tengo experiencia de primera mano sobre como funcionan los movimientos internos de desarrolladores en empresas grandes. Ya sabeis que trabajo (excepto hoy que estoy muy perro) como desarrollador de software en una empresa tecnologica grande en UK(mas grande que Frontier) y, cuando el proyecto al que nos dedicabamos entro en fase de mantenimiento y se empezo el proyecto nuevo, nuestra seccion se fue reduciendo desde unos 100 hasta que eramos 9, y a medida que el otro proyecto se ha ido acabando y se daban cuenta que el nuestro necesitaba mas gente para poder reducir el coste de mantenimiento, hemos ido creciendo de nuevo hasta que nuestra seccion es de unas 30 personas. Asi que claro que existe el movimiento interno de desarrolladores, es logico.

Ahora bien, nuestro descenso de 100 a 9 y ascenso de 9 a 30 ha ocurrido en el transcurso de 5 años, fuimos 9 durante solo 2 meses, hace 2 años. El proyecto nuevo se empezo hace 4 años y medio y se ha acabado hace menos de 1 año. Con esto quiero decir que los movimientos migratorios internos ocurren con calma y de forma planificada.

Lo que niego no es que haya movimientos migratorios dentro de una empresa grande, que los hay, sino que estos se hagan rapidamente para cubrir una necesidad puntual de unos pocos meses. Si se hace un cambio, se hace con mas de un año de planificacion.

Otra cosa que niego es que una plantilla reducida (de 9 personas o de hasta 20) pueda hacer algo mas que soporte vital en un proyecto vivo. Para desarrollar todo lo que se desarrollo en Horizons no basta con un equipo de mantenimiento de soporte vital, de hecho, evaluandolo a posteriori, me parece que 100 desarrolladores tienen que currar bastante para hacer todo eso en 2 años.

La historia del desarrollo de Elite, desde mi punto de vista inventado, pero basado en mi experiencia personal es:

2013-2014 : El equipo crece hasta que logran una fuerza de trabajo considerable (100 desarrolladores?) logran sacar ED en un estado basico sin florituras, aun asi se les va de tiempo las wings, que saldran unos meses despues. Los equipos de trabajo tienes movimiento de gente que se va de la empresa y es reemplazada por otros, juniors o seniors que entran en el equipo. Este flujo de gente que se va y gente que viene seguira durante toda la vida del proyecto porque es lo que ocurre en un mundo laboral donde a un Senior le pagan unas £60000 al año por trabajar programando para la banca en Londres. Se empieza Planet Coaster.

2015: Se continua trabajando en ED para sacar 1.1 - 1.5. Algunos desarrolladores de ED se mueven al nuevo proyecto de Planet Coester. Ya sea porque les interesa mas, porque se necesitan sus conocimientos alli o porque tienen una promocion a un puesto de liderazgo que ya esta ocupado en ED, pero libre en PC. Las vacantes en el equipo de ED se suplen con juniors que ascienden a seniors, seniors que ascienden a puestos de liderazgo o nuevas incorporaciones de juniors y seniors. Se presenta Horizons y se muestra una tecnologia de planetas espectacular para el momento. Se empieza a trabajar en Jurassic World a finales de año.

2016: El impacto de Jurassic World sobre ED es el mismo que el que tuvo PC, gente se mueve pero al final se reemplazan y se sigue desarrollando ED. Se dan cuenta que el enfoque de Horizons en nuevas mecanicas esta heciendo de las mecanicas que han quedado "abandonadas" en su modo mas basico. Powerplay no funciona como se esperaba, la comunidad empieza a tener criticas hacia el desarrollo del juego.

2017: Intentan poner parches menores mientras siguen desarrollando, esto hace que el avance se ralentice. La gente percibe que estan tardando mucho en entregar lo que falta de Horizons. El equipo es igual de grande que siempre pero una parte importante (20 o 30 personas?) estan dedicados a hacer mejoras de "calidad de vida" y a rehacer cosas que no han funcionado como se esperaba. La gente se impacienta. Deciden que a continuacion haran Beyond, enfocandose en avanzar las funcionalidades que han quedado desfasadas y de las que mas se queja la gente (exploracion, mineria, guilds) y otras funcionalidades menores (crimen y castigo, ingenieros 2.0), pero primero tienen que acabar Horizons.

2018: A pesar de que han explicado claramente que en vez de hacer 4 entregas normales haran una fuerte a final de año y algo por enmedio con actualizaciones menores y de emergencia, la gente se impacienta porque no han entregado "nada" y ya es septiembre (perdon, perdon, no lo usare mas). Algunos deciden que como que no estan entregando nada, deben estar bajo minimos de personal y proyectan esta sensacion hacia el pasado, suponiendo que la gente se ha ido a Jurassic World y Planet Coaster, cuando hace 3 años que estan en marcha.

Hoy: Aybkamen esta vago y se dedica a estar de chachara sobre el Elite.

Te lo puedo comprar, es razonable.

Pero a mi me da la sensación de que en 2016 y 2017 hay un descenso en la cantidad de novedades (no estoy diciendo que sean cero, digo que son menos) y en la complejidad de muchas de las que salen (si comparamos con los mismos parches 1.X) que me parece más adecuado a un descenso de la productividad por pérdida de gente (temporal) que por pérdida de productividad por rotaciones.

En cuanto al inicio, todo de acuerdo. Yo no digo que, salvo quizás casos muy puntuales, haya habido algo del tipo "el desarrollador A trabaja tres meses en PC, tres meses en Elite, tres meses en JP, tres meses en PC, y ahora vuelve a Elite". Pero dentro del timeline que pones es perfectamente posible que saquen a gente a finales de 2016 sabiendo que en 2018 les van a volver a meter en Elite. No a muchos, pero si a unos cuantos.
 
Te lo puedo comprar, es razonable.

Pero a mi me da la sensación de que en 2016 y 2017 hay un descenso en la cantidad de novedades (no estoy diciendo que sean cero, digo que son menos) y en la complejidad de muchas de las que salen (si comparamos con los mismos parches 1.X) que me parece más adecuado a un descenso de la productividad por pérdida de gente (temporal) que por pérdida de productividad por rotaciones.

Si comparas solo las funcionalidades y no los tiempos, Powerplay, Ingenieros, Multicrew, Wings, Cazas, ... todas tienen un tamaño mas o menos similar. Pero poniendo los tiempos, Powerplay vino 3 meses despues del anterior update, y Multicrew 4 meses y medio despues del anterior. Es normal que te parezca que hay un descenso en velocidad porque es evidente que lo hay. En tu caso, tu la achacas a que han perdido gente hacia otros proyectos, yo lo achaco a que han perdido gente que tiene que dedicarse a mantener y parchear cosas que no funcionaban correctamente. Cuando hicieron Powerplay no tenian este problema, cuando hicieron Multicrew si.
Este tener que rehacer o parchear cosas ya hechas para sostener el proyecto es algo con lo que no contaban.

En cuanto al inicio, todo de acuerdo. Yo no digo que, salvo quizás casos muy puntuales, haya habido algo del tipo "el desarrollador A trabaja tres meses en PC, tres meses en Elite, tres meses en JP, tres meses en PC, y ahora vuelve a Elite". Pero dentro del timeline que pones es perfectamente posible que saquen a gente a finales de 2016 sabiendo que en 2018 les van a volver a meter en Elite. No a muchos, pero si a unos cuantos.

Seguro que alguno habra, pero prbablemente se fue de ED como junior casi senior y ha vuelto a ED como jefe de equipo. Me refiero a que los movimientos de yoyo son mas comunes en relacion con promociones y ascensos de categoria que como necesidad de suplir un hueco por cuestiones tecnicas.
 
Y no olvidéis que seguramente buena parte del trabajo haya ido a desarrollar tecnología, lo cual no es perceptible desde el "frontend" pero sí desde el "backend".
Es muy posible que, si han seguido una buena planificación, parte del equipo se haya dedicado a desarrollar sistemas y aplicaciones que a su vez servirán para implementar y desarrollar mejoras futuras. Eso puede percibirse muy fácilmente como un "parón", cuando no es ni mucho menos el caso.
 
Eso también puede ser el caso, Akaradrin. Si es así, lo veremos en los próximos meses, quizás no tanto en la 3.3, pero si con las (por ponerles un número) 4.0 o la 4.1.
 
Aunque para mi lo que dice aybkamen va a misa el 99% de las veces, en este caso estoy con bshaftoe en la opinión (subjetiva y personal) de que ha habido una acusada reducción en el número de componentes del equipo de desarrollo de ED para pasarlos a otros proyectos de la empresa.

Pasar gente de un proyecto a otro tiene un coste, por lo que no se puede hacer alegremente... pero tampoco creo que a un programador de ED le resulte especialmente dificil reconvertirse en programador de Planet Coaster o Jurassic World, porque las herramientas que usan deben ser las mismas, es la misma empresa, con la misma política en gestión de proyectos... Y con un analista o jefe de proyecto debe ocurrir lo mismo.

Aunque ni trabajo en UK ni lo hago en proyectos tan gordos, así que no sé...
 
El equipo inicial y el que hay ahora no es el mismo, casi con seguridad.

Sí, es posible que hayan trasladado a parte del equipo de ED al desarrollo de otros juegos porque ya son experimentados (¿quién no quiere ser el que dirija en vez de ser el currito?), eso sin tener sus reemplazos listos (tan habitual que parece una sorpresa a pesar de estar previsto hace meses, una merma que suplen en un par de meses, pero que genera retrasos) y que las nuevas adquisiciones tengan que aprender a manejar el motor y el lenguaje (todos se parecen, pero, ah, la sintaxis, y eso pues otro par de meses ó más), por si fuera poco, con el equipo experto de "niñeras" de los nuevos.

Y si han ampliado el equipo, que será que sí, pues lo mismo, casi medio año hasta que empiecen a saber realmente lo que tienen entre manos y avancen a un ritmo sostenido. De ahí que ahora, a pesar un equipo brutalmente grande (100 personas... deben de estar desarrollando nuevas mecánicas y, sobre todo, gráficos, así que deben estar trabajando en patas o en descensos atmosféricos, pero esto es especulativo), tardan más en desarrollar el contenido.

Eso sin contar que tienen que probarlo todo y que no se vaya de madre si hay equipo o naves nuevas, que si no va bien o no dan su visto bueno, hay que corregir o cambiar parte de lo hecho (y eso sí que lleva tiempo, porque hacerlo nuevo va bien, pero corregir lo hecho...).

Así que ahora no vemos avances, pero en el futuro irá a buen ritmo... por lo menos hasta que empiecen el desarrollo de otros juegos, que volvemos a lo de siempre.
 
Last edited:
Aunque para mi lo que dice aybkamen va a misa el 99% de las veces, en este caso estoy con bshaftoe en la opinión (subjetiva y personal) de que ha habido una acusada reducción en el número de componentes del equipo de desarrollo de ED para pasarlos a otros proyectos de la empresa.

Pasar gente de un proyecto a otro tiene un coste, por lo que no se puede hacer alegremente... pero tampoco creo que a un programador de ED le resulte especialmente dificil reconvertirse en programador de Planet Coaster o Jurassic World, porque las herramientas que usan deben ser las mismas, es la misma empresa, con la misma política en gestión de proyectos... Y con un analista o jefe de proyecto debe ocurrir lo mismo.

Aunque ni trabajo en UK ni lo hago en proyectos tan gordos, así que no sé...

Vuelvo a comentar sobre mi, porque me molo mucho.

Llevo 5 años en el equipo de ASOPS, con las mismas maquinas y con las mismas aplicaciones, y no pasa un mes que no descubra algo nuevo y que no sabia sobre las maquinas o el software que llevo 5 años manteniendo. Hay trozos de software que nunca he visto, nunca he tenido que trabajar con ello y si tengo que hacer un cambio alli me tiraria unos dias investigando como funciona en profundidad. Por ejemplo el LiftManager que controla las maquinas elevadoras que hay a la salida de las torres de almacenaje. Me supongo como va, pero hay algoritmos que se me escapan como el sistema de ranking para decidir si hacemos single-pick o double-pick, o el funcionamiento del burst mode. Y esto es la aplicacion principal de control que llevo 5 años manteniendo y ampliando, no te digo algunas aplicaciones oscuras, que no hemos tenido que modificar aun y programadas utilizando codigo no muy elegante que tenemos por ahi. Repito, esto es mi area.

El area de Inbound esta en pasillo de al lado, a 3 metros de mi. Forman parte de mi mismo departamento, ellos simplemente se encargan de gestionar otro tipo de areas, con sus propios procesos. A veces he pillado una tarea de modificar algo suyo porque necesitaba ese cambio para una tarea mia y ellos estaban ocupados y ... vamos que somos como hermanos. Si me cambiase a Inbound, tardaria tres meses de ir a medio gas en las tareas que me tocasen mientras descubro las particularidades de su sistema, analizo el porque utilizan una tecnologia distinta para hacer algo similiar a lo que hacemos en nuestro area, y que es exactamente ese proceso que llaman Marshalling. Pero bueno, mas o menos se que cosas hacen y simplemente iria mas lento porque tendria que investigar mas, aprender sus metodos librerias y procesos especificos, adecuarme a sus sistemas de testing, etc.

Si me moviesen al proyecto "nuevo", estaria bastante perdido durante un tiempo. Es arquitectura nueva, algunas cosas se parecen, pero tendria que desaprender algunas para ver los detalles de nuevas formas de hacer lo mismo. Y luego aprender a coordinar a los robots, que es distinto a coordinar elevadores.

Con esto vengo a decir que no me considero tonto, pero a mi me llevaria un tiempo importante de adaptacion el moverme incluso al equipo de al lado. A mis compañeros igual. La empresa lo sabe y por eso no se hacen movimientos a la ligera. Nunca se mueve un monton de gente a un area ya en proceso para evitar que lleguen 5 tipos que no tienen ni idea del proceso, entiendan la mitad y hagan un destrozo en el resto del codigo. Se mueve uno aqui y otro alla, unos meses mas tarde se mueve otro par mas y asi se migra.

Si un grupo ha programado un trozo de software que va a ser util a otro area u otro proyecto... el codigo ya esta hecho, solo hace falta adaptarlo, asi que se les pasa el codigo al otro equipo y como mucho se mueve temporalmente a uno de los expertos en ese codigo para que ayude, entrene y asesore al resto. Mientras el resto de los que desarrollaron ese codigo se dedican a sus tareas o a mejorarlo o a mantener o ampliar el codigo que es tan util.
 
El movimiento de personal entre departamentos no es la única explicación posible.

Representantes de FD han mencionado en más de una ocasión el que tienen posiciones abiertas y no encuentran personal cualificado para llenarlas. La gente va y viene de acuerdo a su propio interés y se mueven de compañía o dejan el trabajo por diversas razones. Si le sumas a eso una aparente falta de de personal cualificado en el área, y un proyecto con metas que sobrestiman lo que el equipo disponible puede completar, terminas con una explicación plausible para las demoras y deslices en la agenda de FD.

Tengan en cuenta que el desarrollo de ED y sus proyector hermanos en el motor "COBRA" envuelve desarrollo novel. No hay un plano escrito y todas las funciones añadidas tienen que ser creadas. En ese tipo de panorama es común el producir un estimado equivocado del flujo de trabajo.

Si no me falla la memoria, la teoría de la "Gran Emigración de Personal" proviene de la mentes creativas de la comunidad. ¿Hay algún tipo de confirmación oficial o evidencia que la apoye?
 
Vuelvo a comentar sobre mi, porque me molo mucho.

Llevo 5 años en el equipo de ASOPS, con las mismas maquinas y con las mismas aplicaciones, y no pasa un mes que no descubra algo nuevo y que no sabia sobre las maquinas o el software que llevo 5 años manteniendo. Hay trozos de software que nunca he visto, nunca he tenido que trabajar con ello y si tengo que hacer un cambio alli me tiraria unos dias investigando como funciona en profundidad. Por ejemplo el LiftManager que controla las maquinas elevadoras que hay a la salida de las torres de almacenaje. Me supongo como va, pero hay algoritmos que se me escapan como el sistema de ranking para decidir si hacemos single-pick o double-pick, o el funcionamiento del burst mode. Y esto es la aplicacion principal de control que llevo 5 años manteniendo y ampliando, no te digo algunas aplicaciones oscuras, que no hemos tenido que modificar aun y programadas utilizando codigo no muy elegante que tenemos por ahi. Repito, esto es mi area.

El area de Inbound esta en pasillo de al lado, a 3 metros de mi. Forman parte de mi mismo departamento, ellos simplemente se encargan de gestionar otro tipo de areas, con sus propios procesos. A veces he pillado una tarea de modificar algo suyo porque necesitaba ese cambio para una tarea mia y ellos estaban ocupados y ... vamos que somos como hermanos. Si me cambiase a Inbound, tardaria tres meses de ir a medio gas en las tareas que me tocasen mientras descubro las particularidades de su sistema, analizo el porque utilizan una tecnologia distinta para hacer algo similiar a lo que hacemos en nuestro area, y que es exactamente ese proceso que llaman Marshalling. Pero bueno, mas o menos se que cosas hacen y simplemente iria mas lento porque tendria que investigar mas, aprender sus metodos librerias y procesos especificos, adecuarme a sus sistemas de testing, etc.

Si me moviesen al proyecto "nuevo", estaria bastante perdido durante un tiempo. Es arquitectura nueva, algunas cosas se parecen, pero tendria que desaprender algunas para ver los detalles de nuevas formas de hacer lo mismo. Y luego aprender a coordinar a los robots, que es distinto a coordinar elevadores.

Con esto vengo a decir que no me considero tonto, pero a mi me llevaria un tiempo importante de adaptacion el moverme incluso al equipo de al lado. A mis compañeros igual. La empresa lo sabe y por eso no se hacen movimientos a la ligera. Nunca se mueve un monton de gente a un area ya en proceso para evitar que lleguen 5 tipos que no tienen ni idea del proceso, entiendan la mitad y hagan un destrozo en el resto del codigo. Se mueve uno aqui y otro alla, unos meses mas tarde se mueve otro par mas y asi se migra.

Si un grupo ha programado un trozo de software que va a ser util a otro area u otro proyecto... el codigo ya esta hecho, solo hace falta adaptarlo, asi que se les pasa el codigo al otro equipo y como mucho se mueve temporalmente a uno de los expertos en ese codigo para que ayude, entrene y asesore al resto. Mientras el resto de los que desarrollaron ese codigo se dedican a sus tareas o a mejorarlo o a mantener o ampliar el codigo que es tan util.

Yo no lo veo así. Parece que en tu caso son programas muy dependientes de cada máquina (ascensor, robot, etc), a muy bajo nivel, desarrollados por personas distintas sin seguir un patrón homogéneo.

Mi caso particular: yo trabajo para una administración autonómica en un departamento muy pequeño donde estamos mi jefe y yo. Justamente estoy a punto de cambiarme a otro sitio, el lunes próximo empiezo. Llevo toda esta semana enseñando lo que llevo a mi sustituta, y son varios proyectos pequeños, muy variados, unos muy simples, otros más complejos. Y me parece que ella se está enterando bien. Quizás le cueste un poco de tiempo llegar a mi nivel, quizás tenga que ayudarla alguna vez, pero en una semana me parece que está medianamente preparada para cambiarse por mi. Y ella viene de otro sitio donde lo que hacía no tenía nada que ver con lo que va a hacer ahora.

Pero mi caso tampoco es comparable a una empresa como FD.

Yo no entiendo de desarrollo de videojuegos pero supongo que una empresa que lo haga no debe ser muy diferente a otra que desarrolle aplicaciones de gestión, al menos en su estructura de equipo.

Imaginemos una empresa llamada "Desarrollos Fronterizos" que se crea en 2012 con el objetivo de desarrollar una aplicación llamada "Marcianos Peligrosos". Los jefes de la empresa eligen un marco de trabajo:
- Lenguaje de programación: Java 1.7
- Herramienta de programación: Eclipse Juno
- Base de Datos: SQL Server 2008

Contratan analistas y programadores, y les forman en el marco de trabajo. Empiezan a desarrollar. Hay analistas funcionales que conocen a fondo los requisitos de la aplicación y les dicen a los programadores qué clases deben programar y el interfaz que deben tener. Cada programador tiene su estilo, unos mejor y otros peor, pero sus clases se testean a fondo con pruebas de caja negra y de vez en cuando se revisan con pruebas de caja blanca para asegurarse que no se salen de las normas de programación impuestas por la empresa.

En 2014 terminan la aplicación y la empresa decide desarrollar otra llamada "Dinosaurios Cabreaos"

No sería lógico que la empresa decidiera cambiarse a .NET y Oracle. Lo normal es que haya una continuidad y el nuevo marco de trabajo sea:
- Lenguaje de programación: Java 1.8
- Herramienta de programación: Eclipse Luna
- Base de Datos: SQL Server 2012

Habrá personal de "Marcianos Peligrosos" que se quede en el proyecto para realizar labores de mantenimiento correctivo y algo de evolutivo, como algunos programadores y, sobre todo, los analistas funcionales que conocen a fondo los requisitos; el conocimiento funcional es lo más valioso y difícil de transmitir, el conocimiento técnico es más fácil de aprender. Y quizás se contrate a más gente. Pero lo normal es que la mayor parte del equipo pase a desarrollar la nueva aplicación. Será necesario darles algo de formación, pero el entorno de trabajo será muy similar al anterior. A los programadores antes les decían que tenían que programar una clase llamada "Nave" con los métodos "disparar" y "aterrizar". Ahora les dirán que programen una clase llamada "Dinosaurio" con los métodos "comer" y "correr"; les costará poco tiempo adaptarse a trabajar en la nueva aplicación "Dinosaurios Cabreaos".

Quizás esto tampoco sea un escenario demasiado realista y lo haya forzado a mi favor, no lo sé, todo esto son suposiciones... y además yo tampoco tengo experiencia en el ejemplo que he puesto.

A mi lo que no me cuadra es lo relativamente poco que han evolucionado ED en estos años, lo que me hace suponer una disminución acusada del grupo de trabajo. Lo cual es lógico, la empresa mueve sus recursos como le conviene, está en su derecho. Quizás hayan estado trabajando a nivel interno, migrando a otra herramienta de desarrollo o depurando el código, pero lo dudo mucho.
 
Saludos:

De verdad alguno ha trabajado como programador, en una de las grandes, Ubisoft, EA, Sony, 505Games, konami, u otras.?
O en Empresas de desarrollo de aplicaciones para Java, Net etc. etc. de forma seria?
Porque algunos post expresan más sobre su experiencia, que no parece ser de programador, si no; de mantenimiento de usuário final.

Nadie conoce que personal a dedicado Frontier a ED, solo ellos y fiarnos de su comunicación. Las variantes son demasiado para la creación de un juego sobre todo si se quiere evolucionar con un motor propio como es el "cobra" exclusivo de Frontier. Sé debe evolucionar el motor gráfico/Inteligencia Artificial y despúess el juego o juegos.
Esto quiere decir que si han previsto a ejemplo, 99 personas en desarrollar Cobra y evolucionárla, tambien puede deducirse que esas 99 a su vez evolucionaban ED aunque no sea aparente, y otros juegos de motor cobra.
 
Saludos:

De verdad alguno ha trabajado como programador, en una de las grandes, Ubisoft, EA, Sony, 505Games, konami, u otras.?
O en Empresas de desarrollo de aplicaciones para Java, Net etc. etc. de forma seria?
Porque algunos post expresan más sobre su experiencia, que no parece ser de programador, si no; de mantenimiento de usuário final.

Nadie conoce que personal a dedicado Frontier a ED, solo ellos y fiarnos de su comunicación. Las variantes son demasiado para la creación de un juego sobre todo si se quiere evolucionar con un motor propio como es el "cobra" exclusivo de Frontier. Sé debe evolucionar el motor gráfico/Inteligencia Artificial y despúess el juego o juegos.
Esto quiere decir que si han previsto a ejemplo, 99 personas en desarrollar Cobra y evolucionárla, tambien puede deducirse que esas 99 a su vez evolucionaban ED aunque no sea aparente, y otros juegos de motor cobra.

completamente de acuerdo, pero opinar es libre, y mas cuando se habla de informática donde el Copy&Paste esta a la orden del día.
 
completamente de acuerdo, pero opinar es libre, y mas cuando se habla de informática donde el Copy&Paste esta a la orden del día.

La libre opinión, es una cosa y comentar es licito y bueno para todo en general, comentar con justificación "laboral", que esta no sea lo justificablemente directa para sentar cátedra", pues opino, que no tanto.
 
¿Cambios entre departamentos? Los hay, pero difiero un poco sobre lo que ha comentado viyakañero: algún compañero de carrera me comentaba que alguna que otra de esas empresas grandes no se preocupaba mucho sobre lo que sabía el programador de turno, te decían "si te preguntan les dices que si" y ya entre unos y otros iban enseñando al nuevo, aunque claro vete tu a saber si Frontier es lo mismo.

Pero si os voy a comentar una cosilla, cuando tu trabajas en un proyecto gordo lo que hoy haces así, mañana lo haces asao. Esta función que te has hecho para esto, dentro de un año ni te acuerdas de que existía. Pasado un año, despliegas una función que hiciste tu mismo, saltas a otra clase, luego a otra, luego vuelves a la primera... y resulta que te has podido tirar media mañana tratando de aveiguar aquella funcionalidad que hiciste en un momento de brillantez porque por más comentarios que le pusieras acabas perdido por la casuística del momento.

Porque una cosa es hacerte una función sencillita, que te digo yo un protocolo de comunicación y otra muy distinta cuando tienes que meter ese protocolo interactuando con eventos y funciones que andan repartidas por cuatro o cinco clases, algunas de las cuales actuando de forma distinta si resulta que esto lo tienes configurado de una manera concreta.

Si no eres el que ha hecho la función sencillita y tienes que modificarla puede llevarte un tiempo ver en que estaba pensando el programador original, como te toque la interactuación... ahí te puedes cagar un ratito... (vamos que lo mismo y acabas antes haciéndolo todo de nuevo)

Y ahora una verdad (eso sí, va con copy/paste):
2018%2B03%2B03.jpg
 
Last edited:
¿Cambios entre departamentos? Los hay, pero difiero un poco sobre lo que ha comentado viyakañero: algún compañero de carrera me comentaba que alguna que otra de esas empresas grandes no se preocupaba mucho sobre lo que sabía el programador de turno, te decían "si te preguntan les dices que si" y ya entre unos y otros iban enseñando al nuevo, aunque claro vete tu a saber si Frontier es lo mismo.

Pero si os voy a comentar una cosilla, cuando tu trabajas en un proyecto gordo lo que hoy haces así, mañana lo haces asao. Esta función que te has hecho para esto, dentro de un año ni te acuerdas de que existía. Pasado un año, despliegas una función que hiciste tu mismo, saltas a otra clase, luego a otra, luego vuelves a la primera... y resulta que te has podido tirar media mañana tratando de aveiguar aquella funcionalidad que hiciste en un momento de brillantez porque por más comentarios que le pusieras acabas perdido por la casuística del momento.

Porque una cosa es hacerte una función sencillita, que te digo yo un protocolo de comunicación y otra muy distinta cuando tienes que meter ese protocolo interactuando con eventos y funciones que andan repartidas por cuatro o cinco clases, algunas de las cuales actuando de forma distinta si resulta que esto lo tienes configurado de una manera concreta.

Si no eres el que ha hecho la función sencillita y tienes que modificarla puede llevarte un tiempo ver en que estaba pensando el programador original, como te toque la interactuación... ahí te puedes cagar un ratito... (vamos que lo mismo y acabas antes haciéndolo todo de nuevo)

Y ahora una verdad (eso sí, va con copy/paste):

Joer... eso nos ha pasado a muchos tal cual cuentas, crear algo y no acordarte ni con los comentarios +rep
 
Saludos:

De verdad alguno ha trabajado como programador, en una de las grandes, Ubisoft, EA, Sony, 505Games, konami, u otras.?
O en Empresas de desarrollo de aplicaciones para Java, Net etc. etc. de forma seria?
Porque algunos post expresan más sobre su experiencia, que no parece ser de programador, si no; de mantenimiento de usuário final.

Nadie conoce que personal a dedicado Frontier a ED, solo ellos y fiarnos de su comunicación. Las variantes son demasiado para la creación de un juego sobre todo si se quiere evolucionar con un motor propio como es el "cobra" exclusivo de Frontier. Sé debe evolucionar el motor gráfico/Inteligencia Artificial y despúess el juego o juegos.
Esto quiere decir que si han previsto a ejemplo, 99 personas en desarrollar Cobra y evolucionárla, tambien puede deducirse que esas 99 a su vez evolucionaban ED aunque no sea aparente, y otros juegos de motor cobra.

Yo trabajo de consultor en Guidewire. O mejor dicho, trabajaba de consultor (customizando el gestor de pólizas para cada cliente, lo que implica desarrollo, desarrollo y desarrollo). Ahora me he movido a un departamento de sustaining engineering (estamos empezando a ofrecer nuestros productos para prestarlos en la nube y como servicio) en el que me encargo junto con mis compis de velar porque el lado de nuestro software en la nube mantiene alta disponibilidad (quicir, que si hay un bug grave en nuestro software a las 3 de la mañana y estoy de guardia, me tengo que levantar y encontrar ALGUNA solución, la que sea), en el que hay menos desarrollo en el sentido de requisitos del cliente, pero más desarrollo de las herramientas genéricas que no haya en el mercado o que no podamos particularizar a nuestro soft, que nos apoyen a realizar nuestro trabajo.

Y lo de aybkamen yo diría que también es desarrollador 100%.

La inmensa mayoría de trabajos de desarrollador hoy día implican contacto con el cliente directa o indirectamente: alguien tiene que decirte lo que quiere para que tú puedas hacerlo.
 
Back
Top Bottom