sharepoint - tipos - Cómo lidiar con el miedo al desarrollo personalizado
fobias (12)
¿Alguien en la administración posee acciones en SharePoint? ¿Fue el sistema desarrollado por el hermano menor del CEO?
Si son tan flexibles para cambiar, debes descubrir la verdadera razón antes de intentar discutir con ellos. Pueden afirmar que hay complejidad añadida, pruebas de dificultad, etc., pero si puede contrarrestar cada argumento con uno que muestre su posición, con el debido respeto, para estar mal informado, y ellos todavía no lo discutirán, entonces usted puede estar discutiendo el punto equivocado
Si están encerrados en la tecnología por una razón no técnica, como alguien que una vez leyó que SharePoint es lo último en cualquier situación técnica (y, por supuesto, no tenía idea de qué estaba hablando el artículo aparte de SharePoint = bueno) entonces no deberías molestarte en intentar discutir y ahorrar tu energía. Para la búsqueda de trabajo.
Estoy lidiando con un problema con mi empleador actual que me ha llevado seriamente a buscar empleo en otro lado. Tienen la impresión de que el 100% del desarrollo personalizado debe eliminarse y reemplazarse con productos COTS, como SharePoint. Si bien me doy cuenta de que esta no es una expectativa realista, me resulta imposible discutir mis puntos con las personas en la gestión que comparten estos puntos de vista. Su argumento usualmente involucra algo similar a una característica ya existente en SharePoint que cubre la característica X, por lo tanto, hay menos riesgo involucrado y no es necesario realizar pruebas en su contra.
Por ejemplo, tenemos una situación en la que una lista de SharePoint es completamente incapaz de cumplir con las expectativas y requisitos del cliente. Sin embargo, guardar estos datos en una base de datos SQL satisfaría fácilmente los requisitos. Sin embargo, cada vez que nuestro equipo de desarrollo sugiere ir más allá de los límites de SharePoint, la administración se incendia sobre cómo cada línea de código aumenta la complejidad del proyecto y aumenta el riesgo. Si bien esto es cierto en algunas situaciones, no siempre es así. Su argumento, sin embargo, es que dado que SharePoint proporciona un mecanismo para almacenar datos, debemos usarlo el 100% del tiempo. Independientemente de si cumple con los requisitos del cliente, o no.
He llegado al punto en que odio ir a trabajar porque constantemente me veo obligado a hacer cosas que sé (con un 100% de certeza) que no son correctas y que podrían solucionarse haciendo un desarrollo personalizado. Sin embargo, es simplemente lo que parece ser un argumento imposible en el que trabajo.
¿Alguno de ustedes ha experimentado una situación similar? Si es así, ¿qué has hecho para superar estos desafíos?
Definitivamente tendré mi currículum fuera y abierto si fuera usted. No solo la experiencia que estás experimentando actualmente es frustrante, realmente puede dañar el desarrollo de tu carrera a largo plazo. Solo piensa en ello. Mientras está languideciendo con su empleador actual en su posición actual, otros desarrolladores están adoptando nuevas tecnologías y expandiendo su experiencia.
Existe una diferencia ideológica entre los desarrolladores y la idea que tiene una empresa de un rol para un desarrollador. Si la discusión abierta y la franqueza no le llevan a ninguna parte, no se le culpará por la falta de esfuerzo. La lealtad a una empresa es algo bueno, pero la relación debe ser una calle de doble sentido.
Tristemente, eventualmente la voluntad se dará cuenta de que están equivocados en sus suposiciones, pero no puede esperar a que llegue ese día. A veces nunca llega. En particular (y no me malinterpreten, me encanta SharePoint cuando se usa para lo que está destinado), SharePoint se convierte en el próximo Access, en el sentido de que las personas que leen revistas de gestión ven suficiente como para llamarlo el Mesías.
Esto puede sonar mal y puede no ser la respuesta que desea. Hay una pequeña división conocida en mi oficina llamada "The Skunk Works". Las personas, por su propia cuenta (por lo general, durante el almuerzo o el tiempo de compilación) deciden escribir pequeños programas que ayudan a la empresa. Lo divertido de esto es que el resultado no "cuesta" nada a la empresa.
La conversación generalmente es así:
"Necesitamos comprar este software" -Boss
"Pero, hemos tenido esa cosa durante meses. John, escribió eso en el día" -Programador
"¿?" -Jefe
Muchas veces los desarrolladores ven una decisión como mala y solo crean un proceso paralelo que ocurre automáticamente. Entonces, cuando la cosa golpea al ventilador y los clientes se sienten frustrados, la solución alternativa YA está en su lugar.
Tengo un ejemplo de una máquina de liberación automática. Los desarrolladores solían crear estos informes personalizados. A medida que nuestros clientes aumentaron, la carga de trabajo del desarrollador aumentó. El problema era "Para que el cliente obtenga el desarrollador del informe personalizado, debe participar". Entonces, mientras la compañía buscaba contratar a alguien para hacer informes a tiempo completo o para encontrar maneras de hacer que los clientes los hicieran, escribí una máquina de liberación automática que busca cambios en los informes y los lanza directamente al cliente. También escribí una utilidad que permite a cualquier persona hacer cambios en los informes que es más fácil de usar que lo que tiene el desarrollador. Cuando el Jefe hizo el anuncio de tratar de encontrar una solución, le dije que ya estaba en su lugar y que incluso él podía hacer cambios en los informes y hacerlos llegar. Ahora, todo el mundo puede cambiar los informes, generalmente es la administración y el soporte al cliente los que hacen estos cambios. El lado divertido es que los desarrolladores ya no están involucrados.
Solo hazlo. Si va a dejar de todos modos, podría intentarlo.
Estoy haciendo lo mismo en mi trabajo actual, no hay una manera fácil de lidiar con este tipo de situación. Todo lo que he podido hacer es tragar mis argumentos, porque no me han llevado a ninguna parte y hacer lo que exige mi gestión. Este curso irá en contra de la naturaleza básica del programador de utilizar la mejor solución para la tarea en cuestión, y tal vez consiga construir algo interesante en el proceso, pero dado que son el jefe, es realmente su única solución. Podría tratar de ubicar casos, con evidencia, donde tenga más sentido usar soluciones personalizadas. Pero si tu jefe es como el mío, no llegará muy lejos antes de que comience el griterío. La única otra solución es desempolvar ese currículum y encontrar un nuevo trabajo.
He enfrentado el mismo tipo de desafíos desde el primer día. La gerencia tiene una reticencia natural a agregar código personalizado a la solución. Sin embargo, en la mayoría de los casos, ha sido posible explicar que la solución adecuada para el cliente incluiría algún código personalizado.
Recuerde, si argumenta que puede incluir el código personalizado en la base de código común, entonces el jefe podría aprobar la idea.
He trabajado en un lugar donde la dirección no fue constructiva en su enfoque, no es tan mala como usted describe, pero ya es suficientemente malo.
Hay un par de opciones. Una es seguir adelante y hacer lo que debe hacerse para el cliente con la mejor opción de "valor por dinero" que pueda. Probablemente tendrás que reunir a los desarrolladores como equipo para que funcione esta "desobediencia civil".
Un enfoque más contundente que realmente hará que la mierda le pegue al ventilador es ir al cliente (no haga esto si es un cliente externo o si desea conservar su trabajo) y planee qué sucederá con esto. proyecto si X e Y. Esto es más o menos contar cuentos fuera de la escuela y va a ser malo, pero entretenido.
Una forma un poco mejor es ir por la cadena y conseguir un patrocinador que pueda hacer que te suceda. Esencialmente vaya detrás de su (s) jefe (s). Esto puede funcionar, pero va a tener resultados predecibles para su relación con su administración.
Lo último y más difícil es identificar a la persona que sostiene que cualquier código personalizado es malo e involucrarlos en una conversación para descubrir dónde obtuvieron la creencia y contrarrestarla con ejemplos. Énfasis en la conversación, ya que tendrá que escuchar y comprender sus preocupaciones subyacentes (que no será sobre el código personalizado per se) y solo abordarlas una vez que obtenga la confianza de esa persona.
No puedo decirte qué forma de hacer las cosas va a funcionar mejor porque depende mucho de las personas involucradas. Todo lo que sé es que no se puede cambiar a las personas y, en mi experiencia, la mejor manera de resolver el problema hasta ahora ha sido irse y trabajar con personas que no lo son ...
Realmente siento tu dolor
Si fuera yo, utilizaría mi tiempo libre para recopilar información que pruebe mi punto y lo documente de una manera fácil de entender.
Si solo entienden el dinero, hablan sobre el dinero, si solo entienden el miedo (haciendo "esto" porque tienen miedo de "eso"), utilizan el miedo, encontrando algo de miedo para ellos en "su" solución.
Documente cada nueva implementación, el tiempo, el dinero y el problema que surja. Y documente cuál sería su solución en su lugar.
Probablemente no vean el problema en su solución, porque se enfocan en no tener problemas en "su" solución.
Si no comparte la visión de la empresa y si no puede iluminarlos, entonces seguro que es un buen momento para empezar a buscar.
¿Ha señalado que existe el riesgo de forzar una "solución" en un cliente que no los ayuda o le falta funcionalidad o es inutilizable?
Tal vez proponer planes para abordar y mitigar sus riesgos percibidos.
Usted documenta sus inquietudes y deja que quienes están arriba las conozcan, y luego hace lo que le piden. Si no funciona, tiene documentación de que presentó las inquietudes. Pero trate de hacerlo funcionar a su manera, para que no parezca que está tratando de socavar sus planes. Están asumiendo el mayor riesgo, y así obtienen una mayor responsabilidad. Haz tu mejor esfuerzo para que funcione a su manera y deja de preocuparte por ello.
Encuentro que típicamente no hay forma de ''ganar'' estos debates solo a través de la conversación. Muchos gerentes forman una opinión de un producto o solución a través de artículos orientados a la gestión de la lectura. Vea si puede encontrar algunos artículos contrarios.
Si puede citar ejemplos de cosas que SharePoint es incapaz de hacer, y mostrar ejemplos de cómo puede resolver estos problemas de forma rentable a través del desarrollo personalizado, entonces está en buen camino.
El error es tratar de hacer de esto una conversación sobre tecnología, no lo es, es sobre eficiencia, rentabilidad y capacidad de mantenimiento: esos son los mantras y las métricas que influirán en los gerentes no técnicos para que consideren alternativas.
Si puede armar una prueba de concepto para algunos de estos problemas tanto mejor, el caramelo de ojos realmente ayuda a vender fuera de los equipos técnicos.
Finalmente, buena suerte :)
¿Qué tal si no lo llamamos código personalizado? Si, en cambio, lo llamas ''extensiones de usuario de SharePoint anticipadas'' o algo así, puede suavizar el concepto erróneo que rodea un término específico.
también, como se ha dicho, puede haber otras razones ocultas para usted de que la administración está impulsando esta agenda. Probablemente sea mejor no adivinar esto demasiado rápido, ya que muchos serían válidos.
Finalmente, hay muchos lugares que necesitan desarrollo. no duele buscar una mejor combinación.
buena suerte.
Pruébalo a ellos. Cuando los requisitos solicitan una lista que puede manejar 100.000 elementos con un ordenamiento de varias columnas: escriba un script que agregue 100.000 elementos de prueba en una lista de sharepoints y permita que lo intenten, preferiblemente con el "cliente" solicitando que los vea la lista. :-)