Pantalóns curtos de Belokamentsev

Recentemente, por casualidade, por suxestión dunha boa persoa, naceu unha idea: achegar un breve resumo a cada artigo. Non é un resumo, non un atractivo, senón un resumo. De tal xeito que non pode ler o artigo en absoluto.

Probeino e gustoume moito. Pero non importa - o principal é que lles gustou aos lectores. Os que había tempo que deixaran de ler comezaron a volver, tachándome de grafómano. E outra boa persoa recomendoume que escribise un resumo para cada artigo antigo. Aceptei e agora, casualmente, estou escribindo estes contos. Chamáballes curtos.

Chamo á súa atención varias curtas deste tipo, baseadas en varias publicacións. Quizais atopes algo útil para ti.

O gato morreu, o rabo saíuse

Moitas veces as reunións van sen resultados. Reuníronse, charlaron e seguiron camiños separados.
Os resultados ou produtos da reunión son decisións. Por iso normalmente non existen. E se o hai, non sempre é de boa calidade.
Se a reunión está limitada no tempo e hai que tomar unha decisión, entón (a decisión) é de mala calidade.
Se a reunión non está limitada no tempo e dura ata que se tome unha decisión, calquera decisión tomarase mentres remate a reunión.
Se se toma unha decisión nunha reunión, entón será aceptada, simplemente porque o cerebro aprecia o que se lle ocorreu.
A comprensión da mala calidade da solución chegará máis tarde, pero será demasiado tarde.
Para tomar unha decisión eficaz, é mellor non participar na discusión, senón observar en silencio.
En primeiro lugar, o cerebro non estará ocupado en buscar respostas.
En segundo lugar, non hai presión para tomar unha decisión.
Despois de que a reunión remate, podes pensalo con calma e tomar unha decisión. Será de maior calidade.
A clave é permanecer en silencio e escoitar durante a reunión. Para que os demais non se preocupen, digan que esta é unha posición consciente.

habr.com/en/post/341654

Parasitos latentes

Fundamentalmente, hai dous enfoques para establecer obxectivos e supervisar a execución: parasitario e simbiótico.
O enfoque simbiótico é garantir que o problema está resolto.
O enfoque parasitario é asegurarse de que o problema NON está resolto.
O enfoque simbiótico é sinxelo e directo, pero difícil de implementar. Polo tanto, é raro.
A tarefa establécese de forma que todo estea claro: obxectivos, recursos e limitacións.
O control realízase para que o problema se resolva con precisión.
O enfoque simbiótico consiste en deixar parte da responsabilidade (ademais) de resolver o problema no director.
O enfoque parasitario é adornado e intelixente, pero fácil de implementar. Polo tanto, ocorre con frecuencia.
A tarefa exponse de tal xeito que nada está claro. Canto menos claro mellor.
É recomendable non exercer ningún control.
Non hai responsabilidade sobre o director de tarefas; todo o "mono" é transplantado ao pescozo do intérprete.
O propósito do enfoque parasitario: manipulación, angustia emocional, autoafirmación. Polo tanto, adoita atoparse no traballo de mentores con empregados novatos.
O mellor, por suposto, é un enfoque simbiótico.

habr.com/en/post/343696

Dimensións vs Ilusións

Se avalías o proceso e os resultados das túas actividades sen medicións, sempre cometerás erros.
A valoración sen números depende do teu estado de ánimo. Mal humor - parecerá que non está a traballar ben. Un bo humor é o contrario.
Deste xeito, podes sentarte e traballar mal durante unha semana, e o venres podes producir excelentes resultados, e parecerá que toda a semana foi ben.
Fundamentalmente, hai dous tipos de métricas: cuantitativas e alternativas (máis coñecidas polos programadores como booleanas).
"Tarefa completada a tempo" é un booleano. Isto é o mesmo que "A parte é boa" (un sinal alternativo de calidade cando non se poden medir en números).
"Estamos traballando ben", "Estamos cumprindo o plan", "Estou xenial" - tamén booleano.
É difícil construír un proceso de control utilizando estimacións de tipo booleano. Recoméndase pasar ás métricas cuantitativas o máis rápido posible.
O booleano xera burocracia e formalismo. Por exemplo, completar tarefas a tempo pódese conseguir aumentando os prazos, inventando tarefas para ti e implementando IBD.
Para xestionar a base de indicadores booleanos, cómpre dedicar moito tempo: reunións, análises, etc. Porque hai pouca información.
Recoméndase medir tanto o proceso como o resultado. Entón a imaxe será máis completa.
Para os programadores, recoméndase o método "Planning Poker" de Scrum.

