벨로카멘세프의 반바지

최근 우연히 좋은 사람 한 사람의 제안으로 각 기사에 간략한 요약을 첨부하는 아이디어가 탄생했습니다. 요약이나 유혹이 아니라 요약입니다. 기사를 전혀 읽을 수 없을 정도입니다.

나는 그것을 시도하고 정말 좋아했습니다. 그러나 그것은 중요하지 않습니다. 가장 중요한 것은 독자들이 그것을 좋아했다는 것입니다. 오래 전에 독서를 중단했던 사람들이 다시 돌아오기 시작했고, 나에게 문자매니아라는 낙인이 찍혔습니다. 그리고 또 다른 좋은 사람은 나에게 오래된 기사마다 요약을 쓰라고 조언했습니다. 나는 동의했고 지금은 아무렇지도 않게 이 단편소설을 쓰고 있습니다. 반바지라고 불렀습니다.

나는 여러 출판물을 바탕으로 그러한 단편 몇 가지를 여러분에게 알려드립니다. 아마도 당신은 자신에게 유용한 것을 발견하게 될 것입니다.

고양이가 죽고 꼬리가 빠졌어요

회의는 결과 없이 진행되는 경우가 많습니다. 그들은 함께 모여 이야기를 나누고 각자의 길을 갔다.
회의의 결과나 결과물은 결정입니다. 그렇기 때문에 일반적으로 존재하지 않습니다. 그리고 만약 존재한다고 해도 항상 품질이 좋은 것은 아닙니다.
회의 시간이 제한되어 결정을 내려야 한다면 그 결정(결정)의 질은 좋지 않습니다.
회의가 시간 제한이 없고 결정이 내려질 때까지 지속된다면 회의가 끝나는 동안 모든 결정이 내려집니다.
회의에서 결정이 내려지면, 그것은 받아들여질 것입니다. 왜냐하면 뇌는 그것이 내린 결정을 높이 평가하기 때문입니다.
솔루션의 품질이 좋지 않다는 것을 나중에 이해하게 되지만 너무 늦을 것입니다.
효과적인 결정을 내리려면 토론에 참여하지 않고 조용히 관찰하는 것이 좋습니다.
첫째, 두뇌는 답을 찾는데 바쁘지 않을 것입니다.
둘째, 결정을 내려야 한다는 압박감이 없습니다.
회의가 끝난 후에는 차분하게 생각해보고 결정하시면 됩니다. 더 높은 품질이 될 것입니다.
핵심은 회의 중에 침묵을 유지하고 경청하는 것입니다. 다른 사람들이 걱정하지 않도록 이것이 의식적인 입장이라고 말하십시오.

→ habr.com/en/post/341654

잠재 기생충

기본적으로 목표를 설정하고 실행을 모니터링하는 데는 기생 방식과 공생 방식이라는 두 가지 접근 방식이 있습니다.
공생적 접근 방식은 문제가 해결되도록 보장하는 것입니다.
기생 접근법은 문제가 해결되지 않았는지 확인하는 것입니다.
공생적 접근 방식은 간단하고 간단하지만 구현하기가 어렵습니다. 그러므로 그것은 드뭅니다.
임무는 목표, 자원, 한계 등 모든 것이 명확하게 설정됩니다.
문제가 정확하게 해결될 수 있도록 제어가 이루어집니다.
공생적 접근 방식은 문제 해결에 대한 책임의 일부를 (게다가) 감독에게 맡기는 것입니다.
기생 접근 방식은 화려하고 영리하지만 구현하기 쉽습니다. 그러므로 자주 발생합니다.
작업은 아무것도 명확하지 않은 방식으로 제기됩니다. 덜 명확할수록 좋습니다.
전혀 통제하지 않는 것이 좋습니다.
작업 감독에게는 책임이 없습니다. "원숭이" 전체가 연기자의 목에 이식됩니다.
기생적 접근의 목적: 조작, 정서적 고통, 자기 확인. 따라서 초보 직원과의 멘토 작업에서 종종 발견됩니다.
물론 공생적 접근 방식이 더 좋습니다.

