Algunas opiniones sobre la gestión de proyectos

Prefacio

Después de haber trabajado durante cinco años, he sido testigo de nuestro crecimiento de un pequeño equipo de cinco o seis personas a un gran equipo de más de 40 personas. Mirando hacia atrás en mi trabajo en los últimos años, estoy muy feliz. De vez en cuando vuelvo a las fotos de mi trabajo anterior y me siento feliz por dentro. Creo que todavía soy una persona afortunada. Encontré un trabajo que me gusta y encontré un grupo de personas con las que me gusta trabajar. Estamos en constante crecimiento y obteniendo nuevos resultados.

Durante el continuo crecimiento del equipo, tengo mucha buena experiencia, quiero hablar de gestión de proyectos esta vez. Elegí este tema primero porque la empresa está implementando un nuevo sistema de gestión de proyectos. El método de gestión de proyectos que usamos ha sido abandonado. He utilizado ambos sistemas de gestión. Puedo hacer una comparación.

status quo

Hablando de gestión de proyectos, creo que primero necesito describir los procesos de negocio del grupo, después de todo, diferentes procesos de negocio pueden requerir diferentes métodos de gestión de proyectos.

Nuestro equipo es responsable del negocio del centro comercial, en la actualidad se ha mejorado el marco principal del centro comercial y nuestra demanda proviene del producto.

Los estudiantes que conocen el centro comercial deben saber que el negocio del centro comercial necesita una iteración rápida , por lo que podemos tener 30 o 40 proyectos en paralelo cada semana, lo que puede considerarse como un solo proyecto. El proyecto generalmente toma de 1 a 2 meses desde el desarrollo hasta el lanzamiento.

Cada semana, nos reuniremos con el equipo de producto a la hora designada para verificar el progreso del proyecto y la prioridad del proyecto, y determinar el plan para la próxima semana.

Este es nuestro status quo actual.

Tres sistemas

Sin gestión

Cuando solo teníamos cinco o seis personas, casi todos los proyectos tenían fechas límite, el producto decía: lo usaré ese día.

Podemos ver el rápido desarrollo del negocio, nos sentimos llenos de energía, estamos llenos de entusiasmo, no necesitamos gestión de proyectos, nos arremangamos y trabajamos duro, y luego terminamos.

Por supuesto, no tenemos ninguna administración en absoluto, todavía hacemos algunas programaciones y planificación relacionada, pero es un poco burdo, generalmente así:
Inserte la descripción de la imagen aquí
Inserte la descripción de la imagen aquí

Un correo electrónico contiene el momento del proyecto y el desglose del contenido específico. En ese momento había pocos proyectos de I + D, pocos proyectos y pocos gerentes de producto. La mayoría de los estudiantes eran de alta calidad y nivel. Generalmente, lograron completar las tareas según lo planeado, por lo que este plan de manejo fue factible.

Ahora piénsalo. En ese momento, las ruedas realmente giraban y se lograron muchas cosas que otros pensaban que eran imposibles, pero nadie estaba cansado. Todos estaban muy felices.

Este es el primer conjunto de sistemas de gestión de proyectos que utilizamos durante el brutal período de crecimiento empresarial: sin gestión

Sistema de gestión de proyectos de construcción propia

Con el aumento de los negocios, los gerentes de productos y los estudiantes de I + D continúan expandiéndose, lo que resulta en demasiados proyectos y los métodos anteriores ya no pueden satisfacer a la gerencia. Existen principalmente las siguientes razones

  1. Ya sea producto o I + D, necesita una ubicación donde pueda ver todos los proyectos actuales , de modo que pueda controlar los recursos y la planificación.
  2. Los proyectos tienen diferentes estados, debe verificar qué proyecto no se ha procesado durante mucho tiempo o si es riesgoso
  3. La persona a cargo de I + D debe conocer el uso de los recursos de I + D

Al principio quería hacer un set por mi cuenta, pero había muchos proyectos y los líderes sintieron que era innecesario. Al menos se necesitaba un gerente de producto y un front-end para este asunto, así que no lo hice. Ahora piénsalo. Afortunadamente, no lo hice en ese momento. Pensé que debería ser más fácil construir un sistema de gestión de proyectos. Era completamente arrogante. No es que el sistema de gestión de proyectos sea técnicamente complicado, sino si el sistema realmente puede satisfacer las necesidades de todos. En ese momento, la escala del negocio, el número de negocios y las diversas cosas que se encontraron en el proyecto eran relativamente pequeñas, y las cosas que se hicieron sobre la base de este conocimiento pueden no ser buenas.

