Hay mil y un cosas que pueden condenar a un proyecto al fracaso, pero según Roger Sessions la madre de todos los problemas no es nada más ni nada menos que la complejidad de los proyectos.
En un reporte lanzado hace poco Sessions explica cómo la complejidad del proyecto puede causar retrasos, sobrepasar presupuestos y entregar proyectos que no cumplen con las expectativas de los negocios.
Todas estas fallas según el cuestan -a nivel mundial- USD $500.000 millones al mes, con un margen de error de un 30%, una cifra para nada despreciable considerando el panorama económico que se ha dado últimamente.
La solución de Sessions al problema es particionar el desarrollo del proyecto en diversos subsistemas con metas claras y simples, de esa manera se puede alcanzar una eficiencia muchísimo más alta sin incurrir en más gastos ni comprometer la productividad de la empresa. Para quienes trabajan en áreas de desarrollo de software, ¿Cuál es la causa número uno para que las cosas fallen según ustedes?
[CW]
23 Comment
jajjaja uta que me rei con esa foto, es perfecta para los que estuidan administracion y comercio xd
es verdad la falta de comunicacion hace que las cosas se compliquen inecesariamente.
una vez tuve un jefe que entendio los requerimientos del cliente mal, y yo programe lo que mi jefe me dijo ya que no me quiso explicar la necesidad del cliente.
resulto que despues al final el proyecto se atraso un mes puro cambiando cosas para cumplir las necesidades del cliente
jajaj ke creativo ha sido el ke diseño los dibujos exelente!
Nótese q’ de todos los ingenieros somos los q’ entendemos mejor lo q’ quiere el jefe de proyecto, y hacemos losa arreglos pa’ q’ funcione XP
Es largamente conocido esto por quienes trabajamos en el área de gestión del desarrollo de software. La tendencia ha cambiado ultimamente desde los megaproyectos de arquitectura, UML y desarrollo en paralelo usando RUP y otras al uso de metodologías ágiles como Scrum, que permiten enfocar esfuerzos concretos en equipos pequeños y tener metas concretas a cada momento.
Buena imagen. Retrata demasiado bien el tema.
https://www.veryweb.cl
100% de acuerdo con lo que dice tanto el dibujo como con lo que dice el señor Roger Sessions.
No hay nada más complicado que traducir en código de programación las demandas de un cliente (en mi caso el profesor)
La otra cosa son los jefes , que piensan que todo es una simple query , en mi caso en Bi .
EXCELENTE EL DIBUJO
creo que el principal problema, por lo menos en el desarrollo web dentro de empresas, es un conjunto de cosas, que se pueden reducir a 3 grandes problemas
1ro, la falta de un objetivo conjunto entre los programadores, lideres, diseñadores y cliente
cada uno apunta para su lado… el cliente quiere aumentar ya las visitas, el lider quiere satifacer al cliente, el programador termina emparchando cosas para que salga todo rapido y nadie le da bola cuando solicita tiempo para optimizar y estabilizar… eso es algo que pasa TODOS los dias en mi trabajo
2do, demasiada gente trabajando a las apuradas, y poca gente que controle que esta haciendo la gente
si no se respeta una arquitectura consensuada con anticipacion al inicio del proyecto, luego se vuelve inmantenible, y esto complica el desarrollo de nuevas funcionalidades… nadie controla codigo, solo importa que ande, y por el apuro, muchos terminan haciendo lo que les pinta en el momento, dejando la linea para mas adelante, y algun //TODO: corregir este metodo
3ro, se podria decir que lo anterior es culpa de los desarrolladores por estimar mal los tiempos de trabajo, y es cierto, pero tambien hay que decir que no hay una linea clara a seguir… el cliente cambia repetidas veces de requerimientos, incluso mientras el desarrollo esta en curso… mucho peor aun, si el cliente es parte de la misma compañia en la que uno trabaja (lo que suele llamarse product owner)… esto hace que cada uno termine haciendo lo que entendió, y no le de mucha bola a lo que dice el otro… y termina pasando algo muy similar a lo de la imagen
Hay un viejo principio UNIX, KISS = «Keep It Simple, Stupid» Este princpio representa el estilo de subdividir la solucion a un problema complejo en soluciones especificas para cada uno de los problemas parciales(mas simples). La idea es la misma, y la frase notable, jaja.
Saludos, Felipe.
he visto esa ilustracion un monton de veces en la U y siempre le encuentro la razon a la wea xD
yo diria que lo que hace fracasar los proyecto es la comunicacion entre la gente que lo realiza, pasa con el diseño, pasa con la implementacion, pasa con la seguridad luego de tener el producto listo, etc.
En cuanto al planemiento del proyecto la investigacion de operaciones ha sido una gran herramienta para las empresas despues de la 2da guerra mundial… eso si prodria haber problema con el hecho que en pocas carreras las enseñan, o son pocos los empresarios que las conocen .___.
Para cambios e incertidumbre en los requerimientos … hay nuevas posibilidades como métodos ágiles, iterativos e incremental ….
Para mi, lo necesario para lograr que resulte un proyecto son sus bases es decir todo lo previo al mismo, así como tener claro que es lo que se quiere, hacia donde te diriges, cuales fallas podrían ocurrir y finalmente si es factible.
Yo creo que principalmente fracasan por la subestimacion inicial del costo del proyecto.
El Cliente quiere pagar menos por lo mismo, el proveedor quiere ganarse el proyecto y por tanto debe ajustar sus costos y no pone los recursos, los analistas o programadores (que no son suficientes) se van dando cuenta en el camino de la envergadura a medida que se van metiendo en el tema y llegan a sacrifican horas de QA por programacion, los plazos se alargan y al final el sistema se entrega lleno de bugs, y la confianza se va al traste.
El cliente por todos los problemas de retrasos y bugs no vuelve a trabajar nunca mas con el proveedor y el ciclo se repite con otro.
wn! en la U un profe siempre me msotraba esa wea xD
para los que trabajamos en desarrollo (y estudiamos carreras afines), creo que la principal causa de falla es la falta de comunicacion entre el equipo de analisis y los clientes. una buena determinacion de requerimientos, aunque lleve mucho mas tiempo del que quisieramos, es la base que todo proyecto de desarrollo debe tener. y obviamente, tengo que citar esta frase que tengo pegada en una pared del escritorio, y que sirve de mucha ayuda en esos momentos de estancamiento: «Divide y venceràs». saludos
el dibujo tiene la razon, asi de simple y no solo en el area de programacion tambien en la de proyectos de todo aspecto, ya sea telecomunicaciones a un simple trabajo del colegio
Sí, es verdad, el rpoyecto refleja el capitalismo y el consumismo, más allá de su aparición en los negocios informáticos, pero esta buenísimo!! jajaja
me sumo a los comentarios del dibujo
muy bueno y ade+ muy verdad
aunque no soi programador me ha tocado explicar
un proyecto de programacion en donde es muy dificil
programar lo q realmente uno quiere.
Notable la caricatura! 😀
jajaja hace cuanto que no veia ese dibujito, me saco una sonrisa 😀
concuerdo, dividir el proyecto = paso a paso
A mi me pasa desarrollando los programas para los circuitos que diseño.
El problema es que mi equipo de trabajo es de 1 persona, yo…
en chile por lo menos siempre ha sido asi xD
a los ing informaticos siempre les tocan los ekipos de a 1
al = ke los analistas programadores ._.
XD, la pura y santa verdad.
Está buenísimo el dibujito!!!!