1

PROPUESTA DE MEJORAMIENTO PARA EL DESEMPEÑO LABORAL EN EL PROYECTO DE CONSORCIO EN INTERGRUPO S.A

NIKOLAS FERNEY GRISALES MARIN CÓDIGO: 537903

UNIVERSIDAD CATÓLICA DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA INDUSTRIAL ALTERNATIVA PRÁCTICA EMPRESARIAL

BOGOTÁ 2017

2

PROPUESTA DE MEJORAMIENTO PARA EL DESEMPEÑO LABORAL EN EL PROYECTO DE CONSORCIO EN INTERGRUPO S.A

NIKOLAS FERNEY GRISALES MARIN

CÓDIGO: 537903

Trabajo de Grado para optar al título de Ingeniero Industrial

Director Claudia Constanza Jiménez Carranza

Ingeniera industrial

UNIVERSIDAD CATÓLICA DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA INDUSTRIAL ALTERNATIVA PRÁCTICA EMPRESARIAL

BOGOTÁ 2017

3

4

Nota de Aceptación

_______________________________ _______________________________ _______________________________ _______________________________ _______________________________

______________________________ Firma del Presidente del Jurado

______________________________ Firma del Jurado

______________________________ Firma del Jurado

Bogotá, 20, noviembre, 2017

5

CONTENIDO

pág.

INTRODUCCIÓN 10 1. GENERALIDADES 11 1.1 ANTECEDENTES 11 1.2 PLANTEAMIENTO DEL PROBLEMA 11

1.2.1 Descripción del problema. 11 1.2.2 Formulación del problema. 14 1.3 OBJETIVOS 14

1.3.1 Objetivo general. 14 1.3.2 Objetivos específicos. 15 1.4 JUSTIFICACIÓN 15

1.5 DELIMITACIÓN 16 1.5.1 Espacio. 16 1.5.2 Tiempo. 16

1.5.3 Contenido. 16 1.5.4 Alcance. 17

1.6 MARCO REFERENCIAL 17 1.6.1 Marco teórico. 17 1.6.1.1 Indicadores de gestión. 17

1.6.1.2 Desempeño laboral. 17

1.6.1.3 Calidad. 17 1.6.1.4 Mejora continua. 17 1.6.1.5 Software. 18

1.6.1.6 Norma ISO 10667 2014. 18 1.6.1.7 Medición en procesos software. 18 1.6.1.8 Norma ISO/IEC 12207. 18

1.6.1.9 Norma ISO 9000:2000. 18 1.6.1.10 Evaluación del desempeño laboral. 19 1.6.1.11 Capacitación del trabajador. 19 1.6.1.12 Casos de uso 19

1.6.1.13 Metodologías agiles 20 1.6.1.14 Propiedad del código fuente 20

1.6.1.15 Humanware. 20 1.7 METODOLOGIA 22 1.7.1 Tipo de estudio. 22 1.7.2 Fuentes de información 22 1.8 DISEÑO METODOLÓGICO 23

2. RECOPILACIÓN Y ANALISIS DE INFORMACIÓN 24 2.1 RECOLECCIÓN DE DATOS 24 2.1.1 Recolección de solicitudes. 27

6

pág.

2.1.2 Recolección de devoluciones. 28 2.1.3 Recolección de reporte de horas. 29

2.2 ANÁLISIS DE DATOS 29 2.2.1 Análisis de solicitudes. 29 2.2.2 Análisis de devoluciones. 32 2.2.3 Análisis de reportes de horas 34 3. COMPARACIÓN DE FUNCIONES DE COLABORADORES CON FALLAS ANALIZADAS 36 3.1 DETERMINACIÓN DE CAUSAS 36

3.2 COMPETENCIAS DEL DESARROLLADOR 38 3.3 PLAN DE CAPACITACION 39 3.3.1 Objetivo de la capacitación. 39

3.3.2 Audiencia 39 3.3.3 Metodología. 39 3.3.4 Resultados. 40

4. HERRAMIENTAS PARA EL SEGUIMIENTO DEL DESEMPEÑO LABORAL 41

4.1 ESTRUCTURA DE LAS HERRAMIENTAS 41 4.2 HERRAMIENTA DE BÚSQUEDA 41 4.2.1 Estructura de la herramienta de búsqueda 41

4.2.2 Pilotaje del manejo de la herramienta. 43

4.2.3 Ventajas. 44 4.3 HERRAMIENTA DE CONTROL A ESTIMACIONES 45 4.3.1 Estructura de la herramienta de control. 46

4.3.2 Ventajas. 47 5. CONCLUSIONES 48

6. RECOMENDACIONES 49 BIBLIOGRAFÍA 50

7

LISTA DE FIGURAS

pág.

Figura 1. Descripción del Proceso 14 Figura 2. Ubicación del Proyecto 16 Figura 3. Descripción Metodológica 23 Figura 4. Solicitud Incidente en Pruebas 24 Figura 5. Solicitud Correctivo 25

Figura 6. Solicitud Mejora 26 Figura 7. Solicitudes 2015-2017 30 Figura 8. Grafica de Control P 32

Figura 9. Devoluciones 2017 32 Figura 10. Devoluciones Detalladas 2017 33 Figura 11. Bugtracker Trabajador 1 (Julio - Agosto) 2017 33

Figura 12. Bugtracker Trabajador 2 (Julio- Agosto) 2017 34 Figura 13. Indicador de Adherencia General 35 Figura 14. Indicador por Colaborador 35

Figura 15. Grafica de Pareto 37

8

LISTA DE CUADROS

pág.

Cuadro 1. Base de Datos 12 Cuadro 2. Resumen de Solicitudes 28 Cuadro 3. Bugstracker 28 Cuadro 4. Plantilla Reporte de Horas 29 Cuadro 5. Límites de Carta P. 31

Cuadro 6. Categorías y Posibles Fallas de los Bugs 36 Cuadro 7. Cálculos en el Análisis de Pareto 37 Cuadro 8. Formato de Búsqueda 42

Cuadro 9. Plantilla de Resultados 43 Cuadro 10. Resultados de la Búsqueda del Coordinador 44 Cuadro 11. Resultados de la Búsqueda del Analista 44

Cuadro 12. Asignación de Tiempos 46 Cuadro 13. Plantilla Tiempos de Respuesta 47

9

RESUMEN En el siguiente trabajo, se realizó la propuesta de seguimiento y control para el desempeño laboral para el proyecto de Consorcio en la organización INTERGRUPO S.A, enfocado a las competencias y funciones de los colaboradores, dado que no se venía llevando un control acerca de estas características ni se tenía una herramienta que ayudara a llevar dicho control. De acuerdo a lo anterior, se buscó diseñar herramientas de seguimiento que llevaran a cabo el control de ciertas funciones que realizan los desarrolladores del proyecto, realizando un análisis de carácter interno, como lo fueron el seguimiento de horas y actividades diarias, devoluciones internas y externas o también llamados Bugtracker de las Mantis, y estimaciones de tiempos de respuesta, obteniendo como resultados una lista de capacitaciones que se realizaran para poder reforzar la habilidades, competencias y así llevar a cabalidad sus funciones esto con apoyo de la plantilla en la herramienta Excel para su respectivo control. Palabras Clave: Bugtracker, Competencias, Desempeño laboral, Mantis, seguimiento y control.

10

INTRODUCCIÓN La empresa INTERGRUPO S.A se dedica a la producción y control de software para diferentes organizaciones reconocidas como lo son: Compensar, Comfenalco, Caja Social entre otras a lo largo del territorio nacional e internacional como lo son Philips Morris, Weatherford entre otras, de acuerdo con las necesidades y requerimientos de la empresa, se pretende realizar la propuesta para el mejoramiento y el seguimiento de algunos indicadores de gestión para el proyecto consorcio en el cual sus clientes son las empresas nombradas anteriormente, y así poder llevar con mayor facilidad el control del proyecto. Con el desarrollo de esta propuesta lo que se desea es ver reflejada un progreso en el cumplimiento de objetivos por cada colaborador del proyecto y cumplimiento de los estándares de calidad. Dichas mejoras, se espera tengan impacto en la productividad de la empresa, además de lograr mayor satisfacción en los clientes; al ver que se da solución a sus requerimientos formulados en los aplicativos (llamados “mantis” dentro de la organización). El fin de este proyecto es crear una herramienta que facilite y ayude a tener un seguimiento más riguroso y poder generar estrategias de mejora, para ciertas medidas de desempeño y un correcto seguimiento de los mismos. Para esto se parte de la información que suministra el cliente con sus peticiones, quejas, reclamos y opinión al momento de realizar la entrega de la mejora, correctivo o incidente presentado en el desarrollo del proceso. Teniendo en cuenta tiempos de trabajo estipulados, número de devoluciones de inconsistencias por parte del cliente y por parte de los analistas de pruebas internos. El documento está dividido por capítulos en los cuales se tratan principalmente los objetivos establecidos, estos capítulos llevan la información de la recolección de datos e información y análisis para poder llevar a cabo estrategias que mejoren el desempeño laboral de los colaboradores de la organización, con la ayuda de archivos automatizados y no automatizados que serán la base fundamental para poder llevar el control y facilitar el trabajo de los colaboradores. con el resultado arrojado por medio de herramientas de análisis como cartas de control, grafico de Pareto entre otras se puedo llegar a detectar ciertas falencias en el proceso, las cuales estaban afectando la calidad del proyecto y penalizando el mismo. Con la ayuda de capacitaciones se tiene gran favorabilidad para la mejora del personal y así mismo del proyecto en sí, aumentando los niveles de calidad y generando nuevas estrategias a futuro.

11

1. GENERALIDADES 1.1 ANTECEDENTES El mejoramiento de procesos en organizaciones dedicadas al desarrollo de software se ha convertido en parte fundamental para la organización, el control y monitoreo de esta actividad, va ligado al cumplimiento de objetivos y la implementación de mejoras, como se evidencia en la organización.

