Regístrate al Videoboletín informativo
Recibe en tu correo contenido de actualidad sobre el mundo de la gestión de proyectos: videos, entrevistas, artículos, noticias, eventos, ofertas de trabajo, cursos y mucho más.

¡Certifícate ya como PMP® o CAPM®!
Reserva una beca de hasta un 80% para unirte al programa en línea de habla hispana más efectivo de certificación PMP® o CAPM®: Los 1000 Certificados de LiderDeProyecto.com

Documentos - adquisisciones

Más
30 Jun 2020 14:01 #134529 por moderador
Respuesta de moderador sobre el tema Documentos - adquisisciones

moderador escribió:

stergh escribió: Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

GESTIÓN DE DOCUMENTOS Y DE REGISTROS

INTRODUCCIÓN

Los sistemas de gestión de los documentos y de los registros son fundamentales para el éxito de cualquier proyecto.

Los documentos deben estar disponibles para la llevar a cabo los procesos, las actividades y las tareas que son indispensables para la ejecución del proyecto. Por otra parte los documentos que se generan durante dicha ejecución son denominados registros.

Ambos tipos de documentos deben ser gestionados adecuadamente para que al finalizar el proyecto se pueda disponer de los antecedentes del mismo y mantener su historial de modo de guardar las lecciones aprendidas que permitan aprovecharlas en futuros proyectos de naturaleza similar. En un nivel más amplio, la temática de la gestión de la documentación es parte de la gestión del conocimiento.

Los documentos y los registros pueden estar en soporte papel o en soporte electrónico, así como parcialmente en uno y otro soporte.

Cuanto más grande es un proyecto, más difícil se vuelve el compartir información de manera fluida entre todos los miembros del equipo y con las otras partes interesadas. Esto es particularmente cierto cuando más de una persona trabaja en entregables muy grandes.

Si el Gerente del Proyecto no piensa de forma anticipada en estos procesos, el proyecto finalizará con grandes problemas para localizar información relevante así como frustración al tener que manejar formatos de entregables inconsistentes. Esto probablemente derivará en esfuerzos adicionales para rehacer trabajo que ya se había finalizado.

Sin este tipo de herramientas, sería imposible desarrollar y soportar proyectos grandes de desarrollo de aplicaciones, de modo que no se presente confusión, incertidumbre y trabajo extra durante la ejecución del proyecto. Quizá estas consideraciones son triviales para proyectos pequeños. Para proyectos grandes, estos procesos necesitan planearse de modo anticipado, de lo contrario, se presentara

GESTIÓN DOCUMENTAL

Proyectos pequeños

A menos que el proyecto pequeño sea parte de uno de mayor envergadura o incluso de un programa, no será necesario preocuparse por la gestión documental.

Aun así, el Gerente de Proyecto siempre podrá revisar los aspectos de gestión documental para proyectos más grandes expuestos mas adelante, para tomar de ahí lo que haga sentido de acuerdo al tamaño del proyecto que este conduciendo.

Proyectos medianos y grandes

Aunque los proyectos pequeños experimentan menor cantidad de problemas al gestionar su documentación, algunos de los procesos e infraestructura para la gestión de documentos puede resultar útil para ellos. Por ejemplo, aun un proyecto pequeño necesitará un almacenamiento común o bien una estructura de directorios para almacenar los entregables de proyecto. Cada Gerente de Proyecto puede evaluar su propio proyecto con el fin de identificar aquellas áreas que tenga sentido definir. Asimismo, en esta área hay un componente tecnológico. Si se usa una aplicación la gestión documental, ésta puede facilitar y resolver gran cantidad de las definiciones necesarias y, puede definir incluso, ciertos procedimientos para actualizar la información.

Entre más grande sea el proyecto, mayor rigor y estructura se requiere para manejar los documentos.

Almacenamiento de Documentos

Es necesario decidir en donde serán almacenados los documentos del proyecto. Esto puede ser un directorio en una computadora, una aplicación para la administración de documentos, alguna herramienta de trabajo en grupo, un archivero de documentos físicos, etc.

Herramientas de Documentación

¿Qué herramientas de documentación serán usadas como estándar? Obviamente se recomienda no tener a la mita del equipo trabajando con MS Word® y a la otra mitad usando WordPerfect®. Del mismo modo, todos los miembros del equipo deben usar la misma hoja de cálculo. Si se usa una herramienta para hacer el plan de trabajo del proyecto, todo el que necesite acceso deberá estar habilitado para usar la misma aplicación. Una vez que el software estándar ha sido definido, es importante asegurar que el equipo completo usa la misma versión. En otras palabras, si se está usando MS Office 2000 ®, se debe verificar que todos los usuarios tengan la versión 2000 de Office. Algunas veces, los documentos no podrán ser compartidos si el creador y el lector no usan la misma versión del producto.

Reglas de Acceso

¿Quién tendrá la facultad de acceder a los documentos? ¿Quién los puede actualizar? ¿Quién los podrá leer?




Gestión de los documentos y registros

¿Quién será el responsable de gestionar los documentos y registros? ¿Se realizarán respaldos de la información? En proyectos grandes, esto puede significar un rol de tiempo completo. Aunque alguien con experiencia en trabajo administrativo de oficina puede cubrir muy bien esta función. Las responsabilidades de los bibliotecarios son las siguientes:

Coordinar la actividad alrededor de la gestión documental.
Establecer, mantener y reforzar los procedimientos de almacenamiento de documentación y dar seguimiento al cumplimiento de éstos.
Identificar / resolver problemas con el almacenamiento .
Verificar / controlar el acceso y actualizaciones al almacenamiento
Determinar cuando es necesario respaldar documentos viejos y depurarlos.

Organización / física y lógica del almacenamiento

¿Cuál es la organización más conveniente para el almacenamiento ? Se recomienda que primero se haga un esquema de la vista lógica de la estructura. Después es necesario determinar la forma en que este diseño lógico se pueda implementar en un directorio o herramienta. La estructura debe ser tal que sea fácil de entender y fácil y práctica para buscar y encontrar información relevante.

Indexación / palabras clave

En función de la tecnología del almacenamiento, puede ser posible buscar documentos. La búsqueda de documentos normalmente puede ser hecha usando el nombre del documento (lo que hace más importante el uso de estándares de nomenclatura de documentos) o bien por palabra clave. Las palabras clave son palabras descriptivas asociadas al documento de tal forma que se pueda encontrar rápidamente el documento buscado, especialmente cuando no se está seguro del nombre del mismo o bien en donde se localiza.

Las capacidades de búsqueda y de definición de palabras clave, deben establecerse de antemano. Algunos ejemplos de un esquema de indexación básica de documentos incluiría el título del documento, el tema, el autor, persona de contacto, fecha de envío y una lista de palabras clave. Por supuesto, al finalizar lo anterior, el documento deberá ser agregado al almacenamiento ; al concluir, el documento podrá ser buscado, usando cualquiera de las palabras clave o vía la indexación.

Codificación de archivos

Después de que la estructura de archivos ha sido establecida, será necesario definir los estándares de nombramiento de los archivos. Esto evitará que la información sea mal clasificada o almacenada en el lugar incorrecto. Por ejemplo, dentro de la carpeta de reportes de estado, la convención de nombramiento de archivos puede ser “20001201 Juan García Reporte de estado”. En este esquema, todos los reportes de estado de un periodo estarán agrupados.

Por otra parte “Juan García Reporte de estado 200011201” ordenará los reportes por persona. El Gerente de Proyecto y el bibliotecario asegurarán que todo el mundo está usando el estándar de nombramiento. Aunque este ejercicio puede resultar tedioso, esta práctica de trabajo puede resultar muy valiosa cuando el equipo de proyecto produce cientos de documentos al paso del tiempo.

Manejo de Versiones

¿Los documentos anteriores serán conservados si éstos son actualizados o solo la versión más actual será almacenada? Gran cantidad de documentos, como la definición de proyecto, deberá tener todas las versiones aprobadas guardadas. Para estos documentos, el nombre de archivo deberá incluir un tipo de número de versión, por ejemplo, “Definición de Proyecto ABC v1”. Con este tipo de convención en el nombramiento del archivo, será relativamente fácil asegurar que todos estarán consultando la versión mas reciente.

Estado del documento

