엔지니어링 프로세스를 업데이트할 때입니까?

잘 고려된 엔지니어링 프로세스는 모든 회사의 자산이지만 정기적으로 업데이트되지 않으면 이러한 프로세스로 인해 속도가 느려질 수 있습니다.

나는 무거운 엔지니어링 프로세스 문화를 가진 회사에서 Intercom에 왔습니다. 그것은 전투 테스트를 거치고 종종 업데이트되는 절차를 통해 기름칠이 잘 된 기계였습니다.

엔지니어링 관점에서 성공적으로 코딩에 집중할 수 있도록 했습니다. 작업은 항상 Jira에 잘 설명되어 있으며 명확하게 정의된 기대치를 포함했습니다. 디자인이 들어오고 HTML로 내보내지므로 Sketch 사용에 대해 걱정할 필요가 없습니다. 작업을 수행한 다음 작업을 QA로 옮겼습니다. 무언가가 돌아오면 항상 작동하지 않는 것에 대한 좋은 설명과 함께 있었습니다.

그런데 인터콤에 입사했을 때 주간 엔지니어링 프로세스 가 이전 회사에 비해 가벼워서 놀랐 습니다. 견적이 없습니다. 아니 지라. 별도의 QA팀이 없습니다. 처음에는 압도감을 ​​느꼈습니다. 왜 이렇게 생겼는지, 왜 모든 사람들이 정렬을 하고 아무도 나처럼 프로세스를 구성하려고 하지 않았는지 궁금했습니다.

“프로세스는 제품 개발에 도움이 되어야 합니다.”

가장 큰 이유는 두 회사 모두 겉으로 보기에는 비슷해 보여도 풀어야 할 문제가 달랐기 때문이다. Intercom은 매우 제품 우선 회사 이며 매우 무거운 프로세스는 제품 우선 회사에서 너무 많은 제약이 될 수 있습니다. 이러한 종류의 환경에서 프로세스는 미리 결정된 프로세스에서 제품이 개발되는 것이 아니라 제품의 개발을 지원해야 합니다.

Intercom 은 올바른 문제를 해결 하는 매우 강력한 문화를 가지고 있습니다 . 우리는 진정한 문제가 무엇인지, 작고 범위가 넓은 프로젝트(또는 컵케이크 라고 부르는 것과 같이)를 사용하여 문제를 해결하는 방법, 그리고 컵케이크가 성공적으로 판명되면 결과적으로 어떻게 보일지 정의하는 데 무자비합니다. .

요컨대, 우리는 문제가 무엇이며 해결되었는지 어떻게 측정할 것인지 묻습니다. 그리고 우리는 우리 제품에 대해 작업할 때 이 접근 방식을 사용하는 것이 아니라 새로운 엔지니어링 프로세스를 추가하거나 기존 엔지니어링 프로세스를 조정할 때마다 동일한 접근 방식을 적용하려고 합니다.

프로세스의 무의식적 이점

모든 조직에서 프로세스는 중요하고 유익합니다. 워크플로를 간소화하고 사람들이 실수를 덜 하도록 도우며 어느 정도의 편안함을 제공합니다. 적절한 프로세스 집합을 통해 작업이 이미 진행되기 시작했다는 느낌을 받을 수 있습니다.

“절차는 제도적 습관이라는 점에서 일반적으로 편안합니다.”

절차는 일반적으로 제도적 습관이라는 점에서 편안합니다. 우리는 이미 다양한 업무를 수행하고 있으므로 프로세스에 맞춰 정렬된 업무는 습관과 비슷합니다. 이 프로세스는 이미 위험 요소가 제거되고 심사숙고되었으며 이상적으로는 입증된 성공 실적이 있습니다. 접시에서 많은 것을 제거하고 중요한 것에 집중할 수 있습니다. 당신의 접시에 더 적은 것을 가지고 있다는 것은 설득력이 있습니다. 그렇죠?

당신이 가진 문제 해결

새로운 프로세스를 설계할 때마다 가장 중요하고 어려운 부분은 해결하려는 문제를 명확하게 정의하는 것입니다. 이 단계를 건너뛰지 않는 것이 중요합니다. 문제를 명확하게 식별하지 못하면 왜 시작했는지 스스로에게 물어볼 필요가 있습니다. 명확하게 정의된 문제 없이 진행하는 것은 관료주의에 대한 걱정스러운 경향의 신호일 수 있으며 이는 종종 최고의 직원을 소외시키는 첫 번째 단계가 될 수 있습니다.

