Los resúmenes de Belokamencev

Recientemente, por pura casualidad y gracias a una buena persona, nació la idea de agregar un resumen a cada artículo. No una anotación, ni un gancho, sino un verdadero resumen. Algo que permitiera no leer el artículo en absoluto.

Lo intenté, y me gustó mucho. Pero eso no importa; lo principal es que a los lectores les gustó. Regresaron aquellos que habían dejado de leer, tildándome de grafómano. Y otra buena persona sugirió que escribiera un resumen para cada artículo antiguo. Acepté y ahora, entre otras cosas, estoy escribiendo estos resúmenes. Los llamé shorts.

Les presento algunos de estos shorts, sobre varias publicaciones. Tal vez encuentren algo útil para ustedes.

El gato se murió, la cola está pelada.

Las reuniones a menudo se llevan a cabo sin resultados. Se reúnen, charlan y se dispersan.
Los resultados, o productos de la reunión, son decisiones. Y estas suelen faltar. Si existen, no siempre son de buena calidad.
Si la reunión está limitada en tiempo y se debe tomar una decisión obligatoriamente, entonces esa decisión puede tener baja calidad.
Si la reunión no tiene un límite de tiempo y se extiende hasta que se toma una decisión, se tomará cualquier decisión, sólo para que la reunión termine.
Si la decisión se genera en la reunión, se aceptará simplemente porque el cerebro valora lo que ha creado.
La comprensión de la baja calidad de la decisión llegará más tarde, pero entonces ya será tarde.
Para tomar una decisión eficaz, es mejor no participar en la discusión, sino observar en silencio.
Primero, el cerebro no estará ocupado ideando respuestas.
En segundo lugar, no hay presión para tomar una decisión.
Después de que termina la reunión, se puede pensar tranquilamente y tomar una decisión. Será de mayor calidad.
Lo clave es permanecer en silencio y escuchar durante la reunión. Para que los demás no se preocupen, se puede decir que es una posición consciente.

→ habr.com/ru/post/341654

Parásitos latentes

Fundamentalmente, hay dos enfoques para la asignación de tareas y el control de su ejecución: parásito y simbiótico.
El enfoque simbiótico es hacer que la tarea se resuelva.
El enfoque parásito es hacer que la tarea NO se resuelva.
El enfoque simbiótico es directo y sencillo, pero complejo en su implementación. Por eso se encuentra poco.
La tarea se formula de tal manera que todo quede claro: tanto los objetivos como los recursos y las limitaciones.
El control se lleva a cabo de tal manera que la tarea se resuelva de manera exacta.
El enfoque simbiótico implica dejar parte de la responsabilidad (de hecho, la mayor parte) de la resolución de la tarea sobre el que la plantea.
El enfoque parasitario es retorcido y complicado, pero fácil de implementar. Por eso se encuentra con frecuencia.
La tarea se plantea de tal manera que no se entienda nada. Cuanto menos se entienda, mejor.
Preferiblemente, no llevar a cabo el control en absoluto.
No hay ninguna responsabilidad en el que plantea la tarea, toda la 'mono' se traslada al cuello del ejecutor.
El objetivo del enfoque parasitario: manipulación, ego, autoafirmación. Por eso se encuentra a menudo en el trabajo de mentores con empleados nuevos.
Por supuesto, es mejor el enfoque simbiótico.

→ habr.com/ru/post/343696

Mediciones vs Ilusiones

Si evalúas el proceso y los resultados de tu actividad sin mediciones, estarás equivocándote todo el tiempo.
La evaluación sin cifras depende del estado de ánimo. Mal estado de ánimo — parecerá que trabajas mal. Buen estado de ánimo — al contrario.
Así puedes estar una semana sentado y trabajando mal, y el viernes entregar un resultado, y parecerá que toda la semana fue bien.
En principio, hay dos tipos de métricas: cuantitativas y alternativas (más conocidas por los programadores como Booleanas).
'La tarea se ha completado a tiempo' — eso es Booleano. Es lo mismo que 'La pieza es apta' (un criterio de calidad alternativo, cuando no se pueden medir en cifras).
'Trabajamos bien', 'Cumplimos el plan', 'Yo soy genial' — también es Booleano.
Es complicado construir el proceso de gestión sobre evaluaciones tipo Booleano. Se recomienda pasar lo antes posible a métricas cuantitativas.
El Booleano genera burocracia y formalismo. Por ejemplo, se puede lograr que las tareas se completen a tiempo aumentando los plazos, inventando tareas para uno mismo, realizando trabajo inútil.
Para gestionar con base en indicadores Booleanos, se necesita gastar mucho tiempo — en reuniones, análisis, etc. Porque la información es demasiado escasa.
Se recomienda medir tanto el proceso como el resultado. Así, la imagen será la más completa.
Para los programadores, se recomienda el método 'Poker de planificación' de Scrum.

