IT Project Management – Desarrollo de Software Gestión y Asignación eficiente de Capital Humano.

Autor: Norberto Figuerola

De acuerdo con la Guía del PMBOK ®, un proyecto es un esfuerzo temporal emprendido para crear un producto, servicio o resultado únicos. El “Software Extension to the PMBOK® Guide” se espera describa los atributos particulares de los proyectos de desarrollo de software o TI. Los proyectos de desarrollo de software además de la creación de nuevos productos, se realizan a menudo para modificar un producto existente, para integrar un conjunto de componentes de software existentes, o para modificar la infraestructura de software de una organización. Los proyectos de software también pueden llevarse a cabo para satisfacer las solicitudes de servicio, las necesidades de mantenimiento, y para proporcionar apoyo a las operaciones. Sin embargo, estas actividades pueden ocurrir como operaciones continuas de bajo nivel, y sólo se considerarían como proyectos cuando se especifican como esfuerzos temporales que se producen dentro de plazos predeterminados para proporcionar prestaciones y resultados específicos. La Gestión de Operaciones en TI es un área que estaría fuera del alcance de la Gestión formal de un Proyecto.

Manuales dedicados al Gobierno de TI o a los Servicios de TI tal como ITIL son los que se utilizan para estas actividades no consideradas como proyectos. Pero existe una fuerte interrelación entre estas distintas prácticas, dado que el software utilizado por el personal de operaciones ejerce una fuerte influencia en la eficacia y eficiencia de sus procesos y procedimientos de trabajo; por lo tanto, los aportes de las partes operativas son importantes fuentes de requisitos que los proyectos de software deben esforzarse en satisfacer. Es muy habitual encontramos con empresas donde la realización de los nuevos proyectos y los servicios de mantenimiento y/o operativos asociados al negocio se desarrollan con los mismos recursos. Ante cualquier urgencia del negocio que provoque sobre-asignación de los recursos planificados en los proyectos, se acostumbra a priorizar el buen funcionamiento de la actividad de la empresa, ya que es la que genera los ingresos. Y los Proyectos, que antes de la transferencia al negocio representan sólo gasto, acaban perdiendo recursos de manera imprevista y continuada. Hay que entender que las organizaciones implementan su estrategia a través de proyectos que les permiten alcanzar un nuevo posicionamiento desde el que pueden acometer otros retos. Y que la fuga de recursos, que siempre son limitados, para atacar otras prioridades afecta directamente al cumplimiento de la planificación y, por tanto, al éxito del proyecto. El problema se evitaría con la separación de las áreas de Proyectos y Mantenimiento, pero no es tan fácil, dado que hay que considerar distintos escenarios: •

Mantenimiento con Recursos Internos: ¿qué haríamos con ellos cuando no hay urgencias ni reparaciones? ¿Nos podemos permitir tener recursos desocupados? ¿Cuáles son los mínimos recursos que deberíamos disponer y cómo se adquiere el resto en caso de necesidad?

•

Proyectos con Recursos Internos: tendríamos que asegurar que el volumen de las tareas es suficiente para justificar un departamento orientado únicamente a proyectos

•

Subcontratación de trabajos: puede plantearse como una alternativa viable, pero en el caso de que estuviesen relacionados con el know-how y los valores estratégicos de la empresa, habría que valorar su impacto.

No existe una receta única pero hay que empezar por reconocer la existencia del problema, entender el valor de una organización orientada a proyectos y evitar, como demasiadas veces ocurre, que los proyectos acaben estando en la cola de la lista de prioridades. La composición de un equipo de proyecto de software es a menudo un equilibrio entre las consideraciones ideales y las limitaciones prácticas. Las organizaciones tienen que estar constantemente haciendo concesiones entre diferentes consideraciones ideales para equipos de desarrollo de software. Ejemplo de estas son:

• Miembros dedicados o no dedicados. En el mundo del trabajo del conocimiento, el cambio de contexto entre múltiples asignaciones provoca una sobrecarga intelectual. Por lo tanto, los proyectos de software se benefician de los recursos dedicados. La asignación de los miembros del equipo para un proyecto a la vez puede limitar el cambio de contextos entre múltiples tareas a tiempo parcial y mejorar la productividad de los equipos de software. Sin embargo, algunos proyectos simplemente no tienen suficiente trabajo para el skill del recurso, ni el presupuesto para apoyar a recursos dedicados. Como resultado, muchos gerentes de proyectos de software deben establecer un equilibrio entre los recursos dedicados y no dedicados.