Intergrupo fue fundada en Medellín por Darío Solórzano (quien es el CEO del ‘holding’ Intergrupo) en el año de 1996, como una compañía enfocada en la creación de soluciones y servicios de TI. Antes de crearla, su ahora presidente (quien es ingeniero de sistemas de Eafit) había tenido experiencia como vicepresidente administrativo de SAM, gerente general de Softland y vicepresidente de planeación y tecnología de Conconcreto. Actualmente, la compañía tiene 6 unidades de negocio: IT Services, digital, cloud, Mobile, connect (en la que unifican los canales de comunicación de los clientes) y Biz Solutions (donde ofrecen servicios complementarios sobre la plataforma SAP). Respecto a la competencia, Solórzano dice que ha sido emocionante entenderse de ‘tú a tú’ con grandes multinacionales, especialmente de origen español e indio, y que el secreto de su éxito está en la diferenciación de su oferta.1

1.2 PLANTEAMIENTO DEL PROBLEMA 1.2.1 Descripción del problema. Las solicitudes que llegan al proyecto de consorcio ya sean solicitudes de fallos con los aplicativos, errores en el momento de generar un certificado, problemas con la interfaz del aplicativo, entre otras solicitudes provenientes de los aplicativos, que son interpuestas por medio de sus clientes, son recibidos por el aplicativo interno y partiendo de ahí se sigue con el conducto regular para su respectiva solución, en el proceso de solución se debe llevar un control de devoluciones y del tiempo que cada colaborador dentro del proyecto ejecuta en cada solicitud del cliente, toda esta información se ve reflejada en múltiples archivos que maneja la organización y no están estructuradas, simplemente esta información está ahí, sin ser materia de análisis en su totalidad. Partiendo de este hecho no se llevan algunos controles que se deberían tener en cuenta para el óptimo funcionamiento de la organización (véase el Cuadro 1).

1 PORTAFOLIO. Una historia de emprendimiento con acento país [en línea]. Bogotá: Portafolio [citado 14

noviembre, 2017]. Disponible en Internet: <URL: http://www.portafolio.co/negocios/empresas/intergrupo-cerrara-ano-presencia-10-paises-84724>

12

Cuadro 1. Base de Datos

Fuente. PROYECTO CONSORCIO. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual. Como se puede evidenciar existen varias tipologías de solicitudes (véase el Cuadro 1), con diferentes conceptos, que hacen parte de los diferentes aplicativos a los cuales se les realiza el seguimiento y mejoras. La base de datos muestra la información completa de la solicitud del cliente y su caracterización, en la primera columna se ve reflejado el aplicativo en el cual el cliente interpuso su solicitud, en la segunda columna se muestra el “ID”, este es el numero con el cual se identifica la solicitud, en la siguiente columna “ID PADRE” es el número que identifica un incidente en pruebas, es decir, al cliente interponer su solicitud y en medio del proceso se encuentra algún error se creara una nueva solicitud con un “ID” diferente pero será relacionado al “ID” inicial, en la columna “DETALLE” se especifica la solicitud o falla del cliente en el aplicativo, la categoría indica que tipo de solicitud fue interpuesta estas pueden ser mejoras, tareas correctivos o incidentes en pruebas, el “ESTADO” indica en que parte del proceso se encuentra la solicitud, y la columna de “ASIGNACION” muestra la fecha en la cual fue interpuesta la solicitud. Las solicitudes no necesariamente pasarán por todos los estados, estos son transformados por los colaboradores cuando superan una fase del proceso. y se pueden presentar en estas solicitudes y sus características fueron expuestos por

la coordinadora del proyecto () La solicitud al ser creada, tomará el estado de Asignada y será fijada a algún ingeniero de desarrollo para su respectivo análisis, el ingeniero dictaminará si la solicitud toma el estado de “se necesitan más datos” que hace referencia cuando el cliente no es muy específico con el problema o hace falta algún tipo de información, si la solicitud no toma este estado tomará el estado de implementada. La solicitud tomará este estado en el momento que el desarrollador finaliza con el

ENTREVISTA con Ana Carolina Rodríguez, Coordinadora de proyectos. Bogotá, 10 de agosto de 2017.

13

procedimiento de solución, y el analista de pruebas le da el visto bueno al procedimiento. Posteriormente, esta solicitud será motivo de pruebas por parte del analista o tester en el ambiente de pruebas del cliente, al no presentarse ningún inconveniente con la solicitud en el ambiente el analista procederá a cambiar el estado de la solicitud a estado resuelto. El cliente realizará las pruebas en el ambiente respectivo, si al realizar estas, se presenta algún error el cliente devolverá la solicitud a estado implementada, de no presentarse ningún error el cliente aprobará la solicitud y su estado será confirmado. Al estar en estado confirmado, se realiza el paso a producción, es decir, se notifica que ya se puede realizar la instalación real para que el usuario final ya pueda interactuar con el aplicativo, este paso se solicita los días martes hasta las 2pm y generalmente el cliente lo instala el domingo próximo de solicitar el paso a producción. Al momento de conocer el proceso, se ve que toda esta información no está plasmada en herramientas de medición, los programas que maneja la compañía internamente para poder obtener esta información son capaces de exportar esta información en archivos de Excel y por este medio se planea realizar un correcto seguimiento y posteriormente la mejora para la utilización de estos recursos tecnológicos. Toda esta información solo puede ser visualizada por el grupo de trabajo de consorcio por medio de una carpeta compartida en el servidor, aunque por medio de procedimientos del área de tecnología se podrá compartir. El proceso que se lleva en el proyecto consorcio cuenta con diferentes etapas en las cuales incluye desarrollo, pruebas y análisis, el cliente radica una solicitud o falla en alguno de los aplicativos, automáticamente esta se radica en la base de datos, el analista de pruebas recibe la solicitud y genera una estimación de tiempos, esto para saber el tiempo de duración que se tendrá en cuenta para dar solución a la falla o solicitud, esta estimación es enviada al cliente y será aprobada por el mismo, si el cliente no aprueba esta estimación se hará un ajuste a los tiempos, si es aprobada se realiza el plan de trabajo interno, teniendo en cuenta los tiempos estimados, posteriormente la solicitud se le hará llegar al desarrollador quien es el encargado de realizar el procedimiento de solución, al terminar el desarrollo, la solicitud tendrá que pasar por el analista de pruebas o tester, realizará las pruebas pertinentes y hará el paso para que el cliente realice pruebas y confirme el desarrollo, al aprobar el desarrollo tanto el cliente como el analista de pruebas interno o tester se dará paso a producción y se implementará la solicitud en la página o aplicativo para que el usuario pueda tener acceso a ella.

14

De esta manera se lleva a cabo el proceso en el proyecto, quedando todo documentado en el aplicativo de control, pero como se indicó anteriormente esta información no es de análisis, por ende, queda almacenada y no es estudiada (véase la Figura 1). Figura 1. Descripción del Proceso

Fuente. El Autor. 1.2.2 Formulación del problema. ¿Qué estrategias se pueden formular para realizar el seguimiento y mejora de las medidas de desempeño laboral de consorcio en INTERGRUPO SA?. 1.3 OBJETIVOS 1.3.1 Objetivo general. Proponer estrategias de mejora para el desempeño laboral del proyecto consorcio en INTERGRUPO S.A

15

1.3.2 Objetivos específicos. Recopilar y analizar la información actual de reportes de horas y devoluciones internas y externas. Comparar las funciones con las fallas analizadas en el proceso de desarrollo en el proyecto consorcio. Estructurar herramientas para el seguimiento del desempeño laboral de los colaboradores del proyecto consorcio. 1.4 JUSTIFICACIÓN Para la empresa INTERGRUPO S.A, es de vital importancia realizar la control de medidas de desempeño ya que son estas los que permitirán llevar un control de estos estándares tanto de calidad como de cumplimiento de objetivos, la medición en la organización permitirá reconocer las debilidades de los distintos procesos que serán medidos por medio de indicadores y así poder realizar un análisis de las causas por las cuales se vienen presentando fallas, teniendo claras las falencias se procederá a proponer estrategias de mejora. Uno de los principales factores que hacen proponer estas estrategias de mejora y seguimiento es el poder aumentar la calidad interna, ya sea individual como del grupo en general mostrando resultados óptimos al cliente sin que la organización sea penalizada. El proyecto consorcio cuenta con el seguimiento y manejo de 5 aplicativos (SICU, OYS, PORTICO, TRANSACCIONES EN LINEA, GEHOS) que son de uso de operadores y usuarios de Compensar y Comfenalco el usuario al presentar algún tipo de fallo en el aplicativo lo remite al operador, de allí el operador genera un caso llamado “mantis” con un consecutivo con el cual quedara registrado en una base de datos de la organización, con un concepto, este concepto es la clasificación de la solicitud del cliente, mediante esta descripción se evidenció que no se lleva un control acerca de estas falencias aunque cabe resaltar que toda la información está en distintos archivos, pero no está integrada para poder ver lo que sucede por tanto no es materia de análisis. Además, al evidenciar que toda la información está en el sistema, pero no está estructurada ni medida, nace esta iniciativa de implementación y seguimiento.

16

1.5 DELIMITACIÓN 1.5.1 Espacio. Este proceso se llevará a cabo en la oficina principal de INTERGRUPO S.A en Bogotá Colombia en el centro empresarial connecta ubicada en la dirección Av. Calle 26 No. 92-32 Edificio Terranvm piso 3 de la localidad de Fontibón (véase la Figura 2). Figura 2. Ubicación del Proyecto

Fuente. GOOGLE MAPS. Aplicación satelital [en línea]. Bogotá: Google Maps [citado 2 agosto, 2017]. Disponible en Internet: < URL: https: //maps.google.es.>

1.5.2 Tiempo. Este proceso está proyectado realizarlo en cinco (5) meses este

tiempo estipulado en la duración de las prácticas empresariales.

1.5.3 Contenido. Los temas que se desarrollan durante el trabajo son:

