La documentación es siempre hijastra del desarrollo. Aunque simplemente podrías ordenarles que lo hagan, hay algunos puntos que debes tener en cuenta cuando quieras motivarlos :

Demostrar el problema

¿Alguna vez han visto el problema? Ahora mismo es un problema abstracto. Piensas que algo podría pasar en el futuro. Tendrá mejores posibilidades si puede proporcionar un ejemplo real.

¿Recuerdas los problemas que tuvimos cuando Steve se fue?.

Pensamiento positivo

Tienes que darle un giro positivo. Si le pides a la gente que documente, porque da beneficios a los que se quedan si la persona se va, podemos estar de acuerdo en que esa es la forma profesional. Pero a nivel personal, a nadie le importa lo que le pase a la empresa después de que se vayan. Así que deberías convertirlo en algo que los beneficie mientras todavía están allí .

Deberíamos documentar más para que Steve pueda tener sus 3 semanas de vacaciones sin que tengamos que llamarlo cada dos días porque no sabemos cómo funciona.

Trate de ponerlo bajo una luz que sea lo mejor para ellos , no solo para las empresas.

Haz que sea más fácil hacer lo correcto

Concédeles el tiempo para hacerlo. Nunca nadie me dijo que no documentara. Pero todos los gerentes de proyectos que tuve siempre querían que terminara en menos tiempo del que hubiera tomado hacerlo correctamente. Y lo único que puedes saltarte sin perder al cliente es la documentación. No espere que las personas hagan el trabajo que odian en sus propias horas extras no pagadas (o incluso pagadas). ¿Quieres que se haga? Planifíquelo y hágalo parte del resultado del proyecto.

Predicar con el ejemplo

¿ Tu trabajo está debidamente documentado? ¿Quién puede hacerse cargo si te atropella un autobús? No puedes esperar que las personas estén motivadas para hacer algo que no les gusta, cuando no lo haces tú mismo. Y no estoy hablando de un plan de proyecto. Ese es su producto, como el código fuente de otras personas. Estoy hablando de lo que te hizo escribir exactamente este plan de proyecto (o backlog). ¿ Por qué lo hiciste? ¿Qué tareas siguen abiertas? Cualquier cosa que lo ayude a reemplazarlo: usted hará un trabajo adecuado cuando le toque la lotería y se vaya a Hawai por el resto de su vida.

Ha identificado un riesgo y una posible solución. Me abstendría de considerar su solución (más documentación) como "la" solución y pedirles que la apliquen de inmediato. Está trabajando con un equipo de expertos, que probablemente tendrán un punto de vista diferente sobre el asunto, así que no espere poder "motivarlos" para que hagan lo que usted quiere... involúcrelos en una discusión sobre el problema y pídales que piensen en una solución, es mucho más efectivo.

@Mamoo tiene razón. Un gerente de proyecto nuevo y junior no tiene la autoridad o la influencia para llegar a una solución y pedirle al equipo que la implemente. Incluso como gerente de proyecto de dos décadas, no intentaría imponer una solución al equipo.

Como PM, debe ayudarlos a encontrar su propia solución. Para hacer esto, primero debe hacer que identifiquen el problema. Hasta que reconozcan que hay un problema, ni siquiera estarán dispuestos a considerar una solución.

Las retrospectivas son una excelente manera de hacer esto. Al guiar al equipo a través de un examen de lo que está pasando con el proyecto, los ayuda a descubrir los problemas por sí mismos.

Algo tan simple como el juego Speedboat/Sailboat puede hacer esto. También puede ir a TastyCupcakes.org y buscar juegos retrospectivos. Desea concentrarse en ejercicios que revelen problemas. Incluso la simple lluvia de ideas de dos columnas "Qué salió bien, cosas para mirar" lo llevará más lejos que decirle al equipo "Es la documentación".

Creo que te refieres a la gestión del conocimiento. Estoy en la misma posición. Es una pesadilla tratar de mantener actualizados los procesos y el conocimiento, por lo que si el conocimiento tácito se va, no es el fin del mundo. Alguien más puede recoger y hacer ese trabajo, sin riesgo para los sistemas de información, las personas y los componentes necesarios para realizar el trabajo.

Usamos la confluencia. Es una wiki de código abierto. La gente actualiza esto y es accesible para todos en la organización. Una vez que alguien agrega una entrada, se revisa por pares desde una perspectiva de control de calidad. Usé Sharepoint para esto en una organización anterior. Las instrucciones de trabajo y los mapas de procesos se diseñaron para funcionar en paralelo. Ahora es imprescindible para las organizaciones y es absolutamente esencial que se gestione.