“프로세스에 맞춘 일은 습관과 같다”

대신 프로세스는 민첩하고 혁신적이어야 합니다. 그들은 당신이 빨리 움직일 수 있도록해야합니다. 그들은 당신이 가장 중요한 일에 집중할 수 있도록 인지적 부담을 덜어줄 수 있지만, 당신이 그것들과 관련된 적절한 문제를 해결하는 경우에만 가능합니다.

나는 당신이 없애고 싶은 몇 가지 문제를 쉽게 찾을 수 있다고 확신합니다. 그것은 "우리가 고용한 사람들과 실수를 저지르는 것"과 같은 거대한 것일 수 있으며, 이는 당신의 채용 과정을 재평가하게 됩니다. 소프트웨어 컨설팅에서 문제는 예측 가능성과 고객에 대한 책임입니다. 인터콤에서 우리의 문제는 고객의 문제이며 최고의 제품을 만드는 데 있습니다. 다음은 이러한 문제를 해결하기 위한 조언입니다.

성공 기준 정의

문제를 잘 이해했다면 프로세스의 성공 기준을 정의하십시오. 프로세스로 시작하지 말고 성공이 어떤 모습인지부터 시작하십시오. 성공부터 시작하면 디자인에 대한 편견(익숙한 것, 익숙한 것 등)을 없애고 대신 가능한 최상의 결과 에 초점을 맞춥니다 . 이것은 프로세스의 진정한 성공을 정의합니다. 가치 없는 사용은 명백한 실패이므로 프로세스의 사용 자체가 성공의 척도가 아님을 기억하십시오.

“불편함이 심한 상황에서는 '사용이 성공이다'라는 생각의 함정에 빠지기 쉽습니다.”

불편함이 큰 상황에서 "사용이 성공이다"라는 생각의 함정에 빠지기 쉽습니다. 주변의 현재 수준의 구조에 불편함을 느끼면 구조를 개선하고 새로운 프로세스를 도입하는 것에 대해 생각하기 시작합니다. 그러나 프로세스가 실제 문제를 해결하지 못하고 성공 기준을 충족하도록 지속적으로 개선되지 않으면 사람들이 혁신을 방해하고 문화에 해를 끼칩니다.

엔지니어링 프로세스를 주기적으로 업데이트

오래된 엔지니어링 프로세스가 습관적으로 의존하는 것보다 유용성이 오래 지속되면 이를 업데이트하거나 제거하는 것이 중요합니다. 프로세스를 설계하는 전체 연습은 문제 해결을 기반으로 합니다. 그러나 이 문제는 솔루션을 설계할 때 현재 존재합니다. 문제는 고정된 상태로 유지되지 않으므로 프로세스도 마찬가지입니다.

"프로세스가 실제 문제를 해결하지 못하면 문화에 해를 끼칩니다."

잘못된 문제를 해결하고 있지 않은지 확인하려면 프로세스를 사용하는 모든 사람이 현상 유지에 도전하도록 격려해야 합니다. 이를 달성하려면 프로세스를 쉽게 변경할 수 있어야 합니다.

습관과 프로세스를 마스터하십시오.

절차는 관료주의에 의해 부담되지 않고 유익하고 도움이 되어야 합니다. 최선을 다하면 혁신하고 빠르게 움직이며 집중할 수 있도록 도와줄 수 있습니다. 그러나 모든 회사는 서로 다른 문제를 해결하려고 하므로 서로 다른 프로세스가 필요하다는 점을 기억해야 합니다. 최악의 시나리오는 문제를 해결하지 못하거나 회사의 목표에 도움이 되지 않는 프로세스를 적용하려고 할 때입니다.

습관과 마찬가지로 어떤 프로세스는 좋고 어떤 프로세스는 나쁘며 어떤 프로세스는 유용성보다 오래갑니다. 습관과 마찬가지로 프로세스도 변경하기 어려울 수 있습니다. 그러나 성공한 사람들과 마찬가지로 성공적인 회사는 습관에 의존하기보다는 습관을 개발하고 변경할 수 있는 능력으로 정의된다는 점을 기억하십시오.

일하기 좋은 환경이라면 적극적으로 채용하고 있습니다. 채용 공고를 확인하세요.