우리 엔지니어들이 고객과 함께 앉아 있는 이유와 고객이 할 수 없는 일

모든 플랫폼 회사는 결국 이것의 일부 버전을 제공합니다. 엔지니어는 일정 기간 동안 고객과 협력하며 다른 경우보다 더 빠르게 무언가를 구축합니다.

문제는 엔지니어가 떠날 때 고객이 어떤 상태에 있는지이며 이는 전적으로 엔지니어가 무엇을 위해 최적화했는지에 달려 있습니다.

실패 모드

엔지니어가 물건을 만듭니다. 작동하고 고객은 만족하며 작동 방식에 대한 지식은 엔지니어에게 남습니다.

6개월 후 상담원을 변경해야 하고 내부적으로 평가 기준을 이해하는 사람이 아무도 없으며 고객은 자체 시스템을 수정하기 위해 지원 티켓을 엽니다. 그것은 의존성이며 꽤 오랫동안 성공적인 참여로 위장될 수 있습니다.

또한 단기적으로는 상업적으로 유혹적이기 때문에 누구도 결정하지 못한 채 자주 발생합니다.

우리가 실제로 무엇을 하러 거기 있는 걸까요?

에이전트 작업을 효과적으로 수행하는 네 가지 사항을 함께 수행하기보다는 함께 수행하여 가르칩니다.

무엇을 먼저 자동화할지 결정하는 방법은 일반적으로 고객의 본능보다 좁은 선택입니다.

자신의 작업에 대한 평가 기준을 작성하는 방법, 이는 가장 멀리 전달되고 아무도 도달하지 못하는 기술입니다.

두 번째 에이전트가 첫 번째 에이전트의 실수를 반복하지 않도록 비용과 소유권을 계측하는 방법입니다.

프롬프트에서 설명하는 대신 경계를 설정하고 실행 시점에 적용하는 방법입니다.

이 네 가지를 잘 수행하면 첫 번째 에이전트는 배송 속도가 느려지고 다섯 번째 에이전트는 전적으로 그들의 것입니다.

우리가 사용하는 척도

상담원이 전달되지 않았습니다. 고객이 우리 없이 다음 제품을 구축했는지 여부.

이는 성공적인 약혼을 끝내기 때문에 의도적으로 어색한 조치입니다. 우리는 그것이 옳다고 생각하며 우리와 협력하는 공급업체에 적용할 테스트입니다.

엔지니어가 배우는 것

이는 양방향으로 적용되며 예의가 아닙니다. 플랫폼에서 우리가 변경한 거의 모든 것은 팀이 우리가 예상하지 못한 성과를 거두는 것을 지켜본 것에서 비롯되었습니다.

에이전트별 속성은 비용 도구가 아닌 인벤토리 도구로 사용됩니다. 예산은 엄격하게 설정되어 신호로 사용됩니다. 평가 기준은 미리 설계한 것이 아니라 실패부터 역방향으로 작성했습니다. 그 중 어느 것도 로드맵에서 나온 것이 아닙니다. 그들은 누군가 옆에 앉아 있는 것에서 왔습니다.

우리가 거절할 것

우리가 건설해서는 안 된다고 생각하는 것을 건설하는 것입니다. 잘못되면 비용이 많이 들고 검토 단계가 없는 결정 경로에 있는 상담원은 범위 문제가 아니라 설계 이의제기이므로 전달하기보다는 제기하는 것이 좋습니다.

우리는 또한 고객 에이전트의 지속적인 소유자가 되는 것을 거부합니다. 에이전트에는 에이전트에 의존하는 조직 내부의 명명된 소유자가 필요합니다.

우리와 협력하는 방법

참여에는 제한이 있으며 목표는 시작 시 명시됩니다. 귀하의 팀은 우리 없이 이를 실행합니다. 일반적인 제안이 아닌 특정 프로그램에 대해 이야기하고 싶다면 데모를 예약하고 제약 조건을 가져오세요.

다음

에이전트 오케스트레이션 시스템 페이지는 이 작업의 기반이 되는 계층을 다룹니다. 경력은 이러한 역할이 내부에서 어떻게 보이는지 다룹니다.