Generalidades Propuesta de estrategias de mejora y seguimiento sobre las tareas que se llevan a cabo en la organización. Realizar el análisis causal de falencias en los procesos y así poder establecer estas estrategias las cuales ayuden a mejorar el proceso. Conclusiones

17

1.5.4 Alcance. Las actividades a realizar en el tiempo estipulado serán para el

proyecto de consorcio de INTERGRUPO S.A, estas actividades serán ejecutadas

desde la recopilación de información, hasta la entrega de las propuestas. Para el

proceso en el que el cliente realice la solicitud hasta que el proceso quede cerrado

y sea entregada la mejora o solución en el aplicativo para que el usuario pueda

realizar los trámites pertinentes.

1.6 MARCO REFERENCIAL

1.6.1 Marco teórico. 1.6.1.1 Indicadores de gestión. “Hace énfasis a datos esencialmente cuantitativos, que permiten darnos cuenta como se encuentran las cosas en relación a ciertos aspectos de la realidad que nos interesa conocer. Los indicadores pueden ser medidas, números, hechos, opiniones o percepciones que señalen condiciones o situaciones específicas”2. 1.6.1.2 Desempeño laboral. Se define desempeño como “aquellas acciones o comportamientos observados en los empleados que son relevantes para los objetivos de la organización, y que pueden ser medidos en términos de las competencias de cada individuo y su nivel de contribución a la empresa’’3 1.6.1.3 Calidad.

El primer supuesto erróneo es que calidad significa bueno, lujoso, brillo o peso. La palabra "calidad" es usada para darle el significado relativo a frases como "buena calidad", "mala calidad" y ahora a "calidad de vida". Calidad de vida es un cliché porque cada receptor asume que el orador dice exactamente lo que él (ella) "el receptor", quiere decir. Esa es precisamente la razón por la que definimos calidad como "Conformidad con requerimientos", si así es como lo vamos a manejar.... Esto es lo mismo en negocios. Los requerimientos tienen que estar claramente establecidos para que no haya malentendidos. Las mediciones deben ser tomadas continuamente para determinar conformidad con esos requerimientos. La no conformidad detectada es una ausencia de calidad. Los problemas de calidad se convierten en problemas de no conformidad y la calidad se convierte en definición4.

1.6.1.4 Mejora continua. ‘’La mejora continua es lo que nos permite sobrevivir al mercado. Algunas veces se piensa que se ha llegado a un nivel que no permite mejorar, en un mundo cambiante tomar la actitud de que se ha llegado a la cima

2 GARCIA MORA, Luis. Marco general indicadores de gestión. Indicadores de la gestión logística. Bogotá:

Ecoe, 2007. p.27 3 MONTEJO PEREZ, Anna. Evaluación del Desempeño Laboral [en línea]. Bogotá: Academía.edu [citado 15

agosto, 2017]. Disponible en Internet: <URL: http://www.academia.edu/7265132/Evaluaci%C3%B3n_del_ Dese mpe%C3%B1o_Laboral> 4 CROSBY, Philip. Quality is Free. The Art of Making Quality Certain: How to Manage Quality. New York: Mc

Graw Hill, 1979. p. 22

18

es quedarse obsoleto todos los días, la mejora continua se tiene que dar con el desempeño de la propia organización a través del tiempo y luego compararse con los competidores’’5 1.6.1.5 Software. “Conjunto de datos y programas que maneja el ordenador. Es la parte lógica o inmaterial de un sistema informático. Almacenados en el ordenador en forma de ceros y unos.”6 1.6.1.6 Norma ISO 10667 2014.