Cuando los documentos necesitan ser aprobados, y especialmente si el proceso de aprobación tiende a ser largo y sinuoso, es importante señalar que estado de aprobación tiene el documento. Por ejemplo, es importante saber si el entregable que se está consultando es una versión final aprobada, o un borrador. Al definir bibliotecas separadas para documentos que están en proceso de autorización, se puede manejar muy bien esta distinción.

Los estados típicos de un documento son: “Borrador”, “Esperando aprobación” y “Aprobado”. Cuando un documento es creado, estará en estado de borrador. Cuando el documento está circulando para obtener retroalimentación y/o aprobación, éste se mueve a la carpeta denominada “esperando aprobación” y finalmente, cuando el documento es finalmente aprobado, se deberá colocar en la carpeta “aprobado”. Otro proceso es colocar en una carpeta los documentos “no aprobados” y los documentos “aprobados” se almacenan en una base de datos de entregables aprobados.

Retención / Eliminación

Asegura que la información en el almacenamiento es relevante. Por ejemplo, los Repostes de Estado Semanal pueden no ser necesarios después de tres meses; pero por otra parte, el documento Definición del Proyecto será necesario, aun después de 12 meses de haber sido generado. Periódicamente durante el proyecto, el bibliotecario puede respaldar cualquier información que deje de ser relevante y eliminar los documentos del almacenamiento .




Respaldos

Si el almacenamiento de documentos no es respaldado de forma automática, el Gerente de Proyecto necesita incluir actividades de este tipo en el plan de trabajo, de modo que se asegure que el respaldo se ejecute. Si procesos fuera de línea están respaldando el almacenamiento , es necesario cerciorarse de la disponibilidad del respaldo, en caso de que sea necesario recuperar información. También es necesario registrar en donde se conservará el respaldo y por cuanto tiempo. Al menos una copia recuperable del respaldo debería conservarse fuera de sitio en caso de desastre.

Formato estándar de documentación

Es más fácil en el largo plazo leer y crear documentos si todos siguen un formato y plantilla estándar. Por ejemplo, el equipo de proyecto debería acordar un estándar de tipo de fuente y tamaño de letra a ser usado en todos los documentos. Adicionalmente, encabezados y pies de página estándares, carátulas y tablas de contenidos. Esto dará a toda la documentación una imagen estándar.

Revisión periódica del almacenamiento

En caso de que el proyecto sea muy grande y el Almacenamiento de Documentos es muy complicado, podría tener sentido conducir revisiones periódicas para revisar el almacenamiento y los procesos generales de gestión documental. El bibliotecario será responsable de coordinar esta revisión.

Durante ésta se puede verificar lo siguiente:

El almacenamiento se está respaldando y depurando de manera apropiada
La documentación se está colocando en el lugar correcto
Los documentos son indexados y categorizados apropiadamente, de modo que sean fácilmente accesibles cuando sea necesario.
Los documentos son agregados de forma continua, o por lo menos al final de cada fase mayor.

Procedimiento de actualización del almacenamiento

El Gerente de Proyecto tiene que decidir si el acceso de actualización al almacenamiento será controlado o bien, si todo el equipo de trabajo tendrá privilegios para actualizar información en éste. Si todos tienen esta capacidad, existirá la tendencia de degradar la consistencia y calidad de la información. Sí el acceso es controlado, entonces solo el bibliotecario y el proceso de respaldo podrán actualizar o agregar documentos. Un proceso que soporta lo anterior es:

Los miembros del equipo envían los documentos al bibliotecario cuando éstos hayan obtenido la aprobación final, o bien al final de cada fase y al final del proyecto. El equipo de trabajo usa un formato de requisición para el bibliotecario, en donde se describa el entregable, las palabras clave, la fecha de aprobación, la carpeta en donde se encuentra, la versión, etc...

El bibliotecario se asegura que el formato es apropiado para el almacenamiento y que se apega a los estándares definidos. En caso de que no se cumplan estas condiciones, el documento es regresado al equipo de trabajo para que sea corregido.

Si el documento es relevante y cumple con los estándares definidos, el bibliotecario lo coloca en la carpeta que le corresponda y actualiza cualquier otra información requerida. El bibliotecario usa la información del formato de requisición para determinar el lugar en donde éste tendrá que ser almacenado.



Alvaro

Introducción
Idealmente, un documento ágil es apenas bueno o apenas suficiente para la situación que tenemos a mano. La documentación es una parte importante de los proyectos de desarrollo ágiles, pero a diferencia de los tradicionalistas que a menudo ven la documentación como una estrategia de reducción de riesgos, los agilistas comúnmente ven la documentación como una estrategia que aumenta el riesgo total del proyecto y, por lo tanto, se esfuerzan en ser tan eficientes como sea posible cuando se trata de documentación. Los agilistas escriben documentación cuando esa es la mejor manera de lograr las metas relevantes, pero a veces se ha probado que es mejor cumplir las metas que escribir documentación estática. Este artículo resume las “buenas prácticas” comunes que los agilistas han adoptado con respecto a la documentación.
1. Buenas Prácticas para escribir Documentación Efectiva
Las siguientes prácticas nos ayudarán a mejorar nuestro enfoque para escribir documentación:
1. Prefiera especificaciones ejecutables en vez de documentos estáticos.
2. Documente conceptos estables, no ideas especulativas.
3. Genere documentación del sistema
1.1 Prefiera especificaciones ejecutables en vez de documentos estáticos
La mayoría de la información capturada en los documentos de especificaciones tradicionales, tales como la especificación de requerimientos, o especificaciones de diseño, puede ser capturada como “especificaciones ejecutables” en forma de pruebas. Cuando tomas un enfoque TDD (Desarrollo Manejado por Pruebas), escribes efectivamente especificaciones detalladas sobre una base JIT (Just in time, o, sobre la hora). Con TDD escribes una prueba, ya sea a nivel de aceptación de cliente o nivel de desarrollador antes de escribir la suficiente funcionalidad para cumplir esa prueba. Las pruebas son usadas con dos propósitos: especifican los requerimientos/arquitectura/diseño, y validan tu trabajo. Este es un ejemplo de la práctica Información de una Única Fuente.
1.2 Documente Conceptos Estables, no Ideas Especulativas
Como se puede ver en la figura 1, la estrategia ágil es posponer la creación de todos los documentos tanto como sea posible, crearlos justo antes de que los necesitemos vía una práctica llamada “documento atrasado”. Por ejemplo, los resúmenes del sistema se escriben mejor al final del desarrollo de una entrega porque conocemos lo que realmente construimos. De la misma manera, la mayoría de las documentaciones de usuario y soporte es mejor escribirlas al final del ciclo de vida del proyecto. Sin embargo, esto no significa que toda la documentación deba escribirse al final. Igual querremos tomar notas para esos tipos de documentos a través del desarrollo para que no perdamos información crítica. Estas notas puede ser solo información puntual y puede que no haya necesidad de “pulir” los documentos hasta estar bien cerca de entregarlos.


Figura 1. Documentación a través del ciclo de vida de desarrollo de software.

Al esperar documentar la información hasta que se haya estabilizado, reducimos tanto el costo como el riesgo asociado con la documentación. El costo se reduce debido a que no tenemos que perder tiempo documentando información que cambia, lo cual, a la vez, nos motiva a actualizar la documentación. El riesgo se reduce debido a que hay mucho menos posibilidades de que la documentación existente esté desactualizada. Si escribimos documentación que contiene información que aún no ha sido estabilizada, entonces nos arriesgamos a tener que volver a trabajar la documentación cuando ésta cambie. En otras palabras, no queremos invertir mucho tiempo documentando ideas especulativas tales como los requerimientos o diseños de las etapas tempranas del proyecto. En lugar de eso, mejor esperar al final del ciclo de vida, cuando la información se ha estabilizado y cuando sabemos cuál es la información útil. La desventaja es que nuestros esfuerzos de documentación podrían estar unas pocas iteraciones atrasadas con respecto a los esfuerzos de desarrollo de software.
Una versión extrema de esta práctica es esperar hasta que hayamos terminado y recién entonces escribir la documentación. La ventaja principal es que estás escribiendo sobre algo conocido y estable (la entrega del software que acabamos de construir). Pero, hay varias desventajas de este enfoque:
• Probablemente hayas olvidado algunas de las razones detrás de las decisiones que hiciste, lo cual, claramente es un problema si esto es importante de documentar.
• Podrías no tener disponibles a las personas que escriben la documentación porque pueden haberse movido a otros proyectos.
• Podrías no tener financiamiento para hacer el trabajo.
• Podría dejar de existir el deseo de escribir la documentación.


