project-management - software - project management steps

¿Hay algo así como un olor a proceso? (10)

En general, estamos familiarizados con los olores de código aquí, pero igual de dañinos o más lo son cuando el lado comercial de las cosas, aunque sea de nuestro dominio, está yendo mal.

Como ejemplos, lo contrario de cualquier cosa en la prueba de Joel se consideraría un olor de proceso importante (es decir, sin control de fuente, sin probadores) pero esos son obvios y el punto de "olores" es que son sutiles y se convierten en algo destructivo . Estoy buscando granularidad aquí.

Para comenzar, aquí hay un par (que puede convertirse en una lista a medida que las respuestas llegan)

Escribir código antes de firmar un contrato con el cliente
Que se le pida estimados sobre la marcha ( "solo uno aproximado" ) para cualquier cosa que tome más de un día (¿unas pocas horas?)
Predomina la antigua sabiduría del culto a la carga (ejemplo personal: la integración de la fuente de VisStudio está prohibida)
Has dejado de tener reuniones grupales no relacionadas con el proyecto (o no tienes un foro similar para debatir)

¿Cuáles son los olores de otros procesos y qué tan malos son?

Algunos olores que he visto:

Administración optimista, pero no pueden pagar su salario este mes. Esto es realmente malo. Salí de la compañía a tiempo, pero murió pocos meses después.
Sesiones de equipos de fanáticos extremos. Centrándose en lo buena que es la compañía. Pero al final todo baja.
Las buenas nuevas personas son echadas porque intentaron cambiar el proceso. Vergüenza real. He visto a algunas personas que realmente intentaron mejorar la compañía, pero los viejos hábitos nunca mueren, por lo que a menudo terminan en una gran desilusión.
El jefe siempre tiene la mentalidad correcta ...

Hay más, pero no voy a echar a perder la diversión para los demás.

El libro " Antipatterns " de William J. Brown et. Alabama. tiene un montón de olores relacionados con el proyecto. No siempre son desastres en progreso; Existen circunstancias atenuantes para casi cualquier olor.

El Portland Pattern Repository también tiene una página sobre Antipatterns, que cubre muchos de los mismos temas que el libro "Antipatterns". Visite http://c2.com/cgi/wiki?AntiPatternsCatalog y desplácese hacia abajo a "Antipatterns de administración". Algunos ejemplos:

Parálisis de análisis : un equipo de analistas, por lo demás, inteligentes y con buenas intenciones, entra en una fase de análisis que solo finaliza cuando se cancela el proyecto.
Dame estimaciones ahora : un cliente (o PointyHairedBoss) exige estimaciones antes de tener suficientes datos para entregarlo. Usted acepta el "desafío" y da estimaciones fuera de la cabeza (es decir, conjeturas). El cliente / jefe luego trata la estimación como un compromiso revestido de hierro.
Proyecto Ground Hog Day : se celebran reuniones que parecen discutir las mismas cosas una y otra vez. Al final de dichas reuniones, se toman decisiones de que "hay que hacer algo".
Diseño por comité : dado un entorno político en el que ninguna persona tiene la influencia suficiente para presentar un diseño para un sistema y obtener su aprobación, ¿cómo se hace un diseño? Organice un gran comité para resolver el problema. Dejen que luchen entre ellos y finalmente tomen lo que salga al final.

¡Colecciónalos todos! :-)

Lo que llamo: NIH (edición de proceso), también conocido como Elige tu propia aventura.

Evidencia de esto:

pasas reuniones interminables depurando el proceso. Y refactorizarlo.
nada realmente se hace, porque nadie sabe lo que deberían estar haciendo.

Creo que esto es un antipattern, en lugar de un olor.

Los cambios en el proceso se realizan sin pensar en el tiempo o en los entregables actuales, y luego se revierten inmediatamente cuando los entregables llegan tarde debido a la institución de un nuevo proceso.

Alguien se va de baja médica y el equipo, como resultado, está tratando de recoger el trabajo de esa persona tan bien como el suyo y cuando a los gerentes o clientes o representantes de ventas se les dice que las cosas se retrasarán como resultado, solo les preocupa cuando las cosas suceden y puede trabajar noches y fines de semana mientras tanto y nunca preguntar acerca de la persona con la emergencia y cómo lo está haciendo.

Cuando se esperan horas extraordinarias para las personas de bajo nivel, pero las personas que lo desean se van urgentemente a tiempo y no están disponibles para responder preguntas. O cuando te hacen trabajar horas extras para estar listo antes de las 8 a. M. Y luego no lo mires en QA por tres días más. Hola, podría haberlo hecho para entonces en horas regulares.