Recientemente hice Lean Six Sigma para esto. Obtuve un certificado de estudiarlo a distancia. Le ayuda a analizar sus procesos, reducir la variación y eliminar las cosas sin valor.

Espero que esto ayude.

¡NO! No puedes obligarlos, no es su trabajo. Es su trabajo (o el trabajo del gerente de proyecto).

Soy desarrollador de software, y si alguien me dijera que documentara el proceso de funcionamiento del sistema, no lo haría.

(En realidad, me han preguntado muchas veces y les he dicho que lo dejen, renuncien o hayan tenido una gran repercusión, porque sabía la forma correcta en que debía hacerse sin atajos ni costos)

Ese es el trabajo del gerente del proyecto, entregarme la especificación, para que sepa cómo hacer MI trabajo, aprobado por los grandes jefes. Para que después no sea, por qué hiciste esto y pensé que harías aquello. Joder eso.

Lo que está experimentando es un problema muy común, en el que alguien escribió un código para hacer algo y se convirtió en un negocio, los perros van hacia adelante (al revés). El desarrollador escribió el código basado en lo que dijo el jefe y ahora el proyecto es tan grande que nadie sabe nada.

Las soluciones es:

• Control de código fuente (TFS o GitHub)
• Sistema de venta de entradas. Jira, tareas de TFS, Kanbanary, lo que sea.
• Unidad central con documentos o Wiki en línea

El gerente de proyecto crea la documentación para acompañar el ticket/tarea y se asegura de que esté actualizada en el documento de especificación principal. (Por lo general, Business Analyst hace esto ... pero la falta de BA recae responsablemente en PM)

El administrador de proyectos lo administra todo, los desarrolladores verifican el trabajo y seleccionan los boletos o PM asigna boletos al desarrollador si los desarrolladores son "herramientas" y no pueden ser responsables y seleccionar los boletos ellos mismos.

Creo que la mejor forma de motivar a las personas para que inicien una obra es involucrarlas en la toma de decisiones. Si participan en el proceso de toma de decisiones y eligen una solución, entenderán por qué se debe hacer ese trabajo y, en consecuencia, estarán más comprometidos. Documentar es aburrido a menos que sientas la esencia de ello.

Estoy de acuerdo con la mayoría de los sentimientos en estas respuestas. Si tiene un SDE, o un equipo de SDE, es mejor mantenerlos escribiendo código y cuanto menos tiempo pasen escribiendo documentación, mejor. En el momento en que alguien está escribiendo código, la documentación debería (en su mayoría) estar en su lugar. Dicho esto, existen estrategias que se pueden usar para mantener el código correctamente comentado (otra forma de documentación). La estrategia que utilizamos es una forma de "calidad continua". Usamos una solución de software llamada Sonar que analiza el código cuando se registra para muchas cosas diferentes: convenciones de nomenclatura, líneas de código repetidas, volumen de comentarios, etc. Si el volumen de comentarios es demasiado bajo, echamos un vistazo y nos aseguramos de que el código pueda ser leído y entendido por un desarrollador que no lo escribió. Si no, los comentarios deben reforzarse.

Si, por otro lado, su equipo no está compuesto por SDE, sino por las personas que diseñan el sistema (arquitectos, DBA, etc.), entonces sí necesita que produzcan una buena documentación, y una estrategia para lograr que lo hagan es reclutar uno de los consumidores intermedios de dicha documentación para examinar lo que se ha escrito. Si la documentación no es clara o es demasiado escasa, tiene un elemento procesable con un guardián para iniciar. ¿Tener sentido?

En la mayoría de los casos, si no en todos, la evidencia de una sólida documentación es consistente con una organización madura y de alto desempeño, y la falta de documentación es consistente con una organización inmadura y de bajo desempeño. Es por eso que varios modelos de madurez tienen un ENORME aspecto de documentación. Quién puede crear los documentos depende de quién es el mejor rol para documentar, que generalmente es quien hace el trabajo. Es simplemente parte del trabajo y parte de la descripción del trabajo.

Todos los roles que existen tienen aspectos del trabajo que a nadie le gustan y que desearían poder ceder a otra persona... o se argumenta tontamente que no es necesario.

Si su cultura ha respaldado la falta de documentación, entonces cambie la cultura y eso requiere un patrocinio de alto nivel. Simplemente hágalo parte de la descripción del trabajo y parte de su evaluación. Aquellos a los que no les guste eventualmente serán eliminados y viceversa.

Todos los trabajos, incluidos los desarrolladores de código, tienen tareas que no son deseables. Superalo.