« TRIZ for couples | Main | 'Gestionando' la creatividad organizativa con Twitter »

01/15/2010

Comments

Mario

Gracias por tu comentario :-)
Y sí, a ver si entre todos conseguimos que algunas cosas cambien :-)

Zalakain

Mario, ya lo comentaremos en persona, pero si estuviera en una charla oyendo lo que acabas de decir ahora mismo estaría gritando "Bravo!" y aplaudiendo :) Totalmente de acuerdo contigo, un post magnífico. A ver si hacemos que algo cambie. Un saludo.

Jaizki

Muy interesante.

Creo que el problema de base es la confusión respecto a para qué sirve el Plan de Negocio. No es para ayudar al emprendedor, es para justificar el sueldo de todos los que lo piden. Y que necesitan algo que tengan cierta apariencia de estabilidad y verosimilitud para justificar sus meteduras de pata… Y claro, llegan a creerse que lo que les sirve a ellos le sirve al emprendedor… Y el emprendedor primerizo, pica como un pardillo porque le parece que esa gente tiene que saber lo que hace…

C’est la vie…

David García Raya

Me verás a menudo. Ya sabes que me interesa tu pensamiento. Sólo un deseo, si alguna vez nos toca tomar decisiones procuremos no caer en lo que criticamos (no pedir el típico BP y estar abiertos al cambio)

Mario

Hombre, David, qué sorpresa encontrarte por aquí :-) Pues esa pregunta que haces me la llevo haciendo yo muchos años, compañero. ¿Por qué seguimos todos enseñando, recomendando, requiriendo enfoques y/o metodologías que la experiencia demuestra inadecuados? No lo sé. Un ejemplo reciente. Una amiga quiere solicitar un aval a Aval Madrid. Le exigen un plan de negocio. Desde la AJE le proporcionan una plantilla para que elabore ese plan, asegurándole de que ese es el modelo que esperan recibir en AM. Pues amigo, tendrías que ver la plantilla!!!
Así no hay manera.

Mi respuesta a esa pregunta es... la causa debe ser la misma por la que cualquier otra innovación, en general [te remito a mi célebre post "Escorbuto", publicado en estas mismas páginas] tarda un tiempo incomprensible en ser adoptada. Creo que las personas al cargo de las instituciones que llevan las riendas de las sociedades pertenecen en su mayoría a esa categoría de personas con aversión al riesgo que se denominan "laggards". Dicho de otra manera, los que toman las decisiones, los que "mandan", no están interesados en que las cosas cambien. Luchan permanentemente para ralentizar el cambio. Lo hacen porque están cómodos con el status quo, pero no sólo por eso; lo hacen también porque sus modelos mentales son muy rígidos. De hecho, están ciegos a las ventajas que pueda traer tal o cual innovación. Es por eso que la sociedad siempre va por delante de sus legisladores, por ejemplo, o por delante de los académicos de la lengua, o de sus gobernantes, o de los "grandes" empresarios, etc.

De todas formas, hay sociedades y Sociedades. No todos los pueblos o naciones son igualmente "impermeables" al cambio.

David García Raya

Me parece buena idea. Realmente lo que haces es aplicar el "sentido común". En una organización viva con un entorno cambiante (cada vez más cambiante y en menos tiempo), de poco sirve fosilizar planes trianuales que luego la realidad se ocupa de dejar inservibles. Pero la cuestión es: si esto parace lógico y evidente, ¿por qué seguimos empeñados en mantener el mismo esquema en BP?. Si las empresas conocen (o pueden cocner) cuales son las herramientas útiles para el "manejo" de su capital humano, ¿por qué hacen lo contrario?. Creo que en el día a día reaccionamos de forma impulsiva, con funcionamiento y soluciones "tradicionales" y dedicando poco tiempo a pensar, alejándonos de todo esto que propones.

Mario

Joserra, gracias por tu comentario.
Creo que alguna vez te comenté que mi experiencia en metodologías ágiles es SOBRE TODO fuera del ámbito del desarrollo software. He utilizado metodologías ágiles en I+D+i, en selección de Recursos Humanos, en elaboración de presupuestos y control presupuestario, en entornos de fabricación (make to order), como estrategia para inversiones en start-ups o en creación de empresas. En cada caso tienes que hacer un trabajo de selección de técnicas y metodologías, a veces procedentes de otras disciplinas [ej., Buffer Management de TOC], pero siempre manteniéndote fiel a los principios fundamentales.

Cuando quieras hablamos un día de todo esto. Con una cerveza, claro.

Joserra