1.3 Genere Documentación del Sistema
Las herramientas de modelado de software modernas pueden hacer ingeniería inversa al código existente y presentar una gran variedad de vistas sobre esa información. En resumen, podemos ahorrar mucho dinero generando la mayoría de la documentación del sistema que necesitamos usando las herramientas disponibles.

2. Buenas Prácticas para la Simplificación
Las siguientes prácticas nos ayudaran a simplificar la documentación que escribimos:
1. Mantenga la documentación lo suficientemente simple, pero no tan simple.
2. Escriba el mínimo de documentos con poca redundancia o repeticiones.
3. Ponga la información en el lugar más apropiado.
4. Muestre la información públicamente.
2.1 Mantenga la documentación lo suficientemente simple, pero no tan simple
La documentación exhaustiva no asegura el éxito de un proyecto, de hecho, aumenta las posibilidades que falle. La documentación debería ser concisa: generalmente los resúmenes/mapas son preferidos por sobre la documentación detallada. Siga las prácticas del Modelamiento Ágil (AM – Agile Modeling): Use las Herramientas más Simples, Cree Contenido Simple, y Represente Modelos Simplementa cuando cree la documentación. La mejor documentación es la más simple que logra que se haga el trabajo. No cree documentos de 50 páginas que pueden ser hechas en 5. No cree un documento de 5 páginas cuando se puede hacer con 5 viñetas. No cree diagramas elaborados y complejos cuando se puede hacer con un bosquejo. No repita información en ninguna parte cuando se pueda usar una referencia. Escriba en forma puntual. Documente solo lo suficiente para entregar un contexto útil. Empiece con un documento que es lo suficientemente minimalista para las necesidades de los clientes y vaya aumentándolo a medida que se necesite. Para determinar cuál es la verdadera cantidad mínima de documentación requerida por los clientes, explore activamente (pregunte) en cómo pretenden usar la documentación y por qué la quieren usar de esa manera.
El intercambio básico acá es la “seguridad” de tener el documento contra la confianza en su contenido. ¿Qué prefiere tener, un documento del sistema de 500 páginas que probablemente tenga una cantidad significativa de errores en él pero harto detalle, o un resumen de alto nivel de 10 páginas? El documento grande probablemente tenga toda la información de sistema que necesite para la mantención y mejora del mismo, pero, ¿confiaría en la información que hay en él? El documento más corto probablemente no tenga la información detalla que necesite, pero le entregará un mapa de donde puede indagar en el código fuente, u otros documentos, por detalles. Usted quizás confíe más en este documento porque es más corto, en el peor de los casos, se podría actualizar fácilmente o simplemente reescribirse si encuentra que es groseramente inexacto, debido a que está relacionado con conceptos de alto nivel tales como la arquitectura del sistema, la cual cambia más lentamente que la minuta detallada contenida en el documento más grande. Es importante entender que no estamos diciendo que el documento más extenso es automáticamente de menor calidad que el más corto, pero sí que es mejor percibirlo así hasta que se pruebe lo contrario.
2.2 Escriba el mínimo de documentos con poca redundancia o duplicados
Debemos esforzarnos por viajar lo más ligeros como sea posible, escribiendo la suficiente documentación para la situación a mano, la cual es apenas suficiente para lograr su propósito. Una manera de lograr esto, es escribir documentos más grandes a partir de los más pequeños. Por ejemplo, documentar la arquitectura del sistema en una página HTML, el diseño de pantallas en otra página (o wiki), y así sucesivamente, para finalmente unir todas las páginas con una que tenga un índice con enlaces a cada tema (tabla de contenidos). La ventaja de esto es que la información fue definida en un solo lugar, de tal manera que no hay opción para que hayan duplicados.
2.3 Ponga la información en el lugar más apropiado
¿Dónde alguien querría un pedazo de documentación? ¿Es esta decisión de diseño, mejor documentarla en el código, agregarla como nota en el diagrama, o mejor ponerla en un documento externo? ¿Es un requerimiento específico, mejor capturado como parte de un caso de uso, una especificación de regla de negocio, o como una prueba ejecutable? La respuesta a este tipo de preguntas debería estar guiada por las necesidades del cliente que necesita esa información. También es guiada por nuestro deseo de seguir el principio de Trabajo de Calidad, deberíamos esforzarnos por registrar la información una vez que ésta mejora más nuestro trabajo (por ejemplo, Información de una Única Fuente – SingleSource Information). También deberíamos considerar temas como la indexación, linkeo y accesibilidad cuando se está escribiendo documentación porque no siempre sabemos quién será eventualmente el consumidor de la información.
2.4 Muestre la información públicamente
Cuando los modelos son mostrados públicamente – en una pizarra, o un sitio web interno – estamos promocionando la transferencia de información y así la comunicación a través de la aplicación de lo que Cockburn se refiere como “radiador de información”. Mientras mayor sea la comunicación de nuestro proyecto, menor será la necesidad de documentación detallada porque las personas ya sabrán lo que estamos haciendo. Dicho esto, no olvidemos indicar el estado de nuestro trabajo para que la gente pueda ponerlo en contexto – tratarán a un modelo a un bosquejo de manera muy diferente a si está debidamente aprobado y con línea base para la entrega actual de software.

3. Buenas Prácticas para Determinar Qué Documentar
Las siguientes prácticas nos ayudarán a determinar qué documentar:
1. Documente con un propósito.
2. Enfóquese en las necesidades de los clientes actuales del documento.
3. El cliente determina la suficiencia.


3.1 Documente con un propósito
Se debe documentar solo si satisface una meta clara, importante e inmediata para el total de los esfuerzos del proyecto. No olvide que este propósito debe ser a corto o a largo plazo, puede apoyar directamente a los esfuerzos de desarrollo o puede que no. También recuerde que cada sistema tiene sus propias y únicas necesidades de documentación, es tamaño en particular no sirve para todo – una implicación de que no podrá seguir un “proceso repetitivo” y entregar el mismo conjunto de documentación (o plantillas) en cada proyecto, al menos no si está interesado en ser realmente efectivo.
3.2 Enfóquese en las necesidades de los clientes actuales del documento
Usted quiere trabajar de cerca con la audiencia del documento de tal manera de saber lo que ellos realmente requieren de ella. Para hacer esto, hay que identificar a los potenciales usuarios o clientes de la documentación, que creen que necesitan y luego negociar el subconjunto mínimo que realmente necesitan. Para descubrir lo que ellos creen que requieren, hay que preguntarles acerca de qué hacen, cómo lo hacen y cómo quieren trabajar con la documentación que se les entregará. Entendiendo las necesidades de los usuarios podremos entregar la documentación necesaria y suficiente, y entregarla donde ellos realmente la necesitan encontrar – no importa que tan bien esté escrito un documento si nadie sabe que existe.
3.3 El cliente determina la suficiencia
En una institución financiera de Canadá tenían una política que decía que no se podía hacer la transición de un sistema a alguien a menos que esta persona estuviera dispuesta a aceptarlo. Ellos inspeccionarían el código y los artefactos de apoyo y si sentían que los artefactos no estaban a la par de lo que necesitaban, había que mejorarlos una y otra vez. A veces, tendremos que trabajar en mejorar los artefactos en conjunto, otras veces no. Esta práctica provee una compuerta de calidad justa y efectiva entre los desarrolladores y los usuarios del trabajo. Como escritores de documentación, es nuestro trabajo asegurarnos de que tenga un verdadero significado y entregue valor, el rol del usuario es validar que lo hemos hecho así.

4. Buenas Prácticas para Determinar Cuándo Documentar
Las siguientes prácticas nos ayudarán a determinar cuándo documentar:
1. Iterar, iterar, iterar
2. Encuentre mejores maneras de comunicarse
3. Empiece con modelos que realmente estén actualizados
4. Actualice solo cuando duele


