Tengo ciertas dificultades en plantear este post. Este tema lo he hablado últimamente con varias personas y creo que tengo cierta sintonía en cuanto a el sentimiento que quiero transmitir aquí.
Desde hace tiempo estoy desarrollando soluciones de empresa basados en la tecnología SharePoint.
Desde el punto de vista de negocio, SharePoint ofrece un entorno basado en componentes , homogéneo, fácil y muy adecuado para soluciones Intrenet.
Desde el punto de vista técnico es una extensión de .NET y ASP.NET. Con una clara orientación a construir aplicaciones compuestas.
El desarrollo con SharePoint es básicamente desarrollar con tecnología .NET y utilizando un rico marco de trabajo que facilita y potencia el desarrollo de soluciones colaborativas y de Intranet, las herramientas son las mismas que en el desarrollo de ASP.NET, contando además con SharePointDesigner.
Supuestamente un equipo de desarrollo ASP.NET debería de poder abordar proyectos en SharePoint siendo igual o más productivos que con ASP.NET sin SharePoint.
En teoría SharePoint debería ser un facilitador de desarrollar mejor y más rápido(esto es lo que intento cuando planteo SharePoint como tecnología base).
Esto en la realidad no está sucediendo así, he tenido varias experiencias, con distintas empresas(proveedoras) y normalmente el desarrollo es menos rápido y tiene muchísimas más dificultades. Con SharePoint el desarrollo cuesta más(es solo mi experiencia)!
¿Cual es el problema? ¿Faltan personas con conocimiento?¿Herramientas? ¿Cuales son vuestras experiencias?
Por mi parte sigo pensando que SharePoint es una buena base para el desarrollo. Seguiré buscando la respuesta a mis dudas:-)
Bueno, este post refleja bastante fielmente lo que es mi opinión al respecto.
El problema que trata de resolver Sharepoint, en términos de ‘implementar y desplegar rápidamente web sites de gestión de contenidos’ está claro.
La solución que propone Sharepoint es autodescriptiva e ilustrativa en cuanto te empiezas a documentar sobre este framework.
Pero, en mi opinión, falla estrepitosamente en una de las premisas necesarias para la solución: sencillez. Desarrollar cosas sobre Sharepoint que se aparten un poco de lo que es su piedra angular (listas) se hace complicado, largo y tedioso.
En un principio pensaba que era cosa mía, una apreciación personal. Pero al final lo que mandan son los hechos, y mi (más bién breve) experiencia ha demostrado que los desarrollos sobre Sharepoint son sobre todo eso: complicados, largos y tediosos.
En un proyecto en el que anduve trabajando, se dedicó una cantidad de recursos (económicos, manpower) a conseguir una serie de cosas; lamentáblemente no se llegó a ninguna parte (y hace muuuchos meses que se empezaron a hacer cosas), y el status actual del proyecto es … poco menos que parado. Con resultados reales básicamente cero.
Y, como no, los hechos y los resultados mandan, más que la teoría y las buenas arquitecturas.
Saludos
Para afinar más mi punto de vista:
Sharepoint es, para un problema complejo, una solución compleja.
Debiera ser una solución más sencilla.
Entiendo que el argumento de Jorge orbita alrededor de la idea de que no hay suficientes programadores suficientemente buenos (todavía).
Dejando esta última idea aparte, el desarrollo de soft corporativo -al menos muy a menudo- necesita ser, sobre todo, barato.
Es decir, no requerir de tiempos de desarrollo muy largos, no requerir de los mejores (y por tanto, ‘más caros’) desarrolladores.
Con este planteamiento, soluciones basadas en Sharepoint, que requieran de cierto volumen de desarrollo, tienen bastantes posibilidades de no llegar a ser culminadas con éxito.
De todos modos, yo soy de los que piensan que se da poca importancia al esfuerzo necesario en desarrollo.
Pienso que a menudo se tiene la impresión de que el desarrollo -una vez concebida la idea y puesta en abstracto- va a resultar fácil y rápido.
Y esto (imho) es un error, desarrollar soft no es trivial, ni fácil ni barato; y a menudo se le está dando menos importancia -y recursos- que a otros ámbitos.