La norma ISO 10667 es la evaluación de personas en entornos laborales y organizacionales. La evaluación se debe entender en sentido amplio, puesto que la norma es de aplicación a evaluaciones a lo largo de todo el ciclo de vida laboral y abarca supuestos de evaluación individual (entrevistas, orientación profesional, desarrollo personal, coaching, selección, planificación del relevo profesional), evaluación grupal (evaluación del nivel de compromiso grupal, evaluación del desempeño para mejora del rendimiento del equipo) y evaluación organizacional (clima laboral, evaluación de riesgos psicosociales7.

1.6.1.7 Medición en procesos software. “La medición juega un papel fundamental en las organizaciones que pretenden incrementar el grado de madurez en sus procesos a través de la mejora de procesos de software. Este hecho se demuestra observando el tratamiento e importancia que los modelos relacionados con la mejora de procesos de software le dan al proceso de medición.”8

1.6.1.8 Norma ISO/IEC 12207. “Describe los procesos del ciclo de vida del software y explícitamente define en el grupo de procesos de gestión un “proceso de medición”; el propósito de ´este es recolectar y analizar los datos relacionados con los productos desarrollados y procesos implementados al interior de la organización en sus proyectos, y apoyar la gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos.”9

1.6.1.9 Norma ISO 9000:2000. “Establece la necesidad de implementar el proceso de medición con el objetivo de controlar la calidad del producto, la capacidad del proceso y la satisfacción del cliente. La gestión usa medidas como una entrada

5 NAVA CARBEDILLO, Víctor y JIMENEZ VALADEZ, Ana. ISO 9000-2000: estrategias para implantar la

norma de calidad par a la mejora continua. México: Limusa, 2002. p. 23 6

RODRÍGUEZ ARAGÓN, Licesio J. Tema 3: Software: Sistemas Operativos y Aplicaciones [en línea]. Madrid: IBTEMA [citado 12 agosto, 2017]. Disponible en Internet: <URL: https://previa.uclm.es/profesorado/licesio /Docencia/IB/IBTema3a.pdf> 7

BARBERO, Luis. Capital Humano. En: Language: Spanish. Marzo – abril, 2014. vol. 27, no. 284, p. 96. 8 VASQUEZ, Diana. Modelo liviano de medidas para evaluar la mejora de procesos de desarrollo de software

MLM-PDS. En: Ingeniería y Ciencia. Julio – agosto, 2010. vol. 6, no.12, p. 13. 9 Ibíd., p. 13.

19

fundamental para la planificación, control y gestión del proyecto; todo ello orientado a la mejora continua del proceso”10. 1.6.1.10 Evaluación del desempeño laboral.

Se puede considerar como un procedimiento estructural y sistemático para medir, evaluar e influir sobre los atributos, comportamientos y resultados relacionados con el trabajo, así como el grado de ausentismo, con el fin de descubrir en qué medida es productivo el empleado y si podrá mejorar su rendimiento futuro, que permite implantar nuevas políticas de compensación, mejora el desempeño, ayuda a tomar decisiones de ascensos o de ubicación, permite determinar si existe la necesidad de volver a capacitar, detectar errores en el diseño del puesto y ayuda a observar si existen problemas personales que afecten a la persona en el desempeño del cargo. Los principales objetivos de la evaluación del desempeño no pueden restringirse a un simple juicio superficial y unilateral del jefe respecto del comportamiento funcional del subordinado; es necesario descender más profundamente, localizar las causas y establecer perspectivas de común acuerdo con el evaluado. La evaluación le da al trabajador la oportunidad para hacer autoevaluación y autocrítica para su autodesarrollo y autocontrol. Con ella se estimula el trabajo en equipo y se procura desarrollar las acciones pertinentes para motivar a la persona y conseguir su identificación con los objetivos de la empresa. Es un instrumento para mantener una relación de justicia y equidad con todos los trabajadores. Estimula a los empleados para que brinden a la organización sus mejores esfuerzos y vela por que esa lealtad y entrega sean debidamente recompensadas. Atiende con prontitud los problemas y conflictos, y si es necesario toma las medidas disciplinarias que se justifican. Estimula la capacitación entre los evaluados y la preparación para las promociones11.

1.6.1.11 Capacitación del trabajador. “Los programas de capacitación producen

resultados favorables en el 80% de los casos. El objetivo de ésta es proporcionar

información y un contenido específico al cargo o promover la imitación de

modelos, se considera que los programas formales de entrenamiento cubren poco

las necesidades reales del puesto, las quejas se dan porque formalmente casi

todo el mundo en la organización siente que le falta capacitación”12.

1.6.1.12 Casos de uso. “Los casos de uso son una técnica para especificar el

comportamiento de un sistema. Los casos de uso permiten entonces describir la

posible secuencia de interacciones entre el sistema y uno o más actores, en

respuesta a un estímulo inicial proveniente de un actor, es una descripción de un

10

Ibíd., p. 13 11

MONTEJO PEREZ, Op. Cit., p.2. 12

QUINTERO, Niria, AFRICANO, Nelly, FARIA, Elsis, Clima Organizacional y Desempeño Laboral del Personal Empresa Vigilantes Asociados Costa Oriental Del Lago. Negotium [en línea]. Bogotá: Negotium [citado 14 noviembre, 2017] Disponible en Internet: <URL: http://www.redalyc.org/articulo.oa?id=78230903>

20

conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde

un actor hacia el sistema”13.

1.6.1.13 Metodologías agiles. “Las metodologías ágiles emergen como una

posible respuesta para llenar un vacío metodológico. Por estar especialmente

orientadas para proyectos pequeños, las metodologías ágiles constituyen una

solución a medida para ese entorno, aportando una elevada simplificación que a

pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del

producto”14.

1.6.1.14 Propiedad del código fuente. “En los contratos para el desarrollo de

programas de computador, la entrega del código fuente es uno de los puntos

materia de negociación, de la mano de la discusión sobre la titularidad de los

derechos de autor respecto del software resultante. La posesión del código fuente

determina la posibilidad de efectuar cualquier modificación o actualización del

programa de computador”15.

1.6.1.15 Humanware.

El concepto de Humanware fue propuesto por Shimada para dar cuenta de esa tecnología depositada en las conciencias humanas y en la conducta individual y colectiva de la producción. El Humanware (la tecnología que toma cuerpo en el hombre) es una de las claves esenciales de la espectacular alza de la productividad alcanzada por las industrias japonesas y los implantes toyotistas en Occidente (Shimada, 1993: 24). El futuro de la producción capitalista no depende solo de la tecnología digital, sino también de la intersección del Humanware la nueva forma de producción tecno-humana con las telecomunicaciones, la computación y los autómatas bajo control numérico. La clave de su funcionamiento, el secreto de los incrementos de la productividad, es el óptimo aprovechamiento del trabajo en conjunción con sus complementos: la maquinaria y los insumos.16

13

ARIAS CHAVES, Michael, La ingeniería de requerimientos y su importancia en el desarrollo de proyectos de software [en línea]. Bogotá: InterSedes: Revista de las Sedes Regionales [citado 14 noviembre, 2017]. Disponible en Internet: <URL: <http://www.redalyc.org/articulo.oa?id=66612870011> ISSN 2215-2458> 14

LETELIER, Patricio y PENADÉS, Carmen. Metodologías ágiles para el desarrollo de software: extreme Programming (XP). En: CyTA. Abril - junio, 2006. vol. 5, no. 26, p. 3. 15

MONROY, Juan Carlos. Cuestiones jurídicas entorno a los contratos de desarrollo y licencia de software [en línea]. Bogotá: Proquest [citado 14 noviembre, 2017]. Disponible en Internet: <URL: https://search-proquest-com.ezproxyucdc.ucatolica.edu.co/docview/1438751562/abstract/17A5E8A96E334233PQ/3?accountid=4566 0> 16

ORTEGA, Mario. Análisis de la producción antropocéntrica en una empresa telefónica [en línea]. Bogotá: Universidad Católica de Colombia [citado 14 noviembre, 2017]. Disponible en Internet: <URL: https://search-proquest-com.ezproxyucdc.ucatolica.edu.co/docview/1677598029?accountid=45660>

21

1.6.1.16 Competencia y tipos.

La competencia es el conjunto de los conocimientos, cualidades, capacidades, y aptitudes que permiten discutir, consultar y decidir sobre lo que concierne al trabajo. Supone conocimientos razonados, ya que se considera que no hay competencia completa si los conocimientos teóricos no son acompañados por las cualidades y la capacidad que permita ejecutar las decisiones que dicha competencia sugiere, existen varios tipos de competencia como lo son: Competencia en el puesto de trabajo (Job): competencia de la persona en un rol determinado en una empresa determinada. Competencia ocupacional/profesional: se acercaría a la idea de cualificación (en el sentido de nivel de calificación) porque implica que la persona tiene un repertorio de destrezas, conocimientos y comprensiones, que puede ocupar en una gama de contextos y organizaciones. Competencias genéricas: serían aquellas que aseguran la transferibilidad de destrezas ocupacionales porque se refieren a comportamientos asociados con desempeños comunes a diversas organizaciones y ramas de actividad productiva (habilidad para analizar, interpretar, organizar, negociar, etcétera). Meta-competencias: aquellas que operan en función de otras competencias. Competencias básicas: comportamientos elementales que deberán mostrar los trabajadores, tales como conocimientos de índole formativa (lectura, redacción, aritmética, etcétera). Competencias de empleabilidad: las necesarias para obtener un trabajo de calidad. Podrían equivaler a las competencias básicas. Competencias interpersonales, organizacionales o sociales: las que permiten mantener relaciones humanas y laborales con fluidez, trabajar en equipo y comunicarse en general. Competencias técnicas o específicas: aquellos comportamientos de índole técnico vinculados a un cierto lenguaje o función productiva. Competencias sistémicas: aquellas que permiten aproximarse a la realidad en su complejidad de relaciones y no como un conjunto de hechos aislados. Competencias tecnológicas: las que facultan el conocimiento y uso de tecnologías usuales17.

17

VARGAS, Maritza; JARABA, Bruno y ROMERO, Lidia. Competencias laborales y la formación universitaria.

En: Psicología desde el Caribe. Noviembre – diciembre, 2005. no. 16, p. 76.

22

1.7 METODOLOGIA 1.7.1 Tipo de estudio. Como lo indicaron Roberto Hernández, Carlos Fernández

y María del pilar Baptista18 en su libro se puede evidenciar que en el presente

trabajo se presenta un enfoque cuantitativo puesto que parte de una idea o

problema que va acotándose, y a partir de allí nacen preguntas y objetivos, de

estas preguntas se generan ciertas opciones de respuestas y partiendo de esto,

se diseña un plan para poder analizarlas, medirlas y controlarlas, se hace la

recolección de datos y se fundamenta en las mediciones realizadas. Cabe resaltar

que estas mediciones son representadas con números y deben ser analizados con

métodos estadísticos.

Este tipo de estudio cuantitativo nos permite analizar muestras de un grupo o segmento, en este caso poder analizar ciertos desempeños del grupo de colaboradores. Es de vital importancia resaltar que este estudio no solo se basa en lo cuantitativo también presenta aspectos cualitativos que son desarrolladas a lo largo del estudio del presente trabajo. La parte cualitativa del trabajo se enfoca en desarrollar preguntas antes, durante o después de la recolección de datos es un proceso de forma circular ya que con frecuencia es necesario volver a etapas previas, ya que las opciones no serán probadas, estas se van generando durante el proceso y se van puliendo mientras se vaya recaudando datos e información. No se efectúa una medición numérica por tal motivo el estudio no es estadístico, es más una recolección de datos por medio de los colaboradores como puntos de vista, experiencias y otros aspectos subjetivos. Estos tipos de estudio son enfocados a un alcance descriptivo, es decir busca especificar ciertas propiedades, características, procesos entre otras, de variables que sean sometidos a un análisis previo. 1.7.2 Fuentes de información. Como fuentes primarias de información se usará: Documentación interna de la organización. Entrevistas con la ingeniería a cargo del proyecto. Datos de colaboradores.

Como fuentes secundarias se tendrá en cuenta: Internet.

18

HERNANDEZ, Roberto, FERNANDEZ, Carlos y BAPTISTA, María del Pilar. Metodología de la investigación. 5 ed. México: Mc Graw Hill, 2010. p. 44

23

Bases de datos externas. Libros virtuales. 1.8 DISEÑO METODOLÓGICO Para poder realizar la propuesta se basa en iniciar con la organización y materialización de toda la información que se encuentra en los distintos aplicativos para que posteriormente sea analizada esta información y por medio de herramientas ofimáticas se tendrá un balance general de como el proyecto se ha comportado tanto en años anteriores como en la actualidad, generar un comparativo en cuanto al tiempo y poder tener más clara y ordenada la información. Se hará un estudio causal con herramientas como diagrama de ‘’espina de pescado’’ o diagrama de Pareto entre otras, esto con el fin de poder identificar las causas y poder por medio de herramientas de gestión proponer estrategias de mejora para el proyecto (véase la Figura 3). Figura 3. Descripción Metodológica

Fuente. El Autor.

24

2. RECOPILACIÓN Y ANALISIS DE INFORMACIÓN 2.1 RECOLECCIÓN DE DATOS Con el propósito de generar estrategias de mejora para el desempeño laboral y organización de datos e información para facilitar el trabajo de los colaboradores y coordinadora de proyecto, se evidencia que toda la información necesaria para generar controles sobre el proceso se puede extraer, pero no ha sido organizada ni analizada, simplemente la información está ahí. Se ha hecho una recolección de datos de ciertos aplicativos que maneja el proyecto donde cada colaborador registra lo hecho en cada caso mantis o solicitud, toda esta información tiene la opción de ser descargada en un formato Excel para su manipulación y de allí poder presentar ciertos modelos que nos permite realizar este programa de office. Para la recolección de datos se realizaron las siguientes preguntas: ¿Qué información se necesita descargar? ¿la información a descargar desde que año va a ser tomada? Estas y otras preguntas que se realizaron para poder descargar toda esta información. A lo que se llega a respuestas concretas de cómo se realizara la descarga de todas las solicitudes que se han generado desde el año 2015 hasta la actualidad. A continuación, se relacionarán los tipos de solicitud que son interpuestos por el cliente (véase la Figura 4). Figura 4. Solicitud Incidente en Pruebas

Fuente. PROYECTO CONSORCIO. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual.

25

Este tipo de solicitudes hace referencia a un error diferente al solicitado inicialmente en el aplicativo, este segundo error para ser tomado como incidente en pruebas debe ser generado o evidenciado en la parte de desarrollo y pruebas, y este error es uno de los que afecta la calidad del proceso. Por otro lado, existe otro tipo de solicitud el cual también afecta la calidad del proceso que son los correctivos (véase la Figura 5) con su correspondiente descripción. Figura 5. Solicitud Correctivo

Fuente. PROYECTO CONSORCIO. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual. La solicitud con categoría correctivo es error generado o evidenciado en el área de producción, es decir cuando ya se ha resuelto el primer error y es montado para que el cliente pueda hacer uso de la aplicación sin errores, pero si al momento de montar la solución, el cliente evidencia que sigue presentándose la falla u otra diferente es tomado como correctivo, y este afecta la calidad del proceso. Existen otros dos tipos de solicitudes que son las tareas y mejoras, están solicitudes son requerimientos del cliente, pero no hacen alusión a un error en la aplicación sino a algo adicional que se quiere plasmar en el aplicativo (véase la Figura 6).

26

Figura 6. Solicitud Mejora

Fuente. PROYECTO CONSORCIO. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual. Estas solicitudes al ser generadas llegan al aplicativo del proyecto y mediante este se lleva el proceso respectivo. El aplicativo llamado “herramienta gestión de solicitudes” permite la recepción de estas solicitudes generando un histórico de estas mismas, toda esta información nunca era analizada a fondo, para la recolección de datos se realizó la descarga de estos archivos en su totalidad. Además, se realizó la descarga del histórico de Bugs o errores generados por los desarrolladores del proyecto en el momento de hacer la respectiva programación para la solución de la solicitud, ya que esta información no era tenida en cuenta. Esto con el fin de llevar un mejor control de los errores que eran generados por cada uno de los colaboradores y así poder tomar ciertas medidas. Los Bugs fueron tomados desde el inicio del proyecto para así llevar una estadística por colaborador, aunque en la actualidad ha habido cambios en cuanto a los colaboradores, es decir ya algunos no hacen parte del proyecto al igual se realizó el descargue del historial de estos por medio de otro aplicativo del proyecto llamado “Testing bug tracking system” allí es depositada toda la información por parte del analista de pruebas, consignando el número de errores que son encontrados en la fase de desarrollo por los desarrolladores (véase la Figura 7).

27

Figura 1. Tarea

Fuente. PROYECTO CONSORCIO. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual. Al identificar la información que se va a ser descargar para su respectivo análisis y control, se consigna en una base de datos en la herramienta Excel, con el fin de poder realizar variaciones y filtros de esta información para así poder tener ciertas estadísticas o ayudas visuales como graficas o diagramas que ayuden en el proceso. Se dividió en varios archivos para poder llevar por aparte cada estadística y poder generar reportes que muestren como está funcionando la operación. 2.1.1 Recolección de solicitudes. Al realizar el consolidado de cada mantis que

sean de categoría correctivo e incidente en pruebas, tanto histórico como el actual

para llevar el control mensual, por otra parte, se realizó el descargue del histórico

de mantis que eran generadas desde el 2015 esto con el fin de analizar

anualmente el número de solicitudes que han sido interpuestas y que categorías

manejaban para así llevar un control por categoría y generar un reporte.

Al realizar la recopilación de esta información y ya consolidarla sobre la herramienta Excel se realiza el descargue de todas las solicitudes que han llegado al proyecto desde el 2015 para el frente de demanda y para los 5 aplicativos que se manejan (véase el Cuadro 2).

28

Cuadro 2. Resumen de Solicitudes

Fuente. El Autor Por medio de la herramienta Excel se realizó el descargue de estas solicitudes y por medio de una tabla dinámica (véase al Cuadro 2) se dio orden a la información y mediante filtros resaltar la información que se requiere para poder analizar su comportamiento en el transcurso de los años 2015-2017, cabe resaltar que esta plantilla de Excel fue creada por el autor para el uso de la compañía, que posteriormente se vaya alimentando de información mensual y llevar ese control y así poder presentar resultados a los clientes en informes mensuales. 2.1.2 Recolección de devoluciones. Posteriormente se realiza el descargue de

las devoluciones internas a cada colaborador, estas devoluciones hacen alusión a

los errores cometidos por los desarrolladores en el momento de realizar su

configuración en el mantis, cuando el desarrollador termina su procedimiento,

informa al analista de pruebas quien es el encargado de realizar las pruebas y

detectar si hubo errores cometidos por el desarrollador, estos errores son

reportados por la aplicación y el mantis es devuelto al desarrollador para poder ser

corregido, estos errores son llamados bugtrakers o devoluciones internas. Como

en el paso anterior se organizó la información por medio de tablas dinámicas y

filtros en la herramienta Excel (véase el Cuadro 3).

Cuadro 3. Bugstracker

Row Labels Count of Categoría

trabajador 1 9

trabajador 2 11

trabajador 3 1

trabajador 4 93

trabajador 5 2

Grand Total 116 Fuente. El Autor El resumen de estas devoluciones (véase el Cuadro 1) nos indicará número de devoluciones por cada empleado en el transcurso del año, la información descargada será actualizada mensualmente y así se llevará el control y el registro de estas devoluciones internas.

29

2.1.3 Recolección de reporte de horas. Otro descargue de información será el

reporte de horas por trabajador quien debe cumplir con 9 horas productivas y 1

hora administrativa, cada colaborador debe dejar consignado por medio de notas

aclaratorias, el tiempo y el proceso que realizo en cada mantis y así poder tener

claro que el trabajador si cumple con sus 9 horas productivas, este reporte de

tiempos se realiza manualmente y se consolida por un trabajador, se realizó una

plantilla en la herramienta Excel la cual permite llevar el indicador de adherencia

ya que estos trabajadores no consignan sus horas todos los días, por tal motivo se

realiza el descargue de esta información a diario (véase el Cuadro 4).

Cuadro 4. Plantilla Reporte de Horas Nombre Fecha inicio Fecha de corte Horas a corte Horas realizadas Horas faltantes IND

Trabajador 1 2/10/2017 3/10/2017 18 11,00 7,00 61,11%

Trabajador 2 2/10/2017 3/10/2017 18 18,00 0,00 100,00%

Trabajador 3 2/10/2017 3/10/2017 18 3,00 15,00 16,67%

Trabajador 4 2/10/2017 3/10/2017 18 18,00 0,00 100,00%

Trabajador 5 2/10/2017 3/10/2017 18 13,50 4,50 75,00%

Trabajador 6 2/10/2017 3/10/2017 18 0,00 18,00 0,00%

Trabajador 7 2/10/2017 3/10/2017 18 18,00 0,00 100,00%

TOTAL 126 81,5 44,50

DIAS 2

TOTAL HORAS MES 1323

TOTAL HORAS A CORTE126

cumplimiento de

horas indicador corte

TOTAL HORAS REALIZADAS

POR COLABORADORES 81,5 6,16% 64,68%

TOTAL HORAS FALTANTES 44,5

NOTA:

Fuente. El Autor 2.2 ANÁLISIS DE DATOS

Para el análisis de datos toda la información que fue descargada es motivo de

estudio para poder presentar estrategias de mejora, mediante gráficas y recursos

de la herramienta Excel entre otras.

2.2.1 Análisis de solicitudes. Para el análisis de solicitudes estas solicitudes son

las encargadas de dictaminar la calidad del trabajo que se está realizando por

parte de los colaboradores, como se mencionó anteriormente, los correctivos e

incidencias en pruebas influyen de forma negativa en el proceso ya que estos

indican que el proceso repercutió en otras fallas o simplemente no se trabajó la

30

solicitud de la mejor manera, a comparación de las tareas y mejoras estas son las

encargadas de mejorar algo en los aplicativos que no presentan fallas, como una

actualización o simplemente agregar algo que no estaba, estas solicitudes ayudan

a el proyecto , ya que el cliente pagara adicionalmente estas solicitudes.

Al realizar el descargue de las solicitudes se realizó un consolidado anual por

categoría y de allí se pudo dictaminar que el número de solicitudes que afectaban

el proceso había disminuido (véase la Figura 7).

Figura 7. Solicitudes 2015-2017

Fuente. El Autor

A pesar de que aún hace falta algunos meses para cerrar el año la proporción de

solicitudes es menor en cuanto a correctivos e incidentes de los años pasados, se

superó el número de tareas del año pasado y está cerca de alcanzar las mejoras

en relación al año pasado. La tendencia en solicitudes es hacia la mejora, esto

mostrándonos que los colaboradores están realizando mejor su trabajo.

Se realiza un análisis por medio de la carta de control por atributos P, esta

herramienta nos mostrara la proporción de artículos con errores en nuestro caso,

se realizó un consolidado mes a mes desde el año 2015 con la cantidad de

solicitudes y número de errores de ese mes. Llegando a obtener ciertos límites de

control (véase el Cuadro 5).

31

Cuadro 5. Límites de Carta P. año mes cantidad mantis con errores PI LCI LC LCS

2015 febrero 7 7 1 0,369 0,581 0,958

2015 marzo 19 6 0,316 0,369 0,581 0,958 Pbarra 0,66358

2015 abril 2 2 1 0,369 0,581 0,958

2015 mayo 8 4 0,500 0,369 0,581 0,958

2015 junio 5 3 0,600 0,369 0,581 0,958

2015 julio 12 2 0,167 0,369 0,581 0,958

2015 agosto 12 1 0,083 0,369 0,581 0,958

2016 enero 8 8 1 0,369 0,581 0,958

2016 febrero 19 17 0,895 0,369 0,581 0,958

2016 marzo 29 26 0,897 0,369 0,581 0,958

2016 abril 38 26 0,684 0,369 0,581 0,958

2016 mayo 23 17 0,739 0,369 0,581 0,958

2016 junio 32 25 0,781 0,369 0,581 0,958

2016 julio 39 20 0,513 0,369 0,581 0,958

2016 agosto 15 14 0,933 0,369 0,581 0,958

2016 septiembre 30 16 0,533 0,369 0,581 0,958

2016 octubre 36 28 0,778 0,369 0,581 0,958

2016 noviembre 46 26 0,565 0,369 0,581 0,958

2017 enero 36 28 0,778 0,369 0,581 0,958

2017 febrero 42 27 0,643 0,369 0,581 0,958

2017 marzo 32 23 0,719 0,369 0,581 0,958

2017 abril 19 10 0,526 0,369 0,581 0,958

2017 mayo 30 23 0,767 0,369 0,581 0,958

2017 junio 33 21 0,636 0,369 0,581 0,958

2017 julio 15 14 0,933 0,369 0,581 0,958

2017 agosto 20 13 0,650 0,369 0,581 0,958

2017 septiembre 41 23 0,561 0,369 0,581 0,958

648 430 18,20total Fuente. El Autor.

Teniendo establecidos los límites de control y la media, se procede a graficar esta

información y así poder visualizar si hay meses en los cuales se excede los

límites, con el fin de indagar por qué ese mes no se cumplió con los requisitos y

poder tomar medidas correctivas y preventivas.

Se evidencia que en 6 meses hubo altos niveles de error en las solicitudes (véase

la Figura 8).

32

Figura 8. Grafica de Control P

Fuente. El Autor.

2.2.2 Análisis de devoluciones. Las devoluciones internas o Bugstracker

permiten determinar cuántas veces falla el colaborador en el momento de realizar

el proceso en la mantis, estas devoluciones únicamente se le asignan al

desarrollador y el notificador es el analista de pruebas, con el descargue de esta

información se pudo tener un consolidado de loes errores internos y así poder

tomar ciertas medidas (véase la Figura 9)

Figura 9. Devoluciones 2017

Fuente. El Autor

Mensualmente, se realiza la actualización del archivo para así poder determinar

los colaboradores con más fallas en el proceso de desarrollo, en que mantis lo

presento y la fecha en la cual se reportó (véase la Figura 10).

33

Figura 10. Devoluciones Detalladas 2017

Fuente. El Autor

Se tiene más detallada la información y así poder verificar que paso ese día y en

cual mantis fue el error y así poder tomar medidas en cuanto al desarrollo de la

mantis (véase la Figura 11).

Figura 11. Bugtracker Trabajador 1 (Julio - Agosto) 2017

Fuente. El Autor

Se evidenció que había colaboradores con muchas devoluciones internas en el

proyecto (véase la Figura 9), esto pudiendo llevar a consecuencias como nuevos

correctivos e incidentes que afectarían la calidad del proyecto.

Se realiza el comparativo para el desarrollador 1 quien presentaba un alto índice

de devoluciones, y un desarrollador 2 quién sería el remplazo para el desarrollador

2, y se registra una disminución de devoluciones en el mismo tiempo laborado (2

meses), se analiza que el desarrollador 2 cuenta con más conocimientos en

34

cuanto al tema de desarrollo, esta comparativo se realiza en base a los meses de

julio y agosto del 2017, en los cuales trabajaron los mismos aplicativos.

Y este indicador de devoluciones internas tuvo una gran disminución cuando llegó

el trabajador 2, como se indicaba anteriormente esta información no es analizada

ni tenida en cuenta por la organización, se realiza esta comparación ya que se

pretende saber las causas reales de porque se presentan estas devoluciones que

pueden causar repercusiones en la calidad de cara al cliente, y teniendo estas

causas poder llegar a tratarlas y generar medidas preventivas y correctivas (véase

la Figura 12).

Figura 12. Bugtracker Trabajador 2 (Julio- Agosto) 2017

Fuente. El Autor.

2.2.3 Análisis de reportes de horas. Mediante el reporte de horas se verifica el

cumplimento de horas por parte de los colaboradores este indicador de adherencia

se saca a diario y se reporta a los colaboradores para que realicen el registro en el

aplicativo.

Los colaboradores están en la obligación de reportar sus tiempos ya que con el

tiempo esto puede afectar su nómina.

La plantilla fue creada por el autor ya que anteriormente no se manejaba este tipo

de controles, el saber al finalizar el día, la semana, o el mes como va su indicador

(véase la Figura 13).

35

Figura 13. Indicador de Adherencia General

Fuente. El Autor.

Es mediante este tipo de gráficas que la coordinadora del proyecto muestra las

estadísticas al cliente para poder corroborar la información y saber cómo se está

comportando el proyecto en cuanto a tiempos. Para un control interno más

exhausto, se tiene el indicador por colaborador (véase la Figura 14).

Figura 14. Indicador por Colaborador

Fuente. El Autor.

36

3. COMPARACIÓN DE FUNCIONES DE COLABORADORES CON FALLAS ANALIZADAS

3.1 DETERMINACIÓN DE CAUSAS

Por medio del análisis realizado en el capítulo anterior donde se realizó el análisis

de las devoluciones internas, se pretende comparar las funciones de los

colaboradores de desarrollo con las fallas cometidas anteriormente y así poder

tener en cuenta las posibles causas y efectos que pueden llevar a futuros errores,

de esta manera poder generar medidas preventivas y correctivas. Por parte de los

desarrolladores quienes son los encargados de realizar la programación por medio

de lenguajes de programación se evidencio un gran número de devoluciones

internas, por lo cual se entra a mirar sus principales causas y poder atacarlas.

Como primer paso se determina que la problemática es el alto número de

devoluciones internas generadas en el proyecto por parte de los analistas a los

desarrolladores.

Como segundo paso se dictaminan las causas por las cuales se está generando

estas devoluciones en el periodo analizado anteriormente (2015-2017). Estas

devoluciones internas pueden ser de 3 categorías que desglosan varias causas

por las cuales se genera la devolución. Esta información fue expuesta por la

analista de pruebas principal (véase el Cuadro 6).

Cuadro 6. Categorías y Posibles Fallas de los Bugs CATEGORIA DESCRIPCION POSIBLES CAUSAS

Funcional

No cumple con lo especificado, reglas del caso de uso, flujos alternos, condiciones, validaciones etc.

* Error de interpretación del caso de uso * No se realizan preguntas después de leer el documento * No se lee el documento de la solicitud

Diseño

Errores en los diagramas de diseño (clases, secuencia, estados, colaboración etc.) que afectan la funcionalidad

* No se lee el documento de la solicitud. * Desconcentración

Despliegue

Errores que se presentan cuando se están realizando pruebas de instalación. Falta de componentes, dll´s, que no son de configuración. Cuando los instaladores dejan basura en el Registro de Windows, entre otros.

* Afán. * Desconocimiento.

* Falta de experiencia. * Falta de concentración

Revisión par

Errores que se generan en revisiones pares de diferentes disciplinas del proyecto. Se debe seleccionar la disciplina correspondiente en la cual se detectó el error.

* Poco Análisis * No validar más soluciones.

Fuente. PROYECTO CONSORCIO. Analista de pruebas [CD-ROM]. [Bogotá]: La Empresa, 2014. Categorías Bugs.

37

Por medio de la herramienta Excel se realiza el cálculo de la cantidad de fallos por

categoría y se realiza cálculos en el análisis de Pareto (véase el Cuadro 7).

Cuadro 7. Cálculos en el Análisis de Pareto Causas

Descripción Cantidad % % AC

causa1 No cumple con lo especificado, reglas del caso de uso, flujos alternos, condiciones, validaciones etc.

89 76,72% 76,72%

causa2 Errores en los diagramas de diseño (clases, secuencia, estados, colaboración etc.) que afectan la funcionalidad

16 13,79% 90,52%

causa3

Errores que se presentan cuando se están realizando pruebas de instalación. Falta de componentes, dll´s, que no son de configuración. Cuando los instaladores dejan basura en el Registro de Windows, entre otros.

10 8,62% 99,14%

causa4 Errores que se generan en revisiones pares de diferentes disciplinas del proyecto. Se debe seleccionar la disciplina correspondiente en la cual se detectó el error.

1 0,86% 100,00%

TOTAL 116 100%

Fuente. El Autor.

Mediante esta herramienta resulta evidente que cuales son las causas más

frecuentes, se puede observar que las 2 primeras causas representan el 90.52%

(véase la Figura 15) de la totalidad de fallas y se concluye que las mayores causas

de errores son de la categoría funcional y de diseño, y de manera que si se

eliminan las causas que provocan las devoluciones internas estos mismos

disminuirán.

Figura 15. Grafica de Pareto

Fuente. El Autor.

38

3.2 COMPETENCIAS DEL DESARROLLADOR

Para INTERGRUPO S.A es de vital importancia hacerse de los mejores ingenieros de desarrollo y mejores profesionales es sus áreas respectivas, ya que mediante la calidad de sus colaboradores se cumplirán sus objetivos estratégicos.

Es así que el personal de talento humano y con apoyo del área de producción se enfocan en ciertos perfiles, estos de los ingenieros de desarrollo debe contener ciertas características especiales y conocimientos en ciertos lenguajes de programación para poder desempeñar su labor de la mejor manera, es decir, cumpliendo con los estándares de calidad en cuanto a tiempo de respuesta, eficiencia, y calidad de la solución. (véase el Cuadro 7). Cuadro 1. Competencias del Desarrollador

COMPETENCIAS ASOCIADAS AL CARGO

Orientación al servicio

Comunicación

Aprendizaje y aplicación del conocimiento

Liderazgo

Pensamiento analítico

Orientación hacia resultados

Fuente. PROYECTO CONSORCIO. Información de interés [CD-ROM]. [Bogotá]: La Empresa, 2014. Modelo de competencias perfiles y cargos. Según las potenciales causas analizadas que arrojó la gráfica de Pareto que fueron (no cumple con lo especificado, reglas del caso de uso, flujos alternos, condiciones, validaciones etc.) y (errores en los diagramas de diseño, clases, secuencia, estados, colaboración etc., que afectan la funcionalidad) y con base en las funciones del desarrollador, se evidencia que no se ha venido cumpliendo con el 100% de las funciones como indagar y tener un mayor contexto acerca del problema a tratar, determinación de varias alternativas para la posible solución, entre otras funciones, esto en relación con las competencias como la comunicación y pensamiento analítico que debe tener el desarrollador.

Adicionalmente con el estudio realizado anteriormente y teniendo claras las causas mayores de las devoluciones internas, se plantea un modelo de capacitación tanto de formación de software, outdoor training entre otras para poder preparar a los colaboradores a cambios de tecnologías, mejora de la concentración y un pensamiento analítico y crítico.

39

Reforzando estas competencias se pretende que las devoluciones internas disminuyan en gran cantidad, y esto ayude a evitar que se presenten devoluciones externas en un futuro. 3.3 PLAN DE CAPACITACION

Al establecer las causas por las cuales se vienen presentando estas

inconsistencias en el proceso del proyecto de consorcio, se pretende por medio de

capacitación reforzar estas competencias, y que de igual manera estas mismas

sea un punto de referencia para todos los proyectos de la organización

INTERGRUPO S.A.

3.3.1 Objetivo de la capacitación. El objetivo específico de la capacitación es el

refuerzo de competencias que necesitan refuerzo o desarrollado por parte de los

desarrolladores, y de esta manera cumplir con el trabajo solicitado, evitando

errores en el proceso. Se evidenció que el gran porcentaje de estos fallos va

relacionado a problemas de concentración, el no saber interpretar el requerimiento

del cliente y no realizar preguntas a los otros compañeros o al cliente en sí, un

pequeño porcentaje ira dedicado a la parte técnica del proceso, como lo es el

lenguaje de programación, las nuevas tecnologías, y procesos agiles.

3.3.2 Audiencia. Estas capacitaciones van dirigidas para los desarrolladores de

todos los proyectos sin importar su nivel que pueden ser desarrollador junior,

desarrollador intermedio o desarrollador senior. Cualquier nivel puede asistir a

esta capacitación que en parte ayudaran a formar profesionalmente a los

desarrolladores que aún no han llegado a un nivel superior.

Se pretende integrar cualquier tipo de desarrollador a las capacitaciones ya que

esto podría ser tenido en cuenta para un ascenso dentro de la misma organización

siempre y cuando cumpla con los conocimientos y requisitos que exige la

organización.

3.3.3 Metodología. Para el desarrollo de estas capacitaciones se tendrá en

cuenta el personal de la organización en principio, en segundo plano si fuese

necesario contratar una persona externa a la organización se validaría con el área

de recursos humanos según el tema el cual se quiera reforzar si la organización

no cuenta con algún profesional.

Cabe resaltar que estas capacitaciones deben ser muy lúdicas y no monótonas y

en esto es parte fundamental el capacitador, para tener buenos resultados se

necesita de una persona que cambie la forma de ver a las capacitaciones, ya que

se piensa que una capacitación es una charla aburrida.

40

Estas capacitaciones no solo ayudaran a reforzar las competencias o

conocimientos, la idea es fomentar un ambiente en el cual varias personas de

diferentes proyectos puedan interactuar, conocerse y así poder contribuir al

ambiente laboral mucho más ameno.

3.3.4 Resultados. Es de vital importancia poder medir el nivel de asistencia y

retroalimentar los resultados obtenidos mediante estas capacitaciones, tener en

cuenta la opinión del capacitado y así poder seguir trabajando en mejoras a los

procesos internos de la organización, esto ayudara a realizar mejoras o cambios

en la misma capacitación e ir adaptándose a otras áreas o trabajadores.

41

4. HERRAMIENTAS PARA EL SEGUIMIENTO DEL DESEMPEÑO LABORAL

4.1 ESTRUCTURA DE LAS HERRAMIENTAS

Por medio de la herramienta Excel se genera una plantilla para poder llevar acabo

el seguimiento de las estimaciones realizadas por el desarrollador, más una

plantilla que permita facilitar la búsqueda de cierta información de manera más ágil

y eficaz.

Esto con el fin de poder llevar un control rigoroso en el proceso de calidad del

proyecto consorcio y así poder cumplir con los objetivos estratégicos de procesos

internos de la organización.

Estas herramientas de control se realizarán con el complemento de “macro” en

Excel, principalmente se realizará el descargue de información y se actualizará la

tabla mes a mes manualmente y con la ayuda de la “macro” se podrá filtrar la

información según el criterio que se desee, generando alarmas para poder tomas

decisiones que ayuden a la mejora continua.

4.2 HERRAMIENTA DE BÚSQUEDA Esta herramienta facilitara el modo de búsqueda de las solicitudes que se encuentran en el archivo de “seguimiento y control” esto con el fin de que la persona que necesite realizar una búsqueda de manera fácil y rápida pueda realizarla escribiendo ciertos criterios de búsqueda y dando clic en un botón. El criterio de búsqueda se optó por la manera en la cual se realiza el seguimiento a estas solicitudes que generalmente es por el estado en el cual se encuentran las mismas, se podrá escribir el estado el cual se desea buscar y arrojara la cantidad de solicitudes que se encuentran en ese estado, otro criterio por el cual se opto fue el “responsable” ya que esto permitirá según el estado verificar quien está trabajando en esa solicitud. Cabe resaltar que del archivo de seguimiento se extraerá esta información, que será alimentada manualmente por la persona encargada. 4.2.1 Estructura de la herramienta de búsqueda. Esta herramienta será usada

mediante el programa de office Excel con su complemento “Excel”, en el archivo

de “seguimiento mantis”, este archivo cuenta con una pestaña la cual muestra

toda la información relevante sobre todas las solicitudes que llegan al proyecto

(véase el Cuadro 1), este archivo se actualiza de forma manual a medida que

llegan solicitudes, estas solicitudes el cliente las interpone en un aplicativo de la

organización llamado “herramienta de gestión de solicitudes” y se realiza un

comparativo “archivo Excel vs herramienta de gestión de solicitudes” esto con el

42

fin de verificar si una solitud cambio de estado, y así tener el control interno en el

proyecto.

Este control se lleva acabo con la siguiente información:

Aplicativo. Este ítem hace referencia al aplicativo para el cual se genera la solicitud. Responsable. Es el colaborador que está trabajando en el momento la solicitud. ID. Es el número por el cual se identifica la solicitud. Detalle. Es la descripción de la solicitud interpuesta por el cliente Categoría. Esto hace alusión al tipo de categoría la cual pueden tomar las diferentes solicitudes. Estado. Esto muestra en qué fase del proceso va la solicitud. Asignación. Esta columna nos muestra la fecha en la cual fue creada la solicitud.

En esta herramienta de búsqueda se agrega una nueva pestaña donde la macro arrojará la información solicitada por el usuario escribiendo los criterios de búsqueda, solo con un clic en un botón “ejecutar” esta será filtrada y mostrada con ciertos criterios relevantes (véase el Cuadro 8). Cuadro 8. Formato de Búsqueda

Fuente. El Autor.

43

Este botón fue ubicado en la parte superior de la hoja de Excel con el nombre de “ejecutar”, adicionalmente habrá dos campos en los cuales se podrá digitar los criterios de búsqueda que como se especificó anteriormente son estado y responsable (véase el Cuadro 8). Al diligenciar los criterios y darle click nos arrojara los datos más relevantes para la búsqueda como el mes, el “ID”, la categoría, fecha inicial y el responsable (véase el Cuadro 9). Cuadro 9. Plantilla de Resultados

Fuente. El Autor. Al realizar una búsqueda y extraer la información necesaria podrá limpiar los espacios con el botón “borrar” para realizar una nueva búsqueda (véase el Cuadro 8). 4.2.2 Pilotaje del manejo de la herramienta. A partir de las necesidades que se

visualizaron en el proceso de control, se realizó una prueba piloto para conocer la

efectividad del manejo de la información la cual se realizó a la coordinadora de

proyectos quien tiene acceso a esta información y es de su uso diario y también a

un analista de pruebas quien no utiliza esta información con frecuencia, pero la

conoce.

Se procede a realizar esta prueba piloto con el 25% de los trabajadores, este

porcentaje equivale a dos personas que son mencionadas anteriormente con su

cargo, se decide escoger estas dos personas ya que una de ellas es la encargada

de revisar y hacer consultas por lo cual tiene bastante contacto con el archivo, la

otra persona fue escogida ya que no tiene mucho contacto con el archivo y es

esporádica la interacción con esta información se tiene en cuenta una persona que

44

interactúe frecuentemente para saber si le es útil, y con una persona quien no

tenga mucha interacción con la información y así poder determinar si es entendible

el manejo y la funcionabilidad de la herramienta.

El pilotaje realizado fue una pequeña prueba de búsqueda en la cual el

colaborador realizo una búsqueda detallada de una solicitud con su respectivo

responsable y estado.

Este pilotaje arrojo básicamente tres aspectos muy importantes los cuales van

ligados al objetivo de la herramienta y estos son:

El primer aspecto es la utilidad de la herramienta, el segundo aspecto es el nivel

de dificultad para realizar la búsqueda, y el tercer aspecto el tiempo en el que se

llevó a cabo una búsqueda, y se consignó en una tabla por cada colaborador

(véase el Cuadro 10 y 11).

Cuadro 10. Resultados de la Búsqueda del Coordinador

Coordinador de proyecto. Aspectos SI NO Observaciones

¿Le parece útil la herramienta?

X Ya que esta reduce tiempos facilita el trabajo.

¿Es difícil de usar o entender?

X

¿Reduce tiempos en la búsqueda?

X

Fuente. El Autor.

Cuadro 11. Resultados de la Búsqueda del Analista

Analista de Pruebas Aspectos SI NO Observaciones

¿Le parece útil la herramienta? X

¿Es difícil de usar o entender?

X

¿Reduce tiempos en la

búsqueda? X

Esta tarea a veces podía tardar mucho tiempo para las personas que no manejan

muy seguido esta información.

Fuente. El Autor.

4.2.3 Ventajas. Esta herramienta cuenta con varias ventajas en el proyecto ya

que ayuda a los colaboradores a realizar búsquedas de información de manera

más ágil y eficaz, ayudando a ser más productivos.

45

Otra de las ventajas es el acceso de la información ya que antes se realizaba por

medio del aplicativo que funcionaba con internet este control o búsqueda se puede

realizar sin tener conexión a internet.

Y por último otra ventaja que nos presenta esta herramienta es la organización de

datos, esta puede organizar la información de acuerdo a como se solicite.

4.3 HERRAMIENTA DE CONTROL A ESTIMACIONES

Esta herramienta se diseña por la necesidad de llevar un control más rigoroso

como una medida preventiva y correctiva así poder generar alarmas para llevar un

seguimiento, verificar causas y poder tratarlas en cuanto a las estimaciones de

tiempo generadas por los desarrolladores.

El objetivo final es tratar estas alarmas y que a futuro no se vuelvan a repetir, ya

que al realizar dichas estimaciones se incurren en tiempos muertos y esto influye

en el retraso de las actividades.

Esta estimación la realizan los desarrolladores en el momento que el analista de

pruebas les asigna la solicitud, posteriormente se estandarizo los tiempos de los

correctivos, incidentes en pruebas, tareas y mejoras. Este estándar se declaró

desde el momento que la solicitud es interpuesta al momento que la solicitud pasa

a estado resuelto.

Los correctivos y mejoras menores cuentan con 40 horas, incidentes en pruebas,

tareas, estas cuentan con 24 horas, estos tiempos son establecidos internamente

(véase el Cuadro 12).

Adicionalmente se cuentan con las mejoras mayores, estas solicitudes cuentan

con un nivel de complejidad alto por ende no se puede estandarizar el tiempo, es

necesario que el desarrollador verifique la complejidad de la solicitud y partiendo

de allí pueda generar un diagnóstico para poder asignar el tiempo que el crea que

es necesario para dar solución a la solicitud, teniendo en cuenta esta información,

por políticas de la coordinadora del proyecto ninguna de las solicitudes puede

tener más de 9 horas de lo establecido o tener las mismas por debajo.

Al momento de la asignación de solicitudes y al tener una mala estimación se

puede correr todo el plan de trabajo teniendo demoras al entregar la solución, los

tiempos de respuesta son de vital importancia ya que el cliente tiene un

cronograma que se puede ver afectado por estas malas estimaciones.

46

Cuadro 12. Asignación de Tiempos

Fuente. PROYECTO CONSORCIO. Tiempos de solución [CD-ROM]. [Bogotá]: La Empresa, 2017. Tiempos de asignación. Este control se realiza de forma semanal por parte de la persona encargada, para

generar alarmas a las solicitudes que sobrepasaron con los tiempos y agilizar

tiempos, en tal caso que sea imposible reducir los tiempos por cuestiones de

complejidad poder tener una medida preventiva que ayude a realizar una mejor

estimación de tiempos por medio de capacitaciones o formaciones que la misma

organización puede brindar, solo hay que solicitarlas.

4.3.1 Estructura de la herramienta de control. Esta herramienta diseñada por

medio de Excel con una formulación de condicionales, alimentada de una pestaña

que será diligenciada a diario con las nuevas solicitudes que lleguen al proyecto.

Esta herramienta se crea con la necesidad de llevar el control de manera rápida y

sencilla, las celdas de esta herramienta en su gran mayoría cuentan con fórmulas

condicionales que evitan que la persona que llevara el control digite información,

por el contrario, al escribir cierta palabra esta ya se actualizara en algunos

campos.

Esta plantilla cuenta con ciertas columnas con información relevante para poder

llevar el control y el seguimiento como lo son:

Aplicativo. Este ítem hace referencia al aplicativo para el cual se genera la solicitud. Categoría. Esto hace alusión al tipo de categoría la cual pueden tomar las diferentes solicitudes. Mantis. Es el numero por el cual se identifica la solicitud. Estado. Esto muestra en qué fase del proceso va la solicitud. Tiempo estimado. En esta columna se diligenciará de forma automática los tiempos estandarizados dependiendo de la categoría

47

Tiempo ejecutado. En esta columna se digitará los tiempos que realmente lleva la solicitud.

% ejecución. Nos mostrara el porcentaje sobre los tiempos, según la fórmula matemática:

Evaluación. En esta columna nos mostrara gráficamente si la solitud cumple o no con los tiempos de respuesta, con una equis o con un check.

Esta herramienta está formulada para que de manera rápida se lleve el control

solo digitando el número de la solicitud, la categoría y las horas ejecutadas, nos

arroje la evaluación de los tiempos de la solicitud (véase el Cuadro 13).

Cuadro 13. Plantilla Tiempos de Respuesta

Fuente. El Autor

4.3.2 Ventajas. La ventaja que ofrece esta herramienta es la ayuda a gestionar

los tiempos de respuesta, ya que la organización no contaba con una herramienta

ni un análisis del tiempo que se requería para poder dar solución a las solicitudes,

no se tenía en cuenta que esto hace parte de la satisfacción del cliente en cuanto

a tiempos de respuesta.

Aparte de esto, esta herramienta es de fácil manejo y ayudara a optimizar los

tiempos de ejecución, tomar medidas correctivas y preventivas, con el fin de evitar

sobre tiempos o tiempos muertos dando respuesta de manera eficaz y a su vez

evitando penalizaciones por parte del cliente.

48

5. CONCLUSIONES Se identifica que el personal no tiene claridad de todas las funciones y competencias que se deben tener por parte de la mayor cantidad de desarrolladores del proyecto, lo que causa que a la hora de dar solución a una solicitud interpuesta sin tener claridad en lo que realmente solicita el cliente, por esta causa se procede a generar errores. La realización del presente trabajo ha permitido desarrollar una herramienta de búsqueda que permite consultar la información de las solicitudes de una manera más ágil por campos de mucha relevancia, disminuyendo los errores de los trabajadores a la hora de buscar la información o actualizar la misma. La plantilla realizada permitirá el seguimiento más amigable de las estimaciones y tiempos de respuesta a solicitudes. Para las personas que tengan que realizar dicho control y seguimiento. Gracias a estas plantillas se tendrá la información interna más ordenada para cuando se requiera realizar los informes mensuales del proyecto que se presenta con toda la información del mes al cliente para que evalué la operación.

49

6. RECOMENDACIONES Según el estudio realizado se recomienda capacitar a los trabajadores tanto desarrolladores como analistas de pruebas, para que puedan reforzar sus competencias y así cumplir con todas sus funciones de forma adecuada, para dar autonomía en el momento de tratar una solicitud. Es necesario llevar un control continuo de las estimaciones y tiempos de solución semanal, asignando una persona para que realice esta función de manera continua y rigorosa y así evitar tiempos muertos o sobre estimaciones Se recomienda la utilización de la plantilla de reporte de horas e incentivar de alguna manera a los trabajadores para realizar el reporte de horas de forma asertiva y puntual, ya que al no cumplir con las horas requeridas al mes el cliente puede llegar a tomar medidas. Se recomienda en el momento de realizar las capacitaciones retroalimentar los resultados obtenidos ayudando a generar o implementar las buenas prácticas en la organización.

50

BIBLIOGRAFÍA ARIAS CHAVES, Michael, La ingeniería de requerimientos y su importancia en el desarrollo de proyectos de software [en línea]. Bogotá: InterSedes: Revista de las Sedes Regionales [citado 14 noviembre, 2017]. Disponible en Internet: <URL: <http://www.redalyc.org/articulo.oa?id=66612870011> ISSN 2215-2458> BARBERO, Luis. Capital Humano. En: Language: Spanish. Marzo – abril, 2014. vol. 27, no. 284. CROSBY, Philip. Quality is Free. The Art of Making Quality Certain: How to Manage Quality. New York: Mc Graw Hill, 1979. 309 p. GARCIA MORA, Luis. Marco general indicadores de gestión. Indicadores de la gestión logística. Bogotá: Ecoe, 2007. 129 p. GOOGLE MAPS. Aplicación satelital [en línea]. Bogotá: La Empresa [citado 02 agosto, 2017]. Disponible en Internet: < URL: https: //maps.google.es.> HERNANDEZ, Roberto, FERNANDEZ, Carlos y BAPTISTA, María del Pilar. Metodología de la investigación. 5 ed. México: Mc Graw Hill, 2010. 560 p. LETELIER, Patricio y PENADÉS, Carmen. Metodologías ágiles para el desarrollo de software: extreme Programming (XP). En: CyTA. Abril - junio, 2006. vol. 5, no. 26. MONROY, Juan Carlos. Cuestiones jurídicas entorno a los contratos de desarrollo y licencia de software [en línea]. Bogotá: Proquest [citado 14 noviembre, 2017]. Disponible en Internet: <URL: https://search-proquest-com.ezproxyucdc.ucatolica. edu.co/docview/1438751562/abstract/17A5E8A96E334233PQ/3?accountid=4566 0> MONTEJO PEREZ, Anna. Evaluación del Desempeño Laboral [en línea]. Bogotá: Academía.edu [citado 15 agosto, 2017]. Disponible en Internet: <URL: http://www.academia.edu/7265132/Evaluaci%C3%B3n_del_Desempe%C3%B1o_Laboral> NAVA CARBEDILLO, Víctor y JIMENEZ VALADEZ, Ana. ISO 9000-2000: estrategias para implantar la norma de calidad par a la mejora continua. México: Limusa, 2002.139 p. ORTEGA, Mario. Análisis de la producción antropocéntrica en una empresa telefónica [en línea]. Bogotá: Universidad Católica de Colombia [citado 14 noviembre, 2017]. Disponible en Internet: <URL: https://search-proquest-com.ezproxyucdc.ucatolica.edu.co/docview/1677598029?accountid=45660>

51

PORTAFOLIO. Una historia de emprendimiento con acento país [en línea]. Bogotá: Portafolio [citado 14 noviembre, 2017]. Disponible en Internet: <URL: http://www.portafolio.co/negocios/empresas/intergrupo-cerrara-ano-presencia-10-paises-84724> PROYECTO CONSORCIO. Analista de pruebas [CD-ROM]. [Bogotá]: La Empresa, 2014. Categorías Bugs. -------. Control mantis [CD-ROM]. [Bogotá]: La Empresa, 2014. Seguimiento y control mantis mensual. -------. Información de interés [CD-ROM]. [Bogotá]: La Empresa, 2014. Modelo de competencias perfiles y cargos. -------. Tiempos de solución [CD-ROM]. [Bogotá]: La Empresa, 2017. Tiempos de asignación. QUINTERO, Niria, AFRICANO, Nelly, FARIA, Elsis, Clima Organizacional y Desempeño Laboral del Personal Empresa Vigilantes Asociados Costa Oriental Del Lago. Negotium [en línea]. Bogotá: Negotium [citado 14 noviembre, 2017] Disponible en Internet: <URL: http://www.redalyc.org/articulo.oa?id=78230903> RODRÍGUEZ ARAGÓN, Licesio J. Tema 3: Software: Sistemas Operativos y Aplicaciones [en línea]. Madrid: IBTEMA [citado 12 agosto, 2017]. Disponible en Internet: <URL: https://previa.uclm.es/profesorado/licesio /Docencia/IB/IBTema3a. pdf> VARGAS, Maritza; JARABA, Bruno y ROMERO, Lidia. Competencias laborales y la formación universitaria. En: Psicología desde el Caribe. Noviembre – diciembre, 2005. no. 16. VASQUEZ, Diana. Modelo liviano de medidas para evaluar la mejora de procesos de desarrollo de software MLM-PDS. En: Ingeniería y Ciencia. Julio – agosto, 2010. vol. 6, no.12.