Hay un chiste que dice así:
1. El programador escribe un código que cree que no tiene bugs.
2. Las pruebas de software encuentran 20 bugs.
3. El programador corrige 10 bugs y le dice al equipo de pruebas que los otros 10 no son bugs.
4. El equipo de pruebas descubre que 5 de esos cambios simplemente no funcionan, y a la vez encuentra 15 bugs nuevos.
5. Repite los pasos 3 y 4 tres veces.
6. Debido a la presión del mercado, y para ajustarse al calendario de lanzamiento excesivamente optimista establecido al principio, el producto finalmente sale al mercado.
7. Los usuarios encuentran 137 bugs nuevos.
8. El programador que ya cobró la bonificación del proyecto desaparece sin dejar rastro.
9. El nuevo equipo de proyecto corrige casi todos los 137 bugs, pero encuentra 456 bugs nuevos.
10. El programador original envía una postal desde Fiyi al equipo de pruebas, que sufre por los salarios atrasados. Todo el equipo de pruebas renuncia en bloque.
11. La empresa es adquirida hostilmente por un competidor. En el momento de la adquisición, la versión final del software contiene 783 bugs.
12. El nuevo CEO asume el cargo. La empresa contrata a un nuevo programador para reescribir el software.
13. El programador escribe un código que cree que no tiene bugs.
En mi opinión, si realmente existiera una empresa así, sería un insulto al pueblo que no quebrara.
Este chiste empieza con el programador y termina con el programador, criticando al programador de principio a fin. Pero lo que yo digo es que esto es un fracaso total de los directivos; a lo largo de todo el proceso no se ve ninguna labor de gestión. Este tipo de directivo no solo es ignorante e incompetente, sino también desvergonzado: echa la culpa de su fracaso al programador.
1. ¿Con qué pruebas demuestra el programador que su código no tiene bugs? ¿Hay casos de prueba? ¿Hay revisión de código? Esta etapa carece de gestión.
2. ¿Se gestionaron los bugs encontrados en las pruebas? ¿Se les hizo seguimiento? Esta etapa carece de gestión.
3. ¿Qué prueba que el programador haya corregido esos 10 bugs? ¿Y por qué los otros 10 no son bugs? ¿Acaso el estándar para evaluar los bugs lo decide el programador? Esta etapa carece de gestión.
4. ¿Se exigieron responsabilidades por las 5 modificaciones de bugs que no funcionaban? Aumentar los bugs nuevos es inevitable durante el proceso de modificación, pero con un mecanismo eficaz de pruebas unitarias se podría reducir en gran medida esta situación. Esta etapa carece de gestión.
5. La iteración es normal, pero el tratamiento de los problemas evoluciona de forma divergente en lugar de convergente, lo que demuestra que no hay una regulación eficaz de la gestión. Esta etapa carece de gestión.
6. Un cronograma demasiado optimista y plazos imposibles de cumplir demuestran la ignorancia e incompetencia del directivo. Lanzar el producto a la fuerza en tales circunstancias es la temeridad de los ignorantes.
7. Esto es una irresponsabilidad hacia los usuarios; la mayor responsabilidad recae en el directivo.
8. Que en una situación así se pueda otorgar la bonificación del proyecto solo demuestra que el directivo no es un tonto cualquiera.
9. La gestión no ha mejorado en absoluto; los problemas siguen en un estado de iteración divergente. La labor de gestión sigue sin cumplirse.
10. Retrasar los salarios del departamento de pruebas refleja el descuido del directivo hacia la gestión de calidad y su total desconocimiento de la gestión de recursos humanos.
11. A la empresa adquirida le dedico dos palabras: se lo merece. Al adquirente le dedico dos: está ciego.
12. Se ve que el nuevo directivo y el anterior son tal para cual, ninguno reconoce la causa raíz del problema. Por lo demás, solo un directivo así tomaría la decisión de adquirir una empresa de este tipo.
13. La repetición de la historia es inevitable.
Una empresa o proyecto normal debe operar en un ciclo ascendente. El trabajo que garantiza ese funcionamiento es la gestión. El contenido principal de la gestión es el control, incluyendo controlar el ritmo del ciclo —ni demasiado rápido ni demasiado lento—, controlar la dirección del desarrollo —solo hacia arriba, nunca hacia abajo—, y controlar la estabilidad de la operación —sin grandes altibajos ni dispersiones momentáneas—.
Y nada de todo esto se ve en este ejemplo.
En el ejemplo de este chiste, todo está impulsado por el trabajo de desarrollo; eso ya es un error de dirección. El producto sirve a los usuarios, por lo que debería estar impulsado por los usuarios y el mercado, y combinado con las propias capacidades para finalmente determinar las prioridades del trabajo. Este error refleja que el directivo no entiende bien lo que gestiona, y tiene que dejarse manipular por los programadores, que saben más del tema; de hecho, aparte de la tecnología, no saben mucho más.
Un directivo que no comprende lo que gestiona no puede gestionar bien.
Esto es algo indudable, pero la industria del software nacional parece no creerlo. Una de las mentiras más nocivas en la industria del software china es: el directivo solo necesita saber de gestión, no necesita saber de tecnología.
En realidad, no es más que algo inventado por esos directivos ignorantes, incompetentes y desvergonzados para engañar y ganar dinero; quien se crea esta frase sin duda pagará el precio en dinero.
En segundo lugar está la gestión de calidad. El sentido común básico de la gestión de calidad nos dice que, antes de que termine cada ciclo, la tarea más importante es resumir y mejorar. Solo así se garantiza que el funcionamiento cíclico se desarrolle hacia arriba, y no hacia abajo sin control. Solo una gestión de calidad eficaz puede garantizar que el proceso iterativo sea convergente y finalmente alcance los objetivos. Pero en este ejemplo, esa parte evidentemente falta; aunque hay un departamento de pruebas, su función es solo el eslabón de inspección de calidad dentro de la gestión de calidad; la parte de gestión sigue ausente.
Luego está la gestión de recursos humanos. El desarrollo de software es un trabajo intensivo en mano de obra; aunque es trabajo intelectual, igual significa que el factor humano ocupa una posición decisiva. En el ejemplo, el programador que no terminó de corregir los bugs recibe la bonificación del proyecto, mientras que los probadores, que trabajaron igual de duro, tienen sus salarios retrasados. Esto no solo muestra que el directivo no comprende su trabajo ni valora la gestión de calidad, sino que también demuestra que el directivo no sabe dirigir gente en absoluto. Es un comportamiento que asesina al equipo: asesinar a un equipo es mucho más fácil que construirlo.
Finalmente, este directivo fracasado convierte su experiencia en este chiste para que todos vean lo mucho que los programadores lo perjudicaron, demonizándolos como un grupo de mentirosos. Pero cualquiera que entienda un poco de gestión puede ver con un simple análisis que son la ignorancia y la incompetencia de esta persona las que causaron su situación actual, y culpar a los demás demuestra aún más su desvergüenza. Como directivo en una posición alta, si ni siquiera quiere asumir la responsabilidad que le corresponde, ¿de qué más es capaz?
Fuente: http://blog.csdn.net/raptor/article/details/727299