Revista Cubana de Ciencias Informáticas

ISSN: 1994-1536

rcci@uci.cu

Universidad de las Ciencias Informáticas

Cuba

André, Margarita; Baldoquín, María G.; Soler McCook, Jorge M.

Gestión de Recursos Humanos por Competencias en los Proyectos de Software

Revista Cubana de Ciencias Informáticas, vol. 1, núm. 4, 2007, pp. 82-91

Universidad de las Ciencias Informáticas

Ciudad de la Habana, Cuba

Disponible en: http://www.redalyc.org/articulo.oa?id=378343634007

Cómo citar el artículo

Número completo

Más información del artículo

Página de la revista en redalyc.org

Sistema de Información Científica

Red de Revistas Científicas de América Latina, el Caribe, España y Portugal

Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto

Gesti6n de Recursos Humanos por Competencias en losProyectos de SoftwareHuman Resources Management based on Competences inSoftware Projects

Margarita Andr Ampuerol*, Maria G. Baldoquin de la Pe6a2 y Jorge M.Soler McCook3lDepartamento de Ingenieria de Software Instituto Superior Po|itChico "Jose Antonio Eche-Verna" Marianao, CP~ 19390 La Habana, Cuba2 Departamento de Matematica, Instituto Superior Po|itChico "Jose Antonio Echeverria", LaHabana, Cuba3 Empresa DESOFT, La habana, Cuba

*Autor para la correspondencia: mayi@ceis.cujae.edu.cu

REV/STA CUBANA DE CIENCIAS INFORMATICAS VOL.l No.4 DICIEMBRE 2007 p. 82-93

Este trabajo tiene como objetivo contribuir a fa implementaci6n, en fa industria desoftware, de fa gesti6n de recursos humanos basado en el enfoque por competencias.Para elfo, se realiza y fundamenta Una propuesta de roles invariantes que participan tantoen proyectos de desarrollo como de implantaci6n de software, y de competencias tantotecnicas como genricas requeridas para desempehar los roles propuestos. En el trabajose fundamenta el uso def mtodo Delphi y fas variaciones requeridas, como via paravalidar fa propuesta de roles y competencias, y para identificar fa importancia de cadacompetencia en el desempeho de cada rof. Ademas, se propone un procedimiento paradeterminar el indice de competencia de Una persona para desempehar un rof asignadoen el proyecto.

Palabras clave: Competencias, gesti6n de recursos humanos, mtodo Delphi, proyectosde software, roles.

The main objective of the paper is to contribute to the implementation, in the softwareindustry, of human resources management based on competences. To do this, the useof the Delphi method and the required changes are discussed, as a way to validate theroles~ and competences~ proposal, and to identify the importance of each competenceto carry out each role. Besides, it presents the procedure to calculate the competence'sindex of each person to perform the assigned role in the project.

Key words: Competences, Delphi method, human resources management, roles,software's projects.

A pesar def vertiginoso desarrollo, los reconocidos resultados y el gran impacto que hatenido fa industria de software en prcticamente todas fas ramas def desarrollo de fasociedad a nivel mundial, aun resulta significativo el numero de proyectos de softwareque no culminan con exito (Pressman, 2002). Entre fas causas que provocan estosfracasos se encuentran fas asociadas a factores humanos. Son varias fas investigacionesque reconocen que los recursos humanos juegan un papel critico en el xito o fracaso deun proyecto de software (Acuha, 2002; DeMarco, 1999; Gorla, 2004; Pressman, 2004).Sin embargo, el personal continua siendo el factor menos formalizado en los modelos deprocesos de software actuales, en fas metodologias de desarrollo y gesti6n de proyectosy en los estndares aplicables a esta industria; los cuales se centran ms en aspectostech|cos que en los aspectos humanos (Acuha, 2002; Andre, 2008).

La industria de software ha experimentado un aumento significativo en el vofumen ycomplejidad de los productos que desarroffa. En consecuencia, el desarrollo de softwarepas6 de ser un trabajo esencialmente artesanal a un trabajo en equipo donde cadapersona no solo debe desempehar correctamente su rol sino que debe constituir unmiembro efectivo def equipo mostrando disciplina personal y en equipo. La necesidad