• Equipo Colaborativo o División Funcional. En algunas organizaciones, los miembros del equipo conforman un grupo interdisciplinario que reúnen todos los conocimientos necesarios para el desarrollo de software, y ya tienen experiencia en trabajar de manera colaborativa y cooperativa. En cambio, otras organizaciones poseen diferentes unidades funcionales que aportan sus propios recursos con sus conocimientos a diferentes proyectos. Este último enfoque puede implicar a diferencia del primero la asignación de desarrollo de componentes de interfaz (de usuario, bases de datos, etc.). La alineación de los equipos de forma colaborativa aumenta la retroalimentación entre los miembros del equipo y reduce el tiempo de reacción. También permite que ocurra el aprendizaje a lo largo de este proyecto, que se refleja en los productos de trabajo y las interacciones entre los miembros del equipo. Algunas organizaciones de software tienen grupos funcionales con el interés de maximizar la utilización de los recursos y su especialidad. Como se ha indicado anteriormente, logrando un equilibrio entre los recursos dedicados y no dedicados, que pueden reflejarse como un equipo de colaboración frente a las divisiones funcionales es un dilema económico difícil en el desarrollo de software.

• Especialistas o Generalistas. Los proyectos de software a menudo requieren habilidades especializadas que incurren en altos costos de mano de obra. Como resultado, muchos gerentes de proyecto asignan personal a sus proyectos de software con miembros que tienen habilidades generalistas y confian en ellos para llevar a cabo la mayor parte del trabajo. De forma periódica, un experto será llamado a colaborar para guiar a los generalistas en áreas especializadas. Otra ventaja de este enfoque es que los generalistas pueden ofrecer perspectivas más amplias que los expertos y desarrollar más opciones de solución.

• Equipo Estable o Temporario. Muchas organizaciones crean un nuevo grupo de trabajo para cada proyecto de software y disuelven al equipo cuando se entrega el producto. Para el mantenimiento continuo, mejora y apoyo de productos de software, es beneficioso mantener equipos multi-funcionales, durante el tiempo para que el conocimiento se retenga sobre el producto y los equipos mantengan altos niveles de rendimiento. Otro de los beneficios de los

equipos estables es que los resultados del proyecto a través de la organización normalmente se vuelven más predecible.

• Recursos Propios o Tercerizados. Es importante tener en cuenta la posición y la filosofía de la empresa en materia de personal, al decidir qué tipo de dotación de personal requiere para el proyecto. Una empresa puede optar por cubrir un cargo con un empleado, mientras que otra compañía llena la misma posición con un contratista. Gran parte de la decisión depende de la estrategia de la empresa de dotación de personal, el tipo de trabajo que deberá ser cubierto, los costos que el proyecto puede afrontar y el desarrollo o software a implementarse. La empresa debe considerar alguno de los pros y los contras tales como: tipo de empresa (dedicada al desarrollo de software o no), normas contractuales de personal, proyecto a corto o largo plazo, habilidades, trabajo estratégico o no, confidencialidad, producto enlatado, etc.

Particularmente respecto de este último punto señalado vamos a extendernos un poco más. Por supuesto que en muchos casos el proyecto resulta en un mix de personal interno y externo. Para incorporar personal externo o tercerizado a un proyecto generalmente se utiliza contratar personal temporario por intermedio de empresas de servicios habilitadas para tal fin y que ya se encuentran o tuvieron alguna relación con el departamento de Recursos Humanos, Compras y Legales. En el caso de implementación de paquetes de aplicaciones tipo ERP, generalmente se contrata todo el servicio de desarrollo e implementación al proveedor y no se considera en este caso como una contratación de personal externo, de hecho, por lo general el proyecto es supervisado mayoritariamente por el proveedor aunque coloquemos recursos propios. Adicionalmente, también es práctica común incorporar jóvenes estudiantes, por medio de diversos regímenes para la realización de pasantías y/o becas. Deberá tener en cuenta que el contrato de pasantía profesional no puede superar los dos años, ni ser inferior a 3 meses, y la extensión de la concurrencia del pasante no será superior a seis (6) horas. El número de pasantes no podrá superar tampoco determinados límites y porcentajes, calculados sobre el total de trabajadores. Lo más conveniente es que recurra al departamento de RR HH y Legales para decidir que figura legar es más conveniente para su compañía si ha decidido colocar personal contratado en su proyecto. Lo más simple siempre es hacerlo como dijimos a través de empresas de servicio. Recuerde además que si su proyecto se extiende fuera de las fronteras deberá conocer los regímenes de contratación de otros países.