→ habr.com/en/post/343696

차원과 환상

측정 없이 활동의 ​​과정과 결과를 평가하면 항상 실수를 하게 됩니다.
숫자가 없는 평가는 기분에 따라 달라집니다. 기분이 좋지 않습니다. 일이 잘 안되는 것 같습니다. 좋은 기분은 그 반대입니다.
이렇게 하면 일주일 동안은 앉아서 엉성하게 일을 할 수 있고, 금요일에는 훌륭한 결과를 얻을 수 있고, 일주일 내내 잘 지낸 것처럼 보일 것입니다.
기본적으로 측정항목에는 정량적 측정항목과 대체 측정항목(프로그래머에게는 부울로 더 잘 알려져 있음)이라는 두 가지 유형이 있습니다.
"작업 완료 시간"은 부울입니다. 이는 "부품이 좋다"(숫자로 측정할 수 없는 경우 품질의 대체 표시)와 동일합니다.
"우리는 잘 일하고 있다", "우리는 계획을 이행하고 있다", "나는 훌륭하다" - 또한 부울입니다.
부울 유형 추정을 사용하여 제어 프로세스를 구성하는 것은 어렵습니다. 가능한 한 빨리 정량적 지표로 전환하는 것이 좋습니다.
부울은 관료주의와 형식주의를 생성합니다. 예를 들어, 마감 시간을 늘리고, 스스로 작업을 고안하고, IBD를 구현함으로써 작업을 제 시간에 완료할 수 있습니다.
부울 지표를 기반으로 관리하려면 회의, 분석 등에 많은 시간을 투자해야 합니다. 정보가 너무 적기 때문이죠.
과정과 결과를 모두 측정하는 것이 좋습니다. 그러면 그림이 가장 완성 될 것입니다.
프로그래머라면 스크럼의 '플래닝 포커(Planning Poker)' 방식을 추천한다.

→ habr.com/en/post/343910

이것은 스파르타

당신이 프로그래머이고 심각한 임무를 맡았다고 가정해 봅시다. 그리고 당신은 문제를 해결할 필요가 없다고 생각합니다. 그것은 어리 석고 해롭습니다.
이러한 상황에서의 일반적인 동작: 공개 필드에 작업을 표시합니다. 상사에게 승인을 위해 보내고, 내부 프로젝트를 시작하고, 시스템에 기록하는 등의 작업을 수행합니다.
여기서 모든 것이 무너집니다. 임무를 맡은 사람은 바보로 여겨지기를 원하지 않습니다. 그리고 일단 공개 분야에 들어가면 스스로를 방어할 것입니다.
정치적 의미에서 사람이 체면을 잃지 않는 것이 중요합니다. 정치에서 가장 중요한 것은 실수를 결코 인정하지 않는 것입니다. 아무것도 할 필요는 없지만 가장 중요한 것은 실수를 인정하지 않는 것입니다.
사람은 프로그래머가 악당, 바보, 변화의 반대자임을 증명하기 위해 최선을 다할 것입니다. 그리고 프로그래머는 여전히 문제를 해결해야 합니다.
어떤 경우에는 프로그래머가 문제를 전혀 해결하지 못하도록 모든 것을 준비합니다. 그러면 그 사람은 "백인"이 될 것이고, 프로그래머는 완전히 "흑인"이 될 것입니다(그는 저항했고 결국 실패했습니다).
몇 가지 솔루션이 있습니다.
첫 번째는 비즈니스 프로그래머가 되어 관련 분야를 이해하고, 그곳에서 무엇을, 어떻게 자동화할지 스스로 결정하는 것입니다.
두 번째는 Chief of Changes 기사입니다. 예를 들어 개발 이사.
셋째, 나타나지 말고 시키는 대로만 하세요.
넷째 - 스파르타의 길, 결정을 빠르게 거부합니다. 빠른 실패, 저렴한 실패로 더 잘 알려져 있습니다.
가장 중요한 것은 홍보를 포함하지 않는 것입니다. 그 사람에게 말하세요 - 많은 시간을 낭비하지 말고 프로토타입을 만들어서 솔루션이 실행 가능한지 확인합시다.
프로토타입에는 약간의 시간이 걸립니다. 성공하면 둘 다 정상적인 결정과 정치적 포인트를 얻게 됩니다.
실패하면 누구도 다치지 않을 것이다. 글쎄, 사람들은 프로그래머를 더 잘 대할 것입니다.

