¿Cómo implementar la gestión de proyectos de sistemas de información?

La clave para un director de proyectos es tener una buena comprensión de la comunicación con el jefe, los clientes, los socios y los miembros del equipo. Las siguientes son algunas de mis acumulaciones. Si hay algún problema, corríjame. 1. Hágale saber al jefe que el proyecto del sistema de información es un proyecto de sistema de información de ingeniería relativamente único, progresivo y relativamente complejo, y no es un producto de hardware. Tiene propiedades relativamente visibles y fijas. Es dinámico precisamente porque es altamente personalizable. Una vez contactados, debemos estar preparados para una guerra prolongada y todos los recursos de la empresa deben tener prioridad para el equipo del proyecto. Los retrasos en la aceptación del proyecto y los frecuentes cambios en los requisitos de los clientes también son razones importantes. El éxito de una empresa depende en gran medida de la adecuada gestión de los proyectos. 2. Preparar el alcance del proyecto y el control de objetivos del proyecto. El alcance del proyecto debe describirse en documentos estandarizados. La mayoría de los clientes describen lo que quieren verbalmente y es bastante informal, especialmente para proyectos gubernamentales. Puede que sean buenos escribiendo documentos oficiales, pero necesitan expresar sus necesidades de forma organizada con palabras. Es difícil decir una palabra, e incluso si lo mencionaran, sería semanas después. Además, el alcance del proyecto no está claro a medida que avanza, el entusiasmo por el trabajo de todos los miembros del equipo del proyecto puede verse fácilmente abrumado. Ambas partes sienten que el proyecto se hace cada vez más grande, superando seriamente el alcance inicial y la fecha de finalización planificada. . La función de hoy no es perfecta, pero será necesario perfeccionar la función de mañana. Con el paso del tiempo, los ingenieros de desarrollo empezaron a dudar de sus capacidades. Lo mejor es indicar en qué fase del proyecto se encuentra, el alcance y los objetivos del proyecto, y también indicar en el documento qué se hará si se excede el alcance de este proyecto. Debe estar firmado por el departamento comercial utilizado por el cliente y el líder del cliente. Puede haber una situación en la que el cliente tenga una razón para eludir la firma, así que convéncelo de que este es el proceso y las regulaciones del proyecto de la empresa. 3. Controlar estrictamente los cambios en las necesidades de los clientes y decirles que no todos los cambios deben implementarse y que los clientes son Dios. Es innegable. El proyecto es finalmente utilizado por el cliente. ¿Encontramos que a veces las necesidades planteadas por los clientes son un poco extrañas, poco realistas o los costos de implementación son altos por el momento? Luego hay que ser firme y decirles qué pasará si hacen lo que hacen, lo que traerá problemas prácticos relacionados con costos, plazos y calidad. Bríndeles la sensación de que somos un proveedor de soluciones de sistemas, centrándonos en resolver problemas generales, críticos y necesarios. Además, ¿Microsoft todavía tiene parches? Nuestra política para sus necesidades es: "Registrar todo, evaluar y controlar todo, implementar algo y aceptarlo todo". Cuarto, dejar que los clientes proporcionen personas relevantes a cargo para organizar las cosas de "integración" necesarias. En la práctica, algunos clientes lo saben todo. es indicar lo que desea, luego solicitar una fecha de finalización y utilizarla cuando llegue el momento. Después de eso, parecía no tener nada que ver con él. Es probable que el cliente sea un miembro del personal del departamento comercial; después de todo, tiene su propio trabajo diario. Luego, sea valiente y dígale que en la última reunión inicial del proyecto, su líder había anunciado sus responsabilidades en el proyecto. Y cuéntale tus dificultades laborales reales. Creo que le resultará difícil dudar y eludir más. 5. Deje que los ingenieros de desarrollo "salgan" y comprendan completamente la investigación. No crea que la investigación es una pérdida de tiempo cuando se comunica con los clientes. Si es conveniente, traiga colegas femeninas (oye... oye... no). No seas demasiado mezquino) Mira a las colegas femeninas) y a los ingenieros de desarrollo. No estoy de acuerdo. Sólo hay dos roles entre los investigadores: directores de proyectos y analistas de requisitos. Se debe generar un informe de análisis de los problemas de la encuesta. Y puede presentar rápidamente puntos clave, dificultades y cuestiones clave en función del contenido de la investigación. De esta manera, los ingenieros de desarrollo centrarán la mayor parte de su energía en módulos clave y los perfeccionarán mejor. Cada uno de nosotros tiene una comprensión diferente. Los ingenieros de desarrollo prestan más atención a las habilidades de codificación y la implementación de funciones. Los representantes de ingenieros de desarrollo que participan en la encuesta pueden garantizar que la encuesta oriente el desarrollo y evite mejor la desconexión entre las necesidades comerciales y el desarrollo. Además, déjeles sentir realmente lo que los usuarios dicen y piensan. Hágales entender también que a veces la expresión de las necesidades del cliente no es clara y cambiable. No suele ocurrir que los analistas e investigadores de la demanda avergüencen deliberadamente a los ingenieros de desarrollo. Esto es mucho mejor que gritar acerca de mejorar la calidad del producto todos los días y pensar desde la perspectiva de los usuarios. 6. Esté preparado para la implementación, primero "ejecutar" para "ganar". Una vez que el sistema esté listo, la gente debe usarlo. Creo que sólo usándolo se puede reflejar el valor del sistema y la credibilidad de la empresa. Sólo cuando se utiliza el sistema se puede reflejar su valor como director de proyectos. Por lo tanto, debemos encontrar formas de hacer todo lo posible para permitir que los clientes recopilen datos primero. Una vez que llegan los datos, la iniciativa está en nuestras manos. Varias modificaciones posteriores ya no indican un funcionamiento imperfecto del sistema. Lo que es más importante es que en la empresa, el jefe pensará que los diversos cambios y modificaciones que ha realizado antes son significativos. No refine todas las funciones y espere hasta que se perfeccionen antes de conectarse a Internet para recopilar datos. La posibilidad de éxito es muy pequeña, e incluso es posible que hasta el día de tu partida las funciones del sistema sigan modificadas de la misma manera, pero dejará de tener sentido porque no hay respaldo de los datos comerciales del cliente. Muchos proyectos, tanto grandes como pequeños, carecen de una metodología de implementación. He conocido a muchas empresas de software. Sólo hay dos roles: vendedor e ingeniero de software, y no hay un ingeniero de implementación dedicado. Quizás no crea que el proyecto es pequeño, pero cuando el proyecto crezca un poco, los problemas quedarán expuestos. Como dice el refrán, "tres puntos son desarrollo y siete puntos son implementación". Se recomienda que una vez probadas la mayoría de las funciones del sistema, lo ejecute primero. Algunas modificaciones menores, objetivos no críticos, se tratarán como actualizaciones "después de la ejecución".

