La competitividad en el software tiene poco que ver con ajustar estimaciones o tarifas

Resumen: Una situación habitual en nuestro sector, es la que se presenta cuando los gerentes de cuentas nos piden que ajustemos estimaciones o tarifas de cara a tratar de ser más competitivos en los procesos de capacitación de proyectos y en definitiva ganar oportunidades.

La situación es muy habitual y lo paradójico es que la competitividad tiene poco que ver con ajustar estimaciones o tarifas.

Normalmente cuando se ajustan las estimaciones lo que termina sucediendo es que el software se desarrolla pero no consigue alcanzar el punto de madurez o acabados necesarios para estar en producción. Es decir, la funcionalidad implementada normalmente es la que espera el cliente pero siempre aparecen múltiples oportunidades de mejora.

Otra situación habitual, es que por tratar de ir más rápido, dejan de realizarse ciertas tareas (una típica son las pruebas unitarias) que en muchas ocasiones implican detrimento en la calidad del software y a la larga es perjudicial.

Seguro que sabéis a que me refiero.

Cuando se ajusta la tarifa, lo que viene a suceder es que el cliente no siempre es consciente del esfuerzo que va a realizar la compañia proveedera de servicios de IT y de ser así, sirve para bien poco.

En relación al ajuste de la tarifa, yo siempre he sido defensor de no hacerlo pero como la vida, normalmente no nos lleva a situaciones ideales, cuando hay que hacerlo, prefiero hacerlo aplicando un descuento de manera que siempre queda escrito en la propuesta de colaboración y parece que cuesta algo más que pase al olvido. Otra opción es dar más facilidades de pago para que nuestro cliente pueda aprovecharse de descuentos financieros. No obstante, facilidades de pago, normalmente las damos todo el mundo.

La competitividad, tiene más que ver con impulsar iniciativas intraempresariales que permitan agilizar el desarrollo de software y aumenten la calidad del mismo a un menor coste.

El asunto es sencillo, si a un menor coste, trabajo más rápido y mejor la cosa pinta bien.

Hasta aquí todo es perfecto aunque la realidad me dice que muchas veces estas iniciativas no terminan de encajar bien en el mundo empresarial. Para empezar, cuales son estas iniciativas. Estas iniciativas, no son otra cosa que lo que voy a llamar como procesos de estandarización, es decir, definir las herramientas y tecnologías estándares de la compañía con las que se va a trabajar en el día a día.

Normalmente estos procesos de estandarización tienen un coste, ya sea en horas de investigación o desarrollo de las piezas que se utilizaran posteriormente y no todas las compañías están dispuestas a asumirlo. A la larga, ese coste es insignificante ya que prácticamente en el primer proyecto en el que lo implantes se va a ver amortizado con creces.

No tiene sentido que en cada proyecto tengamos que implementar un modelo de salud. No tiene sentido que en cada proyecto tengamos que crear una colección de hojas de estilo, no tiene sentido que en cada proyecto tengamos que hacer lo mismo que hemos hecho en el proyecto inmediatamente anterior.

Lo que tiene sentido es utilizar las piezas que son reutilizables y aprovecharlas de manera que cuando nos encontremos en la situación de estimar un futuro proyecto, sepamos que integrar el modelo de salud que utilizamos normalmente nos cuesta 5, 10, 20, 40 jornadas, las que sean, que siempre serán menos que volverlo a desarrollar.

Lo que tiene sentido es utilizar un framework de interfaz de usuario que nos permita construir aplicaciones sin que continuamente tengamos que estar diseñando los diferentes elementos con los que va a interactuar el usuario.

Lo que tiene sentido es usar Membership Provider (los que trabajamos con tecnologías Microsoft) para implementar el modelo de Autenticación y Autorización.

Hace poco más de dos años, fui el responsable de impulsar una iniciativa de este tipo en Kabel Sistemas de Información. Tras una semana explorando diferentes frameworks de interfaz de usuario apostamos por el que consideramos más completo. Todo un acierto. Prácticamente la totalidad del equipo de desarrollo, era capaz de crear las vistas del proyecto, algo que tradicionalmente no sucede.

En NBICI.es hemos utilizado soluciones ASP.Net Dynamic Data para gestionar maestros (y en muchas ocasiones lo que no son maestros) como una de nuestras herramientas de BackEnd. Otra de nuestras herramientas de BackEnd es una solución que utiliza documentos Excel para realizar ciertas tareas. El sistema de Autenticación y Autorización, lo tenemos implementado vía seguridad integrada delegando la autenticación y autorización en Active Directory y evitando así tener que implementar una herramienta que nos gestione roles y usuarios.

El conocimiento profundo de la tecnología nos permite ser más competitivos y eficaces sin que por ello aparezcan mermas en la calidad de los productos que desarrollamos. Esta es la mayor ventaja competitiva que tenemos y lo único que hay que hacer es aprovecharla.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s