야생의 오란, 그리고 우리를 놀라게 한 것

릴리스 노트는 버전의 기능을 설명합니다. 다음에 무슨 일이 일어났는지 설명하는 것은 흔하지 않습니다. 그 이유 중 하나는 대답이 약간 당황스러울 때가 많기 때문입니다.

여기에 우리가 잘못한 세 가지가 있습니다.

우리는 비용 귀속이 비용에 사용될 것으로 예상했습니다.

Oran 3.1은 팀이 비용이 얼마인지 답변할 수 없었기 때문에 에이전트당 지출을 귀속시켰습니다. 그것은 정확했고 사용법은 우리가 기대했던 것과 달랐습니다.

대부분의 팀이 상담원별 어트리뷰션을 통해 가장 먼저 한 일은 지출을 줄이는 것이 아니었습니다. 아무도 모르는 요원이 활동하고 있는 것을 발견했습니다. 귀속은 재무 도구 이전에 인벤토리 도구로 판명되었습니다. 왜냐하면 인식된 소유자가 없는 비용 라인은 무언가 잊혀졌다는 가장 명확한 신호이기 때문입니다.

이는 소유권에 대한 우리의 생각을 재구성했으며, 3.6이 소유권을 관습이 아닌 대리인의 재산으로 취급하는 이유의 큰 부분입니다.

예산이 넉넉하게 책정될 것으로 예상했습니다.

우리는 팀이 폭주 행위에 대한 안전망으로 예상 사용량보다 훨씬 높은 한도를 설정할 것이라고 가정하고 3.2에서 회로 차단기 예산을 구축했습니다.

많은 사람들이 의도적으로 이를 예상 사용량에 가깝게 설정하고 블록을 보호가 아닌 신호로 사용했습니다. 에이전트가 한계에 도달하면 그것은 정보였습니다. 뭔가 변경된 것을 살펴보십시오.

우리는 가드 레일을 구축했고 팀은 이를 연기 탐지기로 사용하고 있었습니다. 작동하지만 해당 기능의 용도가 아닙니다.

배포 전에 평가가 작성될 것으로 예상했습니다.

Oran 3.3에서는 가정된 기준이 미리 정의되어 있으며, 이는 우리가 권장하는 것이며 거의 누구도 수행하지 않는 것입니다.

실제로 대부분의 팀은 에이전트가 뭔가 잘못된 것을 생성한 후 첫 번째 평가를 작성하여 실패부터 거꾸로 작업했습니다. 결과로 나온 기준은 설계된 세트보다 좁았고 종종 더 유용했습니다. 왜냐하면 상상된 실패가 아닌 실제 실패를 인코딩했기 때문입니다.

우리는 이것을 팀이 잘못하고 있는 것으로 간주하는 것을 중단했습니다. 실제 실패를 통해 성장한 세트는 좋은 것으로 수렴되며, 존재한다는 장점이 있습니다.

무엇을 보유 했습니까?

읽기-쓰기 비대칭. 팀은 우리가 작업하는 모든 부문에 걸쳐 상담원에게 광범위한 읽기 액세스 권한과 좁은 쓰기 액세스 권한을 일관되게 부여합니다. 이러한 가정을 바탕으로 정책 계층을 구축하는 것이 옳았습니다.

공유 카탈로그의 가치. 팀 간 중복은 우리가 예상한 만큼 컸으며 Agent Hub는 예상대로 이를 해결했습니다. 이는 이 목록에서 가장 놀라운 항목입니다.

우리가 미스를 게시하는 이유

제작자가 기대하는 것에만 기반하여 구축된 플랫폼은 사용자의 행동과 동떨어져 있기 때문입니다. 위의 세 가지 놀라움은 각각 3.6에서 무언가를 변경했으며 그 중 어느 것도 로드맵에서 나타나지 않았을 것입니다.

귀하의 배포가 우리가 설계하지 않은 Oran과 관련된 작업을 수행하는 경우 이에 대해 듣고 싶습니다. 그것은 정말로 우리가 받는 가장 유용한 것입니다.

다음

버전 페이지에는 Keter 1.0 이후의 모든 버전이 포함됩니다. 개방형 개발 커뮤니티는 무료로 가입할 수 있으며 관찰 내용은 contact@capconsultor.eu로 이동할 수 있습니다.