De esta manera, incluso si algunas funciones no están lo suficientemente detalladas, puede decirles con seguridad a sus clientes y a su jefe que el proyecto ha logrado los objetivos esperados, e incluso se puede decir que fue exitoso. 7. Respecto de la reunión de consulta de usuarios durante el proceso de desarrollo, el director del proyecto o el responsable de la empresa desarrolladora deberá tomar la iniciativa en el desarrollo de la reunión. En cualquier reunión de proyecto a la que asista el cliente, después de presentar el sistema, los líderes del cliente a menudo expresarán sus opiniones, algunas de las cuales están relacionadas con las funciones del sistema y otras pueden involucrar el mecanismo de gestión, el flujo de trabajo e incluso cuestiones laborales del cliente. Departamentos funcionales del cliente. Incluso es difícil ponerse de acuerdo sobre la Gala del Festival de Primavera. Recuerde, si se sale del tema, tráigalo en el tiempo. Entre estas opiniones no se excluyen las opiniones altas que puedan obstaculizar el proyecto. La reunión no debería ser demasiado larga. Para cualquier reunión relacionada con sistemas de información, el tema no debe desviarse de la idea central: "¿Cuál es el sistema que usted desarrolla, qué puede hacer por ellos y cómo incorpora y optimiza sus efectos reales?". ¿Procesos de negocio?" No es necesario utilizar demasiadas demostraciones. Cuentas, operación de sistemas de información desarrollados. Su discusión no debe ser demasiado larga (manténgala en unos cuarenta minutos). Después de la reunión, el informe de la reunión debe compilarse lo antes posible. Lo mejor es que una persona dedicada prepare el documento de Word in situ durante la reunión. Después de firmar sus nombres en el acto, se les permitió irse. Después de grabar la reunión, regrese a la empresa para convocar a todos los miembros del equipo del proyecto y a los asistentes del cliente para evaluar y controlar los problemas relevantes en las actas de la reunión y, finalmente, producir documentos de control y evaluación de cambios de la demanda del cliente. Archivo (tres copias, una para enviar al cliente para su confirmación y otra al departamento comercial de la empresa. Por supuesto, debe conservar una copia para usted. Cuando el jefe verifique el progreso, será bueno tener un explicación).