En nuestra búsqueda de una solución SE/BIM sin correo electrónico, nos esforzamos por reducir los "términos" de comunicación a su esencia. En la jerga de PM, tendemos a usar muchos términos, como; Decisión - Acción - Tarea - Nota - Pregunta - Solicitud de cambio - Orden de cambio - Asunto - Observación - Comentario - Aprobación - Supuesto - Elemento - …
¿Cuál es el conjunto mínimo de 'términos' para gestionar todo tipo de comunicación? Se trata de algo más que semántica.
Imagine que desea configurar una aplicación de base de datos para reemplazar totalmente la necesidad de correo electrónico, para todas las necesidades de comunicación en un proyecto. Tiene que estar basado en roles, rastreable y hermético.
Entonces, ¿para qué usamos el correo electrónico en los proyectos? Informar, cuestionar, dar una tarea, implementar una decisión, señalar un problema, solicitar u ordenar un cambio, dar retroalimentación, .... etc. etc. ¿Cómo podríamos reducir esto a un conjunto mínimo? de 'tipos de comunicación' - a falta de una mejor expresión - para que podamos construir un reemplazo de correo electrónico basado en una base de datos? Con el beneficio obvio de que toda comunicación es siempre explícita, estructurada, relacionada, registrada, rastreable,... en lugar de mi Bandeja de Entrada, ¿cuál es un Agujero Negro?
Por ejemplo:
una Nota (o Observación o Comentario) es un mensaje (una pieza de información), de un Remitente (una persona/función o una 'reunión') a un Receptor (una o más personas/función(es) o un reunión). No requiere una respuesta. Entonces, los únicos campos de datos requeridos son: Mensaje (= la nota) - Remitente - Receptor.
una pregunta (¿o solicitud de información o problema?) es un mensaje de un remitente a un receptor (las mismas definiciones que arriba). SÍ requiere una respuesta, en un tiempo determinado. Entonces, los campos de datos requeridos ahora son: Mensaje (= la pregunta) - Remitente - Receptor - Fecha de vencimiento. La Respuesta estará vinculada a esta Pregunta, para que sea rastreable.
una Decisión es un mensaje (una pieza de información), de un Emisor a un Receptor (las mismas definiciones que arriba). No requiere una respuesta como tal, pero debe dar lugar a la mutación de un Requerimiento (Eliminar, Cambiar o Crear). Si no, es solo una nota. Entonces, los campos de datos requeridos ahora son: Mensaje (= la decisión) - Remitente - Receptor - Requisito(s) afectado(s). La Decisión permanecerá vinculada a la Decisión afectada, de manera que sea trazable.
y así ...
Mi pregunta ahora es: ¿cuántos 'términos' se requieren para atender todos los tipos de 'intercambios de información' en un sistema PM basado en roles, si el objetivo es dejar obsoleto el uso del correo electrónico? ¿Y cuál es el conjunto más pequeño, para mantener esto lo más simple posible?
¿Existe algún tipo de 'modelo de intercambio de información' (es decir, modelo de comunicación)?
Intentaré responder a tu pregunta, pero no estoy seguro de que sea realmente posible.
Digamos que hay 5 mensajes discretos que uno puede enviar a otro.
*Dentro de los 30 segundos posteriores a la publicación de esto, alguien dirá "¿qué pasa con x?" y tendrán razón. Para hacer una pequeña lista, debe hacer generalizaciones generales.
En este punto, un BA o PM preguntaría, ¿cuál es realmente el problema que está tratando de resolver? Parece que el correo electrónico no funciona para ti y quieres crear algo mejor. Luego miraríamos y veríamos cuánto costaría y cuáles serían los beneficios para la organización.
Una de las primeras cosas que le preguntaría a mi equipo técnico es: "¿Existen ya herramientas que se puedan obtener por menos de lo que se necesitaría para construirlas?" Tal vez, tal vez no, pero siempre vale la pena mirar. (Además, ¿este producto será parte de su negocio principal? Vea la opinión de Joel )
En este caso particular, hay muchas herramientas diferentes que pueden usarse para resolver este problema, aunque no exactamente de la manera que mencionas. Tal vez la holgura haría el truco, o tal vez asana.
Entiendo sus objetivos de la siguiente manera:
Asumiendo que esto es correcto, aquí están mis pensamientos:
Esto ha sido intentado y parcialmente resuelto por un montón de gente. ¿Qué tal echar un vistazo a varias herramientas de colaboración y comunicación en el lugar de trabajo para ver qué han decidido implementar en términos de objetos y flujos de trabajo? Este podría ser un lugar para comenzar: http://alternativeto.net/software/jira/
No conozco su organización ni lo que está en juego en este esfuerzo, pero su enfoque suena demasiado teórico. Dudo que sea eficiente y que llegues a un entendimiento final que todos puedan suscribir que no sea muy complejo. es decir, tendrás
Sin conocimiento sobre su organización, las personas solo podrán darle respuestas inspiradoras, pero no necesariamente precisas. Si está tratando de desarrollar una solución para su organización, se adaptará a sus necesidades y, por lo tanto, debe derivarse de los procesos que su organización emplea actualmente (e idealmente, los que prevé que se emplearán en el futuro). Entonces, estos requisitos solo pueden ser entendidos por personas en la organización. O recibirá información sobre conceptos bastante genéricos, que con toda probabilidad ya estarán disponibles en alguna solución OTS (es decir, un denominador común de las herramientas de PM, por así decirlo).
Su mejor enfoque podría ser usar una solución que
Hay varios modelos de comunicación. Sin embargo, la forma más segura de crear un entorno sin correo electrónico y comprender su impacto es cortar el correo electrónico para las comunicaciones del proyecto.
Por una variedad de razones, incluida la comunicación... construya el flujo de trabajo de su proyecto en torno a Git o algún sistema de control de versiones DESCENTRALIZADO.
Debe anticipar que las personas trabajarán en diferentes lugares, en aeropuertos, en sus hogares, en parques o cafeterías y ocasionalmente en sus escritorios. Si no descentraliza los repositorios de control de versiones, el sistema de control de versiones no se utilizará y la gente adaptará una increíble variedad de alternativas de copia de seguridad y almacenamiento de archivos ad hoc y sneakernet.
Insto encarecidamente a cualquiera [que se tome en serio la comunicación] a que analice detenidamente el flujo de trabajo centrado en Github... debido al códegrafo completo de Github y todas las formas de comunicar inherentemente el progreso a todos los participantes mediante el seguimiento visual de confirmaciones, extracciones, problemas, comentarios, etc... Y, quizás aún más importante, para que pueda prescindir de las reuniones [donde de todos modos nunca ocurre una comunicación real] y usar el chat centrado en el repositorio, por ejemplo, Gitter.
Una ventaja adicional para todos los que soportan el dolor de aprender Git y pasar a un modelo de flujo de trabajo basado en Git es que sus habilidades trabajando dentro de este marco mental serán transferibles y funcionarán en todas las organizaciones.
Git es de código abierto y eso es EXTREMADAMENTE importante porque explica por qué Git y sus variantes han ganado la batalla en el importante ámbito del control de versiones . Cualquiera que utilice el control de versiones utilizará un dialecto de Git durante los próximos 25 años o más... un flujo de trabajo de PM [comunicación] basado en Git va a triunfar sobre todos los demás enfoques propietarios. Si hay una idea mejor, vendrá de una extensión o bifurcación de Git.
Todd A. Jacobs
johan kuppens
Todd A. Jacobs
MCW