Un departamento web desarrolla una gran cantidad de CMS utilizando herramientas y marcos amigables para desarrolladores, principalmente utilizando tecnologías de código abierto.
Se les pide que desarrollen y admitan un sitio web utilizando Sharepoint para cumplir con los requisitos definidos por TI propuestos en uno de sus grandes clientes empresariales. Son capaces de desarrollar en la pila de Windows, pero no quieren usar Sharepoint porque no es apto para desarrolladores y ni siquiera es apropiado para un CMS de sitio web de marketing externo. Están familiarizados con la rica historia anecdótica de los sobrecostos de Sharepoint y el desarrollo continuo limitado de funciones.
En pocas palabras, esta es una pregunta sobre el CMS más amigable para los desarrolladores que tiende a satisfacer a estos departamentos de TI que marcan casillas de verificación. Pero la pregunta general del lugar de trabajo es: ¿cómo pueden los desarrolladores que respaldan el marketing comunicar de manera más efectiva a los tomadores de decisiones de TI obsesionados con la lista de verificación de funciones el costo potencial de la incompatibilidad del desarrollador y los gastos generales de mantenimiento en una herramienta grande como un CMS?
Me siento calificado para responder esta pregunta como gerente de desarrollo desde hace mucho tiempo que se asoció con departamentos de marketing en cuatro organizaciones diferentes para construir sistemas similares. Dicho esto, puede que no te guste mi respuesta, pero es una que necesitas escuchar.
Esta pregunta no parece tener en cuenta las necesidades del usuario comercial en absoluto.
El desarrollo de aplicaciones no es un fin en sí mismo. Si está desarrollando aplicaciones de línea de negocio, lo está haciendo para satisfacer una necesidad comercial. Lo que llama "tomadores de decisiones de TI obsesionados con las listas de verificación" son personas que están tratando de encontrar soluciones a problemas comerciales específicos. Probablemente no se preocupen demasiado por las preferencias personales de su equipo de desarrollo, y ¿por qué deberían hacerlo? Ponte en sus zapatos, ¿ te importaría? Desde su perspectiva, SharePoint puede ser "apto para el marketing". Y ellos son el usuario final. ¿La opinión de quién importa más?
Su pregunta parece muy condescendiente con los departamentos de TI y marketing de su cliente, y si se acerca a la contratación con esta actitud, no progresará mucho. Si cree que la plataforma debe ser el producto X en lugar del producto Y, y parece que prefieren el producto Y, debe explicarles cómo les beneficia elegir el producto X. Tal vez piense que el producto X será más fácil de mantener: para ellos, eso significa que puede ofrecer nuevas características más rápidamente. vende eso
Tendrá mucho más éxito si trata de asociarse con los departamentos de marketing y TI de su cliente para tomar la mejor decisión y evitar la frase "apto para desarrolladores".
He estado en el mundo de CMS/LMS por más de 10 años. Creo una gran cantidad de soluciones personalizadas que generalmente admiten de 5 a 10 000 personas en diferentes sectores en nuestro gran mundo. He usado al menos 6-7 CMS PHP de código abierto muy grandes y los he personalizado mucho para lo que hacemos.
Y sí, tenemos Sharepoint. Al comienzo de cada proyecto, nuestros representantes de Sharepoint y Jive vienen y demuestran que pueden hacer esto y aquello. Llegará a esto más en un momento.
Así que ahora mismo tenemos una iniciativa con todos los VP del sector para que toda nuestra empresa esté en ONE CMS. Todos nuestros sectores hacen cosas muy, muy diferentes. Manzanas, naranjas, plátanos y sandías. Este proyecto tiene una lista de verificación en una hoja de cálculo de Excel de más de 150 cosas diferentes. Sopesan cada una de estas cosas y supuestamente sumarán la puntuación y elegirán la solución, ya sea del proveedor o interna, con la puntuación más alta. Tenga en cuenta que las posibilidades de que este proyecto termine alguna vez son muy, muy bajas.
Así que soy el líder técnico del proyecto. Siento que soy muy confiable y soy bastante realista sobre lo que nuestro pequeño equipo de desarrollo puede hacer frente a un proveedor. Bueno, 1 año después de este proyecto, tenemos un proveedor que tiene un modelo que no es escalable a piezas de contenido de 5K, y mucho menos los 100K que tendremos en un año. Y otro proveedor con el que estamos sujetos a un contrato actual es tan horrible que no creerías las historias sobre ellos (cambian el código en vivo a la mitad del día, repetidamente y, a veces, por accidente).
Esto se debe a que estos proveedores les mostraron algunas cosas llamativas con excelentes gráficos y actuaron como si todo funcionara mágicamente .
El problema con la hoja de cálculo es que solo incluye ventajas. Si hace algo horrible (relaciones de datos) no hay menos. Esta es la falacia en la que cae la alta dirección. El cebo es el tipo más común de CMS que he escrito en Algernon CMS .
El CMS de Algernon es el modelo de CMS en el que pones las cosas en categorías. La gente sigue poniendo cosas similares en categorías. Al principio, el CMS no es mucho. Pronto es genial porque los conceptos básicos son fáciles de encontrar: estos se ingresan primero. Luego tiene toneladas de cosas y sigue siendo realmente bueno. Pero... Luego las cosas se vuelven viejas y obsoletas, la gente pone cosas duplicadas, o simplemente hay demasiado (generalmente alrededor de 1-1.5 años en un CMS muy utilizado). Y se cae. Eligen otro CMS de Algernon porque el anterior ya no funciona (sarcasmo) y enjuagan y repiten.
Tenga en cuenta que el modelo SE es más o menos lo contrario de un CMS de Algernon. Su objetivo es una pieza de contenido para una pregunta y tiene mecanismos de autolimpieza. Sharepoint es un CMS de Algernon seguro. Tal vez no sea el peor infractor y definitivamente más escalable que la mayoría, pero es realmente difícil hacerlo realmente fácil de usar.
¿Qué puedes hacer para elegir tu CMS?
Averigüe cuál es la motivación de TI. Según su pregunta, probablemente sea lo mismo que TI en mi empresa. Pagamos mucho por Sharepoint, así que mejor lo usamos para todo. Su primera acción es presentarle a TI los costos adicionales que supondrá hacer las cosas en Sharepoint frente al código abierto. Sea brutalmente unilateral porque es probable que esté subestimando (la mayoría de los costos están asociados con el código alrededor de UX, no con las cosas básicas de Sharepoint). Como TI si están dispuestos a pagar la factura de los costos adicionales. Tienen que entender que Sharepoint es un costo irrecuperable. Úselo donde tenga sentido y deje que cada decisión sea propia.
Asuste a la mierda de la alta dirección en las demostraciones. Muy serio aquí. Hablé por teléfono con el proveedor y nos mostraron su creador de PDF. Le permiten combinar varias páginas de contenido diverso en un PDF para usar en oportunidades de ventas. Bueno, se veía increíble en las demostraciones y la alta gerencia estaba entusiasmada. Luego vi que todo menos el texto estaba usando HTML personalizado. Entonces, el vendedor que combinaba documentos tenía que ser un desarrollador web. Le pregunté a la alta gerencia cuántos empleados de ventas eran desarrolladores web. Dijeron que ninguno. Dije bien esperar agregar 6-8 desarrolladores web en el personal y esperar un gran retraso antes de que los documentos solicitados estén disponibles de esta manera bonita.
Para profundizar en el último punto. Coloque cada tema sobre la mesa. Sé brutal. Considere que cualquier cosa que no le hayan explicado está funcionando de la peor manera posible hasta que sea examinada. Pero ten cuidado. Si te gusta una solución, susurra sus problemas. Los presentas, pero no son tan importantes. Este es el poder que tienes como desarrollador.
Tienes que darles la experiencia de usuario. Las marcas de verificación solo importan si se ve bien y es fácil de usar. No sabe cuántas veces he visto a un proveedor mostrar algo realmente genial y la gerencia dijo: "Uh, qué demonios estaban tratando de mostrarnos" después de la llamada. Porque el proveedor no tenía css/graphics en torno a la nueva tecnología.
Comparte tu opinión abiertamente. No tienes que ser malo con algo, pero al menos di lo que quieras a todo el grupo. Primero, otros pueden estar pensando como usted y están esperando que alguien más lo mencione. En segundo lugar, si eres de confianza, la gente puede pensar que necesitan dar un paso atrás y considerar más lo que quieres.
Al final, tienes que mostrarle a la gente cómo funcionarán las cosas. Hice algo hace un par de años que pensé que nunca haría: convertirme principalmente en Wordpress. Perdí demasiadas batallas usando lo que creo que son modelos de CMS superiores porque carecían de experiencia de usuario. Wordpress tiene que ver con la experiencia del usuario y realmente no hace mucho más que categorías o taxonomías listas para usar. Así que tengo que pasar mucho tiempo agregando cosas para que no se convierta en un CMS de Algernon (las cosas se archivan a intervalos y nuestros editores reciben muchos correos electrónicos diciéndoles que hagan cosas, y si no lo hacen... archivado). ¿Es más fácil para mí convertirme en una tienda de Wordpress para los CMS pequeños/medianos que hago? Sí, porque no puedo codificar 30 "complementos" cada vez, pero puedo encontrarlos gratis en la comunidad de WP o comprarlos por $10.
¿Te estoy diciendo que hagas Wordpress o Sharepoint? No. Te digo que el usuario final quiere algo que le guste usar. CUALQUIERA puede dar una demostración para mostrar lo fácil que es encontrar algo. Casi NADIE entenderá qué algoritmo de búsqueda está usando alguien en segundo plano ni le importará.
Usted se comunica con los marcadores de casilla de verificación llamando a las cosas que no funcionan y mostrándoles funcionalmente cómo funcionaría algo en su alternativa. Si solo está gritando promesas, es mejor que confíe en usted o nunca funcionará.
Miguel
Juan76
BeboyConozcoCosas
Miguel