Jos Mara Obando B.

A continuacin encontrar una narracin de experiencias relacionadas con el proceso de desarrollo de software y recomendaciones para su identificacin en situaciones de la vida real. No es una explicacin de lenguajes de programacin, ni de artefactos o metodologas de software, es simplemente una exploracin de las situaciones desde el punto de vista de quin por muchos aos, en mi caso 18 aos, ha dedicado su vida a mejorar los procesos de negocios de empresas mediante la produccin de software.

Lima Per

07/04/2013

Introduccin
Este documento se estructura bajo la motivacin de que el software no es solo ingeniera y que hay muchos inconvenientes y temas que no los aborda ninguna metodologa de software a los cuales se debe prestar atencin antes y durante la ejecucin de un proyecto. No reclama de las metodologas formales de proyectos, pero si deja claro hasta donde es bueno seguir esquemas rigurosos de proyectos y hasta donde es bueno tener una percepcin del proyecto directa, no solamente cifras o roles de personas.

Contenido
Incertidumbres y Riesgos .................................................................................................................... 4 Egos en conflicto ............................................................................................................................. 4 Requerimiento difuso...................................................................................................................... 5 Herramienta desconocida ............................................................................................................... 6 Proceso de negocio inmaduro......................................................................................................... 7 Falta de compromiso del usuario .................................................................................................... 8 Ausencia de mtricas de las actividades ......................................................................................... 9 Estilo de desarrollo no orientado a objetivos ............................................................................... 11 Desconocida capacidad de los recursos participantes .................................................................. 12 Dificultad para justificar o precisar el costo del proyecto ............................................................ 13 Primeros, segundos o terceros interesados en que el proyecto no salga.. .................................. 15 Sobre el Desarrollo de software........................................................................................................ 17 Traslape tecnolgico.. ................................................................................................................... 17 Esquematizar Alcance y Actividades ............................................................................................. 18

Incertidumbres y Riesgos
Egos en conflicto
Tpicamente un proyecto de software nace como una necesidad de un rea o empresa.. Ya sea que la desarrolle internamente un equipo o que se contrate a un tercero. Lo primero que encontrar en la primer escarbada del tema ser a un grupo de colaboradores (o a un solo individuo, en el peor de los casos) orgullosos de sus procesos manuales, de sus fallidos o semiexitosos intentos de automatizacin - nunca bien reconocidos, ni premiados por el pblico-. Probablemente ese ser el escenario ms normal, quien est orgulloso de sus esfuerzos anteriores lo inundar con detalles, algunos hasta irrelevantes de los escenarios, incluir en muchas ocasiones referencias a los documentos, correos, y otras gestiones de su autora. En esos casos la mejor postura es no desestimar el esfuerzo anterior pero siempre concentrarse en el verdadero objetivo, ya sea de la empresa o del rea donde se vaya a desarrollar el proyecto. Se debe tener siempre en mente que todo lo anterior por algo ya no se va a usar, y es peligroso apuntalar un nuevo proyecto con bases que ya fueron desgastadas por otros procesos de desarrollo previos.. Abstraer el concepto, pero no el procedimiento, ms si se incluye herramientas de legado o procedimientos con nombres y apellidos (as lo haca yo cuando no tena computadora, si quiere le traigo a la persona que lleva 10 aos haciendo lo mismo, haba un proceso automtico documentado pero mejor le explico como lo terminamos haciendo nosotros cuando se fue el otro jefe..) ah escudrie con cuidado, la sensibilidad ms grande de las personas est en el reconocimiento y/pero, su mayor miedo.. He mencionado actitudes positivas, disposicin, necesidad de reconocimiento, pero existen y vaya que existen muchos ms escenarios, donde el dueo del conocimiento para el proyecto, no es quien lo patrocina, ni ninguno de sus sbditos, sino ms bien el ms acrrimo rival del jefe, aquel que nunca fue tomado en cuenta y que conoce todo, el orculo del proceso. Y que por esa falta de remuneracin, buena relacin laboral, peligro de despido, obsolescencia tcnica o inmadurez profesional, va a convertir la extraccin de la informacin y la abstraccin del proceso en un reto interminable. Ahora bien cuando logre estar de frente a la fuente de la informacin y est tratando de esquematizar el proyecto con una base ms consciente, encontrar entre sus pares y superiores a aquellos que lancen las tpicas preguntas capciosas: cuanto va a durar en eso??, que herramienta va a usar??, usted cree que ya sabe lo suficiente para comenzar el proyecto??, se anima usted solo, ocupa ayuda??. Yo ya lo intent y no pude??.. Adems de las tpicas serruchadas de piso, de quien prob hacer ese proyecto y no lo pudo dimensionar y ante la nueva oportunidad descargar toda su ofensiva destructiva de envidia y tratar a toda costa de ocultar el xito del nuevo proyecto. Ante todo eso, debe no slo perseverar, sino dar pasos cortos, pero decididos que manden un mensaje a los dems de que se tiene una intencin sana y clara de lo que se quiere hacer. Ahora que si entre todos esos egos no descubre una visin compartida con un colaborador y/o contraparte que pueda ser el patrocinador..NO LO INTENTE!!

