Una cruz (+) significaba que el mensajero podía ir al destino en pasos, dos cruces (++) significaban un lince, tres cruces (+++), un galope inmediato. Por lo tanto, el galope en el ejército se llamó extraoficialmente el encanto de las tres cruces , y más tarde esta expresión entró en el idioma ruso, lo que significa la ejecución más rápida de las órdenes de las autoridades. [Wikipedia]
Tar pit (en inglés, literalmente alquitrán de alquitrán ) - 1) un problema insoluble, 2) un lago de betún (un lugar donde el betún subterráneo sale a la superficie, creando una sección de asfalto natural). [Diccionario inglés-ruso] Los animales atrapados en el betún no pueden salir, por lo que estos lagos son un gran lugar para excavar esqueletos prehistóricos [Wikipedia].
“La imaginación representa dinosaurios, mamuts y tigres dientes de sable que intentan liberarse de la resina. No importa cuán fuerte o ágil sea la bestia, al final estará destinado a la muerte. En la última década, este pozo de alquitrán ha sido la programación de grandes sistemas ... ” [1, p.16] Con esta sorprendente imagen, comienza el clásico libro de Frederick Brooks, vio por primera vez la luz en el lejano 1975. Otro libro clásico, publicado en el mismo antiguo 1987, no comienza mejor: "Y en ese momento el proyecto se está muriendo en alguna parte" [2, p.23]. Pasan los años, la humanidad entra en un nuevo milenio, pero en 2014 otro éxito de ventas comienza con la misma historia eterna: "El 3 de marzo de 2010, la Oficina Federal de Investigación decidió suspender su plan prometedor a gran escala para modernizar la gestión de la información ... La oficina intentó actualizar su sistema informático durante más de diez años, y parece que les ha sucedido una catástrofe ” [3, p.14].
44 años después de Brooks, podemos, con la conciencia tranquila, repetir: ahora, cuando lees estas líneas, el próximo proyecto, como sus predecesores, se está hundiendo en el mismo pozo de alquitrán . Las posibilidades de éxito en la gestión de proyectos son menores que al lanzar una moneda, y no parece crecer mucho:
De acuerdo con los estudios CHAOS de Standish-Group [4]
¿Por qué el progreso en la ciencia de la gestión (incorporado en 6 ediciones de PMBoK y varias docenas de otros libros gruesos) durante 40 años (!) ¿Nunca condujo a una mejora en la calidad de la gestión en sí misma (a menos que, por supuesto, por la calidad de la gestión se entienda la probabilidad de llegar a un punto dado)? Para abordar este problema, comenzamos con el problema principal de cualquier proyecto, identificado en todo el famoso libro de Brooks.
El primer problema: la complejidad del producto que se está creando.
Si le preguntas al primer especialista de TI que se encontró: "¿Qué es lo principal en el mes del hombre mítico?" - es probable que la respuesta sea: "Que todos los meses hombre son diferentes, los nuevos trabajadores no son lo mismo que los viejos". Incluso Brooks llama a la "ley" la disposición formulada al comienzo del libro ("Si el proyecto no cumple con los plazos, entonces agregar más mano de obra lo retrasará aún más"). Pero esto es solo una observación empírica, conocida por todos que al menos una vez "cambió de caballo en el cruce"; La pregunta es cómo planificar un proyecto cuando todos los meses-hombre son diferentes.
El "mes-hombre mítico" se convirtió en un éxito de ventas, lo que da una respuesta a esta pregunta. Así es como Brooks formula su comprensión de un problema de diseño básico:
"... las dificultades clásicas del desarrollo de software se derivan de esta complejidad de la entidad y su crecimiento no lineal con un tamaño creciente. La complejidad causa dificultades en el proceso de comunicación entre los miembros del equipo de desarrollo, lo que conduce a errores en el producto, que exceden el costo de desarrollo y retrasan la ejecución de los horarios de trabajo. La complejidad es la razón las dificultades de enumeración, y aún más la comprensión de todos los estados posibles del programa, y por lo tanto, surge su falta de confiabilidad ... La complejidad de la estructura causa la dificultad durante el desarrollo de programas y la incorporación de nuevas funciones para que no haya efectos secundarios ... " [1, p. 167]
La diferencia fundamental entre el proyecto y cualquier otra producción es que el proyecto creado en él se produce por primera vez [somos conscientes de que muchas tareas como "atornillar el contador de visitas al sitio" también se llaman "proyectos", pero estamos hablando de proyectos reales]. Como cualquier cosa real, este nuevo producto (ya sea software o hardware) está compuesto por una gran cantidad de componentes capaces de las interacciones más inesperadas (negativas - talidomida y positivas - viagra). Es extremadamente difícil prever cómo funcionará todo esto en conjunto, y esto literalmente requiere "mejores mentes" y no interminables "meses-hombre":
“Los proyectos sobresalientes son creados por diseñadores sobresalientes. Crear programas es un proceso creativo. Una metodología sólida puede potenciar y liberar la mente creativa, pero no puede inflamar o inspirar a alguien que está ocupado con un trabajo tedioso ... Por lo tanto ... creo que el único y más importante esfuerzo que podemos hacer es desarrollar formas de educar a los diseñadores sobresalientes " [1 p. 185-186]
Desde la posición básica de Brooks (el diseño es creatividad y el proceso creativo no puede ser llevado a cabo por la multitud), todo el contenido real del "Mes Mítico del Hombre" sigue directamente: los requisitos de la "dictadura de los arquitectos" y "el efecto del segundo proyecto", y la recomendación "planear tirar la primera versión" . Pero también sigue la tesis más olvidada de Brooks: que en la gestión de proyectos "¡no hay bala de plata ! " La complejidad de los proyectos es objetiva, no se puede superar ni con la ayuda de nuevos lenguajes de programación (incluso gráficos) ni conectando la inteligencia artificial. Es necesario hacer frente a la complejidad cada vez más, y si el talento del diseñador no es suficiente para esto, el proyecto no tendrá éxito.
El principal enemigo del proyecto Brooks es la complejidad del producto que se está creando . Con cada línea de código nuevo, con cada página de documentación tecnológica, esta complejidad crece y crece de forma no lineal. Y al mismo tiempo, el gerente tiene a su disposición menos recursos, tanto el tiempo restante hasta el final del proyecto como el dinero restante hasta el final del presupuesto:
En el punto de intersección, o poco antes, queda claro que el proyecto realmente requiere mucho más dinero y tiempo del que se pretendía originalmente:
El siguiente proyecto, llamado "Sentinel", comenzó el FBI de inmediato, en 2005. El precio de la emisión es de $ 451 millones, y el sistema Sentinel estará en pleno funcionamiento en 2009 ... En marzo de 2010, Lockheed Martin, el contratista, llegó tarde el año completando solo la mitad del proyecto y gastando 405 millones. Para completar, según expertos independientes, tomaría otros seis a ocho años y $ 350 millones adicionales. [3, p.17-18].
Pero déjame! Si, desde 1975, sabemos que la complejidad de los proyectos está creciendo, por ejemplo, de forma cuadrática, ¿qué impide que el presupuesto y el equipo se incrementen de forma cuadrática ? ¿Por qué todas las nuevas generaciones de gerentes continúan liderando proyectos con un éxito previsto del 30%, cuando solo se puede agregar dinero ?
Ahora, es hora de pasar al siguiente libro.
El segundo problema: la complejidad de la colaboración.
Como ya sabemos, el bestseller de fama mundial Peopleware ("dotación de personal" traducido al ruso como "Factor Humano"), que apareció doce años después del Mes del Hombre Mítico, comienza con una declaración de la alta tasa de mortalidad de los proyectos. "Alrededor del quince por ciento de los proyectos terminaron en nada ... En el caso de proyectos grandes, la situación es aún peor, el colapso comprendió el veinticinco por ciento de los proyectos, cuya duración varió de veinticinco años-persona" [2, p.24] Esto fue escrito en 1987 (la URSS todavía estaba viva !), con referencia al estudio de 1981 (Brezhnev todavía estaba vivo); y que tenemos hoy
Según el Informe CHAOS 2015 [5]
El desarrollador promedio de hoy cuesta $ 100K por año, agregando gastos generales, obtenemos que 25 años-persona son alrededor de 3-6 millones de dólares. Como puede ver, la situación no ha cambiado desde esos largos años: el 26% de los proyectos medianos y el 43% de los proyectos grandes esperan un fracaso, y no hay nada que podamos hacer al respecto. ¿Pero por qué está pasando esto? Demarco y Lister preguntaron a los desarrolladores sobre los motivos de las fallas, y esto es lo que obtuvieron en respuesta:
“En la gran mayoría de los casos, no hubo una sola razón para el fracaso del campo de la tecnología. Muy a menudo, los participantes en nuestras encuestas llamaron "política" como la causa del accidente
¡No se trata en absoluto de la complejidad del producto que se está desarrollando, y no de la insuficiencia de recursos, como cabría esperar al mirar la Brooks Cross! "Política", la relación entre las personas dentro y fuera del equipo (lo que Demarco y Lister preferían llamar "sociología"): esto es lo que, según los desarrolladores, impidió el éxito sobre todo.
Piense en este hecho : esas mismas personas (desarrolladores, jefes y clientes) que a primera vista estaban más interesadas en el éxito, se unieron por el bien del proyecto, organizaron "política" en él, lo que llevó al proyecto al colapso. "Nos encontramos con el enemigo, y él somos nosotros" [6]; El proyecto reveló el segundo peor enemigo: su propio equipo.
Es intuitivamente claro que cuantas más personas participen en un proyecto, más tiempo tendrán que dedicar a organizar el trabajo conjunto y menos, en realidad, a desarrollar un producto. La pregunta es cuánto menos:
Fig. 2 del artículo Putnam, Myers [7]
Después de recopilar las características numéricas de 491 proyectos de desarrollo de software de 35 a 95 mil líneas de código, Putnam y Myers obtuvieron resultados que son casi imposibles de creer. Los proyectos de tamaño comparable fueron completados por equipos de diferentes números casi al mismo tiempo, y los equipos de números más grandes no necesitaban menos, sino más tiempo. La ley de Brooks ("agregar desarrolladores - ralentizar el proyecto") funcionó no solo con la amenaza de interrupción del proyecto, sino desde el principio , comenzando con la incorporación del noveno programador. Si presenta los mismos resultados en términos de los notorios meses-hombre, obtendrá un horario aún más expresivo. Cuánto dinero (en salarios mensuales) se requiere para resolver el mismo problema por equipos de diferentes números:
Fig. 3 del artículo Putnam, Myers [7]
Los datos obtenidos se ajustan aproximadamente a un patrón completamente fantástico: la productividad de un desarrollador en un equipo es inversamente proporcional a su tamaño. En este caso, el período de desarrollo será el mismo para cualquier equipo, que es aproximadamente lo que demuestran los datos de Putnem y Myers. Lo creas o no, el asunto personal de todos; pero incluso si no lo cree, debe admitir que el tiempo dedicado a la política crece de manera no lineal con el tamaño del equipo y, por lo tanto, queda mucho menos tiempo para trabajar realmente en equipos grandes.
El libro de Demarco y Lister contiene muchos ejemplos de "sociología", que reemplaza el trabajo en el proyecto con el trabajo de mantener el "orden" en el equipo. Oficinas de espacios abiertos, donde los jefes pueden ver quién se aleja del trabajo (y los empleados se distraen constantemente); planificación detallada y requisitos constantes para cumplir con los plazos (date prisa y lleva a un aumento en el número de errores); pequeña regulación (lo que hace que pase mucho tiempo informando sobre el trabajo realizado y cambiando la motivación de los empleados del código al "papel"). Todas estas medidas parecen necesarias para la organización del trabajo conjunto, pero, cuando se aplican por completo, ya no dejan tiempo para el trabajo en sí.
Ahora podemos entender por qué el método de "solo agregue dinero" no funciona. Un aumento en el tamaño del proyecto con la organización moderna del trabajo (espacio abierto, plazos ajustados, informes detallados) no conduce a un aumento significativo en la productividad. Por el contrario, cuanto más grande es el equipo del proyecto, mayor es el riesgo de que se revuelva por completo en el papeleo al acordar quién está haciendo qué y de qué lado está el problema. La cruz de Demarco pone fin a los intentos de aumentar la efectividad de los proyectos de una manera "extensa".
Pero, ¿qué pasa si cambiamos los principios mismos de organizar actividades conjuntas? Demarco y Lister recomendaron esto en 1987: para gestionar eficazmente a las personas en el campo del trabajo intelectual, es necesario tomar medidas opuestas a las enumeradas anteriormente. [es decir regulación, estandarización, trabajo bajo pena de despido y prohibición de cualquier iniciativa]. Se supuso que en Peopleware estaba escrito con bastante claridad cómo deberían ser las medidas "opuestas" [de hecho, no]. Veamos nuevamente el gráfico de éxito del proyecto. ¿Y dónde se incluye el resultado del libro en la lectura obligatoria de cualquier gerente? Algo que no hay que ver.
¿Entonces por qué? ¿Existe realmente otra cruz en el camino hacia la gestión efectiva de proyectos?
Tercer problema: la dificultad de planificar un nuevo
A primera vista, el tercer obstáculo para la gestión perfecta del proyecto es la naturaleza inusual de la forma correcta de guiar el proceso creativo. Uno de esos métodos, ahora conocido comúnmente como Scrum, se describió en un artículo [8] en 1986, incluso antes del lanzamiento de Peopleware. En pocos años, en 1993, Jeff Sutherland utilizó por primera vez elementos individuales de Scrum en su proyecto, y quedó satisfecho con el resultado:
Entregamos el producto de software a Easel a tiempo, dentro de los seis meses, sin exceder el presupuesto y con un número mínimo de errores; nadie podía hacerlo antes.
Sin embargo, una descripción detallada de las ideas principales de Scrum se publicó solo veinte años después , el otro día, en 2014 [3]. Todo este tiempo, Scrum existió como una metodología semi-sectaria, transmitida literalmente de maestro a alumno, y ganó popularidad exclusivamente de boca en boca. La cuestión es que el concepto principal de Scrum, que se deriva directamente de su filosofía, no encaja en ninguna lógica de control razonable:
Esto es lo que repito constantemente al liderazgo: "Solo puedo nombrar la fecha límite cuando veo cuán efectivo actuará el equipo" [3, p. 28).
Si entendemos por "gestión de proyectos" que garantiza la creación de un producto con propiedades específicas a tiempo dentro del presupuesto, ¡resulta que Scrum no es "gestión" en absoluto! El centro de la filosofía de Scrum es una negativa categórica a proponer una "fecha límite predeterminada" desde el techo (aislada del equipo real y su desempeño), y la primera consecuencia de esta negativa es un enfoque completamente no convencional para la planificación de proyectos:
Fui al jefe de la compañía y dije que estamos abandonando las listas de Gantt. Indignado por lo que escuchó, exigió una explicación.
- ¿Cuántos gráficos de Gantt has encontrado para tu carrera profesional? Pregunté
"Con cientos", dijo.
- ¿Cuántos de ellos eran verdad?
"Ninguno", respondió, pensando por un momento.
Luego le expliqué que, en lugar de gráficos y tablas innecesarios, para fin de mes le daremos parte de un sistema completamente funcional, que él mismo podrá probar y ver por sí mismo si el desarrollo está en la dirección correcta " [3, p.50]
En una historia contada por Sutherland, el jefe accedió a intentarlo. Pero sabemos cuál es el "error de los sobrevivientes", y somos conscientes de que hay diez de cada uno de esos jefes que enviarán a ese "gerente de proyecto". ¿Qué tontería, para pagar dinero honestamente, que "trabajaremos y mostraremos algo en un mes"? ¿Qué idiota hace eso?
Por el libro de Sutherland, sabemos con bastante precisión cuál: el que ya intentó hacer el proyecto de una manera clásica y sufrió un fracaso catastrófico. Solo un líder arrinconado, que no tiene nada que perder, se atreve a abandonar el principio básico de "recursos de administración, solo bajo el plan para su uso". Por supuesto, después de veinte años de usar Scrum, la actitud hacia él ha cambiado un poco, pero incluso hoy en día la mayoría de las conversaciones "nombraré el término y la cantidad cuando reúna al equipo y empiece a trabajar" corren el riesgo de esto.
La ideología de Scrum es tan contraria a las ideas generalmente aceptadas sobre el proyecto ("El cliente acepta pagar y el Contratista hace el siguiente trabajo ...") que es hora de hacer la pregunta: ¿por qué Sutherland se vio obligado a dar un paso tan revolucionario? ¿Realmente era imposible dejar las listas de Gantt "por un momento" y concentrarse en organizar el trabajo del equipo (por ejemplo, en las reuniones diarias, en las que muchos ven lo más importante en Scrum)?
A juzgar por la vehemencia con que Sutherland ataca en su libro "Gantt Charts", uno no puede:
Al gestionar proyectos, se requieren tradicionalmente dos cosas: responsabilidad y previsibilidad. Tal enfoque conducirá inevitablemente a la aparición de una gran cantidad de documentación, tablas y diagramas ... Se gastan meses de trabajo para proporcionar todo hasta el más mínimo detalle, evitar un mal funcionamiento, no sobrepasar los recursos financieros y avanzar según el cronograma. [3, p.23] El único problema es que tan pronto como este plan perfectamente perfeccionado se enfrenta a la realidad, inmediatamente se desmorona. Pero en lugar de tirar a la basura tanto el plan en sí como su enfoque, los gerentes fingen que el plan funciona ... De hecho, les pagan a las personas por mentirles . [3, p.20]
Pagan por mentirles, ¡esa es la cosa! ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] ., . « : », , -, 2005
- [3] , . "Scrum. », ., , , 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] CHAOS REPORT 2015
- [6] We have met the enemy
- [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
- [8] , « : » (1986),
- [9] .. « !», ., 1966