En el trabajo hay una forma de pedir cosas que parece inofensiva y es bastante peligrosa.
Mándame cada mes algo con información más o menos así
Esa.
A primera vista parece una petición normal.
Hay un ejemplo del mes pasado. Hay datos anteriores. Se intuye más o menos el formato.
Así que quien hace el trabajo se adapta a esa "idea general" y lo procesa cada mes.
Pero ese "más o menos así" suele traer problemas después.
¿Y este campo? ¿No lo has puesto?
¿De verdad está bien enviarlo ahora?
Pues fulano decía que era distinto, ¿no?
Antes estaba, ¿no?
Y entonces, desde el lado de quien hace el trabajo, uno piensa:
¿Y yo qué sé?
Defínanme desde el principio los campos, la fecha de corte y la fecha de entrega.
Esto no es solo una queja.
Es un problema estructural que se repite una y otra vez en las tareas rutinarias.
"Más o menos así" no es una especificación
"Mándalo cada mes más o menos así" no es una especificación.
Es un ejemplo.
Una sensación.
Lo que se venía haciendo.
Un funcionamiento provisional.
Si de verdad se quiere tratar como especificación, hay que definir al menos lo siguiente:
- Los campos obligatorios
- Los campos opcionales
- Los datos de origen que se consultan
- De qué día deben ser los datos
- Qué día se entrega
- Quién decide cuando hay cambios
- La regla para incorporar peticiones adicionales de otros departamentos
Si nada de esto está definido, quien hace el trabajo solo puede basarse en ejemplos anteriores y hacerlo "a ojo".
Y si después le dicen:
¿Esto no lo has puesto?
no tiene por qué ser un error suyo.
Simplemente no había especificación.
Si durante tres meses nadie dijo nada, esa forma de trabajar quedó aceptada de hecho
Lo importante aquí es el caso en que el proceso lleva meses funcionando así.
Por ejemplo: desde que te encargaste del trabajo, durante tres meses entregaste la lista de empleados a principios de cada mes.
En todo ese tiempo, nadie te dijo "la fecha de entrega no es esa", "falta este campo" ni "esta fecha de corte no nos sirve".
Y de pronto, más tarde, alguien dice:
Lo vamos a usar para la edición del día 16; ¿de verdad está bien enviarlo ahora, el día 1?
Eso no se puede calificar sin más como un error pasado.
Porque durante tres meses se recibió así.
Claro que por el camino puede cambiar el uso que hace otro departamento, descubrirse que hace falta el cargo, o querer replantear el momento de emisión.
Eso no tiene nada de malo.
Pero eso es "ha surgido un requisito nuevo".
No es "la persona anterior lo hizo mal".
Si lo recibiste durante tres meses sin decir nada, esa forma de trabajar fue, como mínimo, tolerada en la práctica.
Si luego quieres cambiar los campos necesarios o la fecha de entrega, lo que toca no es culpar a nadie, sino actualizar la especificación.
El problema no es "no haber puesto el cargo"
Imagina un trabajo como la lista mensual de empleados.
Otro departamento comenta:
Quizá sin el cargo no se entienda bien
Entonces el jefe o el responsable le pregunta a quien lo hace:
¿No has puesto el cargo?
Ya en este punto la conversación se ha desviado un poco.
El problema no es que no se haya puesto el cargo.
El problema es que nadie había definido el cargo como campo obligatorio.
Así que la conversación correcta sería esta:
Ah, entiendo, a partir de ahora también hace falta el cargo.
Entonces lo añado como campo desde la próxima vez.
Y ya está.
Se descubrió que hacía falta un campo sin definir.
Pues se añade a la especificación de ahora en adelante.
Eso es todo.
No conviertas una petición adicional en un "juego de encontrar el error"
En el trabajo, a veces uno se da cuenta más tarde de que falta un campo.
Eso no tiene nada de malo.
Es muy normal que otro departamento, al usarlo, se dé cuenta de que:
Con el cargo se entendería mejor
Sin la fecha de corte cuesta verificarlo
También ayudaría tener este campo
Por eso, la respuesta correcta es sencilla:
Lo añadimos desde la próxima vez
Si lo necesitan también para este mes, envío una versión corregida
A partir de ahora este campo será estándar
Con eso basta.
Pero en los lugares de trabajo que resuelven mal los problemas, esto se convierte, no se sabe por qué, en un "juego de encontrar el error".
¿Por qué no está?
Hasta ahora estaba
¿Quién dijo que era distinto?
¿Se puede decir que es distinto de lo que se dijo antes?
¿Quieres decir que quien lo señaló estaba equivocado?
No.
El tema es otro.
Si hay una petición nueva, se añade a la especificación.
Si se detecta una carencia, se estandariza desde la próxima vez.
Si la fecha de corte es ambigua, se define.
Eso es todo.
No hace falta decir que "quien lo señaló estaba equivocado".
No hace falta decir que "quien hizo el trabajo cometió un error".
No hace falta decir que "la persona anterior lo hizo mal".
Lo único necesario es decidir cómo se funcionará de ahora en adelante.
Si no está decidido, simplemente se decide
Lo más importante en estos casos es esto:
Si no está decidido, simplemente se decide.
No está decidido si se incluye el cargo.
Pues se decide si se incluye.
No está decidido si se envía con los datos del día 1 o con los de justo antes de la emisión del día 16.
Pues se decide la fecha de corte.
No está decidido qué día de cada mes se entrega.
Pues se decide la fecha de entrega.
No está decidido cómo tratar las peticiones adicionales de otros departamentos.
Pues se decide la regla para incorporarlas.
Eso es todo.
Y si se convierte en
quién lo dijo
si es distinto de lo que se dijo antes
si esto es un error
por qué no se incluyó
a quién le falló la comprensión
se vuelve de golpe una reunión inútil.
Eso no es resolver un problema.
Es dejar lo no definido tal cual y buscar solo dónde colgar la responsabilidad.
Si vas a revolver documentos antiguos, decide antes para qué
En estas situaciones hay quien empieza a revolver documentos antiguos.
¿Cómo eran las listas anteriores?
¿Antes incluían el cargo?
¿Desde cuándo falta?
¿Con quién empezó a cambiar?
Por supuesto, mirar documentos antiguos no es malo en sí mismo.
Tiene sentido si el objetivo es
decidir los campos estándar a partir de ahora,
entender qué ha cambiado respecto al pasado,
o comprobar qué miraban los otros departamentos.
Pero si el objetivo pasa a ser
quién lo omitió,
quién se equivocó,
si quien lo señaló tiene razón,
si quien hizo el trabajo cometió un error,
entonces casi no sirve de nada.
Eso no es mejorar el trabajo, es minar responsables.
Por mucho que revuelvas el pasado, no vas a decidir si la lista de este mes necesita el cargo.
Por mucho que revuelvas el pasado, no vas a decidir si la fecha de corte es el 1 o el 16.
Por mucho que revuelvas el pasado, la regla de la fecha de entrega no va a aparecer sola.
Revisar el pasado es útil si se usa como material para definir la especificación.
Si se usa para buscar al culpable, es una pérdida de tiempo.
Si no se separan las dos cosas, las tareas rutinarias seguirán siendo estériles para siempre.
Si lo conviertes en un "juicio de quién tiene la culpa", el trabajo se paraliza
En este tipo de lugares de trabajo, en cuanto surge un problema empieza el juicio.
¿Quién dijo eso?
¿Qué hacía la persona anterior?
¿Se equivocó quien lo señaló?
¿Falló quien hizo el trabajo al no comprobarlo?
¿Quién tiene razón?
Por supuesto, si se trata de un accidente grave o de una infracción legal, hay que investigar la causa.
Pero en una tarea rutinaria como los campos de la lista mensual, donde simplemente ha aparecido un campo adicional, no hace falta tanto juicio.
Lo único que hace falta es esta frase:
Entonces, a partir de ahora, el cargo será un campo estándar.
Con eso basta.
Si hace falta, se puede añadir:
¿La fecha de corte puede ser el día 1 de cada mes?
Para la edición del día 16, ¿hasta qué día de cada mes se entrega?
Eso es trabajar.
Decidir "qué hacemos a partir de ahora" es 100 veces más rápido que buscar "quién tiene la culpa".
Los requisitos "de sensación" generan evaluaciones a posteriori
Lo que da miedo de la petición "más o menos así" es que permite puntuar después.
Al principio no hay una tabla clara de campos.
No hay fecha de corte.
La fecha de entrega es ambigua.
Los datos de origen cambian.
Pero el resultado sí se entrega todos los meses.
Entonces, quien lo revisa después puede decir:
Falta este campo
Es distinto de antes
¿De verdad se puede enviar ahora?
Otra persona decía que era distinto
Pero eso es puntuar solo el resultado, sin mirar la ambigüedad que había en el momento de la petición.
Si desde el principio se hubiera acordado algo como:
La lista de empleados tendrá como campos obligatorios nombre, departamento, cargo y fecha de incorporación
La fecha de corte de los datos será el día 1 de cada mes
La fecha de entrega será hasta el día 10 de cada mes
Se reflejará en la edición del día 16
todo sería sencillo.
Si algo se saliera de esa especificación, sí se podría hablar de error de trabajo.
Pero si al principio solo se dijo "más o menos así", tratar algo como obligatorio a posteriori es peligroso.
Eso no es incumplir la especificación, es que la especificación no estaba definida.
Si los datos de origen cambian, sin fecha de corte los resultados varían
En tareas como una lista de empleados, los datos de origen cambian.
Cambian los cargos.
Cambian los departamentos.
Hay altas y bajas.
Cambian nombres y grafías.
La información varía según el momento de la emisión.
Por eso es tan importante saber "con la información de qué día se entrega".
¿Con los datos del día 1?
¿Con los datos de justo antes de la emisión del día 16?
¿Con los datos del momento en que llegó la petición?
¿Cuando ya estén reflejados los nombramientos de personal?
Si esto no se decide y luego preguntan
¿De verdad está bien enviarlo ahora, el día 1?
quien hace el trabajo no sabe qué hacer.
Eso no es un problema de criterio de quien lo hace.
Es que no se ha definido la fecha de corte.
Un trabajo sin fecha de corte varía cada vez.
En lugar de enfadarse después de que varíe, basta con definir antes la fecha de corte.
Para mejorar, fija los campos, la fecha de corte y la fecha de entrega
Para estabilizar este tipo de trabajo no hacen falta grandes reformas.
Con decidir estas tres cosas todo se vuelve mucho más fácil.
1. Campos
Por ejemplo:
- Nombre
- Departamento
- Cargo
- Número de empleado
- Fecha de incorporación
- Observaciones, si hacen falta
Qué es obligatorio.
Qué es opcional.
Qué campos necesitan los otros departamentos para usarlo.
Eso es lo que hay que decidir.
2. Fecha de corte
Por ejemplo:
- Datos del día 1 de cada mes
- Datos del día 15 de cada mes
- Datos del día hábil anterior a la emisión
- Datos tras reflejar los nombramientos de personal
Si los datos de origen cambian, sin fecha de corte siempre habrá desajustes.
3. Fecha de entrega
Por ejemplo:
- Entrega hasta el día 10 de cada mes
- Como se usa para la edición del día 16, cierre el día X de cada mes
- Si es festivo, el día hábil anterior
Si la fecha de entrega es ambigua, el problema del "¿se puede enviar ahora?" surge cada vez.
Es decir, lo que hace falta no es echarle ganas.
Es una especificación.
Respuestas que sirven en el trabajo real
Cuando llega una petición de añadir un campo
Entiendo, a partir de ahora también hace falta el cargo.
Entonces lo añado como campo desde la próxima vez.
Si también lo necesitan para este mes, lo rehago incluyendo el cargo.
Cuando durante tres meses se trabajó igual y nadie dijo nada
Durante estos tres meses hemos trabajado entregándolo a principios de mes y no ha habido ninguna observación.
Si a partir de ahora se quiere cambiar la fecha de corte o el momento de entrega para la edición del día 16, propongo que se fije como estándar desde la próxima vez.
Cuando los campos obligatorios no estaban claros
Hasta ahora no se había indicado ningún campo obligatorio concreto, así que lo hacía tomando el ejemplo como base.
A partir de ahora lo haré incluyendo el cargo.
Cuando te preguntan por el momento de emisión
Para la edición del día 16, creo que habría menos malentendidos si decidimos con los datos de qué día se hace.
Me gustaría confirmar si basta con los datos del día 1 de cada mes o si deben ser los de justo antes de la emisión.
Cuando la conversación amenaza con derivar en quién se equivocó
Más que un error de alguien, entiendo que hasta ahora los campos y la fecha de corte no estaban claramente definidos.
Propongo decidir si el cargo se incluye como estándar de aquí en adelante.
La clave de estas respuestas es no entrar en la búsqueda de culpables.
Se vuelve de "quién tiene la culpa" a "qué hacemos a partir de ahora".
Conclusión: si pides las cosas "de sensación", no evalúes después
"Mándalo cada mes más o menos así" es una frase muy cómoda.
Pero si se funciona así sin más, es fácil acabar discutiendo.
Los campos no están decididos.
La fecha de corte no está decidida.
La fecha de entrega no está decidida.
Los datos de origen cambian.
Las peticiones de otros departamentos también cambian.
Y aun así, puede que se acepte sin decir nada durante tres meses.
En ese estado, es peligroso culpar después con un "¿esto no lo has puesto?".
Si aparece un campo necesario, se añade.
Si la fecha de corte es ambigua, se define.
Si la fecha de entrega es ambigua, se fija.
Eso es todo.
Cuando encuentres algo sin definir, no busques a un responsable: define la especificación.
Eso es el trabajo.
Algo que debería acabar con
Ha surgido una petición adicional
Pues lo incluyo
no lo conviertas en
¿Quién tiene la culpa?
¿Es un error?
¿Es distinto de lo que se dijo antes?
¿Dices que quien lo señaló estaba equivocado?
Eso no es trabajo, es un juicio de pacotilla.
Lo que necesita una tarea rutinaria no es imponer a base de gritos ni minar responsables.
Es dejar por escrito los campos, la fecha de corte y la fecha de entrega.
