Desarrollos Internos VS Desarrollos Externalizados

Incentivado por los extraordinarios Blogs que leo últimamente entre los que destaco http://efuncionario.com/  ,  http://jagglarian.blogspot.com.es/  (elaborados por dos compañeros TIC que todavía no tengo el gusto de conocer) y de mi amigo Javier Morales (http://javomorales.heroku.com/) me he animado a tratar de expresar mi opinión sobre aquellos temas de trabajo con los que ando relacionado con la intención de compartir y aprender al mismo tiempo.

Desde que entré en la Administración Pública siempre he estado ligado con temas de Desarrollo en general y con Administración Electrónica en particular. Así pues, mis entradas normalmente versarán sobre como enfocar proyectos SW ligados con Administración Electrónica.

En esta primera entrada aunque quizá todo lo que comento pueda parecer bastante obvio, me va a servir para centrarme en el tema y así poder luego ir profundizando en mayor detalle algunas de las cuestiones que comento.

Entrando en materia, las diferentes formas de acometer un proyecto de desarrollo se pueden clasificar en:

Desarrollo Interno: Entendiendo por tal, el desarrollo en el que todo el personal involucrado en el proyecto es “de la casa” y por tanto funcionario (en este caso perteneciente al Departamento responsable del proyecto). Actualmente, este tipo de configuración de equipos rara vez se da en nuevos desarrollos.

Desarrollo Externo: Desarrollo en que todo el todo el personal involucrado en el proyecto es del ámbito privado. Este tipo de desarrollos también se conocen como proyectos llave en mano y en los cuales el personal de la Administración delega gran parte de la gestión del proyecto limitándose a establecer los requisitos (mediante los correspondientes pliegos) y a validar la correcta realización de los mismos cuando se procede a la entrega.

Desarrollo Mixto: Parte del equipo de proyecto son funcionarios y parte pertenecen al sector privado. Un caso concreto es aquel en que el jefe de proyecto es funcionario y el resto de perfiles del equipo pertenecen a una empresa.

Partiendo de la base que en un proyecto de desarrollo como mínimo han de existir los siguientes perfiles: Jefe de Proyecto, Analista y Programador,  mi opinión al respecto, siempre y cuando se tengan los medios necesarios aunque sean precarios, es que se debe tratar de que el perfil jefe de proyecto e incluso el perfil analista sean de la casa por las siguientes razones:

• Obviamente por el tema económico. Abaratamiento del coste de desarrollo.
• Control del proyecto. Si el jefe de proyecto y analista/s  son funcionarios se garantiza un mejor mantenimiento del mismo.  Si queremos retener el conocimiento de los proyectos en la Administración y no delegarlos a las empresas me parece imprescindible que el jefe de proyecto sea interno.  
• Facilita la integración con otros proyectos. Es difícil hoy en día que el proyecto/aplicación no esté integrado con otros. En caso de que los proyectos sean gestionados completamente desde dentro, es mucho más sencillo establecer reuniones de trabajo donde se lleguen a acuerdos de forma ágil y donde desde el primer momento se analicen los posibles problemas que pueden ocurrir en dicha integración.
• La motivación para que salga adelante el proyecto y la capacidad de involucrarse es infinitamente mayor.

Conviene aclarar que el perfil de jefe de proyecto significa asumir las responsabilidades que derivan de dicho cargo. Es decir que no vale ser Jefe de Proyecto y luego contar con otro Jefe de Proyecto externo que sea realmente el que hace las tareas del proyecto asociadas a dicho rol.

Detallando un poco más mi  punto de vista al respecto, opino que cuanto más mixto sea el equipo mejor. En este sentido es interesante que los análisis sean internos e incluso si tienes personal en tu equipo capacitado para programar, habría que contar siempre con ellos en el equipo. Esta configuración mixta  garantiza que “no te cuelen cosas”. Este tema que estoy comentando y mi postura al respecto puede parecer baladí, pero he visto contratos donde se externalizaban absolutamente todos los perfiles y los resultados no han sido positivos.

Cuando he indicado que como mínimo han de existir los 3 perfiles (jefe de proyecto, analista y programador) he considerado que el Analista puede y debería asumir trabajo en las fases de análisis y diseño, y los programadores junto con el resto de perfiles colaborar en otras fases.

Puede parecer que lo  ideal es disponer de perfiles de todo: Jefe de Proyecto, Analista, Diseñador, Programador, Tester, Diseñador gráfico ,Gestor de calidad…  pero en la vida real y más en los tiempos que corren  creo que los equipos de trabajo se parecen bastante más a la hipótesis inicial planteada.  Además, hay una ventaja de tener un grupo de trabajo reducido y es que la gestión del proyecto suele ser más ágil y efectiva (recomiendo leer el artículo El mito del hombre mes).

Me parece importante reseñar las tareas acometidas por el diseñador gráfico, sobre todo en ciertos proyectos como una web, que hacen que sea conveniente contar con este perfil. También puede ser importante dicho perfil en aplicaciones de gestión, ya que lo que el usuario ve finalmente es la interfaz. Puede ser un proyecto muy complicado desde el punto de vista tecnológico, pero esa complejidad nunca la apreciaría un usuario final. Por lo general suele existir bastante diferencia entre una aplicación/web en la que ha intervenido un diseñador gráfico a otras en las que no.