project management - son - ¿Por qué muchos proyectos de software fallan hoy?
qué puede impedir el éxito de la gestión de su proyecto (26)
(Desde el punto de vista de los programadores, no soy un administrador de proyectos, pero a menudo he estado involucrado en el proceso).
Varias personas han mencionado que los programadores malos son endémicos. Pero creo que esto también es cierto en otro sentido: todos somos malos programadores porque nos resulta difícil anticipar la complejidad, un problema inevitable que los 50 años de estimación mágica y esquemas de planificación no han podido resolver.
Anticipar los efectos secundarios de los grandes proyectos se vuelve exponencialmente más difícil a medida que crecen los proyectos. Esta es una perogrullada obvia, sin dudas, pero para mí significa que en cualquier proyecto en el que he trabajado involucrado en el proceso de estimación me encontré con algún caso en el que haya una consecuencia no anticipada de una decisión de diseño que hace que todo se detenga, o al menos unos días de corrección de errores, algo que nadie previó, ni ningún tipo de negligencia o estupidez. Es solo la naturaleza de un sistema lo suficientemente complejo.
Además de la incertidumbre incorporada, también hay una tendencia a subestimar las cosas cuyo perfil se conoce, porque el hecho de que tienen menos incertidumbre hace que parezcan más simples de implementar.
Así que las cosas inciertas se magnifican, las cosas claras se minimizan, y lo que realmente te mata es lo que no creías que fuera incierto.
Mientras haya proyectos de software, el mundo se pregunta por qué fracasan con tanta frecuencia.
Me gustaría saber si hay una lista o algo equivalente que muestre cuántos proyectos de software fallan hoy. Sería bueno si hubiera una comparación en los últimos 20 a 30 años.
También puede agregar su principal razón por la falla de un proyecto de software. El mío es "Los requisitos son pobres o ni siquiera existen". que incluye también "No (real) cliente / usuario involucrado".
EDITAR: es casi imposible definir claramente el término "falla". Digamos que el fracaso significa: el proyecto fue más del 10% por encima del presupuesto y el tiempo. En mi opinión, el 10% + / - es un buen rango para una oferta / oferta.
EDITAR: Hasta ahora (11 de febrero) parece que la mayoría de los carteles coinciden en que el fracaso del proyecto es básicamente una falla de la gestión del proyecto (lo que sea que falle). Pero en mi humilde opinión, sale a la luz que la mayoría de los desarrolladores no están contentos con esta situación. ¿Tal vez porque no se penaliza al gerente cuando un proyecto no tuvo éxito, sino a los equipos de desarrolladores perezosos e incompetentes?
Cuando leo las publicaciones también puedo escuchar que hay una gran "brecha" entre el lado desarrollador y el lado de gestión. Las expectativas (quizás también los requisitos) parecen ser tan diferentes, que un proyecto no puede tener éxito al final (en el tiempo / presupuesto, los usuarios no están contentos, no todas las características del primer prio implementadas, demasiados errores porque los desarrolladores se vieron obligados a implementar en plazos demasiado cortos ...)
Me pregunto: ¿cómo podemos mejorarlo? ¿O tenemos la posibilidad de mejorarlo? Todos parecen estar insatisfechos con la forma en que sucede ahora. ¿Podemos cerrar la brecha entre estos dos mundos? ¿Deberíamos nosotros (los desarrolladores) entrar en huelga y luchar por "requisitos de alta calidad" y "plazos de tiempo basados en realismo / iteración"?
EDITAR: Ralph Westphal y Stefan Lieser han fundado una nueva "comunidad" llamada: Clean-Code-Developer . El objetivo del grupo es incorporar más profesionalismo a la ingeniería de software. Independientemente si un desarrollador tiene un grado o toneladas de años de experiencia, puede ser parte de este movimiento.
Los desarrolladores de Clean Code viven principios como SOLID todos los días. Un desarrollador profesional es el mayor crítico de su propio trabajo. Y tiene un sistema interno de valores que lo ayuda a mejorar y mejorar.
Compruébelo en: desarrollador de código limpio
EDITAR: Nuestra compañía está actualmente haciendo algo llamado "Benchmarking de desarrollo y mantenimiento de aplicaciones". Este es un servicio ofrecido por IBM para obtener retroalimentación de alguien externo sobre la calidad de su proceso de ingeniería de software, etc. Cuando obtengamos los resultados, le diremos más al respecto.
Honestamente, creo que es porque la mayoría de los programadores no son muy buenos en lo que hacen (y no me refiero solo a generar código). La gente en es probablemente la excepción. No sé sobre el resto de ustedes, pero como consultor / programador de contratos he trabajado en muchos lugares, y la proporción de programadores mediocres o pobres a buenos es de aproximadamente 10 a 1.
Una de mis fortalezas siempre ha sido la de estimar con precisión y luego entregar a tiempo, dentro del presupuesto o por debajo del presupuesto. Siempre aspiro a recibir un 10% de descuento en costos y tiempo. Entonces me gustaría decirle a mi cliente que porque hice cosas por menos $$ de lo esperado, ¿cuál de los "extras" le gustaría agregar?
Incluso un producto que funciona perfectamente y que está retrasado y / o por encima del presupuesto será considerado como un fracaso por muchos gerentes comerciales. Los programadores suelen centrarse solo en los aspectos técnicos de lo que hacen, sin tener en cuenta el costo o el plazo. Realmente necesita hacer las tres cosas bien para que se considere un proyecto exitoso. Hay muchos otros programadores que podrían codificar los círculos a mi alrededor sin lugar a dudas, pero para la persona que paga el proyecto, eso rara vez es suficiente.
La última estadística que escuché fue que el 90% de los proyectos están en el tiempo o por encima del presupuesto. Entonces, si considera que falla, renuncie un poco.
La razón por la que falla principalmente se basa en el proceso. Nosotros, como ingenieros de software, no hacemos un buen trabajo para reunir los requisitos y controlar al cliente. Debido a que la creación de software es un trabajo "misterioso" para las personas ajenas a TI, les resulta difícil comprender por qué los cambios de última hora son difíciles. No es como construir una casa y mostrarles claramente por qué no es posible agregar rápidamente otra puerta a la parte posterior de la casa hecha de ladrillo.
La razón número uno: una falla en la gestión del proyecto .
La razón de ser de un PM es hacer que un proyecto tenga éxito, por lo que un fracaso del proyecto es su fracaso. Ciertamente hay factores que escapan a su control, pero todavía está dentro de la descripción del trabajo del PM manejar ese riesgo, y las únicas cláusulas de salida deberían ser alguien más arriba en la cadena alimenticia tomando el control de decisión (lo cual es algo terrible para un PM) o actos de dios
En mi experiencia, las fallas ocurren mayormente cuando el trabajo de MP ha sido rápido y suelto o inexistente, incluso cuando las decisiones comienzan a fluir de los vendedores y cuando el cliente comienza a decretar el control de cambios. Un buen PM no tiene precio .
Las personas / empresas no gritan con orgullo sobre sus fallas, por lo que muchos casos nunca serán escuchados.
Mala administración.
El proyecto SW se inicia lanzando desarrolladores contra un problema percibido. Los requisitos del negocio cristalizan a medida que avanza el proyecto. Se agrega nueva funcionalidad mientras los plazos se mantienen. Se agregan más desarrolladores. Los miembros originales del proyecto renuncian o son despedidos. En este punto, se invierte demasiado tiempo, dinero y recursos en el proyecto, por lo que no se puede cancelar. A medida que transcurre el plazo, el proyecto se declara terminado y exitoso a pesar de la obvia falta de producto terminado.
Ahora que lo pienso, tengo que volar para ver que un proyecto SW falla ...
Mala gestión.
Los proyectos no son éxitos o fracasos basados en alguna característica subyacente del proyecto, sino en si satisfacen las necesidades de los usuarios. (Pueden fallar por completo, en cuyo caso hubo una gran declaración errónea de lo que era posible). Se encuentra principalmente en el proceso de evaluar la factibilidad y la relación costo-beneficio del proyecto, y establecer objetivos, que los proyectos de software tienden a fallar o tener éxito.
Existe una desconexión entre personas que se ocupan de hechos y cosas (como programadores) y personas que tratan con otras personas (como tipos de ventas y gerentes). Para un programador, los hechos son los hechos y deben ser tratados. Para una persona de ventas, los hechos son lo que otras personas piensan, y son modificables.
También hay diferencias entre hechos tangibles e intangibles. Nadie piensa que los trabajadores podrían construir un puente grande en un mes si realmente estaban motivados; pueden ver todo el acero y el hormigón y otras cosas que deben moverse y fijarse en su lugar. El software es mucho menos tangible y carece de restricciones físicas: si bien no es teóricamente posible construir el puente dentro de un mes, es concebible que un equipo pueda crear un gran proyecto en un mes, ya que "todo" lo que tienen que hacer es hacer todo bien la primera vez. Es físicamente posible escribir miles de líneas de código al día; es solo que la posibilidad de que se puedan utilizar como están es tan cercana a cero que no importa. La productividad real de un desarrollador superior es en realidad muy poco impresionante en el conteo de palabras, en comparación con (digamos) la productividad de un periodista.
Por lo tanto, aquellos que están acostumbrados a los hechos flexibles no tienen los límites físicos imponentes para recordarles que las cosas solo se pueden impulsar hasta ahora, no aprecian lo que la programación realmente requiere, y no tienen buena idea de cuánta productividad es realmente posible. Además, saben cómo abrirse camino en las negociaciones, mucho más que el desarrollador promedio, por lo que en las negociaciones sobre lo que es posible, tienden a asumir más de lo que pueden, en el mundo real, obtener.
Mientras tanto, el desarrollo de software es inherentemente difuso, porque producir el producto físico es trivial. Puedo producir una copia de software de forma rápida y económica, una vez que se ha desarrollado. El desarrollo de software es un trabajo de diseño, puro y simple. Todo lo que corresponde a la fabricación se elimina sin piedad con cosas como compiladores y asistentes y generación de código. El desarrollador, enfrentado con el gerente que quiere lo imposible, encuentra difícil decir que lo imposible es realmente imposible, porque no hay forma de decir que es realmente imposible. Dado los hechos que son lo suficientemente desconocidos como para sentirse flexible, la persona con fuertes habilidades de negociación y determinación generalmente obtendrá la respuesta que él o ella desea.
Dada esta desconexión, uno podría preguntarse de quién es la responsabilidad de salvarlo. La respuesta es, en mi opinión, clara. La responsabilidad de entender cómo piensan las diferentes personas pertenece a las personas que se especializan en tratar con otras personas. La responsabilidad de coordinar diferentes tipos de personas pertenece a las personas cuyo trabajo es coordinar estas cosas. Por lo tanto, gerentes.
Los gerentes que sí entienden el desarrollo de software y los desarrolladores, y que pueden tratar bien con otros gerentes, lo harán bien, y sus proyectos generalmente tendrán éxito. Todavía hay demasiados del otro tipo en el mundo.
No es una respuesta directa, pero encontré el archivo de caso virtual como un estudio de caso fascinante sobre cómo un gran proyecto respaldado por el gobierno y bien financiado todavía puede ser un tanque.
También puede agregar su principal razón por la falla de un proyecto de software.
Otro artículo de IEEE Spectrum Online " Why Software Fails " examina esta misma pregunta. Resume los principales puntos de la siguiente manera:
- Metas del proyecto poco realistas o no articuladas
- Estimaciones inexactas de los recursos necesarios
- Requisitos del sistema mal definidos
- Mala información del estado del proyecto
- Riesgos no administrados
- Mala comunicación entre clientes, desarrolladores y usuarios
- Uso de tecnología inmadura
- Incapacidad para manejar la complejidad del proyecto
- Prácticas de desarrollo descuidado
- Mala gestión de proyectos
- Política de los interesados
- Presiones comerciales
No solo los proyectos de software superan el presupuesto, o toman más tiempo de lo programado para completarse. Simplemente abre el periódico y mira proyectos públicos como puentes.
Pero para un proyecto de software es mucho más fácil cancelar todo. Si un puente o edificio está a medio terminar, no hay camino de regreso. La mitad de la infraestructura está en su lugar. Es muy visible y se necesita dinero para eliminarlo.
Para un proyecto de software puede presionar Shift-Delete y nadie lo nota.
Es simplemente un trabajo muy difícil hacer un análisis de costos preciso.
Un error común es que los vendedores y los técnicos no se comunican lo suficiente. Entonces los vendedores venden cosas que técnicamente no son factibles dentro del presupuesto. (Y luego corren con su bonificación :))
Usar el sistema de archivo de caso virtual del FBI se reduce a una gestión de programa deficiente. El programa tenía requisitos previos al 11 de septiembre y expectativas posteriores al 11 de septiembre. Si la administración del gobierno hubiera hecho su trabajo, habría habido modificaciones contractuales.
http://government.zdnet.com/?p=2518
"Debido a un contrato abierto con pocas garantías, SAIC cosechó más de $ 100 millones a medida que el proyecto se hizo más grande y complicado, aunque su software nunca funcionó correctamente. La compañía siguió cumpliendo con las solicitudes de la oficina, aceptando pagos a pesar de señales claras El enfoque del FBI para el proyecto fue muy defectuoso, de acuerdo con las personas que participaron en el proyecto o más tarde lo revisaron para el gobierno ".
Aunque $ 105,000,000 para 700,000 líneas de código llegan a $ 150 por línea de código. No está mal.
Uso deficiente de prácticas y métodos de desarrollo de software. En mi experiencia, una de las grandes razones por las que un proyecto falló es que el equipo de desarrollo utiliza un método incorrecto para enfrentar el proceso de desarrollo de software. Elegir una metodología sin tener una buena comprensión de cómo funciona y lo que se necesita, puede traerle problemas a un proyecto, como una planificación deficiente.
También un problema común es también el uso de tecnologías sin una evaluación previa del mismo para comprender cómo se puede aplicar y si aporta algún valor al proyecto.
Siempre lleva más tiempo del que espera, incluso cuando toma en cuenta la Ley de Hofstadter.
Planificación deficiente.
Es porque nadie parece leer más. Cada razón por la cual los proyectos fallan ha sido analizada una y otra vez. Solo tiene que leer tres libros para saber por qué el 80% de los proyectos fracasan:
La fecha límite: una novela sobre la gestión de proyectos (Tom Demarco, publicada en 1997). Es una gran introducción y es bastante entretenida. Peopleware: Proyectos Productivos y Equipos (Tom Demarco, publicado en 1987) The Mythical Man-Month: Ensayos sobre Ingeniería de Software (Fred Brooks, publicado en 1975)
Nosotros, como profesión, simplemente olvidamos todo cada 3-5 años (ver "la informática centralizada es ineficiente, deje que los clientes la manejen" frente a la computación en la nube).
¡El enlace de Construx arriba es realmente bueno!
Muchos proyectos se gestionan con una imagen optimista de la realidad. Los gerentes tienden a impulsar a los desarrolladores de conversaciones en estimaciones optimistas. Pero dicen que un proyecto de 20 semanas se "minimiza" a 10 semanas. La fase de requisitos ahora será de 1 semana en lugar de 2. Después de 1 semana, los requisitos no están terminados, pero el proyecto continúa. Ahora estás trabajando en terreno inestable ... ¡y en un horario estirado!
Esto puede ser divertido. Una vez hubo un viejo en una habitación frente a la mía. Su título de trabajo era administrador de sistemas. Pero el sistema que se suponía que debía administrar no estaba allí. Nunca se había terminado, aunque la gerencia pensó que había sido así. El tipo jugó durante aproximadamente un año antes de aburrirse y seguir adelante.
La parte más divertida? ¡La gerencia colocó una nueva oferta de trabajo después de que él se fuera!
Como se mencionó anteriormente, la gran mayoría de las personas involucradas en el desarrollo de software no entiende realmente cómo
- haga las preguntas correctas para conocer el problema
- apreciar el objetivo de los usuarios y juzgar las expectativas
- comprender la tecnología disponible y la estructura ecológica relacionada
- la mayor parte del equipo involucrado directa / indirectamente es poco hábil.
- no apreciar o saber cuando están equivocados, pueden tomar medidas.
Incluso con requisitos perfectos y definiciones relacionadas, demasiados desarrolladores no saben lo que están haciendo.
Solo mira los tipos de preguntas que se hacen aquí. ¿Va a ir a un médico que hizo la misma pregunta equivalente? Lo espantoso es que preguntan y no saben cómo aprender o razonar.
El fracaso es un juicio, más una acusación, realmente.
"El proyecto fue más del 10% por encima del presupuesto y el tiempo".
¿Qué presupuesto? ¿Qué horario?
Hace 6 meses, escribí un plan diciendo que tomaría 6 meses.
Hace 3 meses, los usuarios pidieron más cosas. Les di un plan que decía que tomaría 9 meses más.
El mes pasado me dijeron que el proyecto tenía un presupuesto de 6 meses y, por lo tanto, un "fracaso".
Pero espera. Entregó lo que los usuarios querían. Fue por encima de la estimación "original". Estuvo bajo la estimación revisada. Los usuarios quieren más. TI quiere menos.
Lo abordaré desde un aspecto diferente que la mayoría del resto aquí.
Me he dado cuenta de que un proyecto falla lentamente durante un período de tiempo. Claro, ha mejorado en ese momento también, pero aún no es rentable. En esta rentabilidad del mercado, y estar en el negro, significa el éxito.
¿Por qué está fallando? Creo que es simple: obtienes lo que pagas.
El software es como una cuenta bancaria, no un cieno primordial. Si no le pones recursos (tiempo, dinero, concentración, esfuerzo), entonces no obtendrás nada, excepto el fracaso y el costo. Así que debes invertir cosas en tu proyecto, y algunas veces el trabajo más temprano prepara el escenario para los próximos años. No puedes tirar lodo en tu computadora y esperar un nuevo mouse en dos años y $ 10 millones más tarde, por lo que igualmente debe haber un esfuerzo invertido.
Uno de los mayores problemas hoy en día son los "desarrolladores de presupuesto" en un país del tercer mundo. No les envidio su parte del mercado, pero que una startup bien financiada de Silicon Valley los busque y obtenga una base presupuestaria (marco o incluso prototipo) es hacer una inversión deficiente en el futuro. Este mismo marco presupuestario es lo que está causando a mis amigos una gran molestia hoy en día. Ahora funciona; funcionó cuando se escribió, pero no estaba bien escrito y pocos incluso se toman el tiempo para mantenerlo. Si la empresa se detuviera y reescribiera el software de la forma en que debería haberse escrito, en primer lugar no tendrían tantos problemas. Pueden ellos darse el tiempo? Nop. Tienen que hacer que sea rentable antes de que puedan siquiera pensar en eso.
Como dice el refrán, "puedo hacerlo: barato, rápido o bueno. Ahora, escoja dos de esos". Todos quieren los tres, yo incluido. Pero si no invierte el tiempo, la planificación y el trabajo necesarios para que su proyecto sea un éxito desde el principio ... entonces no espere nada de lo que pueda sentirse orgulloso más adelante. Se sentirá como una Mona Lisa forjada donde usted, y cualquier otro ingeniero como usted, puede ver un defecto aquí y allá que no debería haber estado allí desde el principio.
Asi que:
- No haga lo que no puede pagar: tiempo, dinero, esfuerzo, concentración, etc.
- ¡No te saltes la planificación!
- No tenga miedo de reescribir temprano cuando más cuenta. (Más tarde será peor que un viaje al dentista, créanme).
- No subestime el poder de la burocracia para evitar que lo haga bien.
- Y no seas barato donde deberías pasar la mayor parte de tu tiempo. Te costará más tarde, garantizado. Y si no es usted, entonces alguien más tomará la bala por usted.
Para evaluar realmente si un proyecto es realmente exitoso, la estimación / presupuesto original es probablemente un criterio deficiente. La mayoría de los ingenieros tienden a subestimar cuánto tiempo tomará debido a la presión política, y no saben cómo calcular de todos modos. Muchos gerentes son planificadores pobres porque quieren plazos poco realistas para complacer a su jefe, a menudo no entienden lo que está involucrado, y además es algo que pueden ver, entender y utilizar como un palo en las reuniones, en lugar de ayudar a resolver problemas. Prácticamente, ayuda a las empresas a realizar proyecciones de gastos aproximadas con fines presupuestarios, al menos les da algo por lo que pasar.
Una mejor medida del éxito del proyecto sería: ¿están contentos los usuarios? ¿Ayuda a la empresa a ganar dinero? ¿Qué tan rápido ganará el dinero para recuperar el costo del sistema? Sin embargo, estos son más difíciles de medir que un plan simple.
Al final, me parece que es mejor cumplir el plazo, incluso si eso significa trabajar algunas horas extras. Apesta, pero esa es la realidad.
Se han realizado algunos buenos estudios sobre esto. Recomiendo este enlace del sitio web de Construx (compañía Steve McConnells).
Diferentes agendas
La gerencia realmente no entiende lo que hace un desarrollador, cómo producen el código y las dificultades encontradas. Lo único que les importa es que el producto final se entregue a tiempo. Pero a un desarrollador le importan los aspectos técnicos, el código bien producido en una solución de la que están orgullosos.
Plazos
A menudo escuché a los desarrolladores decir que desearían poder producir un mejor código, y que los plazos a menudo los empujan a producir algo que simplemente funciona, en lugar de un buen código. Cuando estos plazos no son realistas, los problemas se agravan.
IT Project Failures es un blog sobre fallas de proyectos que puede tener algunas respuestas aquí si uno quiere leer sobre él.
Yo creo que una gran parte de esto tiene que ver con la cuestión de poder decir exactamente lo que se espera en x meses a $ y cuando realmente la respuesta es mucho más abierta. Por ejemplo, si una empresa está reemplazando un sistema ERP o CRM, existe una buena posibilidad de que uno no vaya a cumplir con todos los requisitos y, por lo tanto, habrá algunos cambios, correcciones de errores y extras que surjan de asumir tales un gran proyecto Para una analogía, considere cuántos estudiantes que ingresan a la escuela secundaria o la universidad podrían establecer su horario preciso durante los 4 años sin tomar ninguna clase y, de hecho, seguir con eso al final. Supongo que serían muy pocos los que cambian de tema, ya que algunas personas cambian las asignaturas o los cursos que querían tomar no se ofrecen o suceden otras cosas que cambian el resultado esperado, pero ¿cómo se refleja esto en un plan de proyecto que comenzamos aquí y mientras pensamos que íbamos allí, terminamos en el lugar número tres.
Mi respuesta es bastante inusual por el resto de esto, pero bastante común aquí: insectos asesinos. Tuve un proyecto de dos semanas extra (50% de tiempo extra) debido a un cambio en la fuente que no conocía hasta que exploré el código fuente (no había nada documentado en la ayuda ni en la web).
Ser superior al presupuesto y al tiempo no es una buena definición de fracaso (y estar dentro del presupuesto y el tiempo no siempre significa éxito). Tome los siguientes ejemplos proporcionados por Hugh Woodward, PMP, en Gestión de proyectos expertos - Éxito del proyecto: Mirando más allá de las métricas del proyecto tradicional :
Sydney Opera House : con sus gráciles velas dominando el puerto de Sydney, la Opera House de Sydney es posiblemente uno de los edificios más reconocidos en el mundo. Sin embargo, desde una perspectiva de gestión de proyectos, fue un fracaso espectacular. Cuando la construcción comenzó en 1959, se estimó que costaría $ 7 millones y tardará cuatro años en construirse. Finalmente se completó en 1973 por más de $ 100 millones.
[...]
Proyecto Orion : este esfuerzo masivo para desarrollar el nuevo sistema fotográfico Advantix de Kodak estaba muy bien administrado desde una perspectiva de administración de proyectos. PMI lo reconoció como el Proyecto Internacional del Año 1997, y Business Week seleccionó el sistema como uno de los mejores productos nuevos de 1996 (Adams, 1998). Pero el precio de las acciones de Kodak ha caído un 67% desde la introducción del sistema Advantix, en parte porque no pudo anticipar el cambio acelerado a la fotografía digital.
Intranet corporativa : Finch describe un proyecto que implicó la implementación de una intranet corporativa para globalizar y mejorar las comunicaciones. Desde una perspectiva de proyecto tradicional, no cumplió con sus criterios de éxito, pero no de manera significativa. Llegó un mes tarde y se cree que se logró con un pequeño sobrepaso de presupuesto. Pero tanto el gerente de proyecto como la gerencia senior vieron el proyecto como exitoso. El hardware y el software se instalaron con éxito con un mínimo de interrupciones, lo que permitió que todos los miembros del personal tuvieran acceso a la intranet corporativa. Sin embargo, después de la implementación, los empleados hicieron un uso limitado de las instalaciones de la intranet. El principal objetivo del proyecto, por lo tanto, no se logró. En este caso, tanto el gerente del proyecto como la alta gerencia se enfocaron en un objetivo que era demasiado estrecho.
[...]
Optimización de la planta de manufactura : una compañía de fabricación de papel con cinco plantas en América del Norte decidió aumentar su capacidad de fabricación al embarcarse en un programa de eliminación de embotellamientos. Se formó un equipo de proyecto para instalar el equipo necesario y se le encargó completar el trabajo en 18 meses a un costo de $ 26 millones. Pero casi de inmediato, se le pidió al equipo del proyecto diferir los gastos importantes hasta que se resolvió un problema de flujo de efectivo no relacionado. En lugar de dejar de trabajar por completo, el equipo adoptó una estrategia de creación de prototipos de las tecnologías en las que se basó el programa de eliminación de embotellamientos, y en realidad desarrolló algunas soluciones más económicas y efectivas. Incluso cuando el proyecto fue autorizado para continuar, el equipo continuó con este mismo enfoque. El proyecto eventualmente abarcó cinco años, pero el aumento de la capacidad resultante fue tres veces el compromiso inicial. Como era de esperar, la compañía se apropió de otros $ 40 millones para continuar con el programa.
[...]
Entonces en estos ejemplos, ¿cuáles fueron realmente exitosos? Ejemplos como los Juegos Olímpicos de Invierno de 2002 y el concentrador de cobre Batu Hijau sugerirían que son verdaderamente exitosos porque no solo cumplieron con la definición de éxito de los gerentes de proyectos tradicionales, sino que también cumplieron con la percepción de éxito de los patrocinadores de los proyectos.
A medida que comenzamos a ver ejemplos como Project Orion, la Intranet corporativa y la actualización de computadora portátil, notamos que las métricas tradicionales comienzan a fallar. Estos proyectos se consideran éxitos en la definición de éxito de los gerentes de proyecto, pero no cumplieron con los criterios de éxito de los patrocinadores. El ejemplo del proyecto Orion es bastante sorprendente ya que este proyecto fue reconocido por PMI (Project Management International) en 1997 como el proyecto internacional del año. Sin embargo, no aumentó los ingresos de Kodak, ya que no previeron la adopción de cámaras digitales.
Los más interesantes son los ejemplos de la Optimización de la Planta de Fabricación y la Casa de la Ópera de Sydney. Ambos no lograron cumplir con las métricas de éxito de los gerentes de proyectos tradicionales, pero de hecho se consideraron exitosos. Esto es particularmente impactante cuando se ve que el Sydney Opera House tuvo un "costo excesivo de 1300%" y un "exceso de programación de 250%".
Una vez que nos damos cuenta de que los proyectos pueden no cumplir con las métricas tradicionales de éxito, pero aún así ser exitosos para las partes interesadas, esto crea un dilema para el gerente del proyecto. ¿Cómo se define realmente el éxito? ¿Es posible que se cancele un proyecto "Desafiado" que habría satisfecho las necesidades de los patrocinadores? ¿También es posible identificar un proyecto que debe cancelarse que está actualmente a tiempo, dentro del presupuesto y satisfaciendo las necesidades definidas?
¿Qué piensas de esa conclusión? ¿Cómo realmente defines el éxito?
Creo que este hilo logró reunir al mayor grupo de desarrolladores de software insatisfechos, ingenieros, gerentes de proyectos, etc. que es posible reunir en un solo lugar.
Comparto el punto de vista con la mayoría de los mensajes trabados aquí y creo que salen de un gran sufrimiento al ver a los compañeros de trabajo que no hacen un buen trabajo cuando el trabajo (programación) y el éxito es la parte más importante de nuestras vidas.
http://www.clean-code-developer.de/ ¡ Tienen una causa increíble! y su filosofía, si se lleva adelante, podría lograr crear una nueva capa de héroes, ya que la corriente principal de desarrolladores y profesionales de TI está muy rota hoy en día.
Estoy trabajando en algo similar aquí en Brasil, porque me encanta nuestra profesión de ofrecer software tanto como PM y desarrollador de software (.NET) y no soporto a las personas que se enfrentan a la programación como a nada más que a salir a hacer mucho dinero sin apenas esfuerzo.
... claro que no considero pasar la noche frente a la genialidad de la computadora. pero los pocos que importan lo han hecho más de una vez.