¿Cómo manejar esta situación desafortunadamente no hipotética con los usuarios finales?

Trabajo en una empresa mediana pero con una fuerza de TI muy pequeña.

El año pasado (2011), escribí una aplicación que es muy popular entre un gran grupo de usuarios finales. Llegamos a una fecha límite a fines del año pasado y alguna funcionalidad (llamaré funcA de ahora en adelante) no se agregó a la aplicación que se quería al final. Por lo tanto, esta aplicación se ha estado ejecutando en vivo / producción desde finales de 2011, podría agregar sin problemas.

Ayer, un grupo completo de usuarios finales comenzó a quejarse de que funcA que nunca estuvo en la aplicación ya no funciona. Nuestra prioridad en esta empresa es que si una aplicación se rompe, debe repararse primero antes de los proyectos priorizados.

He comparado el código y las consultas y no hay diferencia desde 2011, que es prueba A. Luego pude lograr que uno de los usuarios finales admitiera que nunca funcionó la prueba B, pero desde entonces ese usuario final regresó y dijo que estaba funcionando anteriormente ... Creo que la horda de usuarios finales se ha asimilado su. También he revisado mis notas para este proyecto que tiene requisitos y actualizaciones diarias con respecto al proyecto que establece específicamente, "funcA no se logró debido a limitaciones de tiempo", proofC.

He hablado con muchos de ellos y puedo ver dónde podrían confundirse, ya que están muy lejos de un fondo de programación, pero también sé que son lo suficientemente inteligentes como para actuar en un grupo para evitar las órdenes de priorización de proyectos para obtener funcionalidad que desean facilitar su trabajo.

La peor parte es que ahora se está creando el pensamiento grupal y mi jefe y el jefe de TI en realidad están empezando a creerlos, a pesar de que no hay cambios en el código o en las consultas. En cuanto a revisar el estado de la lógica, está muy cortado y seco hasta el punto de si 1 = 1, funcA no funcionará.

Entonces, este es el final de la descripción de mi escenario, pero estoy tratando de no criticar mis métricas de rendimiento debido a esto, lo que esencialmente me habría llevado a solucionar un problema de producción que no existe y que probablemente se hará cargo. 1 mes.

Las disputas sobre hechos fácilmente observables son en realidad bastante fáciles de resolver: solo observe los hechos. Si digo "hay un árbol con madera morada afuera de mi casa", cualquiera que pueda venir a mi casa puede verificar la verdad o la falsedad de mi declaración por sí mismos.

Si se quejan de que FuncA solía estar en el producto y solía funcionar en una versión anterior y ahora no funciona, y no cree que haya estado en el producto, pídales que lo prueben. (O, en palabras más amables, diga algo como "estamos teniendo problemas para reproducir el problema. ¿Podría ayudarnos aquí?")

Entrégueles una copia de la versión anterior si aún no tienen una, y consígalas en LiveMeeting, y pídales que le muestren cómo solían usar FuncA. Si no pueden hacerlo, entonces (con suerte) se dan cuenta de que no estaba allí después de todo y dejan de lado su caso al respecto, o al menos intentan una táctica diferente para implementarlo. (Y asegúrese de que alguien de la gerencia o del primer ministro participe en LiveMeeting).

Este no es un problema que pueda tratarse con hechos: si lo intenta, perderá credibilidad.

Primero, acepte que el software está "roto", ya que no hace lo que los usuarios quieren que haga. Ahora, acepte que los usuarios tienen derecho a que el software haga lo que ellos quieren que haga, eso es, por lo tanto, el software. Entonces, lo que tenemos es un software defectuoso y un ingeniero que se niega a arreglarlo .....

Como resultado, si el sistema que ejecuta para establecer prioridades, estos usuarios no pueden arreglar su software al pasar por los canales normales, por lo que están usando canales laterales y escalando medias verdades más arriba en la cadena alimentaria para intentar maniobrar el sistema, en mientras tanto, hacer que sus KPI se vean mal (su principal preocupación deberían ser los clientes, no sus KPI): sus KPI se consideran "daños colaterales" si les agrada, o un efecto secundario beneficioso si no lo hacen. Sin embargo, tienen cierto control sobre cuánto sucede, lo que más les gusta.

