Madurez e Innovación en el desarrollo de software: convergencia o conflicto

Maturity and Innovation in software development: convergence or conflict

Carlos Antonio Tonini, Mauro de Mesquita Spinola y José Manuel Cárdenas Medina

3. Estudio de caso múltiple

Buscando investigar como las empresas de software se enfrentan con las cuestiones de mejoría e innovación dentro de sus procesos de desarrollo, este artículo presenta el resultado de una pesquisa empírica, de naturaleza cualitativa, conducida por medio del método de Estudio de Casos Múltiplos (Yin, 1998). El uso de este método permitió entender los contextos empresariales específicos y los motivos que llevan a estas organizaciones a mejorar sus procesos y promover innovaciones (Claver et al., 2000).

La investigación fue realizada en dos organizaciones brasileras desarrolladoras de software que aplican sistemáticamente procedimientos de mejoría en sus procesos de desarrollo. La proposición que orientó la investigación fue que “la innovación es la condición básica para que la organización alcance un nivel más alto de calidad y madurez en el desarrollo de software”.

La elección de las empresas fue dada en función de la diversidad del negocio de las mismas. Mientras una de ellas atiende un único cliente y prioriza la estabilidad de sus procesos, la otra atiende el mercado en general y mantiene diversas líneas de productos para arquitecturas distintas. Para la colecta de datos, fueron realizadas entrevistas semi-estructuradas con gestores y desarrolladores en ambas organizaciones. El foco de las entrevistas fue entender los procesos de desarrollo de software, las mejoras ejecutadas en estos procesos y como estas actúan en términos de innovación en estos procesos. Las opiniones fueron confrontadas con el cuadro teórico, lo que permitió entender en que medida tienen adherencia con la literatura.

3.1. Caso 1

La Unidad de Análisis 1 (UA1) es un instituto de investigación con sede en el importante centro económico del Estado de São Paulo, fundado con el propósito de investigación y desarrollo de nuevas tecnologías de TI. Al inicio de sus operaciones, contó con el aporte de capital público en forma de incentivos fiscales. Con una gestión dinámica, orientada por las oportunidades del mercado, y una estructura pequeña, ágil, flexible, de bajo overhead y altamente calificada, tuvo sus procesos clave certificados según las normas de calidad ISO 9001 y de madurez pelo CMMI nivel 2 (1999), nivel 3 (2000), nivel 4 (2005) y nivel 5 (2007). Conviene notar que, es importante para la mayoría de los contratos, que UA1 tiene, demostrar alta maduración en los procesos de software, pues es uno de los requisitos de los contratos.

Por el hecho de viabilizar a los clientes los beneficios proporcionados por la Ley 11.077 de 30/12/2004, conocida como Ley de Informática (MCT/SPI, 2004), los proyectos celebrados con estos son de larga duración (mínimo de cinco años); para tanto, cada cliente es tratado como una unidad de negocio; los equipos son totalmente separados, gracias a la especialidad exigida por el cliente y al cierre del contrato, todo conocimiento producido y, algunas veces, también los ingenieros de software son transferidos para el cliente.

La recolección de los datos para este artículo fue realizada dentro de la unidad de negocio especialista en productos para la Tecnología de Información y Comunicación (TIC) e incluyó al gerente de desarrollo de la unidad de negocio de software embutido para teléfonos celulares y otros equipos de telecomunicación, un ingeniero de software y un analista de garantía de calidad. (quality assurance).

Para atender los diversos modelos de estructuración de procesos de software, UA1 desarrolló un modelo propio, altamente flexible y amplio. Es directriz corporativa solamente desarrollar proyectos de acuerdo con el modelo interno de desarrollo, independientemente de la exigencia del cliente. El modelo interno está totalmente alineado con las áreas de proceso del modelo de madurez CMMI y normas específicas, como la norma NBR ISO/IEC 12.207:1998 y, por esto, soporta cualquier modelo específico de  clientes específicos. Todos los procesos están definidos, conocidos, practicados estabilizados y estandarizados, lo que contribuye de forma positiva para entrenar y capacitar a los desarrolladores.

