제품 개발 프로세스의 숨겨진 비용과 실질적인 민첩성 확보

우탕 일족이 옳았습니다.

현금이 내 주변의 모든 것을 지배합니다. 아무리 투명한 조직이라도 이를 부정할 수는 없습니다. 현금의 발전은 프로젝트 관리 방법, 프로세스 조정 및 최적화 또는 직원 동기 부여는 기본적으로 돈에 대한 보편적인 필요성에 의해 촉발됩니다. 디자인 민첩성에는 특정 위험이 수반됩니다.

우리 모두는 날씬하고 민첩성 수치로 측정되는 활동의 결과가 최대한 높게 나타날 수 있도록 노력합니다. 손실을 줄이는 데 대부분의 에너지를 집중하더라도 결국에는 절감된 비용으로 인해 증가한 수익을 고려합니다.

이렇게 절약된 비용은 나머지 요소들과 함께 같은 주머니에 들어가며, 가장 호기심이 많은 요소들만 사용할 수 있습니다. 이런 식으로 우리는 집중력을 잃고 의도치 않게 많은 귀중한 데이터와 궁극적으로 인텔리전스를 누락하게 됩니다.

실패에서 얻은 교훈

자신의 실수로부터 배우는 것은 특히 유용한 (비용이 많이 들지만) 기술입니다. 조직 문화 그리고 이 능력에 내재된 외교가 항상 도움이 되는 것은 아닙니다. 우리는 종종 "연막"이라는 말로 재정의 부정적인 영향을 숨기곤 합니다. 투자자가 "돈을 잃었어요!"라고 소리치면, 관리자는 그 사실을 팀 "우리는 더 효과적이어야 한다"고 말하며 우리 모두는 기본적으로 새로운 솔루션과 개선점을 찾고 있으며, 뒤를 돌아보는 대신 끊임없이 앞으로 나아갈 방법을 찾고 있습니다.

한편, 손실은 종종 올바른 결론을 도출하기 위한 열쇠입니다. 프로세스의 특정 흐름 단계를 제대로 고려하지 않고 넘어가면 다음 솔루션도 동일한 오류에 감염될 가능성이 높습니다.

예시: 

시니어 JS 개발자로 구성된 소규모 팀이 예상 시간 내에 기능을 제공하지 못합니다. 개발 속도를 높이고자 하는 투자자가 새로운 프로그래머를 고용하라고 지시합니다. 프로젝트에 새로운 인력을 투입하면 팀의 집중력이 분산되어 프로젝트 진행 속도가 더욱 느려집니다.

투자자가 팀의 비효율성의 원인을 더 잘 이해한다면 60-70%에서만 잠재력을 사용한다는 결론을 내릴 것입니다. 더 나은 장비와 작업 자동화에 며칠을 투자하면 문제가 해결될 것입니다.

안타깝게도 이제 그는 동일한 장비에서 작업할 다른 개발자에게 비용을 지불해야 하며, 그의 효율성도 60-70%에 머물게 될 것입니다.

솔루션 A:

• 팀(시니어 JS 개발자 2명): $20만 / 월
• 클라우드 서비스 200$ / 월
• 개발자를 위한 새로운 하드웨어: $10k

지금부터 프로젝트 비용은 $20,200 / 월입니다.

12개월 동안의 총 지출액: 12 * 20,200 + 10,000 = $252,400

솔루션 B:

• 팀(시니어 JS 개발자 2명): $20만 / 월
• 신규 개발자(시니어 JS 개발자 1명): $10k/월

지금부터 프로젝트 비용: $30,000 / 월

12개월 동안의 총 지출액: 12 * 30,000 = $360,000

100%에서 일하는 두 명의 개발자는 60-70%에서 일하는 세 명의 개발자와 거의 동일한 작업을 수행합니다. 투자자는 잘못된 설계 결정으로 인해 연간 동일한 처리 용량에 대해 $ 100,000달러 이상을 더 지불하게 됩니다!

완벽한 제품을 만드는 것은 토끼를 쫓는 것과 같습니다.

프로세스의 민첩성이 반드시 100% 테스트 커버리지를 위해 노력하거나 성능 기록을 깨는 것을 의미하지는 않습니다. 이러한 지표는 프로젝트의 기술적 상태에 대한 개요를 제공하지만, 최종 고객의 관점에서 볼 때 매우 중요하지 않으므로 진정한 애자일 프로세스에서 이상적인 상태로 가져오는 것은 달성할 필요가 없습니다. 시장 값입니다.

완벽한 기술 솔루션을 개발하려면 많은 팀의 헌신과 훨씬 더 광범위한 커뮤니케이션이 필요합니다. 그 결과 패치 작업 속도가 느려지고 과도한 개발로 인해 프로젝트가 무거워집니다.

애자일 개발의 핵심은 제대로 작동하는 코드 최소한의 노력으로. 코드 테스트는 의심할 여지 없이 좋은 관행이며 테스트를 통해 코드의 작동에 대해 많은 것을 알 수 있지만 단순히 테스트를 수행하고 자랑하기 위해 수행해서는 안 되며 솔루션의 최적 기술 품질은 다음과 같이 결정된 최소값 사이에 있습니다. 개발팀 예산으로 제한되는 최대 금액입니다.

