Barrapunto

La complejidad de la implementación de un algoritmo es tema para el analista, quien hará el análisis y diseño, y en algún punto puede que haya ese requisito funcional o no de la velocidad.
Luego el programador se las apañe para obtener dicha complejidad... que existe la implementación... eso menos que tiene que hacer, que no existe... entonces probablemente habrá que involucrar al analista de nuevo por gañán y no conocer las investigaciones existentes en cuando a complejidades en algortimía para la estructura en cuestión (pues qué menos que se documente y al menos proporcione pseudocódigo al programador).

Un buen análisis no requiere de años de programación, y pensar así es un craso error, porque entonces el analista no hace su trabajo, si no piensa en términos de código cuando la realidad es que su nivel de abstracción está por encima del código (a la hora del diseño... más de lo mismo, aunque un nivel de abstracción más cercano al código excluyendo las líneas de código como tales). ¿Ayuda haber codificado previamente a hacer un buen análisis? Sí, pero no es necesario ni tampoco es suficiente :)

Como dice un amigo mio, "only in Spain"...

No se porque me molesto, pero aqui va.

Me estas diciendo que para cada tarea de programacion en una aplicacion quieres tener a un minimo de dos personas involucradas pero no trabajando juntas:
- Uno que no programa pero que tendra que ver el problema, analizarlo, hacer un disenio y posiblemente escribir pseudocodigo para despues pasarselo a otro.

- Este otro, que tendra que ver el problema, analizarlo, comparar su analisis con el disenio que le ha dado la otra persona, revisar el pseudocodigo, seguramente tener una (o mas) reuniones con el analista para aclarar puntos (muchos de los cuales el analista tendra que aclarar con el arquitecto o, en el mejor de los casos, el cliente y en el peor a toda una retahila de mandos intermedios).

Y me estas intentando vender que eso es optimo y es la mejor forma de hacer las cosas. En el mejor caso, segun tu proceso, tienes a un tio que ha dedicado tiempo a entender el problema y despues ha hecho un maravilloso documento explicandole al programador como implementarlo (seguramente tardando mucho mas en escribir ese documento que en solucionar el problema propiamente dicho) y a un programador que no es mas que un mono amaestrado al que le dicen que tecla pulsar y cuando. No te recuerda al juego del "telefono escacharrado"? Porque es la puta definicion.

Te digo como funcionan las empresas de software de verdad? Como funcionan Google, MS y todas estas? Alli no hay analistas ni chorradas de esas, los equipos suelen estar formados por un arquitecto, un jefe de producto (en exclusiva para ese proyecto o con varios al mismo tiempo, que suele ser lo comun), un jefe de proyecto, varios ingenieros senior y varios ingenieros a secas (y tambien varios juniors, de los que se espera poca productividad y cuya responsabilidad principal es aprender para pasar a ser ingenieros).

Cuando el jefe de producto tiene un requisito, un ingeniero (senior o no) lo recoje, lo analiza y lo implementa, discutiendo cualquier duda con el jefe de producto directamente. El jefe de proyecto solo esta ahi para gestionar vacaciones, necesidades del equipo y coordinar a la gente. El arquitecto se preocupa mas de las cosas a grandes rasgos, de definir unas pautas comunes y de ver como encaja esa aplicacion con las demas. Ya esta.
Son los ingenieros (que por cierto es solo un nombre, no tienen porque tener la ingenieria, principalmente porque fuera de espania, la ingenieria informatica es hardware, los de software son ciencias de la computacion) los que hacen todo el trabajo de analisis, disenio e implementacion. Y no conozco a ninguno que no programe, es mas, los que no quieren programar generalmente no llegan a seniors o se dedican a ello solo unos anios, antes de pasarse a gestion de proyectos, a ventas o a educacion (los arquitectos suelen ser seniors con mucha experiencia).

Por supuesto, se que no todas las empresas espaniolas siguen tu modelo, afortunadamente he trabajado en varias que seguian un modelo mas logico (aunque lo de los puestos intermedios es una constante, excepto en empresas tan pequenias que no hay dinero para ellos), y son en esas empresas donde he visto sacar proyectos adelante sin problemas. En las otras, en las que trabajan como tu dices (que tambien he estado ahi: Indra, Accenture...), solo salian proyectos tarde, mal y a saltos, haciendo a la gente currar durante un huevo de horas.

No gracias, prefiero mi modelo.