Nuestra empresa espera participar en licitaciones a nivel de capital provincial. ¿Qué cualificaciones necesita la empresa?

Describe la estructura organizativa del equipo del proyecto. La estructura organizativa de un proyecto se puede describir en términos de roles requeridos y miembros del proyecto. Los roles requeridos se describen principalmente para completar las tareas de este proyecto y los roles que deben componer el equipo del proyecto, como gerente de proyecto, gerente de proyecto, analista de sistemas (o equipo), diseñador de arquitectura, equipo de diseño, equipo de programación, equipo de pruebas, etc. La estructura organizativa se puede representar gráficamente, ya sea como un diagrama de árbol o como un diagrama matricial, e indicar de qué departamentos provienen los miembros del equipo. Además de los gráficos, utilice texto para describir brevemente el nivel de habilidad esperado de cada personaje.

Tenga en cuenta que, si bien existen algunas estructuras generales que se pueden aplicar, la estructura organizativa no es la misma para varios proyectos de diferentes tamaños y formatos. Por ejemplo, un proyecto de desarrollo de productos puede no requerir personal de implementación (equipos), pero sí personal de transferencia de conocimientos (equipos). Los proyectos de subcontratación de codificación de software no requieren programadores y los evaluadores se pueden reducir adecuadamente.

3.2 División del trabajo

Determinar qué papel tiene cada miembro del equipo del proyecto en la estructura organizacional, su nivel de habilidades y su división del trabajo y configuración en el proyecto. realizarse de acuerdo con el proyecto. La estructura organizativa real se describe en forma de lista. A continuación se muestra un ejemplo.

3.3 Colaboración y comunicación

La comunicación y colaboración en el proyecto debe determinar primero los objetos de colaboración y comunicación, es decir, con quién colaborar y comunicarse. Los objetivos de comunicación deben incluir a todas las partes interesadas del proyecto, es decir, a todos los miembros del equipo del proyecto, las interfaces del proyecto, las partes interesadas externas del equipo del proyecto, etc.

En segundo lugar, se deben determinar los métodos de colaboración y comunicación. Los métodos de comunicación incluyen reuniones, llamadas telefónicas, QQ, correos electrónicos internos, correos electrónicos externos, Quickplace, salas de chat, etc. Entre ellos, la comunicación por correo electrónico debe indicar el remitente principal y la persona copia, y el método de comunicación de la sala de chat debe acordar un período de tiempo. El método de colaboración describe principalmente qué medidas debe tomar cada rol (activamente) bajo qué circunstancias, incluida la comunicación y cómo cooperar entre sí para completar una determinada tarea. La comunicación regular generalmente incluye informes de la fase del proyecto, planes de la fase del proyecto, reuniones de la fase, etc.

3.3.1 Colaboración dentro del equipo del proyecto

Esta sección presenta el modelo de colaboración y los métodos de comunicación, la frecuencia de la comunicación, los métodos de registro de resultados de la comunicación, etc. dentro del equipo del proyecto durante el proceso de desarrollo. .

3.3.1 Colaboración dentro del equipo del proyecto

Esta sección presenta el modelo de colaboración y los métodos de comunicación dentro del equipo del proyecto durante el proceso de desarrollo.

3.3.2 Personal de atraque del proyecto

Se debe explicar el contenido del trabajo del personal de atraque, es decir, sus responsabilidades, información de contacto, métodos de comunicación, métodos de colaboración, etc., incluyendo :

a. Personal responsable de la conexión entre proyectos y usuarios;

b. Personal responsable de la conexión entre proyectos y diversas agencias de gestión de la empresa, como gestión de planificación, contrato. gestión, adquisiciones, gestión de calidad, finanzas, etc. Para la interfaz con el proyecto, el equipo del proyecto debe ser responsable del desarrollo con el equipo del proyecto, el equipo del proyecto debe ser responsable del desarrollo con el equipo del proyecto, el equipo del proyecto debe ser responsable del desarrollo con el equipo del proyecto y el equipo del proyecto debe ser responsable del desarrollo con el equipo del proyecto.

b. Responsable de la conexión entre el proyecto y varias agencias de gestión de la empresa, como gestión de planificación, gestión de contratos, adquisiciones, gestión de calidad y departamentos financieros.

