MIS 2009 Turin

UNIVERSIDAD TECNOLGICA NACIONAL FACULTAD REGIONAL BUENOS AIRES
Tesis para optar al grado de Magster en Ingeniera de Sistemas de Informacin
MODELO DE MEJORES PRCTICAS PARA LA ADMINISTRACIN DEL FACTOR HUMANO EN LOS PROYECTOS DE TI
HERNN ALEJANDRO TURIN

DIRECTORA: MAG. ALICIA L. MON
2009
DEDICATORIA
A DIOS, por haberme permitido llegar hasta este punto y darme la salud para lograr mis objetivos, adems de su infinita bondad y amor. A mi esposa Norma y a mi hija Jazmn por el tiempo que les rob y que deb compartir con ustedes. Jazmn, A mis padres Mara y Carlos por apoyarme siempre y ensearme el valor del esfuerzo. Carlos, A mis hermanos Fabricio y Milton por motivarme siempre en mis emprendimientos. Milton,
AGRADECIMIENTOS
A la Universidad Tecnolgica Nacional, por abrirme siempre las puertas para cumplir con mis Nacional estudios de grado y posgrado. A mi directora de tesis Mag. Alicia Mon, por haberme guiado e incentivado en el desarrollo de este Ma Mon, trabajo. A mi profesor y colega Ing. Andrs Pascal por sus consejos y colaboracin a lo largo de toda mi Pascal, formacin profesional. A la Lic. Lujn Gurmendi por ser la impulsora de mis investigaciones cuyos resultados hoy se Gurmendi, plasman en este trabajo. A quienes colaboraron con el presenta trabajo en calidad de expertos, por su tiempo brindado y sus crticas constructivas. A todos mis amigos y colegas que, de una u otra forma, colaboraron conmigo brindndome su tiempo y apoyo para alcanzar los objetivos planteados en esta tesis.
Modelo de Mejores Prcticas para la Administracin del Factor Humano en los Proyectos de TI
INDICE
Lista de Tablas............................................................................................................. iii Lista de Figuras ........................................................................................................... iv Resumen ....................................................................................................................... v Preface ......................................................................................................................... vi CAPITULO I: INTRODUCCION ................................................................................ 1 1.11.2Introduccin...................................................................................................... 3 Objetivos y Metodologa .................................................................................. 7
CAPITULO II: MARCO TEORICO ......................................................................... 11 2.1- Introduccin.................................................................................................... 13 2.2- El Factor Humano y la Administracin.......................................................... 13 2.3- Los Proyectos de TI........................................................................................ 17 2.3.1Habilidades del Lder.............................................................................. 18 2.4- La Gestin de los Proyectos de TI.................................................................. 23 2.4.1El Desarrollo de Software....................................................................... 31 2.4.2Resistencia al Cambio ............................................................................ 34 2.5- Tcnicas Utilizadas......................................................................................... 39 2.5.1Scrum...................................................................................................... 39 2.5.2Joint Application Development (JAD) ................................................... 41 2.5.3Programacin Extrema (Extreme Programming) ................................... 44 2.6- Resumen ......................................................................................................... 46 CAPITULO III: PLANTEAMIENTO DEL PROBLEMA...................................... 47 3.13.23.33.4Los Proyectos de TI y las personas ................................................................ 49 El software y las personas .............................................................................. 51 Las mejores prcticas...................................................................................... 53 Resumen ......................................................................................................... 54
CAPITULO IV: SELECCIN DE MEJORES PRCTICAS ................................ 55 4.1- Introduccin.................................................................................................... 57 4.2- Practicas Genricas......................................................................................... 57 4.2.1- Reuniones ..................................................................................................... 57 4.2.2- Wikis ............................................................................................................ 64 4.2.3- Foros de Discusin ....................................................................................... 66 4.2.4-Listas de Correo ............................................................................................ 67 4.2.5- Mensajera Instantnea................................................................................. 68 4.3- Practicas Especficas....................................................................................... 69 4.3.1- Comits de Desarrollo.................................................................................. 70 4.3.2- Programacin de a Pares .............................................................................. 71 4.3.3- Comits de Usuarios .................................................................................... 72 4.3.4- Grupos de Apoyo ......................................................................................... 73 4.3.5- Mesa de Ayuda............................................................................................. 75 4.3.6- Estructura Desglosada de Trabajo................................................................ 76 4.3.7- CPM ............................................................................................................. 78 4.3.8- PERT ............................................................................................................ 84 4.3.9- Diagramas de Gantt...................................................................................... 86 4.3.10- COCOMO .................................................................................................. 88
Ing. Hernn A. Turin
4.3.11- Puntos de Funcin ...................................................................................... 94 4.2.12- Tcnica de Grupo Nominal ........................................................................ 99 4.3.13- Tcnica Delphi ......................................................................................... 100 4.3.14- Anlisis Estadstico .................................................................................. 101 CAPITULO V: MODELO DE ADMINISTRACION DE PERSONAS PROPUESTO.............................................................................................................. 103 5.1- Introduccin.................................................................................................. 105 5.2- Esquema Seleccionado ................................................................................. 105 5.3- Modelo de Gestin Propuesto ...................................................................... 107 5.4- Aplicacin de Prcticas a las Diferentes Fases de un Proyecto ........................ 108 5.4.1- Iniciacin.................................................................................................... 109 5.4.2- Planificacin............................................................................................... 115 5.4.3- Ejecucin.................................................................................................... 124 5.4.4- Seguimiento y Control ............................................................................... 132 5.4.5- Cierre.......................................................................................................... 139 CAPITULO VI: VALIDACION ............................................................................... 145 6.16.26.37.17.27.3Sistema de Validacin Seleccionado............................................................ 147 Expertos Seleccionados ................................................................................ 148 Resultado de la Evaluacin de los Expertos................................................. 150 Aspectos Generales....................................................................................... 155 Cumplimiento de los Objetivos Planteados.................................................. 156 Lneas de Investigacin Futuras ................................................................... 158
CAPITULO VII: CONCLUSIONES........................................................................ 153
CAPITULO VIII: BIBLIOGRAFIA ........................................................................ 159 CAPITULO IX: ANEXOS......................................................................................... 165 9.19.29.39.49.59.6Anexo I - Extracto del Modelo Enviado a los Expertos ............................... 167 Anexo II Cuestionario Utilizado................................................................ 189 Anexo III Respuestas del Cuestionario del Experto 1............................... 192 Anexo IV Respuestas del Cuestionario del Experto 2............................... 195 Anexo V Respuestas del Cuestionario del Experto 3 ................................ 198 Anexo VI Respuestas del Cuestionario del Experto 4............................... 201
Ing. Hernn A. Turin
ii
LISTA DE TABLAS
Tabla I Relacin entre grupos de procesos y reas de conocimientos del PMBOK. .........26 Tabla II ndice de Resistencia al cambio por el desarrollo de un S.I. en el rea de RRHH ...............................................................................................................................................36 Tabla III Relacin entre el IRC y las variables Sociolaborales.........................................36 Tabla IV Relacin entre el IRC y los factores de la personalidad.....................................37 Tabla V Relacin entre el IRC y los factores organizacionales ........................................37 Tabla VI Importancia de los factores de xito de un proyecto..........................................38 Tabla VII Ejemplo de cuadro se criterios de seleccin. ....................................................64 Tabla VIII Ejemplo de actividades de un proyecto para un CPM......................................80 Tabla IX Ejemplo de actividades de un proyecto para un PERT .......................................85 Tabla X Ejemplo de actividades de un proyecto para un PERT con varianza calculada ...85 Tabla XI Coeficientes de COCOMO segn submodelo y modo utilizado [Boehm, 2000]. ...............................................................................................................................................89 Tabla XII Valores para los atributos del Submodelo INTERMEDIO de COCOMO ........91 [Boehm, 2000].......................................................................................................................91 Tabla XIII Tabla de para el clculo de puntos de funcin no ajustados.............................97 Tabla XIV Esquema de prcticas por fases del proyecto .................................................108
Ing. Hernn A. Turin
iii
LISTA DE FIGURAS
Figura 1 Relacin entre las variables que influyen en el xito de un proyecto. ...................4 Figura 2 Relacin de los cinco procesos principales de un proyecto segn el PMBOK [PMI, 2004] ...........................................................................................................................24 Figura 3 Secuencia de fases tpica de un ciclo de vida segn el PMBOK [PMI, 2004].....25 Figura 4 Relacin entre los interesados y el proyecto segn el PMBOK [PMI, 2004]......27 Figura 5 Esquema grfico de la interaccin entre las etapas de SCRUM ..........................41 Figura 6 Representacin Ejemplo de un diagrama Causa - Efecto. ...................................62 Figura 7 Esquema de una EDT propuesto por el PMBOK [PMI, 2004]............................77 Figura 8 Representacin grfica de una tarea.....................................................................79 Figura 9 Representacin grfica de dos tareas en secuencia..............................................79 Figura 10 Diagrama de red que representa las actividades de la Tabla VIII......................80 Figura 11 Identificacin del camino crtico........................................................................81 Figura 12 Fecha ms temprana de B. .................................................................................81 Figura 13 Fecha ms temprana de C. .................................................................................82 Figura 14 Diagrama con el clculo de fechas ms tempranas............................................82 Figura 15 Diagrama con el clculo de fecha ms tarda para le nodo H. ...........................83 Figura 16 Diagrama completo con fechas tardas y tempranas. .........................................83 Figura 17 Diagrama de Gantt para las actividades de la tabla VIII....................................87 Figura 18 Representacin grfica del esquema de la solucin planteada..........................107 Figura 19 Interaccin entre los grupos de procesos segn el PMBOK [PMI, 2004]. ......133
Ing. Hernn A. Turin
iv
RESUMEN
En la actualidad de las organizaciones, la Tecnologa de la Informacin (TI) y su aplicacin en los diferentes procesos de negocio, representa un factor crtico de xito para el cumplimiento de los objetivos organizacionales. La implementacin de estas tecnologas se lleva adelante a travs de la ejecucin de proyectos. Estos proyectos deben ser gestionados de manera eficiente para poder alcanzar las metas planteadas y, de esta manera lograr la correcta implementacin de las tecnologas en la organizacin. Todo proyecto se ve afectado por una serie de variables entre las cules se encuentran las personas y que se denominan Factor Humano. El factor humano est conformado por las personas y por todos aquellos aspectos que forman parte de la relacin entre ellas y con la organizacin en si misma. Esta investigacin tiene como objetivos identificar cules son los componentes ms importantes del factor humano que inciden en el resultado final de un proyecto de TI, cul es su impacto y determinar cules son las prcticas mas adecuadas para poder realizar una correcta gestin de las personas. A partir de estas prcticas, se construir un Modelo de Gestin de Personas el cual propone las prcticas a aplicar en cada grupo de procesos de un proyecto. Adems en dicho modelo se mencionan los detalles a considerar para aplicar cada prctica. El proceso metodolgico a seguir para poder cumplir con los objetivos descritos, consiste en la revisin del estado del arte de modo que se pueda plasmar cules son los elementos ms estudiados respecto del tema, posteriormente se plantean los objetivos especficos y la hiptesis. Luego, se presenta el marco terico del problema de modo que se dejan en claro todos los conceptos relacionados con el presente estudio, para luego realizar el planteamiento del problema. Finalmente se describe el modelo propuesto para dar solucin al problema de la gestin del factor humano en los proyectos de TI., se realiza la validacin de dicho modelo a travs del juicio de expertos, se elaboran las conclusiones y se determinan las lneas futuras de investigacin.
Ing. Hernn A. Turin
PREFACE
In Contemporary Organizations, the Information Technology (IT) and its application in different business processes, represents a critical success factor for the accomplishment of organizational goals. The implementation of these technologies is achieved through the execution of projects. These projects must be managed efficiently in order to accomplish the goals and thus achieve the successful implementation of technologies in the organization. Every project is affected by a number of variables which include the so-called "Human Factor". The human factor is made up of people and of all those aspects that are part of the relationship between them and the organization. This research aims at identifying the most important components of the human factor affecting the outcome of an IT project, their impact and the best practices to be followed for the proper management of people. From these practices, we will build up a "Model of Personnel Management," which proposes the practices to be applied on each group of processes that form a project. This model also includes details for implementing each practice. The methodology to be followed in order to accomplish the above mentioned objectives is to review the state of the art so as to recognize what are the most studied topics with regard to this subject; then, specific objectives and hypotheses are given. After that, we present the theoretical framework of the problem so as to make clear all the concepts related to this study and then we make the approach to the problem. Finally, the proposed model to solve the problem of managing the human factor in IT projects is described; model validation is carried out through expert opinions; conclusions are made, and as a conclusion, lines for future research are given.
Ing. Hernn A. Turin
vi
CAPITULO
INTRODUCCION
1.1-
INTRODUCCIN
En toda empresa u organizacin los proyectos representan la forma a travs de la
cual se llevan a la prctica las estrategias de la misma. Es por ello que la finalizacin exitosa de un proyecto es de vital importancia y requiere de una administracin especial para asegurar que se cumplirn con los objetivos planteados. El xito o fracaso de un proyecto est directamente relacionado con una serie de indicadores denominados Factores de xito y que pueden agruparse bsicamente en cuatro grupos: Tiempo, Presupuesto, Prestaciones y Personas. Cada uno de dichos factores impactan de una u otra manera en el resultado final del proyecto, pero adems existe una relacin entre los mismos de modo que, por ejemplo, si el lder no coordina correctamente al equipo de proyecto es probable que el trabajo sea desorganizado y que el proyecto no termine ni en el tiempo esperado ni con el presupuesto planificado. De la misma manera, si no se cuenta con el presupuesto necesario para ejecutar el proyecto, no se podrn contratar a las personas con los conocimientos requeridos para llevarlo a cabo. Adems, los tiempos sern mucho mayores a los esperados y probablemente las prestaciones del producto final no satisfagan las necesidades del cliente. Tambin que debe existir un equilibrio entre los cuatro grupos y, la importancia que se le asigne a cada uno debe tener como objetivo principal el logro de un equilibrio que permita llevar adelante el proyecto de forma exitosa. En la Figura 1 se puede observar la relacin entre el proyecto y los diferentes grupos de factores que lo afectan.
Ing. Hernn A. Turin
Proyecto Finalizado Exitosamente
Prestaciones
Presupuesto
Figura 1 Relacin entre las variables que influyen en el xito de un proyecto.
A lo largo del tiempo y con el avance de la tecnologa han ido surgiendo diversas herramientas, tcnicas y metodologas que intentaron dar soporte a los proyectos de Tecnologa de la Informacin, en adelante TI.1, y a los factores de xito del mismo. Algunas de ellas se centraron slo en algunas etapas de todo el proyecto, mientras que otras ofrecieron una visin ms integral con soluciones que puedan ser aplicadas en cualquier instancia del proyecto. En el marco de las herramientas aparecieron Scrum [Schwaber, 2004] y JAD2 [Wood, 1995], dos herramientas que se concentran bsicamente en la etapa de desarrollo de los proyectos de TI, y que proponen una serie de actividades que tiene como objetivo optimizar los tiempos de desarrollo, mejorar la comunicacin entre los miembros del proyecto y brindar resultados que cumplan con las expectativas del clientes. Pero estas tcnicas presentan un problema importante: estn orientadas slo a proyectos de TI que requieren desarrollo de software, por lo cual quedan fuera de su alcance los dems proyectos de TI (tales como la implementacin de un nuevo hardware).
Se define como Tecnologa de la Informacin al estudio, diseo, desarrollo, implementacin, soporte o direccin de los sistemas de informacin computarizados, en particular de software de aplicacin y hardware de computadoras 2 Joint Application Development: Tcnica utilizada en el desarrollo de software, la cual incluye a los usuarios como participantes activos en el proceso de desarrollo. Ing. Hernn A. Turin
Personas
Tiempo
Por el lado de las metodologas se encuentra la Programacin Extrema (XP) [Beck, 1999], la cual pertenece a la familia de las metodologas denominadas giles. Esta nace para dar solucin a los problemas ms recurrentes de la ingeniera del software, y provee una serie de prcticas aplicables a los proyectos de desarrollo de software y que apuntan a evitar desvos en los tiempos y en las prestaciones del producto final. Si bien la XP est basada en principios probados y brinda una serie de tcnicas que, bien aplicadas, dan muy buenos resultados, adolece del mismo problema que Scrum y JAD: est apuntada slo a proyectos de TI que involucran desarrollo de software. Adems su enfoque es incompleto debido a que se centra solo en la etapa de desarrollo, dejando afuera las instancias de planificacin e implementacin. Finalmente se encuentra el PMBOK (Project Management Body of Knowledge) que, no solo representa la mejor alternativa en cuanto a metodologas de administracin de proyectos, sino que tambin es un estndar avalado por un organismo internacional como lo es el PMI (Project Management Institute). Este estndar contiene todos los aspectos que se deben considerar dentro de un proyecto de TI y abarca todas las etapas, desde el inicio del proyecto hasta la finalizacin (cierre del mismo). La ventaja fundamental de PMBOK es el hecho de que provee una gua fcil de entender, pero el problema es que se indica qu es lo que se debe realizar pero no se especifica cmo debe hacerse lo que, en algunos casos, suele ser el gran problema: llevar la teora a la prctica.
En la presente tesis se analizarn las diferentes visiones (y su evolucin) acerca de la administracin de personas dentro de las organizaciones y, en particular, dentro de los proyectos de TI. Tambin se estudiar las caractersticas particulares de los proyectos de TI, la administracin de los mismos y las habilidades que deben poseer las personas involucradas en los mismos, fundamentalmente, los encargados de liderar dichos proyectos. Adems se presentarn y analizarn algunos de los problemas ms recurrentes en los proyectos y que tienen relacin con la administracin del factor humano, como es el caso de la resistencia al cambio. Finalmente se presentarn las tcnicas y metodologas mas utilizadas en dicha administracin indicando las debilidades y fortalezas de cada una para luego plantear
Ing. Hernn A. Turin
una alternativa que permita dar una visin integral al problema de la administracin del factor humano en los proyectos de TI. La administracin de personas es un tema transversal a toda la organizacin, ya que afecta a todas las reas de la misma. Es por ello que el presente modelo resulta aplicable a cualquiera de estas reas, pero especialmente en todas aquellas que se vean afectadas en forma directa por la realizacin de un proyecto de TI. Adems provee tcnicas que resultar muy tiles para quien tenga la responsabilidad de liderar el proyecto como as tambin para sus colaboradores. En la actualidad existe una gran cantidad de tcnicas que se aplican a la gestin de las personas involucradas en los proyectos, algunas de ellas son aplicables en cualquier momento y tipo de emprendimiento. Pero otras solo pueden aplicarse en etapas especfica y slo en proyectos con caractersticas muy particulares. La importancia del problema que se pretende resolver, radica en la escasa importancia que, en muchos casos, se le da a la influencia que tienen las personas sobre el resultado del proyecto. Esto se da especialmente cuando se trabaja en proyectos de TI donde los usuarios finales suelen presentar una gran resistencia a los cambios propuestos y a las tecnologas a implementar. Adems, otro de los aspectos que dan relevancia al tema, es la escasa atencin que se presta al manejo de las relaciones dentro del propio equipo del proyecto. En muchos casos se pondera el cumplimiento de los cronogramas y de los presupuestos por sobre el bienestar y la comodidad de los miembros del equipo, de modo que se genera un desgaste en los mismos que finalmente impacta en forma negativa sobre los resultados del proyecto. Estos problemas se pueden evitar si se plantea un esquema para la administracin del factor humano, de modo que se evitan impactos negativos en las dems variables. En la actualidad no existe un modelo que integre todos los aspectos a considerar respecto de la administracin de personas ni que provea tcnicas especficas a utilizar para ello. Uno de los modelos en el que se menciona este aspecto es el PMBOK, el cual en sus Captulos 9 y 10 se dedica completamente a la administracin de los recursos humanos y a la gestin de las comunicaciones del proyecto. El inconveniente de este modelo es que si bien indica muchas de las variables a considerar, no especifica las tcnicas a utilizar para cada caso. Esta ausencia de tcnica, si bien puede parecer poco importante, puede resultaren un problema para aquellos casos de personas con poca experiencia en manejo de grupos de personas o con formacin escasa en el tema.
Ing. Hernn A. Turin
Adems, estos dos captulos del PMBOK hacen hincapi en el manejo del equipo del proyecto, pero dejan de lados a los clientes y dems interesados en el mismo. La hiptesis formulada en el presente trabajo, es que se puede generar un modelo especfico para TI que permita administrar en forma eficiente todos los aspectos relacionados con las comunicaciones, motivacin y, en general, las relaciones entre las personas involucradas en un proyecto. Lo que se propone es un Modelo para la Gestin del Factor Humano involucrados en los Proyectos de Tecnologa de la Informacin. Este modelo integrar, por un lado un modelo estructurado y ampliamente utilizado en la administracin de proyectos, como lo es el PMBOK, y las diferentes tcnicas utilizadas para la administracin de todos los aspectos relacionado con el manejo de personas dentro de un organizacin. De este modo, se proveer de una serie de Mejores Prcticas fcilmente aplicables a este tipo de proyecto y que redundarn en beneficios en cuanto al manejo de las personas involucradas en el proyecto. Quedan fuera del alcance del presente trabajo, todos aquellos temas referidos al rea de Recursos Humanos propiamente dicha. Esto significa que no se enfocar en todo lo que respecte a definicin de puestos, reclutamiento y seleccin de personal y gestin de personal debido a que el modelo se orienta a los administradores de proyectos y no a las reas de Recursos Humanos del as organizaciones.
1.2-
OBJETIVOS Y METODOLOGA
El objetivo principal de este trabajo de tesis consiste en elaborar un modelo de
mejores prcticas para la gestin del factor humano dentro de los proyectos de TI y que contenga prcticas que sean aplicables a las diferentes etapas del proyecto. Adems se plantean los siguientes objetivos especficos: Especificar las caractersticas de la Gestin del Factor Humano en proyectos de TI. Analizar los diferentes modelos utilizados para la gestin de personas en los proyectos de TI. Definir el alcance y las limitaciones de cada una de las prcticas utilizadas en cada modelo. Elaborar un modelo de mejores prcticas de acuerdo a cada una de las etapas de un proyecto de TI.
Ing. Hernn A. Turin
Evaluar el modelo obtenido y analizar los resultados.
A fin de alcanzar los objetivos propuestos en el presente trabajo de tesis, se ha dividido el desarrollo de la misma en cinco etapas. La primera etapa tiene como objetivo principal una revisin bibliogrfica para determinar el estado del arte de la temtica involucrada. La segunda etapa consiste en analizar los diferentes modelos utilizados para la administracin del factor humano en los proyectos de TI. La tercera etapa tiene como objetivo el relevamiento de las diferentes prcticas y tcnicas que se utilizan para la administracin de las personas involucradas en los proyectos de TI definiendo el alcance y las limitaciones de cada una. La cuarta etapa consiste en el armado del modelo de mejores prcticas, organizando el mismo de acuerdo a las diferentes etapas de un proyecto de TI. Finalmente la quinta etapa consiste en el anlisis y evaluacin del modelo desarrollado a travs del juicio de expertos.
Etapa 1 Profundizacin del estado del arte de la administracin de personas en proyectos de TI mediante la lectura de bibliografa e investigacin en bibliotecas electrnicas y congresos relacionados al tema. Especificacin de las caractersticas de la administracin del factor humano en los proyectos de TI.
Etapa 2 Relevamiento de los diferentes modelos para el manejo de personas utilizadas en casos y proyectos con caractersticas diferentes. Esto se realizar a travs de la bsqueda exhaustiva a travs de bibliotecas electrnicas provistos por la directora. y en proyectos
Etapa 3 Anlisis de las caractersticas de las diferentes prcticas y tcnicas relevadas. Determinacin del alcance y limitaciones de cada una en las diferentes etapas de un proyecto de TI. Esto se lograr mediante la comparacin de las caractersticas de cada prctica versus las necesidades de cada etapa del proyecto.
Ing. Hernn A. Turin
Etapa 4 Armado del modelo de mejores prcticas, organizando el mismo de acuerdo a las diferentes etapas de un proyecto de TI.
Etapa 5 Evaluacin del modelo obtenido a travs del juicio de expertos. Para ello se realizar un cuestionario con preguntas a travs de las cuales se pueda determinar la utilidad o no del modelo elaborado. Anlisis de los resultados a travs de las respuestas de los cuestionarios. Realizacin de ajustes al modelo si fuera necesario. Elaboracin de conclusiones y lneas de investigacin futuras.
Ing. Hernn A. Turin
CAPITULO
II
MARCO TEORICO
2.1-
INTRODUCCIN
En el presente captulo se analizar la historia y evolucin del manejo del factor
humano dentro de las organizaciones y el impacto de este factor en las mismas. Adems se estudiarn las caractersticas particulares de los proyectos de TI y los aspectos que influyen en el xito o fracaso de los mismos. Por otro lado tambin se enumerarn las caractersticas que debera tener la persona encargada de liderar un proyecto y se pondr especial atencin en uno de los inconvenientes ms comunes en proyectos de TI relacionados con la implementacin de un producto software: La Resistencia al Cambio. Finalmente, se analizar el PMBOK como un estndar para la administracin de proyectos y se enumerarn algunas tcnicas y metodologas las cuales ponen especial atencin en las personas como un componente fundamental dentro de todo el proyecto.
2.2-
EL FACTOR HUMANO Y LA ADMINISTRACIN

El factor humano y la administracin de las personas dentro de las
organizaciones, desde hace mucho tiempo, han sido uno de los temas mas ampliamente tratados dentro de las teoras administrativas. Uno de los primeros que se ocup del tema fue Frederick Taylor, creador de la Administracin Cientfica, quien a travs de sus trabajos obtuvo una serie de premisas acerca de la actitud de los trabajadores [Taylor, 2005] y que sirvieron como bases para el resto de sus estudios y publicaciones. Dentro de dichas premisas las ms importantes fueron: El trabajador es incapaz de reflexionar o pensar. El trabajador considera negativo el trabajo en grupo. El trabajador no desea tener iniciativa propia en su trabajo. El trabajador siempre aplica la ley del menor esfuerzo. Si bien esta teora es una de las primeras en analizar y sentar precedentes sobre el comportamiento de las personas dentro de las organizaciones, se le han hecho muchas crticas por haberse centrado ms en la funcin y en la tarea que en la persona en si misma. Adems, se consider al trabajador como un elemento individual sin tener en cuenta la interaccin con los dems trabajadores o las consecuencias psicolgicas acarreadas por algunos fenmenos como por ejemplo por la fatiga.
Ing. Hernn A. Turin
13
Otro de los que se ocup del estudio de los individuos como parte de las organizaciones fue Henry Fayol [Fayol, 1985], quien a travs de sus estudios logr establecer catorce principios acerca de la administracin, la mayora de los cuales giraba entorno al comportamiento del empleado y de cmo era considerado el mismo dentro de la organizacin. De estos catorce principios, los ms importantes referidos al manejo de las personas en las organizaciones son los siguientes: Subordinacin de intereses particulares: Por encima de los intereses de los empleados estn los intereses de la empresa. Los miembros de una organizacin tienen que respetar las reglas y convenios que gobiernan la empresa. Remuneracin personal: La remuneracin y los mtodos de retribucin deben ser justos y propiciar la mxima satisfaccin posible para los trabajadores y para el empresario. Espritu de equipo: Hacer que todos trabajen dentro de la empresa con gusto y como si fueran un equipo, hace la fortaleza de una organizacin. Equidad: Los administradores deben ser leales y respetuosos con el personal, y demostrar cortesa y justicia en su trato. Estabilidad en el empleo: Se debe dar estabilidad en el cargo al personal. Los cambios en las asignaciones de los empleados son necesarios, pero si ocurren con demasiada frecuencia pueden perjudicar la moral y la eficiencia. Adems esta teora planteaba dos tipos de comunicacin dentro de la
organizacin: las descendentes (impartir rdenes a los subordinados) y ascendentes (eleva informacin a los superiores). A pesar de que esta teora fue una de las primeras en tener mayor consideracin con las personas que integran una organizacin, puso demasiado enfoque en la
organizacin formal dejando de lado casi por completo a la organizacin informal y sus aspectos sociolgicos dentro de la empresa. Desde 1920 y hasta la Segunda Guerra Mundial, las monarquas fueron reemplazadas progresivamente por regmenes democrticos, haciendo que los sistemas autoritarios pasasen a ser ms participativos. Simultneamente, se producen importantes cambios en las ciencias como la Sociologa y la Psicologa. Es entonces cuando aparece la teora de las Relaciones Humanas [Mayo, 2003] como una reaccin inmediata al Experimento de Hawthorne (1927) y que represent un complemento a la teora clsica de la administracin.
Ing. Hernn A. Turin
14
Esta teora plante los siguientes postulados: El trabajo es una actividad tpicamente grupal. El obrero no acta como individuo aislado sino como miembro de un grupo social. La tarea bsica de la administracin es formar una lite capaz de comprender y de comunicar, compuestas por jefes democrticos, persuasivos y apreciados por todo el personal. La persona humana es motivada esencialmente por la necesidad de estar en compaa, de ser reconocida, de acceder a una comunicacin adecuada. A partir del experimento de Hawthorne, aparecen otros autores que realizan nuevos aportes a esta teora, tal como es el caso de Roethlisberger y Dickson, quienes aportan los conceptos de Funcin Econmica y Funcin Social de una organizacin, donde la funcin social tiene como objetivo brindar satisfacciones a los miembros de la organizacin [Dickson, 2003]. Algunos aos mas tarde, Abraham Maslow desarroll la Teora de las necesidades [Maslow, 1991] en la cul se plantea cules son las causas que mueven a las personas a trabajar en una empresa y a aportar parte de su vida en ella. Estas necesidades fueron estructuradas en forma de pirmide de modo que las necesidades ms bsicas o simples del individuo se colocaron en la base de la pirmide, mientras que las ms relevantes se colocaron en la parte superior de la misma. A medida que se satisface uno de los niveles de la base se pasa a otro superior y as hasta llegar al nivel mas alto de la pirmide donde el individuo alcanza un estado denominado Autorrealizacin, en el cual la persona alcanza un nivel de felicidad y armona plena. El aporte mas importante de la teora de Maslow es que da el puntapi ara adentrarse en cuales son las necesidades que mueven a la persona en su comportamiento, sea en un grupo de personas como en una empresa. Pero presenta algunos problemas al intentar definir el estado de autorrealizacin, que parece ser mas un ideal al que se intenta llegar mas que un estado en si mismo. En la misma lnea de la Teora de las Necesidades, surge la denominada Teora de la Motivacin e Higiene [Herzberg, 1993] en la que se plantea que las personas son influenciadas por dos factores: Factores de Higiene: Son aquellos factores que hacen que una persona se sienta cmoda en su trabajo.
Ing. Hernn A. Turin
15
Factores de Motivacin: Son aquellos que hacen que la persona deposite su esfuerzo y su colaboracin en la realizacin de sus actividades dentro de la organizacin. Dentro de una organizacin la falta de cobertura de los factores higinicos puede provocar una falta de satisfaccin en sus miembros, lo que generar tambin un estado de falta de motivacin. Por su parte los factores de motivacin, son aquellos que producen un efecto de satisfaccin ms duradero y que incluyen sentimientos de realizacin y crecimiento mediante el cumplimiento de las tareas ofreciendo tambin desafos nuevos para la persona. En 1960, inspirado por la teora de Maslow, el socilogo Douglas McGregor plantea las teora X e Y [McGregor, 2007] donde la primera asume que las personas son desinteresadas con su trabajo, haraganas y que lo nico que los motiva a realizar sus actividades es la constante amenaza de que perdern su empleo. Por otro lado, la teora Y supone que los individuos son creativos, comprometidos con su trabajo y que siempre estn en bsquedas de nuevos retos y responsabilidades. Esta segunda teora es la que mas ha sido mas ampliamente adoptada en la actualidad para la administracin de los recursos humanos en las organizaciones.
Por otro lado, complementando a las teoras de la administracin que se encargaron de estudiar el factor humano dentro de las empresas, se presenta la psicologa que, a travs del estudio de las dinmicas de grupos y los roles que cada individuo juega dentro de los mismos, proporciona otro enfoque interesante del tema. Pichn Riviere define a un grupo como un conjunto restringido de personas que, ligadas por constantes espacio temporales, el cual, articulado en su mutua representacin interna, se propone en forma implcita y explcita una tarea que conforma su finalidad, interactuando a travs de complejos mecanismos de asuncin y adjudicacin de roles [Pichn-Riviere, 1999] y tambin define a un rol como un modelo organizado de conducta , relativo a una cierta posicin del individuo en una red de interacciones ligado a expectativas propias y de los otros. En el marco de la dinmica de grupos de trabajo y de los papeles (roles) de cada integrante, se definen los siguientes: El Vocero es el encargado de comunicar todo lo que sucede dentro del grupo. El Chivo Emisario es aquel en el cual se depositan todos los aspectos negativos del grupo. En l todo el grupo deposita todo lo que no se tolera dentro de la
Ing. Hernn A. Turin
16
estructura del grupo, tambin se habla del enfermo del grupo [Pichn-Riviere, 1999]. El Lder es aquel integrante del grupo en el cual todos los dems depositan los aspectos positivos del grupo. Es el encargado de estimular a los dems para que se alcancen los objetivos del grupo y se superen las metas. El Saboteador es el encargado de realizar la resistencia al cambio. Es el encargado de obstaculizar la consecucin de una tarea. Si se considera a una organizacin como una asociacin de personas regulada por un conjunto de normas en funcin de determinados fines [R.A.E., 2007], los roles antes mencionados pasan a jugar un papel importante en el anlisis y entendimiento de las actitudes y comportamiento de los miembros de la misma frente a los dems, y es por ello que estos conceptos se deben tener presentes en el actual trabajo.
2.3-
LOS PROYECTOS DE TI
Antes de comenzar a analizar este tema, es importante definir que se entiende
por Proyecto y por Gestin de Proyectos. Segn el Project Management Institute [PMBOK, 2004] las definiciones de dichos conceptos son las siguientes: Gestin de proyectos consiste en aplicar los conocimientos, habilidades, herramientas y tcnicas a las actividades de un proyecto de forma tal de cumplir con los requerimientos del mismo. Proyecto se define como una empresa temporal que se asume con el fin de crear un producto o servicio nico. Para el caso de la definicin de proyecto, se considera que es temporal porque tiene un comienzo y un final definido, lo cual lo diferencia de las operaciones normales dentro de una organizacin la cuales, adems, crean productos o servicios que son repetitivos. Como ya mencionamos antes, los proyectos deben ser llevados a cabo bajo una serie de restricciones que, adems, se influencian una a la otra. Si bien estas las restricciones se clasifican en grupos diferentes, estos grupos estn relacionados entre si, de modo que una modificacin el alguna de ellas podra impactar en las dems. Es por ello que resulta importante contar con una buena gestin de proyecto y con las herramientas y tcnicas adecuadas que permitan, a todo el equipo de proyecto, organizar su trabajo para poder cumplir con todas las restricciones planteadas.
Ing. Hernn A. Turin
17
Por otro lado, todo proyecto, y en especial los proyectos de TI, se ven altamente influenciado por los grupos de personas que sern involucrados en la realizacin del mismo. En estos grupos existen 2 tipos de afectados: quienes impulsan el proyecto (por razones polticas, econmicas etc.), denominados Sponsors y quienes sern los usuarios de dicho proyecto y que convivirn da a da con el resultado del mismo, denominados Usuarios Finales o Stackeholders. Es por ello que resulta de gran importancia para el xito de un proyecto de TI que se identifiquen claramente quienes son los componentes de cada uno de los grupos humanos que se ven impactados por la realizacin del mismo. Hoy dos aspectos importantes a considerar en este punto: Determinar las necesidades y expectativas de cada miembro del grupo. Manejar e influenciar las expectativas de modo que se asegure la realizacin de un proyecto exitoso. Otro de los puntos fundamentales es el manejo de lo que se puede denominar interfases del proyecto, que son fundamentalmente las comunicaciones formales e informales entre las diferentes personas que trabajarn dentro del proyecto, como tambin sus relaciones con los usuarios finales del mismo. Para poder realizar un correcto manejo de todos los aspectos que se enumeraron anteriormente y que tienen impacto directo sobre el resultado final de un proyecto, es necesario que la persona que conduce dicho proyecto (lder de proyecto) rena una serie de habilidades. A continuacin se analizarn en detalle cules son las ms importantes y la utilidad de cada una de ellas.
2.3.1- HABILIDADES DEL LDER Segn Konosuke Matsushita [Matsushita, 1993], el empleado ideal es alguien que tenga una gran capacidad para el desarrollo personal, alguien que pueda crecer no solo dentro del trabajo sino tambin junto con el mismo. Basado en sta definicin, Lus Bravo Salomn [Salomn, 2003] sostiene que existen habilidades que favorecen al desarrollo personal y otras que nos permiten mejorar la interaccin con las personas con las que se comparte el lugar de trabajo y las actividades correspondientes. Ambas son necesarias para poder liderar correctamente un equipo comunicacin. Dentro de las habilidades que favorecen al desarrollo personal encontramos las siguientes: y mantener una buena
Ing. Hernn A. Turin
18
Inteligencia Emocional: La inteligencia emocional esta conformada por la capacidad de comunicacin, la comprensin hacia los problemas de los dems, la participacin afectiva y emocional en el entorno, la capacidad para lograr un buen rendimiento cuando se trabaja en equipo y sintetizar a partir de experiencias de los dems y la capacidad de saber consultar y preguntar entre otras cosas. Esta inteligencia indica las aptitudes que tiene una persona para manejar la relacin entre las emociones y la razn como as tambin el dominio de los sentimientos y la disposicin para el trabajo en equipo. Como lder de proyecto, es importante reconocer cuales son las emociones involucradas en cada proceso, reconocer cada uno de los roles que cumplen los integrantes del equipo de trabajo y realizar todas las acciones necesarias para evitar posibles conflictos improductivos dentro del grupo. Lograr un buen desarrollo de la inteligencia emocional permitir mejorar el manejo de las relaciones con los dems.
Empata y Confianza: Se define como empata a la capacidad personal de establecer relaciones positivas, rpidas, autnticas y con gran facilidad para ponerse en el lugar del otro de modo que se puede comprender emocionalmente a la otra persona. Quien posee esta capacidad, puede no necesitar que los dems le comuniquen verbalmente sus sentimientos; sino que la persona puede captarlo a travs de signos corporales como el tono de voz, la postura corporal, la expresin del rostro, etc. Por otro lado se encuentra la confianza, que representa otro de los factores importantes en la relacin entre personas. Los individuos que generan confianza son aquellos que tienen la capacidad de transmitir credibilidad y apertura para poder responder todas las preguntas que se le realicen. Quienes generan
confianza tambin tienen una caracterstica ms: poseen confianza en s mismos, lo cual les permite asumir nuevos riesgos y desafos con la seguridad de poder cumplirlos.
Proactividad: La proactividad es la capacidad de una persona de contribuir y adelantarse para lograr los resultados de la mejor manera posible, siempre se preocupa por participar e intentar mejorar las actividades que realiza.
Ing. Hernn A. Turin
19
Una persona preactiva siempre decide libremente, y sin sentirse presionado, lo que desea hacer tanto en los aspectos personales como laborales, asume sus responsabilidades y toma la iniciativa para enfrentar y solucionar las dificultades.
Asertividad: Se conoce como asertividad a la habilidad de una persona para expresar los sentimientos, pensamientos, ideas, opiniones y creencias a otros de una manera efectiva y cmoda que no altera ni afecta su relacin con quienes lo rodean. Aristteles en tica a Nicmano citaba lo siguiente Cualquiera puede ponerse furioso, eso es fcil, pero estar furioso con la persona correcta, en el momento correcto, por el motivo correcto y de la forma correcta eso no es fcil (Ao 2001, Libro Octavo); esta frase sigue siendo de mucha utilidad para definir y enfocar el significado de la asertividad y es muy simple de comprender. Es muy importante que un lder de proyecto tenga una conducta asertiva ya que la misma favorece a la comunicacin y evita las reacciones agresivas o defensivas por parte de los miembros del grupo de trabajo.
Motivacin: La motivacin es el motor que empuja a la accin. Una persona motivada siempre est predispuesta a actuar, y realizar todo lo necesario para lograr el objetivo deseado o solicitado. La motivacin puede ser intrnseca o extrnseca. Se dice que la motivacin es intrnseca cuando la misma no proviene desde el exterior de la persona sino que nace como un inters de la persona en hacer o adquirir conocimientos acerca de algo, mientras que se dice que es extrnseca cuando el origen de la motivacin se encuentra en el entorno de la persona, es decir, en los halagos y/o reconocimientos que pueda lograr como consecuencia de haber alcanzado los objetivos. Las personas que se encargan de gerenciar y liderar proyectos deben tener siempre presente que es necesario motivar al personal para generar un mejor clima de trabajo y lograr que el proyecto se realice de la mejor manera posible.
Trabajo en Equipo: El concepto que se relaciona directamente con el trabajo en equipo es el de sinergia, es decir que el trabajo en equipo (o el todo) es
Ing. Hernn A. Turin
20
mayor que la suma de los esfuerzos individuales (suma de las partes). Es importante tener siempre presente esto, sobre todo quines lideran los equipos, ya que existen diferentes roles de un equipo y una buena convivencia entre los diferentes roles ayudar a que el equipo sea efectivo. Tambin es necesario que se defina claramente a todo el equipo cuales son las normas de convivencias, las metas a alcanzar, los procedimientos a seguir, etc. Para que se pueda alcanzar la sinergia necesaria dentro del grupo.
Liderazgo: Se define como liderazgo a la capacidad o habilidad de una persona de hacer que las dems la sigan aun a aquellos lugares donde no iran solas. Las relaciones de confianza se construyen con un comportamiento tico, con el cual se logra influir en los dems e incluso despertar en ellos el deseo de que lo sigan. Es por ello que el lder debe estar centrado en principios y esforzarse en mantener y cumplir sus compromisos. Los principios son verdades naturales y universales que estn presentes en todo grupo aunque no se hayan reconocido explcitamente. La honradez, la equidad, la lealtad, la responsabilidad y la dignidad son algunos ejemplos de valores. Cuando una persona asume aunque sea alguno de estos principios para basar su comportamiento, los transforman fcilmente en valores y son parte de lo que nutre al liderazgo. Pro supuesto que un gerente de proyecto debe tener capacidades de lder de modo que se pueda encausar a todo el grupo de trabajo hacia un mismo camino, y aunque algunas veces el liderazgo es innato tambin se aprende.
Comunicacin Efectiva: La comunicacin es el intercambio de informacin y comprensin entre dos personas. Dicho intercambio es en dos direcciones siendo responsabilidad del emisor hacer que la informacin que se transmite sea clara, completa y concisa. Mientras que el receptor es el encargado de asegurar la correcta comprensin de la misma. Existen ocho pasos para comunicarse: desarrollo de la idea del emisor, codificacin del mensaje en smbolos, transmisin a travs del canal correspondiente, recepcin del mensaje, comprensin de la informacin por parte del receptor y retroalimentacin. Es de vital importancia que el lder de proyecto tenga siempre presente los pasos involucrados en la comunicacin, para poder cumplir correctamente con
Ing. Hernn A. Turin
21
cada uno de ellos y asegurar que efectivamente los mensajes se transmiten e interpretan correctamente entre los involucrados en el proyecto.
Negociacin: Es el proceso por el cual se llega a un acuerdo entre los involucrados en un proyecto con relacin a aspectos inherentes a l. Es un proceso persuasivo, y por tanto, una de las habilidades muy necesarias para el logro exitoso del mismo. Dentro de un proyecto existen negociaciones con proveedores, clientes, contratistas, otros gerentes, grupo de trabajo, etc. para acordar diferentes temas con cada uno de ellos. Tambin es importante evitar los conflictos durante el proceso de negociacin de modo que se evite perjudicar a los intereses individuales de las partes. Como lder de proyecto se debe tener siempre claramente identificados los objetivos de la negociacin, los intereses de cada una de las partes y tratar de crear un planteamiento que genere satisfacciones mutuas. Tambin se deben tener presentes otros aspectos que influyen en la negociacin, tales como la religin, la cultura, el lenguaje, la educacin y las creencias de cada uno.
Segn lo expuesto por Bravo Salomn, un gerente / lder de proyecto no solo debe tener conocimientos y habilidades referidos a su profesin; sino que tambin debe tener conocimientos de otras reas debido a que va a tener mucha relacin con el personal y ser el encargado de dirigir al mismo. Esto implica saber comprender las necesidades de cada persona, poder negociar tanto con el equipo como con el resto de los involucrados en un proyecto, saber manejar la motivacin de las personas, dirigir las diferentes reuniones y fomentar la comunicacin. Adems debe realizar todas las actividades necesarias para fomentar el desarrollo personal y profesional de los miembros del equipo de trabajo. Todas estas habilidades se deben adquirir y desarrollar a travs del estudio y de la experiencia. Pero, adems de las habilidades personales de un lder, tambin existe un segundo aspecto a considerar: La organizacin y de un proyecto y la metodologa adoptada para administrar el mismo. Este aspecto es tan importante como las habilidades que debe tener un lder de proyectos, ya que sin metodologa resulta muy engorrosa la organizacin de un proyecto y, por consecuencia, lograr una finalizacin exitosa.
Ing. Hernn A. Turin
22
A continuacin se analizar en detalle como se lleva a cabo la gestin de un proyecto de IT y cules son los aspectos ms importantes a considerar. Para ello se ha elegido las pautas delineadas por el Project Management Institute a travs del PMBOK.
2.4-
LA GESTIN DE LOS PROYECTOS DE TI

Segn el PMBOK, la gestin de proyectos se puede dividir en cinco grupos de
procesos: Iniciacin, Planificacin, Ejecucin, Control y Cierre. Cada uno de estos grupos, est compuesto por actividades que se ejecutan y permiten alcanzar los
resultados esperados para dicho grupo de proceso. Estas actividades pueden solaparse unas con otras como tambin puede ocurrir con los procesos dentro de un mismo proyecto. La finalidad del PMBOK no es exponer disciplinas, herramientas y tcnicas aplicables a la gestin de proyectos sino proveer de un grupo seleccionado de ellas y que son consideradas como buenas prcticas. Adems, el grupo de conocimientos de este estndar se encuentra distribuido entre los miles de colaboradores alrededor del mundo y es por esta razn que no se lo presenta como un manual con pasos a seguir para culminar un proyecto en forma exitosa. Los cinco procesos en los que se estructura el PMBOK son: 1. Inicio 2. Planificacin 3. Ejecucin 4. Seguimiento y Control 5. Cierre Y las nueve reas de conocimiento son: 1. Gestin de la Integracin 2. Gestin del Alcance 3. Gestin del Tiempo 4. Gestin de la Calidad 5. Gestin de Costos 6. Gestin de Riesgos 7. Gestin de Recursos Humanos 8. Gestin de la Comunicacin 9. Gestin del Aprovisionamiento
Ing. Hernn A. Turin
23
A lo largo de un proyecto estos procesos se solapan e interactan entre s (Figura 2). Cada proceso se describe en funcin de sus entradas, herramientas y tcnicas y finalmente la salida del mismo.
Figura 2 Relacin de los cinco procesos principales de un proyecto segn el PMBOK [PMI, 2004]
EL PMBOK remarca que es importante comprender que los proyectos se pueden dividir en proyectos ms pequeos o fases. Estas fases comprenden lo que se denomina Ciclo de Vida de un Proyecto. Este ciclo de vide indica la serie de fases que se sucedern desde el principio hasta el fin del proyecto. El traspaso formal de una fase a la otra, dentro del ciclo de vida, est dada por la conclusin y aprobacin de lo que se denominan entregables. Dichos entregables no son ni ms ni menos que el resultado final de la ejecucin de dicha fase, y puede estar representado por un documento, un producto, etc. que se considera necesario para el comienzo de la fase siguiente. Generalmente los ciclos de vida establecen las fases que componen el mismo y el orden en que se deben ejecutar, las reas y personas que deben participar en cada una de las fases, los entregables de cada una de las fases y los mecanismos a travs de los que se aprobarn los mismos, y los mecanismos de control de cada una de las fases definidas. Aunque los ciclos de vidas de diferentes proyectos se parecen, no todos son exactamente iguales en cuanto a las fases que lo componen, ni requieren los mismos entregables. En algunos casos se da la situacin de solapamiento de fases, es decir, una fase comienza an cuando no ha finalizado la fase que la precede aunque no suele ser una prctica recomendada. De todos modos la conclusin de una fase no implica
Ing. Hernn A. Turin
24
necesariamente el comienzo de otra, sino que puede ser que la conclusin de una fase implique el final del proyecto. En la figura 3 se puede observar el conjunto de fases sugeridas por el PMBOK y las entradas y salidas de cada una de ellas.
Figura 3 Secuencia de fases tpica de un ciclo de vida segn el PMBOK [PMI, 2004].
A continuacin, el la Tabla I se puede ver la relacin que existe entre las reas de conocimiento y los grupos de procesos propuestos por el PMBOK. Dicha tabla permite visualizar claramente que reas estn involucradas en cada uno de los grupos de procesos.
Ing. Hernn A. Turin
25
Grupos de Procesos reas de Conocimiento Gestin de la Integracin Gestin del Alcance
Iniciacin
Planeamiento
Ejecucin
Control
Cierre
Gestin del Tiempo X
Gestin de Costos X X
Gestin de la Calidad X Gestin de los Recursos Humanos X X
Gestin de las Comunicaciones X Gestin de Riesgos X X X X X
Gestin del Aprovisionamiento
Tabla I Relacin entre grupos de procesos y reas de conocimientos del PMBOK.
As como existe una relacin entre los procesos y las reas de conocimientos de un proyecto, tambin existe una vinculacin entre el proyecto y las personas de la organizacin que se involucran con el mismo. Segn el PMBOK los interesados tienen diferentes niveles y responsabilidades las cuales pueden ir cambiando a lo largo del ciclo de vida del proyecto y cada uno de ellos puede influir positiva o negativamente en el resultado final del mismo. Es por ello que es necesario identificar claramente los interesados, sus intereses, los requisitos que
Ing. Hernn A. Turin
26
deben cumplir y gestionar correctamente la relacin de los mismos para con el resto del equipo. La Figura 4 ilustra las relaciones entre los integrantes y el proyecto de acuerdo a lo expuesto anteriormente.
Figura 4 Relacin entre los interesados y el proyecto segn el PMBOK [PMI, 2004].
La estructura de la organizacin tambin tiene influencia sobre le proyecto, sobre todo en lo que se refiere a la disponibilidad de recursos y el manejo de los mismos. A continuacin se describirn brevemente cada uno de los grupos de procesos mencionados.
Iniciacin El grupo de procesos de iniciacin comprende a todos aquellos procesos relacionados con la definicin de los objetivos del proyecto, la justificacin del mismo, el estudio de factibilidad, la evaluacin de las diferentes alternativas, la duracin aproximada y una primera estimacin de los recursos necesarios para el proyecto. Tambin en esta etapa se definen las restricciones y se designa al director del proyecto. Todo esto se realiza para lograr que finalmente se apruebe formalmente el proyecto en caso de ser considerado viable. En los procesos de este grupo, es fundamental la participacin de los clientes, sponsors y stakeholders del proyecto. Los clientes, son aquellas personas que se vern afectadas por la ejecucin del proyecto. Son aquellos individuos que convivirn da a da con el resultado de la ejecucin del proyecto, es decir, los usuarios del producto.
Ing. Hernn A. Turin
27
El sponsor, por ser quien avala institucionalmente al proyecto, es decir, quien impulsa la realizacin del proyecto dentro del a organizacin. Es por ello que en los procesos de iniciacin es muy importante contar con la participacin de esta persona para lograr un apoyo por parte del resto de la organizacin y alcanzar la aprobacin del proyecto. Mientras que, por su parte, los stakeholders son todos los involucrados en el proyecto y que se vern afectados por la ejecucin del mismo, como as tambin aquellos que influyen sobre dicho proyecto. Dentro de los procesos que forman parte del grupo de iniciacin, encontramos los siguientes: Desarrollar el Acta de Constitucin del Proyecto Desarrollar el Enunciado del Alcance del Proyecto
Planificacin El objetivo principal de este grupo de procesos y las interacciones entre ellos es el de planificar y gestionar con xito un proyecto dentro de una organizacin. Adems, los procesos que comprenden este grupo son los encargados de lograr una mayor maduracin del alcance del proyecto, y definir las actividades que se realizarn a lo largo del proyecto. En este grupo de procesos tambin se define las dependencias entre las tareas, los requisitos, los riesgos y tambin las restricciones. Durante la planificacin del proyecto, el equipo debe involucrarse con todos los interesados en el mismo y que pueden influir en el desarrollo del proyecto y sus resultados. La finalidad principal de este contacto es la de aprovechar los conocimientos y habilidades de cada uno de los implicados en beneficio de todo el proceso de planificacin. Pero este contacto no puede realizarse en forma aleatoria y desordenada, sino que se debe propiciar el clima y el entorno para que la contribucin de los interesados sea ms provechosa y para que los integrantes del equipo de proyecto puedan obtener el mayor beneficio de dicha situacin. Los procesos que se ejecutan dentro del grupo de planificacin son: Desarrollo del Plan de Gestin del Proyecto. Planificacin del Alcance. Definicin del Alcance. Crear el EDT.
Ing. Hernn A. Turin
28
Definicin de las Actividades. Definir la secuencia de Actividades. Estimacin de Recursos de las Actividades. Estimacin de la Duracin de las Actividades. Desarrollo del Cronograma. Estimacin de Costos. Preparacin del Presupuesto. Planificacin de la Calidad. Planificacin de los Recursos Humanos. Planificacin de las Comunicaciones. Planificacin de la gestin de Riesgos. Identificacin de Riesgos. Anlisis Cuantitativo de Riesgos. Anlisis Cualitativo de Riesgos. Planificacin de la Respuesta a los Riesgos. Planificacin de las Compras. Planificacin de las Contrataciones.
Ejecucin El grupo de procesos de ejecucin tiene como objetivo completar el trabajo definido en el plan de gestin del proyecto, para poder alcanzar el cumplimiento de lo requerimientos de proyecto. Entre las actividades de este grupo de proyectos estn implicadas todas aquellas relacionadas con la coordinacin de las personas involucradas, la administracin de los recursos y la integracin de todas las actividades del proyecto. Los procesos que se ejecutan dentro de este grupo son: Dirigir y Gestionar de la Ejecucin del Proyecto. Realizar el aseguramiento de la calidad. Adquirir el Equipo del Proyecto. Desarrollar el equipo del Proyecto. Distribuir la Informacin. Solicitar Respuestas de Vendedores. Seleccionar los Vendedores.
Ing. Hernn A. Turin
29
Seguimiento y Control El objetivo de este grupo de procesos es el de monitorear la ejecucin de todo el proyecto a fin de poder identificar los posibles inconvenientes a tiempo y tomar las acciones correctivas correspondientes en caso de ser necesario. Los procesos de este grupo buscan realizar un seguimiento continuo de manera que se pueda proporcionar a todos los miembros del equipo una visin acerca de la salud del proyecto. De esta manera se pueden identificar cualquier rea que requiera algn tipo de atencin especial para evitar desviaciones en la ejecucin. El seguimiento y control no solo controla los procesos de n grupo sino que realiza monitoreos sobre el avance de todo el proyecto. Esta supervisin tambin genera la retroalimentacin necesaria para poder mantener el proyecto dentro del plan de gestin realizado. Los procesos que forman parte de este grupo son los siguientes: Supervisar y Controlar el Trabajo del Proyecto Control Integrado de Cambios Verificacin del Alcance Control del Alcance Control del Cronograma Control de Costos Realizar Control de Calidad Gestionar el Equipo del Proyecto Informar el Rendimiento Gestionar a los Interesados Seguimiento y Control de Riesgos Administracin del Contrato
Cierre El grupo de procesos de cierre esta comprendido por todos aquellos procesos que se ejecutan para concretar la finalizacin formal del proyecto. Esta finalizacin puede estar dada por la conclusin del mismo o por la cancelacin del proyecto por algn motivo en particular. Este grupo comprende los siguientes procesos: Cierre del Proyecto. Cierre del Contrato.
Ing. Hernn A. Turin
30
Adems el cierre tambin se ejecuta cuando se finaliza una fase del proyecto, de modo que se formaliza la conclusin de la misma. En el PMBOK se considera que el cierre del proyecto concluye con la entrega del producto. El concepto de entrega depende en gran medida de lo que se haya definido en el contrato antes de comenzar el proyecto. As, puede ocurrir que la entrega del producto sea, por ejemplo, la entrega de la documentacin del sistema y el producto software para que luego el cliente se encargue de la implementacin y puesta a punto del mismo. O tambin puede que la entrega del producto implique que el sistema y los productos software relacionados deben estar implementados y puestos en marcha. A fin de abarcar una mayor gama de posibilidades, en el presente trabajo se considerar que la entrega del producto se realiza con el sistema funcionando y con los productos software instalados y puestos en marcha. Para el caso particular de los proyectos de TI, se debe considerar que generalmente implican desarrollo o adquisicin de software, por lo que es importante considerar las etapas que involucra, de modo que se puedan determinar las acciones a realizar en cuanto a la administracin del factor humano en cada etapa. A continuacin se presenta una metodologa propuesta por James a Senn y en la cual se pueden identificar las diferentes etapas que se ven involucradas.
2.4.1- EL DESARROLLO DE SOFTWARE Segn el ciclo de vida clsico del desarrollo del software [Senn, 1992], las etapas involucradas son:
Investigacin Preliminar: La investigacin preliminar se divide en tres partes. La primera de ella es la aclaracin de la solicitud, en la cual se especifica de manera clara y detallada que es lo que el usuario desea. Muchas veces el cliente no tiene una idea bien clara y formada de lo que realmente necesita, por lo cual es tarea del analista asistirlo para poder expresar en forma clara lo que se colocar en la solicitud. La segunda parte es el estudio de factibilidad, durante el cual se analizan la Factibilidad Tcnica (la tecnologa y el software disponibles actualmente son suficientes para llevar adelante el proyecto?), Econmica (los beneficios de ejecutar el
Ing. Hernn A. Turin
31
proyecto justificarn los costos del mismo?) y Operacional (los usuarios utilizarn el nuevo sistema o habr resistencia al cambio?). Finalmente la ltima parte de esta etapa es la aprobacin de la solicitud, en este momento es cuando se realiza la firma de la aprobacin formal del proyecto. Una vez aprobada la solicitud se deben realizar las estimaciones de costos, tiempo y personal de modo que se le asigne una prioridad al proyecto dentro de la lista de proyectos de la organizacin.
Determinacin de Requerimientos: En esta etapa se debe especificar cuales son las prestaciones que el cliente espera que le brinde el nuevo sistema. En este momento el analista debe lograr (en conjunto con el cliente) dar respuesta a las siguientes preguntas relacionadas con los procesos de la empresa: Qu es lo que se hace? Cmo se hace? Con qu frecuencia se presenta? Qu tan grande es el volumen de transacciones y decisiones? Cul es el grado de eficiencia con que se realizan las tareas? Existe algn problema? Qu tan serio es? Cul es la causa que lo origina? Para poder obtener esta informacin se debern utilizar diferentes herramientas y tcnicas de recopilacin de datos de modo que se pueda comprender el proceso en su totalidad. La salida de esta etapa debe ser una lista con la descripcin de las prestaciones que debe cumplir el nuevo sistema (caractersticas funcionales) y las caractersticas no funcionales (tales como los tiempos de respuestas).
Diseo del Sistema: En esta etapa se establece cmo el sistema cumplir con lo requerimientos identificados en la etapa anterior. Este es el momento en que se realiza el diseo lgico del sistema. En este momento se deber realizar la especificacin del software y tambin reespecifican los procedimientos asociados.
Ing. Hernn A. Turin
32
Desarrollo del Software: Esta es la etapa en la cual se debe analizar si el software a implementar ser desarrollado internamente en la organizacin o si se adquirir alguno disponible en el mercado. Para tomar esta decisin es importante tener bien en claro las prestaciones indicadas en la lista de requerimientos, a fin de poder evaluar si existe un producto en el mercado que cumpla con todos los tems de la misma. En caso de desarrollo interno se construye el software y la documentacin correspondiente, y en caso de adquirir un producto del mercado tambin se debe solicitar la documentacin del mismo.
Prueba del Sistema: En esta fase se realizan todas las pruebas necesarias para asegurar que el software no posea fallas y que cumple con los requerimientos especificados. Aqu se utilizan datos de pruebas y generalmente es un grupo de usuarios los que llevan a cabo dichas pruebas o al menos un grupo de personas ajenas al equipo que confeccion el software.
Implantacin y Evaluacin: La implementacin es el proceso por el cual se verifica e instala el nuevo equipamiento, se entrena a los usuarios acerca del uso del software y sobre como se realizarn los nuevos procedimientos, se realiza la carga de todos los datos que sean necesarios para comenzar con la operacin del nuevo sistema, y se realiza un seguimiento para asegurar que todo funciona de acuerdo a lo planificado. La implantacin puede hacerse en paralelo (utilizando el nuevo y el viejo sistema a la vez y abandonando progresivamente el primero) o desde cero (eliminando definitivamente el viejo sistema de a un rea por vez y reemplazndolo por el nuevo).
Durante todo el ciclo de vida de un proyecto software, pero principalmente en la etapa de implantacin, existe un factor que resulta determinante del xito o fracaso del mismo. Este aspecto debe ser considerado y analizado durante la etapa de Estudio de Factibilidad al efectuar el estudio de la factibilidad operacional, segn el cual se determina que aceptacin tendr el software por parte de los usuarios finales. Este factor es la Resistencia al Cambio.
Ing. Hernn A. Turin
33
2.4.2- RESISTENCIA AL CAMBIO Otro de los temas que est involucrado en los proyectos de IT y que impacta directamente sobre el xito o el fracaso del mismo es la denominada resistencia al cambio. El principio de accin y reaccin de la fsica puede ayudar a comprender que ante un cambio (accin) (reaccin) [lvarez, 2001]. El cambio por si mismo no es percibido como malo, sino que inicialmente puede captarse como positivo o negativo de acuerdo a la capacidad de las personas que lo impulsan de anticiparlo y controlar sus consecuencias. Es en este punto donde el quipo de proyecto y el sponsor del proyecto deben tener en claro cuales son los principales focos de resistencia, comprender el porque de la misma y tratar de realizar acciones que tiendan a reducir o eliminar dicha resistencia. Los cambios suponen crisis, ya que la propia tendencia a la continuidad por parte del comportamiento social, la hace inevitable incluso en los casos ms insignificantes. La crisis contina hasta que se alcanza alguna nueva forma de es natural y esperable que aparezca una resistencia
adaptacin en que los antiguos elementos se fusionan con los nuevos elementos. Esto sucede porque los miembros de la organizacin pueden percibir los efectos del cambio de diferentes maneras: como beneficiosos, perjudiciales o ambivalentes de acuerdo a sus conveniencias personales y su capacidad de adaptacin [Salinas, 1975]. De acuerdo a lo expuesto podemos concluir que cualquier cambio que se introduzca en la organizacin producir resistencia, y el caso de la implementacin de un proyecto de TI no es la excepcin, ya que generalmente impactan en la estructura de la empresa, los procesos y finalmente en las tareas que realizan los miembros de la misma. El proceso de cambio tiene varias etapas, Kurt Lewin define como etapas del cambio a las siguientes [Cummings, 2007]: Descongelamiento: Es la etapa en la cual se intenta reducir las fuerzas que mantienen a la organizacin en su actual comportamiento. La idea de esta etapa es crear una motivacin en las personas para aceptar o buscar un cambio en la organizacin.
Cambio: Es la etapa en la cual se ejecutan los procesos a travs de los cuales se introducen los nuevos comportamientos. El objetivo de esta etapa es desplazarse desde el estado anterior hacia un nuevo estado mediante la modificacin de los hbitos, valores, conductas y actitudes.
Ing. Hernn A. Turin
34
Recongelamiento: Esta es la etapa en la cual la organizacin se estabiliza en el nuevo estado de equilibrio hacia el que fue desplazada. Se dice que el recongelamiento est realizado cuando el nuevo comportamiento implementado pasa a formar parte de los nuevos hbitos de la organizacin.
Existen diferentes tcticas para poder combatir la resistencia al cambio, dentro de las cuales las ms conocidas son: la comunicacin, la participacin y la negociacin. Cuando la comunicacin es pobre o carece de veracidad en sus contenidos suele debilitar el apoyo hacia el cambio por parte de los implicados y generar, en consecuencia, una resistencia al mismo. Es por ello que es de gran importancia mantener una comunicacin fluida con los empleados a fin de ayudarlos a entender los cambios, sus objetivos y los beneficios que el mismo acarrear. Esta comunicacin debe ser clara y su contenido creble para generar una relacin de confianza y una imagen de credibilidad en quien comunica, evitando malos entendidos y que el proceso se corrompa por la circulacin de informacin errnea entre las personas. Por otro lado, la participacin de los empleados en la toma de algunas decisiones relacionadas con el proyecto, evitar que los mismos se vuelvan en contra del proyecto en el que ellos estuvieron participando y decidiendo. Es por esto que siempre se deben identificar a los principales opositores del proyecto y escuchar con atencin sus opiniones con el objeto de hacerlos sentir partcipes del mismo y eliminar o reducir su fuerza opositora. Finalmente se encuentra la negociacin, que tiene como componentes a la comunicacin y la participacin ya que ambas pueden ser utilizadas por el equipo que lidera el cambio para intentar reducir la resistencia a la implementacin de los cambios. A continuacin se presenta el resumen de las conclusiones de un estudio sobre la resistencia al cambio tecnolgico en las organizaciones durante el desarrollo de un sistema de informacin en el rea de Recursos Humanos [Garca, 2001]: En la Tabla I se muestran los datos referidos a los ndices de resistencia al cambio promedio para cada una de las 6 empresas involucradas en el estudio, adems de un promedio general. Los ndices de Resistencia ala Cambio se definieron a partir de la recoleccin de datos realizada y sus valores oscilan entre 0 y 168. La relacin entre dicho ndice y la resistencia al cambio es inversa, o sea que a medida que el ndice se acerca ms a 0, se habla de una mayor resistencia al cambio y a medida que se acerca ms a 168 se habla de una menor resistencia al cambio.
Ing. Hernn A. Turin
35
Empresa 1 2 3 4 5 6 Promedio General
ndice de Resistencia 144 105 61 105 146 143 117,1
Expresin Cualitativa Poca Resistencia Mediana Resistencia Mucha Resistencia Mediana Resistencia Poca Resistencia Poca Resistencia Poca Resistencia
ndice de Resistencia Mnimo Registrado 125 89 44 56 144 119 ---
Tabla II ndice de Resistencia al cambio por el desarrollo de un S.I. en el rea de RRHH
Los datos mostrados en la Tabla II reflejan que existen diferencias entre los niveles de resistencia entre las empresas estudiadas, donde el nivel de resistencia vara de acuerdo a la forma en que se implement el proceso de cambio. Aunque el ndice promedio indica que hay poca resistencia al cambio en general, no se puede excluir el dato de que el grupo seleccionado es muy heterogneo en cuanto a la forma de implementar el cambio y es por ello que no se deben perder de vista los ndices particulares de cada una. La resistencia al cambio tambin tiene relacin con los factores sociolaborales (edad, sexo, nivel educativo, antigedad, etc.). En la Tabla III se puede observar la correlacin entre el ndice de Resistencia al Cambio (IRC) y los factores sociolaborales. Variables Relacionadas IRC y Edad IRC y Sexo IRC y Nivel Educativo IRC y Cargo IRC y Antigedad ndice de Correlacin 0,2 -0,1 0,3 0,2 0,3
Tabla III Relacin entre el IRC y las variables Sociolaborales
De acuerdo a lo que se muestra en la Tabla III, no hay demasiada correlacin entre las variables sociolaborales y la resistencia al cambio, aunque un detalle a tener en cuenta (y que resulta lgico) es que la resistencia al cambio tiene mayor correlacin con la antigedad. Finalmente se analizar la relacin de la resistencia al cambio con los factores ligados a la personalidad (Tabla IV) y ligados a la organizacin en si misma (Tabla V).
Ing. Hernn A. Turin
36
ndice Promedio 70 64 34 63 73 65 62
Expresin Cualitativa Mnima Resistencia Poca Resistencia Mediana Resistencia Poca Resistencia Mnima Resistencia Poca Resistencia Poca Resistencia
Tabla IV Relacin entre el IRC y los factores de la personalidad
ndice Promedio 73 41 27 42 73 60 53
Expresin Cualitativa Poca Resistencia Mediana Resistencia Mucha Resistencia Mediana Resistencia Poca Resistencia Poca Resistencia Mediana Resistencia
Tabla V Relacin entre el IRC y los factores organizacionales
Si bien en ambas tablas se muestra que no hay un alto nivel de relacin entre los factores de la personalidad y organizacionales respecto de la resistencia al cambio, sin embargo se puede apreciar que los factores ligados a la organizacin, que son los que generalmente se descuidan mas, son los que terminan teniendo un mayor peso con respecto a la presencia de resistencia al cambio en la organizacin. Aunque hay muchos factores que influyen en la resistencia al cambio que se puede producir cuando se implemente un cambio en una organizacin, es necesario recordar que, en gran medida, esto depende de las estrategias que se empleen para la implementacin de dicho cambio y luego de los dems factores relacionados. De acuerdo a lo planteado, la resistencia al cambio es una de las consecuencias de un manejo incorrecto del factor humano relacionado con un proyecto. Este manejo ineficiente tiene su origen en la falta de habilidades por parte del lder para poder gestionar correctamente este factor y lograr, de esta manera, evitar los problemas causados por problemas personales entre los miembros del equipo o conflicto de intereses entre las diferentes partes involucradas. En la Tabla VI se puede observar un estudio realizado por el Standish Group para determinar lo factores de xito de un proyecto de TI [Standish Group, 1995] y donde se muestran los porcentajes de cada factor sobre el total de respuestas obtenidas
Ing. Hernn A. Turin
37
en dicho estudio. Este estudio muestra que el 31 % de los proyectos son cancelados antes de tiempo y que un 53 % sufre un desvo en sus presupuestos que ronda el 189 % del presupuesto original.
Factores de xito de un Proyecto 1. Participacin del usuario 2. Apoyo de la gestin 3. Claridad de los requerimientos 4. Planificacin adecuada 5. Expectativas realistas 6. Pequeos hitos dentro del proyecto 7. Personal competente 8. Sentido de pertenencia al equipo 9. Visin y Objetivos del proyecto claros 10. Trabajo duro y personal motivado 11. Otros
% de Respuestas 15,9 13,9 13,0 9,6 8,2 7,7 7,2 5,3 2,9 2,4 13,9
Tabla VI Importancia de los factores de xito de un proyecto.
De acuerdo al estudio realizado por el Standish Group, los recursos humanos no se ubican en los primeros puestos entre los factores principales de xito de un proyecto, pero hay varios aspectos que se sitan entre los diez mas importantes (personal competente, sentido de pertenencia, trabajo duro y personal motivado) cuya la suma de porcentajes (14,9 %) es considerable y muestra la importancia de los mismos. Finalmente, en el artculo Success or Failure: Human Factors in Implementing New Systems [Bruke, 2001] se presentan estudios de diferentes casos de implementacin de proyectos de IT, se indicaron los siguientes factores de xito de un proyecto que tienen relacin con la administracin de las personas: Participacin activa de todas las reas, desde las gerenciales hasta las operativas. Realizacin de reuniones peridicas. Mantenimiento de la visin global del proyecto dentro de la organizacin. Identificacin y control de los factores de fracaso. Fomento de la confianza en el personal. Capacitacin correcta del personal.
Hasta aqu se han presentado los diferentes aspectos relacionados con los proyectos de TI y los factores claves de xitos de los mismos, pero no se ha hecho
Ing. Hernn A. Turin
38
mencin de las metodologas y/o tcnicas que se utilizan para poder administrar estos factores. En la siguiente seccin se presentarn las tcnicas ms utilizadas actualmente y se realizar un breve anlisis de las caractersticas ms importantes de cada una de ellas.
2.5-
TCNICAS UTILIZADAS
Scrum [Schwaber, 2004] es una metodologa de desarrollo gil que se aplica en
2.5.1- SCRUM proyectos en los cuales se trabaja con requisitos inestables y que requieren flexibilidad y rapidez en el desarrollo. Scrum, ms que una metodologa de desarrollo de software, es una forma de gestionar los grupos de programadores, ya que la idea fundamental de esta tcnica es fomentar el trabajo conjunto, con una misma direccin y objetivos. Adems esta herramienta permite realizar un seguimiento claro del avance de las tareas a realizar por cada miembro del equipo de modo que el lder del mismo pueda tener un panorama claro del progreso del trabajo. Los principios de Scrum son: Para una nueva aplicacin, los requerimientos no son totalmente conocidos hasta que el usuario no haya utilizado la misma. Es imposible describir completamente un sistema iterativo. La incertidumbre es inherente e inevitable en el proceso de desarrollo de aplicaciones. Adems de estos principios, Scrum tiene 3 elementos bsicos que son: el Sprint, el Product Backlog, el Sprint Backlog. El Product Backlog es una lista con las funcionalidades que debe tener el software que se est desarrollando. Esta lista debe estar ordenada por orden de
importancia de las funcionalidades comenzando por la ms importante. En esta lista no es necesario que figuren todas las funcionalidades, pero si se deben listar las mas importantes. De las funcionalidades listadas en el Product Backlog, se toman las ms importantes y se descomponen en una serie de tareas con las cuales se confecciona otra lista denominada Sprint Backlog y que representa las tareas que se debern ejecutar en el prximo perodo, al cual se lo denomina Sprint. La duracin de los sprints no
Ing. Hernn A. Turin
39
siempre es la misma e incluso puede ser diferente de acuerdo al momento del proyecto en el que se est. La idea de Scrum es la de dividir el proyecto en varios sprints en cada uno de los cuales se obtendr como resultado una nueva versin del software que cumplir con las funcionalidades del Product Backlog abarcadas por el Sprint. Segn lo planteado por esta tcnica, se propone tres etapas en las cuales tanto los desarrolladores como los usuarios juegan un papel muy importante. El proceso de Scrum se puede dividir en tres etapas (ver Figura 2): 1. Pre-Juego: En esta etapa se definen las funcionalidades que formarn parte del Product Backlog y a partir de ste se define el Sprint Backlog que se utilizar en el Sprint. Adems, se define la arquitectura se realiza el diseo de alto nivel. 2. Juego: La etapa de juego es aquella durante la cual se desarrollan las tareas definidas en el Sprint Backlog. Para poder realizar un seguimiento de la marcha de las actividades a realizar en esta etapa se realizan reuniones diarias entre los miembros del equipo, denominadas Stand Up Meetings, donde cada miembro debe responder las siguientes tres preguntas: Qu hice ayer? Qu voy a hacer hoy? Qu ayuda necesito? 3. Post Juego: Finalmente, en esta etapa se evalan los resultados del Sprint una vez finalizado el mismo. Aqu no slo se verifica que se hayan cumplido con las funcionalidades predefinidas para el Sprint sino que tambin se evalan los tiempos, el progreso del proyecto y de ser necesario se redefinen algunos tiempos del proyecto. Si se trata de una iteracin dentro del proyecto, se vuelve a la Etapa 1 para planificar el prximo Sprint, en cambio si es la ltima iteracin se proceder a confeccionar toda la documentacin necesaria para la finalizacin del mismo.
Ing. Hernn A. Turin
40
Figura 5 Esquema grfico de la interaccin entre las etapas de SCRUM
Como se mencion antes, Scrum no es una metodologa de desarrollo sino que es una tcnica que debe ser aplicada en conjunto con alguna metodologa de desarrollo. Generalmente Scrum suele aplicarse con desarrollo rpido tal como es el caso de la Programacin Extrema.
2.5.2- JOINT APPLICATION DEVELOPMENT (JAD) JAD [Wood, 1995] es una tcnica creada por IBM en el ao 1978 cuya filosofa consiste en hacer que los usuarios participen en forma activa en el proceso de desarrollo de un producto software, fundamentalmente en la etapa de determinacin y definicin de requerimientos. En el mbito de los sistemas de informacin y del desarrollo de software, JAD es la implementacin de lo que Henry Ford utiliz en la fabricacin de automotores: organizar cada uno de los componentes del proceso de fabricacin de manera tal que un automvil pudiera ser fabricado en menor tiempo del que tomara hacerlo con una lnea de montaje. Para el caso particular de los sistemas y proyectos de TI, el objetivo es identificar lo que los usuarios realmente necesitan y, a continuacin, establecer un proceso que permita obtener un producto que satisfaga esas necesidades. El problema que intenta solucionar esta tcnica es, por un lado la brecha que existe entre las prestaciones de los sistemas que se obtienen a travs de un proceso estndar y lo que los usuarios realmente necesitan, y por el otro reducir la demoras que
Ing. Hernn A. Turin
41
se producen muchas veces por la lenta comunicacin entre los diferentes miembros del equipo de proyecto e inclusive entre las partes interesadas del mismo. Los talleres JAD estn compuestos por una serie de de sesiones estructuradas en las cuales: Todo el mundo se rene en una habitacin para hablar acerca del tema a tratar. Todo el muerdo escucha lo que el resto del grupo tiene para decir. No hay demoras entre preguntas y respuestas y no se dejan temas pendientes. El Joint Application Development elimina muchos de los problemas de las reuniones tradicionales ya que transforma las reuniones en talleres menos frecuentes, ms estructurados y ms productivos. Adems cada talles debe estar compuesto por un equipo en el cual existen roles claramente definidos. Estos roles son: Sponsor: Es el encargado de patrocinar y proporcionar los recursos necesarios para la realizacin del proyecto. Debe ser un miembro de la organizacin con suficiente poder y jerarqua como para asegurar la continuidad del proyecto.
Lder de Proyecto: Es el lder del equipo que lleva adelante la ejecucin del proyecto. Es el encargado de responder a las preguntas referidas a alcance, tiempos, recursos y coordinacin del proyecto. Debe participar en las reuniones pero sin influenciar al resto de los participantes del taller.
Usuarios Finales: Son los encargados de utilizar el sistema, es decir que representan a los principales destinatarios del producto que se generar a partir de los resultados de cada uno de los talleres realizados. Los usuarios finales son los que conocen como ser la interaccin del sistema con el mundo real y su conocimiento es fundamental para rectificar cualquier mala interpretacin al momento de definir los requerimientos del sistema o en cualquier otra etapa.
Facilitador: Es el encargado de organizar y dirigir la reunin de modo que todo el grupo se mantenga dentro de la agenda preparada para el taller. Adems el facilitador se encarga de identificar problemas que deben ser resueltos dentro del
Ing. Hernn A. Turin
42
taller y de asignar actividades al final de la reunin. Este rol solo coordina el taller pero no contribuye con aportes de informacin en la reunin. Expertos en Documentacin: Son los encargados de registrar todo lo ocurrido en la reunin y generar la minuta/acta de reunin. Al igual que el facilitador no aportan informacin a la reunin sino que simplemente aportan organizacin a la misma.
Observadores: Son personas que por algn inters en particular desean presenciar la reunin pero no tienen participacin en la misma. Generalmente se trata de algunos miembros del equipo de proyectos tales como los desarrolladores, quienes pueden tener inters en entender el proceso.
JAD debera abarcar todo el ciclo de vida de un proyecto de sistemas, pero para el caso de grande proyecto es recomendable plantear un esquema incremental dentro del cual se utilice JAD en cada uno de los incrementos. Para que la aplicacin de sta tcnica sea exitosa es necesario tener en cuenta algunos factores, dentro de los cuales los ms importantes son: 1- El objetivo de su aplicacin debe estar claramente especificado y debe ser compartido por todos los miembros del equipo JAD. 2- El equipo debe estar conformado por un grupo de personas que sea representativo de todas las reas involucradas en el proyecto. 3- Todos los miembros del equipo deben tener la misma responsabilidad y poder de decisin dentro del mismo. 4- Se deben escuchar todas las ideas y considerarlas importantes hasta que se demuestre lo contrario mediante un anlisis de la misma. 5- No hacer talleres por el solo hecho de reunirse, los talleres solo se deben realizar cuando hay algo realmente importante para tratar. 6- No debe transcurrir ms de tres o cuatro semanas entre un taller y el otro. Adems es importante que en cada reunin cada integrante haya concluido las tareas que se le asignaron en la reunin anterior. 7- Las decisiones se deben tomar por consenso.
Ing. Hernn A. Turin
43
Los beneficios fundamentales de esta tcnica es que fomenta la comunicacin entre los involucrados en el proyecto, crea consenso y sentimiento de pertenencia entre quienes participan en los talleres y como consecuencia de ello permite mejorar la calidad del diseo haciendo que las soluciones sean transversales a toda la organizacin.
2.5.3- PROGRAMACIN EXTREMA (EXTREME PROGRAMMING) La Programacin Extrema [Beck, 1999] es una metodologa de desarrollo rpido basada en los principios de simplicidad, comunicacin, retroalimentacin y coraje y fue diseada para ser utilizada por equipos pequeos que necesitan realizar desarrollo de software rpido y en un entorno donde los requerimientos varan con mucha frecuencia. XP propone una fuerte interaccin entre el equipo de desarrollo y los usuarios finales del sistema, llegando a proponer que un representante del cliente trabaje en forma conjunta con el equipo de desarrollo. Tambin propone el trabajo de a pares y las reuniones frecuentes para evaluar el estado y avance de las diferentes actividades. La programacin extrema propone doce prcticas o actividades que el equipo de proyecto debe realizar da a da, las cuales tienen su origen en prcticas muy conocidas y aplicadas en la ingeniera del software. Estas doce prcticas son: 1. Juego de Planificacin: La idea de esta prctica es la de dividir la funcionalidad de un proyecto en varios fragmentos mas pequeos denominados Historias. Estos fragmentos se definen en comn acuerdo con el cliente y luego se prioriza cada uno y se realizan las estimaciones correspondientes.
2. Entregas Frecuentes: Se debe presentar una nueva versin del sistema tan pronto como sea posible de modo que se aporte un nuevo valor agregado para el cliente. La idea de esta prctica es fomentar y maximizar la retroalimentacin de modo que se pueda controlar el proyecto y la evolucin de los requerimientos ms fcilmente.
3. Diseo Simple: El sistema debe ser lo mas sencillo posible siempre que cumpla con las necesidades del cliente. La idea de tener un diseo sencillo es evitar las complicaciones que podran generar las futuras modificaciones sobre una funcionalidad en particular.
Ing. Hernn A. Turin
44
4. Pruebas Automticas: Se deben disear pruebas automticas de modo que se puedan ejecutar en cualquier momento sin necesidad de insumir demasiado esfuerzo cada vez que se debe realizar una prueba.
5. Integracin Continua: Para evitar los trastornos y problemas que se producen cuando se realiza una integracin de cdigo al final del proyecto, se propone realizar una integracin continua (diaria, cada hora, etc.) de modo que se
minimicen los problemas que se pueden presentar en esta etapa al final del proyecto.
6. Refactorizacin: La refactorizacin consiste en modificar el diseo de un mdulo pero sin afectar su comportamiento externo. Esto es posible siempre que se realice un diseo sencillo que permita ser modificado para compatibilizar el mismo con el diseo de otros mdulos.
7. Programacin de a Pares: La programacin de a pares consiste en que dos personas trabajen sobre una misma computadora compartiendo el desarrollo del cdigo. La idea de esta prctico es por un lado mejorar la calidad del cdigo que se desarrolla (uno escribe y el otro puede controlar lo que se hacer), y por el otro fomentar la comunicacin dentro del equipo de desarrollo del proyecto.
8. Propiedad colectiva del cdigo: Esta prctica se aplica para evitar cuellos de botella, es decir que se busca que todos los desarrolladores conozcan la mayor parte del cdigo de modo que al memento de realizar mantenimiento del mismo cualquiera pueda hacerlo. Adems esta prctica facilita la transferencia de conocimiento entre los miembros del equipo de desarrollo.
9. Semana de 40 Horas: Los programadores cansados son ms propensos a cometer errores, por eso se sugiere que la semana laboral no debe exceder las 40 horas. Si esto no ocurre es porque algo dentro del proyecto est funcionando mal.
10. Cliente en el Equipo: Uno de los pilares fundamentales de la XP es la retroalimentacin, es por ello que la participacin de un cliente o usuario final
Ing. Hernn A. Turin
45
dentro del equipo permite que se agilice la comunicacin y que la retroalimentacin sea ms rpida.
11. Metfora: Las metforas representan la manera en que los programadores y el cliente pueden entenderse ya que a partir de la utilizacin de las mismas se crea un lenguaje comn entre ellos.
12. Estndares de Codificacin: Los estndares de codificacin permiten que todo el equipo encare la produccin de cdigo respetando ciertos lineamientos, lo cual se traduce en cdigo ms fcil de mantener.
Esta metodologa, como se puede ver, hace mucho hincapi en el trabajo en grupo. Los desarrolladores, los clientes y los administradores son todos partes de un mismo equipo dedicado a la produccin de software de calidad. XP se parece a un rompecabezas, donde cada una de las piezas por separado no significan nada pero cuando se combinan permiten ver un cuadro completo.
2.6-
RESUMEN
A partir de todo lo estudiado, el prximo captulo centrar su atencin en
analizar cada tcnica y metodologa mencionada (SCRUM, XP, PMBOK, JAD) desde el punto de vista de la administracin de personas, a fin de poder identificar los puntos fuertes y dbiles de las mismas y, a partir de esto, plantear claramente el objetivo del presente trabajo.
Ing. Hernn A. Turin
46
CAPITULO
PLANTEAMIENTO DEL PROBLEMA
III
3.1-
LOS PROYECTOS DE TI Y LAS PERSONAS

En el captulo anterior, cuando se analiz la influencia de la resistencia al
cambio a travs del estudio de un caso presentado por el Standish Group [Standish Group, 1995] referido a la implementacin de un sistema de recursos humanos, y a partir de ello se confeccion una lista de los principales factores que influyen en el proyecto. Esta lista incluye los siguientes tems: Participacin del usuario Apoyo de la gestin Claridad de los requerimientos Planificacin adecuada Expectativas realistas Pequeos hitos dentro del proyecto Personal competente Sentido de pertenencia al equipo Visin y Objetivos del proyecto claros Trabajo duro y personal motivado A partir del estudio de los puntos antes enumerados resulta que muchos de los mismos tienen estrecha relacin con las personas que estn involucradas en el proyecto (Participacin del usuario, Expectativas realistas, Personal competente, Sentido de pertenencia al equipo y Personal motivado). Algunos de ellos estn ms orientados hacia las responsabilidades que le competen al rea de Administracin de Recursos Humanos (como por ejemplo reclutar personal competente) y por ende no tienen gran dependencia de la direccin del proyecto. Pero otros escapan a las competencias de Recursos Humanos y recaen directamente sobre los encargados de llevar adelante la direccin del proyecto y es en este aspecto donde se centrar la atencin en el presente trabajo. As se mencion previamente los factores relacionados con la administracin de personas que influyen en el xito de un proyecto, tambin se deben considerar los aspectos que la direccin del proyecto debe tener en cuenta para encarar y llevar adelante en forma exitosa dichos factores. En otras palabras, cuales son las caractersticas que debe tener un lder de proyecto para poder gestionar en forma correcta los factores claves de xito relacionados con el manejo de personas. En este
Ing. Hernn A. Turin
49
sentido, previamente se mencion como caractersticas fundamentales para un lder a las siguientes: Inteligencia Emocional Empata y Confianza Proactividad Asertividad Motivacin Trabajo en Equipo Liderazgo Comunicacin Efectiva Negociacin
Cada una de estas caractersticas afectan en forma directa a la forma en que se lleva a cabo la gestin de un proyecto de IT ya que la inteligencia emocional es la que le permitir al lder manejar la motivacin del equipo, incentivarlo y entender las necesidades de cada uno de los miembros del equipo. De esta manera se pueden evitar los efectos negativos de tener un equipo cuyo rendimiento se ve degradado, por ejemplo, porque no todas las expectativas de sus miembros fueron cubiertas o porque hay necesidades no satisfechas y no identificadas por el lder. Relacionado con la inteligencia emocional, tambin se encuentra la confianza, es decir, la capacidad del lder de generar confianza en los integrantes del equipo de modo que los mismos se sientan seguros de poder plantear sus dudas o inquietudes sin el temor de ser juzgados o de recibir alguna represalia por ello. Adems est la empata, que es la capacidad del lder de entender y vivenciar las necesidades que se le plantean y poder entender de mejor estos planteos. Entro otras caractersticas, de las mencionadas anteriormente, y que no son menos importantes estn la asertividad, la negociacin y la comunicacin efectiva. Estas caractersticas tienen ms relacin con la forma en que el lder puede lograr que el equipo cumpla con ciertas pautas o se encamine en cierto rumbo de acuerdo a las necesidades del proyecto. La comunicacin efectiva es fundamental para evitar los malos entendidos y las suspicacias que se despiertan cuando los lineamientos a seguir dentro del proyecto no estn claramente especificados.
Ing. Hernn A. Turin
50
Finalmente se encuentran la motivacin, la proactividad y el trabajo en equipo, que son caractersticas que estn netamente relacionadas con la forma en que se realizan las actividades del equipo. Es necesario que el lder motive al equipo, fomente la proactividad y el trabajo en equipo de modo que cada una de las actividades que se llevan a cabo se vean enriquecidas por el aporte de todo el equipo. Si bien hasta el momento se ha hablado solamente de las caractersticas a cumplir por parte del encargado de liderar el equipo de trabajo de un proyecto, no se debe dejar afuera a los dems integrantes de dicho equipo. Estas personas tambin deben cumplir ciertos requisitos que resultan tan importantes y vitales para el proyecto como las habilidades del lder. En el caso de los integrantes del equipo de proyecto, se debe poner especial atencin en las caractersticas que tienen relacin con el factor humano pero que, adems, estn relacionadas con el rol que cumplir dentro del equipo. Es por ello que el conjunto de caractersticas se reduce en cada caso de modo que, por ejemplo hay casos en los que las habilidades ligadas con el liderazgo no son necesarias. El presente trabajo se enfocar solamente en las caractersticas relacionadas con el factor humano en las tcnicas para poder administrar correctamente las mismas. Pero no se profundizar en la definicin de puestos.
3.2-
EL SOFTWARE Y LAS PERSONAS

Dentro de los proyectos de TI que se llevan a cabo dentro de las organizaciones,
hay un gran nmero que involucra la implementacin de algn tipo de software. En algunos casos dicho software es desarrollado a medida para la organizacin, mientras que en otros el producto se adquiere y se configura de acuerdo a las necesidades del negocio. En cualquiera de los casos ya se ha estudiado que las etapas que componen el ciclo de vida del software son: Investigacin Preliminar Determinacin de Requerimientos Diseo del Sistema Desarrollo del Software Prueba del Sistema Implantacin y Evaluacin
Ing. Hernn A. Turin
51
Cada una de estas etapas tambin requiere de habilidades para el manejo del factor humano. En la investigacin preliminar es muy importante la capacidad de comunicacin ya que en esta etapa el manejo de los involucrados en el proyecto, especialmente los stakeholders y sponsors es vital, ya que si el mismo resulta viable, ser el sponsor quien respaldar la ejecucin del proyecto. Por su parte los stakeholders son uno de los roles claves para obtener parte importante de la informacin necesaria para confeccionar la lista de requerimientos. Durante la determinacin de requerimientos se vuelve a tornar muy necesaria la capacidad de realizar una comunicacin eficiente y efectiva. La empata y la confianza tambin son importantes porque cuanto mejor sea el clima y la confianza generada con los principales actores de esta etapa (usuarios claves y stakeholders), mejor y mas til ser la informacin que se obtenga para especificar los requerimientos del producto software. Finalmente la negociacin juega un papel vital en esta etapa, sobre todo al momento de determinar que aspectos sern considerados por el producto y cuales no. En la etapa de diseo, las caractersticas ms importantes son la inteligencia emocional, la asertividad y el trabajo en equipo. Las dos primeras caractersticas estn netamente ligadas a la forma en que se enfocar todo el trabajo de diseo, por lo que cuanto mas asertivos y emocionalmente inteligentes sean quienes llevan a cabo la ejecucin de esta etapa, mejor ser el resultado logrado. Por su parte el trabajo en grupo enriquecer el resultado gracias al ya conocido emergente sistmico. Durante la etapa de pruebas es muy importante la inteligencia emocional y la proactividad de modo que las pruebas resulten lo mas representativas posibles del uso que se le dar finalmente al producto. En la ltima instancia se encuentra la implantacin y evaluacin. Esta etapa es la que quizs requiere mayos entrenamiento y capacidades para administrar el factor humano, ya aqu un mal manejo de este factor puede resultar letal para la implementacin y puesta en marcha del producto. La empata, la confianza, la asertividad, la negociacin y la motivacin deben estar centrados fundamentalmente en conseguir la aceptacin completa del producto por parte de los usuarios finales. Mientras que el trabajo en grupo, el liderazgo y la proactividad deben centrarse ms especficamente en asegurarse que el producto implementado funcione de acuerdo a los estndares fijados para el mismo. De este modo si se logra una mejor aceptacin del
Ing. Hernn A. Turin
52
producto por parte de los usuarios y, si adems dicho software cumple con todos los requisitos solicitados, las probabilidades de xito se incrementan considerablemente. De este modo resulta claro que cuando existe desarrollo de software en un proyecto de TI, tambin es de vital importancia la correcta administracin de las variables relacionadas con la administracin de personas. Pero no se debe dejar sin considerar que en todos los proyectos se debe respetar una estructura que indique como llevar adelante el mismo desde su concepcin hasta la implementacin. Es en este contexto donde el concepto de Mejores Prcticas comienza a transformase en otro punto importante a considerar.
3.3-
LAS MEJORES PRCTICAS

Se entiende como mejores prcticas al conjunto de acciones que guardan cierta
coherencia entre si y que han sido aplicadas en forma exitosa en ciertas situaciones determinadas y que se espera que, aplicadas en contextos similares, obtengan los mismos resultados. En general las mejores prcticas suelen obtenerse a partir de
actividades que se realizaron en un determinado proyecto y cuyos resultados fueron exitosos, y si bien guardan cierta coherencia entre s, muchas veces dependen de las tendencias y de la moda que se encuentre en auge en el momento en que se aplican, por lo cual puede suceder que existan conjunto de mejores prcticas que resulten
contradictorias entre s. De todos modos y a pesar de las crticas que se les puedan resultar, han representado una herramienta muy til para plasmar la experiencia de las personas que han participado en diferentes proyectos con diversos resultados, de modo que muchas de estas experiencia resultan sumamente tiles para quienes se embarcan en la tarea de tener que encarar proyectos con caractersticas similares. Las mejores prcticas son ampliamente utilizadas en diferentes reas, desde la informtica hasta la medicina, pasando por la administracin, las organizaciones pblicas, los sistemas educativos y la gestin de proyectos. En general este tipo de prcticas son utilizados por las organizaciones para estandarizar sus procesos de modo que se creen modelos a utilizar dentro de dicha organizacin.
Ing. Hernn A. Turin
53
3.4-
RESUMEN
De todo lo antes dicho, se desprende que algunos factores claves para el xito de
cualquier proyecto de TI estn vinculados en mayor medida a aspectos organizacionales ms que a aspectos relacionados con la tecnologa. Es importante contar con las personas correctas y tener los procesos claramente definidos para poder tomar y
gestionar correctamente el proyecto. Tambin es importante obtener la aprobacin de todos los actores involucrados, definir claramente los roles, conocer cmo se tomarn las decisiones, y tener claramente definidos cules son los resultados que se consideran crticos para que el proyecto resulte exitoso. Es aqu donde la administracin de las personas cobra vital importancia y donde se encuentran los motivos para analizar detalladamente las acciones a realizar para evitar un fracaso en el proyecto. En cuanto a tcnicas y metodologas, es claro que las ms utilizadas actualmente no logran abarcar todos los aspectos ya que cada una provee una solucin parcial al problema de la administracin del factor humano. Es por ello que se propone relevar las diferentes tcnicas y herramientas utilizadas actualmente (en diferentes casos y proyectos variados) y organizar las mismas en un modelo de mejores prcticas. La idea de dicho modelo es proveer, a los lderes de proyectos, diferentes alternativas segn las caractersticas del proyecto a coordinar y transformar dicho modelo en una gua prctica que permita mejorar el manejo de las personas involucradas en un proyecto de IT y reduzca los riesgos asociados con ellas. El planteo de organizar un modelo de mejores prcticas se basa en el hecho de que en los ltimos aos las mejores prcticas han cobrado vital importancia; y es por ello que diferentes instituciones se han dedicado a elaborar modelos para las diferentes reas tales como Administracin de Proyectos [PMI, 2004], Gestin de servicios de IT (ISO20000) [ISO/IEC, 2005], Ingeniera de Software [ISO/IEC, 2008], Calidad [ISO, 2000], Manejo de Stock [Monden, 1998] e incluso algunos autores han tomado como propias algunas prcticas aprendidas a travs de su experiencia.
Ing. Hernn A. Turin
54
CAPITULO
SELECCIN DE MEJORES PRCTICAS
IV
4.1-
INTRODUCCIN
En ste captulo se analizarn todas las prcticas relacionadas con la
administracin de personas. Dichas prcticas se clasificarn de acuerdo a si las mismas son utilizables en cualquier instancia del proyecto o si solamente son aplicables en algn momento en particular. De este modo se establecern dos grupos de prcticas: Prcticas Genricas y Prcticas Especficas. En primer lugar se analizarn las Prcticas Genricas. Estas prcticas se denominan genricas debido a que se podrn aplicar en cualquiera de los grupos de procesos del proyecto, variando simplemente algn aspecto en particular para poder adaptarla mejor cada grupo. Luego se presentarn las que se denominarn Prcticas Especficas. ste grupo de prcticas son aquellas que slo tienen aplicacin en algn grupo de procesos en particular pero no al resto de los grupos.
4.2-
PRACTICAS GENRICAS
En esta seccin se analizarn las caractersticas de aquellas prcticas relacionadas con la administracin de personas y que son aplicables a los diferentes grupos de procesos dentro de un proyecto de IT. Las prcticas que se analizarn son las siguientes: Reuniones Wikis Foros de discusin Listas de Correo Mensajera instantnea
4.2.1- REUNIONES Para asegurar el xito de una reunin [Wong, 2007], es fundamental la correcta organizacin de de la misma a fin de que se asegure la participacin de cada uno de los presentes y se propicie el mbito para que expresen sus ideas y necesidades en relacin con el proyecto. Una habilidad muy importante con la que deben contar los gerentes y lderes de proyectos, es la de poder facilitar (coordinar) correctamente las reuniones en las cuales cumpla con dicho rol. La facilitacin es el arte de dirigir las reuniones de un equipo en forma eficaz. Esto implica disear y utilizar los procesos que permitan al equipo arribar, en tiempo y
Ing. Hernn A. Turin
57
forma, a las conclusiones deseadas a travs del debate. Un buen facilitador de reuniones deber tener conocimientos sobre herramientas y tcnicas de reuniones, dinmicas de grupos y manejo de personas. Una buena facilitacin de un equipo ayudar al mismo a tomar buenas decisiones. Para muchas personas, realizar en forma correcta una reunin se resume simplemente a que el equipo se centre en una agenda prefijada y distribuida previamente a cada participante, alcanzar el objetivo definido para el encuentro y conseguir un lugar confortable para llevar a cabo la reunin. Pero, la mayora de los facilitadores se olvida de uno de los componentes ms importantes a tener en cuenta: el proceso de facilitacin. En general se presupone que una reunin fracasa debido a que no se ha preparado correctamente la agenda o porque no ha habido un comportamiento adecuado por parte de los participantes. Sin embargo nadie repara en el hecho de que la mayora de las reuniones no fracasa por los aspectos antes mencionados sino que lo hacen por un solo motivo: un proceso de coordinacin pobre. En algunos casos suele ocurrir que aun con un proceso de facilitacin malo, se alcancen los objetivos de la reunin, sin embargo esto puede hacer que cada reunin resulte lenta, aburrida, frustrante y altamente propensa a cometer errores en la toma de decisiones. La mayora de los coordinadores insume mucho tiempo en redactar correctamente la agenda del da y organizar los contenidos de la reunin, pero deja completamente de lado la eleccin y armado del proceso por el cual se facilitar dicho encuentro. En algunos casos, el no armado del proceso se debe simplemente al desconocimiento de su importancia, pero en otros se lo deja de lado debido a que se lo considera como una prdida de tiempo. Sin embargo se ignoran las ventajas de utilizar un buen proceso de facilitacin. La eleccin de un proceso de facilitacin adecuado ayuda al equipo a generar mejores ideas, maximiza la produccin de soluciones y facilita la toma de decisiones dentro del equipo de trabajo. El facilitador debe centrarse en disear el proceso de modo que soporte los objetivos planteados para la reunin, explicar y dejar en claro el proceso a todos los miembros del equipo de trabajo, ejecutar dicho proceso y finalmente verificar que tan bien est funcionando el mismo. El secreto de todo proceso es lograr que se canalice toda la energa en alcanzar el objetivo deseado, lo cual en algunos casos puede resultar muy poco sencillo.
Ing. Hernn A. Turin
58
A continuacin veremos algunos aspectos importantes que deben ser tenidos en cuenta al momento de determinar el proceso a utilizar en una reunin: 1. Dedicar el tiempo que sea necesario para organizar las actividades y dejar en claro los objetivos y contenidos del encuentro: Muchas veces se considera que dedicar demasiado tiempo en estas actividades es una prdida de tiempo, sin embargo esto no es as. En muchos casos la ansiedad por comenzar a trabajar y ponerse manos a la obra hace que no se comprendan completamente la metodologa de trabajo y los objetivos de la reunin. Esto puede generar conflictos y malos entendidos ya avanzada la reunin. Es conveniente que se dedique este tiempo al comienzo del encuentro para luego evitar prdidas de tiempo en aclaraciones y resoluciones de conflictos derivados de una mala comprensin de las pautas de la reunin. Para comprender mas en profundidad este aspecto, se puede hacer una analoga con un proyecto cualquiera en el cual, si no se insume el tiempo suficiente en realizar una planificacin correcta y detallada del mismo y no se deja en claro cul es el objetivo de dicho proceso, probablemente fracasar. Lo mismo ocurre con las reuniones si no se planifican y aclaran los objetivos correctamente.
2. Monitorear constantemente el proceso: Muchas veces se da el caso de que un proceso planificado para facilitar una reunin no funciona como se esperaba. Esto suele ocurrir cuando hace que las personas comiencen a preocuparse por otros aspectos y se alejen del objetivo principal del encuentro. Es importante evitar que el proceso maneje los contenidos. Siempre debe fijarse primero los contenidos de la reunin y luego seleccionar el proceso que mejor se adapte a los mismos. Cuando se verifique que la energa del grupo decae, la atencin se dispersa o se centra en temas secundarios, o se comienza a trabajar sobre demasiados supuestos, entonces es momento de verificar si no es necesario realizar cambios en el proceso. Hay que tener muy en claro que no siempre el mismo proceso ser til en todos los casos.
3. Trabajar en un tema a la vez: Una de las situaciones que se suelen dar mas a menudo en las reuniones de equipos es cuando se estn discutiendo mas de
Ing. Hernn A. Turin
59
un tema a le vez. Esto se suele dar cuando en el debate de un tema surgen diferentes posturas ante lo cual, las personas que compartan opiniones seguirn por un camino y el resto del equipo encarar otra alternativa o incluso tratar de aclarar mejor el problema. Esto genera que en el mismo instante de tiempo existan dos o ms grupos discutiendo temas diferentes sin que ello resulte notorio para todo el equipo, pero convirtiendo a la reunin en algo intil e improductivo. Es muy importante que antes de comenzar una discusin sobre un nuevo tema, se cierre correctamente la discusin del tema anterior. De esta manera todo el trabajo se realiza en forma mas ordenada y se asegura que finalizado el encuentro no habrn quedado temas sin definicin.
4. Asegurarse de abrir y cerrar los debates en forma adecuada: En general las reuniones se encaran como una discusin libre de temas de acuerdo a una lista elaborada previamente y distribuida a los miembros del equipo. Si bien este concepto es correcto, se deben tener en cuenta un tem importante y que ayuda a que la discusin sea ordenada: abrir y cerrar correctamente las discusiones. Generalmente en un encuentro de trabajo hay personas que poseen la capacidad innata de ser creadores de temas o debates, mientras que hay otros que tienden a ser los encargados de cerrar los temas y elaborar las conclusiones correspondientes. El problema de estos extremos es que los primeros tienden siempre a seguir analizando y escuchando opciones mientras se pueda, en tanto que los segundos pretenden manejar una solucin lo antes posible. Es importante poder manejar este tipo de comportamientos y lograr un equilibrio que permita abrir cada discusin, generar el debate suficiente como para obtener una conclusin adecuada y finalmente dar un cierre a dicho debate. Tanto para iniciar una discusin como para cerrar la misma y obtener las conclusiones, existen tcnicas muy conocidas y sumamente tiles para cada caso. A continuacin listaremos las ms conocidas y se har una breve exposicin de su utilidad, pero no se entrar en el detalle de su implementacin ya que esto excede los lmites del presente trabajo.
Ing. Hernn A. Turin
60
Tcnicas para apertura de debates Tormenta de Ideas (Brainstorming): Este es uno de los mtodos ms utilizados para iniciar el debate de un equipo entorno a un tema en particular. La idea es lograr que el equipo presente la mayor cantidad de ideas posible acerca del tema a analizar y luego ir reduciendo la lista. En este proceso no se debe descartar ninguna idea por mas ridcula que esta parezca, debido a que con el correr de la discusin dicha idea puede terminar cobrando valor e importancia. La reduccin de la lista se deber realizar en consenso con el grupo y, en especial, con la aprobacin de quien gener cada idea a eliminar.
Diagramas de Influencia: Los diagramas de influencia son un tipo de diagrama que permite representar problemas de decisin tal y como las percibe quien debe tomar la misma: acciones, incertidumbre y preferencias. Este diagrama permite que todos puedan tener muy presentes cuales son los factores claves para el xito de un proceso. Adems, permite analizar cual es la relacin que existe entre estos factores, de modo que se pueda identificar si existen dependencias entre s y poder tenerlas presentes. Este tipo de diagrama permite crear una visin compartida de todos los procesos que influyen en un proyecto, de modo que se puedan establecer prioridades para cada factor y establecer un plan de trabajo para cada uno de dichos factores.
Diagramas Causa Efecto: Este es un diagrama muy conocido y utilizado para identificar cuales son las posibles causas que provocan un determinado efecto o producen un resultado en particular. El objetivo de aplicar este tipo de diagramas es obtener tantas causas como sea posible y que se considera, influyen en el efecto que se est analizando. Esta tcnica tambin incluye una tormenta de ideas, ya que las causas se obtendrn a partir de una tormenta de ideas y luego se estructurarn en forma ordenada en el diagrama segn corresponda. La Figura 8 muestra un ejemplo de un diagrama rendimiento de un sistema. Este tipo de diagramas es especialmente til cuando se desea obtener la causa de un determinado problema. de este tipo para analizar el bajo
Ing. Hernn A. Turin
61
Figura 6 Representacin Ejemplo de un diagrama Causa - Efecto.
Tcnicas para cerrar debates Votacin por Puntos: Esta es una tcnica muy rpida y fcil de implementar en los casos en que la discusin de un tema arroja una lista considerable de tems, la cual es necesario reducir. La tcnica consiste bsicamente en que a cada tem se le asigna un valor nico que lo identifica unvocamente, luego se le pide a cada uno de los presentes que exponga su opinin sobre cada tem. Esto se realiza para asegurarse de que todos los presentes han comprendido correctamente el significado de cada uno de los puntos indicados. Una vez finalizada la ronda de opiniones se reasigna una cantidad de votos a cada miembro. Esta cantidad se obtiene dividiendo la cantidad de tems por 3. Una vez asignados los votos cada miembro asigna sus votos a algn tem, teniendo en cuenta que: i. No se pueden asignar 2 puntos a un mismo tem. ii. Cada punto puede ir ponderado por importancia (de 1 a 3) por ejemplo. Luego de finalizada la ronda revotacin slo se eligen los tems mas populares y se pasa a una segunda ronda de votacin con el mismo sistema. Esta tcnica
Ing. Hernn A. Turin
62
resulta fcil de aplicar, rpida, divertida y es muy similar a la votacin comn y corriente por lo cual es muy recomendable su aplicacin.
Primero de Cinco: Esta es una tcnica que su utiliza para poder ponderar una serie de tems que se estn discutiendo en una reunin de equipo, asignando un nmero a cada tem, el cual indica el grado de acuerdo de cada miembro con dicho tem. El valor que se asigna se representa con los dedos de la mano, de modo que el valor puede ir de uno a cinco. El significado de cada valor es el siguiente: Cinco dedos significan "apoyo totalmente la mocin" Cuatro dedos significan "doy mi apoyo" Tres dedos significan "no estoy totalmente de acuerdo con la mocin pero la acepto como vlida " Dos dedos significan "Necesito que debatamos ms esta mocin" Un dedo significa "Estoy en contra de esta opcin"
sta tcnica permite revelar fcilmente cules son los puntos en los cuales el equipo est de acuerdo y cuales necesitan ser debatidos con mayor profundidad. Adems logra que fluyan nuevas ideas, esto se da en los casos en que una persona solo asigna uno o dos dedos a cada mocin, tras los cual se puede indagar sobre el porqu de este comportamiento y descubrir que la opcin con la cual ste miembro est totalmente de acuerdo no est en la lista y, de esta manera, agregarla al debate.
Criterios de Seleccin: An despus de un proceso de reduccin de opciones, nada garantiza que se llegue tan fcilmente a una decisin. Tal es el caso de que no exista consenso alguno entorno a ninguna de las posibilidades analizadas. En estos casos el equipo necesita que la toma de decisin se haga ms explcita. Un mtodo eficaz para esto es el establecimiento de los denominados criterios de seleccin. Estos criterios se especifican a travs de un cuadro que luego sirve al equipo como base para tomar una decisin. Se trata de una lista de factores crticos a considerar para hacer una seleccin entre diferentes alternativas.
Ing. Hernn A. Turin
63
Los criterios de seleccin son una herramienta sumamente til para revelar lo que motiva a las personas a elegir una alternativa por sobre la otra. La razn de la falta de consenso puede deberse a diferencias en lo que la gente cree son los factores ms importantes en la toma de una seleccin. De modo que resulta de gran utilidad hacer explcitos todos estos factores y, una vez logrado esto, el equipo puede trabajar en desarrollar una combinacin criterios a considerar para tomar la decisin. Normalmente, un cuadro criterios de seleccin se configura como una tabla en la cual la primer columna contiene los criterios, y luego cada una de las
alternativas a lo largo de la fila superior. A cada alternativa se le asigna una etiqueta y se puede describir ms en detalle en una hoja aparte. Cada criterio puede ser ponderado si es necesario, y cada una de las opciones valorada, por cada criterio, con una escala de 1 a 5. En el ejemplo de puntuacin en la Tabla VII, la opcin C recibi el ms alto puntaje general (15) y la opcin B la ms baja (11).
Criterios Beneficios Econmicos Relacin costo Beneficio Capacidad de administrar riesgos Facilidad de implementacin
Peso 50% 25% 15% 10%
Alternativas A B C D 2 3 4 5 3 3 4 5 2 2 3 2 5 3 4 2 Total 12 11 15 14
Tabla VII Ejemplo de cuadro se criterios de seleccin.
En algunos casos las puntuaciones finales de cada opcin pueden tener diferencias nfimas, especialmente cuando la lista de criterios es corta. En estos casos es conveniente ampliar la lista de criterios o bien utilizar los pesos de cada criterio. En este ltimo caso el clculo del puntaje para la opcin B sera: B= (3 x 50) + (3 x 25) + (2 x 15) + (3 x 10) = 285
4.2.2- WIKIS El trmino Wiki [Ebersbach, 2006] es de origen hawaiano y representa la abreviatura de la palabra Wiki Wiki que significa Rpido. En trminos de software 64
Ing. Hernn A. Turin
y tecnolgicamente hablando, el trmino remite a un software para la creacin de contenidos en forma colaborativa. Bsicamente una wiki es un sitio Web en el cul el contenido de las pginas puede ser editado por mltiples usuarios mediante la utilizacin de un navegador Web (browser). En este sitio los usuarios pueden agregar, modificar o eliminar informacin en un mismo artculo que est compartido entre ellos. La ventaja principal de una wiki es que permite crear pginas en forma instantnea o mejorar el contenido de las mismas mediante la utilizacin de una interfaz muy simple y fcil de utilizar por todos los usuarios (aunque no tengan demasiados conocimientos de informtica). Adems, segn como se defina la wiki, no es necesario que los usuarios estn registrados para poder ver, modificar o agregar informacin a la wiki o agregar una nueva pgina a la misma. Este tipo de pginas suelen crearse con la idea de que sea fcil corregir los errores cometidos en lugar de intentar que sea difcil cometerlos. Es por ello que la mayora de las wikis tienen una parte donde se pueden visualizar los cambios ms recientes donde se puede encontrar los artculos modificados (y las modificaciones hechas) dentro de cierto perodo de tiempo. Desde el punto de vista de la comunicacin dentro de un equipo de trabajo, la wiki representa una perspectiva diferente sobre el manejo de las comunicaciones internas. Esta herramienta permite controlar muy fcilmente la informacin del equipo permitiendo que el conocimiento circule entre los diferentes miembros del mismo manteniendo a todos mejor comunicados. Tener una wiki en una Intranet permite desde compartir el listado de telfonos y direcciones de correo electrnico de los miembros de un equipo u organizacin, hasta publicar mensajes sobre actividades varias (reuniones de trabajo, actividades recreativas, etc.) incluso hasta compartir documentos de un proyecto en particular. La wiki es una herramienta que fomenta principalmente el trabajo en grupo y el compartimiento del conocimiento de todos los participantes, y es por ello que dentro de un proyecto es recomendable poseer una Web de este tipo y fomentar su utilizacin. Esta recomendacin se basa fundamentalmente en el hecho de que la tendencia dentro de los grupos de trabajo, y en la sociedad en general, es la de crear una cultura de trabajo colaborativo y de conocimiento compartido y enriquecido por los aportes de los diferentes participantes. Es en este escenario donde las wikis se transforman en una herramienta vital para compartir informacin y hacer que todos los miembros de un
Ing. Hernn A. Turin
65
equipo estn al tanto de las comunicaciones y de las diferentes actividades y eventos que se suceden dentro del proyecto.
4.2.3- FOROS DE DISCUSIN Los foros de discusin son aplicaciones Web que permiten dar soporte al intercambio de opiniones o discusiones en lnea. Estas herramientas provienen de los sistemas de noticias conocidos como BBS (Bulletin Board System) que tuvieron su auge en las dcadas del 80 y el 90. Puede compararse a los foros con el sistema de Chat, con la diferencia de que en el caso del foro el intercambio de opiniones no es en tiempo real y que los mensajes persisten por un determinado perodo de tiempo (dependiendo de cada foro). Un foro de discusin permite compartir informacin sobre un tema en particular o sobre un determinado grupo de temas. Permiten el intercambio de opiniones acerca de un determinado tema (tpico) y favorecen la formacin de comunidades que comparten intereses comunes y que incluso, en algunos casos, hasta crean sus propias reglas de convivencia e incluso un lenguaje propio acorde al tema que los rene. En estos foros existe lo que se denomina moderador que es la persona encargada de supervisar los contenidos de los mensajes publicados y, si lo considera necesario, modificar o suprimir dicho mensaje. A diferencia de las wikis, los foros no permiten que cualquier usuario modifique la informacin publicada por otro usuario, al menos que el mismo posea permisos especiales como el caso del moderador que se mencionaba anteriormente. Existen diversos tipos de foros y cada uno de ellos posee su propia forma de publicar los mensajes y visualizar los mismos, aunque la mayora de ellos opta por agrupar todos los mensajes que se dan en respuesta a otro mensaje publicado con anterioridad. La idea es mantener la coherencia de los mensajes y evitar el caos en la publicacin. Al igual que en el caso de las wiki, la utilizacin de un foro como parte de un proyecto de TI, facilita la comunicacin entre los miembros del equipo y es especialmente til en los casos en que diferentes grupos del mismo proyecto se encuentran en ubicaciones fsicas (edificios) diferentes por lo que resulta engorroso tener que movilizarse para hacer una consulta breve (y que telefnicamente sera difcil
Ing. Hernn A. Turin
66
de hacer). Tambin ayuda a lograr una mayor informalidad en las relaciones y facilitar la relacin entre los miembros de un equipo. Esto ltimo es posible, por ejemplo, cuando sucede que en respuesta a un post aparece algn integrante sin demasiada relacin con el resto y a partir de all comienza a familiarizarse con el resto.
4.2.4-LISTAS DE CORREO Las Listas de correo son una forma especial de utilizar el correo electrnico a travs de la cual se facilita la distribucin masiva de contenidos en forma simultnea a una gran cantidad de usuarios mediante Internet. Para ello solo se enva el correo electrnico con el contenido que se desea distribuir (imagen, texto, documento, etc.) a la direccin que corresponda a la lista y, automticamente, todos los suscriptos a la lista recibirn dicho mail con todo su contenido. Estas listas son esencialmente tiles para mantener informados a los integrantes de un grupo acerca de las novedades que se producen dentro del mismo o para enviar informacin de inters. En los ltimos aos las listas de correo se han transformado en una herramienta corporativa y especialmente til para dar soporte tcnico a usuarios y realizar discusiones de carcter tcnico a travs de Internet. Junto con los foros, las listas de correo ha ido invadiendo el terreno de los denominados canales de noticias. Dentro de una empresa, la utilidad de esta herramienta est dada por: La facilidad para discutir temas tales como la eleccin de una u otra alternativa de accin. La posibilidad de tener un registro cronolgico del orden en que se generaron los temas y el momento en que particip cada usuario. La facilidad para notificar a un grupo de personas sobre un tema en particular en muy poco tiempo. Es el medio ideal para comunicaciones del tipo pregunta-respuesta. Adems junto con la wiki, los foros y la mensajera instantnea y el correo electrnico tradicional, constituye el pilar esencial y bsico para la comunicacin moderna dentro de una organizacin. Todos los beneficios listados anteriormente y enunciados para una empresa entera, son aplicables a un proyecto de IT, ya que recordemos que definimos a un
Ing. Hernn A. Turin
67
proyecto como una empresa temporal por lo que todos los conceptos aplicables a una empresa son aplicables tambin a un proyecto. De todo este es que se desprende la importancia de contar con una lista de correo para poder mejorar la comunicacin y facilitar la administracin del factor humano dentro de un proyecto de TI.
4.2.5- MENSAJERA INSTANTNEA La mensajera instantnea es una herramienta que se diferencia del correo electrnico en el hecho de que las conversaciones se realizan en tiempo real. Permite a cada usuario visualizar el estado de los dems, compartir archivos, e incluso realizar conferencias de voz. Hoy por hoy la mensajera instantnea ha ganado muchsimo terreno en el rea de las comunicaciones gracias a la flexibilidad que presenta para compartir contenidos e informacin. Adems, posee la ventaja de poder entablar una comunicacin con cualquier persona en cualquier lugar del mundo de modo que las distancias y los costos dejan de ser un problema. En la actualidad hay empresas en las que la comunicacin entre sus miembros es casi totalmente va mensajera instantnea, como es el caso de las empresas que trabajan con teletrabajo, donde las personas trabajan desde sus hogares y se comunican con sus compaeros y su jefe mediante el sistema de mensajes instantneos. Esto demuestra el nivel de incursin de esta herramienta, la gran utilidad que aporta y como puede resultar mucho mas amigable que, por ejemplo, un telfono. Sin embargo en muchas empresas el uso de este tipo de herramientas en muchas empresas est (o estaba) limitado debido a los problemas de seguridad que las mismas exhiban, haciendo vulnerable a todo el sistema de la organizacin. Para contrarrestar este problema, empresas como Microsoft y Yahoo se dedicaron a desarrollar herramientas de colaboracin en tiempo real que disminuyan los riesgos empresariales en materia de seguridad. Es entonces como aparecen nuevas herramientas de mensajera instantneas muy simples de utilizar y muy seguras desde el punto de vista informtico. Es por ello que hoy por hoy, los problemas de seguridad informtica ya no son un motivo de negativa para el uso de esta herramienta y, mucho menos, si se analizan las ventajas de la misma.
Ing. Hernn A. Turin
68
Dentro de un proyecto de IT se considera importante contar con una herramienta de este tipo, sobre todo en aquellos casos donde hay ubicaciones fsicas muy distantes y donde resulta difcil coordinar una reunin personalmente.
Como con cualquier herramienta, hay que ser racionales con la aplicacin y uso de las mismas, es importante recordar que los extremos no son buenos. Siempre se debe tener en cuenta que tanto las wikis como los foros, las listas de correos y las herramientas de mensajera instantneas deben usarse con precaucin y teniendo presente que no deben transformarse en la nica va de comunicacin dentro de un proyecto. No resulta conveniente que los mensajes en los foros o un mail a una lista termine reemplazando a las reuniones diarias o de avances. La idea es que estas herramientas fomenten la interaccin y el intercambio de opinin entre los miembros del equipo, pero no que se transformen en la nica va de comunicacin.
4.3-
PRACTICAS ESPECFICAS
En esta seccin se analizarn las caractersticas de aquellas prcticas que se
pueden implementar solamente en algunos de los grupos de procesos dentro de un proyecto de IT y que estn relacionadas con la administracin del factor humano. Las prcticas que se analizarn son las siguientes: Comits de Desarrollo Programacin de a Pares Comits de Usuario Grupos de Apoyo Mesa de Ayuda Estructura Desglosada de Trabajo CPM PERT Diagramas de Gantt COCOMO Puntos de Funcin Tcnica de Grupo Nominal Tcnica Delphi Anlisis Estadstico
Ing. Hernn A. Turin
69
4.3.1- COMITS DE DESARROLLO Se define como comit de desarrollo [Gurmendi, 2006] a aquel encuentro donde participan parte del equipo de proyecto y un grupo de usuarios expertos en las funciones de la empresa afectadas por el proyecto. El objetivo de este comit es el de validar cada uno de los requerimientos del sistema, tanto funcionales como no funcionales. Quedan fuera de esta lista aquellos aspectos tcnicos que tengan que ver con, por ejemplo, la tecnologa a utilizar. Tambin forma parte de las decisiones que toma este comit la validacin de las interfases como as tambin de los circuitos administrativos que se definan o modifiquen como parte del proyecto. Este tipo de comit tiene la ventaja de que es aplicable a cualquier tipo de proyecto de TI, desde aquellos que implican desarrollo de algn producto software hasta los que solo implican la implementacin de una nueva tecnologa. Este comit debe estar conformado de la siguiente manera: El lder del Proyecto. Un grupo de usuarios claves (Key Users) con conocimientos avanzados sobre las tareas afectadas por el proyecto. Uno o dos integrantes del equipo con perfil y conocimientos sobre la tecnologa que se utilizar para llevar adelante el proyecto. Dos integrantes del equipo de proyecto con perfil de analista funcional o similar. Un integrante del equipo encargado de documentar lo sucedido en el comit y que confeccione el acta correspondiente. La cantidad de usuarios no debera ser menor a tres ni mayor a ocho. Este nmero est basado en el hecho de que ya que si son menos de tres es difcil que esos usuarios tengan una visin completa de los procesos involucrados en el proyecto. En cuanto a la cantidad mxima se debe tener en cuenta que cuanto mayor es la cantidad de involucrados mayor ser el esfuerzo requerido para lograr unificar posturas y lograr consenso respecto de los temas tratados. Es necesario remarcar que los usuarios que participan en estos comits no deben variar de un comit a otro. Debe existir una permanencia de las personas que integran este grupo para que se mantenga la coherencia en cuento a las decisiones que se toman. En aquellos casos que se considere necesario la presencia de algn usuario ms, por algn tema particular, se lo puede incluir excepcionalmente en dicho comit.
Ing. Hernn A. Turin
70
En lo que respecta ala frecuencia con que se deben realizar, esta variar de acuerdo con el avance del proyecto. Inicialmente, se recomienda que estas reuniones se realicen cada 15 das o semanalmente (de acuerdo a los avances del equipo y las necesidades de aprobacin) ya que en las primeras instancias de la ejecucin es donde se confecciona y valida la lista de requerimientos y se validan las interfaces. A medida que avance el proyecto estas reuniones se planificarn con una frecuencia menor segn se considere necesario.
Adems de las reuniones, donde los participantes se ven cara a cara y discuten o presentan los temas por los cuales fueron convocados, existen otras herramientas que resultan particularmente tiles para agilizar y fomentar la comunicacin dentro del equipo de proyecto, sobre todo cuando se trata de temas que no ameritan la realizacin de una reunin para su discusin. Adems, estas herramientas sirven como complemento a las reuniones antes planteadas para conseguir una comunicacin eficiente. Dentro de estas herramientas las ms importantes y tiles para un proyecto son: el foro de discusin, las wikis, las listas de correos y la mensajera instantnea.
4.3.2- PROGRAMACIN DE A PARES La programacin de a pares [Beck, 1999] es un concepto utilizado en el mundo de la programacin extrema y que, si bien est mas especficamente orientado al desarrollo de software, tambin resulta importante su inclusin dentro de la lista de tcnicas propuesta. Esto se basa fundamentalmente en dos aspectos: el primero de ellos es que las tcnicas a utilizar para la administracin de personas dentro de un proyecto de TI deben cubrir todos los niveles dentro del proyecto, o sea desde la coordinacin hasta quienes ejecutan cada tarea. El segundo aspecto es que la mayora de los proyectos de tecnologa de la informacin incluyen el desarrollo o modificacin de un producto software, razn por la cul nuevamente es importante contar con alguna tcnica especfica del desarrollo de software. La programacin de a pares consiste en que dos desarrolladores participen y trabajen sobre un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo el trabajo que el otro no est haciendo en ese momento, e incluso puede que
Ing. Hernn A. Turin
71
mientras uno codifica el otro simplemente observe y trate de ver si se esta codificando correctamente o si existe algn error u omisin. La idea de esta tcnica es que una persona experimentada le ensee a una menos experimentada y de esta manera se logra que la persona menos capacitada pueda aprender directamente de la experiencia de su par y recibiendo explicaciones a medida de lo que necesita. As, por ejemplo, cuando se trabaja frente a una computadora la persona inexperta utilizar el teclado, para que el conocimiento de la persona experimentada tenga que fluir a travs del novato hacia la computadora. Cuando se implementa esta tcnica de colocar a un inexperto a trabajar con un experto, el aprendizaje es mucho mayor que con un plan de capacitacin convencional ya que es puramente prctico y las indicaciones tericas se harn solo cuando sean necesarias. Adems, un beneficio adicional es que frente a un problema es probable que aparezcan dos alternativas diferentes de solucin y que, luego de un anlisis detallado de ambas, el resultado probablemente tendr lo mejor de cada uno y ser ms eficiente. Por otro lado, el hecho de colocar dos personas a trabajar juntas los obligar a organizar sus tiempos para coordinar el trabajo y de este modo todo resulta ms provechoso. Finalmente, esta tcnica resulta muy motivadora para quien cumple el rol de principiante ya que tiene la posibilidad de aprender de alguien experto en la materia. Mientras que para el experto la motivacin est en poder transferir sus conocimientos, compartir sus ideas y mejorar su capacidad de comunicacin. Pero siempre debe haber compromiso y predisposicin en los participantes ya que de lo contrario no se vern las ventajas.
4.3.3- COMITS DE USUARIOS As como los comits de desarrollo sirven para formalizar la participacin de los usuarios en la ejecucin del proyecto mediante el aporte de opiniones, sugerencias y la aprobacin de entregables durante la ejecucin, los comits de usuarios [Gurmendi, 2006] tienen como finalidad la formacin de una comunidad de prctica donde los usuarios puedan plantear sus inquietudes y dudas referidas a la utilizacin del producto obtenidos por la realizacin del proyecto. La base de los comits de usuarios es la conformacin de las comunidades de prcticas, en las cules los usuarios comparten sus experiencias de modo que se realiza
Ing. Hernn A. Turin
72
en forma natural la transferencia de conocimiento. La realizacin de este tipo de comit requiere de un grupo de personas pertenecientes al equipo del proyecto que coordine las actividades y gue el encuentro. En los encuentros los usuarios plantean sus inquietudes, problemas y presentan las oportunidades de mejoras detectadas. Adems, el resto de los presentes puede colaborar con los dems proponiendo soluciones a alguno de los problemas planteados. La idea de este tipo de grupo es generar una red de colaboracin en la cul sean los propios usuarios los que generen conocimiento y debates, de modo que puedan detectarse mejora u oportunidades nuevas para enriquecer el proyecto. Al igual que las reuniones, se requiere de un lugar especfico para su realizacin, se debe definir la duracin y una agenda bsica a seguir. Adems debe definirse el proceso de facilitacin. El espacio fsico deber permitir que todos los asistentes puedan verse y escucharse para que todos puedan opinar y brindar su punto de vista respecto de los temas tratados. La frecuencia con que se deben realizar depender del proyecto y de la necesidad de los usuarios. Por lo general, en tiempo de ejecucin de un proyecto estos comits sean mas frecuentes. Mientras que, si se decide continuarlos durante la implementacin, se realizarn con menor frecuencia. Este tipo de encuentros tienen la ventaja de que se pueden seguir realizando aun finalizado un proyecto ya que, dependiendo de las caractersticas del producto generado, podra ser necesario mantenimiento y deteccin de oportunidades de mejoras, lo cual se puede detectar muy fcilmente en este tipo de encuentros. Estos comits son especialmente tiles cuando el proyecto implica la implementacin de un producto software o cuando se trata de la implementacin de una nueva tecnologa en la organizacin.
4.3.4- GRUPOS DE APOYO Muchas veces cundo se implementa un proyecto de TI que involucra la instalacin de un nuevo producto software, uno de los inconvenientes mas comunes suele ser la dificultad de los usuarios para comprender el mismo o, en otros casos, para utilizar correctamente y en su totalidad las prestaciones del mismo. En algunos de estos casos puede identificarse claramente la resistencia al cambio. Pero en otros la
Ing. Hernn A. Turin
73
resistencia al cambio puede no ser el motor de la no utilizacin, sino que la situacin se produce por o bien falta de tiempo para dedicarse a comprender el producto y sus funcionalidades (adicionalmente a la capacitacin que se les brinde como parte de la implementacin) o por dificultades propias de la formacin de las personas encargadas de operar dicho producto. Es en este segundo caso, donde se transforman en una tcnica muy til los grupos de apoyo. Un grupo de apoyo [Gurmendi, 2006] consiste en un grupo de personas con los conocimientos y habilidades suficientes como para dar soporte a los usuarios finales de un sistema y que brindan apoyo y colaboracin in situ. Esto significa que,
adicionalmente con el personal estable del o de las reas en las cuales se utiliza el sistema, se enva un grupo de personas que colaborarn en la nueva operatoria diagramada a partir de la implementacin puesta en funcionamiento del nuevo sistema. Bsicamente estas personas estarn ayudando a los usuarios a realizar sus actividades pero no en forma independiente sino que trabajarn en conjunto y en forma colaborativa funcionando como un consultor de modo que, ante cualquier duda, el usuario pueda consultarlo con esta persona e incluso pedirle la realizacin de un caso de ejemplo para comprender mas claramente el mecanismo. Se debe tener en cuenta que las personas que integren este grupo de apoyo deben tener una gran habilidad para relacionarse con todo tipo de usuarios y ser muy buenos comunicadores, de forma tal que todo lo que ellos transmitan sea claro y fcil de entender para lo usuarios. Adems, en el caso de que haya un producto software involucrado, deben tener un alto grado de conocimiento de las funcionalidades del mismo para poder evacuar las dudas de los usuarios. Es importante aclarar que la implementacin de este tipo de prcticas no se debe realizar por tiempo indeterminado, sino que debe tener una duracin definida que debe ser conocida por los usuarios, quienes tendrn que procurar obtener el mayor provecho posible de esta experiencia. La proporcin ideal en cuanto a la cantidad de personas que deben integrar el grupo vara de acuerdo a la carga de trabajo del rea a la que vayan a brindar soporte y de la cantidad de personas afectadas a la misma, pero lo ideal es que por cada tres usuarios del rea haya una persona del grupo de apoyo. En cuanto a la duracin del servicio del grupo en el rea, tambin depende del tamao del rea y de la cantidad de la complejidad de los procesos / procedimientos
Ing. Hernn A. Turin
74
sobre los cuales se deben dar soportes. Normalmente el tiempo no debera ser menor a una semana ni superior a tres semanas.
4.3.5- MESA DE AYUDA La mesa de ayuda es una de las tcnicas ms populares y mas utilizadas en las organizaciones para dar soporte a los usuarios. La idea de la mesa de ayuda es que los usuarios tengan disponible en todo momento un lugar al cual se puedan dirigir en caso de tener algn inconveniente en la utilizacin de un sistema. Esta tcnica es tpicamente utilizada para dar soporte en los casos en que hay un producto software de por medio y no para ayudar a resolver problemas con procedimientos administrativos. Esta caracterstica es una de las que lo diferencia fundamentalmente de los grupos de apoyo. Adems en este caso el grupo de soporte no se encuentra in situ donde estn trabajando los usuarios, sino que se encuentra fsicamente en un lugar separado y la comunicacin se puede dar tanto por va telefnica como por medio de mensajera instantnea. Una caracterstica particular de la mesa de ayuda es que esta no se utiliza solamente cuando se implementa un sistema/proyecto y durante un perodo de tiempo estipulado, sino que debera transformarse en un rea mas, con personal estable y perdurable a travs del tiempo. La mesa de ayuda tiene dos propsitos, el primero es ayudar al usuario a resolver cualquier problema que tenga referido al sistema, y el segundo es ayudarlos a utilizar el mismo de forma efectiva. Adems pueden diagramarse de modo que no solo ofrezcan ayuda desde el punto de vista funcional sino que tambin sirvan como soporte tcnico. En este ltimo caso la solucin puede ser que se brinde instantneamente o que se ingrese una solicitud de servicio para que sea atendida por personal apropiado cuando el mismo est disponible. Es importante considerar que este servicio puede ser brindado por un rea que forma parte de la organizacin o puede organizarse como un servicio tercerizado que, incluso, puede no estar en el mismo lugar fsico que el resto de la organizacin. Respecto del tamao del grupo que forma parte de la mesa de ayuda, nuevamente depende de la carga de trabajo y del tamao de la organizacin, pero el equipo puede variar entre 2 y 10 personas para el caso de grandes organizaciones.
Ing. Hernn A. Turin
75
4.3.6- ESTRUCTURA DESGLOSADA DE TRABAJO La Estructura Desglosada de Trabajo (EDT) o Work Breackdown Structure [PMI, 2004], es una tcnica de planeacin que permite definir y cuantificar el trabajo que se debe realizar a lo largo de todo el proyecto. Esta tcnica permite organizar y definir el mbito total del proyecto y consiste en una representacin grfica de las diferentes actividades que se han de llevar a cabo para la realizacin de un proyecto. Dichas actividades estarn agrupadas en paquetes de trabajo. El propsito de una EDT es dividir el proyecto en porciones que luego sean fciles de planificar en cuanto a tiempo, costos y recursos necesarios. En el nivel ms alto de la estructura de una EDT, se encontrar el objetivo del proyecto o la fase del mismo que se est gestionando. En el segundo nivel se indican cules son las metas ms importantes que se deben conseguir para lograr el objetivo del nivel superior. Mientras que en el tercer nivel se divide cada una de las metas en hitos mas pequeos. As la estructura del proyecto se divide en niveles y sub-niveles hasta alcanzar las denominadas unidades de trabajo. Cada una de las tareas tiene asignado un cdigo numrico gracias al cual es posible identificar a que paquete de trabajo pertenece cada tarea y en que nivel de la estructura se encuentra ubicado. Las unidades de trabajo son actividades pequeas cuya duracin no debera exceder la semana de trabajo y que son asignables a una persona. El algoritmo que se sigue en general para poder realizar la construccin de una WBS es el siguiente: 1- Se identifica una tarea a realizar y se la suma a la lista de tareas. 2- Se identifican las entradas, salidas y recursos necesarios para la ejecucin de esa tarea. Adems se determina si esa tarea puede ser llevada a cabo con una meta exacta. 3- Si se puede llevar a cabo dicha tarea, ir al paso siguiente. En caso contrario, continuar con las dems tareas y convertir la anterior en un hito. 4- Repetir desde el paso 2 con cada una de las tareas identificadas en el paso 1 hasta finalizar con las tareas identificadas. 5- Verificar la lista de tareas procesadas y acumular la duracin de las mismas en los hitos. El nmero de niveles que comprende la EDT depende de la complejidad del proyecto. Las tareas resultantes de dicha divisin de trabajo deben resultar de modo tal
Ing. Hernn A. Turin
76
que al culminar con la realizacin de todas y cada una de las tareas definidas, automticamente se de por finalizado el proyecto. Existen varias maneras de representar grficamente una EDT. Las ms comunes son la representacin a travs de un rbol o un listado. En la Figura 9 se muestra un esquema de ejemplo para una EDT propuesto por el PMBOK.
Figura 7 Esquema de una EDT propuesto por el PMBOK [PMI, 2004]
Este tipo de esquemas puede ir acompaado de una tabla en la cual adems se indiquen datos tales como el responsable de la tarea, la fecha de inicio, la fecha de finalizacin y la duracin total de la tarea. La EDT es una herramienta muy til para tener una visin completa del trabajo que implica un proyecto y tambin para poder realizar estimaciones con mayor exactitud. En general, los proyectos pueden fracasar an cuando tengan una buena planificacin y se ejecuten de manera correcta, pero en muchos casos los fracasos se remontan a una EDT pobre o mal desarrollada.
Ing. Hernn A. Turin
77
4.3.7- CPM CPM [Winston, 2005] es un mtodo usado por la direccin de un proyecto para, con los medios disponibles, realizar la planificacin de dicho proyecto y lograr su objetivo con xito. Este mtodo no pretende sustituir las funciones de la direccin, sino que busca darle soporte a las mismas La funcin de CPM no es la de resolver problemas sino que relaciona todos los factores de un problema de manera que presenta una perspectiva ms clara para su ejecucin. En un proyecto muchas veces la toma de decisiones no resulta fcil para la direccin debido a la gran incertidumbre. La idea de CPM es la de ofrecer un medio eficaz de reducir sta incertidumbre, y que las decisiones tomadas y acciones emprendidas sean las mas adecuadas al problema, mejorando en gran medida las posibilidades de xito. Uno de los principales inconvenientes que se presentan en la realizacin de proyectos grandes y complejos es cmo lograr una correcta coordinacin entre las diversas actividades para alcanzar el objetivo deseado. Este problema deriva del hecho de que cada una de las reas que participa en el proyecto suele tener su propio plan de trabajo o planificaciones pero en forma independiente del resto. Esta independencia es la causa de la falta de coordinacin en del proyecto en su totalidad. CPM es una tcnica que provee una visin integral de todas las actividades involucradas en el proyecto y de la relacin que existen entre las mismas. El Mtodo de Ruta Crtica (CPM) es un mtodo determinstico, el cual permite visualizar de manera muy sencilla cul es la ruta crtica de un proyecto. Se define como ruta crtica a la secuencia de tareas de mayor duracin dentro del proyecto que definen la duracin del mismo, de modo que si alguna de estas tareas sufre una demora, de retrasar la finalizacin del proyecto. La formulacin de un CPM se basa en: 1- Identificar cules son todas las actividades que se deben realizar dentro del proyecto. 2- Construir la red de actividades utilizando nodos y flechas, de modo que todas las actividades identificadas estn representadas en dicha red. 3- Realizar todos los clculos que sean necesarios para determinar cual es el camino crtico y cules son las holguras del proyecto.
Ing. Hernn A. Turin
78
En todos los proyectos existen actividades que cuentan con cierta flexibilidad en cuanto al tiempo en que deben comenzar y terminar. Pero hay otras en las cuales esto no ocurre. A estas ltimas se las denomina tareas crticas, y son las que constituyen el camino crtico, mientras que las primeras se denominan tareas no crticas. En la construccin de la red de actividades del proyecto, una actividad est compuesta por dos partes: la ejecucin del trabajo (que se representa por una flecha de izquierda a derecha) y los sucesos iniciales y finales (que se representan con dos crculos al inicio y al final de la flecha). En la Figura 9 se muestra como quedara graficada la tarea A.
Figura 8 Representacin grfica de una tarea.
Es importante destacar que la longitud de las flechas no tiene relacin alguna con la duracin de la tarea, mientras que la orientacin de la flecha simplemente se realiza de esta manera debido a que el tiempo no retrocede sino que siempre avanza. En el armado de la red, cuando una tarea precede a otra, el suceso final de la primera ser el inicial de la segunda (ver figura 10). Es importante que al momento de construir la red, se tenga muy presente la relacin entre las tareas, de modo que siempre se sepa que tarea precede y sucede a otra.
Figura 9 Representacin grfica de dos tareas en secuencia.
El suceso inicial del proyecto, no posee una actividad que lo preceda, mientras que el suceso final del proyecto no tiene ninguna actividad que lo contine. Cada uno de los nodos de la red debe ir numerado. El estndar mas usado para la nomenclatura es utilizar nmeros y la forma de asignacin de los mismos es ascendente se izquierda a derecha y desde arriba hacia abajo. Existen algunos casos en que existe una dependencia entre dos actividades, pero no por la necesidad de ejecutar un trabajo en particular, sino por circunstancias muy particulares generalmente cuando se necesita mostrar la relacin de precedencia en forma visual. Para estos casos se utilizan las denominadas Tareas Ficticias. Estas
Ing. Hernn A. Turin
79
tareas se representan por flechas con lnea punteada y no tienen una duracin, por lo cual se les asigna tiempo 0. Para poder llevar adelante el armado del diagrama es necesario determinar claramente cual es el objetivo del proyecto, de modo que ste estar representado en el ltimo nodo del diagrama. Luego se deber establecer la lista de tareas a realizar para alcanzar dicho objetivo y finalmente establecer la precedencia de dichas tareas. Esto ltimo es fundamentalmente importante para el correcto armado de la red de modo que se visualice claramente cual tarea va antes y cual la subsigue. Una vez construida la red, se deben asignar las duraciones a cada una de las tareas. En el caso de CPM, se habla de un mtodo determinstico, por lo cual habr solo una duracin y exacta. A continuacin se muestra la tabla de actividades con las duraciones y predecesoras de cada una: Tarea A - Reingeniera de Procesos B - Anlisis Funcional C - Diseo Tcnico D - Conversin de datos E - Personalizacin del sistema F Capacitacin de Procesos G Prueba de la Solucin H Capacitacin de Usuarios I Produccin Duracin Predecesoras 2 5 A 8 B 6 C 9 B 5 A 6 E 9 D,G 3 H,F
Tabla VIII Ejemplo de actividades de un proyecto para un CPM
Luego de determinada la secuencia de actividades y las duraciones de cada un se procede a construir la red como se muestra en la Figura 11.
Figura 10 Diagrama de red que representa las actividades de la Tabla VIII.
Ing. Hernn A. Turin
80
Analizando la red se puede determinar fcilmente que el camino mas largo dentro del diagrama es A-B-E-G-H-I y por lo tanto ste es el camino crtico del proyecto. Este camino defina la duracin del proyecto, que en este caso es de 34 das. En la Figura 12 se remarcan las actividades que pertenecen al camino crtico.
Figura 11 Identificacin del camino crtico.
En el anlisis de una red CPM aparece un nuevo concepto asociado que es el de Holgura. Se define como Holgura a la cantidad de tiempo que se puede demorar una actividad en particular, sin afectar la duracin total del proyecto. Es decir que indica el tiempo libre que existe dentro de la red. Para poder analizar la holgura debemos analizar el grfico de modo que se puedan determinar la fecha ms temprana y fecha ms tarda. Para ello debemos: 1. Comenzar en 0 desde la primera actividad y sumarle la duracin de la misma, con lo que obtendremos la fecha ms temprana de la actividad B (Figura 13).
Figura 12 Fecha ms temprana de B.
2. Sumar a la fecha ms temprana de B, la duracin de la actividad B. De este modo se obtiene la fecha ms temprana de C (Figura 14).
Ing. Hernn A. Turin
81
Figura 13 Fecha ms temprana de C.
3. Repetir el mismo clculo para cada nodo. Teniendo en cuenta que si desde dos caminos diferentes se llega a un mismo nodo, la fecha elegida ser la mayor. La figura 15 muestra el diagrama con el clculo de las fechas ms tempranas.
Figura 14 Diagrama con el clculo de fechas ms tempranas.
4. Comenzar el anlisis hacia atrs, por el ltimo nodo y restndole a 34 la duracin de la ltima actividad (o sea 9), de modo que se obtiene la fecha ms tarda para estar en el nodo H (Figura 16).
Ing. Hernn A. Turin
82
Figura 15 Diagrama con el clculo de fecha ms tarda para le nodo H.
5. Continuar con el anlisis de la misma manera para los dems nodos, teniendo en cuenta que cuando dos tareas provienen del mismo nodo, se tome el menor valor (Figura 17).
Figura 16 Diagrama completo con fechas tardas y tempranas.
Como desventaja se puede mencionar que esta tcnica adolece del problema de que no tiene en cuenta la incertidumbre asociada al proyecto, por lo cual resulta sumamente til en proyectos repetitivos en los cuales las actividades ya tienen una duracin conocida, pero no es recomendable en proyectos con mayor nivel de incertidumbre. sta tcnica resulta sumamente til para tener un diagrama claro y fcil de entender de las actividades que forman parte del proyecto. De este modo, sabiendo cul es la asignacin de los recursos, se puede realizar una mejor distribucin y asignacin de las personas involucradas en el mismo. Es en este punto en el que CPM se transforma en un tcnica importante en el manejo de del factor humano en los proyectos, especialmente en los de TI.
Ing. Hernn A. Turin
83
4.3.8- PERT sta es otra tcnica que se utiliza para reflejar las actividades que forman parte de un proyecto y las relaciones que existen entre ellas. Similar al CPM, PERT
[Winston, 2005] se diferencia en los siguientes aspectos: Es probabilstico. Considera que el tiempo es una variable desconocida sobre la cual solo se pueden tener estimaciones. Supone que la distribucin de los tiempos de las actividades son independientes y que la varianza del proyecto es la suma de las varianzas de las tareas que componen el camino crtico. La duracin del proyecto est determinada por la suma de los tiempos esperados de las tareas que componen el camino crtico. En PERT cada actividad est compuesta por: a- Tiempo Optimista (ta): Es el mnimo tiempo en el cual puede ser completada una tarea o actividad en el caso de que todo funcione de acuerdo a lo planificado. b- Tiempo Pesimista (tb): Es el tiempo mximo en el cual puede ser completada una tarea o actividad considerando que se dan las condiciones ms desfavorables posibles. c- Tiempo Ms Probable(tm): Como su nombre lo indica, es el tiempo mas probable en el que se ejecutar una tarea o actividad. En otras palabras, el tiempo mas probable es el tiempo normal de ejecucin de una actividad si esta se repitiera muchas veces (este tiempo es el que se utiliza en CPM como duracin de cada actividad). d- Tiempo Esperado (te): Es el tiempo en el que se espera que sea ejecutada una actividad o tarea. En PERT, el valor de este tiempo se calcula de acuerdo a la siguiente frmula:
te =
t a + 4t m + t b 6
La Tabla IX muestra como seran los tiempos de las actividades analizadas en CPM, pero con la aplicacin del mtodo PERT.
Ing. Hernn A. Turin
84
Tarea A Reingeniera de Procesos B - Anlisis Funcional C - Diseo Tcnico D - Conversin de datos E - Personalizacin del sistema F Capacitacin de Procesos G Prueba de la Solucin H Capacitacin de Usuarios I Produccin
Predecesoras A B C B A E D,G H,F
Ta 2 3 6 6 7 3 5 9 2
Tm 2 5 8 6 9 5 6 9 3
Tb 4 8 11 10 10 7 8 15 5
Te 3 5 8 7 9 6 6 10 3
Tabla IX Ejemplo de actividades de un proyecto para un PERT
En este caso, la duracin del camino crtico A-B-E-G-H-I es de 36 das. Otro de los conceptos que se incorpora en el mtodo PERT es el concepto de varianza, que es un concepto que indica la incertidumbre asociada con la estimacin de la duracin de cada actividad. Si la varianza es grande, significa que hay gran incertidumbre sobre el tiempo de finalizacin de la actividad. Por el contrario, si la varianza es pequea, significa que la estimacin de la duracin de la actividad en cuestin es bastante precisa. La frmula para el clculo de la varianza es la siguiente:
2 te =
(t b t a ) 6
Tarea A B C D E F G H I
Predecesoras A B C C B D,E F G
Ta 2 3 6 6 7 3 5 9 2
Tm 2 5 8 6 9 5 6 9 3
Tb 4 8 11 10 10 7 8 15 5
Te 3 5 8 7 9 6 6 10 3 Total
Varianza 0.11 0.69 0.69 0.44 0.25 0.44 0.25 1 0.25 1
Tabla X Ejemplo de actividades de un proyecto para un PERT con varianza calculada
La Tabla X muestra el clculo de la varianza para cada una de las actividades de un proyecto. De acuerdo a la informacin contenida en la tabla, se puede determinar que la duracin del proyecto ser de 36 +/- 1 das.
Ing. Hernn A. Turin
85
Como se acaba de analizar, PERT aventaja a CPM en el hecho de que incorpora el concepto de incertidumbre y permite tener una visin ms integral sobre las fechas y los tiempos asociados a un proyecto y las posibles variaciones en los mismos. Como desventaja se puede mencionar el hecho de que se considera que la distribucin de los tiempos de las actividades es independiente. Desde el punto de vista de la administracin de proyecto, se transforma en una herramienta muy til especialmente para analizar ciertos tems tales como la holgura en una actividad, y por tanto, la disponibilidad de un recurso en un momento determinado. Cuando los recursos son personas, es cuando comienza a cobrar importancia para la administracin de las personas.
4.3.9- DIAGRAMAS DE GANTT El denominado Diagramas de Gantt [Kendall, 1997] es un tipo de grfico creado por Henry L. Gantt. La idea de este grfico es la de resolver el problema de la programacin de actividades, es decir, la distribucin de las mismas de acuerdo a un calendario, de modo tal que se pudiese visualizar la duracin de cada actividad, las fechas de iniciacin y terminacin de cada una, como as tambin el tiempo total requerido para la ejecucin de un trabajo. Este diagrama permite adems obtener un seguimiento del curso de cada actividad, ya que proporciona informacin relacionada con el porcentaje ejecutado de cada una de las tareas y el estado (adelanto o retraso) de la misma con respecto al plazo previsto. El grfico de Gantt consiste simplemente en un sistema de ejes cartesianos en los cuales se indica: En el eje Horizontal (tiempo): En este eje se indica el calendario, el cual estar expresado en la unidad de medida mas adecuada al trabajo que se realizar (horas, das, semanas, meses, etc). En el eje Vertical (actividades): En este eje se indican las actividades que forman parte del total del trabajo a realizar. A cada una de las actividades indicadas en este eje, le corresponde una lnea horizontal cuya longitud es proporcional a su duracin de acuerdo a la escala definida en el eje del tiempo.
Ing. Hernn A. Turin
86
Smbolos Adicionales: De acuerdo a la herramienta utilizada para la construccin de este tipo de diagramas, puede que se introduzcan smbolos particulares y aplicables a ciertos tipos de proyectos. Entre los smbolos ms usuales se encuentran los hitos, inicio de tarea, fin de tarea, etc.
Desde su creacin, los diagramas de Gantt se han convertido en una herramienta bsica en la gestin de proyectos de todo tipo, ya que permite representar en forma muy sencilla las diferentes fases, tareas y actividades programadas como parte de un proyecto o para mostrar una lnea de tiempo en las diferentes actividades haciendo el mtodo ms eficiente. La creacin de un diagrama de este tipo consiste en los siguientes pasos: 1. Identificar las actividades que formarn parte del trabajo a realizar. 2. Determinar la duracin de cada una de las actividades. 3. Identificar las dependencias entre las actividades como as tambin el orden en que deben comenzar a ser ejecutadas. 4. Confeccionar el grfico de acuerdo a las tareas definidas, su duracin y el calendario definido para las mismas.
En la Figura 17 se muestra el diagrama de Gantt para el ejemplo mostrado en la Tabla VIII.

A B C Actividades D E F G H I 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 Duracin (das)
Figura 17 Diagrama de Gantt para las actividades de la tabla VIII.
Ing. Hernn A. Turin
87
La ventaja principal del diagrama de Gantt radica en que para su armado se requiere un nivel mnimo de planificacin por lo que pueden se r utilizados en las primeras etapas de un proyecto. Sin embargo, despus de iniciada la ejecucin actividad y cuando comiencen a efectuarse modificaciones en la planificacin, el grfico puede volverse confuso. Por eso se utiliza mucho la representacin grfica del plan, en tanto que los ajustes en la planificacin requieren por lo general de la formulacin de un nuevo grfico. En trminos de planificacin, este diagrama adolece de una limitacin bastante grande en lo que refiere a la representacin de planes de cierta complejidad. Gantt no ofrece condiciones para el anlisis de opciones, ni toma en cuenta factores como el costo. Es fundamentalmente una tcnica de prueba y error. No permite, tampoco, la visualizacin de la relacin entre las actividades cuando el nmero de stas es grande. En la actualidad existe una gran cantidad de herramientas informticas que permiten confeccionar y mantener muy fcilmente los diagramas de Gannt de un proyecto. Esto hace que su facilidad de implementacin sea aun mayor y ms til en todos los casos. En resumen, para la planificacin de actividades relativamente simples, el grfico de Gantt representa un instrumento de bajo costo y gran simplicidad de uso. Pero para proyectos complejos, sus limitaciones llevan al uso adicionas de las tcnicas de CPM o PERT.
4.3.10- COCOMO El mtodo COCOMO (Constructive Cost Model) [Boehm, 2000] es un modelo utilizado para realizar la estimacin del costo de un producto software. Este modelo incluye tres submodelos en el que cada uno ofrece un nivel de detalle y una
aproximacin que vara de acuerdo al avance del proyecto. Este modelo fue desarrollado por Boehm en 1981 de acuerdo con las tcnicas de desarrollo de software utilizadas en aquel momento, pero posteriormente (en el ao 1997) se desarrollo COCOMO II el cul puede ser utilizado con las tcnicas modernas de desarrollo. COCOMO es un modelo que se basa en la estimacin matemtica y est orientado a determinar cual ser el tamao del producto final, lo cul se mide en cantidad de lneas de cdigo fuente. Los tres submodelos que componen a COCOMO
Ing. Hernn A. Turin
88
son: Bsico, Intermedio y Avanzado. Estos tres modelos utilizan una funcin bsica que permite estimar el esfuerzo de de desarrollo. Esta funcin tiene la siguiente forma:
E = aS b m( x )
Donde: S: es el nmero de miles de lneas de cdigo fuente. m(x): s un multiplicador que depende de 15 atributos. a y b: son valores constantes definidos de acuerdo a cada submodelo.
Adems, cada submodelo se divide en modos que representan los diferentes tipos de proyectos. Estos modos pueden ser: Orgnico: El proyecto est desarrollado por un grupo pequeo de programadores expertos que trabajan en un entorno conocido. En este caso el tamao del producto software vara entre un tamao pequeo (algunas miles de lneas de cdigo) y un tamao medio (decenas de miles de lneas). Semi-acoplado: En este caso el proyecto se desarrolla por un grupo de desarrolladores mixto. Esto significa que existen desarrolladores
experimentados y no experimentados trabajando sobre el mismo proyecto. Empotrado: En este caso el proyecto es llevado a cabo por un grupo de desarrollo no experimentado. Adems, en este caso el proyecto tiene grandes restricciones relacionadas con las funcionalidades del producto software a construir o con las tcnicas a utilizar en el mismo, lo cual se agrava con la falta de experiencia del equipo de desarrollo.
De acuerdo con el modo al cual se asocie al proyecto, los valores de las constantes a y b se obtendrn de acuerdo a lo que se muestra en la tabla XI.
Orgnico Semi-acoplado Empotrado
Bsico ai bi 2.40 1.05 3.00 1.12 3.60 1.20
Intermedio ai bi 3.20 1.05 3.00 1.12 2.80 1.20
Tabla XI Coeficientes de COCOMO segn submodelo y modo utilizado [Boehm, 2000].
Ing. Hernn A. Turin
89
MODELO BASICO ste modelo se utiliza para tener una primera aproximacin del esfuerzo necesario para el desarrollo de un producto software. La idea de este modelo es obtener una estimacin rpida aunque no demasiado exacta del esfuerzo necesario para llevar adelante el proyecto. En este modelo se deben utilizar las constantes correspondientes a la columna Bsico de la Tabla XI. Si se observa con atencin esta tabla, se puede observar como, a medida que aumenta la complejidad del proyecto, aumenta en forma considerable la constante relacionada con el personal (a). Esto implica que se debe ser muy cuidadoso al utilizar este modelo debido a que no tiene en cuenta muchas caractersticas del entorno en que se lleva a cabo el proyecto.
MODELO INTERMEDIO ste modelo aade al modelo bsico quince atributos denominados modificadores relacionados con el costo, para tener en cuenta el entorno de trabajo. Estos modificadores aumentan la precisin de la estimacin realizada. Los valores a utilizar en las constantes, tambin se muestran en la Tabla XI, en la columna Intermedio. Los quince atributos que se agregan en este modelo son los siguientes: Atributos de software RELY: Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Este atributo puede ir desde la sola inconveniencia de corregir una falla (muy bajo) hasta la posible prdida de vidas humanas (extremadamente alto) DATA: Indica el tamao de la base de datos relacin con el tamao del programa. CPLX: Indica la complejidad del producto.
Atributos de hardware TIME: Indica las restricciones en los tiempos de ejecucin. STOR: Indica las limitaciones en el porcentaje del uso de la memoria. VIRT: Indica la volatilidad de la mquina virtual. TURN: Indica el tiempo de respuesta.
Ing. Hernn A. Turin
90
Atributos de personal ACAP: Indica la capacidad de los analistas. AEXP: Indica la experiencia del personal en aplicaciones similares. PCAP: Indica la calificacin de los programadores. VEXP: Indica la experiencia del personal en la mquina virtual. LEXP: Indica la experiencia en el lenguaje de programacin a usar.
Atributos de proyecto MODP: Determina el uso de prcticas modernas de programacin. TOOL: Indica el uso de herramientas de desarrollo de software. SCED: Indica las limitaciones en el cumplimiento de la planificacin. Los valores para cada uno de estos atributos estn dados por la calificacin asignada a cada uno y se pueden visualizar en la Tabla XII. Valor Atributos
Muy Bajo Bajo Nominal Alto Muy Alto Extra alto
RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED
Atributos de software 0,75 0,88 1,00 0,94 1,00 0,70 0,85 1,00 Atributos de hardware 1,00 1,00 0,87 1,00 0,87 1,00 Atributos de personal 1,46 1,19 1,00 1,29 1,13 1,00 1,42 1,17 1,00 1,21 1,10 1,00 1,14 1,07 1,00 Atributos del proyecto 1,24 1,10 1,00 1,24 1,10 1,00 1,23 1,08 1,00
1,15 1,08 1,15 1,11 1,06 1,15 1,07 0,86 0,91 0,86 0,90 0,95 0,91 0,91 1,04
1,40 1,16 1,30 1,30 1,21 1,30 1,15 0,71 0,82 0,70
1,65 1,66 1,56
0,82 0,83 1,10
Tabla XII Valores para los atributos del Submodelo INTERMEDIO de COCOMO [Boehm, 2000]. Ing. Hernn A. Turin
91
La valoracin de cada atributo tiene cierta componente de subjetividad. En algunos casos se pueden tener parmetros aproximados para asignar la valoracin, pero en otros casos esto no es tan sencillo. Para el caso de RELY se considera lo siguiente: Muy Bajo: el efecto de un fallo del software simplemente trae como consecuencia la inconveniencia de corregir el fallo Bajo: el efecto de un fallo software es una prdida fcilmente recuperable para los usuarios Nominal: el efecto es una moderada prdida para los usuarios, pero es una situacin de la que se puede salir sin excesiva dificultad Alto: el efecto es una gran prdida financiera o una inconveniencia masiva humana Muy Alto: el efecto es una prdida de vidas humanas. Para el caso de DATA ser: Hay cuatro segmentos con la razn 10-100-1000, que determinan las puntuaciones de Bajo a Muy Alto. Este se define por el siguiente cociente: Tamao _ de _ la _ base _ de _ datos _ en _ bytes Tamao _ del _ programa _ en _ DSI Para el caso de CPLX ser Bajo si el mdulo est formado por expresiones matemticas sencillas y Extra Alto para el caso de mdulos que utilizan recursos que deben ser planificados. En el caso de TIME se considera que el valor es Nominal, si el tiempo disponible para la ejecucin es del 50 % del tiempo, mientras que si la restriccin es del 95 % entonces ser Extra Alto. Para STOR se considera Nominal el caso de que la reduccin del almacenamiento principal es del 50 %, mientras que se considera Extra Alto si la reduccin es del 95 %. En el caso de VIRT se considera Bajo cuando la mquina en que correr la aplicacin casi no vara durante el desarrollo, mientras que si la variacin es mucha ser Muy Alto. Para el caso de TURN, cuanto mayor sea el tiempo de respuesta, mayor ser el esfuerzo humano. Se considera Bajo cuando el sistema es muy interactivo y Muy Alto cuando el tiempo de respuesta es de mas de 12 horas. En el caso de ACAP, cuanto mayor sea la capacidad de los analistas, mas alto ser el valor del atributo. Para AEXP, se considera que es Muy Bajo cuando se tiene menos de cuatro meses de experiencia, Bajo cuando tiene un ao de experiencia, Nominal para tres aos de
Ing. Hernn A. Turin
92
experiencia, Alta para seis aos de experiencia y Muy Alta cuando tienen mas de 12 aos de experiencia. El caso de PCAP, es similar que ACAP pero considerando a los desarrolladores como grupo y no en forma individual. Para VEXP, se considera que ser Muy Bajo si la experiencia del grupo de programacin con el procesador es menor a un mes y ser Alto cuando dicha experiencia sea mayor a tres aos. Para LEXP, ser Muy Bajo cuando la experiencia en promedio sea menor a un mes y Alta cuando supere los tres aos. MODP, ser Muy Bajo si no se utilizan tcnicas de programacin modernas, y Muy Alto si tiene experiencia y habitualmente utiliza dichas tcnicas. En el caso de TOOL, va desde Muy Bajo para el caso en que no se utilicen herramientas o slo se utilicen algunas muy bsicas, hasta Muy Alto cuando se utilizan tcnicas avanzadas y muy especficas. Finalmente SCED, ser Muy Bajo el proyecto se acelera y Muy Alto si el proyecto se retrasa.
MODELO DETALLADO ste modelo introduce al intermedio dos caractersticas principales: 1- Multiplicadores de esfuerzo sensitivos a la fase: Algunas de las fases del proyecto se ven mas afectadas que otras por algunos atributos tales como la experiencia en la aplicacin y los conocimientos de ciertas herramientas de software. El modelo detallado incluye una serie de de multiplicadores cuyo valor vara de acuerdo con la etapa del proyecto. 2- Jerarqua de productos de tres niveles: Se establecen tres niveles de productos que son Mdulo, Subsistema y Sistema. Esta cuantificacin se realiza de modo que los aspectos que representan gran variacin se consideran a nivel mdulo, las que representan pocas variaciones, a nivel subsistema; y los restantes a nivel sistema. El COCOMO detallado se basa en dividir el esfuerzo de en fases, de modo que en cada una de ellas se obtenga un factor de costo para finalmente obtener el costo total a partir de la suma de los costos de cada fase. Las fases que se consideran son: Determinacin de requerimientos, diseo del producto, desarrollo y finalmente prueba.
Ing. Hernn A. Turin
93
En lneas generales se puede concluir diciendo que COCOMO es una tcnica muy til para estimar el esfuerzo necesario para llevar adelante un proyecto de TI que implica el desarrollo de un producto software. El principal inconveniente que posee es que depende en gran medida de la experiencia en proyectos previos, cosa que en muchas organizaciones no existe. Pero resulta til debido a que permite tener una visin global de la relacin entre los diferentes factores que afectan al costo de un proyecto.
4.3.11- PUNTOS DE FUNCIN La mtrica de puntos de funcin [ISO/IEC, 2007], es una tcnica utilizada para medir el tamao de un producto software. Este mtodo fue creado en 1979 por Allan Albrecht y tiene como objetivo la obtencin de una medicin del producto que se le entrega al usuario independientemente de la tecnologa utilizada para el desarrollo del mismo. Este mtodo puede ser utilizado en cualquiera de las etapas del ciclo de vida del desarrollo de un producto software sea en el inicio del mismo o en cualquiera de las dems etapas. El tamao de un producto software podra medirse en trmino de la cantidad de bytes que el mismo ocupa en el disco rgido, o bien en trminos de cantidad de lneas de cdigo fuente necesarias para alcanzar las funcionalidades deseadas. En otros casos se puede medir el tamao de un software en trminos de las funcionalidades que el mismo proporciona. El problema es seleccionar cual de estas alternativas es la mas
conveniente para obtener una medida que permita tener una correlacin con el esfuerzo necesario para llevar adelante dicho proyecto. Una de las consideraciones que se deben hacer es que la sola utilizacin de lneas de cdigo para la medicin del tamao puede ser engaosa. Esto se basa en el hecho de que la etapa de codificacin es apenas una etapa dentro de todo el ciclo de vida y que apenas representa un aproximadamente un 25 % del costo total del proyecto (ya que no se consideran las etapas de anlisis, documentacin del proyecto, ejecucin de pruebas etc.). Otro de los aspectos que se deben considerar es que el esfuerzo necesario para generar cada lnea de cdigo, puede variar en forma sorprendente de una tecnologa a otra.
Ing. Hernn A. Turin
94
Todo lo antes dicho, lleva a considerar que es mas conveniente utilizar una mtrica que considere los requerimientos del usuario (funcionalidades) y que sea independiente de la tecnologa en que se realizar dicho desarrollo. La mtrica de puntos de funcin puede ser definida como una mtrica funcional, debido a que se enfoca en las prestaciones que el producto software debe proporcionarle al usuario. La medicin de la funcionalidad de un producto software ha sido estandarizada por la Organizacin Internacional para la Estandarizacin (ISO) en la norma ISO/IEC 14143, la cual define cuales son los conceptos de una mtrica basada en la funcionalidad y qu caractersticas debe cumplir un mtodo para ser homologado al estndar y ser considerado como una medida del tamao de la funcionalidad. Los mtodos ms conocidos que estn homologados por ISO 14143 [ISO/IEC, 2007] son: IFPUG 4.1: El Unajusted Functional Size Measurement Method [ISO/IEC, 2003] fue desarrollado en IBM y es el ms conocido y utilizado en Estados Unidos, al punto de que se est convirtiendo en el mtodo por defecto en toda la industria. NESMA: Es un estndar definido por la Netherlands Software Metrics Users Association [NESMA, 2001] y que representa una pequea variante respecto del mtodo IFPUG. Mk II: Fue desarrollado por la United Kingdom Software Metrics Association [UKSMA, 1998] y es un mtodo simplificado y adaptado para las ideas de anlisis y diseo estructurado. COSMIC FFP: Es un mtodo desarrollado para ser utilizado con mayor precisin en la medicin de sistemas de tiempo real y fue definido por el Common Software Measurement International Consortium [Abran, 2001].
El mtodo que se analizar en el presente trabajo ser el IFPUG ya que es el ms utilizado en la industria del software. El mtodo IFPUG utiliza como unidad de medida los puntos de funcin. Se basa principalmente en la identificacin de cuales son los componentes del sistema (transacciones y grupos de datos lgicos) que son relevantes para el usuario. A cada uno de los componentes identificados se les asigna una cantidad de puntos de funcin de acuerdo al componente y su complejidad. De acuerdo a esto, la
Ing. Hernn A. Turin
95
suma de los puntos de funcin de todos los componentes del producto software dar los puntos de funcin del sistema sin ajustar. El ajuste es un proceso donde se modifica el valor de acuerdo a ciertas caractersticas generales del producto a construir. El procedimiento del IFPUG [ISO/IEC, 2003] es el siguiente: 1- Determinar el tipo de conteo En este paso se determinar el tipo de medicin de tipos de funcin. Las mediciones pueden estar asociadas tanto a proyectos como a aplicaciones. Existen tres tipos de mediciones de puntos de funcin: Puntos de funcin de un proyecto de desarrollo. Puntos de funcin de un proyecto de mejora. Puntos de funcin de una aplicacin.
2- Identificar los alcances de la medicin y los lmites de la aplicacin En este paso se define que funcionalidades sern incluidas en la medicin de puntos de funcin a realizar (alcance) y cuales son los lmites entre el software a medir y el usuario (lmites de la aplicacin). 3- Determinar los puntos de funcin no ajustados Los puntos de funcin no ajustados reflejan la funcionalidad cuantificable proporcionada al usuario por parte del proyecto o aplicacin. La funcionalidad se evala en funcin de qu es lo que se entrega al usuario y solo se cuentan los componentes solicitados y definidos por el usuario. La medida de puntos de funcin no ajustados tiene dos tipos de funcin: de datos y transaccional. a- Medicin de las funciones de datos En este paso se identifican y cuentan las funciones que proporcionan al usuario la capacidad de satisfacer los requisitos de almacenamiento de datos tanto interno como externo. Las funciones de datos son archivos lgicos internos o archivos de interfaz externos. Un archivo lgico interno (ILF) es un grupo de datos lgicamente relacionados, identificados por el usuario y que son mantenidos dentro de los lmites de la aplicacin. Esto significa que los ILF almacenan datos que son mantenidos a travs de alguna transaccin que est considerada dentro del conteo de la aplicacin.
Ing. Hernn A. Turin
96
Por su parte, los archivos de interfaz externos (EIF) son aquellos grupos de datos relacionados lgicamente, identificables por el usuario y que son referenciados por la aplicacin pero que son mantenidos dentro de los lmites de otra aplicacin. Esto significa que los EIF son mantenidos a travs de una transaccin que no est incluida dentro del conteo. El objetivo principal de los EIF es almacenar datos que son referenciados por uno o ms procesos que se encuentran fuera de los lmites de la aplicacin que se est midiendo. Esto significa que un EIF de una aplicacin es un ILF de otra. b- Medicin de las funciones transaccionales En esta etapa se identifica y cuenta la capacidad de realizar operaciones por parte de la aplicacin. Existen tres tipos de funciones transaccionales: Entrada Externa, Salida Externa, Consulta Externa. Una entrada externa (EI) es un proceso cuyo propsito principal es el de mantener uno o mas ILFs. Mientras que una salida externa (EO) es un proceso que tiene como objetivo presentar informacin al usuario mediante un proceso lgico diferente de la sola recuperacin de datos. Finalmente la consulta externa (EQ) es un proceso por el cual se presenta la informacin leda de uno o ms grupos de datos al usuario.
A cada uno de los cinco componentes definidos anteriormente, se les debe asignar una complejidad, la cual puede ser Baja, Media o Alta. Dicha complejidad se asigna de acuerdo al nmero de datos utilizados en el proceso y la cantidad de archivos referenciados. De acuerdo a la complejidad asignada, se deber utilizar la Tabla XIII para poder calcular el total de puntos de funcin no ajustados. EI EO EQ ILF EIF Bajo __ x 3 __ x 4 __ x 3 __ x 7 __ x 5 Medio __ x 4 __ x 5 __ x 4 __ x 10 __ x 7 Total Alto __ x 6 __ x 7 __ x 6 __ x 15 __ x 10 Total
Tabla XIII Tabla de para el clculo de puntos de funcin no ajustados
Ing. Hernn A. Turin
97
4- Determinar el valor de ajuste En esta etapa lo primero que se debe hacer para obtener el valor del ajuste es analizar los 14 atributos que impactan en el desarrollo y que deben ser evaluados en forma independiente. A cada uno de dichos atributos se les deber asignar un valor entre 0 y 5 dependiendo del grado de influencia de dicho atributo. Los posibles valores son: 0- Sin Influencia: El sistema no contempla este atributo. 1- Influencia mnima: La influencia es muy poco significativa. 2- Influencia moderada: Si bien el sistema contempla este atributo y su influencia es pequea, debe ser considerada. 3- Influencia apreciable: El atributo no es fundamental pero su influencia debe ser tenida en cuenta. 4- Influencia significativa: El atributo tiene una gran importancia en e sistema. 5- Influencia muy fuerte: El atributo es fundamental para el sistema y su influencia debe ser tenida en cuenta en el diseo. Los atributos son: 1. Comunicacin de datos. 2. Funciones distribuidas. 3. Prestaciones. 4. Gran uso de la configuracin. 5. Velocidad de las transacciones. 6. Ingreso de datos en lnea. 7. Diseo para eficiencia del usuario final. 8. Actualizacin de datos en lnea. 9. Procesos complejos. 10. Reusabilidad del cdigo por otras aplicaciones. 11. Facilidad de instalacin. 12. Facilidad de operacin. 13. Instalacin en mltiple sitios. 14. Facilidad de cambios. Para obtener el factor de ajuste (AF) se debe sumar 0,65 a la sumatoria de los grados de influencia de las 14 caractersticas generales del sistema (TDI, Total Degree of Influence), multiplicado por 0,01, es decir:
Ing. Hernn A. Turin
98
AF = (TDI 0.01) 5- Determinar los puntos de funcin ajustados En este paso simplemente se debe multiplicar los puntos de funcin no ajustados por el factor de ajuste.
La mtrica de puntos de funcin est orientada a medir sistemas informticos completos y no programas. En este sentido se convierte en una herramienta muy importante para la administracin de un proyecto porque permite abarcar un panorama ms amplio que la sola aplicacin. Esto lo convierte en una tcnica til para estimar el esfuerzo necesario para llevar a cabo un proyecto, especialmente cuando se cuenta con una base de conocimiento dentro de la organizacin, sobre la cual se puedan basar los clculos. La existencia de una base de conocimiento es muy importante ya que de la experiencia en otros proyectos es que se podr determinar la cantidad de horas necesarias por cada punto de funcin y, de acuerdo a esto, la cantidad y distribucin de los recursos (entre ellos personas) a lo largo del proyecto.
4.2.12- TCNICA DE GRUPO NOMINAL

La tcnica de grupo nominal [Kelly, 1999] es una tcnica til al momento de realizar la planificacin de los recursos humanos necesarios para llevar adelante un proyecto. Esta tcnica consiste en presentar a un grupo de gerentes un tema bsico, por ejemplo: Cul ser el personal necesario para llevar adelante el nuevo proyecto que se est analizando? Cada uno de los participantes procede a poner por escrito las
respuestas que estime pertinentes. Despus de 10 minutos se discuten las ideas del grupo se clasifican y se permite que cada integrante las numere en orden de importancia, seleccionando las tres o cuatro mas importantes. La tcnica de grupo nominal es muy til cuando se trate de una cuestin delicada, polmica o importante y que generar opiniones encontradas en la cul se quiera asegurar la participacin equitativa de todos los miembros del equipo. Tambin es til cuando la seleccin de una alternativa entre varias, se hace sumamente difcil. sta es una tcnica de las que se denominan como basadas en experiencia. Esto se debe a que, para poder realizar una estimacin como la que se indica
Ing. Hernn A. Turin
99
anteriormente, es necesario que los participantes cuenten con cierta experiencia. Es conveniente que estos conocimientos previos sean de proyectos con caractersticas similares al proyecto que se est planificando. En este caso los que deberan participar del proceso son el sponsor del proyecto, el lder, y todas aquellas personas que cumplan algn rol gerencial dentro del proyecto.
4.3.13- TCNICA DELPHI Delphi [Kelly, 1999] es una tcnica de sondeo de opiniones. En esta dinmica se solicitan estimados especficos de un grupo de expertos, por lo general a nivel gerencial. Los en cargados de realizar la planificacin de los recursos humanos necesarios para el proyecto actan como intermediarios, resumen las respuestas obtenidas e informan a los expertos de los resultados. El proceso se repite hasta que el grupo empieza a concordar en determinados factores. Generalmente cuatro o cinco fases sucesivas son suficientes para llegar a resultados concretos. Las ocho etapas de esta tcnica son [Kelly, 1999]: 1- Definir la decisin a tomar. 2- Recibir los comentarios del equipo para la primera ronda. 3- Resumir los comentarios de la primera ronda y solicitar los comentarios de la segunda ronda. 4- Recibir los comentarios de la segunda ronda. 5- Resumir los comentarios de la segunda ronda y solicitar los comentarios de la tercera ronda. 6- Recibir los comentarios de la tercera ronda. 7- Resumir los comentarios de la tercera ronda. 8- Dar por concluida la sesin.
La tcnica delphi se diferencia del grupo nominal en que ste requiere que todos los miembros estn presentes fsicamente en un mismo ambiente, mientras que en este caso no se requiere esa presencia fsica. Entre todos los miembros de la tcnica delphi se da la bsqueda de un comportamiento proactivo. La interaccin entre miembros siempre va a ser controlada a travs de las respuestas de los miembros segn estadsticas. sta buscar el grado de consenso mximo entre opciones; cuando haya discrepancia o consenso se pedir el
Ing. Hernn A. Turin
100
razonamiento. La tcnica delphi se aplica para multitud de actividades empresariales para realzar pronsticos, evaluar caractersticas de productos, sistemas, tecnologas; resolver e identificar problemas; establecer metas y prioridades; para aclarar posiciones, identificar diferencias, optar por determinados grupos de referencia, etc. La tcnica delphi es til cuando se desea conocer las opiniones de varios miembros del equipo evitando, a la vez, el efecto negativo del contacto cara a cara. Es recomendable especialmente cuando los miembros del equipo no se encuentran en el mismo lugar fsico y se requiera lograr una decisin por consenso.
4.3.14- ANLISIS ESTADSTICO El anlisis estadstico es una tcnica de mayor complejidad en la cual se utilizan modelos computarizados, los cuales permiten predecir la necesidad de personal para un proyecto u organizacin. Estos modelos incluyen factores tales como las variantes en la demanda externa de producto. Los procedimientos estadsticos utilizan datos histricos para proyectar la demanda futura. El Procesamiento de los modelos puede ofrecer una representacin simplificada de la demanda de los recursos humanos de toda la organizacin o de un proyecto en particular. Alterando los datos de entrada pueden contrastarse las necesidades recursos humanos en diferentes escenarios de demanda. Entre las tcnicas estadsticas de modelizar utilizadas para la previsin de las necesidades de recursos humanos se encuentran las siguientes [Caldera Meja, 2004]: Anlisis de series temporales: Se utilizan niveles histricos de personal para proyectar las necesidades futuras de recursos humanos. Se estudian los niveles histricos de personal para aislar las variaciones estacinales y cclicas, las tendencias a largo plazo y los movimientos aleatorios. Luego se extrapolan las tendencias a largo plazo utilizando una media mvil, un suavizado exponencial o la tcnica de regresin. Ratios de personal: Se examinan los datos obtenidos del rea encargada del manejo del personal para determinar las relaciones histricas entre el nmero de empleados en diversos puestos o categoras de puestos. A continuacin se utiliza el anlisis de regresin o ratios de productividad para proyectar las necesidades totales o de grupos claves de recursos humanos y se utilizan
Ing. Hernn A. Turin
101
dichos ratios para asignar necesidades totales a diversas categoras de puestos o para estimar necesidades de grupos no claves. Ratios de productividad: Se utilizan datos histricos para examinar los niveles histricos de un ndice de productividad. La frmula que se utiliza es:
P= c arg a _ de _ trabajo Numero _ de _ personas
Si se encuentran relaciones constantes o sistemticas, pueden calcularse las necesidades de recursos humanos dividiendo las cargas previstas de trabajo por P. Anlisis de regresin: Se estudian los niveles histricos de varios indicadores de carga de trabajo, como ventas, niveles de produccin y valor agregado, para encontrar relaciones estadsticas con los niveles de personal. Cuando se encuentran relaciones suficientemente fuertes, se obtiene un modelo de regresin (o de regresin mltiple). Los niveles previstos de los indicadores mantenidos se pasan al modelo resultante y se utilizan para calcular el nivel asociado de las necesidades de recursos humanos. Los modelos de regresin presentan la ventaja de que son muy sensibles a los cambios en la orientacin de la organizacin, lo cual permite identificar la necesidad de reasignar personal o de modificar los niveles de dotacin. Los modelos de regresin dan buenos resultados cuando se utilizan con empresas que operan en un entorno estable.
Ing. Hernn A. Turin
102
MODELO DE
CAPITULO
ADMINISTRACION DE PERSONAS PROPUESTO
5.1-
INTRODUCCIN
En el presente captulo se expone como solucin al problema planteado, un
Modelo de Gestin de Personas aplicable a los diferentes tipos de proyectos de TI. Lo que se propone es la aplicacin de diferentes tcnicas de gestin de personas dentro de una estructura de administracin de Proyectos. Las tcnicas que se implementarn son todas aquellas relacionadas con motivacin de equipos de trabajo, gestin de las relaciones interpersonales dentro de un equipo, relacin con los clientes y manejo de la asignacin y distribucin de los recursos. La idea es poder aprovechar al mximo las ventajas y beneficios de cada una de estas tcnicas, adaptndolas a cada momento del proyecto cuando se lo requiera. Por otro lado, se plantea la utilizacin de un modelo de administracin de proyectos reconocido y ampliamente utilizado en el mbito de la gestin de proyectos, tal como lo es el PMBOK. Este modelo plantea un conjunto de conocimientos que permiten dirigir un proyecto, y que est basado en la experiencia obtenida en diferentes casos y empresas. La idea es combinar por un lado un estndar reconocido de administracin de proyectos, que funcione como estructura para comprender las etapas o fases del proyecto, y por el otro proponer el uso de las diferentes tcnicas de acuerdo al momento del proyecto en que se encuentre. Finalmente se indicar como se debe implementar cada tcnica en cada grupo de proceso definido en la estructura del proyecto, y las consideraciones particulares que se debern realizar para poder llevarlo a cabo.
5.2-
ESQUEMA SELECCIONADO
Para poder abordar y llevar adelante el planteo propuesto en el captulo anterior,
es necesario primero definir cul ser el esquema / estndar de administracin de proyectos que se utilizar como gua para identificar las actividades relacionadas con la administracin del factor humano. En este sentido, se considera que la metodologa ms completa de las conocidas y utilizadas actualmente, es aquella propuesta por el Project Management Institute (PMI): El PMBOK (Project Management Body of Knowledge). El PMBOK, como ya se analiz anteriormente, provee un estndar para la direccin de proyectos que est estructurado en cinco grupos de procesos bsicos y
Ing. Hernn A. Turin
105
nueve reas de conocimientos que son comunes prcticamente a todos los proyectos. La eleccin de este estndar se basa en que representa un conjunto muy actual y sumamente amplio de conocimientos que resultan de la experiencia, el estudio y el desarrollo de proyectos. Lo interesante de este esquema es que su finalidad no es exponer disciplinas, herramientas y tcnicas aplicables a la gestin de proyectos sino proveer un grupo seleccionado de ellas y que son consideradas como buenas prcticas. Esto permite que se puedan encuadrar en su esquema todas aquellas tcnicas y herramientas relacionadas con la administracin del factor humano que influyen en la administracin de un proyecto. Por otra parte, el grupo de conocimientos del PMBOK se encuentra distribuido entre los miles de colaboradores alrededor del mundo y es por esta razn que no se lo presenta como un manual con pasos a seguir para culminar un proyecto en forma exitosa. Los cinco procesos en los que se estructura el PMBOK son: 1. Inicio 2. Planificacin 3. Ejecucin 4. Seguimiento y Control 5. Cierre Y las nueve reas de conocimiento son: 1. Gestin de la Integracin 2. Gestin del Alcance 3. Gestin del Tiempo 4. Gestin de la Calidad 5. Gestin de Costos 6. Gestin de Riesgos 7. Gestin de Recursos Humanos 8. Gestin de la Comunicacin 9. Gestin del Aprovisionamiento Para el planteo de la solucin propuesta al problema abordado en el presente trabajo, se tomar como base esta estructura y dentro de ella es que se organizarn las tcnicas y herramientas propuestas como mejores prcticas.
Ing. Hernn A. Turin
106
5.3-
MODELO DE GESTIN PROPUESTO

La solucin al problema presentado se estructurar de modo que, se analizarn
en detalle las necesidades de cada uno de los grupos de procesos del PMBOK desde el punto de vista de la administracin del factor humano. Luego se especificar el modelo final que combina las prcticas genricas y especficas analizadas en el captulo anterior con cada grupo de procesos. En la Figura 6 se puede visualizar el esquema planteado para el desarrollo de la solucin.
Prcticas Genricas Reuniones Wikis Foros de discusin Listas de Correo Mensajera instantnea
Prcticas Especficas Comits de Desarrollo Programacin de a Pares Comits de Usuario Grupos de Apoyo Mesa de Ayuda Estructura Desglosada de Trabajo C.P.M. P.E.R.T. Diagramas de Gantt COCOMO Puntos de Funcin Grupo Nominal Delphi Anlisis Estadstico
Grupo de Procesos Inicio Planificacin Ejecucin Control y Monitoreo Cierre
Modelo de Mejores Prcticas

Figura 18 Representacin grfica del esquema de la solucin planteada.
Ing. Hernn A. Turin
107
5.4- APLICACIN DE PRCTICAS A LAS DIFERENTES FASES DE UN PROYECTO

En esta seccin se presentar cmo se relaciona cada una de las prcticas definidas en las dos secciones anteriores con las diferentes fases de un proyecto de TI. En la Tabla XIV se muestra un esquema que sintetiza cual es la aplicabilidad de cada tcnica segn la fase del proyecto en que se encuentre. Iniciacin Planificacin
Reuniones Wikis Foros de discusin Listas de Correo Mensajera Instantnea Comits de Desarrollo Programacin de a Pares Comits de Usuarios Grupos de Apoyo Mesa de Ayuda Estructura Desglosada de Trabajo Diagramas de Gantt CPM PERT COCOMO Puntos de Funcin Grupo Nominal Delphi Anlisis Estadstico X X X X X X X X X X X X X
Ejecucin
X X X X X X X X
Seguimiento y Control
X X X X X
Cierre
X X X X X
X X X X
X X X X X X X X
X X X X X
Tabla XIV Esquema de prcticas por fases del proyecto
Ing. Hernn A. Turin
108
En general se ve claramente que las prcticas que se definieron como genricas son aplicables a casi todas las fases de un proyecto, mientras que las especficas solo se aplican a uno o dos grupos de procesos. Siempre se debe tener en cuenta que el conjunto de prcticas propuestas solo conforma una gua. Es decir que no necesariamente se deben aplicar todas sino que se seleccionarn solo aquellas que se adapten a las necesidades del proyecto. A continuacin se detallarn, para cada uno de los grupos de procesos de un proyecto, cul es su objetivo, necesidades y las tcnicas aplicables de acuerdo a lo definido en la Tabla XIV. Adems se analizarn las particularidades de la aplicacin de cada tcnica de acuerdo a los requerimientos de la fase analizada.
5.4.1- INICIACIN 1- Objetivo: El objetivo de este grupo es definir claramente que es lo que se har y lo que se espera del proyecto. En este grupo de procesos se debe establecer tambin la viabilidad del proyecto o de la fase correspondiente y se plantean las alternativas de solucin. En el grupo de procesos de iniciacin, tambin se describe el mecanismo de seleccin de alternativas de solucin y se detallan los motivos que llevaron a la seleccin de una determinada opcin. Adems es en la iniciacin donde se verifica que los objetivos del proyecto se encuentren alineados con el plan estratgico de la organizacin.
2- Necesidades: En este grupo de procesos se debe poner espacial atencin a como se manejar la relacin con las personas involucradas y, especialmente, como se las interioriza y se les transmite la importancia y relevancia del proyecto como as tambin el alcance y limitaciones del mismo. Para poder conseguir esto es que se debe tender siempre a lograr un alto nivel de participacin y compromiso de los interesados, de modo que se sientan parte integrante del proyecto. En la iniciacin, el rol del sponsor y de los satkeholders es fundamental, ya que son quienes avalarn e impulsarn el proyecto siempre y cuando lo que se plantee en dichos documentos sea acorde a lo que ellos esperan. Adems en este grupo de procesos es necesario tener una primera aproximacin de los tiempos necesarios para llevar adelante el proyecto y de los costos asociados al mismo.
Ing. Hernn A. Turin
109
En este grupo de procesos, la mayora de los encuentros con el cliente y las actividades a realizar se suelen organizar bajo la forma de reuniones. Es por este motivo que es de vital importancia tener muy en claro las pautas a considerar al momento de organizar una reunin.
3- Tcnicas a utilizar: De acuerdo al objetivo del grupo de procesos y de las necesidades detectadas en el mismo respecto de la administracin del factor humano, en la Tabla XIV se indican como aplicables las Reuniones, Foros de Discusin, Listas de Correo, Mensajera Instantnea, Puntos de Funcin y Diagramas de Gantt.
Reuniones En el caso de las reuniones que se llevan a cabo durante la iniciacin, se deben tener en cuenta algunos aspectos que tienen mayor importancia respecto de los ya mencionados anteriormente. En este caso particular es importante que se tomen en cuenta y se le preste mucha atencin a todas las opiniones y sugerencias de cada uno de los participantes, se analicen y finalmente se determinen si influirn o no en el objetivo y alcance del proyecto. Otro aspecto en el que se debe poner atencin, en la preparacin y posterior ejecucin de la reunin, es el lugar fsico donde se realizar el encuentro y la disposicin de cada uno de los participantes. En cuanto al lugar de encuentro, es conveniente que cuente con buena iluminacin, silencio y que no existan interrupciones por parte de terceros. Es conveniente que se cuente con material de apoyo necesario para poder expresar los conceptos. En este sentido es importante contar con pizarrn, marcadores, proyectos y PC, ya que de esta forma se puede desplegar una amplia gama de tcnicas para transmitir los conceptos y lograr que los mismos queden claros. En lo que refiere a la disposicin de los participantes, en las reuniones de iniciacin de proyecto el nmero de integrantes suele ser reducido, no ms de 4 o 5 personas, por lo cual es conveniente que se realicen en una mesa redonda, donde todos puedan verse y donde no haya mucha distancia entre las personas, de modo que todos puedan escucharse mutuamente.
Ing. Hernn A. Turin
110
Otro de los aspectos que no se debe descuidar es el armado del proceso de facilitacin. Nunca se debe olvidar que la mayora de las reuniones no fracasa por un mal armado de la agenda sino por la ausencia o pobreza en el proceso de facilitacin de la misma. La reunin debe comenzar con una breve presentacin de cada uno de los participantes (en caso de ser necesario) y luego una introduccin que estar a cargo de quien es el facilitador de la reunin. En dicha presentacin se explicar el tema que se tratar en el encuentro y para dicha explicacin, el facilitador se puede valer de transparencias, grficos, cuadros, videos o cualquier otro elemento que se considere til para facilitar la comprensin del tema. Es importante que en los das previos a la reunin, se haya entregado a los participantes el orden del da con los temas a tratar. Cada vez que sea necesario comenzar con la discusin de un nuevo tema, se debe tener en cuenta las tcnicas presentadas anteriormente para iniciar un debate. Es conveniente adems, que haya un encargado de documentar todo lo que se discute en la reunin, de modo que queden plasmadas las diferentes opiniones expuestas, lo que luego ser de gran utilidad para poder elaborar las conclusiones de la reunin. Respecto de las conclusiones, se deben tener siempre presentes las tcnicas para cerrar debates. Una vez finalizada la reunin, se debe confeccionar una memoria con las conclusiones y acuerdos alcanzados durante la misma, y repartir dichos documentos entre todos los participantes a modo de recordatorio de los acuerdos realizados y los pendientes (si es que existieran). Las actividades del facilitador se reducen a tres acciones principales (adems de dirigir el proceso): 1. Preguntar: El facilitador debe estar muy atento al desarrollo de la reunin e interrumpir para preguntar o repreguntar todo lo que crea necesario, ya sea para aclarar algn tema o para fomentar la participacin de todos los asistentes. Estas preguntas deben ser breves y claras para no desviar el foco de la discusin. 2. Recopilar: Se debe ir recopilando las diferentes ideas expresadas durante el desarrollo del encuentro, de modo que se vayan ordenando la produccin de las mismas.
Ing. Hernn A. Turin
111
3. Resumir: Se deben sintetizar las diferentes ideas expresadas durante el desarrollo del debate para luego presentarlas como posibles alternativas de accin y facilitar la toma de decisiones del grupo Estas tres actividades deben realizarse con la mayor naturalidad posible y evitando que esto afecte el desarrollo de la reunin. Siempre se debe tener en cuenta que la duracin de una reunin es un factor que influye en los resultados de la misma. En el caso de las reuniones que se realizan durante los procesos de iniciacin, hay que tener en cuenta que los principales implicados son miembros de la alta gerencia de la organizacin, por lo cual se debe evitar quitarles demasiado tiempo ya sea por una reunin extensa o por una cantidad excesiva de reuniones. Antes de convocar hay que analizar si realmente el tema justifica la realizacin de la misma o si es algo que, o bien se puede solucionar por otros medios o bien se puede aplazar para tratarlo en otro encuentro junto con otros temas. Hay que tener muy presente que una buena comunicacin es fundamental para lograr una reunin de trabajo exitosa, y es por ello que hay algunos puntos que son importantes para mejorar la comunicacin, dentro de ellos los ms importantes son: Las palabras tienen diferentes significados para las personas, por lo cual es necesario asegurarse que al momento de utilizar un trmino todos entiendan a que se est haciendo referencia. La comunicacin no solo es verbal, sino que adems tiene un componente no verbal que muchas veces indican ms que las propias palabras.
Foros de Discusin En el caso de los foros utilizados durante el grupo de procesos de iniciacin tiene particular importancia en el hecho de hacer ms dinmicas las comunicaciones entre las partes interesadas. De acuerdo al funcionamiento te esta herramienta, se puede crear un foro en la cual los involucrados en el grupo de procesos puedan realizar sus consultas y evacuar todas las dudas sin necesidad de realizar una reunin para ello. Adems, como las consultas son pblicas pueden ser vistas por todos los participantes se
cuenta con la facilidad de que cada uno puede dejar su comentario/sugerencia respecto de un tpico en particular.
Ing. Hernn A. Turin
112
Otra de las ventajas que tienen los foros es que son relativamente fciles de utilizar y no se requieren grandes conocimientos de informtica para ello, con lo cual, si alguno de los involucrados posee escasos conocimientos de informtica, podr utilizarlos sin mayores inconvenientes. Esta herramienta es til cuando los involucrados en la iniciacin del proyecto no se encuentran en ubicaciones geogrficas muy distantes, donde la organizacin de una reunin requiere de un tiempo considerable e implica la necesidad de que los asistentes tengan que recorrer distancias considerables para participar de la misma.
Listas de Correo Las Listas de correo son sumamente tiles en este grupo de procesos. Esta importancia radica, adems de en la agilizacin de las comunicaciones, en la efectividad para que los mensajes lleguen a los destinatarios. A diferencias de los foros de discusin, las listas de correos hacen que los mensajes que se envan a las mismas lleguen directamente a la casilla de correo electrnico de cada uno de los integrantes de dicha lista. De esta manera se elimina la necesidad de que cada persona deba ingresar especficamente al foro para verificar si existen mensajes nuevos. La ventaja principal es que en la actualidad el correo electrnico es una herramienta de uso corporativo generalizado en todas las organizaciones y en todos los niveles, por lo cual no hay prcticamente inconvenientes para su implementacin y no suelen requerir ninguna capacitacin previa a la implementacin. Dado que la mayora de los miembros de una organizacin chequean sus casillas de correo electrnico varias veces en el da, los mensajes llegan con mayor celeridad que en los foros. La recomendacin es que, independientemente del uso de otras herramientas para la comunicacin, es conveniente que siempre se utilice la lista de correo ya que es una herramienta muy sencilla y fcil de implementar. Aplicadas al grupo de procesos de iniciacin, las ventajas de las listas de correos son prcticamente las mismas que los foros de discusin, es decir: agilizar la circulacin de informacin, realizar discusiones sobre ciertos tpicos sin necesidad de una reunin y evacuar las dudas que se generen. Adems tambin son muy tiles en caso de que haya involucrados en ubicaciones geogrficas muy distantes.
Ing. Hernn A. Turin
113
Mensajera Instantnea Esta es una de las herramientas ms nuevas dentro de las que se mencionan para ser utilizadas en este grupo de procesos. La mensajera instantnea, como ya se analiz anteriormente, cuenta con la ventaja de ser una herramienta en lnea. Esto significa que cuando dos personas se comunican a travs de esta herramienta, la comunicacin se realiza en tiempo real. Si se analizan las ventajas de la implementacin de la mensajera instantnea, se puede llegar fcilmente a la conclusin de que en cuanto al dinamismo de la circulacin de informacin es la ms conveniente. Sin embargo cuenta con una caracterstica que pede tornarse en desventaja: requiere la presencia instantnea de las partes para que la comunicacin sea llevada a cabo. Esto es necesario ya que si una de las personas abandona la herramienta, no hay forma deque el otro reciba la informacin. Este inconveniente no se presenta en las listas de correo ni en los foros, ya que la informacin se encuentra disponible en ellos el 100 % del tiempo, de modo que puede ser consultada en todo momento por los involucrados. En el caso particular de la iniciacin de un proyecto, la mensajera instantnea resulta sumamente til cuando se deben resolver temas urgentes y no hay tiempo de organizar una reunin, de modo que se puede iniciar una conferencia de voz donde todos puedan participar de la discusin y resolver el tema con mayor celeridad. Pero por otro lado requiere de algunos conocimientos ms de informtica por parte de los involucrados. Aunque en la actualidad esta herramienta ha adquirido mucha popularidad llegando a ser en muchos casos de uso corporativo. De todos modos lo recomendable es que el uso de esta herramienta en el grupo de procesos de iniciacin vaya siempre acompaada del uso de al menos o una lista de correo o un foro de discusin.
Puntos de Funcin El uso de esta tcnica durante la iniciacin de un proyecto est orientado especficamente a la obtencin de una primera aproximacin del tiempo necesario para llevar a cabo el proyecto y del costo aproximado del mismo. Como se analiz con anterioridad, esta tcnica permite, con algunos datos relacionados al proyecto, obtener una estimacin del tamao del proyecto y, por consiguiente, del tiempo necesario para ejecutarlo y de su costo.
Ing. Hernn A. Turin
114
Si bien en el grupo de procesos de iniciacin no se cuenta con demasiados detalles acerca del proyecto, se puede obtener la informacin mnima a indispensable para realizar un primer clculo de su tamao (utilizando puntos de funcin) y de esta manera obtener un valor (en puntos de funcin) que permita armar un presupuesto y determinar aproximadamente la duracin del mismo. Siempre se debe tener en cuenta que los resultados que se obtengan carecern de precisin debido al momento temprano del proyecto en que se aplica, peor al menos permiten tener una gua para poder comenzar la discusin con las partes interesadas en el proyecto.
Diagramas de Gantt El uso de los diagramas de Gantt durante el grupo de procesos de iniciacin tiene como objetivo el permitir tener una visin aproximada de los tiempos que se insumirn en las tareas que forman parte de un proyecto. Dado que para su armado no se requiere demasiado nivel de detalle, el diagrama de Gantt es una herramienta sumamente til en este grupo. La idea es fundamentalmente tener una aproximacin de la distribucin de tareas y dar una primera impresin de cul ser la duracin total de un proyecto. Adems, usada en combinacin con la tcnica de Puntos de Funcin permite tener un panorama mas claro sobre todo el proyecto, an en un momento muy temprano del mismo como lo es la iniciacin. Desde el punto de vista de la administracin de personas, la principal utilidad est dada por el hecho de que se puede visualizar como debern estar aproximadamente distribuidas las personas. Esto es viable por el hecho de que este diagrama muestra las dependencias entre tareas y, por lo tanto, se puede estimar sin demasiado detalle donde deber ponerse mayos esfuerzo humano.
5.4.2- PLANIFICACIN 1. Objetivo: El objetivo de este grupo es definir cules son las actividades que se realizarn dentro del proyecto, la dependencia de las mismas, su duracin como as tambin los riesgos asociados al proyecto. En este grupo de procesos,
Ing. Hernn A. Turin
115
tambin se identifican cuales son las restricciones del proyecto y se definen cuales son los entregables de cada una de las actividades. 2. Necesidades: En este grupo de procesos una de las necesidades mas importantes es la de poder estimar aspectos del proyecto tales como el tamao del mismo y del producto a desarrollar, la duracin total del proyecto y la duracin de cada una de las etapas. Estas estimaciones resultan fundamentales para poder planificar correctamente cmo ser la distribucin del equipo a lo largo del proyecto, cmo se asignarn las responsabilidades y qu tareas se asignarn a cada integrante del equipo. Durante este grupo de procesos se realiza la distribucin de los recursos en las diferentes etapas y actividades, y tambin se necesita tener una visin ms aproximada de cual ser el costo del mismo. Esto significa que, durante la planificacin de un proyecto se necesitan tcnicas que permitan obtener una estimacin lo mas certera posible sobre cada una de las variables que inciden sobre el mismo. Es por ello que es uno de los grupos de procesos donde se pueden aplicar la mayor variedad de tcnicas. Desde el punto de vista de la administracin del factor humano, lograr una correcta planificacin de un proyecto, es fundamental para que luego, durante el resto del mismo, las personas puedan manejarse con tranquilidad y con comodidad, evitando sobrecarga de trabajo o realizacin de horas extras. 3. Tcnicas a utilizar: Si se analiza el objetivo del grupo de procesos de planificacin y las necesidades planteadas en el mismo, se determina que las tcnicas aplicables en la administracin del factor humano son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, COCOMO, Puntos de Funcin, Estructura Desglosada de Trabajo, Diagramas de Gantt, CPM, PERT, Tcnica de Grupo Nominal, Tcnica Delphi y Anlisis Estadstico.
Reuniones En el momento de realizar la planificacin de un proyecto, las reuniones son una tcnica que tiene especial utilidad en la recopilacin de informacin de diferentes fuentes. Esta informacin es importante para poder hacer una planificacin confiable y exacta. En este caso son aplicables la mayora de los tems mencionados para las reuniones que se llevan adelante durante la iniciacin,
Ing. Hernn A. Turin
116
especialmente aquellos relacionados con la administracin de los espacios fsicos y la disposicin de los participantes. La diferencia radica en que, en este caso, los asistentes pertenecen a reas operativas de la organizacin, es decir, que son los futuros usuarios del producto final. El hecho de que quienes asistan a las reuniones sean los futuros usuarios del producto o los responsables de las reas impactadas por el mismo puede explicarse por la necesidad de obtener informacin exacta y relevante. Esta informacin es necesaria para conocer los aspectos especficos relacionados tanto con los procesos como los procedimientos que sern afectados por el proyecto. De aqu es que se
hace necesaria la asistencia de personas con conocimientos de dichos procesos y procedimientos. Este tipo de reuniones se denominan Reuniones de Relevamiento. Las reuniones de relevamiento son encuentros focalizados en el objetivo principal de obtener informacin acerca de ciertos temas en particular. En el caso de los proyectos de TI, estas reuniones tienen dos objetivos: comprender las necesidades de informacin de las reas involucradas y comprender los procesos / procedimientos afectados por el proyecto. En este tipo de reuniones, el facilitador debe tener en claro cuales son los procesos, procedimientos y reas afectadas, de modo que se pueda dirigir el encuentro y guiarlo hacia el cumplimiento de las metas de recopilacin de informacin. En cuanto a la cantidad y el tipo de asistente de las reuniones de relevamiento, se puede decir que variarn de acuerdo con el proceso/procedimiento y las reas. En el caso de procesos/procedimientos que involucran a ms de un rea, es conveniente que asistan entre uno y dos representantes de cada rea. La idea es poder comprender todo el circuito, detectar las necesidades de informacin de cada afectado e incluso determinar los casos en que desde lugares diferentes se requiere la misma informacin. Adems en estas reuniones se pueden determinar los circuitos administrativos y detectar las mejoras que pueden realizarse en los mismos (se debe tener presente que los proyectos de TI no solo involucran tecnologa y software sino tambin procedimientos administrativos realizados por personas). Si bien anteriormente no se menciona, tambin pueden asistir a estas reuniones otras reas que, sin ser afectadas por el proyecto, tienen inters en el mismo o en el tema a analizar en la misma. Adems puede que en alguno de estos
Ing. Hernn A. Turin
117
encuentros se involucre al sponsor o a los stakeholders con el objetivo de conocer sus necesidades de informacin asociadas al proceso/procedimiento analizado. Finalmente se puede concluir diciendo que para las reuniones de relevamiento es necesario: Identificar el/los procesos/procedimientos a relevar. Identificar las reas afectadas por los mismos. Identificar las reas que requieren informacin de los mismos. Identificar los actores claves de cada rea. Focalizar el encuentro en lograr la obtencin de informacin con el mayor grado de exactitud posible y que resulte relevante para las necesidades del proyecto.
Wikis En el caso de la planificacin de un proyecto, las wikis tambin se transforman en una herramienta til. Las mismas permiten dar soporte a las actividades que en este grupo de procesos se realizan y que tienen relacin con la administracin del factor humano. Dado que la recopilacin de informacin y la generacin de documentos tales como el cronograma de actividades y precedencias, las wikis cobran utilidad al momento de compartir esta informacin. Dado que en general los documentos se crean y luego son revisados, corregidos y versionados, esta herramienta permite fcilmente publicar la informacin a todos los usuarios. Adems, se pueden almacenar las diferentes versiones del documento de modo que se encuentran accesibles desde una intranet para todos los usuarios interesados en ver los mismos. Si bien las wikis permiten que los dems usuarios puedan editar el contenido de las mismas, tambin es posible que solo puedan visualizar el contenido de las mismas sin poder editarlo. Adems pueden dejar sus comentarios/agregados los cuales luego pueden ser revisados en el transcurso de una reunin. Desde el punto de vista de la administracin del factor humano dentro de un proyecto de TI, las wikis permiten lograr una mayor agilidad en las comunicaciones y tambin fomentar la participacin de los usuarios, ya que quienes tengan permiso para hacerlo pueden comentar y/o modificar un contenido de modo que se enriquece el mismo.
Ing. Hernn A. Turin
118
La nica limitacin que puede presentarse en esta herramienta, y que debe ser considerada, es que es necesario que para editar un tema los usuarios deben tener ciertos conocimientos mnimos. Es por ello que se recomienda el uso de la Wiki solo para grupos o comunidades de personas que estn altamente involucrados en el proyecto y que, por lo tanto, cuentan con los conocimientos necesarios para la utilizacin de la Wiki.
Listas de Correo En el caso de las listas de correo, su implementacin y utilidad dentro del grupo de procesos de planificacin es bsicamente el mismo que para la iniciacin de un proyecto. Esto se puede resumir en los siguientes puntos: Proveer mayor dinamismo en las comunicaciones. Permitir distribuir en forma muy sencilla y rpida documentos generados por los procesos de planificacin. Proveer una herramienta simple y accesible para todos los involucrados. Facilitar el intercambio de opiniones acerca de ciertos tpicos cuando los involucrados en la discusin se encuentran en ubicaciones geogrficas muy distantes.
Mensajera Instantnea El caso de las ventajas de mensajera instantnea aplicada al grupo de procesos de planificacin tambin es coincidente con el grupo de procesos de iniciacin. Es decir que nuevamente se trata de agilizar las comunicaciones de modo que, cuando los interesados estn en lnea, se pueden resolver en pocos minutos ciertas cuestiones que de otra manera tomaran mayor tiempo. Al estar frente a una herramienta que tiende a ser de uso corporativo en muchas organizaciones, su aplicacin tiene un costo muy bajo y redunda en grandes mejoras en la comunicacin. En cuanto a las restricciones e inconvenientes, se deben considerar los mismos aspectos mencionados en la iniciacin, es decir que se recomienda que su aplicacin vaya acompaada de otra herramienta tal como las listas de correos o los foros de discusin.
Ing. Hernn A. Turin
119
Puntos de Funcin El mtodo de estimacin por Puntos de Funcin se transforma en una tcnica til para la planificacin debido a la necesidad que se presenta en este grupo de procesos de poder tener una primera aproximacin del tamao del proyecto. En el grupo de procesos de planificacin es necesario conocer el costo asociado al proyecto para poder comenzar a construir el cronograma del proyecto, la EDT (Estructura de Desglose del Trabajo), determinar la distribucin de cada uno de los miembros del equipo a lo largo de todo el proyecto y determinar cules sern los hitos del mismo. Es por ello que se requiere el uso de tcnicas que permitan tener una estimacin lo mas aproximada posible de dichos aspectos. La estimacin por puntos de funcin, es una tcnica muy conocida y utilizada en todos los proyectos y debido a ello es que se recomienda su uso durante este grupo de procesos. Si bien es probable que an no se conozcan con exactitud algunos tems requeridos para tener una estimacin mas exacta, su uso puede combinarse con otras tcnicas tales como COCOMO de modo que se puedan tener varios resultados que ayuden a tener un panorama mas claro al respecto. Desde el punto de vista de la administracin de las personas dentro de un proyecto, los puntos de funcin tienen importancia debido a que, cuanto mas exacta sea la estimacin de tiempos, mejor ser la distribucin del equipo y se llegar con mayor tranquilidad a la finalizacin del proyecto. Pero se debe considerar que, para que esta tcnica resulte ms eficiente en la administracin de personas, es conveniente contar con una base de conocimientos de proyectos anteriores. Esto se debe a que no todos los equipos realizan las mismas tareas en iguales tiempos, por lo cual es conveniente que se cuente con antecedentes de proyectos. De este modo se pueden tomar como base de clculo aquellos antecedentes de proyectos similares que hayan sido desarrollados con equipos de similares caractersticas y obtener una aproximacin de mayor exactitud.
Estructura Desglosada de Trabajo La utilizacin de esta tcnica durante la planificacin de un proyecto, tiene especial utilidad cuando se debe realizar las estimaciones de tiempo, costos y recursos necesarios para el mismo. Complementaria con las tcnicas de estimacin, la Estructura Desglosada de Trabajo permite tener una clara visin de todas las tareas involucradas en el
Ing. Hernn A. Turin
120
proyecto. De este modo se puede comenzar a analizar las tareas desde el nivel mas bajo de la estructura e ir subiendo en la misma para, al llegar al nivel ms alto, tener una estimacin ms certera de todo el proyecto. En lo que respecta a la administracin de personas en los proyecto, se puede decir que en combinacin con los diagramas de Gantt, la Estructura Desglosada de Trabajo provee una clara visin acerca de la distribucin de todos los recursos a lo largo del proyecto. Esto permite que se detecten sobrecargas de trabajo o mala distribucin del personal a lo largo de todo el proyecto.
COCOMO Al igual que los puntos de funcin, COCOMO permite obtener una estimacin del tamao del proyecto y del tiempo y esfuerzo necesario para concluirlo. Dado a que esta tcnica consta de 3 modelos aplicables para la estimacin, es posible aplicarlo en diferentes momentos del avance del proyecto, de modo que se obtiene estimaciones con diferentes grados de exactitud. Nuevamente, la utilidad de COCOMO (al igual que los Puntos de Funcin) en la administracin del factor humano dentro de un proyecto est dada por la informacin que provee para la organizacin del equipo del proyecto. Siempre que se obtiene una estimacin del tamao de un proyecto, se puede realizar el clculo aproximado de las horas/hombre necesarias para llevar adelante el mismo. Si estas estimaciones son certeras, la distribucin del equipo en cada tarea ser adecuada y permitir que las personas trabajen sin las presiones que se generan cuando los tiempos se estiman mal y se deben dedicar ms horas de las que se haban planificado para cada persona. En comparacin con la estimacin por Puntos de Funcin, COCOMO posee la ventaja de ser mas adaptable a diferentes proyectos y adems es mas sencillo de aplicar ya que no requiere demasiada formacin previa. Sin embargo en ambas tcnicas de estimacin se debe tener en cuenta: ambos mtodos estn orientados hacia el desarrollo de software. Esto significa que son muy tiles en el mbito de los proyectos que se estudian en el presente trabajo debido a que involucran Tecnologa de Informacin que generalmente requieren algn desarrollo de software. Pero en aquellos proyectos donde no hay desarrollo de software, estas tcnicas carecen de utilidad. Es en este punto donde las bases de conocimiento cobran vital importancia,
Ing. Hernn A. Turin
121
ya que es a travs de la experiencia en otros proyectos similares como se obtendr una estimacin ms realista.
Diagramas de Gantt Dado de estos diagramas fueron concebidos para ser utilizados durante la planificacin de un proyecto, su uso en este grupo de procesos es tanto o ms importante que en cualquier otro grupo. En la planificacin de un proyecto, el diagrama de Gantt permite ver en forma simplificada todo lo relacionado con la distribucin de actividades a lo largo del tiempo y las dependencias entre las mismas. Tambin se pueden utilizar este tipo de diagramas para analizar la carga de trabajo de cada una de las personas. Este grfico es semejante al de la distribucin de actividad pero tiene por objetivo proporcionar una visin de carga total de trabajo aplicada a cada recurso. En l se indica el periodo durante el cual el recurso estar disponible para el trabajo (representado por una lnea fina) y la carga total de trabajo asignada a este recurso (representado por una lnea gruesa). Dado que esta tcnica presenta ciertas limitaciones en grandes proyecto, su uso se recomienda en combinacin con CPM o PERT de acuerdo a las necesidades de cada proyecto.
CPM Una de las necesidades del grupo de procesos de planificacin, es poder tener una visin clara de cules son las actividades que se debern realizar dentro del proyecto, la secuencia de las mismas, sus dependencias y la duracin de cada una. Es en esto donde el Mtodo del Camino Crtico (CPM) cobra relevancia y utilidad ya que permite visualizar muy fcilmente la distribucin y dependencia de cada una de las actividades de modo que su anlisis resulta muy sencillo. Adems con dicha distribucin se puede tener una visin mas acertada de cmo deber distribuirse el equipo dentro del proyecto. Es en este sentido donde su aplicacin es importante al momento de administrar el factor humano ya que permite detectar sobrecarga de trabajo sobre algunas personas y holguras en otras.
Ing. Hernn A. Turin
122
PERT El uso de PERT como una tcnica importante en la administracin de las personas involucradas en un proyecto de TI, tiene la misma utilidad que las mencionadas para CPM Esto significa que la ventaja principal de su uso est asociada a la visibilidad de la distribucin de las tareas y los tiempos dentro del proyecto. De esta forma se puede determinar cules sern las tareas que marcarn el camino crtico del proyecto, de modo que se brinde mayor atencin a como se asignan las personas a las tareas que forman dicho camino. Por otro lado se pueden detectar tems como la holgura de una tarea, de modo que se puede manejar de modo eficiente la asignacin de personas, evitando que stas tengan perodos prologados sin actividad dentro del proyecto, lo cual puede causar desmotivacin o frustracin. En comparacin con CPM, la ventaja de PERT es que es probabilstico y que, al considerar al tiempo como una variable desconocida, puede resultar es una distribucin ms realista de los tiempos.
Tcnicas de Grupo Nominal y Delphi La aplicacin de este tipo de tcnicas durante el grupo de procesos de planificacin tiene como objetivo dar soporte a todas las actividades relacionadas con la planificacin de los recursos humanos. En todo proyecto es fundamental la determinacin de la cantidad de personas que sern necesarias para llevar adelante el mismo. En algunos casos, la cantidad de personas disponibles es conocida de antemano y por tanto tenida en cuenta para la planificacin y estimacin de tiempos. Pero en otros casos, se desconoce la cantidad de personas con que se contarn y, por consiguiente, se deber contar con una estimacin de los recursos necesarios. Es en este punto donde estas dos tcnicas cobran importancia. Ambas tcnicas se basan en la experiencia de las personas que participan, de modo que es importante realizar una correcta seleccin de quienes estarn involucrados en las mismas.
Anlisis Estadstico Al igual que el Grupo Nominal y Delphi, esta tcnica tiene como objetivo dar soporte a la planificacin de los recursos humanos necesarios para llevar adelante el proyecto. En este caso no se trata de una tcnica en la cual participan
Ing. Hernn A. Turin
123
personas en el proceso de estimacin, sino que solo se proveen datos histricos a un proceso computarizado el cual, de acuerdo a ciertas variables, determinar la disponibilidad de recursos. La importancia de su implementacin radica en que, al utilizarse informacin histrica de la organizacin, la prediccin es ms cercana a la realidad. Adems puede ahorrar tiempo en las estimaciones aunque, como contrapartida, posee la desventaja de ser ms compleja y requerir ciertos conocimientos previos para poder aplicarla.
5.4.3- EJECUCIN 1. Objetivo: El objetivo del grupo de procesos de ejecucin es poner en marcha todas las actividades y las personas que estn involucradas en el proyecto para llevar adelante todo lo definido durante la planificacin. 2. Necesidades: Este grupo de procesos implica coordinar todos los recursos y las personas involucradas en el proyecto de acuerdo a lo planificado. Es en este momento donde la administracin de personas resulta crtica. Esto se ocurre debido a que la mayor parte de las actividades que se ejecutan a lo largo de todo el proyecto se concentran en este grupo de procesos y es donde, por lo general, se suelen suceder los conflictos y las diferencias en el modo de resolver los problemas o abordar las diferentes situaciones. Tambin hay que tener en cuenta que la mayora de los retrasos en un proyecto se dan durante la ejecucin y esto es probable que ocurra por una mala organizacin del trabajo, dentro de lo que tambin se enmarca la administracin de las personas (coordinacin, organizacin, motivacin y comunicacin). Es por ello que se debe prestar especial atencin a este aspecto y seleccionar las tcnicas mas adecuadas para que esta administracin resulte exitosa y redunde en beneficios para todos. 3. Tcnicas a Utilizar: Considerando las necesidades planteadas para este grupo de procesos, se determina que las tcnicas a utilizar son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, Comits de Desarrollo, Programacin de a Pares y Comits de Usuarios.
Ing. Hernn A. Turin
124
Reuniones En el caso de las reuniones aplicadas al grupo de procesos de desarrollo, permite realizar un anlisis ms detallado y exhaustivo acerca de las formas de aplicacin de las mismas. Esto se da a causa de que la ejecucin involucra una gran cantidad de variables que deben ser tenidas en cuenta y, por lo tanto, requieren de reuniones de diferentes caractersticas para poder tener la informacin necesaria. A continuacin se presentarn los diferentes tipos de reuniones aplicables durante la ejecucin de un proyecto de TI. La primera reunin que se tendr al momento de comenzar con el grupo de procesos de ejecucin es la Reunin Inicial. Quizs resulte redundante hablar sobre esta reunin ya que, en casi todos los proyectos, de una u otra manera esta reunin se lleva a cabo. Pero de todos modos se le dedicar tiempo para listar que tems deben estar presentes en la misma. El primer aspecto que se debe considerar es el objetivo de la reunin: Este encuentro se realiza para dejar en claro a todo el equipo de proyecto cual es el objetivo del mismo, como ser la metodologa de trabajo, cules son los tiempos con los que se dispone, como se manejarn formalmente las comunicaciones (algo que ya estar definido en el Plan de Comunicaciones) y cuales son las pautas de trabajo. El segundo aspecto que se debe tener en cuenta es que este encuentro debe realizarse una vez que el equipo de proyecto est conformado y deben estar presentes todos los integrantes de dicho equipo. La razn para exigir esto es simple: esta reunin resulta clave para que cada uno comience a tomar contacto con el proyecto y con la metodologa de trabajo que se pretende implementar. Si bien la mayora del equipo ya ha participado de una u otra forma en las los procesos anteriores, puede que haya miembros del equipo que se integren recin al momento de comenzar con la ejecucin del mismo. El cuarto aspecto a considerar es como se llevar adelante esta reunin y en que orden se realizar cara actividad planteada para la misma. En este caso se propone el siguiente cronograma: Presentacin formal del lder de proyecto y breve explicacin de las actividades que realizar y de sus responsabilidades. Breve introduccin al proyecto indicando objetivos del mismo y los tiempos con los que se cuentan para su finalizacin.
Ing. Hernn A. Turin
125
Presentacin de cada uno de los integrantes del equipo de proyecto indicando el rol que cumplir dentro del equipo. Presentacin de la estructura del equipo, es decir, explicar como se
distribuyen las responsabilidades y que roles dependen de cada responsable. En este caso puede resultar til el armado de un organigrama en el cual se indique en que lugar del mismo se encuentra cada uno de los presentes. Breve presentacin en la cul se explica la filosofa de trabajo y de cules sern las pautas bsicas a seguir, tanto en las comunicaciones (de acuerdo a lo definido en el Plan de Comunicaciones) como el la ejecucin de las tareas de cada miembro del equipo. Atencin de cualquier consulta por parte de los presentes y referida al proyecto y los temas presentados previamente.
Esta reunin debera realizarse o bien el primer da de trabajo de todo el equipo, o bien en algn da previo al mismo. Lo recomendable es que se haga el primer da de trabajo y que una vez finalizada la misma cada grupo se dirija a su lugar de trabajo y comience con sus actividades. Si bien esta reunin est presentada y planteada para el lder del proyecto, puede ser tomada tambin por los mandos intermedios del equipo para luego presentar a su grupo de trabajo todo lo relacionado con las actividades que le competen. Esto es posible cuando cada grupo se concibe como un subproyecto, sin perder de vista los objetivos del proyecto principal.
Las Reuniones Diarias tienen lugar una vez que comienzan las actividades en cada grupo de trabajo dentro del proyecto ya que es muy importante realizar un seguimiento muy minucioso del avance de las actividades. Esto es esencial para poder identificar puntos crticos o problemas que puedan causar retrasos o generar inconvenientes en la realizacin de las tareas del equipo de trabajo. Las reuniones diarias son una herramienta que, bien aplicada, resulta muy til para detectar problemas en forma temprana y evitar los desvos que surgen en el da a da de cada proyecto. Pero estas reuniones deben cumplir con una serie de caractersticas para que sean eficaces y tiles al proyecto. A continuacin se presentan los tems a tener en cuenta:
Ing. Hernn A. Turin
126
El encuentro se debe realizar al principio del da antes de comenzar la jornada laboral. La duracin no debe exceder los 10 o 15 minutos como mximo. Deben estar presentes todos los integrantes del quipo. Cada integrante debe responder brevemente las siguientes preguntas: a. b. c. En qu estado estn sus actividades? Qu tiene planeado hacer en el da de hoy? Necesita ayuda con algo?
La idea de este encuentro es que cada integrante del equipo este al tanto del avance de las actividades del resto. Adems se favorece la comunicacin y la participacin de todos ya que si algn miembro presenta algn problema relacionado con sus actividades dentro del proyecto, quizs alguien del resto del quipo pueda colaborar con alguna propuesta de solucin. Por otra parte esto permite, al responsable del equipo, detectar a tiempo cualquier retraso e iniciar las acciones que crea convenientes para corregir dicho desvo. En caso de que se manifieste un inconveniente que necesite ser tratado ms en detalle, se dejar pendiente dicho punto para continuar la rueda con los dems integrantes y, al finalizar la reunin, se seguir el tema con le involucrado. Esto es para evitar que el encuentro se extienda ms all del tiempo sugerido y se permita al resto del equipo continuar con sus actividades. Una vez finalizada la reunin, cada uno vuelve a sus actividades habituales. Por otro lado, las Reuniones de Avance, si bien son aplicables a todos los grupos de trabajo de un proyecto, representan una herramienta fundamentalmente til para el lder de proyecto ya que permite medir el grado de avance general de los diferentes grupos de trabajo dentro del proyecto. Estas reuniones se recomienda que sean realizadas cada 15 das, aunque este plazo puede extenderse o reducirse de acuerdo a las caractersticas de cada proyecto y, fundamentalmente, de los tiempos del mismo. El objetivo de la reunin de avance es proveer al lder de proyectos de una visin global del estado de las diferentes actividades dentro del proyecto. En esta reunin deben participar el lder del proyecto y los encargados de los diferentes grupos de trabajo. All cada uno de los encargados expondr el grado de avance de su grupo y, en caso de existir, expondrs las dificultades con las que se ha
Ing. Hernn A. Turin
127
encontrado y las consecuencias de las mismas en el cumplimiento de los objetivos de su grupo. La duracin recomendada de esta reunin es de no ms de dos horas, dependiendo de la cantidad de asistentes y de la frecuencia con la que se fije la realizacin de dicho encuentro. Se debe tener en cuenta que cuanto menor es la frecuencia de reunin, probablemente mayor ser la duracin de la misma.
Wikis En el caso de la ejecucin de un proyecto, las wikis tambin se transforman en una herramienta til. Al igual que en los casos anteriores, tienen como utilidad principal el dar soporte a las actividades que en este grupo de procesos se realizan y que tienen relacin con la administracin del factor humano. En este caso particular, las wikis permiten que todo el grupo pueda encontrar en ella toda la informacin necesaria para su trabajo. Esto incluye: informacin de contacto de los diferentes grupos/miembros del equipo, documentos relacionados con la planificacin, plantillas para la generacin de documentacin, calendario de reuniones y cualquier otra informacin que se decida colocar en el sitio. Tambin se pueden almacenar las diferentes versiones del documento de modo que se encuentren accesibles desde una intranet para todos los usuarios interesados en ver los mismos. Si bien las wikis permiten que los dems usuarios puedan editar el contenido de las mismas, tambin es posible que los usuarios solo puedan visualizar el contenido sin poder editarlo. Adems pueden dejar sus comentarios/agregados los cuales luego pueden ser revisados en el transcurso de una reunin. Todo esto nuevamente apunta a lograr una mayor agilidad en las comunicaciones y tambin fomentar la participacin de los usuarios y la colaboracin entre los miembros del equipo de trabajo.
Listas de Correo En el caso de las listas de correo utilizadas durante la ejecucin el proyecto, sus beneficios son los mismos que los planteados para el grupo de planificacin, es decir: Proveer mayor dinamismo en las comunicaciones ya que durante los procesos de ejecucin, el dinamismo y la agilidad en todos los sentidos resulta un factor crtico de xito.
Ing. Hernn A. Turin
128
Permitir distribuir en forma muy sencilla y rpida documentos generados. Proveer una herramienta simple y accesible para todos los involucrados. Facilitar el intercambio de opiniones acerca de ciertos tpicos cuando los involucrados en la discusin se encuentran en ubicaciones geogrficas muy distantes. Foros de Discusin El caso de los foros de discusin aplicados a los procesos de ejecucin, tienen la ventaja de permitir la comunicacin de los miembros del equipo sin la necesidad de tener que movilizarse a otras ubicaciones fsicas. Bsicamente este caso es una combinacin de algunas de las ventajas de las wikis (compartir informacin y contenidos) y las ventajas de las listas de correo (simplicidad de uso y facilidad de implementacin). Esta combinacin de ventajas la convierte en muy atractiva para mejorar la comunicacin dentro de un proyecto. Sin embargo, en comparacin con las dems ventajas que ofrecen las dos alternativas antes mencionadas, no resulta tan conveniente aunque para algunos proyectos con una estructura mas reducida, su simplicidad puede resultar ms atractiva que las wikis.
Mensajera Instantnea El caso de la mensajera instantnea aplicada al grupo de procesos de ejecucin, resulta una herramienta casi indispensable para la comunicacin tanto entre los grupos dentro del equipo como entre los miembros de cada grupo. En este caso, los beneficios de la mensajera instantnea estn ms relacionados con los beneficios de las listas de correo y con el beneficio adicional de ser una herramienta online. Esta herramienta se hace especialmente interesante cuando el equipo de trabajo est distribuido en oficinas diferentes, de modo que las consultas breves o pedidos simples pueden gestionarse mediante esta herramienta. Sin embargo siempre se debe tener presente que no es conveniente que reemplace el trato cara a cara excepto que las caractersticas del proyecto as lo requieran.
Ing. Hernn A. Turin
129
Comits de Desarrollo Cuando hablamos de la influencia del factor humano en los proyectos de TI, uno de los primeros factores que se menciona es la influencia que tienen los usuarios finales del proyecto sobre el xito o fracaso del mismo. Esta influencia de los usuarios sobre el resultado final de un proyecto puede ser positiva o negativa de acuerdo como se maneje esta variable. Es entonces donde aparece la necesidad de involucrar a los mismos en algunos procesos del proyecto, de modo que se sientan parte del mismo y que sus opiniones y sugerencias sean tenidas en cuenta por el equipo de proyecto. La participacin activa de los usuarios dentro del proyecto tiene sus bases en tres hechos fundamentales: 1- Los usuarios son los encargados de hacer el trabajo y, por lo tanto, son quienes mejor comprensin tienen del mismo. 2- Los integrantes del equipo de proyecto son lo que poseen el entrenamiento y la visin sobre las tecnologas de la informacin y, por lo tanto, son los que pueden comprender cmo aplicar esas tecnologas para realizar el trabajo de los usuarios o facilitarles la realizacin del mismo. 3- El trabajo en grupo siempre enriquece el resultado final. En este caso si el grupo de los usuarios (que son los que conocen el trabajo) y el grupo del proyecto (que conocen las tecnologas) trabajan en conjunto, podrn lograr un resultado que satisfaga las expectativas de los usuarios con las tecnologas que considere el equipo de proyecto. Si se tiene en cuenta estos tres aspectos, puede lograrse un muy buen equipo de trabajo donde los usuarios formen parte activa del mismo de modo que se cree un sentido de pertenencia a dicho grupo. Adems se aleja la posibilidad de una eventual resistencia a los cambios generados por la implementacin del proyecto. Todo esto cobra mayor relevancia cuando se trata de un proyecto que incluye el desarrollo de un producto software destinado a dar soporte a las tareas de las personas que trabajan dentro de la organizacin. Es en este contexto que radica la importancia de la implementacin de los comits de desarrollo, ya que esta tcnica facilita la administracin de las personas involucradas en el proyecto y que, como se menciona antes, tienen gran influencia en el xito o el fracaso del mismo.
Ing. Hernn A. Turin
130
Otra de las ventajas en el uso de esta tcnica es su adaptabilidad a los diferentes tipos de proyectos de TI. Su versatilidad permite que no solo se utilice para aquellos proyectos que involucran desarrollo de software, sino tambin a aquellos en los que, por ejemplo, solo se implementan nuevas tecnologas.
Programacin de a Pares Uno de los conceptos asociados al mundo de los sistemas es el concepto de sinergia, segn el cul el todo es ms que la suma de las partes. Es exactamente ste el concepto que transforma a la programacin de a pares en una herramienta muy importante al momento de administrar las personas involucradas en un proyecto de TI. La programacin de a pares permite que dos personas puedan trabajar sobre el mismo cdigo, de modo que se poseen dos visiones sobre un mismo tema y se enriquece el desarrollo. Pero no slo esta es una ventaja sino que tambin hay otro factor que es de gran valor para la administracin de personas: la transferencia de conocimientos. En los proyectos, la transferencia de conocimientos es otro de los factores muy importantes a tener en cuenta, ya que es conveniente que varias personas tengan conocimiento acerca de las actividades que se realizan. Esto facilita la rotacin de las personas y adems funciona como plan de contingencia para casos en que se pierda alguno de los miembros del equipo. Adems, sirve como plan de capacitacin para los eventuales ingresos que se produzcan durante la marcha del proyecto. La desventaja que se presenta en este caso, es que la programacin de a pares es solo aplicable a proyectos que involucran desarrollos de software, de modo que todas sus bondades no pueden aprovecharse cuando se trata de otro tipo de proyectos de IT, aunque algunos tems podran adaptarse (por ejemplo en caso de un proyecto de implementacin de nuevas tecnologas, colocar a una persona novata a trabajar con un experto en la instalacin del nuevo hardware de modo que se produzca la transferencia de conocimientos).
Ing. Hernn A. Turin
131
Comits de Usuarios Para comprender con mayor facilidad la utilidad de esta tcnica, es conveniente primero definir un concepto que est muy relacionado con ella: Comunidades de Prctica. Las comunidades de prctica son grupos sociales constituidos con el fin de desarrollar un conocimiento especializado, compartiendo aprendizajes basados en la reflexin compartida sobre experiencias prcticas. Una comunidad de prctica vuelve explcita la transferencia informal de conocimiento dentro de redes y grupos sociales ofreciendo una estructura formal que permite adquirir ms conocimiento a travs de las experiencias compartidas dentro del grupo. Es a partir de estos conceptos donde queda claro el porqu de la utilidad de los comits de usuarios, ya que stos son simplemente espacios donde los usuarios involucrados en el producto final de un proyecto pueden compartir sus experiencias y trasferir conocimientos a partir de las mismas. Si bien se est frente a una tcnica que puede ser implementada en ms de un grupo de procesos, su implementacin durante la ejecucin del mismo tiene fundamentalmente dos razones: Disminuir al mximo el riesgo de resistencia al cambio: se busca que los usuarios se sientan identificados con el nuevo producto involucrndolos en las discusiones relacionadas con ciertos aspectos funcionales del mismo. Obtener mayor cantidad de informacin acerca de ciertos requisitos del proyectos e incluso obtener soluciones creativas y alternativas frente a ciertos problemas. Esto ltimo se logra gracias a que los usuarios no estn tan compenetrados en el detalle del proyecto y por lo tanto sus ideas pueden fluir sin ningn tipo de sesgo.
5.4.4- SEGUIMIENTO Y CONTROL Una de las particularidades de la estructura de grupos de procesos propuestos por el PMBOK es que la ejecucin de los mismos se solapa y que existe una interaccin entre los mismos. Esta interaccin est dada por las entradas y salidas necesarias para cada proceso (la salida de un proceso representa la entrada de otro).
Ing. Hernn A. Turin
132
Adems la superposicin hace que muchas veces se estn ejecutando mas de un grupo de proceso a la vez solo que con diferente intensidad. La interaccin entre los grupos de procesos se puede ver claramente en la Figura 16.
Figura 19 Interaccin entre los grupos de procesos segn el PMBOK [PMI, 2004].
Si analizamos la interaccin del grupo de procesos de seguimiento y control para con los dems grupos, resulta claro que la mayor interaccin se da con el grupo de ejecucin. Es a partir de este anlisis que se puede plantear como tcnicas y herramientas para la administracin del factor humano, a algunas de las mencionadas en el grupo de ejecucin. Para ello habr que poner mayor atencin en algunos aspectos de dichas tcnicas de modo que la informacin que se obtenga en las mismas sea til tambin para el control y el seguimiento. A continuacin se analizarn que aspectos deben priorizarse y considerarse en las tcnicas aplicadas en la ejecucin, para que resulten tambin tiles en el control y seguimiento del proyecto. 1. Objetivo: El objetivo de este grupo de procesos es el de monitorear la ejecucin de modo que se puedan detectar problema en forma temprana y poder aplicar acciones correctivas en caso de que sea necesario. 2. Necesidades: Desde el punto de vista de la administracin del factor humano, en este grupo de procesos, las necesidades se centran bsicamente en la
Ing. Hernn A. Turin
133
recopilacin de informacin y la identificar los posibles puntos de conflictos. La informacin de de gran importancia para poder realizar los controles, pero tambin para detectar posibles problemas antes de que tengan consecuencias graves en el proyecto. Por su parte, la deteccin de posibles puntos de conflictos es quizs el aspecto ms importante a tener en cuenta ya que es aqu donde la administracin de personas debe poner especial atencin. 3. Tcnicas a Utilizar: De acuerdo a las necesidades planteadas y segn los objetivos que se persiguen en el grupo de procesos de control, las tcnicas a aplicar son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, Diagramas de Gantt, Estructura de Desglose de Trabajo, PERT, CPM, COCOMO y Puntos de Funcin.
Reuniones Conservando las mismas caractersticas que se mencionaron anteriormente para cada tipo, la reunin es una tcnica que claramente permite obtener informacin muy valiosa para poder realizar el seguimiento y control del avance del proyecto. Adems tambin resultan muy importantes para detectar posibles puntos de conflictos entre integrantes del equipo del proyecto, o entre el equipo y algn usuario del proyecto. Durante el seguimiento y control de un proyecto se pueden utilizar los mismos tipos de reunin que se mencionaron para la ejecucin, solo que en este caso se deber ponderar algunos otros aspectos para poder obtener informacin especfica de control. A continuacin se analizarn cada uno de los tipos ya mencionado remarcando los aspectos a considerar para convertirlas en una tcnica til para el seguimiento de proyectos. En el caso de las reuniones diarias, se debe prestar especial atencin a la respuesta que se obtiene en las preguntas: a. En qu estado estn sus actividades? b. Qu tiene planeado hacer en el da de hoy? c. Necesita ayuda con algo? Este aspecto es muy importante ya que la respuesta que se obtenga puede develar algunos problemas que no tengan que ver con la tarea que est realizando la persona y que tal vez estn dificulte o haga incmodo su paso por el proyecto.
Ing. Hernn A. Turin
134
Si bien anteriormente se seal que este tipo de reuniones no debe extenderse demasiado en el tiempo y que, si hay inconvenientes y otros temas, se deben tratar con posterioridad, es importante darle tratamiento a los mismos. En este sentido lo ms recomendable es que una vez que se da por finalizada la reunin, el facilitador de la misma dedique inmediatamente un tiempo extra a cada uno de los que plantearon problemas. La idea de este tiempo es poder analizar en ms detalle lo planteado para tratar de encontrar una solucin y lograr que la persona se sienta contenida y escuchada. Por el lado de las reuniones de avance aplicadas al seguimiento y control de un proyecto, permiten tambin controlar el avance del trabajo e identificar problemas a tiempo para as realizar las acciones correctivas que se consideren necesarias, e incluso tomar acciones preventivas si as se cree conveniente. Cuando se realiza una reunin de este tipo es conveniente que el moderador de la misma tenga presente cules son los parmetros dentro de los cuales debera encontrarse el proyecto para que todo est en orden. Se debe prestar atencin a la forma en que se avanza en cada uno de los temas como as tambin la velocidad de dicho avance. En aquellos casos en que se verifiquen dificultades en el avance, se debe dedicar un momento a analizar el porqu de las dificultades de forma tal que se trate de dejar lo mas claro posible las causas para que cada responsable pueda dedicarse a trabajar en el mejoramiento de las mismas. Si bien las reuniones de avance tienen la ventaja de tener una duracin mayor que las diarias, cuentan con la desventaja de que la cantidad de temas a tratar es mayor. Adems no se puede ir a un nivel de detalle tan profundo con todos los temas, de modo que debe tratarse de ahondar solo en aquellos puntos donde se detectaran problemas o probables conflictos. Tambin se recomienda su uso combinado con las reuniones diarias de modo que lo que no pueda ser tratado en las reuniones de avance pueda tratarse en las diarias y, si fuese necesario, solicitar otro tipo de encuentro para tratar el problema.
Wikis, Foros de Discusin y Listas de Correo El caso de las Wikis, los Foros de Discusin y las Listas de Correo en este caso se analizarn en conjunto ya que la utilidad de las tres tcnicas aplicadas al seguimiento y control de un proyecto es bsicamente la misma, con las diferencias que marcan simplemente su forma de funcionamiento.
Ing. Hernn A. Turin
135
En cualquiera de los tres casos la utilidad est dada fundamentalmente por dos aspectos: la facilidad para distribuir / recopilar informacin necesaria para monitorear el avance del proyecto y la facilidad para imprimir dinamismo en las comunicaciones. Este segundo aspecto es el que mas importa en lo que respecta a la administracin del factor humano dentro de un proyecto. Tanto las wikis, como los foros y las listas de correo permiten una fluida y rpida comunicacin entre los miembros de un equipo de modo tal que, si surgiera algn inconveniente, este puede ser comunicado en forma rpida a todo el resto del equipo. Adems, si en lugar de tratarse de un problema se tratase de un pedido de informacin o una consulta acerca de algn tema en particular, el hecho de tratarse de tcnicas que hacen pblica informacin, permitir tener diferentes opiniones o sugerencias por parte de los miembros. Sin embargo, el hecho de que todo lo que se publica es visto por todos los miembros genera un inconveniente: cuando la consulta debe ser privada porque afecta a las relaciones con algn otro integrante del equipo o es un tema muy delicado, no permiten tener privacidad. Esto lleva a sugerir que estas herramientas se utilicen en conjunto con otras tcnicas las cuales permiten tener mayor privacidad en ciertos temas.
Mensajera Instantnea El caso de la mensajera instantnea es justamente la tcnica que provee la solucin al problema de privacidad planteado con lo foros, las wikis y las listas de correo. En este caso la ventaja principal es que la mensajera instantnea permite mantener contacto entre personas en forma privada, de moso que el resto del equipo no conozca dicho contacto. La prestacin de contacto persona a persona es fundamental en casos donde hay conflictos personales o problemas que requieren un tratamiento discrecional. Adems tambin tienen la ventaja de que cuando se requiere informacin de solo una persona, slo se contacta a sta sin molestar al resto con mensajes que no le corresponden ni interesan. Como contrapartida, la distribucin de contenidos a todo un grupo es un poco ms compleja ya que actualmente no hay herramientas que permitan, por ejemplo, transferir un archivo a mltiples destinatarios. Es por esto que la utilizacin de la mensajera instantnea para este caso se recomienda en combinacin con un Foro, Wiki o Lista de correo.
Ing. Hernn A. Turin
136
Diagramas de Gantt Bsicamente, el uso de esta tcnica en el seguimiento y control de un proyecto, tiene como objetivo el poder comparar el avance real del proyecto con lo planificado. Nuevamente en este caso su simplicidad es el factor determinante para su inclusin en este grupo de procesos. La ventaja radica en que con una simple revisin de este diagrama y con un resumen del estado actual del proyecto, se puede determinar si el mismo est avanzando de acuerdo a lo planificado o si es necesario realizar algn tipo de ajuste. Uno de los tipos de diagramas de Gantt que se puede utilizar en este grupo de procesos es el Diagrama de Gantt para seguir la marcha de las actividades. En este tipo de diagrama se usa el eje vertical para representar actividades, mientras que los recursos aplicados a cada actividad se indican indicados por medio de claves sobre la lnea que representan la duracin de la actividad. Desde el punto de vista de la administracin del factor humano, la utilidad principal se encuentra en el hecho de poder detectar retrasos en el proyecto en forma temprana. De este modo se pueden tomar medidas preventivas y/o correctivas para evitar retrasos en la finalizacin del mismo y evitar sobrecarga de trabajo en las personas en las instancias finales del proyecto.
Estructura Desglosada de Trabajo La utilizacin de esta tcnica durante el seguimiento y control de un proyecto, tiene especial utilidad cuando se debe realizar un seguimiento acerca del avance de las distintas tareas que comprenden el proyecto. Las planillas que se obtienen a partir del desglose en tareas, en algunos casos pueden contener una columna denominada Porcentaje de Seguimiento la cual se actualiza peridicamente segn el avance. De este modo, de acuerdo al avance de cada tarea, se puede subir de nivel y determinar en que estado se encuentra el avance total del proyecto. Desde el punto de vista de la administracin de personas en los proyecto, se puede decir que la principal utilidad de esta tcnica es la de detectar retrasos en los cronogramas y evitar sobrecargas sobre el final del proyecto, como as tambin evitar las tensiones que conlleva un retraso el en cronograma.
Ing. Hernn A. Turin
137
En este caso es conveniente su uso en combinacin con alguna otra tcnica como lo son CPM o PERT, adems de los diagramas de Gantt, los cuales proveen un panorama ms claro sobre el avance del proyecto.
PERT y CPM Si se observa la Tabla XIV, se notar que ambas tcnicas son aplicables solamente a los grupos de proceso de planificacin y de seguimiento y control. El porque de esto es simple: durante la planificacin se utilizan para determinar la distribucin de los recursos a lo largo de todo el proyecto y la asignacin de los mismos a cada una de las tareas. Mientras que en el seguimiento y control del proyecto, se utilizan los documentos generados el la planificacin para monitorear el avance del proyecto. En el caso del seguimiento y control visto desde el punto de vista de la administracin de personas, la utilidad de los documentos generados por CPM y PERT radica en determinar la carga de trabajo de las personas. En muchos casos se realiza una determinada distribucin de tareas durante la planificacin, pero luego, durante la marcha del proyecto, puede que se noten deficiencias en esa distribucin. Esto puede darse porque las estimaciones no fueron lo suficientemente precisas o porque el desempeo de las personas no es el previsto. Es para detectar este tipo de inconvenientes que se necesitan de las dos tcnicas mencionadas. Por lo general por si solas no tienen demasiada utilidad ya que, quien se encarga de hacer el seguimiento del proyecto, debera ir grupo por grupo o persona por persona viendo como estn respecto de lo planificado. Lo ideal es que se utilicen como material de soporte para las reuniones (diarias y de avance) para poder tener un panorama de lo que se espera del desempeo del equipo. Adems la idea de su aplicacin es monitorear el avance del trabajo de cada persona y detectar cuando haya sobrecargas y retrasos de modo que se pueda ayudar y evitar tensiones en el trabajo.
COCOMO y Puntos de Funcin El caso de COCOMO y de los Puntos de funcin aplicados al seguimiento y control de un proyecto de TI tiene su importancia en el hecho de que durante la marcha del proyecto pueden surgir cambios. Estos cambios pueden ser menores o pueden ser cambios sustanciales que impacten en la duracin del mismo. En este
Ing. Hernn A. Turin
138
ltimo caso es que se dar la necesidad de utilizar estas tcnicas para redefinir algunos tiempos y determinar si, de acuerdo a las nuevas definiciones y los nuevos tiempos calculados, la marcha del proyecto es la correcta. Nuevamente, al igual que con PERT y CPM, lo que se utiliza en estos casos son los resultados de stas tcnicas para monitorear la marcha del proyecto y detectar inconvenientes en la carga de trabajo o cualquier inconveniente que afecte a los miembros del equipo y que pudiese generar conflictos. Si bien puede considerarse que, el reclculo de los tiempos cuando se realizan cambios en las definiciones del proyecto, forma parte del proceso de planificacin, en el presente trabajo tambin se los incluye en el seguimiento y control debido al impacto que pueda tener sobre el trabajo el hecho de modificar los tiempos y la distribucin del equipo.
5.4.5- CIERRE Antes de comenzar con el anlisis de este grupo de procesos es necesario hacer una salvedad: si bien en el caso particular del PMBOK se considera que el cierre del proyecto concluye con la entrega del producto. El concepto de entrega depende en gran medida de lo que se haya definido en el contrato antes de comenzar el mismo. As, puede ocurrir que la entrega del producto sea, por ejemplo, la entrega de la documentacin del sistema y el producto software para que luego el cliente se encargue de la implementacin y puesta a punto del mismo. Tambin puede que la entrega del producto implique que el sistema y los productos software relacionados deben estar implementados y puestos en marcha. A fin de abarcar una mayor gama de posibilidades, en el presente trabajo se considerar que la entrega del producto se realiza con el sistema funcionando y con los productos software instalados y puestos en marcha. Realizada esta aclaracin se comenzar con el anlisis correspondiente. 1. Objetivo: El objetivo de este grupo de procesos es el de dar por finalizadas cada una de las actividades de un proyecto, de modo que se pueda dar por terminado formalmente el mismo. 2. Necesidades: En este caso, considerando la salvedad hecha previamente sobre lo que se considera como parte del grupo de procesos de cierre, las necesidades de
Ing. Hernn A. Turin
139
administracin de personas se centra especialmente en los usuarios finales. Esto es de debido a que la mayora de las actividades que se llevan a cabo estn relacionadas con la implementacin y puesta a punto del sistema. Es en este momento donde resulta crtico el logro de la aceptacin del producto por parte de los usuarios finales. En el cierre del proyecto es donde aparece con fuerza la posibilidad de encontrarse con resistencia al cambio por parte de quienes sern los encargados de operar de acuerdo a las nuevas normas implementadas con el proyecto. De modo que, cuanto mayor sea la atencin que se le dedique al tema y cuanto mejor organizadas estn las tcnicas a implementar para evitar la resistencia al cambio, mayores sern las probabilidades de obtener una implementacin exitosa. 3. Tcnicas a Utilizar: Segn lo expuesto en la Tabla XIV, las tcnicas a utilizar en este grupo de procesos son: Reuniones, Wikis, foros de Discusin, Listas de Correo, Mensajera Instantnea, Comits de Usuarios, Grupos de Apoyo, Mesa de Ayuda y Estructura Desglosada de Trabajo.
Wikis, Foros de Discusin y Listas de Correo Nuevamente en este caso se analizarn las tres tcnicas en conjunto dado que su utilidad y aplicabilidad es muy semejante entre s. La idea de utilizar estas tcnicas durante el grupo de procesos de cierre est fundamentalmente orientada a dar soporte a los usuarios finales. Esto se basa en el hecho de que, al implementar un nuevo proyecto en una organizacin, surgirn dudas acerca del uso tanto del software que se implemente como de las tecnologas involucradas. En este sentido es que las wikis, los foros y las listas de correo pueden ser muy bien explotados. Estas herramientas permiten que los usuarios se puedan comunicar fcilmente con el grupo del proyecto encargado de la puesta en marcha del mismo, de modo que sus dudas o comentarios puedan ser recibidos y atendidos en forma muy simple. La idea fundamental del uso del foro es el de poder crear un foro de discusin donde todos los usuarios puedan dejar sus consultas para que el equipo del proyecto pueda darles una respuesta, o bien lo pueda hacer otro usuario con mas conocimientos. De este modo se puede crear una comunidad virtual sumamente til
Ing. Hernn A. Turin
140
y que adems sirve como base de conocimiento. Lo mismo ocurre con las wikis, aunque en este caso la informacin ser un poco mas esttica. Este hecho radica en que en las wikis se puede colocar documentacin y cualquier otro tipo de informacin que pueda ser consultada por los usuarios frente a una duda o requerimiento de informacin relacionada con el proyecto que se est implementando. Finalmente estn las listas de correo. sta es la ms dinmica de las tres tcnicas ya que, al ser el correo electrnico una herramienta de uso masivo y generalmente corporativo, las respuestas se darn con mayor rapidez que en el caso de un foro. Adems pueden montarse sitios donde todos los mails conformen tambin una base de conocimiento en la cul puedan definirse diferentes criterios de bsquedas. De este modo los usuarios podran buscar todos aquellos mails con consultas relacionadas a un tema particular y, de esta forma, hallar una respuesta a su consulta sin la necesidad de volver a reiterar un tema va correo electrnico a la lista. La desventaja principal radica en que, al no ser herramientas en lnea, las respuestas a consultas urgentes estarn sujetas a la frecuencia con que el equipo de proyecto o el resto de los usuarios ingresen al foro, el correo electrnico o la Wiki.
Mensajera Instantnea La idea de implementar la mensajera instantnea en el grupo de procesos de cierre es bsicamente la misma que se menciona para el caso de los foros y las listas de correo, es decir: dar soporte a los usuarios durante la implementacin del proyecto de forma tal que se disminuya todo lo posible la resistencia al cambio. Adems, se genera confianza en los usuarios ya que, por contar con este tipo de mecanismos para evacuar dudas, se da una sensacin de respaldo y acompaamiento en la implementacin. La diferencia fundamental de la mensajera instantnea es que se encuentra en lnea, lo cual es muy bueno para los usuarios. Pero tambin tiene una implicancia no menor en el equipo encargado de implementar el proyecto: probablemente se requerir una persona con dedicacin completa para atender las consultas. Este es un dato no menor porque y que se debe tener en cuenta al momento de decidir si se implementa o no. Por lo general esto puede hacerse a travs de una pgina Web
Ing. Hernn A. Turin
141
donde los usuarios pueden acceder y conectarse con la persona encargada de atender las consultas. La ventaja es clara: las consultas urgentes son atendidas y respondidas de inmediato, generando satisfaccin y aceptacin por parte del usuario. La desventaja, es la ya mencionada: requiere personal con dedicacin casi exclusiva para estas tareas. Dependiendo del tamao y caractersticas del proyecto, la persona encargada de recibir las consultas puede tener asignadas otras actividades ya que probablemente no habr consultas constantes, pero en otros casos la dedicacin ser de tiempo completo. Cada equipo deber definir el uso o no de sta tcnica en funcin del grado de criticidad de la implementacin y de la percepcin de resistencia al cambio que se detecte en los usuarios finales.
Comits de Usuarios La implementacin de sta tcnica obedece a fundamentalmente a las dos razones: Disminuir al mximo el riesgo de resistencia al cambio: se busca que los usuarios se sientan identificados con el nuevo producto involucrndolos en las discusiones relacionadas con ciertos aspectos funcionales del mismo de modo que se asegure una mejor comprensin. Generar un espacio donde los usuarios puedan compartir sus experiencias y compartir su conocimiento, y generar una verdadera comunidad de prctica.
sta segunda razn es quizs la mas importante porque ninguna de las dems tcnicas mencionadas apunta a lograr la creacin de este tipo de comunidades. Si bien en proyecto de pequeo o mediano tamao puede resultar poco convincente el uso de este tipo de comits, en proyectos de gran tamao, que se implementa en diferentes lugares u organizaciones, se transforma en una tcnica sumamente til. Lo que se busca lograr formando este tipo de comunidades es generar un sentido de pertenencia por parte de los usuarios para con el proyecto, de forma tal que no se vean como algo externo al proyecto sino como un componente mas del mismo. Esto resulta de gran ayuda para lograr una finalizacin exitosa de proyecto.
Ing. Hernn A. Turin
142
Nuevamente la decisin de si utilizar o no este tipo de tcnicas, deber ser evaluado por el equipo de acuerdo a las caractersticas del proyecto, ya que insume tiempo y recursos para realizarlo.
Grupos de Apoyo La utilizacin de los grupos de apoyo en el cierre de un proyecto tiene como objetivo lograr una implementacin rpida y exitosa. Como se mencion anteriormente, los grupos de apoyo son equipos de personas que brindan soporte in situ en los lugares afectados por la implementacin del proyecto. Estos grupos son aplicables fundamentalmente en proyectos que involucran la implantacin de un nuevo producto software, de modo que los usuarios necesitarn soporte para comenzar a utilizarlo (adems de la capacitacin previa). Sin embargo se debe tener especial cuidado en como funciona esta clase de grupos, ya que la idea es dar soporte en la realizacin de tareas y no hacer el trabajo por los usuarios. Adems de tiene que definir el perodo que durar este soporte ya que debe realizarse por un perodo acotado de tiempo. Nuevamente la idea de esta tcnica es generar confianza en los usuarios y mostrarles que, en el equipo de proyecto, existe preocupacin por su comodidad. La ventaja principal es que, el hecho de tener personas que los ayuden en sus tareas con el nuevo sistema, tiene un efecto muy positivo sobre los usuarios quienes se sentirn contenidos. Pero como contrapartida, la desventaja es que requiere de personas del proyecto con un tiempo importante dedicado a estas actividades. Aadems, en algunos casos, se puede generar en el usuario una sensacin de invasin de su espacio y su trabajo. Es por ello que se debe analizar muy detenidamente tanto a los usuarios como al proyecto antes de decidir implementar esta tcnica, ya que si no se lo analiza se corre el riesgo de lograr el efecto contrario al esperado.
Mesa de Ayuda Al igual que los grupos de apoyo, la mesa de ayuda tiene como objetivo brindar soporte a los usuarios del proyecto de modo que se pueda lograr una implementacin exitosa del mismo. Desde el punto de vista de la administracin de
Ing. Hernn A. Turin
143
las personas, el objetivo es minimizar la resistencia al cambio y generar confianza y seguridad en los usuarios respecto de la implementacin del sistema. Existen diferentes formas de implementar la mesa de ayuda, una de ella es utilizando la mensajera instantnea, lo cul ya se analiz con anterioridad. Otra de las formas es a travs de los denominados Call Center que operan en forma telefnica. Finalmente tambin se puede utilizar el call center combinado con mensajera instantnea de modo que se puedan tener ambas opciones. Dependiendo de la organizacin y del tipo de proyecto, la implementacin de la mesa de ayuda puede ser muy simple, ya que hay muchas organizaciones que cuentan con grupos de este tipo para atender las necesidades de los usuarios. De este modo solo se requerira contar con personas que tengan conocimiento del proyecto y que formen parte del grupo de la mesa. Finalmente las mesas de ayuda tienen la ventaja de que pueden ser perdurables a travs del tiempo. Es decir que si el proyecto se da por finalizado, la organizacin puede decidir la continuidad de la mesa de ayuda para dar soporte a los usuarios no solo en aspectos relacionados con el proyecto puntual que le dio origen, sino tambin a todos aquellos temas (tecnologa y otras aplicaciones) que la organizacin defina.
Estructura Desglosada de Trabajo La utilizacin de esta tcnica durante el cierre de un proyecto, tiene su principal utilidad cuando se debe verificar si se ha cumplido con todas las tareas que conforman dicho proyecto. Dado que el cierre formal del mismo se puede declarar una vez que todas las tareas se han cumplido totalmente, la Estructura Desglosada de Trabajo permite visualizar si la totalidad de las tareas tienen un porcentaje de cumplimiento de 100%. De este modo se evita dar por finalizado un proyecto cuando aun no se culmin con alguna tarea. Bsicamente funciona como lista de control para verificar cada actividad y, en el caso de la administracin de personas, sealarle a cada responsable si es que hay alguna tarea pendiente.
Ing. Hernn A. Turin
144
CAPITULO
VI
VALIDACION
6.1-
SISTEMA DE VALIDACIN SELECCIONADO

La validacin del modelo planteado en el presente trabajo de tesis consisti en
determinar si el mismo puede ser, o no, aplicado en forma exitosa en la gestin de un proyecto de TI dentro de una organizacin. Las alternativas para poder realizar esto eran acotadas y se redujeron a dos opciones: 1La realizacin de una prueba piloto en la cul se implemente el modelo de gestin propuesto en un proyecto real y evaluando los resultados obtenidos al finalizar dicha prueba. 2La utilizacin del sistema de juicio de expertos, a travs del cual el modelo ser sometido al anlisis exhaustivo de un grupo de expertos en la gestin de proyectos. De las dos alternativas planteadas, la seleccionada fue la nmero dos, es decir, la validacin a travs del juicio de expertos en la materia. Esta seleccin se bas fundamentalmente en que no se contaban con los recursos necesarios para poder llevar adelante una prueba piloto en la cul se pueda gestionar el factor humano de un proyecto mediante el la implementacin del Modelo de Gestin de Personas propuesto. Para llevar adelante la validacin, se seleccionaron cuatro profesionales cuya formacin y experiencias estn relacionadas con la gestin de proyectos y de los diferentes factores de xito que afectan a los mismos. A cada uno de estos expertos se le entreg un extracto de la solucin planteada a travs del trabajo de tesis, en el cul se indicaba el modelo seleccionado un breve detalle acerca de la implementacin de cada una de las prcticas (Ver Anexo I). Adems se les entreg, juntamente con el extracto del modelo, un cuestionario que a ser contestado por el experto y en el cul se hacan todas las preguntas necesarias para poder obtener un juicio de valor por sobre la utilidad del modelo (Ver Anexo II). El cuestionario estaba estructurado en tres secciones: la primera de ellas contena preguntas orientadas a la evaluacin del modelo utilizado para la estructuracin de la solucin (estructura del modelo, aplicabilidad del mismo y divisin de prcticas en genricas y especficas). La segunda seccin, estaba orientada a la evaluacin de las prcticas genricas seleccionadas (utilidad de las mismas y aspectos de implementacin) y, finalmente, la tercera seccin dedicada a la evaluacin de las prcticas especficas del modelo (utilidad de las mismas y aspectos de implementacin). Cada una de las secciones, contena preguntas abiertas y cerradas, de modo tal que no slo se pueda evaluar la conformidad del experto para con el modelo sino que
Ing. Hernn A. Turin
147
tambin se le permita al experto poder sugerir modificaciones o mejoras sobre los aspectos evaluados. Finalmente, una vez recibidas las devoluciones de cada experto, se procesaron los resultados de los cuestionarios y se determin la utilidad o no del Modelo de Gestin de Personas propuesto.
6.2-
EXPERTOS SELECCIONADOS
Considerando que la naturaleza del problema abordado en esta tesis est ligada
fundamentalmente a las Tecnologas de la Informacin y a la Gestin de Proyectos, el perfil que deban tener los expertos que realizaran la evaluacin, deba tambin estar orientados a estos dos temas. Del anlisis realizado para definir las condiciones que deba cumplir el perfil de cada experto, se determinaron tres aspectos importantes: Cada experto deba tener ttulo de grado y posgrado (o especializacin) en reas relacionadas con Tecnologas de Informacin o Gestin de proyectos. Esta condicin se considera como obligatoria en la seleccin de los expertos. Cada experto deba tener experiencia en la gestin de proyectos de Tecnologas de la Informacin. Esta condicin tambin era de carcter obligatorio. El experto deba tener conocimientos sobre el PMBOK o certificacin de PMI. Esta condicin no se consider obligatoria para la seleccin de los evaluadores, pero s deseable. A partir de las caractersticas indicadas como necesarias para la seleccin de los expertos que se encargaran de realizar la evaluacin del modelo planteado, se determin que los cuatro evaluadores sern los siguientes:
Experto 1 Ttulo de Grado: Ingeniero Electrnico Ttulo de Posgrado o Especializacin: Magster en Ingeniera en Sistemas de Informacin.
Ing. Hernn A. Turin
148
Experiencia Laboral Relacionada: Ex CEO de Texas Instruments Cono Sur, Verbano S.A. y Fiplasto S.A. Creador dos PyMEs de TI. Docente de posgrado en la Universidad Tecnolgica Nacional. Consultor de Management.
Experto 2 Ttulo de Grado: Ingeniero en sistemas de Informacin Ttulo de Posgrado o Especializacin: Especialista en Ciencias de la Computacin. Experiencia Laboral Relacionada: Ex Director de la carrera de Ingeniera en Sistema de informacin en una Facultad Regional de la Universidad Tecnolgica Nacional. Docente de la carrera de Ingeniera en Sistema de informacin en la Universidad Tecnolgica Nacional. Lder de varios proyectos de desarrollo de software tanto en el mbito pblico como en el privado.
Experto 3 Ttulo de Grado: Ingeniero en sistemas de Informacin Ttulo de Posgrado o Especializacin: Magster en Ciencias de la Computacin con Orientacin en Bases de Datos. Experiencia Laboral Relacionada: Secretario de Informtica en Facultad Ciencias de la Salud de la Universidad nacional de Entre Ros. Encargado de: asesoramiento a la gestin sobre la adquisicin de equipamiento informtico, gestin de los recursos humanos del rea informtica de la facultad (seleccin y coordinacin de actividades relacionadas con proyectos) y gestin de proyectos de S.I./TI
Ing. Hernn A. Turin
149
Docente de la carrera de Ingeniera en Sistema de informacin en la Universidad Tecnolgica Nacional.
Experto 4 Ttulo de Grado: Ingeniero en Informtica Ttulo de Posgrado o Especializacin: PMP Certificado Experiencia Laboral Relacionada: Sr. Manager, Product Development en Teletech S.A.. Ex Docente de grado en Universidad Nacional de La Matanza
6.3-
RESULTADO DE LA EVALUACIN DE LOS EXPERTOS

Del anlisis de los resultados obtenidos a travs de los cuestionarios realizados a
cada uno de los expertos mencionados (Anexos III, IV, V y VI), se pueden obtener las siguientes conclusiones: Modelo Utilizado En cuanto al modelo utilizado para el planteo de la solucin, todos los expertos coincidieron en la estructura seleccionada para el mismo es adecuada y que dicho modelo es aplicable a cualquier tipo de proyecto de TI. Adems todos los expertos coincidieron en que la agrupacin de prcticas en Genricas y Especficas resulta acertada. Slo se recibieron algunas sugerencias para mejorar el mismo, tal como la inclusin de un anlisis ms detallado sobre cmo integrar las diferentes prcticas. Adems se recibe la observacin de que el PMI est reevaluando el PMBOK debido a que no es aplicable a ciertos proyectos de TI, aspecto a tener en cuenta al momento de aplicar el modelo planteado en este trabajo.
Ing. Hernn A. Turin
150
Prcticas Genricas En cuanto a las prcticas Genricas, los expertos concordaron en que el conjunto de prcticas seleccionado es acertada, como as tambin los detalles de implementacin de cada una en los diferentes grupos de procesos de un proyecto. Se recibi la sugerencia por parte de uno de los expertos de agregar Cadena Crtica como prctica genrica a fin de ampliar el conjunto de prcticas propuestas.
Prcticas Especficas En lo que respecta a las prcticas Especficas, nuevamente hubo coincidencia en la evaluacin de los expertos. En este caso todos concordaron en que el conjunto seleccionado es adecuado. Se incorporaron por sugerencia de uno de los expertos, los Diagramas de Gantt y la Estructura Desglosada de Trabajo, la cuales se consideran de gran utilidad en la administracin de proyectos. Por otro lado, tambin se recibi la sugerencia de que, solo a modo de mejora, se podra incluir alguna otra prctica relacionada con la comunicacin interpersonal.
De acuerdo a los resultados obtenidos, se pudo determinar el Modelo de Gestin de Personas planteado en el presente trabajo de tesis, es factible de ser utilizado en forma exitosa en la administracin de proyectos de TI. Adems, en todos los casos se observ que hay inters por parte de los expertos en poder adaptar el modelo para hacerlo aplicable a cualquier tipo de proyecto. Esto demuestra que su aplicacin no es solo factible sino que tambin resulta de gran utilidad e importancia.
Ing. Hernn A. Turin
151
CAPITULO
VII
CONCLUSIONES
7.1-
ASPECTOS GENERALES
Siempre que se analiza cules son los factores claves de xito en un proyecto se
mencionan aspectos relacionados con costos, tiempo y prestaciones, y se enfocan todos los esfuerzos en mejorar la administracin de estos tres factores. Si bien este enfoque es correcto, existe un cuarto factor igualmente importante y que tiene gran influencia en la finalizacin del proyecto, este factor es el constituido por las personas y se lo denomina como el factor humano. El factor humano tiene la particularidad de que no slo en el resultado final del proyecto, sino que adems es una variable transversal al presupuesto, el tiempo y las prestaciones. Esto es debido a que cada una de las actividades es ejecutada por personas y que depende de stas que se cumplan o no con los objetivos fijados para cada uno de los otros tres factores. En la actualidad existen algunas metodologas de desarrollo giles, aplicadas al desarrollo del software, que incorporan en mayor o menor medida muchos de los conceptos relacionados con el manejo de las personas. Pero lo cierto es que todas estas metodologas proporcionan un enfoque incompleto del problema ya que lo que proponen muchas veces no es aplicable a otros proyectos de IT o a proyectos de gran tamao. Adems, los estndares definidos para la administracin de proyectos presentan el tema de la administracin de las personas pero no brindan detalles acerca de tcnicas a utilizar, y por ello muchas veces es muy difcil de implementar un manejo correcto del factor humano. En el presente Modelo de Gestin de Personas se combin uno de los estndares mas utilizados en la administracin de proyectos, como lo es el PMBOK, con las tcnicas que aplican algunas metodologas giles de desarrollo referidas al anejo de personas y otras tcnicas obtenidas a travs de la experiencia del autor del presente trabajo. A partir de esto se obtuvo un esquema de Mejores Prcticas aplicables a cada uno de los grupos de procesos que conforman un proyecto. Para ello se definieron dos grupos de prcticas: prcticas genricas y prcticas especficas. Dentro del grupo de las prcticas genricas estn aquellas que, por sus caractersticas y utilidad, son aplicables a cualquiera de los grupos de procesos de un proyecto de TI, mientras que las prcticas especficas son slo aplicables a ciertos grupos de procesos en particular. A partir de esto se defini un esquema de aplicacin de prcticas por grupos de procesos donde, a partir del anlisis de las necesidades de cada grupo se defini que
Ing. Hernn A. Turin
155
prcticas aplicar. Adems se estudiaron las particularidades a tener en cuenta en la aplicacin de las mismas segn el grupo de procesos en que se utilizan. De este modo se obtuvo una gua muy fcil de entender y de aplicar por parte de los lderes de proyecto y que permite lograr una mejor administracin del grupo de personas involucradas en el proyecto y as encaminar el proyecto hacia una finalizacin exitosa. Finalmente, la evaluacin a travs del juicio de expertos arroj resultados muy positivos en lo que respecta al modelo planteado. Esto permiti verificar que el modelo es factible de ser implementado en la gestin de personas en los proyectos de TI. Adems se pudo determinar un inters por parte de los expertos en la ampliacin del conjunto de prcticas presentadas, de modo que se puedan incluir nuevas prcticas que permitan adaptar el modelo a todo tipo de proyectos.
7.2-
CUMPLIMIENTO DE LOS OBJETIVOS PLANTEADOS

A continuacin se analizar cada uno de los objetivos planteados para el
presente trabajo de tesis y el cumplimiento de los mismos a lo largo de todo el desarrollo del presente: Especificar las caractersticas de la Gestin del Factor Humano en proyectos de TI. Para poder determinar las caractersticas ms importantes de la Gestin del Factor Humano en los proyectos de TI, en el Captulo II del presente trabajo de tesis, se analizaron todos aquellos aspectos relacionados con esta clase de proyectos. En primer lugar se estudi la evolucin de los conceptos relacionados con la administracin de personas a lo lago de la historia en las administraciones. Finalmente, se estudiaron las caractersticas especficas de los proyectos de TI y los factores relacionados con las personas que influyen en el xito o el fracaso de los mismos (como por ejemplo las habilidades del lder y la resistencia al cambio).
Analizar los diferentes modelos utilizados para la gestin de personas en los proyectos de TI.
Ing. Hernn A. Turin
156
Para cumplir con este objetivo, en el Captulo II se realiz el estudio algunas metodologas y tcnicas que implementan conceptos importantes en cuanto al manejo de personas. La mayora de ellas relacionadas con el desarrollo de software, aunque tambin se analiz un estndar utilizado para la gestin de proyectos, como lo es el PMBOK. Finalmente, en el Captulo III, se plante el impacto sobre las personas de los proyectos de desarrollo de software y se mencionaron algunos tems importantes a considerar en estos casos.
Definir el alcance y las limitaciones de cada una de las prcticas utilizadas en cada modelo. En este caso, en los Captulos IV y V, se plante un modelo compuesto por un grupo de prcticas que se dividen en genricas y especficas, analizando las caractersticas de cada una y las ventajas de su aplicacin en la gestin del factor humano en los proyectos de TI.
Elaborar un modelo de mejores prcticas de acuerdo a cada una de las etapas de un proyecto de TI. Para este punto, en el captulo V se propuso, en primer lugar una estructura para la administracin de proyectos basada en el PMBOK. Esta estructura divide al proyecto en cinco grupos de procesos en los cules pueden ser aplicadas las prcticas seleccionadas. Para finalizar, se plante un esquema en el cul se propone cules de las prcticas analizadas son aplicables en cada uno de los grupos de procesos y que consideraciones se debern tener en la aplicacin de cada una de ellas.
Evaluar el modelo obtenido y analizar los resultados. Para la validacin del modelo, en el captulo VI, se propuso la evaluacin del mismo a travs del Juicio de Expertos. Se defini el perfil bsico que debe cumplir cada experto y se seleccion 4 de ellos para cumplir con el proceso de evaluacin. Este proceso consisti en enviar un extracto del modelo a cada experto, acompaado de un cuestionario. Dicho cuestionario permiti obtener las respuestas necesarias para determinar si el experto considera que el modelo es o no aplicable en forma exitosa a la gestin de un proyecto de TI.
Ing. Hernn A. Turin
157
Finalmente se analizaron las respuestas obtenidas y se determin la viabilidad en la implementacin del modelo propuesto y de analizaron posibles mejoras en el mismo.
7.3-
LNEAS DE INVESTIGACIN FUTURAS

A partir del presente trabajo de tesis, existen aspectos que quedan fuera del
alcance planteado y que forman parte de las lneas de investigacin futuras. Entre ellas las ms importantes son: Aplicacin dentro del modelo de tcnicas relacionadas con la motivacin de los equipos de trabajo, tales como los Programas de Calidad de Vida en el Trabajo. Ampliacin del campo de estudio de la presente tesis, para su aplicacin en cualquier tipo de proyectos. Profundizacin del estudio del presente modelo para determinar la conveniencia o no de aplicar ciertas tcnicas de administracin de personas de acuerdo con el tipo de proyecto. El estudio de las diferentes plataformas en las cuales se pueden integrar las distintas tcnicas mencionadas en el presente trabajo (redes sociales y/o plataformas colaborativas).
Ing. Hernn A. Turin
158
CAPITULO
VIII
BIBLIOGRAFIA
[Abran, 2001] Abran A.; Desharnais J. M.; Oligny S.; St-Pierre D. & Symons Charles S., COSMIC FFP Manual de Medicin Versin 2.1, Common Software
Measurement International Consortium, 2001 [lvarez, 2001] lvarez, R., Echange, el Lado Humano de la Economa Digital. Ediciones Granica, 2001 [Beck, 1999] Beck, K., Extreme Programming Explained. Editorial Addison Wesley, 1999. [Beckhard, 1998] Beckhard, R. & Reuben, H., Transiciones organizacionales: Administracin del cambio. Editorial AddisonWesley Iberoamericana, 1998. [Boehm, 2000] Boehm, B.; Abts, C.; Winsor Brown, A.; Chulani, S.; Clark, B.; Horowitz, E.; Madachy, R.; Reifer, D. & Steece, B., Software cost estimation with COCOMO II. Editorial Prentice Hall, USA, 2000. [Burke, 2006] Burke, R.; Kenney, B.; Kott, K & Pflueger, K. Success or Failure: Human Factors in Implementing New Systems. Educause, Article 0152, 2001 [Caldera Meja, 2004] Caldera Meja, R., Conceptos y Teora Sobre Planeacin Efectiva de Recursos Humanos. Editorial Estrategika-Consultoria, 2004 [Chiavenato, 2003] Chiavenato, I., Introduccin a la Teora General de la Administracin. Editorial McGraw-Hill Latinoamericana S.A., 2003. [Cuevas Agustn, 2003] Cuevas Agustn, G.; de Amescua Seco, A., Gestin del Proceso del Software. Editorial Ramn Areces, 2003. [Cummings, 2007] Cummings, T.; Worley, C., "Desarrollo Organizacional Y Cambio". Cengage Learning Editores, 2007 [Dickson, 2003] Dickson, W. & Roethlisberger F., Management and the Worker. Editorial Routledge, 2003. [Ebersbach, 2006] Ebersbach, A.; Glaser, M.; Heigl, R. & Dueck, G., Wiki Web Collaboration. Editorial Springer, 2006. [Fayol, 1985] Fayol, F., Administracin industrial y general. Ediciones Orbis, 1985. [Garca, 2001] Garca, G. & Rangel, J., Resistencia al Cambio Tecnolgico en las organizaciones durante el desarrollo de un sistema de informacin en el rea de Recursos Humanos. Universidad Catlica Andrea Bello, 2001.
Ing. Hernn A. Turin
161
[Gurmendi, 2006] Gurmendi, L.; Williams, R. , Desarrollo Informtico Colaborativo en el Sistema Universitario: La Experiencia SIU-Guarani. Buenos Aires 2006. [Herzberg, 1993] Herzberg, F. & Bloch Snyderman, B., The motivation to work. Editorial Transaction Publishers, USA, 1993. [Hiebeler, 2000] Hiebeler, R., Las Mejores Prcticas. Editorial Gestin, 2000. [IEEE, 2004] IEEE Std. 1490-2003, Adoption of PMI StandardA Guide to the Project Management Body of Knowledge. IEEE Standars Association, 2004. [ISO, 2000] ISO, ISO9001:2000 Sistemas de Gestin de Calidad. Requisitos. ISO, 2000 [ISO/IEC, 2003] ISO/IEC, ISO/IEC 20926:2003 - Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual. ISO/IEC, 2003 [ISO/IEC, 2005], ISO/IEC, ISO/IEC 20000-1 - Information Technology - Service management - Part 1: Specification, ISO/IEC, 2005 [ISO/IEC, 2007] ISO/IEC, ISO/IEC 14143-1:2007 Information technology - Software measurement - Functional size measurement - Part 1: Definition of concepts. ISO/IEC, 2007. [ISO/IEC, 2008] ISO/IEC, ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes, ISO/IEC, 2008 [Kelly, 1999] Kelly, K., Tcnicas para la Toma de Decisiones en Equipo. Ediciones Granica, 1999 [Kendall, 1997] Kendall, K. & Kendall, J. Anlisis y Diseo de Sistemas. Editorial Pearsona Addison Wesley, 2005 [Lagrange, 1983] Lagrange, J., Resistencia al Cambio Tecnolgico. Edicion UCAB, 1983. [Maslow, 1991] Maslow, A., Motivacin y personalidad. Ediciones Daz de Santos, 1991. [Matsushita, 1993] Matsushita, Konosuke, Claves para un Buen Gerente. Editorial PHP Institute, 1993.
Ing. Hernn A. Turin
162
[Mayo, 2003] Mayo, E., The Political Editorial Routledge, 2003.
Problems in an Industrial Civilization.
[McGregor, 2007] McGregor, D., El lado humano de las empresas. Editorial McGraw Hill, 2007. [Monden, 1998] Monden, Y. Toyota Production System: An Integrated Approach to Just - In -Time. Engineering and Management Press, USA, 1998 [NESMA, 2001] NESMA, Function Point Analysis for Software Enhacement. Netherlands Software Metrics Users Association, 2001 [Norman, 2008] Norman, E; Brtotherton, S. & Fried, R., Work Breakdown Structures: The Foundation For Project Management Excellence. John Willey & Sons, 2008. [Pichn-Riviere,1999] Pichn-Riviere, E., El Proceso Grupal. Editorial Nueva Visin, Buenos Aires, 1999 [PMI, 2004] Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute, 2004. [Quintero, 2005] Quintero, M., Evaluacin del Impacto de los sistemas de Informacin En el desempeo Individual del Usuario. Aplicacin en Instituciones Universitarias. Tesis Doctoral. [R.A.E.,2007] Real Academia Espaola, Diccionario de la Lengua Espaola. Editorial Espasa Calpe, 2000. [Salinas, 1975] Salinas, Alberto, La Reforma Administrativa. Editorial FCE Mxico, 1975. [Salomn, 2003] Bravo Salomn, L., El Factor Humano y el xito en la Gerencia de Proyectos. Editorial Fundacin Diego de Sagrado, 2003. [Schwaber, 2004] Schwaber, K., Agile Project Management with Scrum. Microsoft Press, 2004. [Senn, 1992] Senn, James A., Anlisis y Diseo de Sistemas de Informacin. Editorial McGrawHill, 1992. [Sommerville, 2005] Sommerviile, I., Ingeniera del Software, Editorial Pearson Educacin, 2005
Ing. Hernn A. Turin
163
[Soto, 2004] Soto, E., Comportamiento Organizacional - Impacto De Las Emociones. Thomson Editores, 2004. [Standish Group, 1995] Standish Group, Chaos Report. Educase, Article 08083B, 1995 [Taylor, 2005] Taylor, F., The Principles of Scientific Management. Editorial Adamant Media Corporation, 2005. [UKSMA, 1998] UKSMA, MKII Function Points Analysis Counting Practices Manual. United Kingdom Software Metrics Association, 1998 [Wake, 2000] Wake, W., Extreme Programming Explored. Editorial Addison-Wesley, 2000. [Wenger, 1998] Wenger, E., Communities of Practice: Learning, Meaning, and Identity. Cambridge University Press, 1998. [Winston, 2005] Winston, W., Investigacin de Operaciones: Aplicaciones y Algoritmos. Cengage Learning Editores, 2005. [Wood, 1995] Wood, J. & Silver, D., Joint Application Development. Editorial John Willey & Sons, 1995. [Wong, 2007] Wong, Z., In Human Factors in Project Management. Editorial John Wiley & Sons, 2007.
Sitios WEB: http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html http://www.softwaremetrics.com/freemanual.htm http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm http://www.rrhhblog.com/2008/08/23/tipos-de-tecnicas-iii/ http://www.cosmicon.com/ http://www.ifpug.org/ http://www.carolla.com/wp-jad.htm http://www.programacionextrema.org/ http://es.wikipedia.org/wiki/Foro_(Internet) http://www.elmundo.es/nuevaeconomia/index.html
Ing. Hernn A. Turin
164
CAPITULO
IX
ANEXOS
9.1-
ANEXO I - EXTRACTO DEL MODELO ENVIADO A LOS EXPERTOS
INTRODUCCIN
En el presente captulo se expone como solucin al problema planteado, un Modelo de Gestin de Personas aplicable a los diferentes tipos de proyectos de TI. Lo que se propone es la aplicacin de diferentes tcnicas de gestin de personas dentro de una estructura de administracin de Proyectos. Las tcnicas que se implementarn son todas aquellas relacionadas con motivacin de equipos de trabajo, gestin de las relaciones interpersonales dentro de un equipo, relacin con los clientes y manejo de la asignacin y distribucin de los recursos. La idea es poder aprovechar al mximo las ventajas y beneficios de cada una de estas tcnicas, adaptndolas a cada momento del proyecto cuando se lo requiera. Por otro lado, se plantea la utilizacin de un modelo de administracin de proyectos reconocido y ampliamente utilizado en el mbito de la gestin de proyectos, tal como lo es el PMBOK. Este modelo plantea un conjunto de conocimientos que permiten dirigir un proyecto, y que est basado en la experiencia obtenida en diferentes casos y empresas. La idea es combinar por un lado un estndar reconocido de administracin de proyectos, que funcione como estructura para comprender las etapas o fases del proyecto, y por el otro proponer el uso de las diferentes tcnicas de acuerdo al momento del proyecto en que se encuentre. Las prcticas se clasificarn de acuerdo a si as mismas son utilizables en cualquier instancia del proyecto o si solamente son aplicables en algn momento en particular. De este modo se establecern dos grupos de prcticas: Prcticas Genricas y Prcticas Especficas. Finalmente se indicar como se debe implementar cada tcnica en cada grupo de proceso definido en la estructura del proyecto, y las consideraciones particulares que se debern realizar para poder llevarlo a cabo.
ESQUEMA SELECCIONADO
Para poder abordar y llevar adelante el planteo propuesto en el captulo anterior, es necesario primero definir cul ser el esquema / estndar de administracin de proyectos que se utilizar como gua para identificar las actividades relacionadas con la
Ing. Hernn A. Turin
167
administracin del factor humano. En este sentido, se considera que la metodologa ms completa de las conocidas y utilizadas actualmente, es aquella propuesta por el Project Management Institute (PMI): El PMBOK (Project Management Body of Knowledge). El PMBOK, como ya se analiz anteriormente, provee un estndar para la direccin de proyectos que est estructurado en cinco de procesos bsicos y nueve reas de conocimientos que son comunes prcticamente a todos los proyectos. La eleccin de este estndar se basa en que representa un conjunto muy actual y sumamente amplio de conocimientos que resultan de la experiencia, el estudio y el desarrollo de proyectos. Lo interesante de este esquema es que su finalidad no es exponer disciplinas, herramientas y tcnicas aplicables a la gestin de proyectos sino proveer de un grupo seleccionado de ellas y que son consideradas como buenas prcticas. Esto permite que se pueda encuadrar en su esquema todas aquellas tcnicas y herramientas relacionadas con la administracin del factor humano que influyen en la administracin de un proyecto. Por otra parte, el grupo de conocimientos del PMBOK se encuentra distribuido entre los miles de colaboradores alrededor del mundo y es por esta razn que no se lo presenta como un manual con pasos a seguir para culminar un proyecto en forma exitosa. Para el planteo de la solucin propuesta al problema abordado en el presente trabajo, se tomar como base esta estructura y dentro de ella es que se organizarn las tcnicas y herramientas propuestas como mejores prcticas.
MODELO DE GESTIN PROPUESTO

La solucin al problema presentado se estructurar de modo que, en primer lugar se analizarn las Prcticas Genricas. Estas prcticas se denominan genricas debido a que se podrn aplicar en cualquiera de los grupos de procesos del proyecto, variando simplemente algn aspecto en particular para poder adaptarla mejor cada grupo. Luego se presentarn las que se denominarn Prcticas Especficas. ste grupo de prcticas son aquellas que slo tienen aplicacin en algn grupo de procesos en particular pero no al resto de los grupos. Luego se analizar en detalle las necesidades de cada uno de los grupos de proyectos del PMBOK desde el punto de vista de la administracin del factor humano, para finalmente poder especificar el esquema final de prcticas aplicadas a cada grupo. En la Figura 6 se puede visualizar el esquema planteado para el desarrollo de la solucin.
Ing. Hernn A. Turin
168
Figura 6 Representacin grfico del esquema de la solucin planteada.
Ing. Hernn A. Turin
169
APLICACIN DE PRCTICAS A LAS DIFERENTES FASES DE UN PROYECTO Finalmente en esta seccin se presentar cmo se relaciona cada una de las prcticas definidas en las dos secciones anteriores con las diferentes fases de un proyecto de TI. En la Tabla XII se muestra un esquema en el cual se sintetiza cual es la aplicabilidad de cada tcnica segn la fase del proyecto en que se encuentre.
Inicio Reuniones Wikis Foros de discusin Listas de Correo Mensajera Instantnea Comits de Desarrollo Programacin de a Pares Comits de Usuarios Grupos de Apoyo Mesa de Ayuda CPM PERT COCOMO Puntos de Funcin Grupo Nominal Delphi Anlisis Estadstico X X X X X
Planificacin X X X X X
Ejecucin X X X X X X X X
Control X X X X X
Cierre X X X X X
X X X
X X X X X X X
X X X X
Tabla XIII Esquema de prcticas por fases del proyecto
En general se ve claramente que las prcticas que se definieron como genricas son aplicables a casi todas las fases de un proyecto, mientras que las especficas solo se aplican a una o dos etapas.
Ing. Hernn A. Turin
170
A continuacin se detallarn, para cada uno de los grupos de procesos de un proyecto, cul es su objetivo, necesidades y las tcnicas aplicables de acuerdo a lo definido en la Tabla XIII. Adems se analizarn las particularidades de la aplicacin de cada tcnica de acuerdo a los requerimientos de la fase analizada.
INICIACIN 1- Tcnicas a utilizar: De acuerdo al objetivo del grupo de procesos y de las necesidades detectadas en el mismo respecto de la administracin del factor humano, en la Tabla XIII se indican como aplicables las Reuniones, Foros de Discusin, Listas de Correo, Mensajera Instantnea y Puntos de Funcin.
Reuniones En este caso particular es importante que se tomen en cuenta y se le preste mucha atencin a todas las opiniones y sugerencias de cada uno de los participantes, se analicen y finalmente se determinen si influirn o no en el objetivo y alcance del proyecto. Otro aspecto en el que se debe poner atencin, en la preparacin y posterior ejecucin de la reunin, es el lugar fsico donde se realizar el encuentro y la disposicin de cada uno de los participantes. En cuanto al lugar que de encuentro, es conveniente que sea un lugar con buena luz, silencioso y donde no existan interrupciones por parte de terceros. Es conveniente que se cuente con material de apoyo necesario para poder expresar los conceptos. En este sentido es importante contar con pizarrn, marcadores, proyectos y PC, ya que de esta forma se puede desplegar una amplia gama de tcnicas para transmitir los conceptos y lograr que los mismos queden claros. En lo que refiere a la disposicin de los participantes, en las reuniones de iniciacin de proyecto el nmero de integrantes suele ser reducido, no ms de 4 o 5 personas, por lo cual es conveniente que se realice en una mesa redonda, donde todos puedan verse y donde no haya mucha distancia entre las personas, de modo que todos puedan escucharse mutuamente. Otro de los aspectos que no se debe descuidar es el armado del proceso de facilitacin. Nunca se debe olvidar que la mayora de las reuniones no fracasa por un mal armado de la agenda sino por la ausencia o pobreza en el proceso de facilitacin de la misma.
Ing. Hernn A. Turin
171
La reunin debe comenzar con una breve presentacin de cada uno de los participantes (en caso de ser necesario) y luego una introduccin que estar a cargo de quien es el facilitador de la reunin. En dicha presentacin se explicar el tema que se tratar en el encuentro y para dicha explicacin, el facilitador se puede valer de transparencias, grficos, cuadro, videos o cualquier otro elemento que se considere til para facilitar la comprensin del tema. Cada vez que sea necesario comenzar con la discusin de un nuevo tema, se debe tener en cuenta las tcnicas presentadas anteriormente para iniciar un debate. Es conveniente adems, que haya un encargado de documentar todo lo que se discute en la reunin, de modo que queden plasmadas las diferentes opiniones expuestas, lo que luego ser de gran utilidad para poder elaborar las conclusiones de la reunin. Respecto de las conclusiones, se deben tener
siempre presentes las tcnicas para cerrar debates. Una vez finalizada la reunin se debe confeccionar una memoria con las conclusiones y acuerdos alcanzados durante la misma y repartir dicho documentos entre todos los participantes a modo de recordatorio de los acuerdos realizados y los pendientes (si es que existieran). Siempre se debe tener en cuenta que la duracin de una reunin es un factor que influye en los resultados de la misma. En el caso de las reuniones que se realizan durante los procesos de iniciacin, hay que tener en cuenta que los principales implicados son miembros de la alta gerencia de la organizacin, por lo cual se debe evitar quitarles demasiado tiempo ya sea por una reunin extensa o por una cantidad excesiva de reuniones. Antes de convocar hay que analizar si realmente el tema justifica la realizacin de la misma o si es algo que, o bien se puede solucionar por otros medios o bien se puede aplazar para tratarlo en otro encuentro junto con otros temas. Hay que tener muy presente que una buena comunicacin es fundamental para lograr una reunin de trabajo exitosa, es por ello que hay algunos puntos que son importantes para mejorar la comunicacin, dentro de ellos los ms importantes son: Las palabras tienen diferentes significados para las personas. La comunicacin no solo es verbal, sino que adems tiene un componente no verbal.
Ing. Hernn A. Turin
172
Foros de Discusin De acuerdo al funcionamiento de esta herramienta, se puede crear un foro en la cual los involucrados en el grupo de procesos puedan realizar sus consultas y evacuar todas las dudas sin necesidad de realizar una reunin para ello. Adems, como las consultas son pblicas pueden ser vistas por todos los
participantes se cuenta con la facilidad de que cada uno puede dejar su comentario/sugerencia respecto de un tpico en particular. Otra de las ventajas que tienen los foros es que son relativamente fciles de utilizar y no se requieren grandes conocimientos de informtica para ello, con lo cual, si alguno de los involucrados no posee demasiados conocimientos de informtica, no tendr mayores inconvenientes para utilizarlos. Esta herramienta es particularmente til cuando los involucrados en la iniciacin del proyecto no se encuentran en locaciones geogrficas muy distantes, donde la organizacin de una reunin requiere de un tiempo considerable e implica la necesidad de que los asistentes tengan que recorrer distancias considerables para participar de la misma.
Listas de Correo A diferencia de los foros de discusin, las listas de correos hacen que los mensajes que se envan a las mismas lleguen directamente a la casilla de correo electrnico de cada uno de los integrantes de dicha lista. De esta manera se elimina la necesidad de que cada persona deba ingresar especficamente al foro para verificar si existen mensajes nuevos. Aplicadas al grupo de procesos de iniciacin, las ventajas de las listas de correos son prcticamente las mismas que los foros de discusin, es decir: agilizar la circulacin de informacin, realizar discusiones sobre ciertos tpicos sin necesidad de una reunin y evacuar las dudas que se generen. Adems tambin son muy tiles en caso de que haya involucrados en locaciones geogrficas muy distantes.
Ing. Hernn A. Turin
173
Mensajera Instantnea En el caso particular de la iniciacin de un proyecto, la mensajera instantnea resulta sumamente til cuando se deben resolver temas urgentes donde no hay tiempo de organizar una reunin, de modo que se puede iniciar una conferencia de voz donde todos puedan participar de la discusin y resolver el tema con mayor celeridad. Pero por otro lado requiere de algunos conocimientos ms de informtica de los involucrados aunque en la actualidad esta herramienta ha adquirido mucha popularidad llegando a ser en muchos casos de uso corporativo. De todos modos lo recomendable es que el uso de esta herramienta en el grupo de procesos de iniciacin vaya siempre acompaada del uso de al menos o una lista de correo o un foro de discusin.
Puntos de Funcin El uso de esta tcnica durante la iniciacin de un proyecto esta orientada especficamente a la obtencin de una primera aproximacin del tiempo necesario para llevar a cabo el proyecto y del costo aproximado del mismo. Como se analiz con anterioridad, esta tcnica permite, con algunos datos relacionados al proyecto, obtener una estimacin del tamao del proyecto y, por consiguiente, del tiempo necesario para ejecutarlo y de su costo. Si bien en este grupo de procesos no se cuenta con demasiados detalles acerca del proyecto, se puede obtener la informacin mnima a indispensable para realizar un primer clculo y de esta manera obtener un valor (en puntos de funcin) que permita armar un presupuesto y determinar aproximadamente la duracin del mismo. Siempre se debe tener en cuenta que los resultados que se obtengan carecern de precisin debido al momento temprano del proyecto en que se aplica, peor al menos permite tener una gua para poder comenzar la discusin con las partes interesadas en el proyecto.
PLANIFICACIN 1. Tcnicas a utilizar: Si se analiza el objetivo del grupo de procesos de planificacin y las necesidades planteadas en el mismo, se determina que las
Ing. Hernn A. Turin
174
tcnicas a utilizar en la administracin del factor humano son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, COCOMO, Puntos de Funcin, CPM, PERT, Tcnica de Grupo Nominal, Tcnica Delphi y Anlisis Estadstico.
Reuniones En el momento de realizar la planificacin de un proyecto, las reuniones son una tcnica que tiene especial utilidad en la recopilacin de informacin de diferentes fuentes. Esta informacin es importante para poder hacer una planificacin confiable y exacta. En este caso son aplicables la mayora de los tems mencionados para las reuniones que se llevan adelante durante la iniciacin, especialmente aquellos relacionados con la administracin de los espacios fsicos y la disposicin de los participantes. La diferencia radica en que, en este caso, es que los asistentes pertenecen a reas operativas de la organizacin, es decir, que son los futuros usuarios del producto final. El hecho de que quienes asistan a las reuniones sean los futuros usuarios del producto o los responsables de las reas impactadas por el mismo radica en la necesidad de obtener informacin exacta y relevante. Esta informacin es necesaria para conocer los aspectos especficos relacionados tanto con los procesos como los procedimientos que sern afectados por el proyecto. De aqu es que se hace necesaria la asistencia de personas con conocimientos de dichos procesos y procedimientos. Este tipo de reuniones se denominan Reuniones de Relevamiento. Las reuniones de relevamiento son encuentros focalizados en el objetivo principal de obtener informacin acerca de ciertos temas en particular. En el caso de los proyectos de TI, estas reuniones tienen dos objetivos: comprender las necesidades de informacin de las reas involucradas y comprender los procesos / procedimientos afectados por el proyecto. En este tipo de reuniones, el facilitador debe tener en claro cuales son los procesos, procedimientos y reas afectadas, de modo que se pueda dirigir el encuentro y guiarlo hacia el cumplimiento de las metas de recopilacin de informacin. En cuanto a la cantidad y el tipo de asistente de las reuniones de relevamiento, se puede decir que variar de acuerdo con el
proceso/procedimiento y las reas. En el caso de procesos/procedimientos que

Ing. Hernn A. Turin
175
involucran a ms de un rea, es conveniente que asistan entre uno y dos representantes de cada rea. La idea es poder comprender todo le circuito, detectar las necesidades de informacin de cada afectado e incluso determinar los casos en que desde lugares diferentes se requiere la misma informacin. Adems en estas reuniones se pueden determinar los circuitos administrativos y detectar las mejoras que pueden realizarse en los mismos (se debe tener presente que los proyectos de TI no solo involucran tecnologa y software sino tambin procedimientos administrativos realizados por personas). Finalmente se puede concluir diciendo que para las reuniones de relevamiento es necesario: Identificar el/los procesos/procedimientos a relevar. Identificar las reas afectadas por los mismos. Identificar las reas que requieren informacin de los mismos. Identificar los actores claves de cada rea. Focalizar el encuentro en lograr la obtencin de informacin con el mayor grado de exactitud posible y que resulte relevante para las necesidades del proyecto.
Wikis En el caso de la planificacin de un proyecto, las wikis tambin se transforman en una herramienta til. Las mismas permiten dar soporte a las actividades que en este grupo de procesos se realizan y que tienen relacin con la administracin del factor humano. Dado que la recopilacin de informacin y la generacin de documentos tales como el cronograma de actividades y
precedencias, las wikis cobran utilidad al momento de compartir esta informacin. Desde el punto de vista de la administracin del factor humano dentro de un proyecto de TI, las wikis permiten lograr una mayor agilidad en las comunicaciones y tambin fomentar la participacin de los usuarios, ya que quienes tengan permiso para hacerlo pueden comentar y/o modificar un contenido de modo que se enriquece el mismo. La nica limitacin que puede presentarse en esta herramienta, y que debe ser considerada, es que es necesario que para editar un tema los usuarios deben tener ciertos conocimientos mnimos. Es por ello que se recomienda el
Ing. Hernn A. Turin
176
uso de la Wiki solo para grupos o comunidades de personas que estn altamente involucrados en el proyecto y que, por lo tanto, cuentan con los conocimientos necesarios para la utilizacin de la Wiki.
Listas de Correo En el caso de las listas de correo, su implementacin y utilidad dentro del grupo de procesos de planificacin es bsicamente el mismo que para la iniciacin de un proyecto. Esto se puede resumir en los siguientes puntos: Proveer mayor dinamismo en las comunicaciones. Permitir distribuir en forma muy sencilla y rpida documentos generados por los procesos de planificacin. Proveer una herramienta simple y accesible para todos los involucrados. Facilitar el intercambio de opiniones acerca de ciertos tpicos cuando los involucrados en la discusin se encuentran en locaciones geogrficas muy distantes.
Mensajera Instantnea El caso de las ventajas de mensajera instantnea aplicada al grupo de procesos de planificacin tambin es coincidente con el grupo de procesos de iniciacin. Es decir que nuevamente se trata de agilizar las comunicaciones de modo que, cuando los interesados estn en lnea, se pueden resolver en pocos minutos ciertas cuestiones que de otra manera tomaran mayor tiempo. Al estar frente a una herramienta que tiende a ser de uso corporativo en muchas organizaciones, su aplicacin tiene un costo muy bajo y redunda en grandes mejoras en la comunicacin. En cuanto a las restricciones e inconvenientes, se deben considerar los mismos aspectos mencionados en la iniciacin, es decir que se recomienda que su aplicacin vaya acompaada de otra herramienta tal como las listas de correos o los foros de discusin.
Puntos de Funcin Desde el punto de vista de la administracin de las personas dentro de un proyecto, los puntos de funcin tienen importancia debido a que cuanto mas
Ing. Hernn A. Turin
177
exacta sea la estimacin de tiempos, mejor ser la distribucin del equipo y se llegar con mayos tranquilidad a la finalizacin del proyecto. Pero se debe considerar que, para que esta tcnica resulte ms eficiente en la administracin de personas, es conveniente contar con una base de conocimientos de proyectos anteriores. Esto se debe a que no todos los equipos realizan las mismas tareas en iguales tiempos, por lo cual es conveniente que se cuente con antecedentes de proyectos. De este modo se pueden tomar como base de clculo aquellos antecedentes de proyectos similares que hayan sido desarrollados con equipos de similares caractersticas y obtener una aproximacin de mayor exactitud.
COCOMO Nuevamente, la utilidad de COCOMO (al igual que los Puntos de Funcin) en la administracin del factor humano dentro de un proyecto est dada por la informacin que provee para la organizacin del equipo del proyecto. Siempre que se obtiene una estimacin del tamao de un proyecto, se puede realizar el clculo aproximado de las horas/hombre necesarias para llevar adelante el mismo. Si estas estimaciones son certeras, la distribucin del equipo en cada tarea ser adecuada y permitir que las personas trabajen sin las presiones que se generan cuando los tiempos se estiman mal y se deben dedicar ms horas de las que se haban planificado para cada persona.
CPM Una de las necesidades del grupo de procesos de planificacin, es poder tener una visin clara de cules son las actividades que se debern realizar dentro del proyecto, la secuencia de las mismas, sus dependencias y la duracin de cada una. Es en esto donde el Mtodo del Camino Crtico (CPM) cobra relevancia y utilidad ya que permite visualizar muy fcilmente la distribucin y dependencia de cada una de las actividades de modo que su anlisis resulta muy sencillo. Adems con dicha distribucin se puede tener una visin mas acertada de cmo debern distribuirse el equipo dentro del proyecto. Es en este sentido donde su aplicacin es importante al momento de administrar el factor humano ya que permite detectar sobrecarga de trabajo sobre algunas personas y holguras en otras.
Ing. Hernn A. Turin
178
PERT. El uso de PERT. como una tcnica importante en la administracin de las personas involucradas en un proyecto de TI, tiene la misma utilidad que las mencionadas para CPM Esto significa que la ventaja principal de su uso est asociada a la visibilidad de la distribucin de las tareas y los tiempos dentro del proyecto. De esta forma se puede determinar cules sern las tareas que marcarn el camino crtico del proyecto, de modo que se brinde mayor atencin a como se asignan las personas a las tareas que forman dicho camino. Por otro lado se pueden detectar tems como la holgura de una tarea, de modo que se puede manejar de modo eficiente la asignacin de personas, evitando que stas tengan perodos prologados sin actividad dentro del proyecto, lo cual puede causar desmotivacin o frustracin. En comparacin con CPM, la ventaja de PERT. es que es probabilstico y que, al considerar al tiempo como una variable desconocida, puede resultar es una distribucin ms realista de los tiempos.
Tcnicas de Grupo Nominal y Delphi La aplicacin de este tipo de tcnicas durante el grupo de procesos de planificacin tiene como objetivo dar soporte a todas las actividades relacionadas con la planificacin de los recursos humanos. En todo proyecto es fundamental la determinacin de la cantidad de personas que sern necesarias para llevar adelante el mismo. En algunos casos, la cantidad de personas disponibles es conocida de antemano y por tanto tenida en cuenta para la planificacin y estimacin de tiempos. Pero en otros casos, se desconoce la cantidad de personas con que se contarn y, por consiguiente, se deber contar con una estimacin de los recursos necesarios. Es en este punto donde estas dos tcnicas cobran importancia. Ambas tcnicas se basan en la experiencia de las personas que participan, de modo que es importante realizar una correcta seleccin de quienes estarn involucrados en las mismas.
Ing. Hernn A. Turin
179
Anlisis Estadstico La importancia de su implementacin radica en que, al utilizarse informacin histrica de la organizacin, la prediccin es ms cercana a la realidad. Adems puede ahorrar tiempo en las estimaciones aunque, como contrapartida, posee la desventaja de ser ms compleja y requerir ciertos conocimientos previos para poder aplicarla.
EJECUCIN 1. Tcnicas a Utilizar: Considerando las necesidades planteadas para este grupo de procesos, se determina que las tcnicas a utilizar son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, Comits de Desarrollo, Programacin de a Pares y Comits de Usuarios.
Reuniones En el caso de las reuniones aplicadas al grupo de procesos de desarrollo, permite realizar un anlisis ms detallado y exhaustivo acerca de las formas de aplicacin de las mismas. Esto se da a causa de que la ejecucin involucra una gran cantidad de variables que deben ser tenidas en cuenta y, por lo tanto, requieren de reuniones de diferentes caractersticas para poder tener la informacin necesaria. A continuacin se presentarn los diferentes tipos de reuniones aplicables durante la ejecucin de un proyecto de TI. La primera reunin que se tendr al momento de comenzar con el grupo de procesos de ejecucin es la Reunin Inicial. Quizs resulte redundante hablar sobre esta reunin ya que, en casi todos los proyectos, de una u otra manera esta reunin se lleva a cabo. Esta reunin debera realizarse o bien el primer da de trabajo de todo el equipo, o bien en algn da previo al mismo. Lo recomendable es que se haga el primer da de trabajo y que una vez finalizada la misma cada grupo se dirija a su lugar de trabajo y comience con sus actividades. Las Reuniones Diarias tienen lugar una vez que comienzan las actividades en cada grupo de trabajo dentro del proyecto ya que es muy importante realizar un seguimiento muy minucioso del avance de las actividades. Esto es esencial para poder identificar puntos crticos o problemas que puedan
Ing. Hernn A. Turin
180
causar retrasos o generar inconvenientes en la realizacin de las tareas del equipo de trabajo. Las reuniones diarias son una herramienta que, bien aplicada, resulta muy til para detectar problemas en forma temprana y evitar los desvos que surgen en el da a da de cada proyecto. Pero estas reuniones deben cumplir con una serie de caractersticas para que sean eficaces y tiles al proyecto. La idea de este encuentro es que cada integrante del equipo este al tanto del avance de las actividades del resto. Adems se favorece la comunicacin y la participacin de todos ya que si algn miembro presenta algn problema relacionado con sus actividades dentro del proyecto, quizs alguien del resto del quipo pueda colaborar con alguna propuesta de solucin.
Las Reuniones de Avance, si bien son aplicables a todos los grupos de trabajo de un proyecto, representan una herramienta fundamentalmente til para el lder de proyecto ya que permite medir el grado de avance general de los diferentes grupos de trabajo dentro del proyecto. Estas reuniones se recomienda que sean realizadas cada 15 das, aunque este plazo puede extenderse o reducirse de acuerdo a las caractersticas de cada proyecto y, fundamentalmente, de los tiempos del mismo. El objetivo de la reunin de avance es proveer al lder de proyectos de una visin global del estado de las diferentes actividades dentro del proyecto. En esta reunin deben participar el lder del proyecto y los encargados de los diferentes grupos de trabajo. All cada uno de los encargados expondr el grado de avance de su grupo y, en caso de existir, expondrs las dificultades con las que se ha encontrado y las consecuencias de las mismas en el cumplimiento de los objetivos de su grupo.
Wikis En el caso de la ejecucin de un proyecto, las wikis tambin se transforman en una herramienta til. Al igual que en los casos anteriores, tienen como utilidad principal el dar soporte a las actividades que en este grupo de procesos se realizan y que tienen relacin con la administracin del factor humano. En este caso particular, las wikis permiten que todo el grupo pueda encontrar en ella toda la informacin necesaria para su trabajo. Esto incluye:
Ing. Hernn A. Turin
181
informacin de contacto de los diferentes grupos/miembros del equipo, documentos relacionados con la planificacin, plantillas para la generacin de documentacin, calendario de reuniones y cualquier otra informacin que se decida colocar en el sitio. Tambin se pueden almacenar las diferentes versiones del documento de modo que se encuentran accesibles desde una intranet para todos los usuarios interesados en ver los mismos.
Listas de Correo En el caso de las listas de correo utilizadas durante la ejecucin el proyecto, sus beneficios son los mismos que los planteados para el grupo de planificacin, es decir: Proveer mayor dinamismo en las comunicaciones ya que durante los procesos de ejecucin, el dinamismo y la agilidad en todos los sentidos resulta un factor crtico de xito. Permitir distribuir en forma muy sencilla y rpida documentos generados. Proveer una herramienta simple y accesible para todos los involucrados. Facilitar el intercambio de opiniones acerca de ciertos tpicos cuando los involucrados en la discusin se encuentran en locaciones geogrficas muy distantes.
Foros de Discusin Bsicamente este caso es una combinacin de algunas de las ventajas de las wikis (compartir informacin y contenidos) y las ventajas de las listas de correo (simplicidad de uso y facilidad de implementacin). Esta combinacin de ventajas la convierte en muy atractiva para mejorar la comunicacin dentro de un proyecto. Sin embargo, en comparacin con las dems ventajas que ofrecen las dos alternativas antes mencionadas, no resulta tan conveniente aunque para algunos proyectos con una estructura mas reducida, su simplicidad puede resultar ms atractiva que las wikis.
Ing. Hernn A. Turin
182
Mensajera Instantnea El caso de la mensajera instantnea aplicada al grupo de procesos de ejecucin, resulta una herramienta casi indispensable para la comunicacin tanto entre los grupos dentro del equipo como entre los miembros de cada grupo. Esta herramienta se hace especialmente interesante cuando el equipo de trabajo est distribuido en oficinas diferentes, de modo que las consultas breves o pedidos simples pueden gestionarse mediante esta herramienta.
Comits de Desarrollo Esta tcnica facilita la administracin de las personas involucradas en el proyecto y que, como se menciona antes, tienen gran influencia en el xito o el fracaso del mismo. Otra de las ventajas en el uso de esta tcnica es su adaptabilidad a los diferentes tipos de proyectos de TI. Su versatilidad permite que no solo se utilice para aquellos proyectos que involucran desarrollo de software, sino tambin a aquellos en los que, por ejemplo, solo se implementan nuevas tecnologas.
Programacin de a Pares En los proyectos la transferencia de conocimientos de otro de los factores muy importante a tener en cuenta ya que es conveniente que varias personas tenga conocimiento acerca de las actividades que se realizan. Esto facilita la rotacin de las personas y adems funciona como plan de contingencia para casos en que se pierda alguno de los miembros del equipo. Adems, sirve como plan de capacitacin para los eventuales ingresos que se produzcan durante la marcha del proyecto. La desventaja que se presenta en este caso, es que la programacin de a pares es solo aplicables a proyectos que involucran desarrollos de software, de modo que todas sus bondades no pueden aprovecharse cuando se trata de otro tipo de proyectos de IT, aunque algunos tems podran adaptarse (por ejemplo en caso de un proyecto de implementacin de nuevas tecnologas, colocar a una persona novata a trabajar con un experto en la instalacin del nuevo hardware de modo que se produzca la transferencia de conocimientos).
Ing. Hernn A. Turin
183
Comits de Usuarios Si bien se est frente a una tcnica que puede ser implementada en ms de un grupo de procesos, su implementacin durante la ejecucin del mismo tiene fundamentalmente dos razones: Disminuir al mximo el riesgo de resistencia al cambio: se busca que los usuarios se sientan identificados con el nuevo producto involucrndolos en las discusiones relacionadas con ciertos aspectos funcionales del mismo. Obtener mayor cantidad de informacin acerca de ciertos requisitos del proyectos e incluso obtener soluciones creativas y alternativas frente a ciertos problemas. Esto ltimo se logra gracias a que los usuarios no estn tan compenetrados en el detalle del proyecto y por lo tanto sus ideas pueden fluir sin ningn tipo de sesgo.
SEGUIMIENTO Y CONTROL 1. Tcnicas a Utilizar: De acuerdo a las necesidades planteadas y segn los objetivos que se persiguen en el grupo de procesos de control, las tcnicas a aplicar son: Reuniones, Wikis, Foros de Discusin, Listas de Correo, Mensajera Instantnea, PERT., C.P.M, COCOMO y Puntos de Funcin.
Las Reuniones Durante el seguimiento y control de un proyecto se pueden utilizar los mismos tipos de reunin que se mencionaron para la ejecucin, solo que en este caso se deber ponderar algunos otros aspectos para poder obtener informacin especfica de control. A continuacin se analizarn cada uno de los tipos ya mencionado remarcando los aspectos a considerar para convertirlas en una tcnica til para el seguimiento de proyectos.
Wikis, Foros de Discusin y Listas de Correo El caso de las Wikis, los Foros de Discusin y las Listas de Correo en este caso se analizarn en conjunto ya que la utilidad de las tres tcnicas
Ing. Hernn A. Turin
184
aplicadas al seguimiento y control de un proyecto es bsicamente la misma, con las diferencias que marcan simplemente su forma de funcionamiento. En cualquiera de los tres casos la utilidad est dada fundamentalmente por dos aspectos: la facilidad para distribuir / recopilar informacin necesaria para monitorear el avance del proyecto y la facilidad para imprimir dinamismo en las comunicaciones. Este segundo aspecto es el que mas importa en lo que respecta a la administracin del factor humano dentro de un proyecto. Sin embargo, el hecho de que todo lo que se publica es visto por todos los miembros genera un inconveniente: cuando la consulta debe ser privada porque afecta a las relaciones con algn otro integrante del equipo o es un tema muy delicado, no permiten tener privacidad. Esto lleva a sugerir que estas herramientas se utilicen en conjunto con otras tcnicas las cuales permiten tener mayor privacidad en ciertos temas.
Mensajera Instantnea El caso de la mensajera instantnea es justamente la tcnica que provee la solucin al problema de privacidad planteado con lo foros, las wikis y las listas de correo. En este caso la ventaja principal es que la mensajera instantnea permite mantener contacto entre personas en forma privada, de moso que el resto del equipo no conozca dicho contacto. La prestacin de contacto persona a persona es fundamental en casos donde hay conflictos personales o problemas que requieren un tratamiento discrecional. Adems tambin tienen la ventaja de que cuando se requiere informacin de solo una persona, slo se contacta a sta sin molestar al resto con mensajes que no le corresponden ni interesan.
PERT. / CPM En el caso del seguimiento y control visto desde el punto de vista de la administracin de personas, la utilidad de los documentos generados por CPM y PERT. radica en determinar la carga de trabajo de las personas. En muchos casos se realiza una determinada distribucin de tareas durante la planificacin, pero luego, durante la marcha del proyecto, puede que se noten deficiencias en esta distribucin. Esto puede darse porque las estimaciones no fueron lo suficientemente precisas o porque el desempeo de las personas no es el
Ing. Hernn A. Turin
185
previsto. Es para detectar este tipo de inconvenientes que se necesitan de las dos tcnicas mencionadas. COCOMO y Puntos de Funcin El caso de COCOMO y de los Puntos de funcin aplicados al seguimiento y control de un proyecto de TI tiene su importancia en el hecho de que durante la marcha del proyecto pueden surgir cambios. Estos cambios pueden ser menores o pueden ser cambios sustanciales que impacten en la duracin del mismo. En este ltimo caso es que se dar la necesidad de utilizar estas tcnicas para redefinir algunos tiempos y determinar si, de acuerdo a las nuevas definiciones y los nuevos tiempos calculados, la marcha del proyecto es la correcta.
CIERRE 1. Tcnicas a Utilizar: Segn lo expuesto en la Tabla XIII, las tcnicas a utilizar en este grupo de procesos son: Reuniones, Wikis, foros de Discusin, Listas de Correo, Mensajera Instantnea, Comits de Usuarios, Grupos de Apoyo y Mesa de Ayuda.
Wikis, Foros de Discusin y Listas de Correo La idea de utilizar estas tcnicas durante el grupo de procesos de cierre est fundamentalmente orientada a dar soporte a los usuarios finales. Esto se basa en el hecho de que, al implementar un nuevo proyecto en una organizacin, surgirn dudas acerca del uso tanto del software que se implemente como de las tecnologas involucradas. En este sentido es que las wikis, los foros y las listas de correo pueden ser muy bien explotados. Estas herramientas permiten que los usuarios se puedan comunicar fcilmente con el grupo del proyecto encargado de la puesta en marcha del mismo, de modo que sus dudas o comentarios puedan ser recepcionados y atendidos en forma muy simple. La desventaja principal radica en que, al no ser herramientas en lnea, las respuestas a consultas urgentes estarn sujetas a la frecuencia con que el equipo de proyecto o el resto de los usuarios ingresen al foro, el correo electrnico o la Wiki.
Ing. Hernn A. Turin
186
Mensajera Instantnea La idea de implementar la mensajera instantnea en el grupo de procesos de cierre es bsicamente la misma que se menciona para el caso de los foros y las listas de correo, es decir: dar soporte a los usuarios durante la implementacin del proyecto de forma tal que se disminuya todo lo posible la resistencia al cambio. Adems, se genera confianza en los usuarios ya que, por contar con este tipo de mecanismos para evacuar dudas, se da una sensacin de respaldo y acompaamiento en la implementacin.
Comits de Usuarios La implementacin de sta tcnica obedece a fundamentalmente a las dos razones: Disminuir al mximo el riesgo de resistencia al cambio: se busca que los usuarios se sientan identificados con el nuevo producto involucrndolos en las discusiones relacionadas con ciertos aspectos funcionales del mismo de modo que se asegure una mejor comprensin. Generar un espacio donde los usuarios puedan compartir sus experiencias y compartir su conocimiento, de modo que se genere una verdadera comunidad de prctica. sta segunda razn es quizs la mas importante porque ninguna de las dems tcnicas mencionadas apunta a lograr la creacin de este tipo de comunidades. Si bien en proyecto de pequeo o mediano tamao puede resultar poco convincente el uso de este tipo de comits, en proyectos de gran tamao, que se implementa en diferentes lugares u organizaciones, se transforma en una tcnica sumamente til. Lo que se busca lograr formando este tipo de comunidades es generar un sentido de pertenencia por parte de los usuarios para con el proyecto, de forma tal que no se vean como algo externo al proyecto sino como un componente mas del mismo. Esto resulta de gran ayuda para lograr una finalizacin exitosa de proyecto.
Grupos de Apoyo La utilizacin de los grupos de apoyo en el cierre de un proyecto tiene como objetivo lograr una implementacin rpida y exitosa.
Ing. Hernn A. Turin
187
Nuevamente la idea de esta tcnica es generar confianza en los usuarios y mostrarles que existe preocupacin por su comodidad de parte del equipo del proyecto. La ventaja principal es que, el hecho de tener personas que los ayuden en sus tareas con el nuevo sistema, tiene un efecto muy positivo sobre los usuarios quienes se sentirn contenidos. Pero como contrapartida, la desventaja es que requiere de personas del proyecto con un tiempo importante dedicado a estas actividades y que adems, en algunos casos, se puede generar en el usuario una sensacin de invasin de su espacio y su trabajo.
Mesa de Ayuda Dependiendo de la organizacin y del tipo de proyecto, la implementacin de la mesa de ayuda puede ser muy simple ya que hay muchas organizaciones que ya cuentan con grupos de este tipo para atender las necesidades de los usuarios, de modo que solo se requerira contar con personas que tengan conocimiento del proyecto y que formen parte del grupo de la mesa. Finalmente las mesas de ayuda tienen la ventaja de que pueden ser perdurables a travs del tiempo. Es decir que si el proyecto se da por finalizado, la organizacin puede decidir la continuidad de la mesa de ayuda para dar soporte a los usuarios no solo en aspectos relacionados con el proyecto puntual que le dio origen, sino tambin a todos aquellos temas (tecnologa y otras aplicaciones) que la organizacin defina.
Ing. Hernn A. Turin
188
9.2-
ANEXO II CUESTIONARIO UTILIZADO
CUESTIONARIO: MODELO PARA LA GESTIN DEL FACTOR HUMANO

Sobre el Modelo en General 1- Considera adecuada la eleccin de la estructura utilizada para el planteo del modelo? SI NO
2- Sugerira alguna modificacin a la estructura?
3- Considera que el modelo planteado es efectivamente aplicable a todos los proyectos de TI? SI 4- En caso negativo, Porqu? NO
5- Considera que el Modelo puede ser llevado a la prctica en forma exitosa? SI NO
6- En caso negativo: Qu modificaciones sugerira para que sea posible de llevar a la prctica?
7- Considera correcta la agrupacin de prcticas en Genricas y Especficas? SI NO
Ing. Hernn A. Turin
189
8- Por qu?
Sobre las Prcticas Genricas 9- Considera que la seleccin de las Prcticas Genricas del modelo es acertado? SI 10- En caso negativo, Porqu? NO
11- Sugerira la inclusin de alguna otra prctica? SI 12- En caso afirmativo, Cules? NO
13- Considera correctas las particularidades indicadas para la aplicacin de cada una de las prcticas en cada grupo de procesos? SI 14- Sugerira alguna modificacin? NO
Ing. Hernn A. Turin
190
Sobre las Prcticas Especficas 15- Considera que la seleccin de las Prcticas Especficas del modelo es acertado? SI 16- En caso negativo, Porqu? NO
17- Sugerira la inclusin de alguna otra prctica? SI 18- En caso afirmativo, Cules? NO
19- Considera correcta la distribucin prcticas especficas / grupo de procesos propuesta? SI 20- Sugerira alguna modificacin? NO
Ing. Hernn A. Turin
191
9.3-
ANEXO III RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 1

Sobre el Modelo en General 1- Considera adecuada la eleccin de la estructura utilizada para el planteo del modelo? SI X NO

Aunque es mejor el foco a lo largo de cada grupo de procesos, evitara cierta redundancia al considerar cada prctica en cada uno de esos grupos.
3- Considera que el modelo planteado es efectivamente aplicable a todos los proyectos de TI? SI X NO
4- En caso negativo, Porqu?
5- Considera que el Modelo puede ser llevado a la prctica en forma exitosa? SI X NO
Poner el foco en la integracin de las prcticas.
7- Considera correcta la agrupacin de prcticas en Genricas y Especficas? SI X NO
Ing. Hernn A. Turin
192
8- Por qu?
Porque las generales se tratan en todo el proyecto, y las especfica en cada grupo de proceso o rea de conocimiento
Sobre las Prcticas Genricas 9- Considera que la seleccin de las Prcticas Genricas del modelo es acertado? SI X NO
11- Sugerira la inclusin de alguna otra prctica? SI X NO
12- En caso afirmativo, Cules?

Cadena Crtica, porque pone en evidencia los fenmenos humanos que causan la gran mayora de los fracasos de los proyectos, y provee un enfoque metodolgico para resolverlos.
13- Considera correctas las particularidades indicadas para la aplicacin de cada una de las prcticas en cada grupo de procesos? SI X NO
14- Sugerira alguna modificacin?
Ing. Hernn A. Turin
193
Sobre las Prcticas Especficas 15- Considera que la seleccin de las Prcticas Especficas del modelo es acertado? SI X NO

Comunicacin interpersonal
19- Considera correcta la distribucin prcticas especficas / grupo de procesos propuesta? SI X NO
20- Sugerira alguna modificacin? Nada ms all de la sugerida en el punto 12.
Ing. Hernn A. Turin
194
9.4-
ANEXO IV RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 2


No,, la estructura es adecuada.
3- Considera que el modelo planteado es efectivamente aplicable a todos los proyectos de TI? SI X NO
7- Considera correcta la agrupacin de prcticas en Genricas y Especficas? SI

Ing. Hernn A. Turin
NO 195
8- Por qu?
Esta divisin es usual en los modelos de calidad, tiene coherencia, y ha sido verificada en suficientes casos.

Se podra analizar si la conveniencia de dividir la prctica Reuniones en tres tipos: Reunin Objetivo, que posee un nico y claro objetivo e incluye la toma de decisiones; Reuniones de Ideas en las cuales se generan ideas sobre algn tema, pero no se toman decisiones y Reuniones de relevamiento cuyo objetivo es obtener informacin, tambin, sin tomar decisiones. Tambin sera importante incluir Reuniones Virtuales a travs de Internet (por ejemplo con Camfrog), sobre todo si los involucrados no residen en la misma localidad

En las Reuniones, creo que es conveniente informar a todos los participantes los temas a tratar en forma previa a la reunin (en el modelo se menciona que se lo informa al comenzar la reunin).
Ing. Hernn A. Turin
196

Las tcnicas de CPM y PERT son complementarias a la tcnica GANTT. Actualmente existen herramientas informticas de gestin de proyectos que combinan las tres tcnicas dando como resultado una representacin ms completa y til. Sera interesante utilizar esta ltima solucin. Las prcticas PF y COCOMO slo sirven si el proyecto es de desarrollo de software o de sistemas de informacin. Debera haber alguna prctica alternativa de estimacin, como por ejemplo Top-Down y/o Buttom-Up para otros tipos de proyectos..
20- Sugerira alguna modificacin? No, considero que es adecuada.
Ing. Hernn A. Turin
197
9.5-
ANEXO V RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 3

Sobre el Modelo en General 1- Considera adecuada la eleccin de la estructura utilizada para el planteo del modelo? SI x NO

No.
3- Considera que el modelo planteado es efectivamente aplicable a todos los proyectos de TI? SI x NO
4- En caso negativo, Por qu?
5- Considera que el Modelo puede ser llevado a la prctica en forma exitosa? SI x NO
7- Considera correcta la agrupacin de prcticas en Genricas y Especficas? SI x NO
Ing. Hernn A. Turin
198
8- Por qu?
La agrupacin planteada y el detalle presentado de las prcticas permiten visualizar claramente las ventajas que se obtienen con su aplicacin en cada una de las fases de un proyecto.
Sobre las Prcticas Genricas 9- Considera que la seleccin de las Prcticas Genricas del modelo es acertado? SI x NO
10- En caso negativo, Por qu?
11- Sugerira la inclusin de alguna otra prctica? SI 12- En caso afirmativo, Cules? NO x
13- Considera correctas las particularidades indicadas para la aplicacin de cada una de las prcticas en cada grupo de procesos? SI x NO

No.
Ing. Hernn A. Turin
199
Sobre las Prcticas Especficas 15- Considera que la seleccin de las Prcticas Especficas del modelo es acertado? SI x NO
17- Sugerira la inclusin de alguna otra prctica? SI 18- En caso afirmativo, Cules? NO x
19- Considera correcta la distribucin prcticas especficas / grupo de procesos propuesta? SI x NO
20- Sugerira alguna modificacin? No.
Ing. Hernn A. Turin
200
9.6-
ANEXO VI RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 4


No. Considero correcto la utilizacin de la estructura propuesta y la divisin en Practicas Genricas y Prcticas Especficas.
23- Considera que el modelo planteado es efectivamente aplicable a todos los proyectos de T.I.? SI 24- En caso negativo, Porqu?
El modelo y conjunto de prcticas expuesto por el PMI ha tenido en sus comienzos una amplia aceptacin en cuanto al estudio de cada una de las posibles fases y reas de conocimiento existentes en un proyecto. Sin embargo, esta sumando da a da nuevos cuestionamientos respecto a la falta de dinmica propia de los proyectos no tradicionales (como los de TI). Esto est llevando al PMI a evaluar la posibilidad de revisar su metodologa y orientar parte de la prctica hacia una versin ms gil, incluso en el rea de Administracin del Factor Humano.
NO X
NOTA: Considero puede ser positivo en el caso de proyectos tradicionales y de duracin prolongada. Sugerira observar con mayor detenimiento los lineamientos expuestos por SCRUM (una de las prcticas lder en TI) y a su vez, la visin de la Administracin del factor humano por parte de CMMI (niveles 3 y 4).
27- Considera correcta la agrupacin de prcticas en Genricas y Especficas?
Ing. Hernn A. Turin
201
SI 28- Por qu?
NO
Todo proyecto, sea cual fuere su Industria de pertenencia contiene prcticas que son transversales a las etapas por las que pasa y otras, mas particulares, que tiene una inherencia una fase en cuestin. El desarrollo del equipo de trabajo, es un aspecto clave, tanto en la fase de Iniciacin, de Ejecucin, como de Cierre.

Plataformas Colaborativas y Redes Sociales. La utilizacin de plataformas colaborativas en el mbito del TI es actualmente uno de los aspectos de Administracin del Factor Humano que ms est creciendo en las organizaciones. (ClearSpace, FaceBook, Sharepoint, etc)

No.
Ing. Hernn A. Turin
202

Creo que las seleccionadas son acertadas pero estn faltando otras prcticas que hacen a la administracin del factor humano. Una de ellas que resalta ampliamente PMI es la creacin de la WBS (Estructura de desglose del Trabajo). La considera no solo una herramienta comunicacional sino tambin un elemento que da sentido de ubicacin, pertenencia y motivador del equipo. Insisto en que pueden haber algunas mas, pocas en el caso de PMI, pero ms si se evala la Gestin de Proyectos en su sentido ms amplio. Recomiendo repasar el libro de Kim Heldman referido al PMBOK, dado que ella hace foco en el Factor Humano.
40- Sugerira alguna modificacin? No.
Ing. Hernn A. Turin
203

MIS 2009 Turin

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MIS 2009 Turin

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD TECNOLGICA NACIONAL FACULTAD REGIONAL BUENOS AIRES

Tesis para optar al grado de Magster en Ingeniera de Sistemas de Informacin

HERNN ALEJANDRO TURIN

CAPITULO VII: CONCLUSIONES........................................................................ 153

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Proyecto Finalizado Exitosamente

Figura 1 Relacin entre las variables que influyen en el xito de un proyecto.

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Evaluar el modelo obtenido y analizar los resultados.

Ing. Hernn A. Turin

Ing. Hernn A. Turin

EL FACTOR HUMANO Y LA ADMINISTRACIN

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

LA GESTIN DE LOS PROYECTOS DE TI

Ing. Hernn A. Turin

Grupos de Procesos reas de Conocimiento Gestin de la Integracin Gestin del Alcance

Gestin del Tiempo X

Gestin de la Calidad X Gestin de los Recursos Humanos X X

Gestin de las Comunicaciones X Gestin de Riesgos X X X X X

Gestin del Aprovisionamiento

Tabla I Relacin entre grupos de procesos y reas de conocimientos del PMBOK.

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Empresa 1 2 3 4 5 6 Promedio General

ndice de Resistencia 144 105 61 105 146 143 117,1

ndice de Resistencia Mnimo Registrado 125 89 44 56 144 119 ---

Tabla II ndice de Resistencia al cambio por el desarrollo de un S.I. en el rea de RRHH

Tabla III Relacin entre el IRC y las variables Sociolaborales

Ing. Hernn A. Turin

Empresa 1 2 3 4 5 6 Promedio General

Tabla IV Relacin entre el IRC y los factores de la personalidad

Empresa 1 2 3 4 5 6 Promedio General

Tabla V Relacin entre el IRC y los factores organizacionales

Tabla VI Importancia de los factores de xito de un proyecto.

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Figura 5 Esquema grfico de la interaccin entre las etapas de SCRUM

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

Ing. Hernn A. Turin

PLANTEAMIENTO DEL PROBLEMA

LOS PROYECTOS DE TI Y LAS PERSONAS

Ing. Hernn A. Turin

Ing. Hernn A. Turin

EL SOFTWARE Y LAS PERSONAS

Ing. Hernn A. Turin

LAS MEJORES PRCTICAS

Ing. Hernn A. Turin

Ing. Hernn A. Turin

SELECCIN DE MEJORES PRCTICAS