que experimenta la industria del software se corresponde con la tendencia cada vez masfuerte, que existe en la actualidad hacia la gesti6n de los recursos humanos, potenciandolas caracteristicas del personal que integra las organizaciones. La Gesti6n de RecursosHumanos (GRH) es mucho mas eficiente si se basa en las competencias individuales delos trabajadores, teniendo en cuenta que para las organizaciones la competencia laboralapoya los procesos de selecci6n, contrataci6n, capacitaci6n, evaluaci6n y compensaci6ndel personal (Cuesta, 2005). Sin embargo, las investigaciones indican que esta disciplinaesta muy poco desarrollada aun (Urquiza, 2007). La industria de software no esta exentade esta realidad a pesar de que para ella, esta disciplina resulta muy importante. Ni losmode|Os de procesos, ni las metodologias de desarrollo ofrecen un marco de referenciabien formalizado, que contenga claramente definidas las competencias genricas ytecnicas requeridas para desempehar cada rol establecido acorde a las caracteristicas delos proyectos de software.

Gesti6n de Recursos Humanos por competencias en proyectos de softwareLos primeros aportes practicos sobre el tema de competencias Se deben a David McClelland,quien demostr6 que los resultados academicos y los tradicionales tests de inteligencia nopredicen de forma fiable el xito profesional (McClelland, 1973). Vargas (Vargas, 2001), apartir del analisis de varias definiciones de competencias y de los trabajos de un grupo deestudiosos del tema concluy6 que las competencias: son caracteristicas permanentes dela persona, se ponen de manifiesto cuando se ejecuta Una tarea o se realiza un trabajo,estan relacionadas con la ejecuci6n exitosa en Una actividad (sea laboral o de otra indole),tienen Una relaci6n causal con el rendimiento laboral y pueden ser generalizables a masde Una actividad.

En este trabajo Se utiliza el concepto de competencia laboral expuesto por Cuesta en(Cuesta, 2005) que plantea: "las competencias laborales son caracteristicas subyacentesen las personas, asociadas a la experiencia, que como tendencia estan causalmenterelacionadas con actuaciones exitosas en un puesto de trabajo contextualizado enuna determinada cultura organizacional" Ademas, Se distinguen dos categorias decompetencias: las genericas (que definen caracteristicas referidas al comportamientogeneral del empleado, independientes de los conocimientos tcnicos concretos. Ejemplos:negociaci6n, planificaci6n y organizaci6n, liderazgo, capacidad de analisis, etc.) y lastecnicas o especificas (asociadas a conocimientos y habilidades tcnicas especificas decada puesto de trabajo).

Para las organizaciones de software la GRH por competencias constituye Una practicamuy necesaria ya que debido a las peculiaridades de esta industria resulta clave protegery desarrollar a su personal. En el profesional del software confluyen condiciones idea|espara que experimente gran movilidad: es especializado (por Sus conocimientos yhabilidades), pero a su vez generalista (por la gran cantidad y variedad de dominios deaplicaci6n de su trabajo) y muy demandado, debido aI impacto de la informatizaci6nen practicamente todas las ramas de desarrollo de un pals. Por otra parte, debido aldesarrollo vertiginoso de las Tecnologias de la lnformaci6n y las Comunicaciones, lo cualprovoca cambios continuos en el estado del arte, las organizaciones de software necesitancontar con un personal tecnicamente competente y en continua superaci6n. Ademas, porser la ingenieria de software un proceso social complejo en el cual la comunicaci6n y lainteracci6n cooperativa entre los miembros del equipo tiene su impacto en la calidad delproducto desarrollado de forma colaborativa, es preciso que el personal tambin poseacompetencias de comportamiento como: la comunicaci6n, la negociaci6n y la capacidadde trabajar en equipo, entre otras.

