Financiación:Patrones de apredizaje/Pequeña guía para proyectos malos

This page is a translated version of the page Learning patterns/A short guide to bad projects and the translation is 67% complete.
Outdated translations are marked like this.
Other languages:
English • ‎dansk • ‎español • ‎français • ‎नेपाली • ‎中文
Un patrón de aprendizaje paraorganizational
Una pequeña guía para proyectos malos
The Crooked House of Sopot, Poland (3173810231).jpg
problema¿Todo está funcionando correctamente?, ¿tu equipo está aburrido?, ¿estás ejecutando un proyecto impecable?, ¡No te preocupes! Aquí hay un resumen de equivocaciones para escoger. ¡Siéntete libre de usar, compartir y complementar!
soluciónSolo sigue las instrucciones de este patrón de aprendizaje y no tienes que preocuparte de estropear el mejor proyecto que nunca has tenido. ¡Elige el error que parece más atractivo y desafiante para ti y tu equipo!
creado10:28, 26 September 2016 (UTC)
estado:DRAFT

¿Qué problema resuelve esto?

Este es el segundo patrón de aprendizaje en la serie de de patrones que te ayudará a estropear las cosas. Mientras el primer patrón se centró en eventos, este posee una aproximación más amplia y provee instrucciones de cómo ejecutar proyectos realmente malos. El patrón de aprendizaje es el resultado de las sesiones colaborativas durante la reunión 2016 del CEE en Armenia y resume la experiencia de los Wikimedistas de los diferentes rincones del Wiki-universo.

¿Cuál es la solución?

Un buen proyecto sin sobresaltos en el camino -vamos a asumirlo- es aburrido. Si estás buscando algunos errores estúpidos (que pueden ser evitados, pero no lo fueron) los cuales generaron un pequeño desafío. ?¡Siéntete libre de usar, compartir y complementar!

Visión general

Condiciones generales
  • Crear una atmósfera de trabajo intoxicante
  • Asegúrate que hay una infraestructura realmente mala
  • Siempre ignora los plazos
  • Nunca decidas cosas ni tomes acciones ni responsabilidades
  • Create budgets and time estimates that are highly optimistic.
  • Underestimate the probabilities and significance of risks.
  • Ignore legal risks.
  • Use technologies that are expensive, unreliable, difficult to learn, and not maintained; have poor performance; and have publicly known security and privacy vulnerabilities.
  • Frequently disregard standard operating procedures and established best practices.
Equipo
  • Delega todo el trabajo en UNA persona
  • No necesitas experiencia real para ejecutar un proyecto, así que solo elige a las personas que más te agradan
  • Mantén la comunicación del equipo al mínimo
  • Espera que las personas hagan las cosas por ti - no hay necesidad de preguntarles antes
  • Add or remove people from the team without notifying or consulting others.
  • Assign critical parts of the project to someone who is also working on other important projects so that the person is spread too thinly to be effective at anything.
  • Spend significant amounts of time on bikeshedding.
  • When something goes wrong, focus on blaming someone rather than fixing the problem.
  • Say that you'll be available and then become unresponsive. Do this repeatedly.
  • Have vague and/or conflicting expectations for priorities and performance. There is a bonus for assigning multiple managers with competing priorities to supervise one person.
Comunicación
  • No hagas preguntas
  • Mantén tu proyecto lo más secreto posible
  • Ignora todas las preocupaciones y retroalimentación desde el interior y el exterior del equipo
  • Enfócate en lo negativo - entrega retroalimentación disruptiva
  • Evita toda la documentación acerca del proyecto
  • Start work without a communications plan.
  • Wait until the last minute to request feedback, or request feedback only after significant amounts of time and money have been expended.
Aprendizajes
  • Pregúntate PORQUE haces este proyecto solo cuando este finalizado
  • Asume que lo sabes todo
  • ¿Falló un proyecto anterior? ¡Hazlo nuevamente sin cambios!
  • O -incluso mejor: nunca busques proyectos similares hechos por alguien más. Si crees que fue exitoso, haz todo diferente.
  • Don't document what you learn.

Explicación más detallada

It is impossible to make anything foolproof because fools are so ingenious.

- Artur Bloch, Murphy’s Second Corollary