4.1 Iterar, iterar, iterar
Idealmente se debe crear documentación a través de todo el ciclo de vida del software, cuando tiene más sentido, aunque eso normalmente es cerca del final del ciclo. Cuando escribimos documentación, debemos tomar un enfoque evolutivo (iterativo e incremental) para su desarrollo para que tengamos retroalimentación de su valor actual. En otras palabras, escribir un poco, mostrárselo a alguien, obtener la retroalimentación, actuar sobre esa retroalimentación y luego iterar. Los mejores documentos son escritos iterativamente, no todo de una vez. Un enfoque iterativo nos permite enfocarnos en lo que la audiencia realmente necesita.
4.2 Encuentre mejores maneras de comunicarse
Highsmith cree que el problema principal con la comunicación es el entendimiento, no la documentación, por lo tanto, no se debe sobrevalorar el valor de la documentación. Documentación bien escrita apoya a la memoria organizacional efectivamente, pero es una manera pobre de comunicarse durante el proyecto. Nuestra meta es asegurar que los desarrolladores de mantención entienden cómo trabaja el sistema para que pueda evolucionar en el tiempo, no producir una montaña de documentación que pueda o no pueda usarse. Nuestra meta es asegurar que nuestros usuarios trabajen con nuestro sistema efectivamente, no que tengan un bonito sistema de ayuda disponible para ellos. Nuestra meta es permitir nuestro apoyo al staff de soporte y operaciones, no taparlos con papel.
La documentación apoya la transferencia de conocimiento, pero solo es una de las muchas opciones disponibles para hacerlo y como se muestra en la figura 2, a menudo no es la mejor opción. La implicancia de este diagrama es que deberíamos elegir el mejor medio de comunicación disponible dada la situación. Las opciones de documentación, en particular, las “especificaciones en papel” son la opción menos deseable, no la más deseable. Las conversaciones con los stakeholders, tenerlos activamente involucrados con el desarrollo, estar disponible para trabajar en cualquier problema con ellos, muchas veces va más lejos que la mejor de las documentaciones. La documentación se convierte en una mejor opción para nosotros cuando es mayor la distancia (física o temporal) entre los individuos que nos estamos comunicando.

Figura 2. Comparando la efectividad de los distintos modos de comunicación.
Es importante reconocer que cuando especificamos detalles de cómo se hace algo y luego le pasamos el documento a alguien para que lo siga, hemos logrado efectivamente quitarle toda la gracia a la actividad para esa persona porque hemos hecho el pensamiento por ellos. ¿Cuál sería la motivación para un trabajador intelectual, tal como un profesional TI, de seguir instrucciones detalladas? Nunca olvidemos que los desarrolladores rara vez confían en la documentación, particularmente en la documentación detallada porque usualmente no está sincronizada con el código, así que minimicemos la cantidad de documentación que entregamos.
4.3 Empiece con modelos que realmente estén actualizados
Si hemos elegido mantener nuestro diagrama de despliegue UML, nuestro diagrama de flujo de interfaces y nuestro diagrama físico de datos al día a través del desarrollo, entonces esa es una buena señal de que los modelos de valor deberían ser la base de nuestra documentación. Los modelos desactualizados no dan ningún valor al proyecto.
4.4 Actualice solo cuando duele
En este aspecto, los documentos son solo como modelos, mi recomendación es seguir la práctica “Actualice solo cuando duele”. Los documentos ágiles, al igual que modelos ágiles, deberían ser solo suficientemente buenos. Muchas veces un documento puede estar desactualizado y no importa mucho. Por ejemplo, hay veces que uno trabaja con un manual de referencia de una versión más actual (o más antigua) que el software que se está utilizando, no es la situación ideal, pero no hay tanta diferencia como para que duela debido a que los manuales son relativamente buenos. Serían suficientes los manuales un poco más desactualizados o actualizados (de más de 1 o 2 años de antigüedad)? Probablemente no porque puede que hayan los cambios suficientes para que haya una pérdida de productividad al leer documentación demasiado atrasada y el costo podría ser más grande que el de conseguir manuales al día.


5. Buenas Prácticas Generales
Las siguientes prácticas nos ayudarán a mejorar nuestros esfuerzos de documentación:
1. Trate la documentación como a un requerimiento
2. Requiera o solicite personas que justifiquen los requerimientos de documentación.
3. Reconozca que necesita la documentación.
4. Consiga a alguien con experiencia en escribir documentación.

5.1 Trate la documentación como a un requerimiento
Una filosofía ágil común es tratar la documentación como a cualquier otro requerimiento: debe ser estimado, priorizado y puesto en el stack de ítems de trabajo (ver figura 3) junto con todos los otros ítems de trabajo que debemos realizar. La necesidad de escribir un documento claramente es un requerimiento tal como lo es la necesidad de escribir una característica de la aplicación. Cualquier inversión que hagamos en documentación es una inversión que podríamos haber hecho en una nueva funcionalidad y viceversa, así que alguien debe hacer una decisión a conciencia de cuánto se debe invertir. Al tratar la documentación como un requerimiento hacemos de su creación una decisión visible y explícita para que consideren los stakeholders. Fundamentalmente, la inversión en documentación es una decisión de negocio, no una técnica: no deberíamos crear documentación porque el proceso lo dice sino porque los stakeholders lo dicen.

Figura 3. Administrando el trabajo como un stack priorizado.
5.2 Requiera o solicite personas que justifiquen los requerimientos de documentación
¿La persona que pidió la documentación, sabe lo que está pidiendo y por qué lo está pidiendo, o está pidiéndolo porque se les dijo que lo hicieran? ¿Están los usuarios pidiendo documentación porque fueron plantados por los desarrolladores y ahora piden todo para poder obtener algo? ¿El solicitante entiende las concesiones que se deben hacer para documentar y que la documentación tiene un costo? La experiencia dice que cuando exploramos los temas de documentación con los usuarios, rápidamente se descubre que lo están haciendo porque desconfían de nosotros, ellos a menudo no entienden las implicancias de lo que están pidiendo y a menudo no saben que hay alternativas (por ejemplo, menos documentación). Una buena pregunta a realizar es para qué pretenden usar la documentación y cómo realmente usan la documentación. Cuando hacemos esto, a menudo descubrimos que los usuarios no usan toda la documentación, que más que nada la piden como un seguro o respaldo por escrito. Hay muchas maneras mejores de manejar estos temores que la documentación. Algunos temas importantes:
1. Debemos entender el costo total de propiedad del documento (TCO), y esforzarnos en maximizar el ROI de los stakeholders para proporcionar el mejor valor posible a nuestra organización.
2. Alguien debe elegir explícitamente hacer la inversion de documentar.
3. El beneficio de tener documentación debe ser mayor que el costo de crearla y mantenerla.
4. Preguntarse si NECESITAMOS la documentación o si la queremos.

5.3 Reconozca que necesita la documentación
Algunas observaciones importantes:
1. La Documentación es tan parte del sistema como el código fuente. Además del software en el que trabajamos, probablemente también querremos entregar mínimamente manuales de usuario, documentación de soporte, de operaciones y resúmenes del sistema.
2. La meta principal de tu equipo es desarrollar software, su meta secundaria es permitir nuestro próximo esfuerzo. Sí, la construcción de software que funcione de alta calidad que satisfice las necesidades de los clientes o usuarios es importante, pero asegurar que la gente que viene después de ti, pueda mantenerlo, mejorarlo, operarlo y darle soporte también es importante.
3. La Documentación aún sirve a un propósito. En particular, queremos capturar información de alto nivel en la documentación pero no detalles. Igual querremos capturar información importante permanentemente, y a veces las regulaciones requieren ciertos niveles de documentación.
4. Los Agilistas de hecho están escribiendo documentación. La encuesta DDJ's 2008 Modeling and Documentation enconró que los equipos ágiles fueron muy similares a los equipos tradicionales al escribir documentación entregable, tal como manuales de usuario, documentación de operaciones, etc. La figura 4 resume los resultados de la encuesta pertinente a documentación entregable. Lo importante es que esta encuesta debiera a desmitificar lo que la gente piensa cuando se refiere al desarrollo y documentación de software ágil.


Figura 4. Creación de documentación entregable.
5.4 Consiga a alguien con experiencia en escribir documentación
Los escritores técnicos traen muchas ventajas en lo que respecta a escribir documentación porque ellos saben cómo organizar y presentar la información de manera efectiva. ¿No tiene acceso a un escritor técnico? Aquí hay algunas estrategias:
• Considere leer y seguir algún curso corto de Escritura Técnica para saber los fundamentos.
• Trate de escribir documentación con un compañero, tal como es significativa la programación en pares, hay un valor similar en la documentación en pares.
• Mantenga la documentación compartida para que varias personas puedan trabajar sobre ella.
• Compre software text-to-speech que le permita escuchar lo que ha escrito, es una gran manera de descubrir los pasajes que están pobremente escritos.


ALvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
30 Jun 2020 13:59 #134528 por moderador
Respuesta de moderador sobre el tema Documentos - adquisisciones

stergh escribió: Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

GESTIÓN DE DOCUMENTOS Y DE REGISTROS

INTRODUCCIÓN

Los sistemas de gestión de los documentos y de los registros son fundamentales para el éxito de cualquier proyecto.

Los documentos deben estar disponibles para la llevar a cabo los procesos, las actividades y las tareas que son indispensables para la ejecución del proyecto. Por otra parte los documentos que se generan durante dicha ejecución son denominados registros.

Ambos tipos de documentos deben ser gestionados adecuadamente para que al finalizar el proyecto se pueda disponer de los antecedentes del mismo y mantener su historial de modo de guardar las lecciones aprendidas que permitan aprovecharlas en futuros proyectos de naturaleza similar. En un nivel más amplio, la temática de la gestión de la documentación es parte de la gestión del conocimiento.

Los documentos y los registros pueden estar en soporte papel o en soporte electrónico, así como parcialmente en uno y otro soporte.

Cuanto más grande es un proyecto, más difícil se vuelve el compartir información de manera fluida entre todos los miembros del equipo y con las otras partes interesadas. Esto es particularmente cierto cuando más de una persona trabaja en entregables muy grandes.

Si el Gerente del Proyecto no piensa de forma anticipada en estos procesos, el proyecto finalizará con grandes problemas para localizar información relevante así como frustración al tener que manejar formatos de entregables inconsistentes. Esto probablemente derivará en esfuerzos adicionales para rehacer trabajo que ya se había finalizado.

Sin este tipo de herramientas, sería imposible desarrollar y soportar proyectos grandes de desarrollo de aplicaciones, de modo que no se presente confusión, incertidumbre y trabajo extra durante la ejecución del proyecto. Quizá estas consideraciones son triviales para proyectos pequeños. Para proyectos grandes, estos procesos necesitan planearse de modo anticipado, de lo contrario, se presentara

GESTIÓN DOCUMENTAL

Proyectos pequeños

A menos que el proyecto pequeño sea parte de uno de mayor envergadura o incluso de un programa, no será necesario preocuparse por la gestión documental.

Aun así, el Gerente de Proyecto siempre podrá revisar los aspectos de gestión documental para proyectos más grandes expuestos mas adelante, para tomar de ahí lo que haga sentido de acuerdo al tamaño del proyecto que este conduciendo.

Proyectos medianos y grandes

Aunque los proyectos pequeños experimentan menor cantidad de problemas al gestionar su documentación, algunos de los procesos e infraestructura para la gestión de documentos puede resultar útil para ellos. Por ejemplo, aun un proyecto pequeño necesitará un almacenamiento común o bien una estructura de directorios para almacenar los entregables de proyecto. Cada Gerente de Proyecto puede evaluar su propio proyecto con el fin de identificar aquellas áreas que tenga sentido definir. Asimismo, en esta área hay un componente tecnológico. Si se usa una aplicación la gestión documental, ésta puede facilitar y resolver gran cantidad de las definiciones necesarias y, puede definir incluso, ciertos procedimientos para actualizar la información.

Entre más grande sea el proyecto, mayor rigor y estructura se requiere para manejar los documentos.

Almacenamiento de Documentos

Es necesario decidir en donde serán almacenados los documentos del proyecto. Esto puede ser un directorio en una computadora, una aplicación para la administración de documentos, alguna herramienta de trabajo en grupo, un archivero de documentos físicos, etc.

Herramientas de Documentación

¿Qué herramientas de documentación serán usadas como estándar? Obviamente se recomienda no tener a la mita del equipo trabajando con MS Word® y a la otra mitad usando WordPerfect®. Del mismo modo, todos los miembros del equipo deben usar la misma hoja de cálculo. Si se usa una herramienta para hacer el plan de trabajo del proyecto, todo el que necesite acceso deberá estar habilitado para usar la misma aplicación. Una vez que el software estándar ha sido definido, es importante asegurar que el equipo completo usa la misma versión. En otras palabras, si se está usando MS Office 2000 ®, se debe verificar que todos los usuarios tengan la versión 2000 de Office. Algunas veces, los documentos no podrán ser compartidos si el creador y el lector no usan la misma versión del producto.

Reglas de Acceso

¿Quién tendrá la facultad de acceder a los documentos? ¿Quién los puede actualizar? ¿Quién los podrá leer?




Gestión de los documentos y registros

¿Quién será el responsable de gestionar los documentos y registros? ¿Se realizarán respaldos de la información? En proyectos grandes, esto puede significar un rol de tiempo completo. Aunque alguien con experiencia en trabajo administrativo de oficina puede cubrir muy bien esta función. Las responsabilidades de los bibliotecarios son las siguientes:

Coordinar la actividad alrededor de la gestión documental.
Establecer, mantener y reforzar los procedimientos de almacenamiento de documentación y dar seguimiento al cumplimiento de éstos.
Identificar / resolver problemas con el almacenamiento .
Verificar / controlar el acceso y actualizaciones al almacenamiento
Determinar cuando es necesario respaldar documentos viejos y depurarlos.

Organización / física y lógica del almacenamiento

¿Cuál es la organización más conveniente para el almacenamiento ? Se recomienda que primero se haga un esquema de la vista lógica de la estructura. Después es necesario determinar la forma en que este diseño lógico se pueda implementar en un directorio o herramienta. La estructura debe ser tal que sea fácil de entender y fácil y práctica para buscar y encontrar información relevante.

Indexación / palabras clave

En función de la tecnología del almacenamiento, puede ser posible buscar documentos. La búsqueda de documentos normalmente puede ser hecha usando el nombre del documento (lo que hace más importante el uso de estándares de nomenclatura de documentos) o bien por palabra clave. Las palabras clave son palabras descriptivas asociadas al documento de tal forma que se pueda encontrar rápidamente el documento buscado, especialmente cuando no se está seguro del nombre del mismo o bien en donde se localiza.

Las capacidades de búsqueda y de definición de palabras clave, deben establecerse de antemano. Algunos ejemplos de un esquema de indexación básica de documentos incluiría el título del documento, el tema, el autor, persona de contacto, fecha de envío y una lista de palabras clave. Por supuesto, al finalizar lo anterior, el documento deberá ser agregado al almacenamiento ; al concluir, el documento podrá ser buscado, usando cualquiera de las palabras clave o vía la indexación.

Codificación de archivos

Después de que la estructura de archivos ha sido establecida, será necesario definir los estándares de nombramiento de los archivos. Esto evitará que la información sea mal clasificada o almacenada en el lugar incorrecto. Por ejemplo, dentro de la carpeta de reportes de estado, la convención de nombramiento de archivos puede ser “20001201 Juan García Reporte de estado”. En este esquema, todos los reportes de estado de un periodo estarán agrupados.

Por otra parte “Juan García Reporte de estado 200011201” ordenará los reportes por persona. El Gerente de Proyecto y el bibliotecario asegurarán que todo el mundo está usando el estándar de nombramiento. Aunque este ejercicio puede resultar tedioso, esta práctica de trabajo puede resultar muy valiosa cuando el equipo de proyecto produce cientos de documentos al paso del tiempo.

Manejo de Versiones

¿Los documentos anteriores serán conservados si éstos son actualizados o solo la versión más actual será almacenada? Gran cantidad de documentos, como la definición de proyecto, deberá tener todas las versiones aprobadas guardadas. Para estos documentos, el nombre de archivo deberá incluir un tipo de número de versión, por ejemplo, “Definición de Proyecto ABC v1”. Con este tipo de convención en el nombramiento del archivo, será relativamente fácil asegurar que todos estarán consultando la versión mas reciente.

Estado del documento

Cuando los documentos necesitan ser aprobados, y especialmente si el proceso de aprobación tiende a ser largo y sinuoso, es importante señalar que estado de aprobación tiene el documento. Por ejemplo, es importante saber si el entregable que se está consultando es una versión final aprobada, o un borrador. Al definir bibliotecas separadas para documentos que están en proceso de autorización, se puede manejar muy bien esta distinción.