..el proyecto no tiene cabeza, y usted por complacer a todos puede terminar siendo cocinado en la hoguera de las brujas..

Requerimiento difuso
Cuando va a trabajar un proyecto de software tpicamente tendr que priorizar sus actividades, como en cualquier proyecto en general. Y siempre se encontrar un conjunto de requerimientos medibles, acotados, con abundante documentacin, proceso de negocio maduro, usuarios comprometidos y otras condiciones ideales. Esos requerimientos definidos, trate de ubicarlos de primeros en su proceso de desarrollo. Convenza y cuide de que la prioridad de los requerimientos no vaya en funcin de los intereses del usuario (Cmo??, as debiera ser, pero tal vez no, puede que ese inters del usuario vaya en contra de la percepcin y resultados de su proyecto). Si lo que ms le interesa al usuario es lo que est menos claro, an no se ha madurado como proceso de negocio o implica un esfuerzo de anlisis mayor, NO DESGASTE al equipo de desarrollo nadando en tempestad, primero vaya por aguas mansas y cuando vea que el tiempo amaina trate de cruzar el ocano.. Tpicamente los proyectos o desarrolladores quemados, se enfrescaron en los requerimientos inciertos, donde: Haba cambios de parecer Continuas iteraciones con percepcin de no avance. Especificaciones desactualizadas o ambiguas. Documentos sin firma de responsable Reuniones donde se dijo que el problema era muy grande, pero en la minuta no se encuentra ningn acuerdo Minutas que regresan sin firmas de los participantes Minutas que regresan con tantas observaciones que pareciera que no hubo reunin. Usuarios que dicen que no entienden un documento tcnico o son renuentes a firmarlo Usuarios que no leen los documentos e insisten en la tradicin oral para especificar todo su proceder Tomadores de decisiones que se ausentan de las reuniones importantes o mandan a un chivo expiatorio para que no figure su firma en los acuerdos Personal que se nota excesivamente nervioso o distrado, con continuas llamadas telefnicas o intervenciones de subalternos o secretarias que interrumpen las reuniones Excesiva rotacin en los puestos operativos o mandos medios donde se va a implementar la solucin. Todas esas caractersticas producen un requerimiento difuso, ambiguo o demasiado voltil. Una vez detectadas algunas de esas caractersticas, no es muy decoroso salir corriendo, pero si est en sus manos la toma de decisiones, patee lo ms adelante posible esos requerimientos hasta que tenga alguna certeza de que va a poder generar una percepcin de solucin.

Recuerde siem pre que el softw are si es tangible com o bits, pero un

requerim iento solo es al fin y al cabo una acotacin ex itosa de una intencin, pero que para ojos del usuario estar finalizado, solam ente si se gener una percepcin real y positiva de la solucin.

Herramienta desconocida
Pasa que se tiene un proyecto, se tiene desarrolladores, pero no se tiene la herramienta. Y puede que la herramienta ideal para el proyecto sea desconocida para el equipo de desarrollo. O puede suceder lo contrario el equipo de desarrollo est entusiasmado con una nueva herramienta que ampla su mercado laboral y es innovadora, pero que no tiene ninguna relacin con el proyecto a desarrollar. Peor an si alguien recin llegado o que quiere ser protagonista lanza la habitual pregunta y.. cuanto cree usted que van a durar con esa herramienta??...y ese silencio..solamente se escuchan los grillos en el jardn.. Pues resulta que no, no hay que dar fechas..primero revise si tiene un framework (herramienta ms un conjunto de clases o procedimientos base que le permite superar la curva inicial de desarrollo). Es una herramienta con licencia??, sabe usted cuando se vence. Va a desarrollar para un producto que de por si tiene licencia, es un producto con fuentes abiertas o gratuitas. Revise el contrato de adquisicin puede que est enfrascndose en un proyecto que no se puede hacer porque no puede tocar los fuentes de su herramienta o aplicativo soado. Cuenta con una versin estable de la herramienta o los aplicativos, si no es as, no se atreva a dar una fecha...se va a quemar tratando de estabilizar el producto y la percepcin de los usuarios nunca va a estar alineada con los resultados a corto plazo que usted pueda dar. Si la herramienta es muy vieja, est listo, sus desarrolladores no van a sentir la misma motivacin para trabajar y puede que el proyecto se alargue simplemente por no tener una herramienta "fashion".