궁극적으로 완벽함은 아무 소용이 없습니다. 흥미롭게도 보안 문제도 이 규칙의 적용을 받는데, 이론적으로는 모든 시스템이 해킹될 수 있습니다. 그러나 앞서 언급한 최소 개발 수준은 코드 사고로 인한 잠재적 결과의 무게, 규모 및 비용에 따라 그에 상응하는 더 높은 수준이어야 합니다. 종종 오류 위험이 높고 보안 취약점이 발생할 수 있는 로그인 모듈을 처음부터 다시 작성하는 대신 상대적으로 빠르고 안전하게 구현할 수 있는 'Google로 로그인' 버튼 등을 사용하는 것이 좋습니다.

짧은 출시 기간이 목표인 한, 지나치게 야심찬 가정은 오히려 비생산적인 것으로 판명됩니다. 완벽해 보이는 프로세스에서 지나친 열정은 자원 낭비가 될 수 있습니다..

모든 것에 대해 모든 것을 아는 것이 좋습니다.

사용자 중심의 디자인은 멋집니다. 사람 중심의 협력이 더 중요합니다. 팀이 같은 파장으로 소통하면 자연스럽게 잠재적 손실을 줄일 수 있습니다.

프런트엔드 기술을 최신 상태로 유지하는 UX 디자이너는 솔루션을 제안하지 않습니다. MVP 구현 단계에서 불합리한 시간을 소비할 수 있습니다.

사용성 휴리스틱을 알고 있는 프론트엔드 개발자는 UX 디자이너의 개입 없이도 빠른 수정, 미리보기, 수락 등 주어진 화면 해상도에 맞게 인터페이스를 조정할 수 있습니다.

애플리케이션을 작업하려면 완전히 다른 역량 프로필을 가진 사람들의 활동을 동기화해야 합니다. 고객에게 가치를 효과적으로 전달하려면 팀 내 기술 분포를 파악해야 합니다.

참여도가 높고 동기화된 팀은 비용을 절감할 수 있는 핵심 요소입니다. 이러한 유형의 민첩성에는 최적의 제품 개발이 필요합니다..

이러한 방식으로 이해되는 좋은 팀 성과는 특히 다음과 같은 시대에는 달성하기가 매우 어렵습니다. 원격 근무. 수년간 '원격 친화적'으로 운영되어 온 기업은 봉쇄 기간 동안 조직을 조정해야 했고 이제 막 새로운 방법과 형태의 커뮤니케이션에 대해 배우고 있는 기업보다 이 분야에서 상당한 이점을 가지고 있습니다.

출발 전 강력한 장비

커뮤니케이션에 대한 요구가 증가함에 따라 Whimsical, Miro, Mural, Figma, Balsamiq 등의 도구가 인상적인 인기 상승을 기록하고 있습니다.

물론 봉쇄 조치와 원격 근무의 필요성이 이러한 사용자 폭발에 영향을 미쳤습니다. 도구 선택은 개인의 선호도에 따라 달라져야 한다고 생각하지만, Miro를 살펴보겠습니다:

이러한 도구의 대중화는 자연스럽게 방법론 자체의 인기 증가로 이어집니다. 페르소나 작업을 위해 Miro를 구매한 사람은 흥미롭고 팀의 일상 업무에 긍정적인 영향을 미칠 수 있는 수십 개의 다른 템플릿에 액세스할 수 있습니다.

프로젝트의 정보 흐름을 간소화할 수 있는 도구를 항상 갖추고 있어야 합니다. 새로운 도구와 방법에 대한 개방성 또한 효과적인 프로젝트의 기초 중 하나입니다. 제품 개발.

게으름을 피울 수 있고, 또 피워야 합니다.

인터페이스와 소프트웨어 아키텍처의 숙련된 설계자는 일반적으로 협력 초기에 검증해야 할 몇 가지 잠재적 솔루션을 발견하고 적절한 영감이나 시중의 기성 솔루션을 효율적으로 찾습니다. 일반적으로 프로토타입 단계에서 안전하게 사용할 수 있는 머티리얼 UI 프레임워크가 좋은 예입니다..

때로는 Behance 또는 Dribble에서 몇 가지 구현을 검토하고 영감을 얻어 무드 보드를 개발한 다음 개발자에게 전달하는 것으로 충분할 수 있습니다. 개발자는 이를 사용하여 클릭 가능한 프로토타입을 만들어 얼리 어답터에게 제시하고 피드백을 수집할 수 있습니다. 디자인에 관심이 많고 헌신적인 사람들 사이에서 효과적인 프로세스를 위한 이러한 유기적인 노력은 자연스러운 일입니다.

디지털 제품을 효율적으로 제공하려면 사람들이 자신의 업무를 수행할 수 있도록 해야 합니다. 고객에게 제공하고자 하는 가치/서비스가 무엇인지 알고 있다면 그것으로 충분합니다. 유능하고 잘 관리된 프로젝트 팀은 이 가치/서비스를 필요한 비용 효율성으로 최대한 빨리 제공하는 방법을 가장 잘 알고 있을 것입니다.