Los estados típicos de un documento son: “Borrador”, “Esperando aprobación” y “Aprobado”. Cuando un documento es creado, estará en estado de borrador. Cuando el documento está circulando para obtener retroalimentación y/o aprobación, éste se mueve a la carpeta denominada “esperando aprobación” y finalmente, cuando el documento es finalmente aprobado, se deberá colocar en la carpeta “aprobado”. Otro proceso es colocar en una carpeta los documentos “no aprobados” y los documentos “aprobados” se almacenan en una base de datos de entregables aprobados.

Retención / Eliminación

Asegura que la información en el almacenamiento es relevante. Por ejemplo, los Repostes de Estado Semanal pueden no ser necesarios después de tres meses; pero por otra parte, el documento Definición del Proyecto será necesario, aun después de 12 meses de haber sido generado. Periódicamente durante el proyecto, el bibliotecario puede respaldar cualquier información que deje de ser relevante y eliminar los documentos del almacenamiento .




Respaldos

Si el almacenamiento de documentos no es respaldado de forma automática, el Gerente de Proyecto necesita incluir actividades de este tipo en el plan de trabajo, de modo que se asegure que el respaldo se ejecute. Si procesos fuera de línea están respaldando el almacenamiento , es necesario cerciorarse de la disponibilidad del respaldo, en caso de que sea necesario recuperar información. También es necesario registrar en donde se conservará el respaldo y por cuanto tiempo. Al menos una copia recuperable del respaldo debería conservarse fuera de sitio en caso de desastre.

Formato estándar de documentación

Es más fácil en el largo plazo leer y crear documentos si todos siguen un formato y plantilla estándar. Por ejemplo, el equipo de proyecto debería acordar un estándar de tipo de fuente y tamaño de letra a ser usado en todos los documentos. Adicionalmente, encabezados y pies de página estándares, carátulas y tablas de contenidos. Esto dará a toda la documentación una imagen estándar.

Revisión periódica del almacenamiento

En caso de que el proyecto sea muy grande y el Almacenamiento de Documentos es muy complicado, podría tener sentido conducir revisiones periódicas para revisar el almacenamiento y los procesos generales de gestión documental. El bibliotecario será responsable de coordinar esta revisión.

Durante ésta se puede verificar lo siguiente:

El almacenamiento se está respaldando y depurando de manera apropiada
La documentación se está colocando en el lugar correcto
Los documentos son indexados y categorizados apropiadamente, de modo que sean fácilmente accesibles cuando sea necesario.
Los documentos son agregados de forma continua, o por lo menos al final de cada fase mayor.

Procedimiento de actualización del almacenamiento

El Gerente de Proyecto tiene que decidir si el acceso de actualización al almacenamiento será controlado o bien, si todo el equipo de trabajo tendrá privilegios para actualizar información en éste. Si todos tienen esta capacidad, existirá la tendencia de degradar la consistencia y calidad de la información. Sí el acceso es controlado, entonces solo el bibliotecario y el proceso de respaldo podrán actualizar o agregar documentos. Un proceso que soporta lo anterior es:

Los miembros del equipo envían los documentos al bibliotecario cuando éstos hayan obtenido la aprobación final, o bien al final de cada fase y al final del proyecto. El equipo de trabajo usa un formato de requisición para el bibliotecario, en donde se describa el entregable, las palabras clave, la fecha de aprobación, la carpeta en donde se encuentra, la versión, etc...

El bibliotecario se asegura que el formato es apropiado para el almacenamiento y que se apega a los estándares definidos. En caso de que no se cumplan estas condiciones, el documento es regresado al equipo de trabajo para que sea corregido.

Si el documento es relevante y cumple con los estándares definidos, el bibliotecario lo coloca en la carpeta que le corresponda y actualiza cualquier otra información requerida. El bibliotecario usa la información del formato de requisición para determinar el lugar en donde éste tendrá que ser almacenado.



Alvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
30 Jun 2020 13:58 #134527 por moderador
Respuesta de moderador sobre el tema Documentos - adquisisciones

moderador escribió:

moderador escribió:

stergh escribió: Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

´
Unas líneas estimada stergh al respecto.
Debemos tener una cultura de gestión de los documentos recordando que son auxiliares, que nos permiten desarrollar los procesos de gestión del proyecto y no un fin en sí mismo!!
Alvaro

DOCUMENTOS DE ADQUISICIONES (DOCUMENTOS DE LICITACIÓN)
Una vez que se selecciona el tipo de contrato y se haya creado el Enunciado del Trabajo Relativo a las Adquisiciones, el comprador puede juntarlos en el documento de adquisiciones, el cual describe sus necesidades al proveedor. Los siguientes son algunos de los diferentes tipos de documentos de adquisiciones:
- Solicitud de Propuesta (RFP, algunas veces llamado Solicitud de Oferta): La RFP solicita una propuesta detallada sobre cómo se logrará el trabajo, quién lo hará, experiencia de la compañía, precio, etc.
- Invitación a Licitación (IFB, o Solicitud de Licitación, RFB): Usualmente la IFB sólo solicita un precio total para hacer todo el trabajo.
- Solicitud de presupuesto (RFQ): Una RFQ solicita un presupuesto de precios por artículo, hora, metro, u otra unidad de medida.
Nota: La Guía del PMBOK® menciona la Solicitud de Información (RFI) como uno de los tipos de documentos de adquisiciones, pero en realidad, esto no pertenece a esta categoría. Un documento de adquisiciones es un intento de adquirir algo, mientras que una RFI simplemente busca información. Una RFI podría ser usada antes de crear los documentos de adquisiciones. La información recibida podría ayudar a identificar empresas calificadas para enviar un RFP o una IFB. Además una RFI podría ser usada para recopilar información sobre qué trabajo es posible realizar para una posterior inclusión en una RFP o IFB. Recuerde que el propósito de una RFI es obtener información, mientras que el propósito de un documento de adquisiciones (por ejemplo: RFP, IFB y RFQ) es comprar algo.
Para proporcionar al proveedor una imagen lo más clara posible de lo que hay que hacer para ganar el trabajo y lo que implica el trabajo, los documentos de adquisiciones podrían incluir lo siguiente:
- Información para los proveedores:
- Información de antecedentes sobre por qué el comprador quiere realizar el trabajo.
-Procedimientos para tratar de ganar el trabajo (si habrá una Conferencia de Oferentes, cuándo se les responderá, cómo se seleccionará al ganador, etc.).
- Guías para la preparación de respuesta (longitud máxima, temas a abordar en la respuesta, etc.).
- La forma exacta que debe tener la respuesta (formularios para llenar, si se permite envíos por email, etc.).
- Criterios de selección de fuente – el criterio que utilizará el comprador para evaluar las respuestas de los proveedores (cantidad de años que está en el negocio, calidad de la respuesta, precio, etc.).
- Formas de precios (formas para describir adecuadamente el precio al comprador).
- Enunciado del Trabajo Relativo a las Adquisiciones.
- Términos y condiciones propuestas en el contrato (legales y del negocio).
Noten que el contrato propuesto está incluido en los documentos de adquisiciones. ¿Saben por qué? Es debido a que los términos y condiciones del contrato también son trabajos que deben ser realizados y tienen costos asociados a éstos (garantías, costo de propiedad, etc.). El proveedor debe ser consciente de todo el trabajo que se debe completar para entender y valorizar adecuadamente el proyecto.
Los documentos de adquisiciones bien diseñados pueden tener los siguientes efectos en el proyecto:
- Comparar las respuestas de los proveedores se hace más fácil.
- Respuestas más completas.
- Precios más exactos.
- El número de cambios al proyecto disminuye.
Una vez que hayan revisado los documentos, los proveedores pueden sugerir cambios a los documentos de adquisiciones, incluyendo al Enunciado del Trabajo Relativo a las Adquisiciones y a los requisitos de gestión del proyecto contenidos en los documentos, antes de firmar el contrato. Cuando se aprueben, estos cambios son publicados por el comprador como adiciones (adendas) a los documentos de las adquisiciones.


Alvaro

INTRODUCCIÓN

Los sistemas de gestión de los documentos y de los registros son fundamentales para el éxito de cualquier proyecto.

Los documentos deben estar disponibles para la llevar a cabo los procesos, las actividades y las tareas que son indispensables para la ejecución del proyecto. Por otra parte los documentos que se generan durante dicha ejecución son denominados registros.