Cada proyecto representa una instancia del modelo patrón de procesos y contiene apenas aquellos procesos, prácticas y artefactos que son necesarios. Esta customización envuelve el nivel de actividades y tareas, manteniéndose el perfil a nivel de procesos, esto es, planeamiento, proyecto y ejecución. Tanto la producción de nuevos softwares, como el mantenimiento posterior, son realizados solamente mediante pedidos específicos.

Fue un hecho motivador y gratificante para los desarrolladores descubrir que la acción de “definir procesos de software” no significó nada mas que el hecho de traducir en palabras lo que realmente era ejecutado. Al comienzo, la resistencia fue grande, por la falta de conocimiento de como “describir el proceso”. Sin embargo, vencida la resistencia inicial, esto se transformó en un factor crítico de éxito (FCE) para mejorar los procesos de desarrollo.

Una parte del desarrollo es terceirizado, siendo que la gestión de los recursos humanos a veces es realizada internamente y a veces contratada. Todos los ingenieros de software, independientemente del hecho de ser mano de obra propia o tercerizada, reciben entrenamiento específico sobre los procesos de desarrollo adoptados por la UA1 y exigidos por los clientes. Las necesidades de entrenamiento son acusadas por las métricas de defectos posteriores a la entrega y de productividad. Además de esto, existe un flujo significativo de interés en entrenamiento por parte de los desarrolladores, en el sentido de capacitarse y contar con el apoyo de la organización (efecto sinérgico).

Una de las mayores dificultades apuntadas por UA1 reside en la capacitación de los gestores externos, cuando es realizada la contratación para el desarrollo de un producto. Vía de regla, los gestores externos son contrarios a cualquier tipo de control. Minimizar este problema, se ha tornado uno de los ítems más importantes en la selección de proveedores, a través de la demostración de la calificación de los gestores externos, en relación a sus conocimientos de gestión de proyectos, manejo de técnicas estadísticas y gestión de personas.

Los esfuerzos de mejora de los proyectos se manifiestan por el incentivo a la innovación y el histórico apunta para las siguientes innovaciones adoptadas:

• capacitar todos los gerentes en metodologías de proyecto, de modo que se establezca un lenguaje estándar con todos los clientes;
• capacitar a los equipos para describir los procesos de desarrollo de software, considerando reglas de programación y de lógica computacional. Nótese que grande parte de los software desarrollados están embutidos en los productos y deben tener una dimensión bastante pequeña;
• crear una biblioteca de componentes, en todos los lenguajes de programación que apunten hacia el ambiente de software embutido;
• crear comunidades de discusión, inclusive con técnicos de empresas de la competencia, mejorando la capacidad profesional de los miembros de los equipos;
• crear incentivos especiales a través de concursos internos de conocimiento sobre tecnologías y metodologías de desarrollo de software;
• contratar especialistas en diferentes tecnologías (ambiente Windows, Mainframe, Linux, Web y otros);
• celebrar acuerdos con universidades que mantienen centros de investigación en la mejora de la calidad de los procesos de desarrollo y también en el propio desarrollo de software.

3.2. Caso 2

La unidad de análisis 2 (UA2) es una organización genuinamente nacional, líder en el mercado nacional y en América Latina, de Sistemas Integrados de Gestión, conocidos como ERP (Enterprise Resource Planning). Está presente también en los EUA, a través de dos empresas franqueadas para atender clientes con matriz en Brasil y a través de una empresa franqueada en Portugal. Recientemente, el grupo adquirió otras dos empresas de destaque en este mercado. Sus productos son certificados por el sistema ISO 9001:2000, sus procesos de desenvolvimiento están reconocidos por el modelo CMMI nivel 4, pasaporte necesario para entrar en el mercado europeo y el cuerpo gerencial practica las disciplinas de gerenciamiento de proyectos según el PMI (Project Management Institute). Participaran de la entrevista, el gerente de desarrollo de sistemas y dos ingenieros de software.

Por el hecho de contar con una cartera de mas de 10.000 clientes, UA2 procura mantener equipos especialistas para

 cada uno de los modelos de desarrollo, tanto tradicional como según las tendencias mas recientes (orientación a objetos, metodologías ágiles, ambiente Linux, sistemas para WEB y cliente-servidor).

Los ingenieros de software son entrenados constantemente respecto a las innovaciones tecnológicas, son estimulados a participar de grupos independientes de pesquisa y son estimulados a dar sugerencias que puedan tornar el trabajo más productivo, menos vulnerable a error y aumentar la calidad en los productos entregados a los clientes.

Los coordinadores de cada equipe tienen la obligación de mantener el conjunto de procedimientos de cada uno de los ambientes de desarrollo, lo más actualizado posible.

Como la meta es alcanzar lo más rápidamente la certificación conforme el nivel 5 del modelo CMMI, desde el lanzamiento de este modelo (iniciaron el proceso del modelo CMMI en 2000; obtuvieron las certificaciones nivel 2 y 3 en 2002, el nivel 4 en 2005 y el nivel 5 a inicios de 2009). Desde el comienzo, existe  preocupación con la mejora continua, de acuerdo con la filosofía kaizen (mejoras pequeñas y constantes). Las principales innovaciones que fueron realizadas en el proceso de desarrollo fueron:

• obligar que los desarrolladores permanezcan periódicamente en las empresas clientes, junto con los equipes de implantación para conocer las necesidades reales de los usuarios y entender sus requisitos;
• distribuir versiones alfa y beta de los productos para determinados clientes que, reconocidamente hacen pruebas de aceptación de nuevas versiones del sistema;
• criar uma universidade interna orientada para análise de sistemas (modelo de negócio), tecnologia de la informação;
• capacitar el cuerpo gerencial con certificaciones en gestión de proyectos;
• adquirir componentes de software para integrar los diferentes estadios de software: aplicación, reglas de negocio, banco de datos y presentación;
• contratar especialistas en diferentes tecnologías (Windows, Mainframe, Linux, Web y otros);
• contratar especialistas en diferentes metodologías de desarrollo (desde las tradicionales, hasta las mas modernas, con énfasis en ambiente WEB);
• estimular la creación de redes de conocimiento, promoviendo eventos de tecnología y metodología;
• distribuir gratuitamente copias de software en las universidades, colaborando con la formación técnica de los estudiantes;
• crear un sector de I&D en tecnologías de desarrollo de sistemas y establecimiento de contratos de transferencia de tecnología con empresas desarrolladoras de lenguajes de programación y sistemas operacionales;
• crear concursos de conocimientos en metodología y tecnología con premiación;
• crear bibliotecas de componentes de software y estimular el uso en vez del re-desarrollo de la funcionalidad.

3.3. Resultados

Analizando las respuestas de las dos organizaciones, se percibe que todas las innovaciones implementadas en los procesos de desarrollo son mejoras puntuales e incrementales y fueron agrupadas en acciones: externas a las empresas, organizacionales, en el personal (técnicos y gerentes), metodología y tecnología, conforme resume a tabla 3. Todas las acciones indicadas denotan preocupación de las Unidades de Análisis con el futuro de sus negocios y con la creación de ventaja competitiva. Se destacan los siguientes ítems:

• los resultados de los acuerdos con las Universidades sólo ocurrirá después de algún plazo, una vez que estos están condicionados a la formación de los alumnos. Sin embargo, los objetivos de ambas Unidades de Análisis son distintos; una busca una sociedad para desarrollar componentes para los clientes mientras la otra objetiva generar mercado futuro para sus productos;
• el envolvimiento de los clientes para probar los sistemas tiene por objetivo la fidelidad del cliente;
• la creación de un centro de investigación interno envuelve costo, pero disminuye la dependencia de la organización en relación a terceros;
• la capacitación gerencial, la permanencia de los ingenieros en los ambientes de los clientes, la contratación de especialistas, los estímulos para desarrollo personal y la creación de una universidad corporativa tienen por objetivo asegurar la calificación y disponibilidad de la mano de obra;
• la descripción de los procesos de trabajo, por parte de los actores que lo ejecutan, garantiza que los trabajos serán ejecutados de manera natural y minimiza los efectos de resistencia a los cambios;
• la creación de bibliotecas de códigos y adquisición de componentes traduce una innovación que reduce tiempo y garantiza estandarización del proceso de desarrollo.

RESUMEN DE LAS INICIATIVAS DE INOVACIÓN EN LOS PROCESSOS DE SOFTWARE

Sin duda, los resultados del estudio de caso muestran que ambas organizaciones buscan constantemente mantener el nivel de calidad de los productos y servicios prestados a sus clientes, lo que demuestra la madurez empresarial permeando los procesos de trabajo, independientemente del camino elegido frente a las oportunidades ofrecidas por el mercado.

Este posicionamiento muestra también que la innovación es constante; algunas veces se muestra más evidente en el producto y otras veces está más presente en la gestión de los procesos, lo cual demanda de sus gestores, práctica de creatividad empresarial.

Frente al permanente ejercicio de creatividad e innovación, tales aspectos pueden ser incorporados a la cultura organizacional, transformándose en factores decisivos para el diferencial competitivo de las empresas.

4. Consideraciones finales

Como el desarrollo de software presenta características de creatividad con seguimiento de modelos pre-definidos, las mejoras implementadas siempre se traducen en la forma de acciones innovadoras que varían del “hacer mejor” al “hacer diferente”. Estas innovaciones pueden ser aplicadas a cualquier situación en que la empresa se encuentre y para cualquier proceso de trabajo.

La prioridad de la implementación debe priorizar las acciones más simples y que producen los efectos más benéficos, tanto para los clientes cuanto para los desarrolladores. Una vez criado un ambiente que propicie el desarrollo de habilidades de creación e innovación, las empresas pueden usufructuar de los resultados obtenidos, lo que significa dar oportunidad para las personas que, voluntariamente, estén dispuestas a innovar, independientemente del área en que actúan o del cargo que ocupan dentro de la organización.

Así como los proyectos de desarrollo y las situaciones son pasajeros y temporarios, las acciones innovadoras deben ser aplicadas en el momento y en la intensidad exacta. La cantidad mas adecuada de cambio sólo será conocida en la medida en que el ejercicio continuo de mejora sea una política adoptada por la organización.

Referencias bibliográficas

Allway, M; Corbett, S. (2002); “Shifting to Lean Service: Stealing a Page from Manufacturer’s Playbooks”. Journal of Organizational Excellence. Spring.

Ansoff, H.I.; McDonnell, E.J. (1984); Implementing Strategic Management. Prentice-Hall.

Blakeslee JR., J. A.(1999); Achieving quantum leaps in quality and competitiveness: implementing the Six Sigma solution in your company. Proc. of the 53th Annual Quality Congress, American Society for Quality, Anaheim: Califórnia, 486–496, May.

Bresnahan T., Malerba, F., (1999); “Technological competition and the structure of the computer industry”, Journal of Industrial Economics, 47, 1-40.

Brisolla, S.N., (2001); Indicadores de Innovación: los siete pecados capitales, en ALBORNOZ, M., (ed) Temas Actuales de Indicadores de Ciencia y Tecnología en América Latina y el Caribe, editado pela RICYT, Red Iberoamericana de Indicadores de Ciencia y Tecnología, 39-57 p.

Card, D. N. (2002); Managing software quality with defects. Proceedings. 26th Computer Software and Applications Conference, IEEE Computer Society, p.472-474.

Chaos. The Chaos Report, 2000. [Citado en 26/03/2008], disponible en: [http://www.agilealliance.org/system/article/file/1053/file.pdf].

Claver, E.; Gonzalez, R.; Illopis, J. (2000); “An analysis of research in information systems (1981-1997)”, Information Management, 37(4), 181-195.

Cohn, M.; Ford, D. (2003); “Introducing an agile process to an organization”, IEEE Computer Magazine, 1(1), 74-78.

Costa, I.(2003); Contribuição para o aumento da qualidade e produtividade de uma fábrica de software através da padronização do processo de recebimento de serviços de construção de softwares. Tesis (Doctorado), Escola Politécnica de la USP, Departamento de Engenharia de la Produção.

Chrissis, M. B.; Konrad, M.; Shrum, S. (2003); CMMI: Guide for Process Integration and Product Improvement. Boston: Addison-Wesley.

Dodgson, M.; Griffiths, (2004); “A. Sustainability and innovation”, International Journal of Innovation Management, 6(3).

Fenton, N. E.; Pfleeger, S. L. (1997); Software metrics: a rigorous approach, 2a ed. International Thomson Computer Press.

Fernandes, A.A.; Abreu, V.F. (2006); Implantando a Governança de TI. Rio de Janeiro: Brasport.

Fernandes, A. A., Teixeira D. S. (2004); Fábrica de Software: Implantação e Gestão de Operações. São Paulo, Editora Atlas.

Frick, S.,Nunes, R. (1996); “Produtos, Estruturas de Mercado e Estratégias Competitivas no Setor de Software”, Economia & Empresa, 3(1), 34-44.

Goffin, K.; Pfeiffer, R. (2001);Competing in the innovation pentathlon. Innovation: Management, Policy and Practice, v.4, n.1 y 3, p.143-150.

Hunter, D.; B. Schmidt. (1999); “Six sigma: benefits and approaches”. Chemical Week, 161(37),35-36.

Marash, S. A. (2000); Six Sigma: Business Results Though Innovation. Proc of the 54th Annual Quality Congress of the American Society for Quality, Indianapolis, Indiana.

Mintzberg, H. &; Quinn, J. B. (2001); O processo da estratégia, 3ª ed. Porto Alegre: Bookman.

MCT/SPI. Lei 11.077 (2004). Capacitação e Competitividade do Setor de Informática e Automação. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. Disponível em [http://www.mct.gov.br/index.php/content/view/13950.htm]. Acesso em 30/maio/2010.

Patterson, M. (1998); From Experience: Key Opportunities for Improving Innovation Cycle Time. The CERTI Conference on Rapid Development of Technology-based Products, Santa Catarina – Brasil.

Paulk, M. C.; Weber, C. V.; Curtis, B., Chrissis, M. B. (1997); The Capability Maturity Model: Guidelines for Improving the Software Process. SEI, Addison-Wesley Longman Inc.

Plonski, G.A. (2005); “Bases para um Movimento pela Inovação Tecnológica no Brasil”. São Paulo en perspectiva, 19(1), 25-33.

Poppendieck, M. Lean programming. Software Development Magazine. May-jun, 2001. Disponible en http://www.agilealliance.org/articles/LeanProgramming.htm. [citado en 23/out/2007]

Prahalad, C. K.; Hamel, G, (1990); “The Core Competence of the Corporation”. Harvard Business Review, 79-91.

Pressman, R.S. (2004); Software Engineering: A Practitioner's Approach, 5a. ed. Mcgraw-hill / Tecmedd.

Santana, C.; Gusmão, C.; Soares, L.; Pinheiro, C.; Maciel, T.; Vasconcelos, A.; Rouiller, A. (2009). Agile software development and CMMI: what we do not know about dancing with elephants. Chapter 4 of Agile Processes in Software Engineering and Extreme Programming. Springer Berlin Heidelberger, 2009.

Sarker, S.; Sarker, S. Exploring Agility in distributed information systems development teams: an interpretive study in an offshoring context. Information System Research. v. 20. issue 3. p.440-461, sep 2009.

Tidd, J.; Bessant, J.; Pavitt, K. (2005); Managing Innovation: integrating technological, market and organizational change. 3rd Ed. Chichester: John Wiley; Sons.

Weber, K.; Araujo, E.; Machado, C.A.F.;  Scalet, D.; Salviano, C.F.; Rocha, A.R.C.da. Modelo de Referência e Método de Avaliação para Melhoria de Processo de Software – versão 1.0 (MR-MPS e MA-MPS). IV Simpósio Brasileiro de Qualidade de Software. Disponível em: [http://www.softex.br/portal/softexweb/uploadDocuments/MR_MA-MPS.pdf]. Acesso em: 12/05/2010.

Yin, R.K. (1998); Case Study Research: Design and Methods. Newbury Park, Rev. ed. Sage Publications.

Zairi, M. (1997); Business process management: a boundaryless approach to modern competitiveness. Business Process Management Journal, Vol. 3, Nº. 1, p. 64-80.

[anterior] [inicio]