Cudese de los falsos conocedores, son fciles de detectar, encubren todos sus desconocim ientos, no necesita m s de 1 hora trabajando fuentes con ellos para darse cuenta de que conocen, pero cuidan m s su prestigio que su creatividad y al final, dan de cuenta gotas de lo poco que saben y hacen del proyecto una guerra para ahuyentar a los que si quieren aprender e investigar .

Adems por lo general estn cargados de certificaciones y desmeritan a todo el que se aparezca sabiendo y que no haya pagado lo mismo que ellos por los cursos. Si ya consigui un equipo de desarrolladores comprometidos, entonces dese oportunidad de hacer un piloto, no los tire a la guerra. De unos primeros pasos con ellos y mida (saque sus propias mtricas de como desarrollan), con base en eso puede despus animarse a ir avanzando secciones de un proyecto, pero no extrapole demasiado, recuerde que la gente no es constante y que de la naturaleza del problema puede venir el mayor atraso en un desarrollo.

Proceso de negocio inmaduro

Si usted necesita dinero extra y es un proveedor sin mucho escrpulo ofrezca un contrato de desarrollo anual a una empresa que tiene un proceso de negocio inmaduro. Sepa que no le va a faltar trabajo, porque mientras el proceso est en esa etapa se generar cualquier cantidad de requerimientos, eso s nunca se preocupe por finalizarlos..es imposible.. Sntomas que usted observar fcilmente: Cada empleado le cuenta su propia versin de lo que hace, y curiosamente en dos puestos del mismo cargo, los empleados hacen lo mismo de maneras totalmente diferentes. El jefe tiene inters en unas mtricas e ndices de gestin que sus subalternos nunca le proporcionan y es ms le dicen que es imposible sacarlas. Los subalternos hacen tareas repetitivas pero no se dan cuenta de ello, consideran que todos los das el quehacer diario es un nuevo reto. En ningn escritorio o puesto de trabajo encontrar un diagrama, flujo o texto que indica las principales labores y responsabilidades del empleado. Y si lo encuentra puede ser un documento de ms de 2 aos y correspondiente a un puesto o empleado distinto del que ocupa el espacio actual. Si le comentan que algunos empleados ascendieron para cubrir actividades que el sistema no puede hacer y que ellos tienen que rehacer manualmente. Tenga an ms cuidado, porque ah no slo hay inmadurez del proceso, sino una actitud adrede de desmejorar para generar ms trabajo. Si cada empleado es una isla y no se comparte conocimientos, ni tips, entre ellos. Si la rotacin de personal es muy alta y cada nuevo empleado no recibe una capacitacin formal de su puesto de trabajo. Si a los nuevos empleados y a los rasos se les asignan "responsabilidades" apenas ingresan. Ese es un signo bien marcado de inmadurez del proceso, si lo encuentra multiplique por 10 su "score". Si al irse un empleado que realiz una mejora quedan sus cuadernos de apuntes tirados en el escritorio y los discos duros llenos de explicaciones y documentos que nadie ms tiene como referencia. Si la empresa tiene subcontratado a un tercero que da soporte a los aplicativos pero que nunca cambia las versiones, ni hace mejoras de fondo que ayuden a los usuarios a trabajar ms eficientemente. Ante todos estos sntomas y otros ms, va a tener que agregar un cero a la derecha a su presupuesto final. Y preprese porque lo ms probable es que tenga que esperar bastante para poder aterrizar verdaderos requerimientos. Adems, su levantamiento de informacin puede convertirse en el mejor de los casos en una labor de ingeniera industrial de definicin y optimizacin de procesos de negocio, eso si realmente existe voluntad dentro de la organizacin para iniciar su proyecto de software.

Falta de compromiso del usuario