Condiciones generales
Crea una atmósfera de trabajo intoxicante Motivating and supportive working atmosphere is only for the weak, right? You are strong, right? A good background setting is a proper “it-is-not-possible-mentality” which should be shared with all team members from the beginning of the project and throughout its activities. And if things do go wrong, it is so good to add some “told-you-so-communication” to the mix. By implementing this wonderful approach you can feel the tension growing and air thickening and thus project management becoming much more interesting!
Asegúrate que hay una infraestructura realmente mala Atmosphere may be important in creation of general background for a project, but infrastructure is its backbone. Nothing is as boring as to work with projects with good infrastructure, but if you start meddling with cornerstones of the general structure, things get much more interesting. Mix up financial management and communication processes, cancel all contracts and agreements related to the project ... Actually make sure there is no clear structure at all, because improvisation skill is what separates wheat from chaff!
Siempre ignora los plazos You may have heard that timeline is really important for projects. That is true, but remember that following the timeline is only for boring people. You have to “like the whooshing sound they make as they fly by”[1] and to see your partners and team members go mad about missing reports and undone activities. Are you strong enough to endure the real stress? Remember that the best and most renowned leader is the one who saves the team on the last minute … or even later!
Nunca decidas cosas o no tomes acciones ni responsabilidades You know the story about Everybody, Somebody, Anybody and Nobody? You probably understood the first time you heard it that it is much more interesting in real life situations than being just a story. Probably you started thinking about situations when similar thing happened to some project you were involved with. So why not to make this story a mantra of the project team and implement principles of indecisiveness, inactivity and irresponsibility. Threefold increase in interestingness of project guaranteed! Because “left to themselves, things tend to go from bad to worse”[2] and this is when excitement begins.


Equipo
Delega todo el trabajo en UNA persona Delegating is for fools and lazy people - so just do as many things or even better everything yourself. Yes, it might be a bit risky for the project, as things would go downhill when you get sick or have not enough time to do all the things you wanted to do, but that can be dealt with by luring yourself into the belief that you are in control of all this. So no need to worry! In case it can’t be avoided (e.g. when you decide you need a little break after all) you could also put the workload on one (and only ONE) other person, ideally a control freak like yourself, who always tends to have too much on his or her plate anyhow (so they are used to it). Loads of fun guaranteed for at least one person and if there are other stakeholders - it is time to take out the popcorn and to enjoy the show!
No necesitas experiencia real para ejecutar un proyecto, así que solo elige a las personas que más te agradan Financial, organizational, or technical expertise is generally overrated - so in case you missing some of it in your team, don’t let that bother you. There is nothing that can’t be solved with a bit of googling and research! And after all you have managed many unsuccessful projects before and you learn best from the mistakes you make, right? So you don’t actually need background knowledge and skills that could save you and your team time, money, and the sensation of being overwhelmed by some tasks. And admit it, having experts on your team who already know how to do things would be really boring. It is much more fun to figure it all out yourselves.
Mantén la comunicación del equipo al mínimo A little less conversation, a little more action please! Communication takes too much time and it can be tiring to get crucial information from people and to people. So let everybody focus on their tasks! Misunderstandings and bottlenecks may not be so easy to deal with once they occur, but challenges can be overcome with some more action! No need to waste time trying to prevent them beforehand. This is what boring people do.
Espera que las personas hagan las cosas por ti - no hay necesidad de preguntarles antes If people did things for you in the past (updating wikipages, programming websites, being mentors at an edit-a-thon for newbies etc.) there is no reason not to assume they wouldn’t do it again. So why waste your and their time by double checking that they are actually willing to help you out or even have a leading role in your project. Just assume they know what to do and when - what could possibly go wrong?


Comunicación
No hagas preguntas You know everything - and even if you don’t, do not ever admit it! This would be a sign of lacking self-confidence, but you believe in yourself, right? Asking questions to make informed decisions would also look like a sign of lack of expertise. Instead improvise! Make uninformed and thus wrong decisions! Do work that has already been done by others! Take your time near deadlines, shut yourself in your office in an attempt to make sense of stuff you don’t understand yourself! Make your life and that of your team members living hell! Just make sure to stick to that simple rule and make your projects much more fun.
Mantén tu proyecto lo más secreto posible Working collaboratively with partner organizations, contractors and volunteers sounds nice on paper - but things get complicated because other people don’t necessarily share your view or approach on the project, or might ask some too valid and thus extremely annoying questions about crucial aspects of the project. So cover it up, keep it on the hush - there is no rush in sharing the cup. Also, making sure your funders know in advance that you need resources from them (and when and how much) is completely overrated. The project is so good that they just have to fund it and keep funding, because even you don’t know how long it will last and how much will it cost. Telling the secret beforehand would ruin the wonderful surprise!
Ignora todas las preocupaciones y retroalimentación desde el interior y el exterior del equipo This goes hand in hand with keeping your plans secret from other stakeholders - the fewer people know about your project, the less risk you run to get insightful, helpful, or constructive feedback. In case this feedback still makes it through to you, just ignore it. Remember: You know best! You might not run a perfect or even good project - but you did it your way - just like Frankie Boy. And every project team member and stakeholder should know that it’s your way or the highway!
Focus on the negative and get the blame game going