c. Responsable del personal de atraque del proyecto y subcontratas.

3.3.3 Modelo de comunicación y colaboración externa del equipo del proyecto

El exterior del equipo del proyecto incluye el departamento de asistencia a la gestión interna de la empresa, la unidad encargada del proyecto, los clientes, etc. . Esta sección presenta el modelo de comunicación y colaboración del equipo del proyecto durante el proceso de desarrollo del proyecto. Esta sección presenta los métodos de comunicación y la frecuencia del equipo del proyecto con el personal de atraque y los clientes durante el proceso de desarrollo del proyecto, el método de presentación de resultados de la comunicación, etc. Identifique los nombres y números de contacto de los usuarios finales, usuarios directos y sus organizaciones/departamentos. Aclarar el nombre del departamento de desarrollo colaborativo, el nombre del responsable, el contenido del trabajo realizado, así como el nombre y número de contacto del responsable de la ejecución del trabajo. Determinar el nombre de la unidad cooperativa correspondiente, el nombre del responsable, el contenido del trabajo realizado, así como el nombre y número de contacto del responsable del trabajo de implementación.

4 Plan de Implementación

4.1 Evaluación de Riesgos y Contramedidas

Determinar o predecir los riesgos que pueden surgir durante la implementación del proyecto. Se debe analizar la probabilidad (probabilidad) del riesgo, su impacto, las contramedidas que se deben tomar en función del impacto y las medidas a tomar. La identificación de riesgos incluye la identificación de riesgos internos y externos. Los riesgos inherentes son riesgos que el equipo del proyecto puede controlar e influir, como los nombramientos de personal y las estimaciones de costos. Los riesgos externos se refieren a riesgos que están más allá del control y la influencia del grupo de trabajo del proyecto, como cambios de mercado o acciones gubernamentales, alianzas de directores de proyectos, problemas de gestión de proyectos, etc.

Las contramedidas de riesgo incluyen: evitar: eliminar amenazas específicas a menudo depende de eliminar el origen del peligro; mitigar: reducir la inversión financiera esperada en eventos de riesgo para reducir la probabilidad de que ocurra el riesgo y reducir el coeficiente de riesgo; Absorción: Aceptar todas las consecuencias, que pueden ser positivas (como desarrollar planes de prevención para evitar que ocurran eventos de riesgo) o negativas (como aceptar ganancias inferiores a las esperadas debido a ciertos sobrecostos).

Para proyectos de desarrollo de software, invertir suficiente tiempo y mano de obra en el análisis, la identificación y la gestión de riesgos puede hacer que el proyecto avance más fluidamente, mejorar el seguimiento y el control del proyecto y ayudar a resolver los problemas antes de que ocurran. Por lo tanto, tiene más confianza en el éxito del proyecto.

Riesgos de predicción comunes en proyectos de desarrollo de software:

1) Riesgo de ingeniería/escala/cronograma

Si la escala es grande, la estimación de la escala será inexacta. o incluso mayor error en términos de escala, los usuarios son muy estrictos con los requisitos de tiempo de entrega y los costos de trabajo inesperado (trabajo de respuesta en el sitio cuando las pruebas no se completan, etc.); Riesgos técnicos

Los proyectos pueden tener más éxito utilizando nuevas técnicas de desarrollo, nuevos equipos, etc. No hay experiencia en tecnologías recientemente desarrolladas, nuevos equipos, etc., o nuevas aplicaciones combinadas; es una nueva industria o negocio, y no hay experiencia en requisitos de rendimiento muy estrictos;

3) Problemas del sistema del usuario

Pérdida de control de los usuarios, preocupación de que la toma de decisiones y aceptación de funciones no se complete sin problemas (o retrasada) o preocupación de que las funciones se cambien muchas veces, preocupación; que los proyectos se retrasarán (o retrasarán (o retrasarán a los usuarios) o puede haber retrasos en el trabajo realizado por otras organizaciones relevantes;

4) Otros: deben incluir proyectos no incluidos aquí pero que sí lo estén; Se especula que tiene riesgos.

Artículo 4.2 Workflow Project Manager Alliance para una discusión en profundidad.