Le cuentan un problema y usted se suea la solucin, corre a buscar referencias, se acuerda de todo lo que aprendi en la U que le puede ayudar a solucionarlo, es proactivo y hasta le pone las palabras al usuario en la boca para que se hagan las mejoras.. Pero resulta que cada vez que usted llega a una reunin o revisa los correos del proyecto en vez de subir un escaln baja dos... Y usted cree que es un problema de empata, de que no llev la manzanita o el chocolate, de que tal vez no se supo explicar bien, de que su solucin es demasiado volada, fuera de presupuesto, o tal vez el usuario es muy bueno en sistemas y sabe una solucin mejor... Pero no se preocupe, probablemente no sea ninguna de las anteriores..ms bien puede ser la actitud que normalmente est motivada por dejar de hacer o dejar pasar..y que impide que los usuarios colaboren y se comprometan en un proyecto. Puede ser falta de motivacin, puede que el jefe no les haya delegado la toma de decisiones, que el reconocimiento no vaya a ser solamente para ellos, sino que los mritos se los va a llevar un tercero, o usted en el peor de los casos. Puede que si se hacen las mejoras algo en el entorno del empleado cambie y l est confortable as como est. Puede que la misma solucin ya la haya intentado otra persona con anterioridad y haya topado con piedra y ahora el usuario tenga un temor que no quiere divulgar. Tambin y ms relacionada con la estrategia de la empresa, puede ser que usted haya llegado en un momento de transicin, que la empresa est cambiando su proceso de negocio por una fusin, adquisicin, reorganizacin, etc..Entonces en esos casos es difcil que los colaboradores perciban como una salvacin la creacin de valor agregado, se cuidan y reservan todas sus capacidades y atencin a ver cmo va a cambiar la cosa..que les va a pasar ms adelante. Son pocos los que en circunstancias de incertidumbre de su propia empresa tienen claridad para especificar lo que quieren y seguir adelante, normalmente uno lo que se encuentra en esos casos es personal paralizado, que si a usted no le urge, es mejor dejar de visitarlos hasta que el periodo de cambio ya se haya asimilado. Otro escenario de falta de compromiso, puede ser cuando la persona que le asignen como contraparte sea la menos enterada o menos entusiasmada de por si con la idea. Y usted tiene expectativas y referencias del proyecto como de gran importancia, pero desde que llega nota apata, falta de inters, poca respuesta asertiva, ni siquiera una evaluacin concienzuda de sus correos, si ve la bandeja del usuario y sus correos de informacin estn todava en negrita, pida al superior de esa persona que le cambie su contraparte, puede que le haya tocado lidiar con un anula proyectos.

Com o antdoto a estas m ltiples circunstancias y si logra ubicar al verdadero prom otor de la idea, prstele sus m ejores conocim ientos, particpelo de sus hallazgos, dele todo el m erito, aunque sea com partido. M anifistele con franqueza su inters por sacar adelante el proyecto y si logra una com unicacin a buen nivel de confianza, trate de averiguar qu elem entos bloquean o estn divorciados con la iniciativa de su proyecto y lo m s im portante com o podra ganarse una m ejor aprobacin de la idea, siem pre que sea m ediante m edios ticos y transparentes.

Ausencia de mtricas de las actividades

Si a usted le piden dar un pronstico sobre una fecha de entrega de un proyecto, verifique que se hable de pronstico, no de fecha de com prom iso, que es distinto, si el usuario le indica una fecha de com prom iso, esa fecha es para cuando lo quiere el usuario y ah usted si puede dejarse cobrar lo que quiera y pedir los recursos que quiera, porque lo estn obligando a una fecha sin poder dar una segunda opinin.
Para esas situaciones es mejor que usted se prepare con anticipacin, sin hacer mucha bulla y con rigurosidad cientfica pero de bajo perfil. Trate de ir recolectando informacin del tiempo que toma llevar a cabo las tareas de sistemas y de procesos del negocio. Si usted es parte de la organizacin le ser ms fcil porque podr ir monitoreando bases de datos o apuntando cada cuanto se completa una tarea manual. Si es externo le va a ser un poco ms difcil y definitivamente si los procesos no son muy maduros, no es factible emprender esa misin porque los resultados pueden ser aleatorios. Pues bien, si logr recabar algunos datos, le sern tiles para medir sobretodo, el tiempo adicional que tendr que sumar por hitos que deben cumplir terceros o por trmites como creacin de respaldos, solicitud de fuentes, control de calidad, tiempos muertos al convocar reuniones con usuarios, por ejemplo. Algunos tiempos singulares de medir pero tiles en muchos casos son: Tiempo de compilacin de la aplicacin, tiempo que tardan los desarrolladores en levantar el ambiente de trabajo cada da despus de un receso, tiempo adicional dedicado en desplazar el equipo de trabajo a las oficinas del cliente, tiempos de almuerzo, celebraciones de cumpleaos, reuniones oficiales de la empresa. En general tiempo que se le debe restar a las horas productivas del equipo de trabajo. Tambin se debe tomar en cuenta al tratar de medir el tiempo de trabajo, que a mayor cantidad de tiempo de un recurso dedicado a una tarea, menor su rendimiento. Es preferible tener un recurso en dos proyectos medio tiempo, que dedicarlo 100% toda la semana a la misma actividad, o que solamente programe 50% y el otro 50% lo dedique a disear o hacer pruebas. La produccin tiende a decaer por embotamiento. Cuando tenga un dato claro del tiempo que le tomara realizar en actividades adicionales y las horas promedio para un buen rendimiento de su equipo. Felicidades!!.. ya puede saber cuanto puede durar su equipo en labores repetitivas y predecibles. Pero no podr saber cuanto tiempo tardar pensando en resolver un problema a nivel de

