새로운 모바일 개발 팀이 필요하다는 5가지 신호

천국으로 가는 계단처럼 느껴졌어야 했다. 당신은 바퀴를 굴리기 시작했고, 당신 자신을 자랑스러워해야 합니다. 당신은 훌륭한 프로젝트 아이디어를 가지고 가서 계속해서 가슴을 두드리는 사람들을 고용하여 합리적인 가격에 작동하게 할 것이라고 말했습니다. 그러나 그것은 매우 불안하게 느껴지며, 당신의 개발 팀이 당신을 실망시키는 불쾌한 징후가 있습니다. 당신의 꿈을 이뤄줄 사람들과 교류할 때마다 당신은 평온함을 느끼지 못합니다. 더 이상 만족하지 않습니다. 그러면 이 당혹감의 이유를 어디에서 찾아야 합니까? 문제가 당신 편에 있습니까 아니면 다른 편에 있습니까? 나쁜 프로그래머가 있다면 어떻게 대처해야 합니까?

검색을 돕기 위해 귀하의 기대치를 나타내는 요점을 강조하고 귀하의 팀은 별도의 길을 가도록 노력할 것입니다. 이 기사는 나쁜 소프트웨어 회사의 궁극적인 징후가 없기 때문에 좋은 개발자와 나쁜 개발자를 비교하는 것이 아닙니다. 개발 과정에서 특히 주의해야 할 몇 가지 사항이 있습니다. 나쁜 개발자의 특성이나 나쁜 개발 회사의 징후와 같은 직접적인 진술은 제공하지 않습니다. 우리는 모든 기업가가 알아야 할 몇 가지 경고 신호에 주의를 기울일 것입니다.

1. 당신의 팀은 정해진 마감일을 체계적으로 망친다.

이 시점에서 불필요한 과장이 없다면 우리는 모두 인간입니다. 좋든 나쁘든 우리 측의 실수는 발생하는 경향이 있으며 모든 실수를 미리 피할 수는 없습니다. 한 번 놓친 기한은 긴급 상황으로 인해 설명되고 면제될 수 있습니다. 그러나 체계적으로 정해진 기한을 무시하는 것은 불합리한 자원 배분을 상징하며, 이로 인해 주요 제품 문제가 발생할 수 있는 나쁜 징조입니다.

해결책:

현대 세계에는 작업을 설정하고, 작업에 소요된 시간을 추적하고, 시간을 정확하게 추정하는 데 도움이 되는 광범위한 시간 관리 도구 목록이 있습니다. 이러한 목적을 위해 Mind Studios에서는 다음 도구를 사용합니다.
Slack - 모든 기업가, 설립자, 투자자 및 VC의 꿈입니다. Slack을 사용하면 팀 협업을 더 높은 수준으로 끌어올릴 수 있으며 작업 관리와 팀 메시징을 통합할 수 있습니다. 또한 보기 좋고 재미있고 잘 디자인되어 고객과 팀 모두 의사 소통 과정을 즐길 수 있습니다.

Redmine - 프로젝트를 생성하고, 에픽으로 분할하고, 작업을 추정하고, 각 작업에 소요된 시간을 계산할 수 있는 유연한 프로젝트 관리 웹 응용 프로그램입니다. Redmine의 유료 대안은 Jira라고 하며 더 나은 프로젝트 관리를 위해 사용될 수도 있습니다. 언급된 도구의 도움으로 마감일이 도착하기 전에 미리 알 수 있으므로 "목표일을 놓친" 기회가 크게 줄어듭니다.

2. 항상 소통이 부족하다고 느낀다.

개발 관리자가 며칠 이내에 응답합니까? 그리고 매번 무례하다고 느끼지 않습니까? 훌륭한 클라이언트-관리자 커뮤니케이션의 규칙 2번은 다음과 같습니다. 그들은 함께 일합니다. 지속적으로 그를 루프에 유지하는 것 - 이것이 숙달입니다." 그렇지 않은 경우 개발 팀이 여기에서 빠져 있는 것입니다.

해결책:

우리는 커뮤니케이션이 전체 제품의 품질만큼이나 중요하다는 것을 깨달았습니다. 이 때문에 우리는 "황금 원칙"을 따릅니다. 파트너가 원하는 것보다 조금 더 많이 파트너에게 연락합니다. 우리가 보는 대로 클라이언트-팀 커뮤니케이션에서 예정된 주간 통화 및 일일 상태 업데이트.

3. 프로젝트가 완료되면 팀의 기술 지원이 증발합니다.

"큐에서 "다음 사람"이되는 것이 지겹습니까?"