Describe qué flujo de trabajo se utilizará para el proyecto. Por ejemplo, flujo de trabajo en cascada, flujo de trabajo de creación de prototipos, flujo de trabajo en espiral, flujo de trabajo iterativo o puede crear su propio flujo de trabajo. Diferentes procesos afectarán la formulación de planes de trabajo posteriores. Si es necesario, dibuje un diagrama de flujo de trabajo y proporcione una descripción escrita adecuada del flujo de trabajo utilizado en este proyecto.

4.3 Plan general

El plan general mencionado aquí es un plan de alto nivel. Debe complementarse con planos para cada fase del proyecto, que no están incluidos en este documento pero que se basan en este plan maestro.

El cronograma general debe determinar la lista de etapas del proyecto, el cronograma de etapas y los resultados de las etapas que se presentarán en cada etapa en función de la escala del proyecto. En el cronograma de etapas, el estado de finalización de los resultados de la etapa del proyecto y la presentación para. Se debe tener en cuenta el tiempo de revisión y modificación.

Para planificación de proyectos, preparación de proyectos, investigación de demanda, análisis de demanda, diseño de arquitectura o diseño de esquema, codificación, pruebas, entrega, capacitación interna, capacitación de usuarios, instalación e implementación, depuración, aceptación, etc., es necesario proporcionar La fecha de inicio programada, la fecha de finalización y los recursos requeridos de cada tarea de trabajo. La finalización de cada tarea de trabajo debe definir claramente el orden en que se completan las tareas de trabajo, la representación de la finalización de las tareas de trabajo y el. eventos hitos (hitos) de cada tarea laboral. Hitos para cada tarea laboral.

Por ejemplo

Revisión de requisitos

Los artículos de Project Manager Alliance explican cosas sencillas y en profundidad.

Revisión del diseño

La división de fases de los puntos de control/hitos en la tabla es solo un ejemplo. La división de fases, los resultados de las fases, etc. en las operaciones reales deben determinarse de acuerdo con las necesidades del proyecto. .

Se pueden utilizar algunas herramientas especializadas para desarrollar un cronograma de proyecto de software. La más utilizada es Project de Microsoft como herramienta auxiliar. Es relativamente poderosa y adecuada para proyectos más grandes, pero no puede reemplazar completamente el plan del proyecto. , especialmente se deben explicar algunas partes importantes del texto. Los proyectos a pequeña escala pueden simplemente utilizar Excel como herramienta auxiliar. Aquí no se explicará en detalle cómo utilizar estas herramientas.

Se deben considerar los siguientes factores al desarrollar el cronograma de un proyecto de software:

1) El grado de dominio de los requisitos del sistema y los objetivos del proyecto. Si al principio solo tiene una pequeña comprensión de los requisitos del sistema y los objetivos del proyecto, solo podrá desarrollar un cronograma relativamente aproximado. Una vez completada la fase de requisitos o la fase de diseño, el cronograma debe perfeccionarse aún más.

2) La escala del sistema de software y la escala del proyecto no son el mismo concepto. La escala del sistema de software a menudo se deriva de estimaciones de puntos de función u otros métodos de estimación, mientras que la escala del proyecto también debe considerar los requisitos de cantidad y calidad de los documentos, el uso de herramientas de desarrollo, el grado de reutilización de nuevas tecnologías, la facilidad de comunicación y la situación del cliente, si es necesario cumplir normas y reglamentos, etc. Por ejemplo, para completar un sistema a gran escala, la fuerza intelectual y física de una o varias personas en un determinado período de tiempo es insoportable. Dado que el software es un producto lógico e intelectual, aumentar ciegamente el número de desarrolladores de software no puede aumentar proporcionalmente las capacidades de desarrollo de software. Por el contrario, a medida que aumente el número de personal, se agravarán problemas como la organización, coordinación, comunicación, capacitación y gestión del personal.

