GESTION DE RECURSOS HUMANOS

 

PRESION EXCESIVA EN LA PLANIFICACION

La primera reacción de los responsables y los clientes cuando descubren que no están cumpliendo una planificación optimista es cargar más presión en la planificación sobre los desarrolladores e insistir en que realicen más horas extras. La presión excesiva en la planificación ocurre aproximadamente en un 75 por 100 de los proyectos grandes, y cerca del 100 por 100 en todos los proyectos muy grandes [Jones, 1994]. Casi el 60 por 100 de los desarrolladores informa de un aumento en el nivel de tensión que sienten [Glass,1994c].

 presión en la planificación ha llegado a ser tan arraigada en el ámbito del desarrollo del software que muchos desarrolladores la han aceptado como un hecho establecido. Algunos desarrolladores ya ni siquiera son conscientes de que la presión extrema en la planificación que experimentan podría ser distinta. La presión en la planificación perjudica, y mucho, a continuación se detallan algunos de los aspectos que se ven perjudicados.

LAS DE LA PRESIÓN EXCESIVA EN LA PLANIFICACIÓN

Calidad. Se ha determinado que alrededor de un 40 por 100 de todos los errores del software son causa de la tensión; estos errores se podrían haber evitado con una planificación apropiada y no provocando tensión en los desarrolladores [Glass, 1994c]. Cuando la presión en la planificación es extrema, se detectan sobre cuatro veces más errores en el producto respecto a productos desarrollados con una presión menos extrema [ Jones, 1994].

Con una presión extrema en la planificación, los desarrolladores también incrementan la presión interna. y son más sutiles para dedicarse a concentrarse en su propio trabajo, descuidando las actividades de garantía de calidad. Por ejemplo, cuando se enfrentan con la opción de elegir entre revisar código de otros o realizar sus propias rutinas.

Azar. Como una planificación excesivamente optimista es imposible de alcanzar con los métodos de desarrollo eficiente normales, los directivos y desarrolladores del proyecto sienten la tentación de apostar al azar en vez de correr riesgos calculados.

Motivación. A los programadores de software les gusta trabajar. Un poco de presión en la planificación resultante de una planificación ligeramente optimista pero factible puede motivar. Pero en algún punto, la planificación optimista cruza el umbral de la credibilidad, y en ese punto la motivación decae rápidamente.

Creatividad. Muchos aspectos del desarrollo del software requieren ideas creativas. La creatividad requiere pensar mucho y una gran persistencia cuando la solución deseada no aparece inmediatamente, lo que requiere una motivación interna.

La motivación externa excesiva (es decir, estrés) reduce la motivación interna,y a su vez la creatividad [Glass,1994a].

Agotamiento. Si se abusa de las horas extras en un proyecto, los desarrolladores se verán afectados en el próximo proyecto. Los desarrolladores se ocuparan de cosas de poca importancia pasados algunos meses del empujón inicial.

Si la planificación presiona demasiado a los desarrolladores, el agotamiento se puede experimentar en el proyecto actual, en vez de en el próximo.

Cambio de personal. Las planificaciones extremadamente optimistas y la presión resultante en la planificación tienden a causar cambio voluntario excesivamente alto de personal, y las personas que dejan el proyecto tienden a ser las más competentes, con las mejores características de rendimiento [Jones,1991].

Desarrollo rápido a largo plazo. Las horas extras excesivas eliminan el tiempo libre que los desarrolladores invertirían en su desarrollo profesional. Los desarrolladores que no progresan, no aprenden métodos nuevos, y eso perjudica a la capacidad de desarrollo rápido a largo plazo en la organización.

Relación entre desarrolladores y directivos. La presión en la planificación aumenta las diferencias entre desarrolladores y directivos.

Alimenta la tendencia existente entre los desarrolladores de creer que los directivos no los respetan, no se preocupan por ellos, y no saben lo suficiente sobre desarrollo de software como para saber cuándo están pidiendo algo que es imposible.

Las malas relaciones llevan a bajar la moral, perder la comunicación y otras situaciones contrarias a la productividad.

PUNTOS CRUCIALES

