¿Será cierto? How system thinking is killing your creativity — Open Participatory Organization — Medium


(Agustin Villena) #1

¿Que opinan?


(David Lay) #2

Me gustó harto el artículo, se conecta con lo que estamos discutiendo en Hacking Cultural Project Aristotle de Google: ¿Que hace a un equipo exitoso o no? ya que habla del concepto de unidad en un equipo y las complejidades de las interacciones, como un sistema dinámico de relaciones de poder y definiciones de identidad, hasta que, de resultar bien, se establece una identidad conjunta como equipo.

Hace un tiempo vi este twitt:

Lo que me hace pensar que las dinámicas de equipo nunca fueron solucionadas mediante el comando y control. Es necesario dar espacio y ambiente a los equipos para que establezcan su identidad por si solos (dentro del contexto de la organización) y no tratar de “asimilar” a los equipos dentro de una identidad postiza.


(Guillermo Schwarz) #3

El enfoque en Scrum es que todas las personas hacen de todo (equipos multidisciplinarios), el que no sabe, aprende, nada de especialistas y conocimiento secreto.

El enfoque de comando y control es muy coincidente. La jefatura asigna y las personas se vuelven intercambiables. O al menos eso se espera, si no funciona, es tú problema (inserte nombre del culpable aquí).

Hasta el momento lo que he visto en Chile es que Scrum se aplica de manera que se espera que las personas interactúen solas de manera natural, no hay expectativas de cómo deben trabajar, lo que obviamente produce desacuerdos.

Pedirle a ingenieros que tengan inteligencia emocional es como pedirle a las piedras que arrojen agua. No va a pasar. De hecho si lo pensamos ¿cuántos equipos de ingenieros en Chile han fundado empresas como Google? En USA hay cientos de empresas partieron así, con ingenieros que partieron con una idea y terminaron con otra.

El artículo parte de la idea de que “system thinking kills creativity”. ¿Pero qué es system thinking?

Pensamiento del sistema… ¿Dónde están los sistemas que piensan? ¿Alguno ha visto algún sistema que piense? Yo no. Y de seguro nadie tampoco. Las personas piensan… a veces.

Lo que sí hay es la teoría de sistemas, que se puede resumir en:

  1. Todo sistema cerrado muere. Esto es lo mismo que la Entropía.
  2. Todo sistema abierto, vive, porque extrae energía del sistema con el que interactúa.
  3. Todo sistema grande que funciona, partió siendo un sistema pequeño que funciona.

Fuente:

  1. http://www.thinking.net/Systems_Thinking/OverviewSTarticle.pdf

  2. http://www.thwink.org/sustain/glossary/SystemsThinking.htm

¿Qué significa system thinking entonces?

Que debes pensar las cosas “holísticamente”, no entender cada uno de sus componentes sino que enteder sus interacciones. Esto es exactamente lo mismo que hacer análisis: no se rían, la palabra análisis viene de ano, anual, anillo (circulo) y lisis (separación). Es decir, rodear el elemento a analizar para entender todas sus interacciones para luego separar en sus componentes y volver a hacer lo mismo.

Es un enfoque superficial de interacciones con el medio externo, que luego se va profundizando. El enfoque opuesto es la síntesis, el pensamiento holístico que busca las interacciones generales y trata de ir creciendo hacia arriba. Si el pensamiento holístico es “system thinking” ¿como podría ser el análisis lo opuesto al system thinking? ¿y ser lo mismo al mismo tiempo? Bueno el paso uno es lo mismo, en system thinking el paso 2 se obvia.

No me gusta el artículo porque ocupa palabras complejas para explicar ideas simples, y usa esas palabras en el borde conceptual, es decir, el artículo está hecho para inducir a errores.

A principios de los años 90 la quinta disciplina y la teoría de sistemas were all the rage. De hecho se podría decir que Agile es system thinking: ir construyendo un sistema que funciona como un hello world desde el día uno y al que se le van ampliando las funcionalidades, si esa idea no es “system thinking”, no sé qué es.