abstraccin, depurar una pulga brava, que se esconde en un aplicativo, o cuanto tardar una reunin de lluvia de ideas para dar alternativas de solucin. Ah tendr que poner lmites de tiempo razonables, sobre una media de resultados anteriores, hasta que se oculte el sol, hasta que vuelva a salir el sol..o hasta que el oficial de seguridad de su cliente pase a cerrar las oficinas... Tambin tenga cuidado de no extralimitarse, si usted trata de correr al pensar..puede que deje temas inconclusos en el camino y eso para un proyecto o requerimiento puede ser difcil de retomar. Inclusive si calcula una proporcin de 8 horas para definir el requerimiento a nivel de anlisis y 40 para desarrollarlo, puede que esa ponderacin para algunos requerimientos sea demasiado corta para el anlisis y deje como resultado tareas pendientes que tendr que asumir en la etapa de desarrollo (esa ponderacin 8/40 tiende ms a estar apegada a metodologas de desarrollo en cascada pero la incluyo como referencia nicamente).

Si lo que usted tiene com o horizonte es term inar un requerim iento para luego retom arlo com o soporte..adelante!!..aventrese a dar tiem pos rgidos para abstraer los problem as, ah solam ente debe cuidarse de acotar bastante la solucin, ya que los cabos sueltos los podr disim ular y dejar pendientes para la siguiente etapa.

Estilo de desarrollo no orientado a objetivos

Aunque el proyecto est bien enm arcado, puede que la cultura de las personas que van a participar en l no est alineada con el desarrollo de proyectos, sino que estn bajo un perfil m s bien de soporte o de continuidad dentro de la em presa.
Si el equipo de trabajo est acostumbrado nicamente a cumplir horarios, si la organizacin tiene personal interesado nicamente en sobrevivir en su puesto, peor an si parte del personal solo piensa en pensionarse en su puesto. Es difcil que el proyecto de software tenga un horizonte claro. Usted plantea el proyecto para resolver una necesidad, define los objetivos que quiere cumplir, pero su personal o equipo tiene otra necesidad que considera primordial y se distrae u obvia el objetivo principal. Usted quiere disear una aplicacin modular, pero su equipo quiere conocer el proceso de negocio para preservarse en el puesto cuando termine el desarrollo. Usted quiere delimitar el desarrollo para dar entregables claros de corto plazo, el desarrollador quiere asumir todo el problema y resolverlo todo de una sola vez y programa y programa y sigue programando sin ver la luz.. Usted pone sobre la mesa al usuario que es lo que percibe que se necesita, el usuario es un jefe o tiene un jefe que no ha detectado esos objetivos o no est seguro de cuales son realmente los objetivos del puesto o rea donde se va a desarrollar. Entonces aunque se pretende resolver el problema no se sabe a dnde se va a llegar.

Si ha detectado alguna de estas condiciones trate de delim itar bastante el proyecto y no incluya dentro del desarrollo de su proyecto aquellos tem as que podran distraer al equipo o al usuario. Y si detecta que el tem a est m s para pasarlo a soporte que para desarrollo, m ejor no invierta m ucho recurso en esa iniciativa.

Desconocida capacidad de los recursos participantes

Un proyecto puede tener fallas de estim acin y descontrol si no se conoce la capacidad y rendim iento de los recursos participantes.
Usted llega al proyecto y encuentra los recursos asignados o le dicen que los contrate pero ya el puesto tiene nombre. De buenas a primeras usted no va a exigir al equipo que rinda al 100%. Porque: Puede que esas personas tengan muy poca experiencia en la herramienta. La experiencia sea de soporte de un aplicativo ya estable y las destrezas sean ms de configuracin o de reportera. La experiencia sea regular en la herramienta pero las bases acadmicas sean muy dbiles. No abstraen, no entienden de procesos de negocios. Sean desarrolladores muy experimentados pero demasiado comprometidos con otros proyectos. Puede que su equipo est conformado por jefes que aunque parezca mentira ya se les olvid como trabajar en equipo, solo saben asignar trabajo y no se comprometen a hacer el suyo propio. Puede que el equipo se haya conformado de manera ideal pero en el intern del arranque del proyecto, de pronto se cambie la herramienta. Si el proyecto se desarrolla en otro pas tiene que tener an ms cuidado, porque hay personas que al cambiarles el estilo de vida, tienden a bajar su rendimiento, les da mal de patria, se enfiestan ms de lo que trabajan, chatean, fb-ean ms de lo normal, etc. Puede que sean excelentes tcnicos, pero al poco tiempo de tratarlos usted se da cuenta de que les cuesta entender procesos de negocio, y ellos solamente van a hacer lo que les digan pero les va a costar abstraer los problemas aunque tengan formacin universitaria.