Cabe sehalar que, a pesar del avance en la comprensi6n y aplicaci6n de esta disciplinaen algunas de las organizaciones de software cubanas no constituye una practicageneralizada. Prueba de ello es que en la actual|dad, la asignaci6n de personal a losroles de un proyecto de software y la formaci6n del propio equipo se realiza basado,fundamentalmente, en criterios empiricos de los jefes de proyecto. En muchos casos nose contemplan factores tales como: competencias tecnicas y genericas, motivaciones,intereses, carga del personal, tamao del equipo e incompatibilidades o conflictos entremiembros (Rodriguez, 2008).

Los autores de este trabajo participan en Una investigaci6n Que tiene como objetivoprincipal proponer un modelo formal para asignar personal a proyectos de software.Como parte de la investigaci6n se utiliz6 el metodo Delphi para identificar cuales deben serlos factores fundamentales a tomar en cuenta en el proceso de asignaci6n. AI culminar lasegunda ronda en la aplicaci6n del metodo, se pudo concluir que las competencias (tantotecnicas como genericas), para desempear los distintos roles del proyecto, constituyenuno de los principales factores que los expertos consideran Que se debe tomar en cuentaen la asignaci6n (Andr, 2008; Rodriguez, 2008).

Sin embargo, para aplicar este modelo es preciso Que las organizaciones tengan formalizadocuales son los roles que intervienen en los proyectos y cuales las competencias requeridaspara desempear correctamente los roles. En este sentido, existen grandes dificultadesya Que ni los mode|Os de procesos, ni las metodologfas de desarrollo ofrecen un marcode referencia bien formalizado, que contenga claramente definidas las competenciasgenericas y tecnicas requeridas para desempenar cada rol establecido acorde a lascaracteristicas del proyecto. Por otra parte, de manera general, las organizaciones desoftware tampoco cuentan con un marco de referencia bien formalizado Que contengalos roles requeridos en funci6n de los tipos de proyectos.

Propuestas de roles invariantes para proyectos de desarrolllo e implantaci6n desolftwareResulta dificil elaborar una propuesta que contenga todos los posibles roles ya queello depende en gran medida del tipo y de la complejidad del proyecto a desarrollar. Acontinuaci6n se realiza Una propuesta de roles invariantes para proyectos de desarrollo eimplantaci6n de software y de las competencias requeridas para su adecuado desempeo.Esta propuesta puede servir de punto de partida y soporte en la implementaci6n dela gesti6n de recursos humanos por competencias en las organizaciones de softwarecubanas. Para elaborar la propuesta se analizaron los roles definidos en reconocidasmetodologias y mode|Os de proceso de desarrollo de software.

El anlisis de los roles establecidos en el Proceso Unificado de Desarrollo de Rational (RUP)representa un buen punto de partida por su amplia aplicaci6n a nivel internacional y porconstituir la propuesta metodol6gica aceptada por Object Management Group (OMG).Segun RUP, un rol es un puesto que puede ser asignado a una persona o conjunto depersonas Que trabajan juntas en un equipo, y que requiere habilidades y responsabilidadescomo: realizar determinadas actividades y desarrollar determinados artefactos. Losmiembros de un equipo de proyecto generalmente cubren varios roles (Jacobson, 2002).Los roles de RUP se clasifican en cinco grandes grupos (Andre, 2005):

Analistas: Analista del Proceso de Negocios, Disehador de Negocios, Revisor delModelo de Negocios, Analista de Sistema, Especificador de Requisitos, Revisor deRequisitos y Oiseador de la Interfaz Usuario.

Desarrolladores: Arquitecto de Software, Revisor de la Arquitectura, Disehador,Disehador de Ca psula Oiseador de Base de Datos, Revisor del Oiseo, Programador,Revisor del C6digo, Integrador.

Probadores: Disenador de Prueba, Probador.

Directivos: Director de Control de Cambio, Director de Configuraci6n, Director delmplantaci6n, Ingeniero de Proceso, Director del Proyecto, Revisor del Proyecto.

Otros: Stakeholder, Desarrollador de Cursos, Artista Grafico, Administrador deSistema, Documentador Tcnico, Especialista en Herramientas.