Ahora viene este artículo a contradecir la teoría general de sistemas… No creo que el artículo entienda de lo que se trata agile. No creo que entienda system thinking.

Creo que el problema no está bien planteado. ¿Porqué system thinking podría coartar la creatividad? Si hay un equipo aplicando Scrum o Kanban o Lean Startup, ¿en qué momento se coarta su creatividad?

Como concepto es muy extraño, no junta ni pega. La creatividad tiene que ver con probar cosas nuevas. ¿En qué parte de Agile o Lean dice que no se debe probar? De hecho XP habla de hecar spikes, que son prototipos o pruebas de concepto y que van dentro o fuera de las iteraciones o sprints.

De hecho los sprints the Scrum vienen del deporte llamado Rugby. Scrum es cuando los equipos se pelean la pelota, los equipos se empujan, patean la pelota hacia atrás, alguien de su propio equipo la toma y sale corriendo con ella. Ese “salir corriendo” es el sprint. Bueno y todos salen corriendo detrás de él, en línea, esprando que les pasen la pelota, ya que en Rugby sólo se puede pasar hacia atrás. Y en todos los deportes el momento de sprint dura poco, porque el cuerpo no resiste “sprint all the time”… Sin embargo ahora en Scrum sales de un sprint para entrar en el siguiente, lo que está claramente mal, produce stress, y todos sabemos que la gente con demasiado stress se pelea. ¿Quieren mejorar el trabajo en equipo? Eliminen la fuente de stress. Un equipo estresado termina produciendo basura.

Yo sí estoy de acuerdo con que limitan la creatividad pero es porque Scrum promueve ese reporte diario que implica que todos tus minutos están contabilizados, 5 minutos para esto, 5 minutos para esto otro… en un proyecto anoté todo lo que hacía y cómo perdía días y días con indefiniciones de requerimientos, con mi PC que siempre lo tenían que arreglar y no me lo entregaban por días, el ambiente de programación que era más difícil de instalar que terminar el proyecto, el jefe de proyecto que se empecinaba en que los prototipos tenían que ser finalmente enchufados a los servicios y proyecto terminado y todos los errores en dirección de proyecto imaginables enrollados en un sólo proyecto… y según ellos aplicaban Scrum porque hacían el standup meeting.

Cuando no te dejan tranquilamente crear prototipos te están tratando como si trabajaras flipping burgers en MacDonald. Si el problema es la falta de creatividad, el problema no es system thinking sinó que te quieren sacar el jugo. Trabaja con idiotas y terminarás siendo otro idiota más.


(Guillermo Schwarz) #4

Ok, yendo más al fondo del asunto, la teoría de sistemas no está diseñada para controlar personas, no es el objetivo, y si alguien piensa que se puede aplicar está loco.

Las personas son por definición entes autónomos que funcionan mucho mejor cuando se les da la oportunidad de elegir lo que quieren hacer. Es como la diferencia entre el capitalismo y el comunismo. Los sistemas capitalistas funcionan mucho mejor cuando las personas eligen sus trabajos, en vez de que un líder aplique planificación centralizada y te diga qué estudiar y en qué trabajar.

El modelo de planificación y control sirve para planificar la guerra. Alguien tiene que tomar la decisión de qué y cuándo atacar, qué y cuando defender, etc. Y aún así los generales norteamericanos de la segunda guerra decían que los planes no sirven para nada, hay que botarlos y ver realmente lo que está pasando.

El general no puede decirle al soldado cuando disparar. La guerra así no funcionaría. Sin embargo con Scrum tenemos generales que no planifican la batalla, pero están preocupados de decirte cuando disparar. En otras palabras, son la generación de los video juegos. Tú eres el monito que dispara y los bugs son los marcianos.

La cultura se come a la estrategia para el desayuno. Estoy completamente de acuerdo. Ahora bien: hay 2 interpretaciones para esa frase. Una es que la cultura es más importante que la estrategia y que por lo tanto tenemos que corregir la cultura para que se adapte a la estrategia. La segunda es que la cultura es más importante y tenemos por lo tanto que ignorar la estrategia.