3) La complejidad del sistema de software y la complejidad del proyecto: está relacionada con la escala del sistema de software y la escala del proyecto. La complejidad del sistema de software considera principalmente la complejidad de. Las propias funciones y arquitectura del sistema de software. La complejidad del proyecto se refiere principalmente a la composición de los miembros del equipo del proyecto, la complejidad de las tareas del proyecto, la complejidad de las partes interesadas del proyecto, la dificultad de la investigación de la demanda, la seguridad de los recursos, etc. La complejidad del proyecto se refiere principalmente a la composición de los miembros del equipo del proyecto, la complejidad de las tareas del proyecto, la complejidad de las partes interesadas del proyecto, la dificultad de la investigación de la demanda, múltiples proyectos, seguridad de los recursos, etc. La escala de un sistema de software no es necesariamente directamente proporcional a la complejidad del sistema de software ni la escala del mismo proyecto es necesariamente directamente proporcional a la complejidad del proyecto.

4) Los requisitos de avance del proyecto, es decir, la urgencia del proyecto. Algunos proyectos son de gran escala, pero debido a la firma de un contrato con el cliente o para capturar el mercado primero, el período de construcción es muy ajustado. En este momento, debemos considerar cómo organizar mejor y razonablemente el período de construcción. más candidatos y utilizar horas extras son el último recurso. Además de aumentar los costos laborales, definitivamente aumentará los costos de comunicación (el tiempo necesario para familiarizarse con las tareas del proyecto si no se manejan adecuadamente las horas extras causará problemas emocionales y también estará demasiado ocupado para preocuparse por la calidad); lo que lleva a una disminución de la calidad.

5) Capacidad de los integrantes del proyecto. Estas capacidades incluyen las capacidades de gestión de los gerentes de proyectos, las capacidades analíticas de los analistas de sistemas, las capacidades de diseño de los diseñadores de sistemas, las capacidades de codificación de los programadores, las capacidades de prueba de los evaluadores y la capacidad de la empresa o del equipo del proyecto para estimular estas capacidades. Desde otra perspectiva, también está la familiaridad general con el negocio industrial del cliente; el dominio de las herramientas de modelado, herramientas de desarrollo, herramientas de prueba y otras tecnologías y la acumulación de conocimiento comercial de la industria y conocimientos técnicos principales dentro de la empresa;

4.4 Plan de Control del Proyecto

4.4.1 Plan de Aseguramiento de la Calidad

Realizar actividades de revisión de calidad para controlar la calidad del proceso. Los proyectos más grandes deben preparar un "Plan de calidad del proyecto de desarrollo de software" por separado. De acuerdo con las especificaciones del plan de garantía de calidad del software informático gb/t 12504, su contenido incluye:

1:

l Introducción (este capítulo incluye el propósito, la definición y las referencias del plan de calidad )

l Gestión (describe la organización, las tareas y las responsabilidades relacionadas responsables de la gestión de la calidad del software)

l Documentación (enumera el contenido del desarrollo, verificación y validación del software, así como el uso y mantenimiento)

l Revisión e inspección (aclarar los aspectos técnicos y de gestión del trabajo de revisión e inspección, y preparar o citar procedimientos de revisión e inspección relevantes, así como criterios técnicos para aprobar o reprobar.

Al menos incluya revisión de requisitos de software, revisión de diseño general, revisión de verificación y validación de software, inspección funcional del sistema de software, inspección física de procedimientos y documentos)

l Gestión de la configuración del software (preparar regulaciones de gestión de configuración relevantes, o en " 4. 4 Plan de gestión de configuración", o referenciado de acuerdo con "gb/t 12505 Especificación del plan de gestión de configuración de software informático", o referenciado en un documento separado desarrollado de acuerdo con "gb/t")

l Herramientas, técnicas y métodos (Determinar las herramientas, técnicas y métodos utilizados para respaldar el trabajo de gestión de calidad de proyectos de software específicos y explicar su propósito y uso)

l Gestión de la configuración del software (escribir regulaciones relevantes de gestión de la configuración, o en "4.4,

l Controles de medios (describe los métodos e instalaciones utilizados para proteger los medios físicos del programa informático contra el acceso no autorizado, daños accidentales o envejecimiento natural)

l Suministro controles de unidad (las unidades de proveedores incluyen contratistas del proyecto, unidades de venta de software y unidades de desarrollo de software) definen procedimientos para controlar a estos proveedores para garantizar que el software comprado por el contratista del proyecto al proveedor de software, el software desarrollado por otros desarrolladores o el software seleccionado del software existente del desarrollador el software de la biblioteca cumple requisitos específicos).