En agile-spain, que hablamos de las metodologías ágiles en el desarrollo de software, cada vez se pregunta más por su aplicación en otros tipos de proyectos. La verdad que esta aplicación que comentas, parece muy provechosa, veo la creación de una empresa como una innovación al fin y al cabo.
Para conseguir objetivos difusos, o lejanos, funcionan muy bien ponerse metas pequeñas y a corto plazo. Scrum ha conseguido popularizarse para dar el empujón definitivo a las ágiles.

Y tomo nota ;)

 Mario

Amalio, gracias por tu comentario. Estaría encantado de conocer algo más de lo que estás haciendo o has hecho en este sentido. Cuando quieras dedicamos un rato a intercambiar impresiones :-)

 Mario

Por cierto, JM, olvidé comentarte los problemas que sí me he encontrado... por ejemplo, Scrum está pensado para que lo utilice un equipo de personas cualificadas, profesionalmente 'maduras' [no me refiero a la edad, sino a disciplina, etc] y formadas en la metodología. Esto último, la formación, puedo proporcionarlo hasta cierto punto, pero no lo primero.

Además, el trabajo no depende, como en el caso del desarrollo soft, exclusivamente del equipo de desarrollo, sino que frecuentemente depende de plazos marcados por la Administración o terceros como VCs o proveedores. Pero esto se puede resolver.

Amalio A. Rey

Excelente, entrada, Mario. Estamos en la misma linea, suscribo casi todos tus planteamientos. Precisamente llevo en estos dias hablando de estos temas, en alguna formación que he dado, e insistiendo en la necesidad de aligerar los planes de negocio, y concederle la importancia que merecen. Pienso que algunos emprendedores necesitan PN más largos, como herramienta de aprendizaje, mientras que otros más cortos. En cualquier caso, el PN se debe concebir desde la optica de "build to think" más que desde la perspectiva "build to communicate" en la que siempre se insiste. Enhorabuena por el post, es muy util!!!

Mario

JM, gracias por tu comentario.
Conozco Lean, por supuesto. De hecho, lo conozco de cuando no era Lean, sino Toyota Production System. He aplicado principios de lo que ahora se llama Lean [Manufacturing]tanto en entornos de producción como de servicio desde mediados de los 90. Prácticamente la panoplia al completo, desde las 5S hasta el Kanban. Desde el Value Stream Map hasta el "equilibrado de líneas" [craso error, como demuestra TOC] No hay ninguna razón para que un proyecto de start-up no pueda beneficiarse de la aplicación de estos principios, es cierto.

Eso sí, a lo que me refiero en este post es a la gestión del proyecto de creación y desarrollo de la empresa en sus primer(os) año(s) de vida. Créeme, este escenario también lo conozco muy bien. No estoy hablando de una empresa madura que se plantea un CMMI, sino del período que va desde la idea hasta, por decir algo, la estabilización de la generación de Free Cash Flow, un período que según la naturaleza de la iniciativa puede llevar desde unos pocos meses a varios años.

Como consecuencia de los sucesivos ciclos de Release Planning, Iteration Planning, etc, el equipo emprendedor [típicamente no más de 5 personas] irá desarrollando e implantando procesos más "elaborados" de gestión, según sus necesidades. Por ejemplo, todos los relacionados con el manejo de la tesorería, en el sentido más amplio del término [desde compras a facturación]. Por ejemplo, los relacionados con la identificación de necesidades de recursos, en general, y de RRHH en particular.

Como digo, la definición más formal de esos procesos surgirá de forma natural, demandada por las circunstancias de la empresa según se desarrolle.

En el diseño de esos procesos, por supuesto, podrán tener en cuenta principios de Lean y, si son listos, de TOC.

De nuevo, gracias por tu comentario... creo que ahora está más claro :-)

JM

Mario, como bien dices, la aplicación de SCRUM a nivel de gestión de empresa es sin duda, mucho más inteligente que seguir las prácticas absurdas que se suelen exigir (y se siguen practicando sin rechistar).
Sin embargo, piensa que SCRUM se diseñó para gestión de proyectos, y aunque podemos considerar la empresa como un proyecto (al fin y al cabo, es un macro-proyecto, compuesto de micro-proyectos), quizá a nivel de gestión global encajen mejor los principios de Lean, que funcionan más como un modelo adaptable que como un conjunto de prácticas definidas.
De hecho, empresas high-maturity-agile (: suelen utilizar Lean para la capa de negocio, SCRUM para la de proyectos y Extreme Programming para la capa técnica (más o menos las tres áreas fundamentables que propone ScrumManager)

Estupendo post, como siempre.

Un saludo!

JM

The comments to this entry are closed.

Categories