Luego, investigué algunas de las herramientas de administración existentes, y eran más complicadas de usar. Al final, usamos una solución relativamente simple para resolver este problema. Utilice TB

tuberculosis

En primer lugar, determinamos que un buen estado del proyecto son: demanda de alineación, evaluación de necesidades, evaluación de tecnología, vuelo, desarrollo, prueba, en línea, ha sido en línea, suspendido o abandonado. Habrá una lista de elementos correspondiente en cada estado. Producto e I + D juntos promueven el cambio continuo del estado del proyecto.
Inserte la descripción de la imagen aquí

Para cada uno de los detalles del proyecto, los elementos de configuración son los siguientes

  • Gerente de proyecto

  • Hora de inicio y finalización del proyecto

  • progreso del proyecto

  • Área de cobertura del proyecto: nacional / extranjero

  • Línea de producto: qué empresa propone la demanda.

  • Hitos: puntos de tiempo clave, tiempo de inicio de desarrollo, tiempo de prueba, tiempo de lanzamiento

  • Solicitante

  • Dueño del producto

  • Jefe de I + D + i

  • Líder de prueba

  • Valor estimado

  • enlace wiki

  • Observaciones

Debido a que hay una reunión semanal con el producto todas las semanas, el día antes de la reunión semanal, el líder del proyecto actualizará el progreso y tomará notas si hay riesgos.

TB tiene la ventaja de que la búsqueda es muy flexible, por lo que puede filtrar fácilmente los elementos que le interesan. Gestionamos el proyecto utilizando TB.

Normalización

Por supuesto, la TB por sí sola no es suficiente, otra cosa que hacemos es estandarizar los requisitos del proyecto. Todo proyecto debe tener

  • Documento de requisitos: contiene detalles de requisitos y prototipos del producto.

  • Documentación técnica: si el proyecto es complejo, la documentación técnica debe incluir detalles técnicos como arquitectura y api, y la documentación debe ser revisada por varias partes técnicas.

  • Documento de programación: una parte extremadamente importante, que generalmente incluye lo siguiente

Inserte la descripción de la imagen aquí

  • Conéctese y revertir documentos

Estos documentos se colocarán en el elemento de configuración del enlace wiki de TB para que todos los vean.

Cuando se prueba el proyecto, el contenido de la prueba se completará en el sistema de prueba y también se demostrará a los estudiantes de prueba que evitan que el proyecto de I + D sea inutilizable. Por supuesto, los estudiantes de I + D también probarán sus casos de prueba juntos.

Si existe riesgo de aplazamiento y lanzamiento del proyecto, debe comunicarse con el producto con anticipación. Si el riesgo no se puede evitar, debe tener una reunión con todo el personal para reformular el plan y determinar un nuevo punto de tiempo, y enviar un correo electrónico de extensión .

Una vez que el proyecto esté en línea, puede revisarlo según la implementación del proyecto. De esta forma optimizamos continuamente nuestra gestión.

Personalmente, prefiero este método de gestión.

  • La primera es que la información detallada de un solo proyecto es muy fácil de obtener, y la información de muchos proyectos también es clara de un vistazo.

  • En segundo lugar, este enfoque es estricto pero flexible, es decir, todos los proyectos se agrupan en un flujo, pero también permite a los desarrolladores realizar ajustes oportunos cuando encuentran problemas.

  • El tercer punto es que el costo de mantener el proyecto es muy bajo, y actualizar una vez a la semana puede garantizar que todas las partes tengan la misma visión del proyecto.

Por supuesto, esto también tiene sus deficiencias. La deficiencia es que la carga de trabajo de cada estudiante de I + D no se puede cuantificar. Quizás el líder sepa directamente la aproximación, pero no puede expresarla en números. Esto conducirá a la falta de base para la promoción y calificación.

Sistema de gestión de proyectos de desarrollo propio

Este año, el departamento comenzó a desarrollar su propio sistema de gestión de proyectos. El contenido desensamblado se ingresa en el proyecto. Después de completar un elemento pequeño, el estado del elemento pequeño debe actualizarse. De esta manera, el sistema de desarrollo propio puede ver las horas de trabajo y las condiciones de trabajo de todos.