l Recolección, mantenimiento y retención de registros (identifique los registros de las actividades de control de calidad del software que deben conservarse, describa los métodos y las instalaciones utilizadas para compilar, proteger y mantener estos registros). y describir estos períodos de retención de registros)

4.4.2 Plan de control de progreso

(Puede citar directamente la siguiente descripción o puede personalizar esta parte según la situación del proyecto)

Este El seguimiento del progreso del proyecto se lleva a cabo de acuerdo con los "Estándares de gestión de proyectos" de la empresa y es organizado e implementado por el departamento de gestión de calidad de la empresa y otros departamentos de control de procesos, y los registros de inspección diarios generados durante el

4.4.3 Plan de seguimiento del presupuesto

Describe cómo comprobar el uso del presupuesto del proyecto.

4.4.4 Plan de gestión de configuración. /p>

Preparado de acuerdo con gb/t 12505. Los términos relacionados con la gestión de la configuración del software, o la referencia a un documento separado del "Plan de gestión de la configuración", deben proporcionar la identificación del producto de software, el control y la implementación de las modificaciones del software. , el registro y la notificación del estado de implementación de las modificaciones y la gestión de la configuración. Además, también se deben especificar los métodos e instalaciones utilizados para mantener y almacenar las versiones de software controladas, los pasos para informar, rastrear y resolver los problemas de software descubiertos. La organización y las responsabilidades para informar, rastrear y resolver problemas de software

De acuerdo con la "Especificación del plan de gestión de configuración de software informático GB/t 12505", el contenido del plan de gestión de configuración de software es el siguiente:

l.Introducción (Esta sección incluye el propósito, definición y referencias del plan de calidad)

l Gestión (Describe la organización, tareas, responsabilidades y controles de interfaz relacionados responsables de la gestión de la configuración del software. )

l Actividades de gestión de la configuración del software (describe los requisitos para cuatro aspectos de las actividades de gestión de la configuración del software, como la identificación de la configuración, el control de la configuración, el registro y la generación de informes del estado de la configuración y la inspección y revisión de la configuración).

lHerramientas, técnicas y métodos (Identificar las herramientas, técnicas y métodos de software utilizados para respaldar la gestión de la configuración de software para un proyecto específico, describir su propósito y describir su uso en el contexto de propiedad del desarrollador)

lControl de las unidades de entrega (las unidades de entrega se definen como proveedores de software, desarrolladores de software o subdesarrolladores de software. Se deben definir procedimientos de gestión para controlar estas unidades de suministro para garantizar que las compras de las unidades de venta de software, desarrolladas por otros El software desarrollado por la unidad o seleccionado de la biblioteca de software existente de la unidad de desarrollo cumple con los requisitos y retención de gestión de configuración de software especificados (determinar los documentos de gestión de configuración de software que se conservarán, determinar los métodos e instalaciones para la agregación, protección y retención de documentos , determinar los requisitos para los registros retenidos) y las instalaciones, y especificar sus períodos de retención)

5 Condiciones de soporte Project Manager Alliance, Problemas de gestión de proyectos.

Describe las condiciones de soporte e instalaciones necesarias para completar este proyecto.

5.1 Soporte Interno

Enumere los requisitos de soporte para cada etapa del proyecto (incluido personal, equipos, software, capacitación, etc.) y sus requisitos de tiempo y usos.

Por ejemplo, el soporte de equipos y software incluye clientes, servidores, entornos de red, dispositivos periféricos, equipos de comunicación, herramientas de desarrollo, sistemas operativos, sistemas de gestión de bases de datos, entornos de prueba, listas detalladas de requisitos para la fecha de llegada, uso. Requisitos de tiempo.

5.2 Atención al cliente

Enumere el trabajo realizado por el cliente para el proyecto, el plazo de finalización y los criterios de aceptación, incluidas las condiciones y el tiempo que el cliente debe proporcionar.

5.3 Subcontratación (opcional)

Enumerar el trabajo realizado por subcontratistas externos y el tiempo de finalización, incluyendo las condiciones y tiempo que la agencia externa debe proporcionar.

6 Presupuesto

6.1 Costos de personal

Enumere el número esperado de meses de trabajo para cada persona en el equipo del producto/proyecto.

Enumere la mano de obra necesaria para completar el proyecto (incluido el número de personas y el tiempo)

