¿Quiénes son los líderes y por qué son necesarios? ¿Cuál es su uso en la vida? ¿Qué hacen ellos en absoluto? ¿Qué deben hacer ellos?
Por un lado, el líder se entiende tradicionalmente como el que administra: hace planes, da instrucciones, controla el tiempo, grita más fuerte, toma decisiones y es responsable de ellos.
Por otro lado, existe la opinión de que el jefe solo debe ocuparse del desarrollo de la unidad encomendada, sin participar en la gestión operativa.
Por otro lado, hay organizaciones de autogobierno y turquesas, que en la práctica han demostrado que una entidad como líder no es necesaria en absoluto: es solo un conjunto de responsabilidades, roles y puntos de control que se pueden difundir fácilmente entre diferentes personas.
Entonces, ¿quién es él, este líder, y por qué es necesario? ¿Necesita un gerente una empresa o una empresa necesita un líder como fuente de ingresos? Quizás justifique su existencia, porque el resultado lo vale: los ingresos de los gerentes a menudo son incomparablemente más altos que los ingresos de los empleados comunes.
Utilizo un modelo especial para evaluar gerentes, con lo cual sugiero que se familiarice.
Modelo
El modelo es fácil de deshonrar, pero generalmente es comprensible solo para los programadores. Pero ustedes son programadores, y todo estará claro para ustedes.
Entonces, imagine una empresa que ha automatizado su contabilidad en un determinado sistema de información. Y al lado de este sistema hay un programador, solo uno. Él y el jefe del departamento de TI, y el codificador, y el arquitecto, todo en uno. La situación es bastante común para las pequeñas y, a veces, para las grandes empresas: yo mismo, durante algún tiempo, fui el único programador en la empresa.
Entonces, ahora imagine que un programador es el jefe de un departamento, y un sistema de información es, de hecho, su departamento, que incluye personal, equipo, procesos, etc. Y el departamento, y el servicio, y el departamento, y toda la empresa, este es un sistema. E información, también es un sistema.
El programador es libre de tratar su sistema de diferentes maneras: desarrollar, mantener, eliminar, interrumpir, reducir o aumentar la productividad, reemplazar con otro, escribir o eliminar documentos, controlar saldos, etc.
El jefe es libre de hacer lo mismo con su sistema (departamento): desarrollar, acompañar, trabajar como ejecutor, interferir, ayudar, dispersar, reemplazar personal, etc.
El modelo es claro: la relación gerente / departamento es la misma que la del programador / sistema de información.
Ahora veamos a los líderes a través del prisma de este modelo.
Slicker
El tipo de programador más primitivo es aquel que no hace nada en absoluto, pero de alguna manera se las arregla para no quedarse sin trabajo. Yo personalmente vi esto: fue llevado a cambiar del arrancador suave integrado 1C 7.7 a 1C 8, y no usó su pie, ni en el primero, ni en el segundo, pero se estiró un año, solo debido al hecho de que estaba corriendo a Internet para configurar Internet a tiempo, ICQ y descarga música de torrents.
Otro ejemplo es una niña que no sabía cómo hacer nada por sí misma, pero que tenía una extensa red de contactos entre programadores y era, como dicen, bonita y encantadora, por lo que los chicos con gusto la ayudaron, resolviendo completamente sus tareas. Además, los chicos trabajaban en otras compañías.
Usted comprende que el sistema con un programador así vive su propia vida, prácticamente no depende de él en absoluto, y no hay cambios visibles en él antes de partir.
Entre los líderes de estos muchachos también está lleno: que son, que no lo son. A veces se les llama generales de boda, pero esto es en aquellos casos en que el jefe puede realizar al menos funciones representativas, por ejemplo, sentarse bien en una reunión con clientes.
Tales líderes adoran todo tipo de eventos, reuniones, especialmente aquellos en los que hay mucha gente y no es necesario abrir la boca. A veces son tan miserables que si todavía obtienen la tarea del liderazgo, entonces ni siquiera pueden delegarla normalmente, porque el sistema los ignora por completo, a menos que alguien se apiade y ayude.
No tiene sentido hablar sobre el papel de tal programador y tal líder en el sistema y su desarrollo, porque no hay rol ni desarrollo. Este es el caso más miserable.
Un pariente
Este es un tipo de chivato por separado, con la diferencia de que los familiares no tienen que hacer mucho para mantenerse en su lugar. Los trajeron allí con una pata peluda y están sentados. Quién está todo el día, quién está antes de cenar, quién está después de cenar, quién está en casa.
Los familiares ya tienen un impacto en el sistema, ya que tienen miedo: nunca se sabe qué tipo de riendas caerán debajo de la cola, puede perder su trabajo.
Pero, de hecho, generalmente no usan esta influencia. Ser un elemento del sistema, es decir no quieren realizar ninguna función en él, porque aparecerán responsabilidades y obligaciones, al menos tienes que venir a trabajar. No pueden desarrollar el sistema, porque Esto requiere al menos algunas competencias y una comprensión de lo que está sucediendo.
Por supuesto, hay excepciones cuando un pariente no se comporta como un pariente, pero luego lo excluimos solemnemente de esta categoría. A veces, los lazos familiares incluso ayudan, haciendo que una persona sea más responsable y efectiva, por ejemplo, en un negocio familiar. La eficiencia aumenta porque un pariente no teme ser despedido.
Pero, en general, en su mayor parte, dicho programador no juega un papel en la vida del sistema y el jefe en la vida del departamento.
Tornillo
Sucede que un programador se convierte en un operador. No a menudo, pero sucede.
Solo hace eso, intercambia, carga y descarga archivos, hace copias de seguridad, ingresa documentos, genera informes, hace algún tipo de análisis de datos, etc. De hecho, simplemente hace el trabajo del usuario. En mi vida vi esto cuando, lentamente, poco a poco, y el programador se convirtió en contador.
Si se gira, es decir se mudó a otro departamento y a otra posición, y al infierno con él, una transformación tan normal. Pero sucede que funciona como operador y se llama programador. ¿Quién es él entonces, en nuestro modelo? Solo un elemento del sistema que se suponía que debía administrar. ¿Quién entonces maneja y desarrolla el sistema? Nadie, hasta que llega otro y se da cuenta de que algo está mal aquí.
Esto sucede todo el tiempo con los líderes, especialmente con el nivel más bajo, como los líderes de equipo, los gerentes de sitio, los administradores principales del sistema, etc. Su posición es una formalidad, no manejan nada y no desarrollan nada, trabajan como todos los demás, solo tienen un poco más de responsabilidades, como ir a la RAM y proporcionar hojas de tiempo.
Ni uno ni los otros líderes tienen influencia en su sistema. No manejes, no desarrolles, no respondas. El sistema no depende de ellos.
Pulpo
Pero este es un caso completamente diferente. Tal programador, aunque no está involucrado en la programación, es un elemento de sistema único en importancia. Por ejemplo, solo él sabe cómo calcular el costo y ajustarlo de acuerdo con la estrategia fiscal.
De hecho, este es el mismo operador, solo que más avanzado, se da cuenta de su valor y lo vende con éxito. Tal programador afirma que solo él sabe cómo hacer ajustes para registrar entradas para que "nada vuele". Solo él puede corregir el menos en la parte posterior para que el subconto no se disperse. Puede continuar la lista usted mismo.
Tal programador es una parte integral del sistema, su cuello de botella, un apéndice que no se puede cortar. Sin ella, habrá una crisis, y todos, incluido él mismo, lo entienden: todo depende de ello. Toma decisiones sobre la ejecución de operaciones complejas, sobre la resolución de problemas complejos, como errores al descargar informes, etc.
Hay más gerentes de este tipo que programadores. Crean artificial e intencionalmente condiciones bajo las cuales el sistema no puede existir sin ellos ni siquiera por un día (esto se puede ver claramente cuando se van de vacaciones). Coordinan todo, verifican todo, especialmente lo que se proporciona "arriba", toman decisiones sobre cada instancia del proceso (por ejemplo, el pedido de un cliente), van a todas las reuniones.
Cuando se les dice que necesitan ser delegados, se refieren al empleo, simplemente no hay tiempo para sentarse y pensar, escribir instrucciones y entregar las cosas. En general, esta es su excusa favorita: el empleo que crearon artificialmente. Y más multitarea.
La situación a veces parece ridícula, especialmente cuando un gerente superior cambia y comienza a preguntar nuestro elemento clave: ¿qué está haciendo? Y lo más importante: ¿por qué? La respuesta es generalmente: "tan aceptado" o, si logró arreglar su indispensabilidad en los estándares de la empresa, "así debería ser". Quién aceptó, cuando aceptó, por qué aceptó: no hay respuesta o no se puede pronunciar, porque "Pensé en esta basura sin sentido" suena más o menos.
Tanto el programador como el gerente comienzan a creer gradualmente en su exclusividad. A veces, incluso comienzan a sentir lástima de sí mismos, y exigen lástima de los demás, o incluso inducen esta lástima de los más altos para aumentar sus ingresos.
Sucede que dicho programador o administrador clave realiza cambios en el sistema, es decir actúa favorablemente en ella. Pero casi siempre le falta un enfoque en deshacerse del sistema. Por ejemplo, un programador puede escribir un procesamiento genial para la formación de paquetes de documentos, lo que salva a las personas del trabajo de rutina, pero solo el programador usará este procesamiento. Si le piden que le enseñe a alguien más, entonces encontrará un montón de excusas, como "sí, para explicarlo más, déjame hacerlo mejor".
Los líderes hacen lo mismo, agudizando el sistema por sí mismos. Por ejemplo, hubo un director de ventas que eliminó una condición: dame un porcentaje de las ventas de todo el departamento y distribuiré la prima lo que me plazca. Usted comprende que para los vendedores se convierte en el motivo principal para trabajar para un líder así, no "para vender más", sino "para que le guste más". El administrador no podrá explicar el algoritmo de distribución, porque este algoritmo no existe.
Como resultado, para el programador, para el administrador, el resultado es uno: el sistema no puede existir ni desarrollarse sin él.
Guante
Hay programadores que cambian los sistemas como guantes. Realmente no saben cómo programar, recordar la implementación, resolver problemas pequeños y grandes de los usuarios y beneficiar a la empresa.
En cualquier situación de crisis, cuando hay más daño que bien del sistema, dicen: es hora de cambiar a otro sistema.
Afortunadamente, ahora no hay problemas con esto, especialmente dada la mezcla de nichos en la línea de productos, el mismo 1C. Puede cambiar de UT 10.3 a arranque suave, luego a KA 1, luego a KP 3.0, luego a KA 2, luego a ERP, luego escupe todo e implementa UNF, luego algún tipo de perversión como USHP (si la industria lo permite), entonces, Sorprendentemente, volver a SCP. Cada transición es un mínimo de un año. Cuente cuánto puede aguantar en tal estrategia. ¿Has conocido a tales programadores? Me he encontrado
¿Cómo se ve un líder similar? Cambia sin cesar la metodología, el enfoque básico de la gestión. Hoy establece un plan para un mes, mañana establece un plan para un año, luego cambia a Agile, luego a TOS, luego a Lean, luego a 4-4-5, luego a presupuesto, luego a un modelo sin presupuesto. Esto no está mal si el jefe conoce todas estas técnicas, al menos puedes practicar su aplicación.
Pero generalmente todo es más prosaico: un líder así resuelve todos los problemas mediante la reestructuración. Hace dos de un departamento, luego diez, luego de nuevo uno, luego recluta un nuevo departamento de nuevas personas, luego los cancela y los coloca en los departamentos antiguos, inventa nuevos mensajes y escribe instrucciones, procesos y estándares, o de una manera muy infantil: cambia las divisiones a divisiones, divisiones por departamentos, departamentos por equipos, equipos por distritos, etc.
La esencia del enfoque tanto para el programador como para el gerente es la misma: si bien hay cambios a gran escala, nadie llegará al fondo de los resultados. Y si llegas al fondo, siempre puedes otmazatsya: estamos en pleno cambio, ahora es simplemente imposible responder a tu pregunta, volver en un mes o buscar la respuesta tú mismo.
El impacto en el sistema es aterrador en escala, pero no tiene sentido en su resultado y efectividad. Estos son solo cambios por el bien del cambio, solo en una escala colosal.
Lo que es especialmente malo es que otros se acostumbran a tal comportamiento y gradualmente olvidan que estos cambios tuvieron un comienzo y debe haber un final. Olvidan la cadena de cambios, qué sistema o metodología ha cambiado y por qué. Como resultado, después de un tiempo, simplemente puede repetir todo el rango de cambios nuevamente, y nadie lo notará. En la práctica, observé esa imagen y calculé la frecuencia del ciclo: 4 años.
Por supuesto, no es necesario hablar sobre ningún beneficio para la empresa de dicho programador y gerente.
Plyushkin
Plyushkin es el personaje de "Dead Souls" de Gogol, un mercenario codicioso que arrastró y mantuvo todo lo que encontró, hasta el más mínimo detalle.
Tales programadores de Plyushkin adoran todo tipo de repositorios de soluciones y códigos, como git, pero se usan para otros fines. En lugar de buscar una solución a su problema allí, descargan estúpidamente todo lo que tiene suficiente capacidad de disco o dinero (para soluciones pagas). Se almacenan en carpetas ordenadas, ordenadas, a veces intentan integrarlas en su sistema para mostrarlas a los usuarios o al director, haciéndose pasar por las suyas y justificando así su existencia.
Ellos mismos no saben cómo hacer nada, por lo que usar las pequeñas cosas de otra persona para ellos es la única forma de sobrevivir en la profesión. Para los cambios serios, carecen de la fuerza, las competencias y el coraje.
Puede reconocer tales Plyushkins mirando la interfaz de su sistema: estará lleno de iconos de varios complementos, cuyo significado no será claro para nadie. Todo tipo de paneles de funciones, duplicación del árbol de metadatos, clasificación universal de tablas, gestión de intercambios en una base de datos que no utiliza intercambios, un montón de informes, incluso para otros sistemas, etc.
Los ejecutivos de Plyushkina se comportan de manera similar. Leen blogs, artículos, todo tipo de grupos en redes sociales sobre cómo hacer cambios útiles con poco esfuerzo. Debido a la naturaleza no sistemática en la elección de los métodos, la comprensión de los problemas de su departamento y la implementación en sí, por lo general no tienen sentido.
Por ejemplo, Plyushkin verá en la televisión que el nuevo joven gobernador está celebrando reuniones mientras está de pie, diciendo que esto aumenta la eficiencia, y eso es todo, disfruten, subordinados. Anteriormente, sentados en una estupa, empujaban el agua, ahora estarás de pie. O leerá otra práctica recomendada de que todos los empleados deben escribir un informe diario a mano, dicen que no se trata de una copia de la computadora, sino palabras reales y sinceras, y aquí, ensayos diarios, menos una hora del tiempo de trabajo.
Dichos programadores y gerentes tienen un impacto menor y mayormente dañino en el sistema. llénalo con basura y ruido.
Amante de la escort
Hay programadores que casi siempre, para la solución de tareas más o menos complejas, se llaman subcontratistas. El proyecto de introducir el sistema, lanzar un nuevo subsistema, integrarse con el sitio, desarrollar un nuevo documento, agregar accesorios: se requiere un programador externo para todo.
Hay los mismos líderes, yo personalmente vi. ¿Necesita un sistema de motivación? Optimización de procesos de negocio? Desarrollo de estrategia? Análisis del sistema de gestión? Solo hay una respuesta: estamos buscando especialistas externos.
Parece que el impacto en el sistema es, pero casi siempre torcido y dañino, porque el consultor trabaja solo con una parte del mosaico.
Por ejemplo, crea un sistema de motivación para procesos torcidos. O escribe una estrategia, sin considerar la motivación para su implementación. O, nuestro nativo, hace la automatización de la instantánea del proceso, que pierde relevancia un año antes del final del proyecto, aunque esto no es importante, porque los objetivos y la motivación tampoco se tienen en cuenta.
Como resultado, siempre está torcido, con un sesgo en alguna dirección. Tanto el jefe como el programador. Pero lo principal es que su propio papel en este proceso de desarrollo es cero.
Tolerado
Este es el tipo de programador más común: aquellos que hacen todo lo que se les dice. En consecuencia, realizan cambios sin sentido en el sistema, dándole, pieza por pieza, para la realización de las ambiciones poco saludables de otra persona. Esta es la mayoría de nosotros, ¿qué puedo decir?
Y tales líderes, a granel. Estos son todos aquellos que permitieron la entrada a especialistas en automatización externa, implementadores de ISO 9001, burócratas internos de todos los niveles que requerían proporcionar un montón de informes, hojas de papel, pasar por millones de aprobaciones, aprender canciones y preparar escenas para eventos corporativos, etc. En general, quien abrió una parte de su sistema a un asalto externo, como un porche para personas sin hogar, y ahora no sabe cómo sacarlos de allí, para no olerlo todo.
Como resultado, tanto el sistema de información como el departamento o sistema de gestión empresarial se vuelven como Frankenstein inhibido, incapaz de dar un paso.
Estas personas son plagas, porque bajo el disfraz de "y yo Che, me dijeron que" destruyera sus sistemas.
Normal
Hay programadores normales en el mundo que deciden por sí mismos qué hacer con el sistema, sabiendo los objetivos que enfrenta. Si los objetivos son curvas establecidas, entonces no son tímidos y los ajustan, y todos logran ponerse de acuerdo.
Hay gerentes normales que se dedican constantemente a mejorar la eficiencia de su sistema, y lo hacen de manera cuidadosa, consistente y profesional.
Ninguno de los dos ingresa al sistema, excepto en casos de emergencia.
Ninguno de ellos ató el sistema a sí mismos, y en cualquier momento pueden irse, y el sistema continuará funcionando, aunque dejará de desarrollarse.El único problema es que ni uno ni el otro existen.Cuestión clave
Hay conocimiento, experiencia, competencias dispersas en diferentes personas que nunca pueden ponerse de acuerdo. Algunos son capaces de crear sistemas de motivación, otros son estrategia, terceros objetivos e indicadores, cuarta automatización, quinto sistema de gestión. Pero nunca trabajan juntos al mismo tiempo.El desarrollo siempre es consistente, se puede ver desde proyectos que a veces se conciben en empresas.Por ejemplo, se está introduciendo un sistema de motivación basado en procesos actuales. Si es visible que los procesos están torcidos, entonces esto se ignora para no ir más allá de la escala y el presupuesto del proyecto.O se inicia la optimización de procesos, pero la automatización no se mantiene al día, lo que resulta en un terrible híbrido de las versiones nuevas y antiguas de ambos.Ya he hablado de la automatización muchas veces, especialmente externa, a través de los esfuerzos de subcontratistas. Simplemente hacen un elenco automatizado de procesos sin sentido, motivación desmotivada, objetivos inconmensurables y sin un sistema de gestión en general.Se obtienen razas interminables: cada parte del sistema toma turnos por delante, lo que solo exacerba el estado de toda la población.Solución
La solución es fácil de deshonrar: integrar el desarrollo. Cambie todas las partes del sistema al mismo tiempo para que no haya desequilibrio entre ellas.Debido a que el problema principal es el desequilibrio, la falta de coincidencia de partes del sistema entre sí. Aunque parece que el problema está en una parte específica.Por ejemplo, muy a menudo reducen la automatización, es la culpa de todo.Nosotros, los programadores, generalmente culpamos a los procesos, dicen que hay un desastre y nos vemos obligados a automatizarlo.Los implementadores de los sistemas de motivación se quejan de los procesos, los indicadores no automatizados y la falta de objetivos. Etc.
Pero el verdadero problema es el desequilibrio que crea la carrera de desarrollo, y la empresa nunca obtiene los beneficios de cada parte del sistema empresarial.Implementa ERP, y aprovecha el 10% de las posibilidades, porque no hay procesos para el resto. Implementa un sistema de calificación y no lo utiliza, porque el cálculo de los indicadores no está automatizado. Escribe objetivos estratégicos, pero nunca los alcanzará, porque los procesos no se reorganizan en consecuencia.Solo hay un punto: cada parte, por sí misma, no es mala, pero en conjunto no funcionan, porque están en desequilibrio.Volver a los ejecutivos y programadores.
La modelo que te dije no es solo para reír. Ella es para entender la situación en un lugar particular, en una empresa particular, con un líder específico.Elegí la analogía con un programador por una simple razón: yo mismo soy programador y ustedes son programadores. Seguramente, si explica el papel y la influencia de los líderes a las niñas de RRHH, tendrá que proponer un modelo diferente. Porque el pensamiento que quiero transmitir es uno, pero puede haber muchos modelos: son solo para facilitar la comprensión.Pero, como me parece, los líderes son atavismos. Las empresas no los necesitan. Son como un mal hábito que odias, pero temen dejarlo. Los líderes crean la ilusión de apoyo, estabilidad, capacidad de gestión empresarial. Ellos, como "tienen responsabilidad", "toman decisiones", "coordinan" y similares, palabras sin sentido.Todas estas palabras fueron inventadas por los propios líderes. Intenta, por diversión, convencer al líder de que no es necesario. Él te dice tantas cosas lo malo que sería sin él que le sacarían las orejas. Pero escuchar a la cabeza sobre por qué los negocios lo necesitan es lo mismo que pedirle a la persona sentenciada que le disparen por qué debería vivir.Espero que el modelo de comparación de un gerente con un programador lo ayude, durante conversaciones tales y similares, a no olvidar por qué se necesita un gerente.¿Dónde ponerlo?
No es necesario poner a una persona, pero el modelo generalmente aceptado de un líder: "un gran jefe con un gran salario". De hecho, ¿aquellos que quieren convertirse en líderes realmente están luchando por esto?El modelo de Belbin da una buena respuesta. Un líder ordinario es una compilación indefinida de responsabilidades poco claras, que solo necesita clasificar a través de los roles y seleccionar un trabajo adecuado para una persona en particular.¿Puedes coordinar las acciones de las personas en línea? Ok, se el coordinador.¿Puedes inspirar, apoyar, hacer avanzar las cosas? Ok, se un motivador.¿Puedes terminar proyectos en poco tiempo? Ok, se un finalista.¿Tiene una visión, sabe a dónde ir, puede ofrecer las ideas correctas? Ok, se un generador.¿Puede analizar, tener en cuenta muchos parámetros del sistema y comprender sus vulnerabilidades? Ok, sé analista.Todos estos roles no son liderazgo. Son solo roles, tal trabajo.Si le dice a la gente qué hacer, no significa que usted esté a cargo. El despachador también le dice a los taxistas a dónde ir. Él no habla, lo hizo. Fue reemplazado por el sistema.Si sabe cómo inspirar a las personas, esto no significa que usted esté a cargo. Alguien solo necesita ver la película correcta para inspirarse, y follarlo no renunció a su motivación. Y alguien en casa estará tan inspirado en casa que no parecerá suficiente.Si ampliamos el "liderazgo" tradicional en los estantes de roles y competencias, entonces no quedará nada de eso. Entonces, ¿por qué necesitamos un líder así? Además, con el diseño resulta que realmente no puede realizar ninguno de los roles.Y el rey está desnudo, como dice el cuento.