Debido a que este sistema aún está en construcción, hay algunas áreas que creo que se pueden mejorar, principalmente de la siguiente manera

  1. Es problemático rellenar los elementos pequeños divididos. En el pasado, solo necesitábamos escribir un documento de programación, y el documento de programación puede ver fácilmente la carga de trabajo de cada grupo. Ahora es necesario escribir primero el documento de programación y luego completar los elementos pequeños en el documento de programación en el sistema, lo que requiere varias horas de trabajo. La función de completar elementos pequeños se puede hacer más intuitiva y el contenido de la pantalla se puede mostrar claramente.
  2. Actualización de problemas. Después de completar cada elemento pequeño, si no se actualiza, el progreso completo del proyecto no se actualizará, por lo que debe actualizarse a tiempo después de completar un elemento pequeño. Si lo olvida, habrá problemas para mostrar el progreso. Esto se puede solucionar mediante recordatorios por correo electrónico.
  3. Problemas para encontrar elementos. Si desea encontrar los artículos que le interesan, es difícil filtrarlos, puede ordenar los atributos del artículo y optimizar la función de búsqueda de artículos.
  4. Problemas para ver los hitos. Este sistema de gestión carece de una ubicación donde los hitos se muestren claramente, por lo que encontrar hitos generalmente requiere ver los documentos de programación.
  5. Faltan cambios en el proyecto. En la actualidad, solo existe una gestión de procesos normal, si el proyecto está en riesgo, no hay lugar para este tipo de operación de cambio.
  6. Dificultad para asignar puntos. Cada proyecto tiene puntos. Una vez completado el proyecto, los participantes deben calificar a cada estudiante que participa en el proyecto para obtener estos puntos. Esta es una prueba de la naturaleza humana y lo familiarizado con el trabajo de otras personas.
  7. Algunos cambios menores no pueden reflejarse en el sistema, como corregir errores, rastrear problemas, responder preguntas, etc.

Este sistema tiene una ventaja. Independientemente de si los datos son precisos o no, energiza la carga de trabajo de todos. Puede ver las horas de trabajo de todos y ver los puntos ganados por todos. Espero que este sistema pueda mejorar cada vez más.

Por lo tanto, el sistema de gestión de proyectos sigue siendo muy difícil de establecer. Debe ser fácil de completar, fácil de ver, fácil de actualizar, además de la parte más humana del cálculo de la contribución de cada persona, que pondrá a prueba la sabiduría de los productos y la investigación y el desarrollo.

para resumir

Después de todo, la gestión de proyectos es imprescindible. Todo el mundo puede sentirse seguro y controlar mejor las cosas sólo si ve todo en funcionamiento. Pero, ¿cuál es la intención original de la gestión de proyectos? Creo que lo más fundamental es hacer que el negocio se desarrolle mejor y más rápido.

Cuando no usamos ninguna gestión de proyectos antes, ¿por qué pudimos completar tantos desafíos? ¿Contiene cosas más importantes?

Espero que este artículo pueda ayudarlo mucho. Si tiene alguna otra idea, puede enviarnos sus comentarios.

Al final

Si te gusta mi artículo, puedes seguir mi cuenta pública (Programador Mala Tang)

Revisión de artículos anteriores:

  1. Algunas opiniones sobre la gestión de proyectos
  2. Realización del límite de corriente 1
  3. Algunas reflexiones sobre los gerentes de producto
  4. Redis implementa bloqueos distribuidos
  5. Seguimiento de errores del código fuente de Golang
  6. El principio de realización de la atomicidad, consistencia y durabilidad de las transacciones
  7. Cómo ejercitar tu memoria
  8. Explicación detallada del proceso de solicitud de CDN
  9. Reflexiones sobre el desarrollo profesional de los programadores
  10. La historia del servicio de blogs siendo aplastado
  11. Técnicas comunes de almacenamiento en caché
  12. Cómo conectarse de manera eficiente con pagos de terceros
  13. Versión concisa del marco de gin
  14. Pensando en la revisión del código
  15. Un breve análisis de los bloqueos y transacciones de InnoDB
  16. Recomendación del editor de Markdown-typora

Supongo que te gusta

Origin blog.csdn.net/shida219/article/details/107597876
Recomendado
Clasificación