→ habr.com/ru/post/343910

Esto es Esparta

Supongamos que eres programador y te han traído una tarea seria. Y tú crees que no debes resolver la tarea — es tonta, perjudicial.
Comportamiento típico en esta situación: llevar la tarea a un campo público. Enviarla para aprobación con el jefe, iniciar un proyecto interno, registrarlo en el sistema, etc.
Aquí es donde todo se rompe. La persona que trajo la tarea no quiere que lo consideren un tonto. Y dado que se ha llevado a un campo público, se defenderá.
Es importante para la persona no perder la cara, en un sentido político. Lo principal en la política es nunca reconocer tus errores. Puedes no hacer nada, pero lo más importante es no tener errores reconocidos.
La persona hará todo lo posible para demostrar que el programador es el villano, un idiota, un oponente al cambio. Y el programador aún tendrá que resolver la tarea.
En algunos casos, la persona organizará todo de tal manera que el programador no resuelva la tarea en absoluto. Entonces la persona será "blanca" y el programador será absolutamente "negro" (y se resistió y al final no pudo manejarlo).
Hay varias soluciones.
La primera es convertirse en un programador de negocios, comprender áreas relacionadas y determinar por sí mismo qué y cómo se debe automatizar.
La segunda es un puesto principal en cambios. Por ejemplo, director de desarrollo.
La tercera es no surgir y simplemente hacer lo que se dice.
La cuarta es el Camino de Esparta, rápida eliminación de soluciones. Más conocido como fallar rápido, fallar barato.
Lo principal es no hacer público. Decirle a la persona: no gastemos mucho tiempo, hagamos un prototipo y veamos si la solución es viable o no.
El prototipo llevará poco tiempo. En caso de éxito, ambos obtendrán lo suyo: una solución adecuada y puntos políticos.
En caso de fracaso, nadie saldrá perjudicado. Y la persona tendrá una mejor opinión del programador.

→ habr.com/ru/post/344650

Sustitutos

El negocio no ama 1C y sus productos, desarrolladores web, sistemas de gestión de calidad, contabilidad, economistas, proyectos de desarrollo, Scrum, TOC, control, KPI y sistemas de motivación.
Los negocios aprecian el aumento de la rentabilidad a través de la automatización, el crecimiento de las ventas mediante la promoción en línea, la mejora de la calidad del producto, una imagen simple y entendible del negocio en cifras, pronósticos sobre el estado de la empresa, un verdadero aumento de la eficiencia, la aceleración de la ejecución de proyectos de 2 a 4 veces, un aumento exponencial de las ganancias y la reducción de inventarios, un sistema de gestión preciso, un sistema claro y comprensible de evaluación de la situación en el negocio, así como un sistema de evaluación del trabajo que permite despedir a la mitad de los gerentes.
Los negocios aman alcanzar objetivos empresariales. Los negocios no aprecian los sustitutos.
Un sustituto es cuando se pide alcanzar un objetivo empresarial y se obtienen un proyecto de automatización, un sitio web, un montón de documentos, un equipo de empleados confusos o informes ilegibles.
Un sustituto es cuando se reemplaza el objetivo por el medio para alcanzarlo. Y todos olvidan sobre el objetivo.
La producción de sustitutos se basa en tres pilares: formalismo, gradualidad y complicidad.
El formalismo es transferir los objetivos al papel con descomposición. En esencia, es desviar la atención del gran objetivo hacia pequeños detalles. Ya nadie recuerda el objetivo: todos discuten los detalles.
La gradualidad es una baja velocidad del avance de los objetivos a los medios. Al principio, el objetivo a veces todavía se discute. Pero gradualmente, paso a paso, se menciona con menos frecuencia. Hasta que el cliente olvida por completo, sumergido en los detalles.
La complicidad radica en que todos los contratistas actúan de manera similar. No hay un solo automatizador que realmente aumente las ganancias. Por lo tanto, el cliente no tiene muchas salidas.
¿Qué hacer?
Evitar los sustitutos y el primer paso en su creación: el formalismo. Al menos en proyectos internos. Establezca un objetivo y converse con el ejecutor sobre él de manera constante. También sobre las escalas, recursos, planes, etc. Pero lo principal es sobre el objetivo.
De lo contrario, la atención se desplazará inevitablemente y obtendrá otro sustituto.