Entrega de los archivos necesarios (para la importación de datos, por ejemplo) o minutos de información antes de la fecha de vencimiento y luego culpar a los desarrolladores cuando no se cumple la fecha de vencimiento.

No ha tenido una revisión de proyecto posterior ... cuando el proyecto finalizó hace 6 meses.

Sugiero ver la sección de la organización de la página de wikipedia sobre Anti-Patrones . He tenido que lidiar con el "modo Crisis" y las "estimaciones sobre la marcha" que mencionaste.

Un olor con el que tengo un problema real (porque trabajo con él): herramientas que no abandonan, software de desarrollo, metodologías o cualquier otra cosa que no funciona.

Muchas veces, hay una (o más de) una pieza de software que claramente, descaradamente, no funciona y probablemente interfiere con el proceso de desarrollo, pero que un gerente de proyecto simplemente se niega a reemplazar / actualizar "porque costaría demasiado {tiempo, dinero, lo que sea} para reemplazar ".

Editar: Esto también se extiende a las máquinas y otras infraestructuras (ejemplos: un servidor de compilación que demora una hora para hacer una compilación de dos minutos o un sistema de control de versiones, ejem. CVS) que demora 15 minutos para descubrir si ha habido alguna actualizaciones en un árbol fuente de 50MB).

Envío de un prototipo - " lo productizaremos más tarde "

Back Dating: se le da una fecha de finalización y luego se le informa qué debe hacerse
Cobertura de QA inversa: el control de calidad se centra en los elementos no esenciales (porque eso es todo lo que saben cómo probar)
Problemas de alineación medioambiental: los diversos entornos (Dev, Test, Staging, Production) no están sincronizados para el código y los datos; por lo tanto, cualquier prueba previa a la producción no es válida.
Desprendimiento de fecha de entrega: nadie cree en la fecha de finalización porque: estaba hecha para empezar y el 100% de los proyectos anteriores nunca cumplieron con sus fechas de entrega
Old Grumpy Code: se teme el código anterior porque no hay ningún deseo de refactorizar
el triángulo malvado pm (alcance, costo, recursos y / o calidad) - para ajustar el proyecto que necesita para agregar personas, reducir la calidad, reducir el alcance, etc. ... una vez que un proyecto está en movimiento, la mayoría de los cambios (incluso la reducción de alcance) aumentará el tiempo y el costo y reducirá la calidad. Una vez que las vías del tren están caídas, es difícil simplemente colgando a la izquierda

Pregunta interesante y aún más respuestas interesantes. Gracias por esos.

He estado en casi todos los roles de desarrollo de software (desarrollador, QA, Tech Lead, Project Manager, incluso cliente) y puedo enumerar con seguridad los siguientes olores

¿Qué tan rápido reacciona el equipo ante las nuevas aportaciones (y qué tan aceptables son los cambios)?
¿Cuántas capas atraviesa para hacer las cosas (bucofagia)
Qué tan claras son las funciones / tareas, y son los objetivos SMART y tenemos KPI.
¿Qué tan serio es el equipo que trabaja en el proyecto al respecto?
¿El equipo se reúne regularmente (leer a diario) para discutir logros, metas y problemas?

Lo más importante, sin embargo, y lo más evidente (para una buena nariz) es el nivel de higiene de la herramienta de gestión de proyectos que se está utilizando (hoja de Excel, hoja de papel, herramientas ágiles, correo electrónico, lo que sea en la metodología que utilice). Eso es lo primero que noté al evaluar proyectos.

¿Sé dónde se encuentra el proyecto en este momento?
¿Puedo decir (sin preguntar al equipo) qué debe hacerse después?
¿Puedo decir en qué está trabajando el equipo en este momento?
¿Puedo decir cuándo es la próxima versión y si es alcanzable?
¿Puedo decir si el cliente recibe actualizaciones regularmente?
¿Puedo decir si el cliente está dando aprobaciones y si sus comentarios son atendidos a tiempo?
¿Puedo decir simplemente mirando la distribución de carga del proyecto en los ingenieros?

Obviamente, todo esto está bien cubierto si eliges una metodología ágil moderna, pero dependiendo del mercado y del tipo de trabajo, el kilometraje puede variar. Así que manteniéndome metodológicamente independiente, este es el conjunto mínimo de olores que deberían eliminarse.