Los costos laborales generalmente incluyen salarios, bonificaciones, subsidios, fondos de previsión de vivienda, pensiones y primas de seguro médico

6.1 Costos de personal

Enumere el número estimado de meses de trabajo para cada persona en el equipo del producto/proyecto. 2 Costos de equipos

Los costos de equipos incluyen: costos de materia prima, costos de compra y uso de equipos

Enumere los equipos a comprar y su configuración y requisitos

Enumere los equipos a comprar El software adquirido, su versión y requisitos

Enumerar los equipos existentes a utilizar y su período de uso

6.3 Otros presupuestos de costos

Enumerar los costos necesarios para completar el proyecto Varios gastos requeridos, incluidos gastos de viaje, tarifas de información, peajes, tarifas de conferencias, tarifas de transporte, tarifas de oficina, tarifas de capacitación, tarifas de subcontratación, etc., incluidos

(1) Viajes gastos (gastos de viaje, tarifas de alquiler de automóviles) (incluido subsidio)

(2) Tarifas de materiales (libros, materiales, fotocopias, publicaciones)

(3) Tarifas de comunicación (locales a largo plazo) llamadas a distancia, comunicaciones móviles, acceso a Internet, gastos de envío)

(4) Honorarios de conferencias (honorarios de evaluación, reuniones de revisión, seminarios, asuntos exteriores, etc.)

(5) Gastos de oficina (tarifas de compra de suministros de oficina)

(6) Tarifas de colaboración (tarifas de entretenimiento de colaboración empresarial, gastos de comidas por horas extras del equipo del proyecto)

(7) Tarifas de capacitación (tarifas de redacción de material de capacitación, impresión de datos) tarifas, tarifas de origen, tarifas de equipo)

Otros (tarifas de prueba, tarifas de procesamiento externo, tarifas de mantenimiento, tarifas de consumibles, tarifas de productos pequeños, tarifas de Tea Party, etc.)

6.

6.4 Presupuesto total del fondo del proyecto

Enumere

7 cuestiones clave

Enumere las cuestiones clave, las dificultades técnicas y los riesgos que pueden afectar el éxito o fracaso de todo el proyecto y señale el impacto de estos problemas en el éxito o fracaso del proyecto.

8 elementos del plan especial

El plan especial se refiere al plan. que se desarrolla independientemente de este documento debido a las necesidades del proyecto. Esta sección lo presenta. Los elementos de cada plan especial que deben desarrollarse durante el desarrollo de este proyecto pueden incluir planes de subcontratación, planes de subproyecto, planes de capacitación de los miembros del equipo del proyecto. planes de prueba, planes de seguridad, planes de garantía de calidad, planes de gestión de configuración, planes de capacitación de usuarios y plan de instalación e implementación del sistema.

"Compilación de especificaciones y estándares nacionales para la ingeniería de software informático 2003" (Editorial de normas de China)

"PMBOK-2000" PMI

"PMBOK" -2004" PMI;

"Gestión de proyectos exitosa" Trevol L Young (Times Business Edition, traducido por Yan Hongjuan);

"Gestión de proyectos exitosa" Jack Gido James P. Clements (serie de libros de texto "Clásicos de la gestión del siglo XXI", traducidos por Zhang Jincheng y otros);

"Cómo hacer un buen trabajo en la gestión de proyectos" stanley e. portny (Serie IDG Nuevas prácticas comerciales económicas para principiantes, traducida por Ning Jun y otros);

Gestión de proyectos de desarrollo de software (segunda edición) neal whitten (Serie Gestión de proyectos de software, traducida por Sun Yanchun y otros);

"Gestión de proyectos de TI" Kathy Schwalbe (Serie de traducción de gestión de proyectos, traducción de Wang Jinyu y otros, artículo de Project Manager Alliance, discusión en profundidad);

"Fundamentos de la gestión avanzada de proyectos" (Folleto de capacitación para gerentes de proyectos sénior de integración de sistemas de información informática del Ministerio de la Industria de la Información)

Fecha de finalización de este artículo: 28 de abril de 2005

La dirección de correo electrónico del autor de este artículo: luls@dragonsoft.com.cn o lulsnet@21cn.com

Corrección es bienvenida.