→ habr.com/ru/post/344844

Vitali Klitschko

Hay un boxeador llamado Vladimir Klitschko. Tiene una característica: el uso constante del jab. Es decir, más constante que otros boxeadores.
El jab mantiene constantemente al oponente en tensión, lo desgasta.
Las características clave del jab de Klitschko: simplicidad de ejecución (relativa, por supuesto) y constancia.
Muchos autores hablan de cómo acciones simples pero útiles que se realizan constantemente pueden aportar grandes beneficios.
Yo también decidí intentarlo. Creé un sistema simple de seguimiento: qué jabás hice hoy.
Esto ocurrió en una fábrica. Hacía jabás en el almuerzo (no almuerzo), es decir, 1 hora al día. Hacía lo que otros no hacían (dicen que eso lleva al éxito).
Configuraba pruebas de un sistema auto-aprendizaje, creaba ideas de desarrollo, implementaba ideas ajenas de desarrollo, configuraba tareas automáticas, refactorizaba y optimizaba el código.
Cada día — cualquier tarea de esta lista. Hice una tarea — soy genial. Se pueden hacer varias.
Llevé a cabo observaciones durante 3 meses. Durante este tiempo, hice 30 pruebas, generé 200 ideas, implementé 80 ideas de otros, construí procesos automatizados para dos departamentos y realicé tres grandes optimizaciones.
Genial, ¿verdad? Esto es ‘de paso’. Lo recomiendo a todos.

→ habr.com/ru/post/344934

Sustituto flexible

Con la palabra ‘Scrum’ se designan, al menos, dos entidades: filosofía y marco de trabajo.
La filosofía, o enfoque de trabajo, está descrita en el libro de Jeff Sutherland.
El marco de trabajo, es decir, el algoritmo de acciones, está descrito en un documento titulado Scrum Guide.
La filosofía se convirtió en un marco de trabajo porque los autores de la filosofía querían ganar dinero con ella (según sus propias palabras).
El marco de trabajo está mucho más simplificado en comparación con la filosofía. Lo principal — se ha simplificado, o más bien eliminado, el objetivo.
El objetivo de la filosofía: acelerar el logro de resultados. Y de manera exponencial. En el libro hay ejemplos de aceleración de hasta 8 veces.
El objetivo del marco de trabajo: que tengas Scrum. Así está escrito: sigues las instrucciones — tienes Scrum, violas las instrucciones — no tienes Scrum.
El marco de trabajo no supone acelerar el logro de resultados, en absoluto.
Las personas que enseñan o implementan Scrum trabajan con el marco de trabajo. Explican e implementan un algoritmo que no conduce a ningún resultado, excepto ‘ahora tenemos Scrum’.
La esencia es clara. Vender la filosofía es muy difícil. El marco de trabajo — es más fácil.
El marco de trabajo es un producto. Pasó por el proceso de ‘empaquetado’. Es simple, claro, tiene soporte y muchos especialistas. ¿No les recuerda a nada?
Todo bien, excepto el resultado — no lo hay.
Si el cliente no está familiarizado con la filosofía de Scrum, la implementación del marco de trabajo le satisfará perfectamente.
Si el cliente está familiarizado con la filosofía Scrum, la implementación del marco le decepcionará: no habrá aceleración en la consecución de resultados.
Será genial, moderno y contemporáneo, pero no se alcanzarán los objetivos empresariales (excepto para gastar el presupuesto en "algo nuevo").
¿Qué hacer? Estudiar la filosofía de Scrum. Se basa en la filosofía japonesa de gestión de la calidad, cuya esencia es: mediciones y mejoras continuas.
Lamentablemente, se necesita pensar mucho, experimentar, observar y, desgraciadamente, trabajar. Si esto no te conviene, simplemente adopta el marco.

→ habr.com/ru/post/345540

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster