이것은 내가 “영원한 갈등”(비즈니스와 엔지니어링 사이)으로 생각하기 시작한 것으로 요약됩니다. 나는 결코 사라지지 않는 문제이기 때문에 해결책이 없지만 완화에 도움이되는 것들을 할 수 있습니다.

• 가치 전달

사람들이 종종 깨닫지 못하는 것은 엔지니어로서 “성공적인 비즈니스”의 문제가 항상 주어진다고 가정합니다. 우리는 코드가 훌륭하고 깔끔하고 유지 관리 가능해지기를 원하므로 더 나은 코드로 방해 받았던 기괴한 프린지 사례를 발견하여 새로운 기능을 추가하고 기존 기능을 신속하게 조정하고 최소한의 고객으로 QA를 수행 할 수 있습니다. 고객을 유지하고 기능과 섬세함을 갖춘 경쟁력을 유지하는 사람은 누구도 충분히 빨리 생산할 수 없습니다. 좋은 코드가 직접 코드를 직접 작성하고 더 나은 코드를 원하는 이유를 알려주는 비즈니스 성공입니다.

철자를 쓰세요. “우리는 Y로 인해 비즈니스에 부정적인 영향을 미치지 않으면 서 코드베이스에서 X를하고 싶습니다.” “

개선이 효과가 있다는 확실한 증거를 얻으려고 최선을 다하십시오. 앱의 일부 하위 집합을 개선하여 기능 / 개선이 더 빨라진 경우 증거를 위해 사용중인 백 로그 도구를 확인하고 적절한 회의에서 지적하십시오.

• 같은 빌어 먹을 페이지에서 팀을 잡아

자아는 종종 문제입니다. 엔지니어링 팀이 매우 나쁘게 필요한 한 가지는 자신의 쿨 에이드 주르 컵을 더 잘 아는 모든 사람들에 대해 특정 유형의 문제를 해결하기위한 일관된 접근 방식의 가치를 확립하는 것입니다. 다른 사람의 선호도가 당신보다 나쁘다는 것을 믿어도 괜찮지 만 그의 접근 방식이 실행 가능하고 이길 수없는 논쟁이라면 일관성을 중요하게 생각합니다. 일관성을 위해 타협하는 것이 중요합니다. 일관된 방법이 일반적으로 가장 빠른 방법이기 때문에 일이 일관되면 잘못하기가 더 어렵습니다.

• 올바른 도구를 선택하십시오

프레임 워크 / 툴셋 / 라이브러리 / 무엇의 두 학교가 있습니다. “내가 당신을 원하지 않을 때 방해하지 말고 내가 실제로 원하는 것들로 DIY를 매우 빠르고 일관되게 도와주십시오.” 스틱 원리보다는 당근에 사용하는 것이 좋습니다. ” 두 번째 것을 좋아하십시오. 비즈에게 “우리 자신의 도구가 우리를 허락하지 않기 때문에 우리는 이것을 할 수 없습니다”라는 말은 결코 받아 들일 수없는 대답이며 질문은 항상 사소한 / 일회용 제품 엔지니어링. 내 경험상, 융통성이없는 도구는 거의 항상 활짝 열리거나 부주의하게 작업하여 유지 관리 할 수없는 커다란 거대 쓰레기를 만듭니다. 보다 더 자주하지, 유연하고 쉬운 솔루션 수정은 단기적으로 거의 또는 거의 빠릅니다. 올바른 도구를 사용하여 빠르고 유연하며 유지 관리가 가능합니다.

• 엔지니어가 결정하지 않은 경우 FFS는 도구 선택에 대한 엔지니어의 의견을 얻습니다.

나는 이것이 개발자 관점의 질문이라는 것을 알지만 제로 엔지니어 입력으로 기술 결정이 내려진 너무 많은 상황에 처해 있습니다. 도대체 무슨 일이 있다는 것입니다? 예, 누군가 최종적으로 전화를해야하지만, 기술 담당자가 아닌 경우 영업 사원이나 데모 사이트가 자체 제품에 대해 말한 것이 아니라 자격을 갖춘 의견을 얻으십시오. 사람들이 똑똑하지 않아도되거나 개발자를 자신으로부터 보호하기 때문에 돈을 절약 할 수 있다고 약속하는 것은 더럽고 더러운 거짓말입니다. 신뢰할 수있는 인재를 고용하십시오. 스택 또는 기타 기술 솔루션에서 원하는 것을 철자하고 기술 밴드 왜건을 결정하기 전에 입력을 진지하게 받아들입니다.

• 구현보다 디자인에 집중

도구는 구현을위한 도구이므로 도움이 될 수 있지만, 우선 순위는 해당 아키텍처를 구축하기 위해 가지고있는 장난감 세트에 관계없이 아키텍처 여야합니다. 하루가 끝나면 KISS와 DRY 및 .NET 또는 Java 또는 무료 또는 빠지지 않는 것 이상의 문제에서 확장되는 모든 훌륭한 철학이 있습니다.

• 우려 사항 기록

비즈 측이 나쁜 방법을 고집 할 때, 특히 비용이 많이 드는 이유를 말한 부분을 이메일로 저장하십시오. 모든 예측이 이루어지고 심각한 비즈니스 피해 문제가 발생하면 엔지니어의 우려를 더 심각하게 받아 들일 수있는 많은 논란이 생깁니다. 그러나 신중하게 시간을 내십시오. 타오르는 불길의 한가운데는 화재 코드를 따르는 데있어 “I-told-you-so”가 안 좋은시기입니다. 화재를 진압하고 이전에 무시한 우려 사항 목록을 회고 회의 / 대화에 가져 와서 실제 사람들의 이름이 아닌 공학적 우려에 대해 표현하고 무시한 이유와 이들이 무시 된 이유를 이해 한 이유에 계속 집중하십시오. 무시하기로 결정했습니다. 당신은 엔지니어입니다. 사람들이 아니라 문제를 해결하십시오. ” 우리는 Y 문제로 이어질 까봐 X에 대한 우려를 표명했습니다. 우리는 Z에게 말하고 그것을 다루는 것을 연기했다. “

답변