Entonces, lo que está sucediendo es que el sistema está roto y todos están tratando de manipular las cosas para obtener lo que quieren. Quieren una función, y usted quiere mantener sus KPI impecables.

A menos que pueda arreglar el sistema o aprender a jugar a la política de la oficina muy rápido, el juego termina: usted pierde.

Nota: Ninguna de estas discusiones involucra líneas muertas, discusiones de errores versus características, quién paga, etc. Estos son hechos, y los hechos no importan (bueno, de alguna manera sí, pero se pueden manipular de muchas maneras ... ) en la política de la oficina.

Organizacionalmente, siento un problema.

Existe una jerarquía que incluye al jefe de TI y su jefe. Si su organización es tradicional (no parece que sea ágil), usted es un recurso y ellos son administradores de recursos. Tiene un trabajo a tiempo completo llamado desarrollo de software. Si los usuarios finales solicitan funciones directamente, establecen sus prioridades e intentan administrar su tiempo, sus gerentes son redundantes. Pueden ser responsables ante los usuarios finales, pero si están haciendo su trabajo, usted es responsable ante ellos y deben protegerlo para que no salga del modo de desarrollador enfocado al modo de desarrollador defensivo .

Algunos puntos para establecer el contexto de mi respuesta:

• Los desarrolladores de software no son viajeros en el tiempo, por lo que los resultados deben juzgarse por lo que son, no por lo que podrían haber sido.
• Si una característica estaba en una especificación de requisitos, un cronograma y se priorizó por encima del trabajo que se completó, puede haber una queja legítima. De lo contrario, ¿cuál es la justificación para responsabilizarlo?
• Su castigo, si es necesario, debe provenir de su cadena de mando. Del mismo modo que al marketing y las ventas no les gustaría que el desarrollo de productos regañara a los clientes, la mayoría de las organizaciones tienen gerentes de productos para recibir la ira de los clientes (y elogiarlos) y transmitirla a través de los canales.
• Los gerentes de producto pueden crear relaciones extremadamente difíciles si disfrutan del calor de las partes exitosas de los proyectos, pero solo rompen el látigo cuando se enfrentan a los desarrolladores.
• Si entregó un producto funcional con un año de trabajo, y toma un mes (o dos) agregar la característica deseada, por lo que he visto en nuestra industria, su estimación fue superior al promedio.
• Resolver el problema de manera justa y productiva requiere que las personas vuelvan a meter los dedos de la culpa en sus bolsillos y hagan un plan para seguir adelante.

Podrá hacer un trabajo de mucha mejor calidad con una mejor motivación si es apreciado en lugar de ser la cabra en un proceso que el jefe de TI debe poseer. Es el camino justo y el camino productivo. Espero que lo manejen de esa manera, y en algún momento en el futuro, espero que manejen a los demás de esa manera.

En caso de un fracaso de la realidad como este, lo mejor es seguir adelante. En lugar de discutir sobre el pasado, habla sobre cómo hacerlo funcionar y lo fácil o difícil que será. Realmente no importa si el problema lo está solucionando o implementando por primera vez. Si la gerencia quiere que A termine antes que B, hágalo.

¿Eres el único desarrollador que ha trabajado en este proyecto? Parece que le respondiste a alguien al hacer el proyecto. ¿Dónde está esa persona en todo esto? ¿Dónde está la documentación del proyecto que dice lo que se entregó?

Debe haber un rastro de documentos en papel. Un documento de capacitación que muestra cómo usar la aplicación. Una especificación funcional que describe lo que se desarrolló. Si no se incluyó una función, también debería haber documentación al respecto. Alguien debería haber tenido que cerrar la sesión diciendo que acepta eso.

No debería ser tu palabra contra la de ellos, debería estar todo en la documentación.

Si no tiene esta documentación ... me temo que tendrá que morderla. Considéralo una lección de vida. Al final del día, sus usuarios son sus clientes, y como dice el refrán: el cliente siempre tiene la razón. Dibuje cómo agregar esta función y cuánto tiempo llevará. Tenga una reunión y diga algo como 'Nuestros registros muestran que esta característica nunca se implementó, pero podemos lograr que tenga vida en x semanas. ¿Deberíamos ir a la cabeza?

Y por amor a todo lo que es sagrado ... obtenga la documentación que necesita para demostrar que fue aprobado.