No creo que sea útil especular sobre las motivaciones de las personas que no están adoptando algo que usted considera una buena práctica o que continúan haciendo algo que consideran una mala práctica. En este negocio, las personas que caen en una o ambas de esas categorías lejos superarán en número a las personas a las que verás cara a cara, así que deja de volverte loco.
En su lugar, enfócate en el problema y las posibles soluciones.
1. Escribe buena documentación tú mismo
Puede que no sea realista esperar que todos los miembros de su equipo dirijan sus esfuerzos a las cosas que ven como un problema. Esto es especialmente cierto si eres un recién llegado al equipo. Me atrevería a adivinar que lo eres, porque si fueras un miembro fundador del equipo, parece muy probable que ya hayas resuelto este problema desde el principio.
Considere, en cambio, trabajar hacia el objetivo de escribir una buena documentación y hacer que la gente la use. Por ejemplo, si alguien en mi equipo me pregunta dónde está el código fuente del Proyecto A o qué configuración especial necesita el Proyecto A, les dirijo a la página wiki del Proyecto A.
Si alguien me pregunta cómo escribir una nueva implementación de Factory F para personalizar algo para el Cliente C, les digo que está en la página 10 de la guía para desarrolladores.
La mayoría de los desarrolladores odian hacer preguntas que puedan hacer que parezcan que no pueden simplemente "leer el código", incluso más de lo que odian leer la documentación, por lo que, después de suficientes respuestas de esta naturaleza, acudirán primero a la documentación.
2. Demuestre el valor de su documentación
Asegúrese de aprovechar cada oportunidad para señalar dónde la documentación está demostrando su valor (o la tendría, si se usara). Trate de ser sutil y evite "Te lo dije", pero es perfectamente legítimo decir cosas como
Para futuras referencias, la página wiki de este proyecto contiene información sobre la rama del código central que se creó para el soporte continuo de la versión 2.1, por lo que en el futuro podemos evitar tener que realizar una prueba de regresión completa si las personas que mantienen Las versiones publicadas revisan el wiki antes de revisar el código.
o
Estoy muy contento de haber anotado los pasos para realizar la Tarea T. Realmente no me importa si nadie más lo usa, ya me ha ahorrado más tiempo del que dediqué a escribirlo.
3. Obtener la gestión a bordo
Después de algunos incidentes en los que tener documentación puede ahorrar tiempo / dinero, es probable que note un "deshielo" distintivo hacia la documentación. Este es el momento de presionar el punto al comenzar a incluir el tiempo de documentación en sus estimaciones (aunque, honestamente, generalmente actualizo / creo documentos mientras se ejecutan procesos largos, como compilaciones o registros). Especialmente si se trata de una contratación reciente, es posible que esto no se cuestione, sino que se vea como una nueva práctica que está adquiriendo desde un lugar de trabajo anterior (lo que podría ser).
Advertencia: a la mayoría de los jefes no les gusta obligar a las personas a hacer nada, especialmente las cosas que no están directamente vinculadas a una tarea facturable, así que no espere que este apoyo esté en la Forma de un mandato. En su lugar, es más probable que le dé bastante libertad para escribir más documentos.
4. Fomenta la documentación cuando la veas
Quizás parte de la razón por la que las personas no escriben documentos tan a menudo como deberían es porque sienten que nadie lo está leyendo. Entonces, cuando veas algo que te guste, asegúrate de al menos mencionar que te alegraste de que estuviera disponible.
Si su equipo realiza revisiones de código, este es un momento en el que puede colocar una o dos palabras sutiles para alentar los buenos comentarios.
Gracias por documentar la solución para el error B en el Marco G. No lo sabía, y creo que no podría haber entendido lo que estaba haciendo sin eso allí.
Si tiene a alguien en el equipo que está realmente entusiasta por la documentación, no está mal cultivar a esa persona a través del almuerzo o el café y asegurarse de ofrecer una pequeña validación para contrarrestar el desaliento. pueden obtener al ver que el resto del equipo no valora tanto la documentación.
Más allá de eso, realmente no es su problema a menos que esté en una posición de liderazgo o gerencia. Puedes llevar un caballo al agua, pero no puedes hacer que beba. Si no es su caballo, es posible que no esté contento de que tenga sed, pero todo lo que puede hacer es llenar el comedero.