Com o cualquiera de estas caractersticas se puede presentar en su equipo de trabajo, an siendo colaborador y no jefe del proyecto, lance la alerta desde el principio, no se m ande a hacer todo el proyecto, sin tener una base del desem peo .
Debe tener una referencia de al menos un mes de ver cmo trabajan los colaboradores, sino su proyecto se va a alargar ms de lo esperado y puede que algunos recursos se vayan a quemar rpidamente porque se les asign demasiada carga o asumieron la responsabilidad ajena por tener ms compromiso o tica.

Dificultad para justificar o precisar el costo del proyecto

An cuando exista control presupuestario bien llevado en una empresa, haya asignacin de recursos tecnolgicos fijos y otras condiciones que permitan tener alguna holgura a la hora de acometer proyectos de software, hay algunas seales que le pueden alertar de lo que va a pasar: Si el patrocinador del proyecto dice, "vayan trabajando en eso, y yo estoy seguro que eso le va a interesar a la gerencia". El usuario estrella que conoce a la perfeccin el proceso de negocio, cree que esa aplicacin va a ser lo mejor que va a aportar ese ao, aunque no est enterado de los objetivos de su rea o las nuevas polticas por aplicar. Se cree que eso es muy bueno, todos estn parcialmente comprometidos, pero antes de que arranque el proyecto usted se da cuenta que ningn rea ha reservado el presupuesto para su proyecto y esperan que Sistemas asuma el costo o bien cuando la empresa es externa..le proponen que lo desarrolle y una vez que lo finalice se lo van a pagar. El alcance del proyecto es tan difuso o ha sido expuesto de una manera tan idealista, que nadie se anima a ponerle cifras a aquello. Todos se pasan "la papa caliente" y al que le toque la pregunta angustiante, tendr que responder cuando, porque, quien, para que??... Sistemas est totalmente convencido de que eso ayudar a la empresa, ve los indicadores de negocio, revisa documentacin y casos de xito en otras empresa, pero, para los funcionarios del rea objetivo, eso no les ayudar a mejorar sus ingresos personales, cambiar funciones de los puestos de trabajo o pondr en peligro el puesto de ms de uno.

Entonces desde ah el proyecto nace m uerto, y el costo ser elevadsim o , porque se

culminar hasta que los empleados en peligro encuentren una nueva forma de justificar su salario. Inmadurez en procesos de negocio y en administracin de proyectos. Si para los funcionarios patrocinadores, ese costo debe distribuirse dentro de las asignaciones presupuestarias de soporte de sistemas. Todo cambio, pasa por soporte, sin medir su impacto a nivel de organizacin o los recursos requeridos. Entonces el proyecto muere por no tener un flujo adecuado. Tal vez inicie con el sacrificio de algunos presupuestos ociosos, pero una vez que arranque y requiera continuidad, los recursos asignados para soporte sern insuficientes y los patrocinadores se cansarn de pedir resultados de corto plazo. Se contrata a un tercero que no tiene el "know how" adecuado y que calcula su ingreso a partir del costo interno que significara el proyecto, para anular la competencia interna (dumping)..pero al no tener el panorama claro, incurrir en gastos adicionales que no tiene previstos, entonces o abandonar el proyecto regalando a los desarrolladores o culminar con prdida y mil acotaciones para ganar una referencia de cliente.

El usuario manifiesta sus expectativas una y otra vez, pero nunca las pone por escrito o peor an, las cambia constantemente para complacer a cada interesado. Entonces las actividades del proyecto no quedan bien definidas y el costo se puede disparar una vez que se inicien las primeras iteraciones y se revise nuevamente el alcance.

P ara todo esto la m ejor recom endacin es no vender proyectos dem asiado am biciosos o com prarle iniciativas difusas a los clientes, ya que la posibilidad de variaciones en el alcance aum enta y por lo tanto el riesgo de incurrir en gastos incalculables .

Primeros, segundos o terceros interesados en que el proyecto no salga..

