Desarrollo de software. ¿Qué es un proyecto?
Algo que no termina nunca, dirán algunos.
Y no es así, más bien, no debería ser así. Vamos a analizarlo.
Un proyecto es un conjunto de actividades planificadas en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.
Definiciones, hay muchas, la anterior puede una de ellas.
Un proyecto, por tanto y por definición, debe ser finito. ¿Por qué digo entonces que es algo que no termina nunca?
Para empezar es importante distinguir el rol que desempeña cada cual en los trabajos. Si tu rol es el de proveedor, el proyecto termina cuando se alcanzan los objetivos por lo que te han pagado y una vez finalizada la garantía establecida (esto puede ser más o menos tormentoso, llevar más o menos tiempo, pero los proyectos, terminan), si tu rol es el de responsable técnico del cliente no está tan claro cuando terminas, si es que terminas, ya que un defecto importante para este tipo de desarrolladores es que la explotación del sistema de información y su mantenimiento forman una frontera, en ocasiones, poco definida (generalmente por una mala definición de los procesos de los departamentos TIC), por lo que no se termina de pasar página y esto sucede, tanto si se encadenan proyectos como si no. Eres responsable técnico del sistema y lo serás hasta que el ciclo de vida del mismo se cumpla.
El problema de que la vinculación al sistema de información sea esa es que, conforme vaya pasando el tiempo, cada vez serán más proyectos y sistemas con los que trabajes y la montaña se hace cada vez más grande, tanto que la gestión termina siendo insoportable porque habrá sistemas de información que durante un tiempo no den problemas, pero al final siempre aparecerá algo que origina un trabajo.
Cuando se gestionan muchos sistemas, la suma de elementos aislados forman una sucesión interminable de tareas, que afectan a los proyectos reales en los que estás trabajando en ese momento, mermando la calidad de las actividades que realizas en el mismo.
Pingback: Desarrollo de software. Timothy R. Lister. Gestión del riesgo. Su evolución en el proyecto « Jummp
Pingback: Desarrollo de software. P. J. Plauger. Del primer proyecto a la mejora continua « Jummp
Pingback: ¿Qué es el ciclo de vida del software? « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Las pérdidas de tiempo « Jummp
Pingback: Desarrollo de software. Compartir objetivos « Jummp
Pingback: Desarrollo de software. El analista funcional y el analista orgánico « Jummp
Pingback: Desarrollo de software. Cierre del proyecto « Jummp
Pingback: Desarrollo de software. Ciclo de vida RUP (Rational Unified Process) « Jummp
Pingback: Desarrollo de software. Sun Tzu. Toda guerra se basa en el engaño « Jummp
Pingback: Desarrollo de software. Cuando las personas no pueden suplir los procesos « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. La planificación « Jummp
Pingback: Desarrollo de software. La mejora contínua y el feedback « Jummp
Pingback: Plan de sistemas de información II « Jummp
Pingback: Desarrollo de software. La confianza « Jummp
Pingback: Desarrollo de software. Sun Tzu. Guerra, proyectos, factores similares para conseguir la victoria « Jummp
Pingback: Desarrollo de software. Crisis, problemas, asumir decisiones, mirar adelante « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. El precio de la calidad del software « Jummp
Pingback: Desarrollo de software. Sun Tzu. Gestión inicial del riesgo, condiciones iniciales para el desarrollo « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: Desarrollo de software. Sun Tzu. La importancia de ir liberando versiones operativas cuanto antes « Jummp
Pingback: Desarrollo de software. Sun Tzu. Buenas condiciones de partida « Jummp
Pingback: Desarrollo de software. Desequilibrio entre stakeholders « Jummp
Pingback: Desarrollo de software. Sun Tzu. Saber cómo enfocar un proyecto no asegura el éxito « Jummp
Pingback: Desarrollo de software. Sun Tzu. Las contingencias del proyecto determinan el aprendizaje « Jummp
Pingback: Desarrollo de software. El precio/hora y el triunfo de la mediocridad « Jummp
Pingback: Desarrollo de software. Cuando nos quedamos solos en el proyecto « Jummp
Pingback: Desarrollo de software. Proyectos. La complejidad de tener éxito en todos los contextos « Jummp
Pingback: LCOM4 y la falta de cohesión en las clases « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Cantidad y calidad de la documentación « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. La regularidad en la producción « Jummp
Pingback: Desarrollo de software. El precio/hora y el triunfo de la mediocridad II « Jummp
Pingback: Desarrollo de software. Mala calidad institucionalizada « Jummp
Pingback: Desarrollo de software. Entregas limpias, por favor « Jummp
Pingback: Desarrollo de software. Inercias « Jummp
Pingback: Desarrollo de software. Cuestión de crédito « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Documentación, parte de la solución o parte del problema « Jummp
Pingback: Desarrollo de software. El traspaso de proyectos « Jummp
Pingback: Desarrollo de software. Diversificación y equilibrio entre clientes y proveedores « Jummp
Pingback: Desarrollo de software. La tiranía del área usuaria « Jummp
Pingback: Desarrollo de software. Antipatrones « Jummp
Pingback: Desarrollo de software. El comportamiento en las crisis condiciona el resto del proyecto « Jummp
Pingback: Desarrollo de software. Antipatrón. Complejidad no indispensable « Jummp
Pingback: Desarrollo de software. Antipatrón. Tester driven development « Jummp
Pingback: Desarrollo de software. Antipatrón. Avance del alcance « Jummp
Pingback: Desarrollo de software. Antipatrón. Escalada del compromiso « Jummp
Pingback: Desarrollo de software. Antipatrón. Parálisis del análisis « Jummp
Pingback: Desarrollo de software. Antipatrón. Productividad a toda costa « Jummp
Pingback: Desarrollo de software. Antipatrón. Callejón sin salida « Jummp
Pingback: Desarrollo de software. Antipatrón. Te lo dije « Jummp
Pingback: Desarrollo de software. Antipatrón. Organización de cuerda de violín « Jummp
Pingback: Desarrollo de software. Antipatrón. Organización de cuerda de violín « Jummp
Pingback: Desarrollo de software. La competencia entre proveedores o por qué el grande no tiene por qué comerse al pequeño « Jummp
Pingback: Desarrollo de software. Antipatrón. Migración de coste « Jummp
Pingback: Desarrollo de software. Antipatrón. Pollo sin cabeza « Jummp
Pingback: Desarrollo de software. El cliente no es el enemigo « Jummp
Pingback: Desarrollo de software. Guerra de guerrillas « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología II « Jummp
Pingback: Desarrollo de software. Antipatrón. Introducción de dificultad por analogía « Jummp
Pingback: Desarrollo de software. Buenas prácticas y antipatrones « Jummp
Pingback: Desarrollo de software. La resaca del éxito « Jummp
Pingback: Desarrollo de software. La aceleración y la recuperación del tiempo perdido « Jummp
Pingback: Desarrollo de software. Antipatrón. Ellos me entendieron « Jummp
Pingback: Desarrollo de software. Objetivos, incertidumbre, agilidad « Jummp
Pingback: Desarrollo de software. Avance del proyecto y expectativas « Jummp
Pingback: Desarrollo de software. Antipatrón. Proyecto del día de la marmota « Jummp
Pingback: Desarrollo de software. Cascada y sin dinero para el mantenimiento « Jummp
Pingback: Desarrollo de software. Antipatrón. Cargo cult « Jummp
Pingback: Desarrollo de software. Antipatrón. Corncob. Mazorca de maíz « Jummp
Pingback: Desarrollo de software. Antipatrón. Arrojar al otro lado del muro « Jummp
Pingback: Desarrollo de software. Antipatrón. Caballero de tres cabezas « Jummp
Pingback: Desarrollo de software. Antipatrón. Quiero estimaciones ahora « Jummp
Pingback: Desarrollo de software. Antipatrón. Morir planificando « Jummp
Pingback: Desarrollo de software. Percepción, abstracción, implementación « Jummp
Pingback: Desarrollo de software. Antipatrón. Blowhard Jamboree « Jummp
Pingback: Desarrollo de software. Antipatrón. Los clientes son idiotas « Jummp
Pingback: Desarrollo de software. Antipatrón. Entrenar al entrenador « Jummp
Pingback: Desarrollo de software. Las empresas de desarrollo de software, calidad, cambio de modelo « Jummp
Pingback: Desarrollo de software. Antipatrón. Requisitos esparcidos por la pared « Jummp
Pingback: Desarrollo de software. Si los usuarios quieren, hay sistema « Jummp
Pingback: Desarrollo de software. Fuerza de rozamiento o fricción « Jummp
Pingback: Desarrollo de software. Antipatrón. Otra reunión más lo resolverá « Jummp
Pingback: Desarrollo de software. Agilidad vs fricción « Jummp
Pingback: Desarrollo de software. Antipatrón. Programador discordante o programador con productividad neta negativa « Jummp
Pingback: Desarrollo de software. Antipatrón. Tormenta de reproches « Jummp
Pingback: Desarrollo de software. Antipatrón. Simulacro de incendio « Jummp
Pingback: Desarrollo de software. Antipatrón. El traje nuevo del emperador « Jummp
Pingback: Desarrollo de software. Antipatrón. No es mi trabajo « Jummp
Pingback: Desarrollo de software. Antipatrón. El proceso es el entregable « Jummp
Pingback: Desarrollo de software. Antipatrón. Otro programador más « Jummp
Pingback: Desarrollo de software. Antipatrón. Standing on the shoulders of midgets « Jummp
Pingback: Desarrollo de software. Antipatrón. La cultura del héroe « Jummp
Pingback: Desarrollo de software. ¿Qué es caro?, ¿qué es barato? « Jummp
Pingback: Desarrollo de software. Antipatrón. Equipos fungibles « Jummp
Pingback: Desarrollo de software. Antipatrón. Solicitud dirigida « Jummp
Pingback: Desarrollo de software. Agilidad no es improvisación « Jummp
Pingback: Desarrollo de software. ¿Estamos condicionados por el mercado? « Jummp
Pingback: Desarrollo de software. Antipatrón. Gestión gaviota « Jummp
Pingback: Desarrollo de software. ¿Ser ágil es una moda? « Jummp
Pingback: Desarrollo de software. Antipatrón. Empire building « Jummp
Pingback: Desarrollo de software. Antipatrón. Ingeniería de diapositivas « Jummp
Pingback: Desarrollo de software. Antipatrón. Los arquitectos no programan « Jummp
Pingback: Desarrollo de software. Antipatrón. Abracadabra « Jummp
Pingback: Desarrollo de software. Antipatrón. Guerra de Vietnam « Jummp
Pingback: Desarrollo de software. Antipatrón. Trampas evitables « Jummp
Pingback: Desarrollo de software. La crisis del desarrollo a medida « Jummp
Pingback: Desarrollo de software. Antipatrón. Eso no es realmente un problema « Jummp
Pingback: Desarrollo de software. Antipatrón. Arquitectura o programación orientada a obstáculos « Jummp
Pingback: Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto? « Jummp
Pingback: Desarrollo de software. El miedo a la responsabilidad « Jummp
Pingback: Desarrollo de software. La agilidad y el nirvana « Jummp
Pingback: Desarrollo de software. Contratación ágil II « Jummp
Pingback: Desarrollo de software. Contratación ágil I « Jummp
Pingback: Desarrollo de software. La experiencia es la acumulación de experiencias, no de años « Jummp
Pingback: Desarrollo de software. Antipatrón. Gestor pero no líder « Jummp
Pingback: Desarrollo de software. La evolución en el enfoque del proceso de desarrollo « Jummp
Pingback: Desarrollo de software. Antipatrón. Orientación al medallero « Jummp
Pingback: Desarrollo de software. Contratación ágil IV « Jummp
Pingback: Desarrollo de software. Contratación ágil V « Jummp
Pingback: Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto « Jummp
Pingback: Desarrollo de software. Agilidad y la evolución en la incertidumbre en el proyecto « Jummp
Pingback: Desarrollo de software. La agilidad es un paraguas en la tormenta « Jummp