INTRODUCCION
EN UN PROYECTO DE SOFTWARE EXISTEN DIVERSOS PUNTOS A TRATAR Y TEMAS ESPECIFICOS QUE TENEMOS Q REALIZAR PARA QUE FUNCIONE CORRECTAMENTE Y NO FALLAR AÚN ANTES DE ENTREGAR SIQUIERA UNA APLICACIÓN. CON ESTO CLARO, UNA REVISIÓN A CONCIENCIA DE LAS TÉCNICAS FUNDAMENTALES DE ADMINISTRACIÓN DE PROYECTOS NOS RECUERDA QUE TODAVÍA QUEDA UN LARGO CAMINO POR RECORRER.
PARA QUE DICHO PROYECTO DE SOFTWARE RESULTE CON ÉXITO HAY QUE TENER ENCUENTA LOS DIVERSOS PUNTOS QUE VAMOS A MOSTRAR A CONTINUACION DONDE SE VAN A DESGLOSAR DE FORMA DETALLADA Y EXPLICITA PARA QUE UN PROYECTO DE SOFTWARE SEA EL MEJOR.
ASI COMO LAS ACTITUDES QUE DEBEMOS ADOPTAR EN CASO DE QUE NOS FALLE.
FACTORES CRÍTICOS DE ÉXITO EN LOS PROYECTOS DE SOFTWARE
LOS PROYECTOS DE SOFTWARE TODAVÍA SE ATRASAN, GASTAN MÁS DE LO PRESUPUESTADO, Y SON IMPREDECIBLES. A VECES UN PROYECTO ENTERO FALLA AÚN ANTES DE ENTREGAR SIQUIERA UNA APLICACIÓN. CON ESTO CLARO, UNA REVISIÓN A CONCIENCIA DE LAS TÉCNICAS FUNDAMENTALES DE ADMINISTRACIÓN DE PROYECTOS NOS RECUERDA QUE TODAVÍA QUEDA UN LARGO CAMINO POR RECORRER.
A LO LARGO DE CASI 50 AÑOS DE DESARROLLO DE SOFTWARE, LA INDUSTRIA A PASADO A TRAVÉS DE AL MENOS 4 GENERACIONES DE LENGUAJES DE PROGRAMACIÓN Y 3 PARADIGMAS MAYORES DE DESARROLLO. HEMOS SOSTENIDO EN INNUMERABLES SEMINARIOS CÓMO DESARROLLAR SOFTWARE CORRECTAMENTE, HEMOS FORZADO MUCHOS CURSOS DENTRO DE LOS PROGRAMAS DE PRE-GRADO, E INTRODUCIDOS ESTÁNDARES EN NUESTRAS ORGANIZACIONES QUE REQUIEREN TECNOLOGÍAS ESPECÍFICAS. A PESAR DE ESTO, NO HEMOS MEJORADO NUESTRA HABILIDAD DE MOVER EXITOSA Y CONSISTENTEMENTE LA «IDEA» AL «PRODUCTO». DE HECHO, ESTUDIOS RECIENTES DOCUMENTAN QUE, MIENTRAS LA TASA DE FALLAS PARA LOS ESFUERZOS DE DESARROLLO DE SOFTWARE HA MEJORADO EN LOS ÚLTIMOS AÑOS, EL NÚMERO DE PROYECTOS QUE EXPERIMENTAS PROBLEMAS SEVEROS HA AUMENTADO CASI UN 50%. NO HAY MAGIA EN LA ADMINISTRACIÓN EXITOSA DE DESARROLLO DE SOFTWARE, SINO QUE UN NÚMERO DE PROBLEMAS RELACIONADOS CON DEL DESARROLLO DE SOFTWARE LO HACEN ÚNICO.
ADMINISTRANDO COMPLEJIDAD.
VARIAS CARACTERÍSTICAS DE ESFUERZOS BASADOS EN SOFTWARE COMPLICAN LA ADMINISTRACIÓN. PRIMERO, LOS SISTEMAS BASADOS EN SOFTWARE SON EXCEPCIONALMENTE COMPLEJOS. DE HECHO, MUCHOS ESTÁN DE ACUERDO EN QUE «EL PROBLEMA BÁSICO DE LA COMPUTACIÓN ES LA SUPREMACÍA DE LA COMPLEJIDAD». DEBIDO A QUE LOS DESARROLLADORES DE SOFTWARE DEBEN LIDIAR CON PROBLEMAS COMPLEJOS, GENERALMENTE ELLOS DEBEN SER INDIVIDUOS MUY INTELIGENTES Y COMPLEJOS, LO CUAL TAMBIÉN COMPLICA LA FÓRMULA DE ADMINISTRACIÓN. AGREGANDO EL HECHO DE QUE LOS DESARROLLADORES TRATAN DE CUMPLIR CON UN OBJETIVO MUY CAMBIANTE – LOS REQUERIMIENTOS DE USUARIO – SE TIENE COMO RESULTADO UNA MEZCLA VOLÁTIL DE PROBLEMAS DE ADMINISTRACIÓN.
ESTO Y MUCHAS OTRAS INFLUENCIAS CONTRIBUYEN A UNA IMPRESIONANTEMENTE ALTA TASA DE FALLO SOBRE LOS PROYECTOS DE DESARROLLO DE SOFTWARE. EL «ESTUDIO DEL CAOS», PUBLICADO POR EL STANDISH GROUP, ENCONTRÓ QUE EL 26% DE TODOS LOS PROYECTOS DE SOFTWARE FALLA (BAJO, CON RESPECTO AL 40% DE 1997), Y QUE ADEMÁS, EL 46% EXPERIMENTA COSTOS, ATRASOS EN LAS FECHAS DE ENTREGA O VEN SIGNIFICATIVAMENTE REDUCIDA SU FUNCIONALIDAD (SOBRE EL 33% DE 1997). EL ESTUDIO TAMBIÉN MUESTRA QUE LA TASA DE COMPETICIÓN HA MEJORADO DEBIDO A QUE LAS COMPAÑÍAS HAN TENDIDO PROYECTOS MÁS PEQUEÑOS Y MANEJABLES (Y NO PORQUE HAYAN MEJORADO LAS TÉCNICAS DE ADMINISTRACIÓN). ¿PUEDEN IMAGINARSE UNA FIRMA DE CONSTRUCCIÓN QUE COMPLETE SÓLO EL 74% DE SUS CONSTRUCCIONES Y QUE SÓLO EL 54% DE ESTAS CONSTRUCCIONES ESTÉN DENTRO DE LOS PLAZOS DE ENTREGA Y DE LO PRESUPUESTADO?. PARA CAMBIAR ESTA TENDENCIA, DEBEMOS DAR ESPECIAL ÉNFASIS A CIERTOS FACTORES DEL PROCESO DE ADMINISTRACIÓN.
USTEDES DEBEN PENSAR QUE LAS RESPUESTAS MIENTEN AL ELABORAR METODOLOGÍAS DE ANÁLISIS, TÉCNICAS DE ADMINISTRACIÓN DE CONFIGURACIÓN ALTAMENTE AVANZADAS O EL LENGUAJE DE DESARROLLO PERFECTO. ESOS ELEMENTOS DEL AMBIENTE TECNOLÓGICO SON TAN IMPORTANTES COMO UNA INVESTIGACIÓN ALTAMENTE CIENTÍFICA Y ANALÍTICA, ADEMÁS DEL DISEÑO DE METODOLOGÍAS, ADMINISTRACIÓN DE PROYECTOS Y LA CALIDAD DEL SOFTWARE.
SIN EMBARGO, LOS CIANOTIPOS DEL ÚLTIMO «TREN» DE TECNOLOGÍA NO HAN MEJORADO LA VIDA EN EL «LEJANO OESTE» Y ESTO NO OCURRIRÁ HASTA QUE LAS «COMPAÑÍAS DE RIELES» INVIERTAN EN LOS ASPECTOS FUNDAMENTALES DE «TRANSPORTE DE TRENES», ES DECIR, «VÍAS Y DEPÓSITOS». AL IGUAL QUE EN EL SOFTWARE, TECNOLOGÍAS MÁS «AVANZADAS» SON LEJOS MENOS IMPORTANTES PARA MEJORAR LA PRÁCTICA QUE ADOPTAR LO QUE CREO SON LOS 5 FACTORES ESENCIALES PARA ADMINISTRAR EXITOSAMENTE UN PROYECTO DE SOFTWARE:
1. EMPEZAR CON EL PIE DERECHO.
2. MANTENER EL ÍMPETU.
3. CONTROLAR (O ESTAR AL TANTO) DEL PROGRESO.
4. TOMAR DECISIONES INTELIGENTES.
5. INSTITUCIONALIZAR LOS ANÁLISIS POST-MORTEM.
DADO ESTO, NI SIQUIERA UNA REVISIÓN DETALLADA DE ESOS FACTORES LO DEJARÁN SIN PREGUNTARSE QUÉ HAY DE NUEVO EN ELLOS. NO MUCHO (ESO SE SABE POR SENTIDO COMÚN), SON CUESTIONES BÁSICAS DE ADMINISTRACIÓN. NO OBSTANTE, ESTOS PRINCIPIOS AÚN NO SON COMÚNMENTE EMPLEADOS. SI FUERA ASÍ, NO VERÍAMOS LAS ALTAS TASAS DE FALLAS QUE VEMOS HOY EN DÍA.
1. EMPEZAR CON EL PIE DERECHO.
ES DIFÍCIL LLAMAR A CUALQUIERA DE ESTOS FACTORES «MÁS IMPORTANTE», DEBIDO A QUE TODOS SON CRÍTICOS PARA EL ÉXITO DE ESFUERZOS EN GRANDES PROYECTOS. SIN EMBARGO, OBTENER UNA CONFIGURACIÓN (O SET UP) DEL PROYECTO Y COMENZARLO APROPIADAMENTE, CIERTAMENTE ES A LO QUE CONDUCEN ESTA CLASE DE FACTORES. ASÍ COMO ES DIFÍCIL QUE CREZCAN PLANTAS FUERTES EN TIERRAS DÉBILES, ES CASI IMPOSIBLE LLEVAR EXITOSAMENTE UN ESFUERZO DE DESARROLLO QUE ESTÁ MAL PLANIFICADO. TOM FIELD ANALIZÓ LAS TRAMPAS EN LOS ESFUERZOS DE DESARROLLO DE SOFTWARE Y DIO 10 SEÑALES O INDICIOS DE FALLA EN UN PROYECTO DE IS, DE LOS CUALES, AL MENOS 7 ESTÁN COMPLETAMENTE DETERMINADOS ANTES DE QUE HAGA UN DISEÑO O QUE SE ESCRIBA UNA LÍNEA DE CÓDIGO. POR LO TANTO, EL 70% DE LOS ACTOS QUE SENTENCIAN EL PROYECTO OCURREN INCLUSO ANTES DE QUE COMIENCE LA CONSTRUCCIÓN.
LAS 10 SEÑALES DE FALLA EN UN PROYECTO IS SON:
1. LOS ADMINISTRADORES DEL PROYECTO NO ENTIENDEN LAS NECESIDADES DEL USUARIO.
2. EL ÁMBITO DEL PROYECTO ESTÁ MAL DEFINIDO.
3. LOS CAMBIOS EN EL PROYECTO SON POBREMENTE ADMINISTRADOS.
4. LAS TECNOLOGÍAS ESCOGIDAS CAMBIAN.
5. LAS NECESIDADES DEL NEGOCIO CAMBIAN.
6. LAS FECHAS TOPES SON POCO REALISTAS.
7. LOS USUARIOS SE RESISTEN.
8. SE PIERDE LA CONFIANZA O PATROCINIO.
9. EL PROYECTO CARECE DE PERSONAS CON LAS DESTREZAS APROPIADAS.
10. LOS ADMINISTRADORES IGNORAN LAS MEJORES PRÁCTICAS Y LECCIONES APRENDIDAS.
DADAS ESTAS INFORMACIONES, ¿QUÉ PODEMOS HACER PARA QUE EL PROYECTO TENGA UN COMIENZO EXITOSO?.
- FIJAR OBJETIVOS Y EXPECTATIVAS REALISTAS, PARA TODOS.
EL PRIMER OBJETIVO PARA LLEVAR UN PROYECTO A UN BUEN COMIENZO ES LLEVAR A TODOS A UNA MISMA LONGITUD DE ONDA. ADMINISTRACIÓN, USUARIOS, DESARROLLADORES Y DISEÑADORES, TODOS DEBEN TENER EXPECTATIVAS REALISTAS. EN CASO DE QUE SUS CLIENTES NO HAYAN OÍDO, RECUÉRDELES FRECUENTEMENTE QUE EL SISTEMA NO RESOLVERÁ TODOS SUS PROBLEMAS Y QUE PROBABLEMENTE CREE PROBLEMAS NUEVOS. EL COSTO DEL NUEVO SISTEMA DEBERÍA RESOLVER MÁS PROBLEMAS DE LO QUE GENERE. LOS DESARROLLADORES TAMBIÉN DEBEN ENTENDER QUE LOS CLIENTES NO SABEN EXACTAMENTE LO QUE QUIEREN, CÓMO LO QUIEREN, O CÓMO LOS AYUDARÁ EL SISTEMA. A MENUDO, ELLOS NI SIQUIERA SABEN CUÁNTO PUEDEN GASTAR. TODOS DEBEN LLEGAR A LA MESA CON SUS OJOS BIEN ABIERTOS, DESEANDO ESCUCHAR Y COOPERAR. PARA EVITAR AFLICCIONES DE ÚLTIMO MOMENTO, PONGAN ESTRICTA ATENCIÓN A LOS COMPROMISOS HECHOS POR AMBAS PARTES.
- FORMAR EL EQUIPO ADECUADO.
A CONTINUACIÓN, USTED DEBE REUNIR AL EQUIPO ADECUADO. PRIMERO ASEGÚRESE QUE CUENTA CON LOS RECURSOS SUFICIENTES PARA TERMINAR EL TRABAJO. SI USTED NO OBTIENE COMPROMISOS PARA CON LOS RECURSOS, EL ESFUERZO ESTÁ SENTENCIADO. SI LA ADMINISTRACIÓN NO ESTÁ LO SUFICIENTEMENTE ENTUSIASMADA CON LOS ESFUERZOS PARA DARLE LOS RECURSOS SUFICIENTES, USTED PODRÍA NO TENER EL APOYO SUFICIENTE PARA LOGRAR EL ÉXITO. RECUERDE TAMBIÉN QUE, DE LA MISMA MANERA, USTED NECESITARÁ MÁS RECURSOS DE LOS QUE PIENSA. TODOS SOMOS INHERENTEMENTE OPTIMISTAS, ASÍ QUE GUARDE LAS PROYECCIONES Y ERRORES DEL PERSONAL EN UN LADO ALTO («LEJOS DEL ALCANCE DE LOS NIÑOS») DESDE EL PRINCIPIO.
FORMAR EL EQUIPO ADECUADO SIGNIFICA REUNIR GENTE «BUENA». ESTO ES DIFÍCIL DEBIDO A QUE LAS COMPAÑÍAS USUALMENTE QUIEREN DISTRIBUIR CIERTO PERSONAL HACIA OTRAS TAREAS. A VECES ESTAS PERSONAS SON BUENOS RECURSOS, PERO NO SIEMPRE. SIN EMBARGO, TAMBIÉN RECONOZCA QUE UNO NO SIEMPRE NECESITA O QUIERE A TODOS LOS MEJORES DISEÑADORES Y DESARROLLADORES. EN MI EXPERIENCIA, REUNIENDO A UN 20% DEL EQUIPO, CON LO MEJOR DISPONIBLE, SE TRABAJA BIEN. ESTE CÁLCULO ES VAGAMENTE APOYADO EN EL ENSAYO DE FRED BROOKS, «EL EQUIPO QUIRÚRGICO». SU EQUIPO, DE CERCA DE 10 PERSONAS, INCLUYE A 2 QUE SON REALMENTE EXPERTOS (EL PROGRAMADOR JEFE Y EL EXPERTO O ABOGADO EN LENGUAJE). TENER MUCHAS ESTRELLAS O GENIOS CREA PROBLEMAS DE EGO Y DISTRACCIONES, MIENTRAS QUE NO TENER LOS SUFICIENTES PUEDE DEJAR AL EQUIPO LUCHANDO CON PEQUEÑOS PROBLEMAS.
EL RESTO DEL EQUIPO DEBERÍAN SER DESARROLLADORES BUENOS Y SÓLIDOS CON PERSONALIDADES Y HÁBITOS DE TRABAJO COMPATIBLES. LOS MIEMBROS MÁS AVANZADOS DEL EQUIPO PUEDEN ADELANTARSE HACIA AGUAS MÁS DESCONOCIDAS, DESARROLLAR LOS ALGORITMOS Y APLICACIONES MÁS CRÍTICOS, Y PROPORCIONAR UNA GUÍA TÉCNICA AL RESTO DEL EQUIPO.
EL ELEMENTO MÁS CRÍTICO EN LA SELECCIÓN DE GENTE ES CREAR UN AMBIENTE EN EL CUAL ELLOS PUEDAN DISTINGUIRSE, LO QUE DEJARÁ QUE USTED SE ENFOQUE MÁS EN LA TECNOLOGÍA QUE EN LA DINÁMICA DEL EQUIPO. USTED NO QUIERE UN EQUIPO DE CLONES, LO QUE USTED QUIERE SON PERSONAS QUE SEAN COMPATIBLES UNAS CON OTRAS Y CON LA COMPAÑÍA Y CON EL AMBIENTE DE EQUIPO QUE USTED ESTÁ TRATANDO DE ESTABLECER. POR EJEMPLO, UN DESARROLLADOR «CASADO Y CON HIJOS», «DE BUEN TALANTE», O «DE NUEVE A CINCO», PODRÍA NO TRABAJAR BIEN EN UN EQUIPO DE DESARROLLADORES JÓVENES, SOLTEROS, «PODEROSOS DE SIETE A ONCE». ESTO DE NINGUNA MANERA QUIERE DECIR QUE EL MÁS «VIEJO» SEA MENOS PRODUCTIVO O CALIFICADO.
EN REALIDAD, EL DESARROLLADOR «DE BUEN TALANTE» PUEDE QUE PRODUZCA MEJOR CÓDIGO Y SER MÁS PRODUCTIVO QUE EL RESTO DEL GRUPO. SI USTED PIENSA QUE LA PRIMERA PERSONA DA UNA INFLUENCIA CALMADA Y ENFOCADA SIN QUE NINGÚN LADO SE SIENTA DEMASIADO FRUSTRADO, ENTONCES ÉSTA PODRÍA SER UNA BUENA COMBINACIÓN DESPUÉS DE TODO. EN CUALQUIER RÉGIMEN, USTED DEBE TENER EN CUENTA ESTOS FACTORES AL FORMAR SU EQUIPO DE TRABAJO.
DONDE QUIERA QUE SEA POSIBLE, Y USUALMENTE ES POSIBLE, INVOLUCRE A LOS CLIENTES Y USUARIOS EN EL DESARROLLO. ESTO NO SÓLO AYUDA A CONSTRUIR ALTOS NIVELES DE CONFIANZA ENTRE LOS USUARIOS Y DESARROLLADORES, SINO QUE TAMBIÉN SITÚA EXPERTOS EN EL TEMA (PROBLEMA A SOLUCIONAR COMPUTACIONALMENTE) AL ALCANCE DE LOS DESARROLLADORES A TRAVÉS DE LA CONSTRUCCIÓN DEL SISTEMA. ESTO AUMENTA LA POSIBILIDAD DE QUE USTED DESARROLLE UN PRODUCTO QUE SATISFAGA LOS REQUERIMIENTOS DEL USUARIO.
- DÉ AL EQUIPO LO QUE ELLOS CREEN QUE NECESITAN.
UNA VEZ QUE USTED HA CONSTRUIDO UN EQUIPO SÓLIDO, A CONTINUACIÓN USTED DEBE PROPORCIONAR A SU EQUIPO UN AMBIENTE QUE LOS ANIME A SER PRODUCTIVOS Y QUE MINIMICE LAS DISTRACCIONES. PRIMERO, HAGA TODO LO POSIBLE POR ENTREGARLES ESPACIOS DE OFICINA TRANQUILOS Y PRODUCTIVOS. ESTO MUCHAS VECES ES IMPOSIBLE DADA LA REALIDAD DE LA MAYORÍA DE LAS CORPORACIONES, PERO PODER TRABAJAR EN OFICINAS CONFORTABLES PUEDE EVITAR RESULTADOS DRAMÁTICOS. AMBIENTES ALTAMENTE PRODUCTIVOS CONTIENEN PIZARRAS BLANCAS, ÁREAS DE REUNIÓN (FORMALES E INFORMALES), ÁREAS PARA OFICINAS PRIVADAS, E INSTALACIONES O LABORATORIOS MODERNOS Y FLEXIBLES. SÚMELE ELEMENTOS DE COMODIDAD COMO RADIOS, BUENA ILUMINACIÓN, MÁQUINAS EXPENDEDORAS DE CAFÉ, Y SILLAS CÓMODAS; Y USTED CREARÁ UN AMBIENTE DONDE LAS PERSONAS SE PUEDAN ENFOCAR EN SU TRABAJO Y OLVIDARSE DEL RESTO DEL MUNDO.
UNA VEZ QUE TENGA UN EQUIPO CON UN ESPACIO DE OFICINA PRODUCTIVO, USTED NECESITA EL EQUIPAMIENTO ADECUADO. POR NINGUNA RAZÓN, ESCATIME EN EL EQUIPAMIENTO (NO REPARE EN GASTOS). LA DIFERENCIA ENTRE LAS MÁQUINAS DE CALIDAD (STATE-OF-THE-ART) Y SISTEMAS DE DESARROLLO ADECUADO ES DE MENOS DE US$1.000. USTED PROBABLEMENTE GASTE AL MENOS US$100.000 POR AÑO PARA MANTENER A UN BUEN DISEÑADOR, INCLUYENDO EL SALARIO, BONOS, BENEFICIOS, ENTRENAMIENTO Y OTROS GASTOS RELACIONADOS. ESOS US$1.000 AMORTIZADOS EXTRA SOBRE 2 AÑOS REPRESENTA MENOS QUE EL 50% DEL COSTO DE LOS EMPLEADOS.
FINALMENTE, SU EQUIPO NECESITA HERRAMIENTAS. OBTENGA HERRAMIENTAS BUENAS Y PROBADAS, DE COMPAÑÍAS ESTABLES. NADA DESCARRILARÁ MÁS RÁPIDO UN PROYECTO QUE LAS HERRAMIENTAS SIN SOPORTE. EL EQUIPO TAMBIÉN NECESITA ENTRENARSE PARA USAR ESAS HERRAMIENTAS; PERDER ARCHIVOS O CARPETAS DEBIDO A LA IGNORANCIA E INEXPERIENCIA ES DOLOROSO Y COSTOSO. EL TÉRMINO HERRAMIENTA NO SÓLO SIGNIFICA COMPILADOR. USTED TAMBIÉN NECESITA ANÁLISIS Y DISEÑO, ADMINISTRACIÓN DE CONFIGURACIÓN, TESTEO, ADMINISTRACIÓN DE RESPALDOS, PRODUCCIÓN DE DOCUMENTOS, MANIPULACIÓN DE GRÁFICOS, Y HERRAMIENTAS PARA ARREGLAR PROBLEMAS. ESTO ES, SIN EMBARGO, UN ÁREA DONDE TENER LO DE MEJOR CALIDAD NO SIGNIFICA GASTAR MÁS DINERO. COMPRE CUIDADOSAMENTE, REVISA ENTRE MUCHAS OPCIONES, E INVOLUCRE A TODO EL EQUIPO EN LA DECISIÓN.
2. MANTENER EL ÍMPETU.
POR AHORA, USTED TIENE SU EQUIPO DE DESARROLLO ENERGIZADO CON SÓLIDOS COMPAÑEROS DE TRABAJO (CO-TRABAJADORES), UN GRAN AMBIENTE DE TRABAJO, Y ALGÚN HARDWARE DE ALTO NIVEL. FELICITACIONES, USTED TIENE EL ÍMPETU. EL SIGUIENTE FACTOR CRÍTICO ES EL MANTENIMIENTO Y MEJORAMIENTO DE ESTE ÍMPETU. CONSTRUIR ESTE IMPULSO INICIALMENTE ES FÁCIL, PERO RECONSTRUIRLO ES HORRENDAMENTE DIFÍCIL. EL ÍMPETU O IMPULSO CAMBIA MUCHAS VECES DURANTE EL CURSO DE UN ESFUERZO DE DESARROLLO. ESTOS CAMBIOS AUMENTAN RÁPIDAMENTE, ASÍ QUE ES CRUCIAL COMPENSAR RÁPIDAMENTE LOS CAMBIOS NEGATIVOS CON CAMBIOS POSITIVOS.
USTED SE DEBE ENFOCAR EN LOS TRES ELEMENTOS CLAVE PARA MANTENER O RECONSTRUIR EL ÍMPETU DEL EQUIPO:
· ROCE O FRICCIÓN – MANTÉNGALO BAJO.
· CALIDAD – MONITORÉELA DESDE EL PRINCIPIO Y ESTABLEZCA EXPECTATIVAS DE EXCELENCIA.
· ADMINISTRACIÓN – ADMINISTRE EL PRODUCTO MÁS QUE LA GENTE.
LA FRICCIÓN ES UN PROBLEMA CONSTANTE EN LA INDUSTRIA DE SOFTWARE. ELLA PUEDE PROVOCAR EL DESASTRE EN UN PROYECTO DE SOFTWARE MIDSTREAM, PORQUE EL PERSONAL DE REEMPLAZO DEBE ADAPTARSE RÁPIDAMENTE A LA VELOCIDAD DE TRABAJO SOBRE UN SOFTWARE QUE TODAVÍA NO ESTÁ COMPLETO, PROBADO Y PROBABLEMENTE NO BIEN DOCUMENTADO TODAVÍA. UNA TREMENDA CANTIDAD DE CONOCIMIENTO SE VA POR LA BORDA CUANDO UNA PERSONA RENUNCIA, Y AQUELLOS QUE SE DEJÓ ATRÁS SERÁN VÍCTIMAS DE TODOS LOS PROBLEMAS QUE APAREZCAN DE AHORA EN ADELANTE. ADEMÁS, EN ESTE ESTRECHO MERCADO LABORAL, EL TIEMPO DE RETRASO ENTRE CUANDO UNA PERSONA RENUNCIA Y CUANDO EL REEMPLAZO ES CONTRATADO PUEDE CAUSAR ESTRAGOS HASTA CON LOS PROGRAMAS MÁS PESIMISTAS.
USTED NO PUEDE VOLVER ATRÁS Y AGREGAR CALIDAD. CON EL TIEMPO USTED DESCUBRIRÁ QUE TIENE UN PROBLEMA DE CALIDAD, Y PROBABLEMENTE SEA TARDE PARA ARREGLARLO. ESTABLEZCA PROCEDIMIENTOS Y EXPECTATIVAS PARA ALTOS NIVELES DE CALIDAD ANTES DE QUE COMIENCE CUALQUIER DESARROLLO Y CONTRATE DESARROLLADORES QUE SE SEPA QUE PRODUCEN CÓDIGO DE ALTA CALIDAD. HAGA QUE LOS DESARROLLADORES PARTICIPEN EN REVISIONES REGULARES DE CÓDIGO DE NIVEL POBRE Y REVISIONES EXTERNAS.
INVARIABLEMENTE, CUANDO UN PROYECTO ESTÁ DESARROLLÁNDOSE, TODOS ESTÁN ENTUSIASMADOS, LOS REPORTES DE ESTADO SE VEN GENIAL Y LOS GUI SON FANTÁSTICOS, TODO SALE MAL. PUEDE SER UN MAL REPORTE DE PRUEBA, UN DEMO FALLADO, O UN PEQUEÑO CAMBIO DE REQUERIMIENTOS DEL CLIENTE EL QUE LLEVA LA PIEDRECILLA QUE COMIENZA LA AVALANCHA. UNO ARREGLA UNA FALLA (BUG) Y CREA DOS MÁS. DE REPENTE, EL EQUIPO DE DESARROLLO QUE ESTÁ CAUSANDO UN PROGRESO FANTÁSTICO SE VE ENLODADO EN LA REPARACIÓN Y MODIFICACIÓN DE CÓDIGO QUE HA ESTADO EN EL BANCO POR MESES.
ADMINISTRE EL PRODUCTO MÁS QUE SU PERSONAL. DESPUÉS DE TODO, EL PRODUCTO ES LO QUE USTED ESTÁ VENDIENDO. ASÍ QUE, SI LA CULTURA DE SU CORPORACIÓN PUEDE MANEJAR ESTO, NO SE PREOCUPE DE CÓDIGOS ARREGLADOS U HORAS DE TRABAJO ARREGLADAS. RELÁJESE Y DEJE A SU GENTE ENTREGAR COSAS EN EL ÚLTIMO MINUTO. LUEGO CRITIQUE SUS PRODUCTOS. SI LOS PRODUCTOS NO SON ACEPTABLES, USTED PUEDE EMPEZAR TRABAJANDO CON LOS INDIVIDUOS PARA MEJORAR SUS PRODUCTOS.
LA META AQUÍ NO ES CREAR PROBLEMAS INDIVIDUALES EN EL EQUIPO. SÓLO PORQUE A UNA O DOS PERSONAS LES GUSTE LLEGAR A LAS 10:00 A.M. Y TRABAJAN HASTA LAS 5:00 P.M., ABUSANDO DE LA FLEXIBILIDAD QUE SE LES ESTÁ DANDO, NO SIGNIFICA QUE SE DEBA ESTROPEAR EL AMBIENTE PARA TODO EL EQUIPO. MUY A MENUDO, LOS PROYECTOS EVITAN LA CONFRONTACIÓN CON LOS INDIVIDUOS Y MERAMENTE «ARREGLAN» EL PROBLEMA FIJANDO REGLAS ARBITRARIAS AL EQUIPO. PRONTO, TODOS SE VERÁN ENCERRADOS ENTRE COMPAÑEROS NO CONVENCIONALES Y UNA ADMINISTRACIÓN ESTRICTA.
ESTOS SON INDICIOS DE QUE EL ÍMPETU ESTÁ DISMINUYENDO. HAGA RODAR ALGUNAS DE ESTAS DECISIONES JUNTAS, Y EL EQUIPO PRONTO ESTARÁ MÁS ENFOCADO EN ELUDIR LAS REGLAS O EN CHISMORREAR CONTRA SUS OFENSORES QUE EN PRODUCIR UN PRODUCTO DE CALIDAD.
CUANDO USTED TENGA UN PROBLEMA LEGÍTIMO DE PERSONAL, RESUÉLVALO RÁPIDAMENTE. SI DEBE DEJAR QUE ALGUIEN SE VAYA, HÁGALO RÁPIDO Y REÚNASE CON EL EQUIPO PARA EXPLICARLES QUE PASÓ. EN LA MEDIDA QUE USTED SEA JUSTO, ESTAS EXPERIENCIAS CONTRIBUIRÁN A LA COHESIÓN DEL GRUPO Y LES PERMITIRÁ RECONSTRUIR EL ÍMPETU RÁPIDAMENTE.
3. CONTROLAR EL PROGRESO.
CONSIDERE LA INTANGIBLE NATURALEZA DEL SOFTWARE COMPARADA AL TRADICIONAL LADRILLO Y MORTERO DE LA CONSTRUCCIÓN. EL RESULTADO DE LA CONSTRUCCIÓN ES UNA MANIFESTACIÓN FÍSICA DE UN MODELO CONCEPTUAL – EL CIANOTIPO SE CONVIERTE EN UNA CONSTRUCCIÓN QUE LA GENTE PUEDE TOCAR Y VER. ELLOS INCLUSO PUEDEN TOCAR Y VER TODAS LAS PEQUEÑAS PIEZAS A MEDIDA QUE SON CLAVADAS, SOLDADAS, PEGADAS O ATORNILLADAS A LA ESTRUCTURA DURANTE LA CONSTRUCCIÓN. EL DESARROLLO DE SOFTWARE COMIENZA COMO UN MODELO CONCEPTUAL Y RESULTA EN UNA APLICACIÓN, ASÍ QUE NO HAY UNA MANIFESTACIÓN FÍSICA DE SOFTWARE QUE PUEDA SER TOCADA Y MEDIDA, ESPECIALMENTE DURANTE LA CONSTRUCCIÓN.
UN GRAN PROBLEMA EN LA ADMINISTRACIÓN DE UN PROYECTO DE SOFTWARE ES CALCULAR EN QUÉ PARTE DE LA PLANIFICACIÓN ESTÁ EL PROYECTO. ¿CUÁN COMPLETO ESTÁ UN MÓDULO?, ¿CUÁNTO TIEMPO LLEVARÁ TERMINAR LOS MÓDULOS X, Y, Z?. ÉSTAS SON PREGUNTAS DIFÍCILES DE RESPONDER, PERO DEBEN SER DIRECCIONADAS. SI USTED NO SABE DÓNDE ESTÁ EL PROYECTO EN RELACIÓN AL CALENDARIO DE LA PLANIFICACIÓN, NO SE PODRÁ AJUSTAR PARA VOLVER ATRÁS EN EL CONTROL. EXISTEN MUCHAS METODOLOGÍAS PARA CONTROLAR EL PROGRESO; SELECCIONE UNA EN EL NIVEL CORRECTO DEL DETALLE PARA SU TRABAJO (O ESFUERZO), Y ÚSELA RELIGIOSAMENTE.
4. TOME DECISIONES INTELIGENTES.
TOMAR DECISIONES INTELIGENTES MUCHAS VECES SEPARA LOS PROYECTOS EXITOSOS DE LOS FRACASADOS. NO DEBERÍA SER DIFÍCIL DE IDENTIFICAR UNA MALA DECISIÓN ANTES DE HACERLA. ESCOGER RE-ESCRIBIR ALGUNAS DE LAS LIBRERÍAS ENLAZADAS DINÁMICAMENTE DE MICROSOFT PARA ACOMODARLAS A SUS ELECCIONES DE DISEÑO ES UNA MALA DECISIÓN. AÚN ASÍ, YO HE VISTO POR LO MENOS 4 PROYECTOS IMPORTANTES PROCURANDO ESE TIPO DE LOCURAS.
SI SU APLICACIÓN NECESITA COMUNICARSE A TRAVÉS DE UNA CONEXIÓN SERIAL, ¿COMPRARÁ UNA LIBRERÍA COMERCIAL DE RUTINAS DE COMUNICACIONES O DESARROLLARÁ UNA PROPIA DESDE CERO?. SI USTED LO CONSTRUYE DESDE CERO, PODRÁ IMPLEMENTAR SU PROPIO PROTOCOLO PERSONALMENTE DISEÑADO. MALA DECISIÓN. SIEMPRE USE LIBRERÍAS COMERCIALES CUANDO ESTÁN DISPONIBLES, Y NUNCA TRATE DE CREAR NUEVOS PROTOCOLOS DE COMUNICACIONES. EN EL MEJOR DE LOS CASOS, LE COSTARÁ UNA FORTUNA. EN EL PEOR DE LOS CAOS, ESO HUNDIRÁ SU PROYECTO.
ADEMÁS, LA GENTE CONSISTENTEMENTE TOMA MALAS DECISIONES EN LA SELECCIÓN DE TECNOLOGÍAS. POR EJEMPLO, ¿CÓMO ESCOGE MUCHA GENTE, PARA DESARROLLAR APLICACIONES PARA LA PRÓXIMA PLATAFORMA?. LA MAYORÍA NUNCA TERMINA SUS APLICACIONES ANTES DE QUE LA PLATAFORMA DESAPAREZCA. CUANDO USTED ESCOJA UNA TECNOLOGÍA FUNDAMENTAL, YA SEA UN MOTOR DE BASE DE DATOS, UN SISTEMA OPERATIVO O UN PROTOCOLO DE COMUNICACIONES, DEBERÁ HACER UN ANÁLISIS FINANCIERO Y TÉCNICO. SI LA TECNOLOGÍA NO ESTÁ CAPTANDO UNA PARTE DEL MERCADO Y SI NINGUNA BUENA COMPAÑÍA LO APOYA, ENTONCES USTED ESTÁ CONSTRUYENDO SU PROYECTO SOBRE UNA BASE ARENOSA.
DEBIDO A QUE SU PREVISIÓN PUEDE FALLAR, USE SU DISEÑO PARA AISLARSE DE LA TECNOLOGÍA SUBYACENTE. ENCAPSULE LA INTERFAZ A LAS NUEVAS TECNOLOGÍAS TANTO COMO LE SEA POSIBLE. PIENSE EN QUÉ TECNOLOGÍAS SON PROPENSAS A CAMBIAR A TRAVÉS DEL CICLO DE VIDA DE SU PRODUCTO Y DISEÑE SU APLICACIÓN PARA AISLAR (A UN NIVEL PRÁCTICO) SU CÓDIGO DE ESOS CAMBIOS.
USTED TENDRÁ MUCHAS OPORTUNIDADES PARA TOMAR BUENAS DECISIONES EN LA MEDIDA QUE NEGOCIE LOS REQUERIMIENTOS DEL USUARIO. ESFUÉRCESE EN MOVER LOS REQUERIMIENTOS DESDE LOS COMPLICADOS, CATEGORÍA «NUNCA HECHO ANTES» A LA CATEGORÍA «YA ESTUVE AHÍ, HAZ ESTO». A MENUDO, LOS USUARIOS REQUIEREN COSAS QUE SON MARGINALMENTE VALIOSAS SIN ENTENDER LA COMPLEJIDAD. EXPLIQUE LAS RAMIFICACIONES DE REQUERIMIENTOS COMPLICADOS Y CAMBIOS DE REQUERIMIENTOS EN TÉRMINOS DE COSTO Y PLANIFICACIÓN. AYÚDELOS A QUE LOS AYUDEN.
5. ANÁLISIS POST-MORTEM.
POCAS COMPAÑÍAS INSTITUCIONALIZAN UN PROCESO PARA APRENDER DE SUS ERRORES. SI USTED NO SE TOMA EL TIEMPO DE ANALIZAR QUÉ PASÓ DURANTE UN PROYECTO, LO BUENO Y LO MALO, USTED ESTÁ CONDENADO A REPETIRLO.
¿QUÉ PUEDE APRENDER USTED DE UN ANÁLISIS POST-MORTEM? EN PRIMER LUGAR, USTED APRENDE POR QUÉ SUS ESTIMACIONES DE HORARIO FALLARON. LA COMPENSACIÓN POR AQUELLOS FACTORES EN EL PRÓXIMO PROYECTO MEJORARÁ DRAMÁTICAMENTE SUS TÉCNICAS DE ESTIMACIÓN. ESTE ANÁLISIS TAMBIÉN LO AYUDARÁ A DESARROLLAR UN PERFIL DE CÓMO SU EQUIPO Y COMPAÑÍA DESARROLLA SISTEMAS DE SOFTWARE. LA MAYORÍA DE LAS COMPAÑÍAS Y EQUIPOS TIENEN PERSONALIDADES QUE IMPACTAN FUERTEMENTE AL CICLO DE DESARROLLO. A MEDIDA QUE USTED PASE POR ESTOS ANÁLISIS, ESTAS PERSONALIDADES EMERGERÁN COMO PATRONES EN VEZ DE INCIDENTES AISLADOS.CONOCER LOS PATRONES LE PERMITIRÁ ENGAÑAR O AL MENOS PLANIFICARLOS EN SU PRÓXIMO PROYECTO.
EN SU LIBRO ADMINISTRANDO PROYECTOS DE DESARROLLO DE SOFTWARE, NEAL WHITTEN OFRECE 6 PASOS PARA EJECUTAR UNA REVISIÓN POST-MORTEM DE UN PROYECTO:
· DECLARE EL PROPÓSITO: ANUNCIE EL COMIENZO DEL PROYECTO QUE USTED SOSTENDRÁ UNA REVISIÓN. ADEMÁS, DEFINA QUÉ TÓPICOS SERÁN VISTOS, Y FIJE LOS PROCEDIMIENTOS.
· SELECCIONE LOS PARTICIPANTES: ESCOJA REPRESENTANTES DE CADA GRUPO IMPORTANTE ASOCIADO AL PROYECTO. PARA ASEGURAR UNA REVISIÓN DE OBJETIVOS, LA ADMINISTRACIÓN NO DEBE PARTICIPAR DIRECTAMENTE.
· PREPARE LA REVISIÓN: DESPUÉS DE QUE SE COMPLETE EL PROYECTO, ASIGNE PARTICIPANTES A LA REVISIÓN PARA REUNIR DATOS. ESTO DEBERÍA INCLUIR MÉTRICAS, STAFFING, COMUNICACIÓN ENTRE E INTRA GRUPOS, CALIDAD Y PROCESOS.
· DIRIJA LA REVISIÓN: LA ACTUAL REVISIÓN NO DEBERÍA REQUERIR MÁS DE UNOS POCOS DÍAS DE REUNIONES. TODOS LOS PARTICIPANTES DEBERÍAN COMENZAR POR PRESENTAR SUS CONCLUSIONES Y EXPERIENCIAS CON EL PROYECTO. LUEGO, EL GRUPO PREPARA DOS LISTAS: COSAS QUE ESTUVIERON CORRECTAS Y COSAS QUE ESTUVIERON ERRADAS. LOS PARTICIPANTES PUEDEN ENTONCES COMENZAR A TRABAJAR EN LO QUE ESTUVO ERRADO PARA DESARROLLAR SOLUCIONES.
· PRESENTE LOS RESULTADOS: LOS PARTICIPANTES DEBERÍAN PRESENTAR LOS RESULTADOS AL EQUIPO DE DESARROLLO Y A LA DIRECCIÓN EJECUTIVA.
· ADOPTE LAS RECOMENDACIONES: LA COMPAÑÍA DEBE IMPLEMENTAR LAS RECOMENDACIONES EN LOS PROYECTOS PRÓXIMOS. SIN ESTA CONTINUACIÓN, EL PROCESO PRODUCE UN BENEFICIO MARGINAL.
LA PREMISA Y EL BENEFICIO DE DESARROLLAR ANÁLISIS POST-MORTEM SON VALIDADOS POR EL PROCESO DE MOVIMIENTO DE MEJORAMIENTO INSPIRADO POR W. EDWARDS DEMING DURANTE FINALES DE LOS ’80 Y PRINCIPIO DE LOS ’90. ÉL SUGIERE LA MEDICIÓN OBJETIVA DE UN PROCESO DADO Y USAR ESTAS MEDICIONES PARA EVALUAR LA INFLUENCIA DE LOS CAMBIOS EN LOS PROCESOS. SÓLO MIDIENDO UN SISTEMA Y ANALIZANDO AQUELLAS MEDICIONES INCREMENTALES USTED PODRÁ VERDADERAMENTE MEJORAR EL SISTEMA.
¡ADIVINE QUÉ!, LOS MÉTODOS DE SOFTWARE Y LOS HÁBITOS PARA DESARROLLAR SOFTWARE DE SU COMPAÑÍA CONSTITUYEN UN SISTEMA.
ESTÁ MUCHO MENOS DEFINIDO QUE EN UNA LÍNEA DE ENSAMBLAJE, PERO AÚN ASÍ ES UN SISTEMA. EL ANÁLISIS POST-MORTEM LE PERMITIRÁ MODIFICAR ESE SISTEMA PARA LA PRÓXIMA CORRIDA DE PRODUCCIÓN.
ESTOS CINCO FACTORES CRÍTICOS SOSTIENEN LA VERDAD INDEPENDIENTE DEL DISEÑO, METODOLOGÍA DE DESARROLLO, LENGUAJE DE IMPLEMENTACIÓN, O EL DOMINIO DE LA APLICACIÓN. SIN EMBARGO, ESTA NO ES UNA LISTA EXHAUSTIVA, MUCHOS OTROS FACTORES INFLUENCIAN LA ADMINISTRACIÓN EXITOSA DE UN ESFUERZO DE DESARROLLAR SOFTWARE. PERO SI USTED SOBREPONE ESTO CINCO, INCREMENTARÁ EN GRAN MANERA LAS VENTAJAS EN LA COMPLETACIÓN DE SU PROYECTO EN TIEMPO Y DENTRO DEL PRESUPUESTO. DE IGUAL IMPORTANCIA ES QUE USTED INCREMENTARÁ SUS POSIBILIDADES REALES DE ENTREGAR ALGO QUE EL CLIENTE QUIERA (O NECESITE).
ESCENARIO: ¿POR QUÉ FALLAN LOS PROYECTOS DE SOFTWARE?
SOLUCIÓN: ENTRE LAS DIFERENTES CAUSAS QUE LLEVAN AL FRACASO DE UN PROYECTO DE SOFTWARE, LA TECNOLOGÍA NO ES LA DETERMINANTE. ESTA SESIÓN SE FOCALIZARÁ EN PRESENTAR TÉCNICAS Y HERRAMIENTAS ADECUADAS PARA PREVENIR ESA SITUACIÓN, TOMANDO ALM (APPLICATION LIFECYCLE MANAGEMENT) COMO REFERENCIA.
HAY OTROS TEMAS, COMO MIGRANDO A SOA, MEJORAR LA CALIDAD DEL SOFTWARE, Y LA IMPLEMENTACIÓN DE UN PORTAL CMS, USANDO DOTNETNUKE.
PERO ME GUSTARÍA HOY ENUMERAR RÁPIDAMENTE ALGUNAS DE LAS CAUSAS POR LAS QUE FALLAN LOS PROYECTOS DE SOFTWARE. NO SERÁ UNA LISTA ORIGINAL EN CONTENIDO, Y SEGURAMENTE UDS. PODRÁN APORTAR OTRAS CAUSAS O EXPLICAR MEJOR ALGUNA DE LAS QUE PRESENTE. SIN PONER UNA PRIORIDAD, VEAMOS ALGUNAS CAUSAS:
NO SE TIENE EN CLARO QUÉ HACER: LOS REQUERIMIENTOS SON DIFUSOS, SE TOMAN MAL, Y TERMINAMOS HACIENDO ALGO QUE EL CLIENTE NO NECESITABA NI QUERÍA. NO SE ENTIENDE CUÁL ES EL PROBLEMA A SOLUCIONAR, EL PROBLEMA DE NEGOCIO, EL VALOR QUE NUESTRO ENTREGABLE DEBE APORTAR AL CLIENTE. SE PIENSA MÁS EN DETALLES TÉCNICOS QUE EN LO QUE REALMENTE IMPORTA.
EL CLIENTE PARTICIPA UNA VEZ CADA SEIS MESES: NO SE HABLA CON EL CLIENTE, SE TRATA DE EVITARLO. SE LO CONSIDERA MÁS UN «ENEMIGO» QUE PARTE DEL PROYECTO. CADA VEZ QUE ENTREGAMOS UN AVANCE DE LA SOLUCIÓN, NOS DAMOS CUENTA QUE LO QUE ENTREGAMOS NO ERA LO QUE EL CLIENTE ESPERABA.
GENTE NO DEDICADA AL PROYECTO: SE LANZA EL PROYECTO, PERO LA GENTE QUE LO LLEVA ADELANTE SE DEDICA MIENTRAS TANTO, A OTROS PROYECTOS SIN TERMINAR, SOPORTE DE CLIENTE, MESA DE AYUDA, A MOVER MÁQUINAS DE UN LADO A OTRO POR CUALQUIER CAUSA.
LA GENTE DE VENTAS PROMETIÓ EL ORO Y EL MORO: PASA EN MUCHAS CONSULTORAS. POR UN TEMA DE COMISIONES, O DE POSICIONAMIENTO EN EL MERCADO, SE OFRECE UNA SOLUCIÓN «INFLADA» QUE NO CORRESPONDE CON LO QUE PODEMOS HACER.
NO CONOCER Y ENTENDER LA TECNOLOGÍA: HAY QUE CONOCERLA Y ENTENDERLA. NO SÓLO ES SABERSE DE MEMORIA LOS NAMESPACES DE .NET, O LA CONFIGURACIÓN DE SPRING: HAY QUE ENTENDER PARA QUÉ ESTÁ CADA COSA QUE USAMOS.
USAR MAL LA TECNOLOGÍA: HAY QUIENES CREEN QUE USANDO J2EE Y PATRONES TODO QUEDA SOLUCIONADO: SEGURIDAD, ESCALIBILIDAD, ETC, SIN DETENERSE A PENSAR EN QUÉ AFECTA LA TECNOLOGÍA Y LAS DECISIONES DE DISEÑO EN LO QUE QUIEREN LOGRAR.
CUALQUIER PROBLEMA LO ARREGLAMOS CON MÁS GENTE: EN VEZ DE ENCARAR EL PROBLEMA DE RAIZ. AGREGAR MÁS GENTE A UN PROYECTO CON PROBLEMAS, ES COMO HECHAR QUEROSENE AL FUEGO.
EQUIPO MALFUNCIONAL: EN EL EQUIPO HAY GENTE QUE NO SABE TRABAJAR EN GRUPO, TENEMOS «PRIMA DONNA» QUE HACEN LO QUE QUIEREN, EN VEZ DE HACER LO QUE EL PROYECTO NECESITA.
CAMBIOS PARA MAÑANA: VIENE ALGUIEN, DE VENTAS O DE GERENCIA, PIDIENDO CAMBIOS PARA EL VIERNES, Y ESTAMOS EN LA TARDE DEL JUEVES.
FALTA DE RECURSOS: SE NOS PIDE DESARROLLAR EL PRÓXIMO YOUTUBE + FACEBOOK, CON UNA MÁQUINA IBM XT DE UNA DISKETTERA.
COMPLICAR LA SOLUCIÓN: PARA COMUNICAR UNOS DATOS A OTRA APLICACIÓN, ADOPTAMOS UN ESB, DOS SISTEMAS DE COLA DE MENSAJERÍA, UNA BASE DE OBJETOS, DOS RELACIONALES DE ÚLTIMA GENERACIÓN, Y CUATRO ESPECIFICACIONES DE WEB SERVICES, APLICANDO TRANSFORMACIONES XSLT ANTE CADA PASO. TAL VEZ UNA SIMPLE PROGRAMA HUBIERA DADO EL MISMO RESULTADO.
FALTA DE COORDINACIÓN Y COOPERACIÓN: EN UN PROYECTO GRANDE, HAY VARIOS EQUIPOS, POSIBLEMENTE DE DISTINTAS CONSULTORAS, RESOLVIENDO DISTINTAS PARTES DEL PROYECTO. LO QUE UN EQUIPO HACE, LO NECESITA OTRO, PERO COORDINAN MAL LA ENTREGA Y PRUEBA DE LAS PARTES. LOS EQUIPOS NO SE VEN COMO COLABORADORES: CADA UNO HACE LO SUYO, Y SI OTRO EQUIPO TIENE PROBLEMAS, CONSIDERAN QUE NO ES PROBLEMA DE ELLOS. TAMBIÉN PASA ESTO ENTRE PERSONAS DE UN MISMO EQUIPO.
CONCLUSION
COMO PODIMOS NOTAR EN EL CONTENIDO DESGLOSADO DEL TEMA, OBSERVAMOS DETALLADAMENTE LOS PUNTOS Y CARACTERISTICAS DE UN PROYECTO DE SOFTWARE Y LAS TOMAS DECISIONES INTELIGENTES, MUCHAS VECES SEPARA LOS PROYECTOS EXITOSOS DE LOS FRACASADOS. NO DEBERÍA SER DIFÍCIL DE IDENTIFICAR UNA MALA DECISIÓN ANTES DE HACERLA.
ADEMAS POCAS COMPAÑÍAS INSTITUCIONALIZAN UN PROCESO PARA APRENDER DE SUS ERRORES. SI NOSOTROS COMO DESARROLLADORES NO NOS TOMA EL TIEMPO DE ANALIZAR QUÉ PASÓ DURANTE UN PROYECTO, LO BUENO Y LO MALO, NO TENDREMOS OTRA COSA QUE REPETIRLO.
TAMBIEN PODIMOS ENCONTRAR UNA SOLUCION DE ENTRE LAS DIFERENTES CAUSAS QUE LLEVAN AL FRACASO DE UN PROYECTO DE SOFTWARE, LA TECNOLOGÍA NO ES LA DETERMINANTE. ESTA SESIÓN SE FOCALIZARÁ EN PRESENTAR TÉCNICAS Y HERRAMIENTAS ADECUADAS PARA PREVENIR ESA SITUACIÓN, TOMANDO ALM (APPLICATION LIFECYCLE MANAGEMENT) COMO REFERENCIA.
BIBLIOGRAFIA
http://www.ajlopez.com/
INTEGRANTES DEL EQUIPO:
MARINA AGUILERA AZAMAR
SERGIO CHAPARRO SANDOVAL
IVAN DE JESÚS CASTELLANOS HERNANDEZ
LUIS MANUEL MENACHO RAMIREZ
FERNANDO MORALES RANGEL
RADIEL RODRIGUEZ REYES
Radyel's Blog 