Make sure not to waste time on complimenting your fellow team members on their big and small successes during the project or spreading confidence and assurance when your team is in need of it. Rather make sure to point out every little flaw in the project or other people’s work - ideally more than once of course. Never let go of the chance to emphasise lack of competence of other project team members. Continuous criticism will toughen up the project team and increase your self-esteem, so focusing only on the negative only has positive effects, right? And hopefully your negative attitude is contagious and gets the blame game ball rolling. And once it has started it won’t stop. Extreme fun guaranteed, because the blame game is not one of the favorites of people all around the world for no reason!

Evita toda la documentación acerca del proyecto After the project is finished don’t invest your precious time in documenting your project or your learnings and experiences. In case you will run a similar project in future you’ll surely remember all the details or happily invest time to trace them back and everybody else can figure out how things work themselves. There is a little explorer in everyone of us, right? And reporting is only for insecure project managers anyway. You know how well you have done and that “practice is the sole criterion of truth”[3]. Let the results speak for themselves!


Aprendizajes
Pregúntate PORQUE haces este proyecto solo cuando este finalizado Project management is not philosophy 101 - asking yourself esoteric questions like “Why should we do this project?”, “What is the goal?”, “How we should reach it?, “What is the logic behind our action model?” etc. is just a giant waste of time. It is the same as to ask oneself “Why is there something rather than nothing?”, yada yada yada, blah, blah, blah. Time is gold and there is no need to waste valuable project time on impractical philosophical questions. Acting is much more interesting. And if someone happens to ask some questions, then there is enough time to come up with an answer to them after the project.
Asume que lo sabes todo Learnings? Why bother when you already know it all. It’s also bad for your image because it would mean admitting your work is not perfect and that there were mistakes and shortcomings. Of course a failed project is also not exactly building positive reputation, but then you can always blame it on the circumstances (popular: the weather or force majeure) or others, ideally people who are not present and can’t defend themselves (popular: incompetent politicians, mischievous pixies).
¿Falló un proyecto anterior? ¡Hazlo nuevamente sin cambios! All mistakes have been done before but not by everybody - so just because other failed with a certain approach it doesn’t mean you can’t do it again. The best and easiest way to run a bad project is to copy previous bad projects and epic fails - you can’t go wrong with that! So are you smart enough to escape from pitfalls that have ruined other projects? Can you kill the Minotaur and escape without Ariadne’s thread? Challenge accepted!
O -incluso mejor: nunca busques proyectos similares hechos por alguien más. Si crees que fue exitoso, haz todo diferente. You can’t stop people from giving you advice or sharing their experiences with you. Especially, if they did similar projects the temptation for them is just too high. But that doesn’t mean you have to follow that - actually it’s probably better to do the exact opposite just to prove a point. After all, just copying a recipe for success is for beginners, you want to challenge yourself like a real pro and encounter and tackle every possible challenge and mistake yourself - at all costs!

¿Cuándo utilizar?

¡Los errores pueden ser aplicados a cualquier proyecto, programa o plan anual!. ¡Disfruta las experiencias de proyectos más emocionantes!

Examples

Grants:IEG/Motivational and educational video to introduce Wikimedia[4] suffered from highly optimistic estimates for time and budget requirements, and was largely dependent on the availability of one person who was working on multiple projects.

Respaldos

--Anna Torres (WMAR) (talk) 00:49, 27 September 2016 (UTC)

I do love the description of this learning patter, it really does show the worst scenario in every perspective. --Liang(WMTW) (talk) 03:47, 4 October 2016 (UTC)

I have successfully applied this pattern in many situations. --Daniel Charms (talk) 21:26, 16 November 2016 (UTC)

Anthere (talk) 10:04, 13 June 2017 (UTC)

This learning pattern provides some excellent advice, and I have added a few suggestions of my own based on recent experiences as well as general observations about projects inside and outside of the Wikimedia universe. --Pine 20:43, 29 August 2017 (UTC)

One of the most lovely and instructive learning patterns ever. :) Spiritia 20:32, 18 May 2018 (UTC)

  • This accurately describes much of my work. Bonus points for projects adding unnecessary dependencies or with dependencies that are impossible to meet. Also scope creep. -— Isarra 19:38, 9 January 2019 (UTC)

Véase también

Patrones relacionados

Enlaces externos

Referencias

  1. Douglas Adams
  2. Artur Bloch, Murphy’s First Corollary
  3. Karl Marx
  4. Grants:IEG/Motivational and educational video to introduce Wikimedia/Final