habr.com/en/post/343910

Esto é Esparta

Digamos que es un programador e se lle encarga unha tarefa seria. E pensas que non hai necesidade de resolver o problema: é estúpido, prexudicial.
Comportamento típico en tal situación: mostrar a tarefa nun campo público. Envíao para a súa aprobación co xefe, lanza un proxecto interno, rexistrao no sistema, etc.
Aquí é onde todo se rompe. A persoa que trouxo a tarefa non quere ser considerada un parvo. E unha vez que entren no terreo público defenderanse.
É importante que unha persoa non perda a cara, no sentido político. O principal en política é nunca admitir os teus erros. Non tes que facer nada, pero o principal é non ter ningún erro admitido.
Unha persoa fará todo o posible para demostrar que o programador é un vilán, un idiota, un opoñente do cambio. E o programador aínda terá que resolver o problema.
Nalgúns casos, unha persoa organizará todo para que o programador non resolva o problema en absoluto. Entón a persoa será "branca" e o programador será absolutamente "negro" (resistiuse e fallou ao final).
Hai varias solucións.
O primeiro é converterse nun programador empresarial, comprender áreas relacionadas e determinar por ti mesmo que e como automatizar alí.
O segundo é o artigo Xefe de Cambios. Por exemplo, director de desenvolvemento.
En terceiro lugar, non te presentes e fai o que che digan.
Cuarto - O Camiño de Esparta, rápido rexeitamento das decisións. Máis coñecido como falla rápido, falla barato.
O principal é non implicar publicidade. Dille á persoa: non perdamos moito tempo, fagamos un prototipo e vexamos se a solución é viable ou non.
O prototipo levará un pouco de tempo. Se teñen éxito, ambos terán a súa: unha decisión normal e puntos políticos.
Se falla, ninguén sairá ferido. Ben, a xente tratará mellor ao programador.

habr.com/en/post/344650

Subrogantes

A empresa non lle gusta 1C e os seus produtos, desenvolvedores web, QMS, contabilidade, economistas, proxectos de desenvolvemento, Scrum, TOS, control, KPI e sistemas de motivación.
As empresas adoran o aumento da rendibilidade debido á automatización, o aumento da facturación da promoción en liña, a mellora da calidade do produto, unha imaxe sinxela e comprensible do negocio en números, previsións do estado da empresa, un aumento real da eficiencia, a realización do proxecto máis rápida de 2 a 4 veces, un aumento múltiple dos beneficios e unha diminución de existencias, un sistema de xestión preciso, un sistema claro e comprensible para avaliar a situación da empresa, un sistema de avaliación laboral que permite despedir á metade dos directivos.
Ás empresas gústalles acadar obxectivos comerciais. Ao negocio non lle gustan os substitutos.
Un substituto é cando pediu acadar un obxectivo de negocio, pero recibiu un proxecto de automatización, un sitio web, unha pila de papel, un equipo de empregados incomprensibles ou informes ilexíbeis.
Un substituto é cando o obxectivo ao longo da estrada é substituído por un medio de logro. E todos esqueceron o gol.
A produción de substitutos baséase en tres piares: formalismo, gradualismo e responsabilidade mutua.
O formalismo é a transferencia de obxectivos ao papel con descomposición. Pero, en esencia, transferir o foco de atención do gran obxectivo aos pequenos detalles. Xa ninguén se lembra do obxectivo: todos discuten os detalles.
O gradualismo é unha baixa velocidade de transición dos obxectivos aos medios. Ao principio, o obxectivo aínda se discute ás veces. Pero aos poucos, paso a paso, vaise mencionando cada vez menos. Ata que o propio cliente se esquece diso, afogándose nos detalles.
A responsabilidade mutua é que todos os contratistas actúen aproximadamente igual. Non hai unha única ferramenta de automatización que realmente aumente os beneficios. Polo tanto, o cliente realmente non ten opción.
Que facer?
Evita os substitutos e o primeiro paso para a súa creación: o formalismo. Polo menos en proxectos internos. Establece un obxectivo e fala constantemente co intérprete. Sobre escala, recursos, plans, etc. - O mesmo. Pero o principal é o obxectivo.
En caso contrario, o foco de atención cambiará e obterás outro substituto.