Algunas personas piensan que los proyectos software deberían planificarse de forma optimista, ya que el desarrollo del software debe ser más bien una aventura que un ejercicio monótono de ingeniería. Estas personas alegan que la presión en la planificación ayuda a la emoción. Nada más falso, sin sentido y cercano al fracaso que estas alegaciones.

En Quality Software Management, Gerald Weinberg sugiere pensar en los proyectos software como en sistemas (Weinberg). Cada sistema tiene unas entradas y genera unas salidas. El diagrama del sistema para un proyecto que ha sido planificado con precisión sería similar al de la figura 3.1.

Desafortunadamente, el diagrama del sistema para un proyecto que ha sido planificado de forma excesivamente optimista se parecerá más al esquema de la figura 3.2

Cuando se comparan los dos sistemas, se ve de manera clara que uno es notablemente mejor al otro.

Una planificación excesivamente optimista simplemente no funciona, no produce planificaciones más cortas sino todo lo contrario.

La planificación real más corta es el resultado de la planificación más precisa posible. Un proyecto que tiene problemas de planificación sólo necesita buscar la fuente de sus problemas en una planificación inicial irrealizable.

DISMINUCION DE LA PRESION DE LA PLANIFICACION

La presión en la planificación parece ser endémica en el desarrollo del software, y ha sido perjudicial, pensando a corto plazo, en dos niveles. A nivel local, ha alentado la toma de atajos en proyectos específicos. En un nivel más global, ha contribuido a una mentalidad curiosa sobre la presión en la planificación. La gente ve la presión en la planificación un problema exclusivo del proyecto actual, aunque han sufrido presión en la planificación en todos los proyectos anteriores, y aunque ha sido una de las características definitorias de la industria del software durante al menos 30 años.

Los desarrolladores tienden a ser malos negociadores por una serie de razones.

En primer lugar, por lo general, los desarrolladores son introvertidos y las relaciones sociales competitivas no suelen ser su fuerte.

En segundo lugar, las planificaciones del software normalmente se establecen mediante negociaciones entre desarrollo y gestión o desarrollo y marketing. El personal de marketing suele ser 10 años mayor y negocia para vivir, es decir, tienden a ser negociadores maduros y profesionales [Weinberg,1994].

En tercer lugar los desarrolladores tienden a oponerse enérgicamente a los trucos de negociación. Tales trucos ofenden su sentido de calidad y claridad técnica.

Los desarrolladores no ofrecerán unas estimaciones iniciales desproporcionadas incluso cuando sepan que los clientes, comerciales o responsables comenzarán con unas posiciones de negociación iniciales para comenzar a regatear.

Los desarrolladores necesitan ser mejores negociadores, y aprender a negociar planificaciones eficientemente.

Negociación conveniente. Un buen punto para comenzar es el método de negociación conveniente descrito en Getting toYes [Fisher y Uri,1981].

Este método no confía en los trucos de negociación, pero explica cómo responder a los trucos cuando otros los utilizan. Se basa en la idea de crear alternativas satisfactorias para todas las partes.

No intenta derrotar a la persona con la que se está negociando: intenta cooperar de forma que ambos puedan ganar.

Es una estrategia abierta, no importa que las otras partes conozcan el método, de hecho, funciona mejor cuando todas las partes involucradas lo conocen y lo utilizan.

Este método viene es “Gestión Theory-W” donde se utiliza para fijar una estrategia satisfactoria para todas las partes implicadas en el proyecto,donde todos ganen.

La estrategia de negociación conveniente consta de cuatro partes que tratan sobre personas,intereses,opciones y criterios:

1.       Separar las personas del problema.

2.       Centrarse en los intereses,no en las posiciones.

¡   Apelar a la velocidad de desarrollo verdadera.

¡   Apelar al aumento en la probabilidad de éxito.

¡   Recurrir a hechos históricos.

3.       Inventar opciones para beneficio mutuo.

4.       Insistir en la utilización de criterios objetivos.

¡   No negociar la propia estimación.

¡   Insistir en que la estimación sea preparada por alguien cualificado.

¡   Insistir en un procedimiento de estimación racional.

¡   Resistir a las presiones.