En todo proyecto de software las personas colaboran, se ausentan, obstruyen el proyecto, ponen peros o desinforman sobre los resultados, por distintas motivaciones. A continuacin enumero ejemplos de condiciones que pueden y se dan en la mayora de los proyectos de software. El colaborador del equipo que goza de una ventaja econmica o de ubicacin de transporte y no quiere por ningn medio que se le altere su patrn de vida confortable. El encargado de mantenimiento externo o interno que ve como sus comisiones por reparar emergencias se esfuman si el nuevo sistema es ms estable o est mejor configurado. El usuario que justifica su salario por las constantes intervenciones, atrasos y molestias entrecomillas (muchas simuladas) que le causa el sistema antiguo, porque para el nuevo sistema tendra que volver a fabricarse otras mmicas o ya no seran tan crebles. El jefe que basa su autoridad en someter a sus subalternos a tareas humillantes y sin sentido so pretexto de que eso no lo hacen los sistemas y solo se puede hacer a mano y el nuevo sistema lo hace y demuestra que sus reportes a gerencia eran errneos y por gusto maltrata a los novatos. La empresa externa que est deseando vender un subproducto, un paquete antiguo o un contrato de soporte para el software anterior y reza para que no se instale el nuevo. El empleado que se beneficia indirectamente por extraer informacin de los sistemas para trasladarla a la competencia o que evade controles del viejo sistema para generarse ingresos fraudulentos como por ejemplo, facilitndole datos a los proveedores y que con el nuevo sistema se va a ser ms evidente su proceder. El jefe que ha hecho manejos indebidos o poco claros y que cuando se hagan cuadres para migracin se va a exponer a todos los niveles de la empresa sus datos dudosos. El gerente que dice que debe cambiarse el sistema pero que cambia de actitud si se tiene que quitar a la chica (amante, amiga,) que hace alguna tarea manual. Y se enfrenta a quien sea con tal de salvarla y es capaz de sacar de la empresa a quien trate de echar a andar el sistema. El ingeniero "emprendedor" (tuerce brazos y coimero para obtener contratos) que est formando una empresa y justifica la contratacin externa de su personal por la ineficiencia y dificultades del sistema anterior. Y ve que con el nuevo sistema su contrato se pone en entredicho. El proveedor de hardware o el de software que ve como su cliente estrella se cambia de plataforma y hace hasta lo imposible para botar el nuevo sistema con tal de que le sigan pagando sus contratos anuales y compren o alquilen sus fierros aunque estn subutilizados.

Hasta los conserjes o los vigilantes, si los dems empleados los convencen y manipulan dicindoles que el nuevo sistema les va a quitar privilegios o les va afectar sus ingresos.

A veces las lim itaciones tcnicas que se im ponen a un sistem a, no son tales, son barreras de las m ism as personas que ven afectado su status quo, por no decir su bolsillo o vicios cuando se cam bia de sistem a.
En ese caso, no queda ms que tomar una posicin, si es posible, ser neutral, siendo externo esa posicin queda muy elegante. Compasin de quien se haga el perjudicado, pero sin hacerle caso del todo porque puede ser manipulacin y dejar siempre en claro que quien est haciendo el cambio es la misma empresa, no usted, no se compre enemigos por puro gusto. Siempre resalte quien es el verdadero patrocinador y controlador del proyecto y cules son los objetivos que le han propuesto llevar a cabo.

Sobre el Desarrollo de software

Traslape tecnolgico..
Resulta que usted es invitado a resolver un problema. Su requerimiento es claro, a nivel funcional y tcnico. Existen requerimientos no funcionales que usted aclara dentro del contexto del problema que le plantean. Hasta ah todo muy bien. Mientras usted va desarrollando, escucha con cierta frecuencia a otros equipos o terceros hablando del mismo dominio del problema, incluso refirindose conceptualmente a los mismos problemas que usted tiene en su desarrollo, pero particularmente hablan de otra tecnologa. Pues si, en muchos casos usted se encontrar con traslapes de proyectos, uno o ms desarrollos que son funcionalmente muy parecidos y hasta lo mismo pero desarrollados en distintas tecnologas.

Esto no es ex trao en softw are, surge por la necesidad de m antener el softw are actual, pero adem s con la tendencia natural a evolucionar.
En las empresas donde se tiene claro el avance de la tecnologa y se tiene un plan de mejora, muchas veces se encontrar con varios sistemas en soporte o mantenimiento que necesitan seguir resolvindose dentro de sus propios requerimientos funcionales y a su lado, encontrar nuevas propuestas, algunas que quizs ni siquiera lograrn llegar a reemplazar al software actual, pero que por necesidad de mercado, visin o por antojo de alguno de los desarrolladores, se justifica invertir recursos en alguna nueva tecnologa. En las empresas de software donde se manejan "releases", versiones y se trata de mantener la misma solucin en distintas plataformas o IDEs, es ms usual encontrarse con el mismo aplicativo, pero con algunas adaptaciones tcnicas, y no tanto funcionales de acuerdo a la plataforma o framework sobre el cual se haya rediseado. La posicin en un traslape es ventajosa cuando se tiene el panorama completo de ambas o de todas las soluciones. Aunque parezca que se inventa el agua tibia, hay muchos factores de costos, de expiracin de licencias, de falta de conocimiento de los productos anteriores o incluso de nuevas adquisiciones de hardware o software que implican una duplicidad temporal en las aplicaciones.

P ero cuidado, la parte difcil es cuando se em pieza a hablar del trm ino m igracin , o de
descontinuar productos u otras. En ese momento se activa una alarma para todos los que estn en los productos traslapados, ya que habr fuerzas en conflicto, unos por retardar el cam bio lo