→ habr.com/en/post/344650

대리인

비즈니스는 1C 및 해당 제품, 웹 개발자, QMS, 회계, 경제학자, 개발 프로젝트, 스크럼, TOS, 제어, KPI 및 동기 부여 시스템을 좋아하지 않습니다.
기업은 자동화로 인한 수익성 증가, 온라인 프로모션으로 인한 매출 증가, 제품 품질 개선, 간단하고 이해하기 쉬운 숫자의 비즈니스 그림, 회사 상태 예측, 실질적인 효율성 증가, 프로젝트 완료 속도가 2~4배 빨라지는 것을 좋아합니다. 이익의 다중 증가 및 재고 감소 , 정확한 관리 시스템, 비즈니스 상황을 평가하기 위한 명확하고 이해하기 쉬운 시스템, 관리자의 절반을 해고할 수 있는 노동 평가 시스템.
비즈니스는 비즈니스 목표 달성을 좋아합니다. 기업은 대리모를 좋아하지 않습니다.
대리자는 비즈니스 목표 달성을 요청했지만 자동화 프로젝트, 웹 사이트, 종이 더미, 이해할 수 없는 직원 또는 읽을 수 없는 발 랩 보고서를 받은 경우입니다.
대리자는 길에 따른 목표가 성취의 수단으로 대체되는 경우입니다. 그리고 그들은 모두 목표를 잊어버렸습니다.
대리모 생산은 형식주의, 점진주의, 상호 책임이라는 세 가지 기둥을 기반으로 합니다.
형식주의는 분해를 통해 목표를 종이로 옮기는 것입니다. 그러나 본질적으로 관심의 초점을 큰 목표에서 작은 세부 사항으로 옮기는 것입니다. 더 이상 목표를 기억하는 사람은 아무도 없습니다. 모두가 세부 사항에 대해 논의하고 있습니다.
점진주의는 목표에서 수단으로의 전환 속도가 느립니다. 처음에는 여전히 목표가 논의되는 경우가 있습니다. 그러나 점차적으로, 단계별로 언급되는 횟수가 점점 줄어들고 있습니다. 고객 자신이 잊어버릴 때까지 세부 사항에 빠져들게 됩니다.
상호 책임은 모든 계약자가 거의 동일하게 행동한다는 것입니다. 실제로 수익을 증가시키는 단일 자동화 도구는 없습니다. 따라서 고객은 실제로 선택의 여지가 없습니다.
무엇을해야합니까?
대리자를 피하고 대리자를 생성하기 위한 첫 번째 단계인 형식주의를 피하세요. 적어도 내부 프로젝트에서는요. 목표를 설정하고 이에 대해 출연자와 지속적으로 대화하십시오. 규모, 자원, 계획 등에 대해 - 같은. 그러나 가장 중요한 것은 목표에 관한 것입니다.
그렇지 않으면 관심의 초점이 확실히 바뀌고 다른 대리자를 얻게 될 것입니다.

→ habr.com/en/post/344844

잽 클리츠코