Extreme Programming (XP) es definida por su autor, Kent Beck, como Una metodologia agilpara el desarrollo de software destinada a ser utilizada por equipos de desarrollo pequeosy medianos (de 2 a 10 miembros) que enfrenten proyectos con requerimientos imprecisoso cambiantes, donde las relaciones desarrollador-desarrollador y desarrolladores-cliente,constituyen los elementos claves. XP propone siete roles: Programador, Cliente, Encargadode pruebas, Encargado de seguimiento, Entrenador, Consultor y Gestor (Beck, 1999).Crystal (familia de metodologfas agiles caracterizadas por estar centradas en las personasy en la reducci6n del numero de artefactos producidos, propone ocho roles: PatrocinadorEjecutivo, Jefe de Proyecto, Experto en el Dominio, Experto de uso, Programador-Oiseador, Disehador de Interfaz de Usuario, Probador, Programador Tcnico (Cockburn,2005).

El Proceso de Software en Equipo (TSP), modelo prescriptivo para equipos de desarrollode software, propone que las responsabilidades deben distribuirse entre los miembros delequipo a traves de ocho roles: Gerente de Interfaz-Usuario, Gerente de Oiseo, Gerentede lmplementaci6n, Gerente de Planeaci6n, Gerente de Procesos, Gerente de Calidad,Gerente de Soporte Tcnico y Gerente de Pruebas. Los especialistas de calidad, procesos,administraci6n de configuraci6n, herramientas y bibliotecarios apoyan en cada una de lasareas correspondientes (Serrano, 2005).

A partir del estudio de las propuestas mencionadas anteriormente se puede concluirque es posible identificar un conjunto de roles comunes o invariantes que participan enproyectos de desarrollo de software. Estos son:

Roles tecnicos, responsables del desarrollo del sistema: Analista, Disenador deInterfaz-Usuario, Arquitecto (Oisehador de alto nivel), Oiseador (de bajo nivel),Oisehador de Base de Datos (puede estar incluido en el rol anterior), Programadory Probador.

Roles de gesti6n, responsables de la planificaci6n y la ejecuci6n del proyecto:Jefe de Proyecto (incluye funciones asociadas a la planificaci6n y el control delproceso), Especialista de Calidad, Gestor de Configuraci6n, Gestor de Cambios,Documentador y Especialista en Seguridad (Este rol se incorpora por la importanciaque tiene tomar en cuenta los requisitos no funcionales asociados a la protecci6ny seguridad del sistema).

Sin embargo, resulta importante sealar que no necesariamente son stos los roles aestablecer en cada proyecto. Es posible desglosar o integrar estos roles como ocurre enalgunas de las propuestas estudiadas e incluso se pueden definir nuevos roles acorde

aI tipo de proyecto en cuesti6n. Por ejemplo, en (Viera, 2007) aparece Una propuestade roles para enfrentar proyectos Multimedia. Por otra parte, existe un conjunto deempresas cuya misi6n no solo consiste en realizar proyectos de desarrollo sino queejecutan proyectos de implantaci6n. Para el caso de estos proyectos tambien resultaposible identificar tres roles invariantes: Jefe de Proyecto de lmplantaci6n, EspecialistaOperacional (con experiencia en el dominio del sistema) y Especialista Tecnico (conexperiencia en la actividad informatica).

Propuesta de competencias tecnicas y genericas requeridas para el desempef:iiode los rolesAl evaluar la propuesta de roles de cada uno de los procesos y metodologias de desarrollode software analizadas se constat6 que en ningun caso se formalizan las competenciasrequeridas para su adecuado desempeo. En este sentido, se destaca el modelo deproceso de software propuesto en (Acuha, 2002) que incluye como elemento original,las capacidades de comportamiento o caracteristicas de la conducta profesional. Acuapropone asignar las personas a roles del proyectos en funci6n de las competenciasgenericas requeridas para cada rol. Para ello las clasifica en cuatro grupos: habilidadesintrapersonales, habilidades organizativas, habilidades interpersonales y habilidadesdirectivas.

Tomando como base lo planteado por Acuha encuestas a profesionales de la industriacubana de software, la propuesta de competencias de la empresa DESOFT y el anlisisde los diccionarios de competencias, se decidi6 realizar la propuesta, que contempla 26competencias (19 genericas y 7 tecnicas), que se muestran en la primera fila de la tablaque aparece en la Figura 1.

Una vez elaborada la propuesta de roles invariantes para enfrentar proyectos de desarrolloe implantaci6n de software, y de las competencias requeridas para el desempeho dedichos roles, se decidi6 someterla a la consideraci6n de un comit de expertos. Elobjetivo fundamental era obtener criterio de los expertos sobre: la propuesta de rolesy competencias asi como la importancia de cada competencia en el desempeho de losdiferentes roles. Como paso previo a la conformaci6n de dicho comit, los autores deltrabajo decidieron aplicar el mtodo Delphi para obtener los criterios de selecci6n de losexpertos. Despues de dos rondas, se obtuvo como resultado que los expertos deb\an serprofesionales con conocimientos de ingenieria de software, que tuvieran 10 o mas aosde experiencia en el desarrollo y la direcci6n de proyectos de software, y que hubiesendesarrollado 2 o mas proyectos de mediana o gran complejidad donde hubiesen dirigidoa 3 o mas personas. Posteriormente, se circul6 entre los candidatos Una plantilla paraobtener su sintesis curricular y aplicando los criterios de selecci6n, se cre6 el comiteel cual esta formado por 35 expertos provenientes de la industria y de la academia. Acada experto se le suministr6 Una matriz en cuyas filas aparecian los 16 roles propuestosy cuyas columnas contenian las 26 competencias~ Asi, los expertos debian completar416 celdas (16*26=416) con un valor entre 1 y 5 (ver en la Figura 1 la escala utilizada).Para facilitar el trabajo de los expertos, se asociaron comentarios donde se describian lasprincipales responsabilidades de los roles y Una breve definici6n de cada competencia.Adicionalmente, los expertos ten\an la posibilidad de adicionar y/o eliminar tanto rolescomo competencias.

Una vez recogidas las 35 matrices se obtuvieron 14560 datos (416* 35 expertos=1 4560)los cuales fueron procesados con el paquete estadistico MINITAB, utilizando graficos deboxplots. Estos grficos muestran la mediana y el rango del intercuartil ya que los datos

son ordinales. Por un problema de espacio no resulta posible reflejar el procesamientorealizado a los 16 roles. A continuaci6n, se explican los pasos ejecutados utilizando comoejemplo el procesamiento del rol Jefe de Proyecto:

Paso 1 . Procesar, para cada rol, los datos emitidos por los expertos en las 26 competencias.La Figura 2a muestra el procesamiento de los datos para el rol Jefe de Proyecto.

Paso 2: Analizar los Va|ores outliers (representados por *) . Tomando en cuenta la naturalezade los datos procesados, la escala utilizada y el concepto de outlier que ofrece el MIN|TAB,los autores del trabajo definieron como outlier aquellos Va|ores de la variable que diferianen al menos dos unidades de los extremos de los boxplots. En el caso en que el rangodel intercuartil tomaba valor 1 y existian bigotes (ya fuera superior, inferior o ambos) seconsideraba outlier el valor que difiriera en Una unidad del extremo del bigote.

Paso 3: Eliminar los outliers. Una vez que se eliminaron los 22 outliers identificados parael rol Jefe de Proyecto, se procesaron nuevamente los datos y se obtuvo el grafico que semuestra en la Figura 2b.

Fig. 1. Matriz suministrada a los expertos en la primera ronda del metodo Delphi.

Fig. 2a. An!Isis del rol Jefe de Proyecto. Fig. 2b. Anlisis del rol Jefe de Proyecto (sin outliers) .

Paso 4: Identificar las competencias requeridas para desempehar cada rol. A partir delanal|sis del grafico de la Figura 2b se pudo concluir que las competencias de la 1 a la 20, la22, la 24 y la 26 eran necesarias para desempehar el rol de Jefe de Proyecto ya que comose observa, todos los expertos concuerdan que cada Una de estas competencias al menosresulta util (valor 3) para el rol. Para llegar a conclusiones acerca de las competencias 21,23 y 25, fue preciso analizar los Va|ores de la mediana y la moda. Esto permiti6 concluirque tanto la competencia 21 como la 23 resultaban necesarias para el desempeo del roly que en el caso de la competencia 25, debido a la gran dispersi6n en el criterio emitidopor los expertos, se sugiere someterla a Una segunda ronda de evaluaci6n.

Paso5: Identificar el nivel de importancia de cada competencia para el desempeo de cadarol. Al culminar el paso anterior, para todos los roles se identificaron: las competenciasrequeridas, las no requeridas y las que debian ser sometidas a Una segunda ronda. Sinembargo, entre las competencias requeridas no resultaba muy claro precisar, en Una partede los casos, el grado de importancia de cada Una por la dispersi6n de los datos. Estehecho puede tener su explicaci6n en la poca formalizaci6n que existen, en la mayor partede las empresas, de los roles y las competencias necesarias para enfrentar los proyectosde software. Los autores del trabajo decidieron transformar los datos obtenidos con laescala de Va|ores de 1 a 5, tomando en consideraci6n Una escala ms simple, capaz dereflejar la informaci6n esencial obtenida bajo la escala anterior y que a su vez resultaramas fcil de utilizar por los expertos aI enfrentarse a la segunda ronda (este cambio deescala constituye Una modificaci6n en la aplicaci6n del mtodo Delphi). La nueva escalacontempla tres valores:

2- la competencia es requerida en un alto por ciento.1- la competencia es necesaria en alguna medida.0- la competencia no es necesaria.

Al procesar todos los roles aplicando la nueva escala se obtuvo la matriz que se muestraen la Figura 3. Las celdas en blanco indican que esa competencia para ese rol debe sersometida a la segunda ronda. Asi, para el caso del rol jefe de proyecto es posible decirque las competencias 22 y 25 deben someterse a la segunda ronda, la competencia 21es necesaria en alguna medida y el resto de las competencias son muy importantes parael desempeo del rol.

Para utilizar un modelo formal en la asignaci6n de personal a proyectos de software comoel propuesto en (Andr, 2008; Rodriguez, 2008), y teniendo en cuenta que se deseamaximizar las competencias requeridas por las personas que asumiran los diferentes rolesnecesarios en un proyecto, se propone un procedimiento para determinar un indice decompetencia de cada persona en el desempeo de cada rol asignado aI proyecto. Paraello se tiene en cuenta, para cada rol, tanto el nivel que tiene cada persona relacionadocon las diferentes competencias necesarias para el rol, como el grado de importancia dedichas competencias para dicho rol.

COlll|3etefbCiaS genfiCaIS Cotnpef etbciaS T ClffCaSCotnpef etbciaS T cnicas

dole do prococo 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2

Olsenador Gfaflco 2 2 O 2 1 2 2 2 2 1 1 2 2 O 0 2

Gestor de Cambfos 2 2 2 2 2 2 1 2 1 2 2 2 2 2 2 2 2 2 2 1 1 1 1 2

6estor de Confiquraoi6n 2 1 1 2 1 2 1 1 2 2 2 1 1 2 1 1 1 ! 2Afqnitecto 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2Espociafista de Seqnridad 2 2 1 2 1 2 2 2 2 1 2 2 2 2 2 2 1 0 2AnaRsta 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2Ol5eZador 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2Oisei5ador de Oase de Oatos 2 2 1 1 2 2 1 2 2 2 1 2 2 2 2 2 2 2 2 2 0 2

Promamadov 2 2 2 2 2 2 2 2 1 2 1 2 2 2 2 2

Oocumontador 2 1 1 0 1 1 1 2 2 1 2 2 O O 0 2 2 2

PfOdOf 2 1 0 1 2 1 2 1 2 1 0 0 2EspiaRsta de CaRdad 2 2 2 2 1 2 1 2 2 2 2 2 2 2 2 2 0 ! 2

defe Pf oeoto 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 0 2Especialista Opelracional 2 2 1 2 2 1 1 2 2 2 2 2 2 2 2 2 O 0 2

Espiafista T5cnfco 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2

Fig. 3. Matriz que contiene los resultados de la primera Fonda.

Sean:Rj: el conjunto de competencias requeridas para desempenar el rol jpsh: nivel que tiene la persona s en relaci6n a la competencia h, h C Rjihj: importancia de la competencia h para desempehar el rol j; h C Rjwhj: peso que representa la importancia de la competencia h para desempearh C RjSe quiere determinar:csj: capacidad de la persona s para desempehar el rol jEntonces:

whj = i tal que S whj - 1S ihj h c RJ.

h CR.J

Csj " S Whj * Pshh CR.

J

el fol j;

Ejemplo de c6mo determinar uno de dichos indices:En la organizaci6n para ejecutar un proyecto se precisan dos roles: A y B y unaen cada rol.Para el rol A se requieren las competencias: c I , c3 y c5 .Entonces, RA = { I , 3, 5}Se utiliza una escala de cuatro Va|ores (1, 2, 3 y 4) para evaluar la importanciacompetencia en cada rol

Para el rol A: ilA = 1; i3A = 4; i5A = 2Para la persona X los niveles de cada competencia (en una escala de 1 al 5) son:

Pxl = 5, Px3= 1, PX5 = 2Entonces:

WIA = 1/7; W3A = 4/7; W5A = 2/7;Y la capacidad de la persona X para desempear el rol A se determina como:

CXA= wlA* pxl+ w3A* pX3 + w5A* pX5 = (1/7)*5 + (4/7)*1 + (2/7)*2 = 13/7

persona

de cada

Si Se requiere, es posible indicar un valor minimo para cada competencia para eldesempeho de cada rol.Sea uhj el valor minimo requerido de la competencia h para desempehar el rol j; h C RjEntonces debe cumplirse quepih uhj cualesquiera Sean los Va|ores i, h, j

Gestionar los recursos humanos basados en el enfoque por competencias resulta muynecesario para las organizaciones de software ya que permite preservar y desarrollar supersonal en Una industria donde la tecnologia cambia de manera vertiginosa. Los recursoshumanos constituyen el factor menos formalizado en los mode|Os y metodologfas dedesarrollo de software, las cuales no ofrecen un marco de referencia bien formalizado,que contenga claramente definidas las competencias genericas y tcnicas requeridas paradesempehar cada rol establecido acorde a las caracteristicas del proyecto.

La propuesta de roles invariantes para enfrentar proyectos de desarrollo e implantaci6nde software, y de competencias tanto tcnicas como genricas para el desempeho delos roles propuestos constituye un punto de partida para la implantaci6n de esta practicaen las empresas de software cubanas. Asimismo los procedimientos descritos paraidentificar las competencias requeridas en el desempeo de cada rol y la importanciade cada competencia en el rol, asi como la determinaci6n del indice de competencia decada persona para desempehar cada rol asignado al proyecto, representa Una guia parapoder enfrentar el proceso de asignaci6n de personal a proyectos de software de formamas objetiva.

Acuha, S.T. Capabilities-Oriented Integral Software Process Model. Ph.D. Thesis.Universidad Politecnica de Madrid, Madrid, 2002.

Beck, K. Extreme Programming Explained. Embrace Change. Addison-Wesley, 1999. 224

Andre, M. Roles definidos por el Proceso Unificado de Rational. Reporte de Investigacionesdel CEIS, 2005 . ISBN: 959-261-1 79-3 .

Andre, M., M.G. Baldoquin, S.T. Acuha, A. Rosete. A formalized model for the assignmentof human resources to software projects. XIV Latin Ibero-American Congress onOperations Research (CLAIO 2008). Colombia: 2008, ISBN 978 958 825283-4.

Cockburn, A. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, 2005.

Cuesta, A. Tecnologia de Gesti6n de Recursos Humanos. Academia, 2005.

DeMarco T. T. Lister. Peopleware: Productives Projects and Teams. Dorset House, 1999.

245 p.