habr.com/en/post/344844

Jab Klitschko

Hai un boxeador - Vladimir Klitschko. Ten unha peculiaridade: o uso constante do jab. Ben, iso é. máis consistente que outros boxeadores.
O jab mantén constantemente ao rival en suspenso e esgotao.
Características principais do jab Klitschko: facilidade de execución (relativa, por suposto) e coherencia.
Moitos autores din que as accións realizadas constantemente, útiles, pero simples poden traer moitos beneficios.
Eu tamén decidín probalo. Fixen un sistema de contabilidade sinxelo: que golpes fixen hoxe.
Ocorreu na fábrica. Fixen pinchadas ao xantar (non almorzo), é dicir. 1 hora ao día. Fixo o que outros non fan (din que leva ao éxito).
Configurei probas dun sistema de autoaprendizaxe, inventei ideas para o desenvolvemento, implementei ideas doutras persoas para o desenvolvemento, configurei tarefas automáticas, refactorei e optimicei o código.
Todos os días - calquera tarefa desta lista. Completada unha tarefa - guapo. Varios son posibles.
As observacións realizáronse durante 3 meses. Durante este tempo, fixen 30 comprobacións, decidín 200 ideas, implementei 80 ideas doutras persoas, creei procesos automatizados para dous departamentos e fixen tres optimizacións interesantes.
Genial. Ben, isto é "intermedio". Recomendo a todos.

habr.com/en/post/344934

Subrogado flexible

A palabra "Scrum" refírese a polo menos dúas entidades: filosofía e marco.
A filosofía, ou enfoque do traballo, descríbese no libro de Jeff Sutherland.
Marco, é dicir. o algoritmo de accións descríbese nun documento chamado Scrum Guide.
A filosofía converteuse nun marco porque os autores da filosofía querían gañar cartos con ela (segundo as súas propias palabras).
O marco é moi simplificado en comparación coa filosofía. O principal é que o obxectivo foi simplificado, ou mellor dito botado.
O obxectivo da filosofía: acelerar a consecución de resultados. Ademais, ás veces. O libro contén exemplos de aceleración en 8 veces.
O propósito do framework: para que teñas Scrum. Está escrito alí: se segues as instrucións, tes Scrum; se violas as instrucións, non tes Scrum.
O marco non implica en absoluto unha aceleración na consecución de resultados.
As persoas que ensinan ou implementan Scrum traballan co framework. Contan e implementan un algoritmo que non conduce a ningún resultado que non sexa "agora temos Scrum".
O punto está claro. A filosofía é moi difícil de vender. O marco é máis sinxelo.
Un marco é un produto. El, como era de esperar, pasou pola "embalaxe". É sinxelo, comprensible, hai apoio e moitos especialistas. Non che lembra a nada?
Todo está ben, excepto o resultado: non hai ningún.
Se o cliente non está familiarizado coa filosofía de Scrum, estará bastante satisfeito coa implementación do marco.
Se o cliente está familiarizado coa filosofía Scrum, entón estará decepcionado coa implementación do marco - non haberá aceleración na consecución de resultados.
Será xenial, de moda, moderno, pero non se acadarán obxectivos empresariais (salvo gastar o orzamento en "algo novo").
Qué debería facer? Estudar a filosofía Scrum. Está baseado na filosofía xaponesa de xestión da calidade, cuxa esencia é: medición e mellora sen fin.
Por desgraza, hai que pensar moito, experimentar, observar e, por desgraza, traballar. Se isto non che convén, toma o marco.

habr.com/en/post/345540

Fonte: www.habr.com

Engadir un comentario