La falacia de fábricas de software y la importancia del talento

La semana pasada escuché un podcast de interés por los analistas de ForresterMike Gualtieriand y Jeffrey Hammond titulado lo que importa es el talento: ¿Por qué el Desarrollo de aplicaciones no puede industrializarse . Al principio pensé que esto podría haber sido un debate contra la externalización, pero después de escuchar y pensar en ello, se trata realmente de una comprensión más profunda de la importancia de tener un talento excepcional en su organización de ingeniería de software. Y es un concepto que cualquier negocio impulsado por la tecnología debe hacerse.

La conversación se puede reducir a algo bastante simple: desarrollo de aplicaciones y pruebas profesionales no son un bien fungible que se consume en el uso como los muebles. En el fondo (tal vez no tenemos que ir tan profundo), todos sabemos que esto es cierto, sin embargo, cada proyecto de desarrollo se calcula utilizando la productividad de un desarrollador “promedio”. Y lo que es peor, se refieren a ellos como recursos. Y de acuerdo con Gualtieri y Hammond, esto es donde todo va muy mal. Y tienen razón.

No importa qué método de estimación se utiliza — análisis de puntos de función, las técnicas basadas en analogías, modelos paramétricos — estos métodos se utilizan para estimar los meses-hombre necesarias para completar el proyecto. Pero no todos los desarrolladores son los mismos. Hay estrellas de rock, bajo rendimiento y todo lo demás. Así, mientras que un excelente guía, la precisión de las estimaciones realmente depende de quién son los miembros del equipo de desarrollo.

Arte vs Ciencia

De hecho, los mejores desarrolladores son “artistas” para tomar una frase del último libro de Seth Godin, “pieza clave”. Los chicos de Forrester habla de los atributos de los mejores desarrolladores: creativos, apasionados, disciplinados. Pero mientras que los artistas pueden ser los mejores desarrolladores, no todos los desarrolladores son artistas. Así como industria, hemos tratado de poner un poco más en torno a la estructura de la ciencia de las prácticas de desarrollo de software y hacer de la ingeniería software una “profesión”. También nos hemos apoyado en metodologías y herramientas para que los desarrolladores promedio entreguen resultados por encima de la media. Ha ayudado a la industria avanzar y desarrollar un gran software.

La falacia de la fábrica de software

Pero el error que tal vez muchas empresas hacen es pensar que estas metodologías y herramientas volverían sus equipos de desarrollo de software en fábricas de software. En ninguna parte tiene este enfoque hacia tratar de crear fábricas de software sido más pronunciada que en el negocio de externalización de TI. Eso es debido a que bajo el éxito tradicional modelo de externalización se logra al tratar de romper cualquier tarea en sus componentes más básicos para que esas actividades se pueden completar con los recursos más jóvenes y más baratos.

Esto no quiere decir que los métodos, herramientas, bibliotecas reutilizables no sean valiosos y no hacen a los equipos de ingeniería de software más productivos. Pero no son una panacea para tener buenos ingenieros de software. Herramientas y metodologías son más como carriles de guía para reducir errores y ayudar a los desarrolladores menos experimentadas realizar tareas más avanzadas, pero no garantizan necesariamente software bien escrito, de alto rendimiento. Así que estoy de acuerdo en general con su punto de vista. Pero creo que es importante hablar de la madurez de ingeniería de software.

Software Product Engineering versus IT Application Development

Ahora voy a transformar la conversación ligeramente desde una perspectiva de desarrollo de aplicaciones base a una perspectiva de la ingeniería de productos de software. Permítanme comenzar diciendo que yo creo que la ingeniería de producto de software es un animal diferente que el desarrollo de aplicaciones informáticas. Los productos de software y plataformas — ya sea vendida directamente a los clientes o simplemente proporcionar la infraestructura para ofrecer sus productos o servicios a sus clientes — requiere una complejidad, una reflexión, en el desarrollo, la arquitectura que no se encuentra a menudo en aplicaciones diseñadas para uso de usuarios internos. Y Forrester está de acuerdo. De hecho, han escrito un informe acerca de cómo algunas compañías cuyos negocios son impulsadas por la tecnología, pero no vender el software en sí, están empezando a tratar de volver a organizar sus organizaciones de desarrollo de software en la imagen de una organización tipo Independent Software Vendors (ISVs) R&D Research an develpment. Estas empresas son centradas en el producto más y más compañías de viajes y bancos llenan esta descripción.