신뢰를 보여주고 책임을 공유하며 진정한 양방향 커뮤니케이션을 위해 마음을 열면 제품 가 더 나아질 것이며, 창업자와 기업가들에게 종종 지치게 하는 혼자서 모든 것을 만들어야 하는 부담을 덜어줄 것입니다! At The Codest이 원칙을 프로젝트뿐만 아니라 내부 프로세스에도 적용하고 있으며, 이것이 바로 고객과 직원 모두의 높은 유지율을 자랑하는 이유일 것입니다(실제 사례, 둘 다 90% 이상).

약간의 게으름으로 자신을 대하고, 과감하게 책임을 이양하고, 앞으로 나아가는 데 필요하지 않은 중복 작업은 과감히 버리세요. '있으면 좋은' 기능은 항상 기다릴 수 있습니다.

정답을 찾는 데 집중

디지털 제품을 만드는 과정은 다양한 관점, 경험, 정보 출처가 끊임없이 충돌하는 과정이며, 이러한 충돌은 잘못된 디자인 결정을 내릴 수 있는 위험을 수반합니다.

내부 커뮤니케이션이 원활하면 이러한 위험을 줄일 수 있지만 이는 동전의 양면일 뿐입니다. 시장과 소통하는 방법에 대한 질문은 아직 해답을 찾지 못한 채 남아 있습니다.

비즈니스 인텔리전스, 고객 지원, UX 연구 부서 및 기타 여러 부서와 마찬가지로 개발 팀제품 소유자나 UX 팀이 묻는 질문에 대한 구체적인 답변을 제공하는 데 필요한 최소한의 정보를 제공하기 위해 노력해야 합니다.

브랜딩 자체와 브랜드 커뮤니케이션 전략도 중요합니다. 이는 고객과의 질적 관계를 구축하는 역할을 하며, 이는 곧 고객과의 약속으로 이어집니다. 고객에게 질문을 하고 싶다면 고객이 이러한 질문에 기꺼이 대답할 수 있는지 확인해야 합니다. 목소리 톤이 중요합니다.

시장과 지속적으로 접촉하면 프로젝트가 성공할 수 있는 올바른 궤도를 정의할 수 있다는 것은 확실합니다. 덜 분명한 것은 프로젝트 초기에 이러한 접촉의 필요성을 고려해야 한다는 사실인데, 이는 팀의 적절한 역량을 예상하고(올바른 질문을 하고 그에 대한 답을 찾기 위해) 대상 그룹을 포함하는 제품 전략을 수립하는 것과 관련이 있습니다.

결론

위에서 언급한 모든 문제를 고려하면 디자인 프로세스에서 정기적으로 나타나는 몇 가지 문제를 관찰할 수 있습니다:

- 지나치게 수익 지향적이고 실패를 보지 않으려는 태도,

- 부정확하고 자신의 실수를 X-레이로 촬영하지 않습니다,

- 머릿속에는 있지만 시장이 필요로 하지 않는 완벽한 제품을 쫓아다니는 것은 바람직하지 않습니다,

- 교과서적인 프로세스의 과도한 구현 - 과도한 개발과 과도한 디자인,

- 팀워크의 유연성이 떨어지고 직원들이 자신의 전문 분야에만 머물도록 강요합니다,

- 비효율적인 커뮤니케이션,

- 바퀴를 재발명하는 경향이 있습니다.

거시적 규모의 프로세스 최적화에는 절감액의 합계가 포함됩니다. 위에서 언급한 과제에 제대로 대처하려면 동료들이 프로세스 개선을 위한 아이디어를 공개적으로 제시할 수 있도록 참여시켜야 합니다.

때로는 각자의 역할과 책임에 따라 부하 직원, 고객, 파트너의 말을 적게 하고 더 주의 깊게 듣는 것만으로도 성공을 거둘 수 있습니다.

충분하지 않은 경우, 과잉 투자할 가능성이 높습니다.. 돈이 너무 많으신가요?

닥치고 돈이나 가져가세요! 아, 게다가

1. 스크럼을 연습하기 위해 스크럼을 도입하지 마세요.
2. 프로세스의 누락에 더 많은 주의를 기울이세요.
3. 단기간에 달성 가능하고 측정 가능한 작은 목표를 설정하고, 일반적으로 최소한의 목표를 고수하세요.
4. 때로는 좋은 로드맵 는 팀원들에게 공동의 목표 의식을 심어주고 지금 여기에서 효과적으로 일할 수 있게 해줍니다.
5. 팀에 필요한 자유를 줄 수 있는 좋은 팀을 구성하세요.
6. 항상 현재 도구 세트에 의문을 제기하고 워크샵에서 개선할 수 있는 부분을 찾아보세요.
7. 게으른 사람의 관점에서 가능한 한 일을 적게 하려는 것처럼 프로세스를 설계하세요.

자세히 읽어보세요:

CTO 과제 - 소프트웨어 제품의 확장 및 성장

소프트웨어 프로젝트에서 특정 데이터 유형에 대해 선택할 DB