El artículo plantea la segunda opción. En otras palabras si la gente está acostumbrada a escribir bugs, es mejor dejarlo así. Si la estrategia dice “zero defects”, es una estrategia fracasada, porque la cultura nunca lo va a aceptar.

De hecho trabajé en un ambiente así, propuse test unitarios y me dijeron que no, que el cliente pagaba para que arreglaran los bugs, as´que si algún bug se pasaba al cliente por su QA (inexistente), el cliente lo descubría después y pagaba para que lo arreglaran.

¿Qué tal? Fácil y bonito. ¿Y ustedes se llaman a sí mismos profesionales? ¿No les da vergüenza? Obviamente no.

En ninguna parte dice que system thinking sea command and control. De hecho incluso en las organizaciones más horizontales requieres tener control. ¿Qué sacas con tener un equipo sin jefes si no tienes feedback de cómo usan tu sistema, o si realmente lo están usando? Es una pregunta, porque cuando no tienes jefe, entonces todos son jefes, ¿quién toma las decisiones entonces y cómo se ponen de acuerdo si no tienen datos?

De modo que el control es algo natural en toda organización, lo malo es el castigo. Si a la gente la castigas no responde bien. La gente estresada no produce más y lo notas en la cantidad de retrabajo requerido, lo que es aún peor que trabajar lento y con horarios cortos.

Y respecto del command, si vieron Enemy at the Gates, https://vimeo.com/61627520 cuando los soldados se devolvían, los ametrallaban. O sea o los mataba el enemigo o los mataba los jefes. Hay una frase que se llama Death March para representar esto en el software.

En el mundo corporativo existe el equivalente que es el despido. Te sacan del equipo, suerte. El resultado es que el trabajador se estresa, y después HR se pregunta ¿porqué hay tanta mala onda en los equipos de trabajo? Si el trabajador está entre los bugs y la fecha de entrega, supongo que se entiende el problema.

Command and control es bueno sólo si los que están debajo tuyo son robots desechables. Sino, son requirements and control. Requierements porque puede que del otro lado salga lo que quieres como puede que te los devuelvan como “no se entienden”. Control es bueno en el sentido de controlar que lo entregado sirva, pero es malo si tratamos de controlar tonteras como cuando el programador va al baño.


(Guillermo Schwarz) #5

herval ‏@herval 22 Feb 2015
@richardadalton so an immutable list of mutable elements huh? Sounds like a bug waiting to happen!

malinterpretaciones… de malinterpretaciones… de malinterpretaciones…

En general si pones a 2 personas en el mismo puesto, se van a llevar pésimo. Por ejemplo: 2 gerentes de finanzas.

Nadie haría eso, ¿cierto? ¿Porqué?

Porque la decisión que tome un gerente de finanzas va a ser desecha por el otro y vice versa. Eso de 2 cabezas piensan mejor que una es verdad sólo en los dibujos animados, en al vida real, si llegas a hacer algo así, estarás generando problemas de competencia, ego, y falta de decisiones claras.

¿Porqué piensas que en el software podría ser diferente?

Si yo voy escribo una clase y al día siguiente voy a mirar y está cambiada y alguien renombra, mueve, reescribe mi código, el número de problemas que se va a generar es mayúsculo.

No voy a poder encontrar nada.

Sin embargo las metodologías ágiles promueven que el código es de todos, que todos los programadores son full stack y que todo el mundo hace de todo.

Entonces métele threads y adiós proyecto.

Por el contrario lo que yo propongo es dividir las responsabilidades del proyecto en bajo nivel (o frameworks) y alto nivel (o funcionalidad). Las personas que trabajan a bajo nivel son capaces de resolver los temas tecnológicos y presentar interfaces simples a las personas que trabajan en el nivel alto o de negocios.

Así no existe el problema de que una persona va desarma lo que hizo el otro, lo que es tan común en algunos círculos de software.

A todo esto, esos círculos prohiben TDD. Les produce urticaria, porque obviamente todo el código tiene montones de cosas mezcladas unas con otras, cambiar de framework es imposible y el código es una basura.