사라지는 증상은 또한 우리에게 널리 알려져 있습니다. 프로젝트가 배포되고 실행되고 시작되면 개발 팀에서 점점 더 적게 연락하는 것 같습니다. 연락을 하지 않아도 - 버그가 발생하면 팀에서 이를 처리해야 합니다. 당신은 그들과 연락을 취합니다. 그리고 며칠 동안의 침묵이 당신의 대답이거나 최대한의 신중한 "우리는 최선을 다할 것입니다"입니다. 이것은 가장 사소한 문제이지만 여전히 오래 기다려야 합니다.

해결책:

기다림이나 의무 불이행에서 보편적인 약은 없지만, 당신이 할 수 있는 최대한 - 당신과 함께 일하는 팀이 주요 작업 단계에서 100% 소비자 반응을 하도록 하십시오. 소프트웨어 개발 회사로서 우리도 때때로 사소한 프로덕션 버그에 직면하지만 몇 시간 이내에 요청에 응답하려고 노력하고 모든 불완전한 부분을 수정하기 위해 노력합니다.

4. 당신의 팀은 당신의 결과를 볼 의욕이 없습니다.

“우리는 사람들이 원하는 것을 만들지 않습니다. 우리는 사람들이 필요로 하는 것을 만듭니다” 스티브 잡스

Engagement Multiplier에 따르면 직원 참여의 중요성은 아무리 강조해도 지나치지 않습니다. "직원 참여 전략은 직원 이직률을 줄이고 생산성과 효율성을 개선하며 더 높은 비율로 고객을 유지하고 더 많은 수익을 창출하는 것으로 입증되었습니다." 마인드 스튜디오에서는 이러한 사실을 알고 있습니다. 활기차고 열정적인 개발 에이전시가 만든 프로젝트는 제작자와 매우 흡사합니다. 반대로 무관심하고 게으른 프로그래머가 이끄는 프로젝트는 최고 수준의 성과를 보일 가능성이 훨씬 적습니다.

해결책:

프로젝트에 대한 팀의 참여와 팀의 무관심 간의 차이는 쉽게 추적할 수 있습니다. 아래 질문에 대한 몇 가지 공정한 답변이 도움이 될 것입니다.
당신의 팀은 분석적 관점에서 당신의 아이디어에 도전합니까?
제품의 약점을 개선하는 데 도움이 되는 비즈니스 분석 단계를 제공합니까?
당신의 팀은 당신과 나란히 브레인스토밍을 합니까?
위의 모든 항목에 자신 있게 "예"라고 답했다면 축하합니다. 팀의 참여는 그림자 너머에 있습니다. 그러나 이러한 질문에 어떻게 답해야 할지 잘 모르겠거나 몇 가지 부정적인 점이 있다면 이는 경고 신호일 수 있습니다.

5. 버그, 미생물 및 기타 문제.

이것은 가장 명백한 저성과 지표 중 하나이지만 많은 사람들이 이를 무시하는 경향이 있습니다. 테스트할 새 빌드를 받을 때마다(Agile의 모든 데모 후) 기능에는 수정해야 할 버그가 많습니다. 이것이 단지 개발 단계일 뿐이며 출시 전에 모든 것이 다듬어질 것이라고 생각하지 마십시오. 가능성은 있지만 그렇지 않습니다. 심각한 문제의 양은 팀의 테스트 프로세스가 어떻게 든 능률화되지 않았음을 나타냅니다. 이는 출시 단계에서 나중에 더 많은 문제를 일으킬 것입니다.

해결책:

제품에서 지속적으로(스프린트별로) 버그가 발생한다는 사실을 알게 되면 팀에서 테스트 프로세스를 변경하기를 원할 수도 있고 팀을 변경하기를 원할 수도 있습니다.

Mind Studios에서는 매우 진지하게 테스트를 진행합니다. 각 스프린트 후에 몇 번의 반복을 수행하고 A/B 테스트 그룹을 실험하며 심지어 우리 제품을 QA 해커톤에 참여시켜 고객이 프로젝트를 받을 수 있도록 합니다. 구글 인증 품질. 문제가 발생하면 언제든지 기꺼이 도와드리겠습니다.

변화는 처음에는 어렵고,

중간에 지저분하고,

마지막에 멋집니다.

작가이자 리더십 연설가인 Robin Sharma

처음부터 완전히 새로운 것을 시작하는 것은 결코 쉬운 일이 아닙니다. 예를 들어 나쁜 소프트웨어 개발자를 다루는 것과 같은 함정은 어디에나 있습니다. 때때로 당신은 오해를 받거나 완전히 구식이며 실망할 수 있습니다. 여기에는 안전 보험이 없습니다. 우리는 당신이 나쁜 프로그래머와 함께 일하고 있다는 것을 증명하려고 하지 않습니다. 당신과 함께 일하는 사람들에 따라 다소 심각하게 느낄 수도 있고, 심지어 이러한 감정을 전혀 피할 수도 있습니다. 그렇다면 이제 더 큰 변화가 올 때가 되었습니까?

Dmitry Dobritsky와 Elina Bessarabova가 작성했습니다.