En este momento estoy trabajando en una empresa multinacional, básicamente la sede de la empresa está ubicada en Japón para las ventas y la sucursal está ubicada en el sudeste asiático para el desarrollo. En este momento actúo como gerente intermedio para convertirme en un puente entre el equipo de ventas y el equipo de desarrolladores. Para hacer bien mi trabajo, debo mantenerme lo más neutral posible.
Pero como esperaba, siempre habrá una queja de la sucursal, y tengo que manejar todas las quejas y tengo que encontrar una solución ya sea de su sugerencia o del personal de la sede. Pero recientemente, el número de quejas está aumentando porque creo que el nivel de confianza entre la oficina principal y la sucursal está disminuyendo, y recientemente se han vuelto más sensibles y se quejan de cosas pequeñas.
Mi pregunta es ¿cómo manejan normalmente las quejas y sugerencias? simplemente tomarlos todos claramente e informar a la parte superior para la solución? o tratar de filtrarlo? o tratar de responder por sí mismo si cree que sabe la solución?
¡Gracias!
Muy pocos empleadores entienden realmente cuánto tiempo lleva o qué implica hacer que el software funcione. Estamos viendo una situación particularmente pública y vergonzosa con 'healthcare.gov' y las personas que legislaron el proyecto: este cronograma fue impulsado por los plazos de las elecciones, no por los administradores del proyecto. Por lo tanto, uno puede ver la letanía habitual de quejas de los desarrolladores: especificaciones vagas, recursos insuficientes, objetivos que cambian continuamente, presión para sacar cosas, etc., etc. los 'extranjeros', esto puede convertirse en un grave caos. Lo mejor que se puede hacer es hacer que las personas mayores visiten el lugar en un horario regular y hablen directamente con las personas que realizan el trabajo. Si 'no pueden permitírselo', entonces pueden'
Una buena manera de entender esto es 'suponga que ha contratado a un contratista para remodelar su cocina'. Su suposición inicial es que tomará dos semanas rehacer la cocina. Ha seleccionado el fregadero, la encimera y los gabinetes nuevos, por lo que esto es directo hacia afuera, hacia adentro, ¿verdad?
En cualquier caso, todo se saca y luego uno descubre que la plomería y el cableado deben cambiarse. Luego resulta que el color del piso y los gabinetes no tiene sentido. Entonces el frigorífico sobresale demasiado y el fregadero no está centrado con respecto a la ventana. En resumen, el propietario está cambiando los requisitos a mitad de camino. El proyecto se infla a 6 semanas.
El propietario nunca antes había remodelado una cocina y contrató al postor más bajo. Ahora hay una pelea. Alguien tiene que explicarle al dueño de casa que cambiar las especificaciones cambia los costos y que ciertos elementos de esto fueron imprevistos. Si el dueño de la casa no está escuchando y no le importa, entonces el contratista renuncia, dejando al dueño de la casa en la estacada. Los proyectos de software terminan en situaciones como esta todo el tiempo.
Por lo tanto, uno tiene que tratar con relativa firmeza a las personas que hacen los planes y pagan las cuentas. Lo primero que debe hacer es establecer ciclos de 'entregables' muy cortos para que se pueda demostrar algún progreso cada semana o dos. El siguiente es abandonar cualquier idea de que hay un tiempo fijo y un presupuesto fijo: los planificadores deben determinar en qué punto el proyecto ya no puede pagar su camino y desconectarlo en ese punto. Si la oferta es de $ 1 millón y la oportunidad es de $ 10 millones, el cliente debe estar preparado para gastar $ 2 a $ 3 millones si aún puede recuperar los $ 10 millones.
Se debe hacer un comentario sobre la oficina central: muy pocos empleadores tienen éxito en la gestión de proyectos de software, pero aquellos que lo tienen ganan mucho dinero (inserte aquí los nombres de las grandes empresas de Silicon Valley). Por lo tanto, realmente vale la pena seguir intentándolo hasta que entiendan cómo se hace. Lo último que pueden permitirse es exigir que los presupuestos y el cronograma permanezcan constantes si los objetivos son fluidos.
Es parte de la definición de mi trabajo, por lo que lo que solemos hacer es enviarlos a la otra parte con comentarios sobre cómo creemos que podría/debería solucionarse. Pero, por supuesto, en última instancia, depende del destinatario decidir, ya que estamos justo en el medio.
¿Pero parece que esperan que resuelvas los problemas? En ese caso, haga lo mismo, pero participe más activamente en la gestión de incidentes colaborando con la otra parte. Si usted es la parte responsable, debe seguir hasta el final. En otros casos, haz lo mejor que puedas, especialmente cuando estés bajo cargas pesadas.
Tal vez podría tener reuniones semanales/mensuales con los representantes de ambos equipos, revisar los problemas recientes y trabajar en una solución que funcione para ambas partes.
Niko Adrianus Yuwono