회의 시간과 개발 시간 절약 사이에 관련 요소가 있습니까?

저는 프로젝트를 진행하고 있으며 정기적으로 (보통 매주) 비공식 회의를 통해 프로젝트의 상태와 프로젝트의 GUI에 대해 논의합니다.

나는 유일한 개발자이고 다른 4-5 사람들은 IT가 아닌 배경을 가지고 있습니다.

이 회의는 평소보다 훨씬 오래 걸렸지 만 어느 시점에서 동료 중 한 명이 프로그램의 일부 필드와 작성 방법에 대해 물었습니다. 나는 대답을하고 토론에서 마음 속으로 과정이 잘못되었다는 것을 알게되었다.

그러나 우리가 그것에 대해 이야기하고 오류를 미리 발견했기 때문에 오류를 꽤 빨리 바꿀 수 있습니다.

이것에 대해 생각하면서 개발 시간을 절약 할 때 회의 시간 사이에 요인이 있는지 스스로에게 물었습니다.

예를 들어, 1 분의 회의 시간은 X 분의 개발 시간을 절약 할 수 있습니다.

그렇다면 회의를 얼마나 자주, 얼마나 오래 정의해야하는지 정의하는 것이 도움이됩니다.

(명쾌하게 설명하기 : 더 나은 회의를하고 싶지 않으며 회의 시간을 대략 결정할 수있는 것도 선택 사항입니다. 회의 시간과 개발 시간 사이에 관계가있는 경우 가장 관심이 있습니다! 궁금한 점은 : 호기심입니다! )

"필요한 한 더 이상 필요하지 않습니다."

여기서 알아야 할 것은 개발 시간을 단축하기위한 회의 시간이 결코 선형 적이 지 않다는 것입니다. 팀, 회사, 이 주제에 대해 1 시간의 회의는 2 시간의 개발 작업을 절약 할 수 있습니다. 10 시간의 회의가있는 경우 다른 1 시간의 회의는 0 개의 개발 작업을 절약 할 수 있습니다. 지옥, 그것은 사기 나 사기에 대한 영향으로 인해 2 시간의 개발 작업을 절약 할 수 있습니다.

결국 회의의 전체 요점은 의사 소통과 협업이 일을 처리하는 데 도움이된다는 것입니다. 회의가 당신이 일을하는데 도움이되지 않는다면, 그들은 죽여야합니다.

정확히.

고객 / 이해 관계자를 이해하면 개발 시간을 절약 할 수 있습니다. 대화는 이해하기 쉽도록 충분히 길어야합니다. 그러나 이미 이해하고 있다고 생각되는 기능을 논의한다고해서 반드시 이해력이 향상되는 것은 아닙니다.

방 안에 아무도 오해 나 거짓 가정을 의심하지 않으면 방을 떠나십시오. 전단 시간과 압력이 갈등을 일으키고 조화를 이룰 것이라는 희망에서 "토론"을 인위적으로 연장하는 것은 절망적이고 절망적입니다.

의사 소통은 기술과 행운의 조합이라는 것을 기억하십시오. 토론이 반드시 의사 소통을 의미하지는 않습니다 (상호 이해). 현장에서 더 오래 일하고 더 오래 일하면 나쁜 가정을 더 잘 드러 낼 수 있습니다.

그 동안 "민첩성"이 도움이 될 수 있습니다.

"짧은"회의를 유지하고 원유 UI의 또는 모형 구현 가능한 빨리를 각 회의 후 - 당신도 잘 전에 의심 완전한 이해를 할 수 있습니다. UI / 모의는 오해를 명확히하기위한 자료로 사용됩니다. 회의 사이의 시간은 모든 사람이 말한 것을 압축 해제하고 반영하는 데 도움이됩니다. show-and-tell 자료 를 코드 로 구현하면 실제로 개발을 시작한 것 입니다. (그리고 당신의 고객 / 동료들은 이것을 듣고 기뻐할 것입니다!)

그리고 최악의 시나리오 는 눈 에 띄는 작은 코드 덩어리를 구현했을 때입니다 . 당신은 완전히 기반을 벗어 버리고 버립니다. 그러나 적은 시간 만 투자했다면 막대한 오해를 명확히하는 데 큰 투자를합니다 .

그리고 회사는 개발 시간에 신경 쓰지 않습니다 . 그것은 단지 person-time에 관심 이 있습니다 . ( 총 비용 을 계산하는 수단으로 생각하십시오.) 따라서 개인 시간 이 최소화 되는 균형을 찾아야합니다 . 코드 작성에 시간이 걸리지 않았습니다 .

나는 일반적으로 적용될 수있는 어떤 종류의 상관 관계가 있다고 생각하지 않습니다. 그것은 회의와 개발과 관련된 일에 달려 있습니다.

당신이 묘사하는 상황에서, 몇 분 안에 당신은 나쁘거나 이해하기 어려운 요구를 갖는 것에서 더 좋은 것을 갖는 것까지 갔다. 우리는 좋은 요구 사항이 개발 시간에 직접적인 영향을 미친다는 것을 알고 있습니다.

그러나 회의가 회사 상태 회의와 같은 것이면 어떨까요? 좋은 정보를 공유하여 회사가 어떻게하고 있는지, 다른 일을 알고 있는지 등을 알 수 있습니다. 그러나 대부분 프로젝트의 개발 시간에는 영향을 미치지 않습니다. 개발 관점에서 볼 때 모든 시간은 "폐기"됩니다.

충분한 회의에 참석 한 후에는 일부는 실제로 생산적이라는 사실을 깨닫기 시작합니다 (예 : 소규모 개발자 팀과 좋은 요구 사항을 충족하고 아키텍처를 화이트 보드로 시작합니다. 집중을 유지하면 많은 일을 할 수 있습니다 ). 또한 전혀 생산적이지 않거나 생산성이 좋지 않은 제품도 있습니다 (한 번 고객이 로그인 페이지에 "로그인"또는 "로그온"이라고 표시해야하는지에 대해 고객이 15 분 동안 토론을하게 된 경우). 그것의 끝, 아무도 몰랐고 나중에까지 테이블에 있어야했다).

TL / DR : 회의, 사람 및 회의 목표에 따라 다릅니다.