Ambos tipos de documentos deben ser gestionados adecuadamente para que al finalizar el proyecto se pueda disponer de los antecedentes del mismo y mantener su historial de modo de guardar las lecciones aprendidas que permitan aprovecharlas en futuros proyectos de naturaleza similar. En un nivel más amplio, la temática de la gestión de la documentación es parte de la gestión del conocimiento.

Los documentos y los registros pueden estar en soporte papel o en soporte electrónico, así como parcialmente en uno y otro soporte.

Cuanto más grande es un proyecto, más difícil se vuelve el compartir información de manera fluida entre todos los miembros del equipo y con las otras partes interesadas. Esto es particularmente cierto cuando más de una persona trabaja en entregables muy grandes.

Si el Gerente del Proyecto no piensa de forma anticipada en estos procesos, el proyecto finalizará con grandes problemas para localizar información relevante así como frustración al tener que manejar formatos de entregables inconsistentes. Esto probablemente derivará en esfuerzos adicionales para rehacer trabajo que ya se había finalizado.

Sin este tipo de herramientas, sería imposible desarrollar y soportar proyectos grandes de desarrollo de aplicaciones, de modo que no se presente confusión, incertidumbre y trabajo extra durante la ejecución del proyecto. Quizá estas consideraciones son triviales para proyectos pequeños. Para proyectos grandes, estos procesos necesitan planearse de modo anticipado, de lo contrario, se presentara

GESTIÓN DOCUMENTAL

Proyectos pequeños

A menos que el proyecto pequeño sea parte de uno de mayor envergadura o incluso de un programa, no será necesario preocuparse por la gestión documental.

Aun así, el Gerente de Proyecto siempre podrá revisar los aspectos de gestión documental para proyectos más grandes expuestos mas adelante, para tomar de ahí lo que haga sentido de acuerdo al tamaño del proyecto que este conduciendo.

Proyectos medianos y grandes

Aunque los proyectos pequeños experimentan menor cantidad de problemas al gestionar su documentación, algunos de los procesos e infraestructura para la gestión de documentos puede resultar útil para ellos. Por ejemplo, aun un proyecto pequeño necesitará un almacenamiento común o bien una estructura de directorios para almacenar los entregables de proyecto. Cada Gerente de Proyecto puede evaluar su propio proyecto con el fin de identificar aquellas áreas que tenga sentido definir. Asimismo, en esta área hay un componente tecnológico. Si se usa una aplicación la gestión documental, ésta puede facilitar y resolver gran cantidad de las definiciones necesarias y, puede definir incluso, ciertos procedimientos para actualizar la información.

Entre más grande sea el proyecto, mayor rigor y estructura se requiere para manejar los documentos.

Almacenamiento de Documentos

Es necesario decidir en donde serán almacenados los documentos del proyecto. Esto puede ser un directorio en una computadora, una aplicación para la administración de documentos, alguna herramienta de trabajo en grupo, un archivero de documentos físicos, etc.

Herramientas de Documentación

¿Qué herramientas de documentación serán usadas como estándar? Obviamente se recomienda no tener a la mita del equipo trabajando con MS Word® y a la otra mitad usando WordPerfect®. Del mismo modo, todos los miembros del equipo deben usar la misma hoja de cálculo. Si se usa una herramienta para hacer el plan de trabajo del proyecto, todo el que necesite acceso deberá estar habilitado para usar la misma aplicación. Una vez que el software estándar ha sido definido, es importante asegurar que el equipo completo usa la misma versión. En otras palabras, si se está usando MS Office 2000 ®, se debe verificar que todos los usuarios tengan la versión 2000 de Office. Algunas veces, los documentos no podrán ser compartidos si el creador y el lector no usan la misma versión del producto.

Reglas de Acceso

¿Quién tendrá la facultad de acceder a los documentos? ¿Quién los puede actualizar? ¿Quién los podrá leer?




Gestión de los documentos y registros

¿Quién será el responsable de gestionar los documentos y registros? ¿Se realizarán respaldos de la información? En proyectos grandes, esto puede significar un rol de tiempo completo. Aunque alguien con experiencia en trabajo administrativo de oficina puede cubrir muy bien esta función. Las responsabilidades de los bibliotecarios son las siguientes:

Coordinar la actividad alrededor de la gestión documental.
Establecer, mantener y reforzar los procedimientos de almacenamiento de documentación y dar seguimiento al cumplimiento de éstos.
Identificar / resolver problemas con el almacenamiento .
Verificar / controlar el acceso y actualizaciones al almacenamiento
Determinar cuando es necesario respaldar documentos viejos y depurarlos.

Organización / física y lógica del almacenamiento

¿Cuál es la organización más conveniente para el almacenamiento ? Se recomienda que primero se haga un esquema de la vista lógica de la estructura. Después es necesario determinar la forma en que este diseño lógico se pueda implementar en un directorio o herramienta. La estructura debe ser tal que sea fácil de entender y fácil y práctica para buscar y encontrar información relevante.

Indexación / palabras clave

En función de la tecnología del almacenamiento, puede ser posible buscar documentos. La búsqueda de documentos normalmente puede ser hecha usando el nombre del documento (lo que hace más importante el uso de estándares de nomenclatura de documentos) o bien por palabra clave. Las palabras clave son palabras descriptivas asociadas al documento de tal forma que se pueda encontrar rápidamente el documento buscado, especialmente cuando no se está seguro del nombre del mismo o bien en donde se localiza.

Las capacidades de búsqueda y de definición de palabras clave, deben establecerse de antemano. Algunos ejemplos de un esquema de indexación básica de documentos incluiría el título del documento, el tema, el autor, persona de contacto, fecha de envío y una lista de palabras clave. Por supuesto, al finalizar lo anterior, el documento deberá ser agregado al almacenamiento ; al concluir, el documento podrá ser buscado, usando cualquiera de las palabras clave o vía la indexación.

Codificación de archivos

Después de que la estructura de archivos ha sido establecida, será necesario definir los estándares de nombramiento de los archivos. Esto evitará que la información sea mal clasificada o almacenada en el lugar incorrecto. Por ejemplo, dentro de la carpeta de reportes de estado, la convención de nombramiento de archivos puede ser “20001201 Juan García Reporte de estado”. En este esquema, todos los reportes de estado de un periodo estarán agrupados.

Por otra parte “Juan García Reporte de estado 200011201” ordenará los reportes por persona. El Gerente de Proyecto y el bibliotecario asegurarán que todo el mundo está usando el estándar de nombramiento. Aunque este ejercicio puede resultar tedioso, esta práctica de trabajo puede resultar muy valiosa cuando el equipo de proyecto produce cientos de documentos al paso del tiempo.

Manejo de Versiones

¿Los documentos anteriores serán conservados si éstos son actualizados o solo la versión más actual será almacenada? Gran cantidad de documentos, como la definición de proyecto, deberá tener todas las versiones aprobadas guardadas. Para estos documentos, el nombre de archivo deberá incluir un tipo de número de versión, por ejemplo, “Definición de Proyecto ABC v1”. Con este tipo de convención en el nombramiento del archivo, será relativamente fácil asegurar que todos estarán consultando la versión mas reciente.

Estado del documento

Cuando los documentos necesitan ser aprobados, y especialmente si el proceso de aprobación tiende a ser largo y sinuoso, es importante señalar que estado de aprobación tiene el documento. Por ejemplo, es importante saber si el entregable que se está consultando es una versión final aprobada, o un borrador. Al definir bibliotecas separadas para documentos que están en proceso de autorización, se puede manejar muy bien esta distinción.

Los estados típicos de un documento son: “Borrador”, “Esperando aprobación” y “Aprobado”. Cuando un documento es creado, estará en estado de borrador. Cuando el documento está circulando para obtener retroalimentación y/o aprobación, éste se mueve a la carpeta denominada “esperando aprobación” y finalmente, cuando el documento es finalmente aprobado, se deberá colocar en la carpeta “aprobado”. Otro proceso es colocar en una carpeta los documentos “no aprobados” y los documentos “aprobados” se almacenan en una base de datos de entregables aprobados.

Retención / Eliminación

