세르게예프 귀하의 바램은 명확하고 이해할 수 있으며 유일한 설명이 있습니다. 이익은 개발자 의 주요 동기이며, 이는 차례로 다음을 포함한 제품의 품질에 달려 있습니다. 최종 사용자가 SD에 쓰는 응용 프로그램을 개선합니다.
오류를 식별하거나 제안을 정의한 후에는 설명, 첨부된 스크린샷, 요청 등 형식화 하는 데 시간을 할애합니다. 답은 침묵이다. 한 달, 둘, 셋. 포럼에서 발생한 사건을 상기시키기 위해 공식 '무상 지원' 답변을 받았습니다 . "신청이 승인되었지만 이제 더 중요한 작업이 있으므로 한 달 후에 다시 제출하겠습니다" 등의 스타일로 대답할 수 있습니까? 그것은 수. 그러나 선택한 스타일은 단호하게 무시했습니다. 그런 오만한 대답이 내가 SD에서 더 협력하도록 동기를 부여한다고 생각합니까? 여기 나도 똑같다.
이것은 문제의 윤리적 측면입니다. 두 번째 측면은 회사에 최소한 최종 사용자에 대한 ITIL/SLA가 없다는 것입니다. SD에 대한 모든 지원은 마감일 과 함께 분류되어야 합니다. 클라이언트(DC)의 경우 이것은 확실히 계약 수준에 있어야 합니다. 최종 사용자는 지금까지 무시된 것 같습니다.
오류를 식별하거나 제안을 정의한 후에는 설명, 첨부된 스크린샷, 요청 등 형식화 하는 데 시간을 할애합니다. 답은 침묵이다. 한 달, 둘, 셋. 포럼에서 발생한 사건을 상기시키기 위해 공식 '무상 지원' 답변을 받았습니다 .
당신의 분노는 분명하지만, 우리(당신의 SD에 접근할 수 없는 포럼의 일반 회원)가 당신의 신청서를 판단하는 것은 어렵습니다. 그녀는 "무엇에 대해" 또는 "아무것도 아닌" ... 당신과 SD 외에는 아무도 그녀를 본 적이 없습니다. 따라서 응용 프로그램에 대한 이러한 반응에 대해 개발자를 비난할 필요는 없으며 일방적으로 나타납니다. 그리고 우리를 위한 문제의 본질 없이.
예, 많은 응용 프로그램에 따르면 여전히 침묵이 있습니다. 최소한 수백 가지가 있으며 몇 가지 중요한 문제에 많은 시간을 할애할 수 있습니다.
당신의 침묵입니까?
당신의 침묵입니까?
#715107 | 2013.04.11 22:41
대답할 무언가...
계속 돈을 잃는다? 끄다? 아니면 곧 고쳐질까요?
#685594 - 현재 빌드에서 이미 수정됨(22. MetaTester: 다중 통화 Expert Advisors 의 시각적 테스트 중 기본 차트 표시 수정.)
#681251 - "아니오"라고 말했습니다. 응용 프로그램을 다시 여는 이유
#677530 - 아무것도 신청하지 않음
#677524 - 그들은 당신에게 "특이점이 있습니까? 현재로서는 당신이 묘사 한 행동을 재현하는 것이 불가능합니다. 지금까지는 모든 것이 목발없이 작동합니다."라고 대답했습니다.
#666445 - 아무것도 신청하지 않음
#644298 - 설명 된 동작은 항상 쿼드 MetaEditor에 존재했습니다. 그리고 우리는 이미 여러 번 대답했습니다. "이 행동을 처리하십시오. 우리는 이곳에서 아무 것도 바꾸지 않을 것입니다. 중요한 기관을 다치게하지 않도록"
#685594 - 그렇다면 포럼(TeamWox 시스템 외부)에서 사건에 대한 피드백을 구해야 하는 이유는 무엇입니까?
#681251 - 서신을 다시 읽으십시오. 조심해. 거기에 "아니오"라는 단어나 힌트가 있습니까? 글쎄, 그들이 지금 대답하는 것이 좋습니다.
#677530 - MQL5 문서의 품질이 당신에게 "아무것도" 없다는 것은 슬픈 일입니다.
#677524 - 서신을 다시 읽으십시오. 조심해. 분명히 대답을 한 사람은 복사하여 붙여넣기에 너무 게으른 것입니다.
#666445 - ChartRedraw () 기능이 오프라인에서 "아무것도" 작동하지 않습니까? 확인. 따라서 더 많은 사람들에게 대답하십시오. "당신의 제안은 아무것도 아닙니다. 우리는 당신에게 대답하지 않을 것입니다."
#644298 - 이것이 서비스 데스크에서 침묵의 이유입니까?
버그 추적 시스템의 피드백에 대한 이러한 접근 방식은 비전문적입니다. 그리고 그것의 무상함을 감안할 때, 그것은 의욕을 떨어뜨립니다.
버그 추적 시스템의 피드백에 대한 이러한 접근 방식은 비전문적입니다. 그리고 그것의 무상함을 감안할 때, 그것은 의욕을 떨어뜨립니다.
서비스 데스크 에 연락하는 올바른 방법 :
- 문제가 발생하여 이러한 상황에서 재현하여 스크린샷(코멘트 코드, 상세 로그)을 첨부합니다. 가능한 원인(목록).
- 개선을 위한 제안이 있습니다. 지금은 이렇지만(코드, 스크린샷) 저는 이렇게 제안합니다(코드, 스크린샷).
잘못된 서비스 호출
- 문제가 있습니다. 그것에 대해 이야기하고 싶습니다. 정보를 구합니다.
- 제안이 있지만 개발자로서의 귀하의 의견은 저에게 관심이 없습니다. 제가 말한대로 되었으면 합니다.
기억하다:
- 서비스 데스크에 대한 잘못된 호출은 개발자의 의욕을 떨어뜨 립니다.
세르게예프
내가 SD에 호소하는 디자인을 보거나 읽었습니까?
세르게예프
내가 SD에 호소하는 디자인을 보거나 읽었습니까?
내 게시물을 자신에게 가져가지 마십시오. 또는 내가 본 적이 없으며 여기에 포럼에 쓰지 않은 귀하의 응용 프로그램.
모든 지원자의 바램입니다.
세르게예프
귀하의 바램은 명확하고 이해할 수 있으며 유일한 설명이 있습니다. 이익은 개발자 의 주요 동기이며, 이는 차례로 다음을 포함한 제품의 품질에 달려 있습니다. 최종 사용자가 SD에 쓰는 응용 프로그램을 개선합니다.
오류를 식별하거나 제안을 정의한 후에는 설명, 첨부된 스크린샷, 요청 등 형식화 하는 데 시간을 할애합니다. 답은 침묵이다. 한 달, 둘, 셋. 포럼에서 발생한 사건을 상기시키기 위해 공식 '무상 지원' 답변을 받았습니다 . "신청이 승인되었지만 이제 더 중요한 작업이 있으므로 한 달 후에 다시 제출하겠습니다" 등의 스타일로 대답할 수 있습니까? 그것은 수. 그러나 선택한 스타일은 단호하게 무시했습니다.
그런 오만한 대답이 내가 SD에서 더 협력하도록 동기를 부여한다고 생각합니까? 여기 나도 똑같다.
이것은 문제의 윤리적 측면입니다. 두 번째 측면은 회사에 최소한 최종 사용자에 대한 ITIL/SLA가 없다는 것입니다. SD에 대한 모든 지원은 마감일 과 함께 분류되어야 합니다. 클라이언트(DC)의 경우 이것은 확실히 계약 수준에 있어야 합니다. 최종 사용자는 지금까지 무시된 것 같습니다.
voix_kas :
오류를 식별하거나 제안을 정의한 후에는 설명, 첨부된 스크린샷, 요청 등 형식화 하는 데 시간을 할애합니다. 답은 침묵이다. 한 달, 둘, 셋. 포럼에서 발생한 사건을 상기시키기 위해 공식 '무상 지원' 답변을 받았습니다 .
당신의 분노는 분명하지만, 우리(당신의 SD에 접근할 수 없는 포럼의 일반 회원)가 당신의 신청서를 판단하는 것은 어렵습니다. 그녀는 "무엇에 대해" 또는 "아무것도 아닌" ... 당신과 SD 외에는 아무도 그녀를 본 적이 없습니다.
따라서 응용 프로그램에 대한 이러한 반응에 대해 개발자를 비난할 필요는 없으며 일방적으로 나타납니다. 그리고 우리를 위한 문제의 본질 없이.
그런데,
- 내 의견으로는 논리적이지만 연기된 SD(제안)의 논쟁의 여지가 있는 응용 프로그램에 대해 기능이 필요하다는 것을 보여주기 위해 사용자 설문 조사를 수행했습니다.
- 그리고 SD에서 한 번 거부된 응용 프로그램의 경우 - 잠시 후 개발자에 의해 구현되었습니다. 기능성의 시대가 도래했다고 생각했을 때. ( 예를 들어 )
추신.
저는 SD에 160개 이상의 이의를 제기했습니다. 그래서 나는 경험에서 말하는 것입니다 :)