sobre - formato campos sharepoint
¿Cómo se percibe SharePoint en su empresa? (13)
ACTUALIZAR Un momento interesante para volver a esta pregunta. ¿La percepción sigue siendo la misma ahora que SharePoint 2010 comienza a consolidarse? Ciertamente, la implementación de 2010 no deja de tener sus propios desafíos, ¿pero la percepción empresarial es uno de ellos?
ACTUALIZACIÓN: Nuestra implementación ahora está en marcha con algunos proyectos de alto perfil que se lanzarán en las próximas semanas, así que estoy bastante interesado en ver si el entorno ha cambiado.
Pregunta original
Tenemos un problema dentro de nuestro entorno de trabajo donde la percepción de SharePoint es:
a) La bala de oro, la respuesta a todos nuestros problemas.
b) Una aplicación que resuelve o no un problema específico.
c) Una herramienta frustrante que no cumple con sus exigentes requisitos.
Ahora, en mi opinión, SharePoint (o más específicamente en nuestro caso Microsoft Office SharePoint Server 2007) es un marco sobre varias tecnologías de nivel inferior de Microsoft (IIS, ASP.Net, WSS 3.0, .Net Framework, Windows Workflow Foundation entre otras) y como tal, se puede desarrollar para hacer cualquier cosa (tiempo y recursos).
Las actitudes que se han formado en mi organización (y otras estoy seguro) es una combinación de Microsoft Marketing Machine y el deseo de una organización de obtener la "bala de oro" frente al mayor número de personas posible sin decir "¿Para qué? '' ¿o por qué?'' o en algunos casos incluso ''¿Cómo?''
¿Es esta una actitud y percepción compartida por otros desarrolladores de SharePoint?
Conozco a mucha gente y organizaciones donde ha habido algunas ventas de "plata / oro / bala mágica".
Veo gente que quiere unificar la información almacenada en su negocio, generalmente con grandes unidades compartidas y documentos diseminados por todas partes, aplicaciones dispares basadas en la web.
Las organizaciones quieren que todo esté disponible para sus empleados de forma fácil (capacidad de evaluación) y quieren que parezca que es parte de una gran aplicación para que los usuarios de la organización tengan un lugar consistente al que puedan dirigirse para todo lo que necesitan hacer.
La confusión que se establece es que las personas piensan que debe hacerse "en" SharePoint, en lugar de utilizar SharePoint para juntar todas las partes y darle contexto dentro de la organización (por ejemplo, la gran aplicación "encontrar una flor" se encuentra en el sección de sección de jardinería del sitio).
El problema es que una buena arquitectura de la información requiere muchísimo trabajo y planea dónde ir a parar. Con demasiada frecuencia, SharePoint se usa como una nueva unidad compartida y las cosas simplemente se vuelcan donde sea.
Para los desarrolladores, esto simplemente no es importante para su trabajo diario, pero es importante para el PM o el gerente. El desarrollo puede generar una gran cantidad de documentos y un sitio de desarrollo bien creado puede hacer que sea más fácil encontrar que "el documento de diseño para ese proyecto nunca lo hicimos, pero lo necesitamos ayer".
SharePoint no es realmente para el trabajo principal de los desarrolladores (es decir, no es el entorno de desarrollo o el control de origen).
De lo que he observado en una variedad de organizaciones y comentarios de terceros, se trata de una sola palabra: Expectativa . Hay quienes tienen la expectativa de que SharePoint es la panacea para todos los problemas. Esta escuela de pensamiento es que es el mejor de todos los mundos; un producto rico y listo para usar que ofrece un amplio conjunto de herramientas de colaboración que también puede codificar para ampliar las características mencionadas anteriormente. Y debido a que SharePoint es un producto .NET, puede agarrar a su desarrollador promedio de Microsoft y comenzar a obtener todo el valor de RAD de inmediato.
Comenzar con esta expectativa es establecer la norma a un nivel que a) Microsoft nunca tuvo la intención real yb) es muy poco probable que se logre sin desarrolladores de SharePoint con conocimientos y un entorno adecuado. No lleva demasiado tiempo darse cuenta de que es un poco más complejo que eso. Sí, puedes codificar contra SharePoint pero no puedes esperar que sea análogo a construir una aplicación .NET. Todo, desde los requisitos del entorno de desarrollo hasta el proceso de lanzamiento y el mantenimiento continuo, es más complejo que simplemente crear una aplicación ASP.NET. Esto también necesita ser contextualizado con el hecho de que en muchas organizaciones SharePoint es un entorno centralizado y compartido que a menudo trae consigo un nivel de gobernanza que no le permitirá simplemente implementar soluciones a voluntad.
De regreso a las expectativas; cuando se supone que esta es una gran herramienta para actividades de colaboración, portales o gestión de documentos, es un producto fantástico. Incluso proceda con el desarrollo en la plataforma con la expectativa de que requerirá algunas habilidades especializadas y el proceso de implementación y administración diferirá de la tradicional pila .NET pero lo hará con los ojos bien abiertos en cuanto a las implicaciones.
En resumen, es un gran producto y se puede percibir de manera muy positiva dentro de una organización, siempre que las expectativas se establezcan de forma adecuada. Sin embargo, si queda atrapado en el bombo sin entender completamente las implicaciones, hay una buena posibilidad de que pueda establecer una expectativa que no podrá cumplir.
En cuanto a su actualización de "si el entorno ha cambiado por ahí" ... En mi experiencia las cosas han empeorado un poco. Esto se debe principalmente a la interfaz de usuario.
Como desarrollador, a menudo escucho el comentario "parece que SharePoint" que muestra que el producto se ve cada vez más anticuado. (He estado decepcionado con el aspecto desde el lanzamiento.) Esto significa una gran cantidad de trabajos de CSS y gráficos que es doloroso, ya que hay muchas tablas en uso y un montón de mierda HTML.
Aparte del aspecto, mucha gente considera que la interfaz no es intuitiva y frustrante. Particularmente para los usuarios menos conocedores solo cargando un documento hay muchos clics y páginas diferentes.
También debido a la interfaz de usuario deficiente, me piden que haga muchas cosas sobre Web-2.0 / AJAX / jQuery para mejorar la interfaz y dar mejores comentarios a los usuarios. El producto no fue diseñado para esto. Lleva mucho tiempo cuando jQuery necesita servicios web que son muy decepcionantes en la versión de 2007. (Afortunadamente, alguien finalmente ha iniciado una biblioteca jQuery para SharePoint Web Services ).
Como sucede a menudo cuando la próxima versión de un producto está cerca del horizonte, desesperadamente espero que SharePoint 2010 sea sólido como una roca, por lo que hay pocas razones para comenzar nuevos proyectos en la plataforma 2007 cuando lleguemos a RTM para 2010.
En la organización para la que trabajo, depende completamente del nivel de conocimiento técnico que tenga una persona. El personal de negocios lo ve como una oportunidad para tomar una plataforma preconstruida y aplicar algunos pequeños cambios con relativa facilidad. Sin embargo, la realidad es que para el personal técnico es una pesadilla trabajar con él. Las compensaciones son a menudo de un extremo a otro, lo que significa que si hacemos algo con la funcionalidad incorporada, es relativamente fácil, pero la experiencia del usuario final está lejos de ser satisfactoria. En el otro extremo del espectro, generalmente podemos obtener una mejor experiencia de usuario, pero a costa de una cantidad extrema de mano de obra intensiva.
Personalmente, como individuo en el aspecto técnico, no recomendaría SharePoint para ningún entorno porque cuando se tiene en cuenta el costo de la licencia, además del tiempo de desarrollo para hacer que todo valga la pena (lo que, en mi experiencia, siempre lleva más tiempo) que una aplicación ASP.NET personalizada) terminas con una ridícula pérdida neta. La mayoría de los sitios de Intranet pueden funcionar con la versión gratuita (WSS) con relativa facilidad; sin embargo, por lo general no hacen mucha personalización y simplemente lo usan como un repositorio de documentos.
Por alguna razón, el personal de negocios tiene una opinión completamente deformada del producto. Creen que SharePoint finalmente les ahorra dinero. Digo que esta es una opinión distorsionada porque cada proyecto que he visto que usa SharePoint ha superado con creces mis estimaciones para una aplicación ASP.NET personalizada (tanto a corto como a largo plazo). En un caso particular, he estado involucrado en un proyecto que literalmente habría tomado un mes como máximo (incluido el tiempo de desarrollo, control de calidad, etc.) en una aplicación ASP.NET personalizada. La misma aplicación en SharePoint, sin embargo, ha estado en desarrollo durante casi un año. La conclusión es que el proyecto simplemente no pertenecía a SharePoint, sin embargo, el personal comercial se negó a aceptarlo hasta que no tuvieron otra opción.
Si está considerando SharePoint para su organización, primero le recomiendo que haga su tarea. Espere una gran curva de aprendizaje y mucha frustración. La mayoría de su personal técnico reconocerá de inmediato los defectos del producto y los señalará con extrema frustración. Esto es normal en un entorno de desarrollo de SharePoint. Si, al final, está dispuesto a hacer estos sacrificios con poco o nada que ganar, SharePoint es la solución adecuada para usted.
Entonces noté que nadie realmente ha tenido una experiencia realmente positiva de SharePoint hasta la fecha, y sin embargo, todos lo están comprando. Me confunde cómo MS ha logrado esto?
Hay muchos proyectos simples que tenemos en las tuberías que se beneficiarán enormemente de una inyección de SP. Pero me imagino que en la mayoría de los casos buscaremos ''combinar'' SharePoint en nuestra combinación de productos y tecnologías. Lo que hace bien lo hace realmente bien, pero para escenarios específicos casi siempre va a necesitar algunos elementos de personalización (ya sea CSS, JScript o código del lado del servidor), y puede que no siempre sea la solución adecuada.
Hace poco escuché a un analista de MS referirse a SharePoint como arcilla de modelado y eso me lo resumió.
Mi actual compañía es de la opinión de que deberíamos potenciar al usuario de intranet dándole SharePoint. De esta manera, pueden administrar / agregar / eliminar usuarios, sitios, páginas a voluntad. Y las TI pueden utilizar su tiempo de forma más productiva, como Google para gatos lol.
Usamos SharePoint bien y ampliamente. Una gran cantidad de listas de SharePoint en todo el lugar.
Lo que no sucede es esa idea de autoservicio que realmente vende el producto internamente ... y el 99% de los departamentos que deberían "hacerlo ellos mismos ... o simplemente simplemente usarlo ..." ¡nunca lo han tocado!
- El único software que la mayoría de la gente conoce es Excel
¡Aquí la gente envía imágenes de capturas de pantalla para solucionar problemas y hace manuales con solo imágenes pegadas dentro de archivos de Excel!
(Solía trabajar con una máquina Solaris vieja, sin Open Office, así que aunque uso XP ahora ... todavía me duele ver que esto suceda)
Internet para ellos es la página de inicio de Yahoo y el correo electrónico.
Ellos (los males) quieren que estas personas resuelvan sus necesidades comerciales a través del uso de SharePoint.
Comprobación de la realidad: autoservicio o no, eso simplemente no sucede ... no usan SharePoint para resolver ningún problema por sí mismos, pero nadie lo nota de todos modos ...
... bueno, eso es una mentira, la gente lo nota, pero mencionar la disparidad entre cómo la administración piensa que se usa SharePoint y la realidad, es una forma segura de convertirse en el niño pelirrojo de la empresa.
Este empoderamiento del "usuario normal" es una característica fantasma, nosotros en TI siempre terminamos haciendo el trabajo ... cualquier trabajo ... que debería haberse resuelto teniendo la herramienta estupenda SharePoint ... terminamos creando los sitios, las listas , los flujos de trabajo, y generalmente somos los únicos que los utilizamos.
Nada de esto debe ser gracioso ...
(el único flujo de trabajo utilizado fuera del departamento de TI con SharePoint es el anuncio mensual de almuerzo de la empresa, que proviene de GA o HR en un correo electrónico automático después de agregar un nuevo elemento de la lista a una lista de sharepoint hecha por TI)
Se considera que SharePoint es la bala de oro para hacer que las TI sean más productivas al liberar TI de dichas tareas más pequeñas, pero esas tareas más pequeñas siguen siendo MÁS, tenemos el costo adicional de tratar de hacer que los otros departamentos lo hagan ellas mismas.
Creo que después de años de martillar internamente el producto en la garganta de la gente, ahora hay un conocimiento mínimo de lo que es SharePoint, y se usa bastante. El problema es que la forma en que las personas lo usan es como lo prometió Microsoft, pero no superior. administración:
Almacenamiento de documentos y flujos de trabajo basados en listas de SharePoint: ¡excelente!
Pero los poderes deberían comprender que esto nunca será algo con sus propias piernas que puedan estar libres de la enfermería y la crianza de TI.
Trae a colación un punto que odio acerca de todo el proceso "déjalos que lo hagan ellos mismos", permite que los usuarios que no son de TI desarrollen cosas por sí mismos sea contraproducente en todos los puntos
(Ingrese los formularios de InfoPath ...)
Nosotros en TI pasamos nuestras vidas aprendiendo cómo hacer software y cómo mantenerlo (y aún hacerlo mal), y ahora tenemos a alguien que solo quiere hacer Marketing [o lo que sea] gestionar sus propios datos y proceso interno de UI + lógica de proceso. !
Es una curva de aprendizaje innecesaria (para todos) que nos impulsará a todos a ir a buscar trabajo a otro lugar y dejar a TI con la tarea imposible de depurar objetos de negocios a medio cocinar insaciables e inmanejables.
Ingrese la palabra de moda en abundancia: MOSS hace CMS ...
Resultado: ahora nos movemos de Interwoven como un CMS (estaba siendo utilizado como una herramienta glorificada de servidor de cliente FTP automatizado) a MOSS.
Tengo más de un año de experiencia en SharePoint y ahora MOSS, pero toda la idea de la administración superior es:
"haga que el departamento de marketing lo haga por sí mismo, porque MOSS es SharePoint ++ .. autogestionable"
Creo que MOSS es una herramienta realmente genial, pero aquí está mi comentario en una reunión reciente:
"Bueno, creo que Marketing debería echarle un vistazo rápido a SharePoint Designer para que sepan lo que les espera"
respuesta recibida: "Eso es demasiado técnico ..." <<<< Realmente esperan realizar una marca completa utilizando la función de fábrica de hacer clic en las opciones de los sitios.
Están planificando externalizar el desarrollo de la marca inicialmente y mejorarla a partir de ese momento ... y no tiene sentido tratar de explicarles lo contrario ...
¿Yo? ... Pienso en la búsqueda de trabajo cada vez que tenemos una reunión en este proyecto y agradezco a los dioses que no soy el gerente de proyecto en este caso.
En pocas palabras: no culpo a la herramienta SharePoint, pero puedo ver cómo la gente probablemente la usa con el estado de ánimo equivocado en las oficinas de todo el mundo ... al menos es muy mal utilizada e incomprendida en mi empresa, y seguirá siendo defendida por el mal razones por los poderes que serán en los próximos años.
Nuestra experiencia de SharePoint en mi empresa anterior, un grupo de FMCG en Sudáfrica, fue positiva en muchos sentidos (principalmente WSS, aunque también implementamos MOSS).
Rechazamos demasiado la personalización y decidimos utilizar la mayor cantidad de funcionalidades encuadradas como sea posible, personalizando solo cuando realmente se necesita.
Varios grupos de usuarios empresariales lo adoptaron bastante bien para fines de colaboración y gestión del conocimiento en torno a proyectos o cuestiones departamentales, y en algunos casos sitios de extranet dedicados a asociaciones de clientes particulares. Con mucho, los sitios más efectivos fueron aquellos en los que los CIO de las distintas unidades de negocios participaron directamente ; parecen estar bien posicionados para comprender la tecnología y ayudar a la gente de negocios a ver la luz. Creo que un factor importante también fue el hecho de que uno de los CIO había impulsado la visión general de un portal basado en perspectivas que lo abarcaba todo como parte de la estrategia de información durante años antes de que realmente tuviéramos algún producto en funcionamiento. Creo firmemente en la difusión de SharePoint orgánicamente desde algunos puntos de alto valor en lugar de un disco de arriba hacia abajo pesado. Pero a medida que se implementó SharePoint, la difusión estuvo bien respaldada por nuestra función de administración de cambios, que estaba alojada en TI pero bien arraigada en el negocio.
Para una de las empresas, creamos un sitio de colaboración de extranet general y capacitamos a una persona en SharePoint. Fue una gran victoria para un usuario de negocios el poder crear, en minutos, subsitios para la colaboración con cualquier socio comercial suyo (aparte de la creación de la cuenta, que IT aún tenía). Este tipo de necesidad se trabajó con anterioridad por desarrolladores y diseñadores de sitios web durante meses.
Para mi equipo (el equipo de desarrollo), usamos WSS extensivamente para colaboración, KM, etc. pero también impactó la entrega de nuestra solución de manera significativa. Por un lado, habíamos estado atados muchas veces en el desarrollo de pequeñas aplicaciones de nicho que departamentos desesperadamente querían pero que, francamente, costaban mucho más de lo que debían y tomaban demasiado tiempo. Al estar muy familiarizados con las ofertas de WSS, cada vez más descubrimos que podíamos ayudarlos a establecer una solución adecuada, utilizando solo WSS, en una fracción del tiempo . Mientras que algunos eran lo suficientemente simples para ejecutarlos con ellos (algunos tipos progresivos de secretarios están adoptando sitios de SharePoint como adoptaron Outlook), otros requieren nuestra asistencia continua, pero el mantenimiento fue mucho más ligero que el de un C # / ASP personalizado. Aplicación .NET En pocas palabras, podríamos ofrecer un valor más rápido y usar el código solo donde realmente hiciera la diferencia, reduciendo el TCO.
Creo que SharePoint nos está ayudando en una clase de soluciones donde compilamos en lugar de codificar todo. En un caso, por ejemplo, una empresa quería hacer pedidos haciendo que los humanos los envíen en una hoja de cálculo de Excel. El purista en nosotros se resiste y quiere buscar algo más hermético, pero no estábamos en posición de dictar y debíamos cumplir con esas restricciones y con agilidad. Así que creamos un sitio de WSS (simplemente creando un subsitio desde el sitio de colaboración de la extranet de raíz que habíamos configurado previamente) y le pedimos a las personas que adjuntasen sus hojas de cálculo en una lista. Configuramos BizTalk para recogerlos, extraer los datos, enviar pedidos al sistema ERP y regresar y marcar los elementos de la lista WSS con un estado. Así que todavía escribimos el código, pero usamos la funcionalidad WSS out-the-box para toda la experiencia del usuario final.
Todavía tengo grandes esperanzas para SharePoint como una plataforma general de desarrollo de aplicaciones web (es decir, aquí hay una gran cantidad de plomería, ahora aprovecho y amplío según lo necesite). Todavía no hemos profundizado ya que hay una barrera de aprendizaje y también la pendiente resbaladiza de un montón de código en un lugar que puede ser difícil / complicado de mantener. Tengo planeado seguir explorando si eso es cierto, pero mientras tanto, creo que hay toneladas de valor para explotar de inmediato en una mentalidad de composición de soluciones .
Nunca pensé qué hacer con eso. Nos dejó aturdidos y confundidos y terminamos pasando a otras cosas.
Sé que esta pregunta fue para los desarrolladores (y un poco viejo), pero me gustaría compartir una opinión desde la perspectiva de un usuario de negocios. Nuestra empresa (más de 75,000 empleados en todo el mundo) implementó la plantilla de "Equipo de sitio" de MOSS 2007, retiró nuestro documentum e-Rooms existente y nos dejó sueltos con capacitación CERO, información CERO.
Los usuarios de toda la empresa utilizan los sitios de su equipo como repositorios de documentos, punto. Hay algunos bolsillos de usuarios que tienen un poco más de comprensión y han comenzado a configurar y usar la funcionalidad de colaboración de MOSS 2007.
También debo mencionar que nuestra compañía todavía usa IE6 y MS Office 2003. (Es una pena que todo lo que no podemos hacer con SharePoint sea solo por eso).
Nuestra empresa no recompensa al usuario final que encuentra formas de aprovechar las herramientas proporcionadas para crear una mejor colaboración y nuestros departamentos de TI / TI se niegan a ayudar a proporcionar materiales de aprendizaje, oportunidades o ayudar a los usuarios finales de ninguna manera. En la mentalidad actual de perro come perro: despido después del despido con 1 persona que ahora hace el trabajo de lo que 5 o más hicieron en el pasado, las personas simplemente no tienen tiempo, si no es parte del enfoque central de su trabajo.
Me asusta que haya aprendido e implementado para varios grupos alguna funcionalidad colaborativa, aunque lo aprendí en mi propio tiempo, eso significa que se me percibirá como si no tuviera suficiente trabajo para mantenerme ocupado. y por lo tanto - prescindible?
En cuanto a cómo me siento sobre SharePoint: me encanta compartir. Tiene un poco de capacidad en la mano de los usuarios finales ... me puede llevar un poco el momento ah-ha, pero al final, lo entiendo. A veces me siento un poco frustrado al compilar páginas, desearía que fuera CSS y HMTL, pero, por supuesto, estamos bloqueados para usar el diseñador de sharepoints.
Hubiera sido un mejor despliegue si 1. Se incluyó la capacitación en el despliegue. 2. Se implementó una gestión de cambio sólida durante el despliegue.
Siempre que usted o alguien de la empresa tenga experiencia tecnológica, su empresa se beneficiará de la versión gratuita de Sharepoint. Asegúrese de comprar Sharepoint Designer 2007.
Mi compañía no está realmente al tanto de qué es y qué es sharepoint. En realidad, es el "back-end" de nuestro sencillo sistema de programación de producción y seguimiento de piezas. Los usuarios ven páginas aspx básicas creadas en el diseñador de sharepoint.
Sharepoint me permite crear listas rápidamente para administrar la información. Veo compartir como una extensión de Excel a un entorno web. La mayoría de las personas usa Excel para crear listas de información. Sharepoint habilita la funcionalidad web para esa información de lista.
Uso la versión gratuita de Sharepoint y la he personalizado extensamente con Sharepoint Designer. Soy un ingeniero con algunas habilidades de programación. Sé lo suficiente que he podido crear páginas web simples pero útiles para la recopilación de datos.
Primero utilicé WSS 2.0 para crear un rastreador de errores de software. En ese momento (2003) descubrí Fogbugz y usamos la versión de prueba de Fogbugz. Todo el mundo amaba Fogbugz, principalmente porque podía asignar problemas y los correos electrónicos se enviaban automáticamente. Una lista de seguimiento estándar de problemas de Sharepoint logra esto también. Fogbugz claramente tenía muchas más características, pero la gerencia decidió que usaríamos el punto compartido .....
Al final, sharepoint se usó ampliamente para administrar la información del proyecto y comunicarse con los clientes. Esto fue hecho con poca personalización. Acabo de crear algunas plantillas de sitio y cada vez que se creó un nuevo proyecto, se creó un nuevo sitio con bibliotecas de documentos, listas de seguimiento de problemas, calendarios, etc.
Soy un fan de sharepoint !!! Ah, sí, tiene muchas limitaciones y sus artículos de nivel superior infringen las mejores prácticas de la base de datos, ¡pero Sharepoint WORKS!
Tenemos SP aquí (no MOSS simplemente vainilla).
La mayoría de las personas no están seguras de qué hacer con eso. No está acostumbrado a su potencial, pero nadie (incluido yo mismo) desea invertir ese tipo de tiempo.
La forma en que se usa aquí podría reemplazarse fácilmente con un recurso compartido remoto y una estructura de carpeta / directorio predefinida.
Yo diría que compartir no es malo! ¡La forma en que maneja la información es increíble! Sin embargo, una cosa que me molesta es que es un poco demasiado complicada para los usuarios finales, nuestra organización pasó dos meses educándolos, pero el resultado está muy por detrás de nuestras expectativas. A veces parece que obtuvimos un avión supersónico en los años 50 del siglo pasado. ¡No podemos ponerlo en pleno uso!
tl; dr : Sharepoint no da la impresión de estar centrado en ayudarme a hacer mi trabajo.
No muy bien.
En nuestro trabajo, encontramos que Fogbugz proporciona la capacidad que realmente queremos (y usamos) de una manera claramente más intuitiva, más rápida y, por lo tanto, más útil. Claro, puede crear un flujo de trabajo de Sharepoint para muchas de estas cosas, pero ¿por qué lo haríamos? Obtenemos un flujo de trabajo sensato y características directamente de un sistema que parece estar mucho más centrado en ayudarnos a hacer nuestro trabajo.
- Flujo de trabajo de desarrollo: nos gusta mucho la estructura centrada en el caso.
- Discusiones informales: las discusiones de Fogbugz son paralelas a los grupos de Usenet antiguos y son excelentes para hablar sobre un tema antes de convertirlo en un caso en el que es necesario trabajar.
- Discusiones / documentos persistentes: los wikis son un gran lugar para que construyamos el material que necesitamos, particularmente la documentación.
- Integración de SVN: esto se está volviendo más importante para nosotros.
- Informe de proyectos / programación basada en la evidencia: esto se está convirtiendo rápidamente en un factor crítico para nuestro proceso de planificación e información.
El hecho definitivo: hemos tenido Sharepoint aquí durante bastante tiempo sin interés real por parte de los desarrolladores. Presentamos Fogbugz y casi de inmediato el equipo de desarrollo lo adoptó y lo convirtió en parte de su rutina diaria.
NOTA: esto se parece a un anuncio de Fogbugz, pero hay otras herramientas que parecen querer ayudar mucho más a Sharepoint.