En los casos donde se contrata personal externo o entornos de proyecto que tienen contratistas,, suele a veces darse la situación de "ellos" contra “nosotros” “nosotros por parte del personal interno. Personalmente he experimentado varios trances y problemas cuando se trabaja en conjunto con contratistas y quiero compartir algunos consejos para mejorar esa relación. •

En primer lugar, se debe saber lo que se está contratando. Sepa por qué usted está comprometiendo contratistas. Se está contratando talento o mano de obra? Si usted está contratando talento talento, entonces está buscando personas especializadas, recursos con experiencia específica, o un valor específico que no se tienen dentro de los recursos internos. Frente a esto está la contratación simple de mano de obra, esto es trabajo, más recursos de llos os que uno cuenta sin considerar específicamente el valor agregado de cierta experiencia o conocimiento. Usted necesita más personas para hacer más trabajo.. En un caso usted querrá pagar un precio adecuado por hora, en el otro caso tal vez deba pagar un sobre sobre-precio precio por la especialización especializació que no posee internamente.

•

En el caso de contratación de personal externo siempre existe un contrato ontrato firmado y aprobado, al que debería agregarse una declaración de trabajo o o SOW, dónde se especifica claramente los detalles del proyecto y el objetivo que se espera de las personas a contratar. Se identifica la fecha de inicio y la fecha final del contrato, el costo horario o mensual, la frecuencia de pago, y las funciones y responsabilidades específicas.

•

Fomentar el trabajo en Equipo. Después de formalizar el Contrato ontrato y la Declaración de Trabajo, rabajo, entonces es importante también formalizar su entrada al equipo. Recuerde, no es el "nosotros" contra "ellos". Es el "nosotros", por lo que son parte de nuestro proyecto. Hemos contratado por razones específicas personal tercerizado, tercerizado ya sea por talento o estrictamente laboral. El equipo, es s el concepto de "nosotros". Ellos no son el enemigo. He estado en algunos entornos, como he dicho, el

"nosotros" contra "ellos", donde se les trata como el enemigo. Eso no es sólo un mal ambiente de trabajo sino que lleva a una gran cantidad de tensión. •

Otro aspecto importante es proporcionar apoyo a estas personas, asegurándose de que usted proporcione a ellos todo lo que necesitan para ponerse en marcha. Qué es lo que necesitan y cuando lo necesitan?

•

Mantener el enfoque para el objetivo que fueron contratados también es importante. Cuando se consiguen nuevos recursos en lugares donde cuesta mucho obtenerlos, especialmente con contratistas, generalmente se cae en el pensamiento de “bien tenemos nuevas personas a bordo, recursos adicionales, vamos a conseguir que hagan todo. Los recursos suben al proyecto para algunas tareas específicas entregables, roles y responsabilidades, y a veces terminan haciendo otro tipo de funciones e incluso trabajando en otros proyectos. En esta situación se ha tergiversado el enfoque inicial. Si esto ocurre porque la empresa ha decidido cambiarlo se debería renegociar el contrato y la declaración de trabajo.

Está prohibida la difusión, transmisión, modificación, copia, reproducción y/o distribución total o parcial del presente Documento, en cualquier forma y por cualquier medio, sin la previa autorización escrita del autor, encontrándose protegidos por las Leyes de Derecho de Autor, Marcas, Lealtad Comercial, Bases de Datos y otras normas Asimismo, queda prohibido cualquier uso de los Documentos o parte de los mismos con fines comerciales. La violación de los derechos antes señalados puede acarrear condenas civiles y/o penales establecidas en las normas precedentemente citadas. Se exigirán responsabilidades a los infractores por todas las vías disponibles en derecho. Fecha y lugar de publicación: Buenos Aires, Abril de 2013. Queda hecho el depósito que establece la Ley 11.723.