Asegura que la información en el almacenamiento es relevante. Por ejemplo, los Repostes de Estado Semanal pueden no ser necesarios después de tres meses; pero por otra parte, el documento Definición del Proyecto será necesario, aun después de 12 meses de haber sido generado. Periódicamente durante el proyecto, el bibliotecario puede respaldar cualquier información que deje de ser relevante y eliminar los documentos del almacenamiento .




Respaldos

Si el almacenamiento de documentos no es respaldado de forma automática, el Gerente de Proyecto necesita incluir actividades de este tipo en el plan de trabajo, de modo que se asegure que el respaldo se ejecute. Si procesos fuera de línea están respaldando el almacenamiento , es necesario cerciorarse de la disponibilidad del respaldo, en caso de que sea necesario recuperar información. También es necesario registrar en donde se conservará el respaldo y por cuanto tiempo. Al menos una copia recuperable del respaldo debería conservarse fuera de sitio en caso de desastre.

Formato estándar de documentación

Es más fácil en el largo plazo leer y crear documentos si todos siguen un formato y plantilla estándar. Por ejemplo, el equipo de proyecto debería acordar un estándar de tipo de fuente y tamaño de letra a ser usado en todos los documentos. Adicionalmente, encabezados y pies de página estándares, carátulas y tablas de contenidos. Esto dará a toda la documentación una imagen estándar.

Revisión periódica del almacenamiento

En caso de que el proyecto sea muy grande y el Almacenamiento de Documentos es muy complicado, podría tener sentido conducir revisiones periódicas para revisar el almacenamiento y los procesos generales de gestión documental. El bibliotecario será responsable de coordinar esta revisión.

Durante ésta se puede verificar lo siguiente:

El almacenamiento se está respaldando y depurando de manera apropiada
La documentación se está colocando en el lugar correcto
Los documentos son indexados y categorizados apropiadamente, de modo que sean fácilmente accesibles cuando sea necesario.
Los documentos son agregados de forma continua, o por lo menos al final de cada fase mayor.

Procedimiento de actualización del almacenamiento

El Gerente de Proyecto tiene que decidir si el acceso de actualización al almacenamiento será controlado o bien, si todo el equipo de trabajo tendrá privilegios para actualizar información en éste. Si todos tienen esta capacidad, existirá la tendencia de degradar la consistencia y calidad de la información. Sí el acceso es controlado, entonces solo el bibliotecario y el proceso de respaldo podrán actualizar o agregar documentos. Un proceso que soporta lo anterior es:

Los miembros del equipo envían los documentos al bibliotecario cuando éstos hayan obtenido la aprobación final, o bien al final de cada fase y al final del proyecto. El equipo de trabajo usa un formato de requisición para el bibliotecario, en donde se describa el entregable, las palabras clave, la fecha de aprobación, la carpeta en donde se encuentra, la versión, etc...

El bibliotecario se asegura que el formato es apropiado para el almacenamiento y que se apega a los estándares definidos. En caso de que no se cumplan estas condiciones, el documento es regresado al equipo de trabajo para que sea corregido.

Si el documento es relevante y cumple con los estándares definidos, el bibliotecario lo coloca en la carpeta que le corresponda y actualiza cualquier otra información requerida. El bibliotecario usa la información del formato de requisición para determinar el lugar en donde éste tendrá que ser almacenado.




Alvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
30 Jun 2020 13:57 #134526 por moderador
Respuesta de moderador sobre el tema Documentos - adquisisciones

moderador escribió:

stergh escribió: Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

´
Unas líneas estimada stergh al respecto.
Debemos tener una cultura de gestión de los documentos recordando que son auxiliares, que nos permiten desarrollar los procesos de gestión del proyecto y no un fin en sí mismo!!
Alvaro

DOCUMENTOS DE ADQUISICIONES (DOCUMENTOS DE LICITACIÓN)
Una vez que se selecciona el tipo de contrato y se haya creado el Enunciado del Trabajo Relativo a las Adquisiciones, el comprador puede juntarlos en el documento de adquisiciones, el cual describe sus necesidades al proveedor. Los siguientes son algunos de los diferentes tipos de documentos de adquisiciones:
- Solicitud de Propuesta (RFP, algunas veces llamado Solicitud de Oferta): La RFP solicita una propuesta detallada sobre cómo se logrará el trabajo, quién lo hará, experiencia de la compañía, precio, etc.
- Invitación a Licitación (IFB, o Solicitud de Licitación, RFB): Usualmente la IFB sólo solicita un precio total para hacer todo el trabajo.
- Solicitud de presupuesto (RFQ): Una RFQ solicita un presupuesto de precios por artículo, hora, metro, u otra unidad de medida.
Nota: La Guía del PMBOK® menciona la Solicitud de Información (RFI) como uno de los tipos de documentos de adquisiciones, pero en realidad, esto no pertenece a esta categoría. Un documento de adquisiciones es un intento de adquirir algo, mientras que una RFI simplemente busca información. Una RFI podría ser usada antes de crear los documentos de adquisiciones. La información recibida podría ayudar a identificar empresas calificadas para enviar un RFP o una IFB. Además una RFI podría ser usada para recopilar información sobre qué trabajo es posible realizar para una posterior inclusión en una RFP o IFB. Recuerde que el propósito de una RFI es obtener información, mientras que el propósito de un documento de adquisiciones (por ejemplo: RFP, IFB y RFQ) es comprar algo.
Para proporcionar al proveedor una imagen lo más clara posible de lo que hay que hacer para ganar el trabajo y lo que implica el trabajo, los documentos de adquisiciones podrían incluir lo siguiente:
- Información para los proveedores:
- Información de antecedentes sobre por qué el comprador quiere realizar el trabajo.
-Procedimientos para tratar de ganar el trabajo (si habrá una Conferencia de Oferentes, cuándo se les responderá, cómo se seleccionará al ganador, etc.).
- Guías para la preparación de respuesta (longitud máxima, temas a abordar en la respuesta, etc.).
- La forma exacta que debe tener la respuesta (formularios para llenar, si se permite envíos por email, etc.).
- Criterios de selección de fuente – el criterio que utilizará el comprador para evaluar las respuestas de los proveedores (cantidad de años que está en el negocio, calidad de la respuesta, precio, etc.).
- Formas de precios (formas para describir adecuadamente el precio al comprador).
- Enunciado del Trabajo Relativo a las Adquisiciones.
- Términos y condiciones propuestas en el contrato (legales y del negocio).
Noten que el contrato propuesto está incluido en los documentos de adquisiciones. ¿Saben por qué? Es debido a que los términos y condiciones del contrato también son trabajos que deben ser realizados y tienen costos asociados a éstos (garantías, costo de propiedad, etc.). El proveedor debe ser consciente de todo el trabajo que se debe completar para entender y valorizar adecuadamente el proyecto.
Los documentos de adquisiciones bien diseñados pueden tener los siguientes efectos en el proyecto:
- Comparar las respuestas de los proveedores se hace más fácil.
- Respuestas más completas.
- Precios más exactos.
- El número de cambios al proyecto disminuye.
Una vez que hayan revisado los documentos, los proveedores pueden sugerir cambios a los documentos de adquisiciones, incluyendo al Enunciado del Trabajo Relativo a las Adquisiciones y a los requisitos de gestión del proyecto contenidos en los documentos, antes de firmar el contrato. Cuando se aprueben, estos cambios son publicados por el comprador como adiciones (adendas) a los documentos de las adquisiciones.


Alvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
30 Jun 2020 13:55 #134525 por moderador
Respuesta de moderador sobre el tema Documentos - adquisisciones

stergh escribió: Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

´
Unas líneas estimada stergh al respecto.
Debemos tener una cultura de gestión de los documentos recordando que son auxiliares, que nos permiten desarrollar los procesos de gestión del proyecto y no un fin en sí mismo!!
Alvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
30 Jun 2020 01:53 #134500 por stergh
Tener claro las caracteristicas de cada documento facilita el proceso,
y saber tratar cada documento/proceso/ tipo de proveedor tambien es importante, me refiero; en mi pais existe todo un protocolo para aplicar una licitacion, procesos cortos para cotizaciones pero cual sea el proceso he notado que una de las debilidades es la falta de compromiso que tienen los proveedores sin duda trabajar con habilidad la negociacion para lograr el compromiso de los mismos es indispensable ya que en caso de fallo de compromiso con la entrega de materiales por ejemplo se pone en riesgo el tiempo, calidad y costo de cualquier proyecto

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Tiempo de carga de la página: 0.144 segundos