Si necesita una regla de oro, pensar en quién está usando el software en cuestión: ¿es un cliente — que pueden optar por cambiar a un competidor si no están contentos con su experiencia o el rendimiento de la aplicación — o es una aplicación u otro recurso informático utilizado por un empleado cuya única alternativa es encontrar otro lugar para trabajar? Si se trata de la primera, probablemente estás hablando de una aplicación que necesita un enfoque de ingeniería de producto de software más desarrollada.

Actividades de ingeniería del producto de software difieren de las organizaciones de TI, ya que:

· Ellos son más maduras en las prácticas de ingeniería de software si se compara con los modelos de madurez como CMMi

· Se adhieren a las prácticas de ingeniería de software formalizados y uso de las prácticas comunes de codificación

· Reconocer, apreciar y respetar calendarios de lanzamiento

· La calidad es de suma importancia. La prueba es importante, pero se diseña centrado en la calidad.

· Equipos de QA utilizan el control de la planificación, la estrategia de pruebas, en lugar de un enfoque ad-hoc para las pruebas

Yo quiero evitar pintar todas las organizaciones de TI con un cepillo demasiado amplio. Algunas organizaciones de TI son más maduros que otros y han puesto una mayor inversión en poner las prácticas de ingeniería de software, se centraron en la arquitectura y hacer cumplir adherencia a los estándares de codificación de toda la organización. Sin embargo, es más probable que usted verá que con los equipos cuyo código está estrechamente relacionado con la generación de ingresos o de apoyo a la entrega del producto o servicio de la compañía a sus clientes. Adoptan un enfoque “centrado en el producto”, como diría Forrester, están en el desarrollo de software porque se dan cuenta de que un mal software afecta negativamente el rendimiento de la empresa.

El Talento es aún más importante en el software de Organizaciones de ingeniería orientada al producto

Mi firma, Ness Software product Labs, no es lo mismo que las grandes empresas de ITO(IT Oursourcing). Nuestra misión es ayudar a ampliar y mejorar las capacidades de las organizaciones de ingeniería de productos de software — que ayudan a las empresas a construir y probar el software que impulsa los ingresos — en lugar de gestionar las aplicaciones internas de TI y la infraestructura. Para lograr ese objetivo, Ness SPL cree que se requiere un enfoque filosófico diferente de lo que se ve desde las grandes empresas ITO. Se informa del tipo de personas que contratamos, la forma en que colaboramos con nuestros clientes y el tipo de relaciones y modelos de compromiso que empleamos.

Pero en el contexto de este tema, me quiero centrar en la cuestión de talento nuevo. Ingeniería de producto de software no es ITO. Diseño de arquitecturas, diseño, construcción y prueba de los productos que están vinculados a los ingresos, que requieren altos niveles de rendimiento, escalabilidad y capacidad de recuperación no es una tarea a realizar por las personas del mínimo común denominador. Creemos que requiere de gran talento de los individuos … artistas con la disciplina. Pasamos mucho tiempo al desarrollo de mejores prácticas, aceleradores de soluciones, y la identificación de las mejores herramientas a utilizar. Pasamos por lo menos tanto tiempo para encontrar a las personas adecuadas y desarrollar su talento y ofrecemos los desafía que la mayoría de las empresas ITO no pueden. Nosotros no tratamos de crear una fábrica de software, tratamos de crear un ambiente donde los ingenieros con talento pueden prosperar.

Y el crisol en el que hacemos que el trabajo no es para los débiles de corazón. Somos parte de las organizaciones de ingeniería de software de algunas de las empresas líderes en tecnología en el planeta: Amadeus el proveedor número uno de tecnología de viajes en el mundo; NAVTEQ, la plataforma líder de mapas y servicios basados ​​en localización, PayPal la principal plataforma de pagos alternativos, OpenText una firma de Empresa de Gestión de Contenidos mil millones de dólares. Y la lista continúa. Nuestro enfoque y el talento que contratamos se ve confirmada por los clientes que nos eligen para ser una parte de su organización de I + D, que no se ejecute la instalación de cañerías.

fuente original