Cambios forzados en equipos de desarrollo de software

Cuando hay que cambiar a una persona en un proyecto en los casos que esta persona mantiene en contacto con el cliente, hay que informárselo. Esto no habría que hacerlo en un proyecto de costo fijo si esta persona no se comunica con el cliente activamente, por ejemplo. Estoy hablando de realizar un cambio porque supongo que el proyecto está en curso y la necesidad de esa persona sigue, y no es común que se quiera dejar de obtener ganancias por esa posición.


La razón del cambio puede ser por:

• Necesidad de reasignarla a otro proyecto debido a que se obtendría un mayor margen.
• Necesidad de reasignarla a otro proyecto debido a que sus habilidades serian mas aprovechadas en el nuevo proyecto.
• Pedido de cambio de la persona, por aburrimiento u otras razones.
• Pedido de cambio del líder técnico o project manager por considerar a la persona no apta por temas de motivación, falencias técnicas o similares.
• Renuncia por diversas razones.
• Despido por diversas razones.

Existen muchas otras razones, las que enumere son las más comunes. Una vez me paso que la novia de un ingeniero había conseguido una asignación de 6 meses en Estados Unidos y la empresa de la novia también le pagaban la estadía y el pasaje a él y no dudo en renunciar. Sin embargo, el objetivo de este artículo no es citar razones, sino contarles qué hay que informar en estos casos.

Lo ideal es tener un candidato para reemplazar a esta persona. Si se sabe esto con la suficiente anticipación, se puede esperar unos días para encontrar un posible reemplazo. Si uno se entera sobre la hora, hay que informarlo cuanto antes. En este caso lo mejor es llamar al cliente, contarles que cierta persona no está más, que ya se está trabajando en buscar un candidato, y decirle que en tal día (sugiero no más de 3 días) se le va a actualizar sobre la situación.

Si uno tiene un candidato para presentar, lo ideal es mandar un mail con el curriculum vitae de esta persona, ofreciendo hablar sobre el tema ni bien el cliente pueda. Lo mejor que puede pasar, lo más fácil de digerir para el cliente es decir es que esta persona consiguió una beca de investigación en una universidad del exterior. Si es renuncia, lo mejor que se puede decir es que se fue a una empresa que le ofrecía un desafío tecnológico mayor, que en esta empresa no existía tal cosa. Recuerdo una vez que el cliente luego de informar que alguien renunciaba ofreció contratarlo por su cuenta, freelance, y le conto a la persona lo que pagaba por mes por él, un mamarracho. Lo peor es decir que se va por mas plata. Hay que manejar el tema con cuidado, porque si se disfraza la verdad (recomiendo no hacerlo) y la persona tiene una buena relación con el cliente, este le va a ir a preguntar enseguida.

Si uno manda un mail con un candidato, lo ideal es comenzar contando que uno lamenta informar que cierta persona se va, si no se tiene el día exacto comentarle al cliente cuando uno lo va a tener. Luego hay que comentar la razón. Después se tiene que presentar al candidato (adjuntando el curriculum vitae, informando el costo por hora) y dar las razones por la cual uno piensa que es el correcto. Posteriormente hay que avisar que se planeo una transferencia de conocimientos para que la transición no impacte en los planes (esto hay que hacerlo en serio con el líder técnico, hay que comentarle al cliente que se comunique con esta persona para mas detalles). También hay que ofrecerle que conozca a esta nueva persona en una charla telefónica. Prefiero no sugerir que lo entreviste para evitar que lo reboten, ya que es difícil tener más de un candidato en estas situaciones. Hay clientes que quieren entrevistar a la gente si o si, y no se puede hacer nada para evitarlo. Finalmente hay que ofrecer disculpas de nuevo y comentarle que puede contactarse con uno cuando quiera para charlar sobre el tema. Les deseo la mejor suerte si tienen que pasar por esto.

Cualidades del Software

Hoy me preguntaron sobre cualidades del software y recordé lo que me habían enseñado en la facultad, como es un tema interesante, quiero escribir algo en el blog sobre ellas.

Las cualidades del software podrían definirse como las características propias e innatas del producto de software a construir. Idealmente, Las cualidades de un sistema deben estar por encima y por delante de la funcionalidad del sistema. Lamentablemente, la funcionalidad no sólo ocupa el primer lugar en las prioridades de los desarrolladores sino que muchas veces es el único.

Las cualidades podrían clasificarse como externas (visibles a los usuarios), internas (visibles solo a los desarrolladores), del producto, del proceso, observables y no observables en tiempo de ejecución.