그런 권투 선수가 있습니다 - Vladimir Klitschko. 그는 잽을 지속적으로 사용하는 특이성을 가지고 있습니다. 글쎄요. 다른 복서보다 더 일관성이 있습니다.
잽은 상대를 끊임없이 긴장하게 만들고 지치게 만듭니다.
Klitschko 잽의 주요 특징: 실행 용이성(물론 상대적) 및 일관성.
많은 저자들은 지속적으로 수행되고 유용하지만 간단한 조치가 많은 이점을 가져올 수 있다고 말합니다.
나도 시도해보기로 결정했습니다. 오늘은 어떤 잽을 했는지 간단한 회계 시스템을 만들어 봤습니다.
공장에서 일어난 일입니다. 나는 점심 시간에 잽을 했습니다(점심 시간이 없습니다). 하루에 1시간. 남들이 하지 않는 일을 했습니다(그렇게 하면 성공할 수 있다고 합니다).
저는 자가 학습 시스템 테스트를 설정하고, 개발 아이디어를 생각해 내고, 다른 사람의 개발 아이디어를 구현하고, 자동 작업을 설정하고, 코드를 리팩토링하고 최적화했습니다.
매일 - 이 목록의 모든 작업. 작업 하나를 완료했습니다. 잘생겼습니다. 여러 가지가 가능합니다.
관찰은 3개월 동안 수행되었다. 이 기간 동안 저는 30번의 점검을 수행하고 200개의 아이디어를 생각해 냈으며 80개의 다른 사람의 아이디어를 구현하고 XNUMX개의 부서를 위한 자동화된 프로세스를 구축하고 XNUMX개의 멋진 최적화를 수행했습니다.
시원한. 음, 이것은 "중간"입니다. 나는 모든 사람에게 추천합니다.

→ habr.com/en/post/344934

유연한 대리자

"스크럼"이라는 단어는 철학과 프레임워크라는 두 가지 이상의 개체를 나타냅니다.
작업에 대한 철학 또는 접근 방식은 Jeff Sutherland의 책에 설명되어 있습니다.
프레임워크, 즉 작업 알고리즘은 Scrum Guide라는 문서에 설명되어 있습니다.
철학의 저자들이 (자신의 말로) 그것으로부터 돈을 벌고 싶었기 때문에 철학은 하나의 틀이 되었습니다.
철학에 비해 프레임워크가 크게 단순화되었습니다. 가장 중요한 것은 목표가 단순화되었거나 오히려 폐기되었다는 것입니다.
철학의 목표: 결과 달성을 가속화합니다. 게다가 때때로. 이 책에는 8배 가속의 예가 포함되어 있습니다.
프레임워크의 목적: 스크럼을 갖기 위함입니다. 거기에는 다음과 같이 적혀 있습니다. 지침을 따르면 스크럼이 있고, 지침을 위반하면 스크럼이 없습니다.
프레임워크는 결과 달성의 가속화를 전혀 의미하지 않습니다.
Scrum을 가르치거나 구현하는 사람들은 프레임워크를 사용하여 작업합니다. 그들은 “이제 스크럼이 있습니다.” 외에는 어떤 결과로도 이어지지 않는 알고리즘을 말하고 구현합니다.
요점은 분명합니다. 철학은 판매하기가 매우 어렵습니다. 프레임워크가 더 간단합니다.
프레임워크는 제품입니다. 예상대로 그는 "포장"을 거쳤습니다. 간단하고 이해하기 쉬우며 지원과 많은 전문가가 있습니다. 아무것도 생각나지 않나요?
결과를 제외하고는 모든 것이 정상입니다. 결과가 없습니다.
고객이 스크럼 철학에 익숙하지 않은 경우 프레임워크 구현에 상당히 만족할 것입니다.
고객이 스크럼 철학에 익숙하다면 프레임워크 구현에 실망하게 될 것이며 결과 달성이 가속화되지 않을 것입니다.
멋지고 패셔너블하며 현대적이지만 비즈니스 목표는 달성되지 않습니다(“새로운 것”을 위한 예산 지출 제외).
어떻게 해야 하나요? 스크럼 철학을 공부하세요. 이는 품질 관리에 대한 일본의 철학을 기반으로 하며, 그 핵심은 측정과 끊임없는 개선입니다.
안타깝게도 많이 생각하고, 실험하고, 관찰하고, 아쉽게도 노력해야 합니다. 이것이 당신에게 적합하지 않다면 프레임워크를 사용하십시오.

→ habr.com/en/post/345540

출처 : habr.com