m s que se pueda para no perder la estabilidad o control del softw are anterior y otros pujantes por dem ostrar que la nueva o las nuevas soluciones dan un resultado m s adecuado, eficiente, m oderno o sim plem ente estable, con respecto al anterior sistem a o softw are .
Incluso esa disyuntiva va a abarcar a los propios usuarios. Ms de un patrocinador quitar las manos del fuego justo antes de echar a andar una nueva solucin cuando detecte diferencias en detalles del control, personal, modificaciones a bajo nivel, reportes personalizados u otras facilidades que le brindaban anteriormente y que con el nuevo sistema aun no est tan convencido.

Esquematizar Alcance y Actividades

Una vez que ya detect riesgos, mitig los que tuviera oportunidad de subsanar e identific las nebulosas y arenas movedizas de los requerimientos. Entonces ahora s, puede especificar las actividades a realizar. Tpicamente, casos de uso, o subsistemas en caso de un proyecto grande. La regla bsica para llevar un proyecto con buena presentacin es establecer hitos o entregables de buen impacto en la percepcin del usuario y adems que involucren los temas ms masticados y que por supuesto tengan menor incertidumbre. As que aleje las tormentas, nubes negras y cielos encapotados al inicio del proyecto y procure ir despejando el camino, trabaje siempre con metas cortas que le permitan estimar "el tiempo de maana estar soleado o seminublado" y que no lo tengan comindose las uas, pensando si realmente podr terminar las tareas en la semana. Muy importante independiente de la metolodoga que utilice de desarrollo, no com prom eta esfuerzos futuros considerando que todo le va a salir bien en la etapa actual . Siempre ponga por escrito, una vez finalizada la presente etapa, se reevaluarn objetivos y se redefinir o acordar el alcance de la siguiente . Inclusive con el mejor de los usuarios, puede que usted suee con una segunda etapa para impresionar al gran pblico, pero de camino en la primera fase el usuario entre en conciencia de que el proyecto es an ms grande y que o ampla el alcance o redefine expectativas y resultados. Y eso significa que usted tambin debe adecuar su plan de trabajo para ir resolviendo los temas ms aterrizados y prioritarios, no necesariamente los que le hubiera gustado presentar en primera instancia.

En cada iteracin entere al equipo del objetivo y a los usuarios del entregable. Ex plique a su equipo porque no va a hacer todo el proyecto de una vez y porque algunos tem as prefiere postergarlos.
Es importante que todos los miembros en su equipo expresen las mismas opiniones o tengan claros los mismos objetivos a la hora de comunicar a terceros. Los hroes que se lanzan en pos de sus propias campaas, muchas veces se desgastan ms de la cuenta y en ciertas ocasiones crean una expectativa ms alta de lo que se puede resolver en una iteracin corta.

Ex plique a su equipo adem s el concepto de que "todo puede cam biar" y que eso no es pecado.
Aunque en algunas ocasiones se encontrar seguidores crdulos que le siguen incondicionalmente, ser en el menor de los casos, por naturaleza las personas esperan analizar los titubeos y ven muchas veces en los cambios de rumbo, la duda en la preparacin de quin los dirige o aporta en un proyecto.

Aclare m uy bien que en softw are nadie tiene la culpa de los cam bios de decisin, debe ser una responsabilidad com partida y no unilateral.
Excepto que el usuario o un miembro diga: "esto se hace as, porque me da la gana". Todo cambio es justificable, siempre y cuando la decisin o requerimiento que se cambia, en un principio haya

sido acordado entre varios o haya llegado crudo de otra etapa y se tenga pleno convencimiento de que debe ser evolucionado. Y sobretodo no olvide de docum entar las ex pectativas y los cam bios , no para incriminar a las personas, sino para que al cierre del proyecto se refleje la sana evolucin de las ideas y bueno, para que se justifique de m anera transparente el costo a nivel de presupuesto de proyecto . Aunque existen artefactos (estndares de documentacin) muy buenos para expresar el alcance y las actividades del proyecto. Es muy valioso el aporte que pueda dar el equipo preparando presentaciones y haciendo esquemas libres en pizarra.

Con slo atreverse a dibujar el "big picture" o panoram a general , se tiene una idea del
"bosque", y a partir de ah se puede decidir que rboles podar primero. Y cuales reas son ms inaccesibles o definitivamente intocables en un principio. Sintase en confianza en un principio de hacer consultas sobre requerimientos no funcionales, ya que si deja en duda esos temas, puede que la solucin ms impactante del proyecto sea inviable tcnicamente y eso solo lo puede averiguar si a la par de sus deseos de hacer pantallas, pginas o cdigo hiper-poderoso, se dedic un rato a ver de qu manera iban a almacenarse o fluir los datos en el entorno del proyecto y con qu infraestructura mnima se podra soportar.