Robustez: es un concepto difícil de definir, pero haremos nuestro intento: robustez = distancia al caos. Mientras menor es la distancia al caos, mayor solidez/robustez posee ese sistema. También puedo medir la robustez de un sistema en base a la tranquilidad al: 1) usar, 2) modificar una pieza de software.

Corrección: un sistema es correcto si hace lo que el cliente necesita. Dicho de otra forma, un sistema es correcto si su resuelve el problema real que causó su desarrollo. Adaptación total a una especificación no necesariamente implica corrección ya que dicha especificación puede no ser un fiel reflejo de la realidad del problema a resolver. Dicho de otra forma: pasa todo el tiempo que el cliente te pide y/o espera algo distinto de lo que necesita (de hecho lo que dice, lo que espera y lo que necesita pueden ser los tres súper distintos entre sí).

Eficiencia: tenemos dos dimensiones posibles para medir la eficiencia (tiempo/recursos) de un sistema: Recursos necesarios para la construcción (tiempo de desarrollador) o Recursos necesarios para la ejecución (tiempo de usuario + hardware). “Tiene mejor eficiencia el sistema que necesita menos recursos para realizar una tarea determinada”, por lo tanto deberíamos considerar ambas dimensiones a la hora de medir esta cualidad.

Claridad: Se refiere a la posibilidad de entender el funcionamiento de un sistema, subsistema o una porción de código cualquiera, su objetivo y la forma de solucionar el problema; en particular por gente que no es la que lo construyó. La claridad de un módulo afecta claramente a la posibilidades de modificarlo (flexibilidad).

Flexibilidad: es la capacidad que tiene un sistema para reflejar cambios percibidos en el dominio (sea por mejor comprensión del mismo o porque de verdad cambió) de una manera simple y sencilla. Conceptos relacionados son:
Extensibilidad: un sistema es extensible cuando pueden incorporarse nuevas características al mismo sin mayor impacto sobre las características actuales.
Mantenibilidad: un sistema o desarrollo es más mantenible cuanto menor esfuerzo requiere para que el sistema siga funcionando en condiciones distintas a las originales e incluso en las originales. Entre estas tareas podríamos enumerar:

1. Pequeños cambios de funcionalidad o parametrización (aquí se relaciona con la flexibilidad)
2. Debugging
3. Posibilidad de corregir las incongruencias producidas por los propios errores del software
4. Posibilidad de hacer cualquier tipo de cambio sobre el sistema mientras este sigue funcionando.

Consistencia: el sistema debe comportarse siempre de la misma manera ante un mismo evento y las tareas similares deben poder realizarse siguiendo pasos similares.

Simplicidad: el sistema debe ser simple tanto en la interfaz como en la implementación. Es más importante la simplicidad en la interfaz que en la implementación.

Completitud: Un sistema es completo cuando contempla todas las posibles situaciones a darse en la práctica.

Encapsulamiento o Modularidad: poder agrupar unidades funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad del sistema y aumentando en cierta forma su flexibilidad.

Escalabilidad: la facilidad con la que un sistema pensado originalmente para una carga determinada puede ser adaptado para soportar una carga mayor. Las aplicaciones Web nos dan una buena muestra de cuándo la escalabilidad puede ser importante para no afectar 1) la imagen del usuario que da vida a nuestro sistema, 2) la imagen corporativa del negocio que manejamos.

Abstracción: un sistema debería contener buenas abstracciones de la realidad. Recordemos que el sistema no es la realidad, sino un modelo. En base a nuestras abstracciones podemos definir:

1. Reusabilidad: la posibilidad de utilizar un sistema construido anteriormente para resolver un problema nuevo.
2. Genericidad: Un sistema o subsistema es genérico cuando se puede aplicar a un conjunto de situaciones similares.

En general reusabilidad y genericidad están relacionadas, un sistema muy específico difícilmente puede ser reutilizado.

Utilidad: no está de más recordar que el sistema debe ser útil al usuario.

Seguridad: Un sistema seguro debe impedir que agentes (personas u otros sistemas) no autorizados realicen acciones sobre el sistema.

Hagan click para ver la siguiente imagen mas grande con una subdivisión de estas y otras cualidades:


Fuentes:

• UTN - Técnicas Avanzadas de Programación
• Facultad de Ciencias Exactas, Ingeniería y Agrimensura (FCEIA) de la Universidad Nacional de Rosario