기술 사양에 따라 작업을 수행하십시오. 기술명세서는 어떻게 작성하나요?! 시스템 구축의 목적과 목표

참조 용어 "TOR"은 모든 프로젝트 개발의 기초로 사용되는 문서입니다. 그리고 작업이 아무리 복잡하거나 크더라도 항상 명확하고 이해하기 쉬운 기술 사양이 수반되어야 합니다. 우선, 고객이 보고 싶었던 것을 정확히 얻으려면 이것이 필요합니다. 그러나 연기자는 자신이 원하는 것이 무엇인지 이해하기 위해 항상 명확하게 명시된 작업을 요구하는 것이 좋습니다. 많은 사람들이 상세한 기술 사양을 작성한다는 사실을 무시하며, 이로 인해 오해, 분쟁, 갈등 및 다툼이 발생합니다.

다음 내용을 읽어 보시기 바랍니다:

이 기사의 저자인 나는 평생 동안 수만 달러에 달하는 여러 대규모 프로젝트의 고객이자 덜 비싼 주문의 실행자였습니다. 심각한 수준에 도달하기 전에 저는 수백 개의 "기술 사양"을 다시 읽고 수행자에 대한 수십 개의 설명을 직접 작성해야 했습니다. 매번 기술 사양이 점점 더 명확해졌고, 덕분에 내가 상상했던 대로 작품의 최종 버전을 얻을 수 있게 됐다. 이번 글에서는 글쓰기 방법에 대해 이야기하고 싶습니다. 참조 조건, 먼저주의해야 할 사항. 또한 고객과 계약자가 좋은 단어로 작업하지 않고 모든 것을 문서화하는 것이 바람직한 이유도 알려 드리겠습니다.

고객에게 기술 사양이 필요한 이유는 무엇입니까?

귀하는 고객으로서 주문의 최종 버전에 대한 아이디어를 가지고 있습니다. 인생만이 사람마다 같은 말을 다르게 해석할 수 있는 그런 것이다. 이로 인해 특히 고객과 공연자 사이에서 문제가 자주 발생합니다. 첫 번째는 모든 것을 설명하지 못했고, 두 번째는 제대로 이해하지 못했고, 결과는 모두가 생각했던 것과 전혀 달랐습니다. 기술 사양은 수행된 작업을 수락하는 데 기준이 되는 문서입니다. 그리고 뭔가 잘못되면 뭔가가 완료되지 않고 뭔가가 제대로 이루어지지 않은 것입니다. 전체적으로, 그러면 언제든지 기술 사양의 요점을 지적하고 제출된 프로젝트를 마무리하기 위한 주장을 정당화할 수 있습니다. 기술 사양이 없으면 귀하가 말하고, 쓰고, 언급했음을 증명하는 것이 사실상 불가능합니다. 기술 사양은 일종의 서비스 계약의 프로토타입이라고 말할 수 있습니다. 대규모 프로젝트를 진행하는 경우 참조 조건이 주 계약에 추가되어야 합니다. 완성된 작품에 대한 승인 증명서에 서명할 때 원본 작업 명세서에 표시된 작업량과 모든 것을 비교해야 합니다.

다음 내용을 읽어 보시기 바랍니다:

공연자에게 기술 사양이 필요한 이유는 무엇입니까?

우선, 이것은 무엇을 해야 하는지에 대한 지침입니다. 종종 고객은 개발 과정에서 불필요한 작업을 수행하도록 강요하는 무언가를 생각해냅니다. 무료로 일하고 싶나요? 나는 그렇지 않을 것이라고 확신합니다. 처음에 합의된 금액은 오로지 위임 사항에 명시된 작업 범위에만 해당된다는 점을 분명히 하십시오. 그 이상의 금액은 별도로 지불됩니다. 또한, 프로젝트가 인도되면 할당된 작업과 구현에 대해 보고할 수 있습니다. 고객이 작업이 완전히 완료되지 않았다고 주장하면서 작업을 수락하고 싶지 않은 순간을 여러 번 경험했습니다. 그러나 초기 기술 사양이 제기되었을 때 아무도 문제의 작업을 설정하지 않은 것으로 나타났습니다. 다시 한 번 강조합니다. 기술 사양 없이는 작업하지 마십시오. 고객의 의견은 날씨보다 더 자주 바뀔 수 있으며 모든 것을 수십 번 다시 실행해야 하고 시간을 낭비하며 추가 비용을 받지 못하기 때문입니다.

유능한 기술 사양 작성을 시작하는 곳

그럼 다음으로 넘어 갑시다 주요 주제이 기사. 다음으로 기술 사양을 작성하는 방법과 반드시 주의해야 할 사항에 대해 이야기하겠습니다. 아시다시피 각 TK는 고유하며 모든 측면을 다룰 수는 없습니다. 따라서 프로젝트와 고객의 활동 분야에 관계없이 어떤 작업에서나 있어야 할 주요 사항만 지적하겠습니다.

기술 사양의 일반 조항

기술적으로 복잡한 프로젝트나 매우 구체적인 프로젝트가 있는 경우 다음을 확인하세요. 일반 조항용어집, 즉 용어 및 정의 사전이 있어야 합니다. 물론, 고객과 계약자가 서로를 이해하고 특정 용어를 문제 없이 이해한다면 매우 좋습니다. 그러나 항상 그런 것은 아니므로 특정 단어, 문구, 명칭이 의미하는 바를 적어 두는 것이 좋습니다. 용어집에서 일부 문구를 설명하는 것이 좋습니다. 특정 문구를 사용하여 조금 다르게 해석한다고 가정해 보겠습니다. 혼란을 피하려면 즉시 모든 것을 제자리에 두십시오.

다음 내용을 읽어 보시기 바랍니다:

약관에 대한 이해 부족으로 인해 한 달 넘게 마감 기한을 놓친 사례가 있었습니다. 그 결과 고객은 일정한 손실을 입었지만 문제는 전적으로 고객 측에 있었습니다. 그러므로 불일치를 허용하지 마십시오. 프로젝트를 시작하기 전에 용어를 결정하십시오.

프로젝트 목표

참조 조건에는 프로젝트의 목표가 무엇인지, 프로젝트가 생성되는 이유, 작동 방식 및 최종 결과가 무엇인지 나타내는 것이 중요합니다. 계약자가 프로젝트의 작은 부분을 작업하더라도 해당 프로젝트의 구조, 작업, 목표 및 기술 솔루션을 완전히 이해해야 합니다. 무엇을 위해? 계약자가 항상 고객으로부터 조언과 설명을 받을 수 있는 것은 아니며, 목표를 향해 가고, 프로젝트의 목적을 이해하고, 업무를 기반으로 수행할 수 있다면 작은 것들에 대한 해석을 요구할 필요가 없습니다. 이것에.

예를 들어 보겠습니다. 우리는 최근 대규모 인터넷 프로젝트를 개발하고 디자인을 주문했습니다. 디자이너는 사이트가 무엇에 관한 것인지, 어떤 기능을 갖게 될 것인지, 무엇을 해야 하는지, 그리고 사이트가 사람들에게 어떻게 도움이 될 것인지에 대해 들었습니다. 일반적으로 그들은 디자인에 관한 것뿐만 아니라 모든 것을 가장 작은 세부 사항까지 씹었습니다. 그 결과, 우리는 사실상 수정이 필요하지 않은 레이아웃뿐만 아니라 사이트를 개선하는 방법, 추가할 내용, 사이트를 더욱 매력적으로 만드는 방법에 대한 12가지 아이디어를 받았습니다.

기능적 요구 사항

모든 고객 요구 사항은 기능적 요구 사항과 특별 요구 사항의 두 가지 유형으로 나눌 수 있습니다. 기능적 요구 사항은 제품에서 확인하려는 구현 옵션입니다. 인터넷 사이트의 예를 사용하는 경우 귀하는 귀하가 좋아하고 귀하의 프로젝트에서 보고 싶은 다른 프로젝트의 기능적 솔루션의 예를 계약자에게 제공해야 합니다. 예를 들어, 기술적으로 마음에 드는 요소를 보고 설명하면 즉시 링크를 제공하여 사람이 그 내용을 명확하게 이해하고 기초로 삼을 수 있도록 했습니다.

다음 내용을 읽어 보시기 바랍니다:

특별 요구사항은 할당된 작업을 충족해야 하는 요구사항입니다. 웹사이트 개발을 다시 기본으로 삼는다면 프로그래밍 언어, 특수 레이아웃 매개변수, 인코딩, 특정 스타일의 사용 및 보고 싶은 모든 것을 지정할 수 있습니다. 그러한 요구 사항이 없으면 계약자가 기술 사양을 수행할 때 무엇을 어떻게 사용할 것인지 독립적으로 결정하도록 하십시오.

마감일

완료 기한은 참조 조건에 명시되어야 합니다. 실행 속도가 품질에 영향을 미치지 않도록 항상 작은 여유를 가지고 가져 가십시오. 어떠한 경우에도 명확한 기한이 있어야 하며, 기한을 지키지 못한 경우의 제재 조치가 설명되어 있습니다. 계약자는 이것이 단지 참조 사항의 요점이 아니라 실제 설치라는 점을 이해해야 하며, 완료되지 않으면 재정적 또는 기타 제재를 받을 위험이 있습니다.

보고

프로젝트 규모가 크고 완료하는 데 몇 달이 걸릴 경우 작업을 여러 단계로 나누고 각 단계에 대해 명확한 기간을 설정하세요. 특정 단계를 완료한 후 완료된 작업에 대한 보고를 요구합니다. 이렇게 하면 연기자의 몸매가 좋아져서 몇 달 동안 선불금을 먹고 마시며 돌아다니다가 일주일 안에 엄청난 속도로 모든 일을 하는 일이 없게 됩니다.

또한 실제 수행된 작업에 대한 보고서도 있어야 합니다. 수행된 작업, 소요된 시간, 수행자가 직면한 어려움 등

책임

계약서를 작성하면 책임에 관한 조항이 포함됩니다. 기술 사양으로만 제한되는 경우 마감일을 놓치고 프로젝트를 제공하지 않고 작업의 뉘앙스를 제3자에게 공개하여 손실을 초래하는 책임이 계약자에게 있다는 점을 설명하는 것이 좋습니다. 어느 것? 첫째, 법률에 따라 벌금과 제재를 스스로 설정할 수도 있습니다.

다음 내용을 읽어 보시기 바랍니다:

그리고 이 글의 마지막 부분에서는 기술 과제를 작성하고 받은 경험을 바탕으로 몇 가지 조언을 드리고 싶습니다.

기술 사양이 상세해야 합니다. 모든 요소, 모든 항목, 모든 버튼을 설명하는 것을 두려워하지 마십시오. 모든 것을 가능한 한 자세히 작성하십시오. 세심한 것처럼 보이는 것을 두려워하지 마십시오. 나중에 끝내고 추가 비용을 지불하고 수정하는 것보다 여러 번 반복하고 씹어 보는 것이 좋습니다. 내가 작성한 마지막 기술 작업은 웹 사이트 개발에 관한 것입니다. 대규모 정보 프로젝트였습니다. 먼저 우리는 디자인을 개발한 다음 이를 기반으로 프로그래머를 위한 기능적 작업을 설명했습니다. 그래서 모든 사양이 A4 11글꼴 54페이지로 밝혀졌습니다. 참조 조건은 7페이지 길이의 주 계약서에 추가로 제공되었습니다. 하지만 개발 과정에서 세 가지가 더 서명되었기 때문에 그렇게 상세한 기술 사양에서도 모든 것을 고려할 수는 없었다고 말하고 싶습니다. 추가 계약, 이를 통해 과제의 원래 버전을 일부 조정했습니다.
기술 사양이 명확해야 합니다. 물이 필요하지 않습니다. 모든 것이 요점입니다. 마감일에 대해 작성하는 경우 특정 수치, 기능에 관한 경우 필요한 기능적 솔루션 목록 등을 작성합니다.
귀하의 기술 사양은 교리가 아니라 다음 중 하나일 뿐입니다. 가능한 옵션작업 실행. 솔직히 말해서 저는 프로그래밍 전문가는 아닙니다. 예, 프로젝트의 구조, 기능, 일부 기술 솔루션을 생각할 수 있지만 항상 기술 사양의 최종 버전을 작성할 때 수행자와 협의합니다. 그들은 무언가를 보고, 자신의 의견을 표현하고, 조언을 줄 수 있습니다. 최적의 솔루션실행.

아마도 이것이 제가 이 기사에서 말하고 싶었던 전부일 것입니다. 기술 사양을 작성하는 것은 계약자에게 원하는 것이 무엇인지 명확하게 이해하면 그리 어렵지 않습니다. 내 조언을 다시 읽고 특정 사례에 적용할 수 있습니다. 행운을 빌어요!

기술 사양은 계약자에 대한 고객의 요구 사항을 설명하는 주요 문서입니다. 그것은 설명한다 전체 설명프로젝트, 목표, 특성, 초기 데이터, 마감일, 결과 요구 사항. 기술 사양 (기술 사양)의 존재는 필수는 아니지만 대부분의 경우 고객과 계약자 사이에 문제와 오해가 발생하여 납품 기한이 지속적으로 지연되고 프로젝트 비용이 증가하며 기타 예상치 못한 비용이 발생합니다. 때로는 지속적인 개선과 편집에 몇 달을 허비하는 것보다 며칠 동안 기술 사양을 개발하는 것이 더 수익성이 있을 때도 있습니다.

이 기사에서는 제품 개발을 목적으로 하는 기술적 작업에 대해 설명합니다. 그러나 일반적인 경우에는 자료가 유용할 수 있습니다.

누가 참조 조건을 작성해야합니까?

때로는 기술 사양을 수행자가 직접 작성해야한다는 의견을 듣습니다. 그러한 오해가 어디서 유래했는지는 확실하지 않지만, 그 작성자는 개발 과정을 이해하는 데 거리가 먼 사람이었습니다. 이 의견을 갖고 있는 사람들은 질문을 해야 합니다. "결국 무슨 일이 일어날지 모른다면 개발자를 어떻게 찾고 그에게 어떤 요구 사항을 제시합니까?".

누가 뭐라고 하든 기술 사양은 고객이 작성해야 하며, 제품 개발의 모든 단계를 알고, 수행자 선택을 전문으로 하고, 이 제공에 대한 실제 시장 가격을 알고 있는 고용된 프로젝트 관리 관리자(프로젝트 관리자)가 작성해야 합니다. 해당 유형의 서비스를 제공하고 개발 기간을 현실적으로 평가할 수 있습니다. 대부분의 경우 프로젝트 규모가 작고 프로젝트 관리자를 고용하는 것이 상업적으로 수익성이 없기 때문에 고객이 직접 기술 사양을 작성하거나 기술을 어느 정도 이해하고 계약자를 찾아 문서 준비에 도움을 요청합니다.

기술 사양의 구조

명확하게 표시된 모든 것 일반 규칙참조 조건에는 존재하지 않습니다. 일반적으로 각 회사는 자체 활동에 더 적합하고 편리하고 적합한 자체 구조를 만듭니다. 그러나 무언의 권장 사항이 있습니다.

TOR 문서의 구조:

목차
변경 내역
술어
일반 정보프로젝트에 대해 (프로젝트의 목적, 목표 및 목표)
프로젝트 요구사항(기능, 사용자, 일반 및 기타 요구사항)
담보 유형에 대한 요구 사항
문서 요구 사항
개발 단계 및 단계
프로젝트 통제 및 승인 절차
추가 자료

구조의 각 지점을 자세히 살펴 보겠습니다.

이름에서 알 수 있듯이 기술 사양의 모든 부분을 나열한 목록입니다.

2. 변경 내역

이 단락에는 초기 버전에서 문서에 영향을 준 모든 변경 사항이 포함되어 있습니다.

3. 용어

프로젝트 설명에 사용된 비표준 용어를 모두 설명합니다.

4. 프로젝트에 대한 일반 정보

프로젝트와 그 목적에 대한 일반적인 정보를 설명합니다. 프로젝트를 통해 달성해야 하는 목표와 목적.

5. 프로젝트 요구사항

가장 방대하고 참조 측면에서 주요 요점 중 하나입니다. 다음과 같은 프로젝트의 모든 요구 사항을 절대적으로 설명합니다.

프로젝트 기능에 대한 요구 사항;
신뢰성 요구사항;
임원에 대한 요구 사항;
특허 순도 요건;
표준화 요구사항;
기밀 유지 요구 사항;
안전 요구 사항;
그리고 다른...

6. 담보 유형에 대한 요건

이 섹션에서는 기술, 소프트웨어, 언어, 수학 등 필요한 모든 유형의 소프트웨어에 대한 요구 사항을 설명합니다.

7. 문서 요구 사항

프로젝트 고객에게 제공해야 하는 문서 목록입니다. 최소 패키지에는 다음이 포함되어야 합니다.

사용자 설명서;
관리자 안내서;
수행된 테스트에 대한 데이터
완료된 작업의 행위.

8. 개발 단계 및 단계

이 섹션에서는 개발의 모든 단계, 각 단계를 완료하기 위한 기간 및 최종 결과를 자세히 설명해야 합니다.

9. 프로젝트 관리 및 승인 절차

이 섹션에서는 프로젝트 및 테스트 시스템을 수락하는 절차를 설명합니다.

10. 추가 자료

추가 자료에는 다음이 포함될 수 있습니다. 다양한 종류개발 과정에서 사용할 수 있는 문서입니다. 이는 연주자에게 유용할 수 있는 리소스 및 자료에 대한 링크일 수 있습니다.

기술 사양을 개발하는 과정에서 위의 모든 사항은 필수 사항은 아니며 단지 예시로만 제공됩니다. 각 프로젝트는 어느 정도 독특하며 요구 사항이 있을 수 있습니다. 추가 서류, 그러면 섹션 목록이 확장되거나 반대로 단순해지고 각 섹션을 설명하는 것이 비현실적입니다. 하지만 어쨌든, 각 기술 사양에는 기능 요구 사항 설명, 문서 요구 사항 및 프로젝트 승인 절차 등 최소 3개 섹션이 포함되어야 합니다. .

가능한 한 그래픽 자료를 사용하는 것이 좋습니다. 하나의 다이어그램이나 다이어그램이 여러 페이지의 텍스트를 대체할 수 있는 경우가 종종 있습니다.
모호하고 모호한 설명을 사용하지 마십시오. 모든 것이 명확하고 이해하기 쉽게 설명되어야 합니다.
프로젝트 설명은 논리적으로 일관성이 있어야 하며 모순이 없어야 합니다.
언뜻보기에는 터무니없는 것처럼 보일지라도 모든 데이터와 요구 사항을 절대적으로 표시해야합니다. 이러한 데이터는 등록 양식의 필드, 기사의 날짜 형식 등이 될 수 있습니다.
마감일을 지정할 때 개발의 필수적인 부분은 테스트와 버그 수정이라는 점을 고려해야 합니다. 단기투자하지 않을 수도 있습니다.
계약자를 선택한 후에는 참조 조건을 함께 검토해야 하며 새로운 질문이나 추가 사항이 나타날 수 있습니다.

기술 사양은 구매가 수행되는 조건 목록과 수행할 작업을 정의하는 조달 품목에 대한 고객의 주요 요구 사항을 포함하는 전문 문서로 이해됩니다. 법이 규정하지 않음에도 불구하고 필수 준비작업 및 기타 서비스 수행에 대한 참조 조건은 참조 조건 덕분에 노동력 및 시간 자원이 다음 단계에서 절약되기 때문에 이러한 형태의 문서가 널리 퍼져 있습니다.

기획단계;
다가오는 조달, 통지, 프로젝트 계약에 대한 최종 문서 작성
계약 조건을 직접 실행하는 단계.

구매 계획 통지를 게시하기 전에 기술 사양(이하 TOR)을 작성하면 작업을 완료하거나 상품을 제공하고 자격을 갖춘 전문가를 선택하는 데 필요한 시간을 최적으로 계산할 수 있습니다. 또한 적절하게 작성된 기술 사양을 통해 조달 대상 자체를 최대한 지정하고 최대한 명확하고 자세하게 설명할 수 있습니다. 이전에 준비된 기술 사양을 기반으로 조달 결과가 원래 명시된 특성과 일치하는지 최종 평가가 수행됩니다.

에 포함된 정보를 바탕으로 이 문서, 다음이 가능해집니다.

조달 계획 및 프로젝트의 수립
가능한 초기 및 최대 계약 비용을 결정합니다.
조달 통지서 작성
계약 조건 이행을 위한 일정 수립
초안 계약을 포함한 기본 문서 준비
조달에 참여하고자 하는 사람들로부터 받은 제안에 대한 평가
계약 체결 및 이행 모니터링.

양식을 만드는 방법

원칙적으로 참조 조건은 계약 관리자가 전문가와 협력하여 작성합니다. 법무 부서, 그 후 조달과 관련된 결정을 내릴 권한이 있는 사람이 문서를 인증합니다. 통지 및 기타 관련 조달 문서가 생성되기 10일 이내에 문서에 서명하는 것이 좋습니다.

참조 조건은 다음과 같습니다.
계획된 구매에 대한 기본 정보
조달 대상에 관한 일반 정보
공연자 요구 사항
계약을 체결할 때 준수해야 할 조건은 무엇입니까?

주의하세요! 기술 사양을 준비할 때는 모순이 없는 명확하고 간결한 공식을 사용하여 객관성을 바탕으로 해야 합니다. 기술 사양의 요구 사항은 법률 규범에 모순되지 않고 확립된 관행에 따라 구성되어야 합니다.

기술 사양을 작성할 때 기술 사양에 따라 공급자와 수행자의 위험과 부담이 고객이 가정하는 수준을 초과해서는 안 된다는 점을 고려해야 합니다. 그렇지 않으면이로 인해 계약 비용이 증가하거나 참가 신청서 제출이 거부될 수 있습니다.

건설 및 설치 작업용

건설 및 설치 작업에 대한 위임 사항에는 필요한 작업을 수행하는 데 필요한 기준이 포함되어야 합니다. 문서를 작성할 때 다음 사항을 표시해야 합니다.

경매 객체 자체. 향후 계약에 따라 어떤 종류의 작업을 수행해야 합니까?
위치 주소. 건설 및 설치 작업이 필요한 대상의 정확한 위치
근무 조건. 이 단락에는 일반적으로 토양의 특성, 공학적 및 지질 학적 특성, 예를 들어 지하수 깊이 수준 및 향후 건설 중에 중요한 기타 특성이 나열됩니다.
건설 및 설치 작업의 성격이 표시됩니다. 즉, 새로운 건설이 될지 아니면 이미 건설된 시설에서 작업이 수행될지 여부입니다.
예를 들어 연속적으로 구현하는 방법;
다음 단락에는 설계 견적의 가용성과 이를 편집한 사람에 대한 정보가 포함되어 있습니다.
건설현장의 기술적, 경제적 특성
다음 단락에서는 회계, 모든 단계의 건설 진행 상황 모니터링, 작업 조직, 건설 및 설치 작업 수행 허가 제공 등 건설 및 설치 작업 고객이 수행하는 기능을 설명합니다.
계약자가 수행할 작업 목록이 있는 계약자에 대한 요구 사항
단계별 배분에 따른 공사의 단계와 일정 물량의 완성 기한
예를 들어 GOST 및 현재 SNiP의 요구 사항에 따라 수행되는 작업을 준수해야 할 필요성과 같은 조직 요구 사항
마지막 지점은 건설 및 설치 작업이 완전히 완료되어야 하는 기간을 나타냅니다.

전기설치공사의 경우

전기 설치 작업에 대한 기술 사양을 작성할 때 이전 예와 동일한 원칙이 적용됩니다. 항목별로 다음 정보가 표시됩니다.

근무지
완료 마감일
주어진 간략한 설명필수 작업;
수행자 요구 사항.

중요한! 세부 사항으로 인해 개별 종특히 다음을 포함하는 작품 전기 설치 작업, 경매 참가자에 대한 표준 요구 사항과 함께 고객은 기술 사양에 특별한 조건을 제시할 수 있습니다.

따라서 이는 입학에 관한 정보를 제공하기 위한 요구 사항일 수 있습니다. 특정 유형작업, 구현을 위한 기술 자원의 가용성, 경매 참여를 신청하는 참가자의 근로자 자격 수준 확인 제공.

44-FZ에서 작업을 수행하려면

요구 사항에 따라 연방법 No. 44-FZ, 고객은 실제 계약 이행 방법에 관계없이 문서를 준비할 때 조달 대상 설명과 관련된 통일된 요구 사항을 안내받아야 합니다. 기술 사양을 준비할 때 고객은 다음 지침을 따라야 합니다.

경매 대상을 설명할 때 객관성 기준에 중점을 두어야 합니다.
필요한 경우 조달 대상의 기능, 기술 및 운영 특성이 설명에 포함되어야 합니다.
위임사항은 본질적으로 중립적이어야 하며 잠재적 참가자 수를 제한하기 위해 과도한 요구 사항을 너무 많이 포함하지 않아야 합니다.

고객은 연방법 No. 44-FZ "On"의 조항을 준수해야 합니다. 계약 시스템상품, 작업, 서비스 조달 분야에서 "요구 사항에 따라 계약자 또는 공급 업체의 선택이 엄격한 규칙에 따라 수행됩니다. 전자 경매, 일반적으로 가장 낮은 가격을 제시한 참가자가 승자가 됩니다. 따라서 조달의 모든 미묘한 차이를 고려한 올바른 기술 사양을 준비하는 것이 매우 중요합니다.

많은 회사는 기술 사양 작성 단계에서 계약자를 참여시킬 준비가 되어 있지 않습니다. 각 계약자가 자신의 직원만이 이해할 수 있는 문서를 작성하여 경쟁/입찰에서 특권적인 위치를 효과적으로 보장할 것이라고 믿습니다.

이는 부분적으로 사실이지만 많은 경우 이 현상은 계약자의 상업 이익보다는 본 문서 구현에 대한 접근 방식의 차이와 관련이 있습니다.

특히 Wikipedia의 기술 사양 정의에는 "조달 대상에 대한 고객의 요구 사항이 포함된 문서이며 공개 또는 공개를 보장하기 위한 구현 조건 및 절차를 정의합니다. 지방 자치 단체의 요구, 이에 따라 상품 공급, 작업 수행, 서비스 제공 및 수락이 수행됩니다.”

또한 19.201-78과 같은 여러 GOST가 있는데, 이는 해당 문서에 무엇을 어떤 형식으로 포함해야 하는지 규정합니다.

그러나 실습에서 알 수 있듯이 소중한 약어 "TK"는 본질, 내용, 디자인 및 세부 사항이 완전히 다른 문서를 의미합니다. 안타깝게도 많은 고객은 미래 시스템에 대한 몇 페이지의 요구 사항을 작성하면 당사로부터 정확한(최대 델타 10-20%) 추정치를 얻을 수 있다고 확신합니다. 달력 계획공장 내일까지 평가를 하고 제안서를 보내야 한다는 TK라는 메일을 다시 한번 받았을 때, 나는 항상 정신적으로 "시스템이 모든 것을 교환해야 한다"는 스타일로 다음 창작물을 볼 준비가 되어 있습니다. 사이트에 필요한 정보를 제공합니다.”

한때 제가 일했던 부서에서는 다음과 같은 부서가 채택되었습니다. 기술 사양은 비즈니스 사용자가 이해할 수 있는 언어로 시스템 요구 사항을 설명하는 문서이고, 기술 프로젝트는 다음을 기반으로 작성된 문서였습니다. 모든 기능을 자세히 설명하는 더 자세한 기술 사양이지만 주로 개발자가 이해할 수 있는 언어로 작성됩니다.

나에게 이러한 특성은 공식적인 관점에서는 올바르지 않지만 초과 예산이 없지만 긴급한 솔루션이 필요한 작업을 수행하는 소규모 회사에는 매우 공정한 것으로 보입니다. 그들에게 가장 중요한 것은 직원이 기술 사양을 작성하여 예를 들어 여러 프랜차이즈 회사에 배포하는 것입니다. 그리고 엄청나게 많은 양을 담은 거대한 시트를 쓰는 것은 당연하다. 기술정보아무도 그렇지 않을 것이다.

그렇다면 "일반적인 구성 기능이 수행할 수 있는" 것이 아니라 작성자가 의도한 것과 정확히 일치하는 결과를 궁극적으로 얻을 수 있는 기술 사양을 어떻게 만들 수 있습니까?

기술 사양은 프로젝트의 목표를 설명해야 하고, 기능 요구 사항을 포함해야 하며, 약어 목록과 목차가 있어야 하며, 모든 내용은 다음과 같이 작성되어야 합니다. 가능한 가장 간단하고 짧은 문구 등. 나는 이것이 기술 사양을 여러 번 읽은 모든 사람에게 알려져 있다고 생각합니다.

내가 접한 문서와 이를 바탕으로 아이디어에 가장 가까운 결과를 얻은 문서에는 다음과 같은 속성이 있었습니다.

1. 지침에 따른 TK. 문서의 구조는 사용자 매뉴얼과 유사하며, 필요한 결과를 얻기 위해 사용자가 수행해야 하는 작업이 단계별로 기록되어 있습니다. 저것들. 이는 필요한 기능의 전체 목록은 없지만 세부 사항을 설명하는 개별 프로세스에 대한 논리적 분석이 포함된 문서였습니다.

2. 더 많은 시각화. 문서에 포함된 레이아웃/스크린샷/모형/흐름도가 많을수록 필요한 기능을 수행하는 것처럼 보이지만 완전히 다른 논리/디자인/인터페이스를 갖는 시스템을 얻을 가능성이 줄어듭니다.

3. 유용성.이전의 두 가지 요점에서 간단한 결과가 나옵니다. 명확한 작동 논리와 미래 시스템의 최대 시각화는 궁극적으로 시스템 사용 편의성과 관련하여 필요한 수의 참고/점을 기술 사양에 포함하는 데 도움이 될 것입니다. 기술이 부족한 직원이 사용하는 시스템의 경우 이는 프로젝트 성공에 결정적인 요소가 될 수 있습니다. 회계 프로그램"). 예를 들어, 소매 판매 시스템의 기술 사양에는 기사를 검색하는 데 3초를 넘지 않아야 한다고 명시되어 있지 않습니다. 표준 구성 검색을 통해 시스템을 구현한 경우 다음과 같은 결과가 발생할 수 있습니다. 중요한 상황실제 운영 중이기 때문에 항목 수를 고려하면 이 검색에 최대 30초가 걸렸는데, 이는 매 초가 중요한 소매 고객과 작업할 때 허용되지 않습니다.

4. 널리 사용되는 솔루션 링크. 예를 들어 회사의 영업 관리자와 같은 모든 사람에게 "거래 기능"이라는 문구는 거의 동일한 의미이지만 계약 직원에게는 이 문구가 전혀 의미가 없습니다. 하지만 이 문구에 몇 단어를 추가하면 "Bitrix24(또는 1C:CRM)의 거래 카드와 유사한 거래 카드" 옵션에서 고객이 바로 이 카드에서 기대하는 것이 무엇인지 이미 분명해집니다.

5. 초기 피드백. 다시 한 번 반복합니다. 기술 사양을 성공적으로 구현하려면 GOST에 따라 작성할 필요가 없습니다. 단지 의도된 문서를 작성할 필요는 없습니다. 기술 전문가. 우선 참조 조건은 컴파일러 동료와 이를 구현할 사람이 이해할 수 있어야 합니다. 긍정적인 결과를 얻는 것이 매우 중요합니다 피드백문서를 잠재적인 계약자나 내부 개발 부서에 전달하기 전에 동료 비즈니스 사용자로부터 확인하세요. 한 사람에게는 매우 명확하지만 가장 가까운 사람에게도 이해할 수 없는 문서는 성공적인 구현 가능성이 없습니다.

물론 기술 사양 작성 요구 사항에 대해서는 다른 관점이 있습니다. 그러나 필요한 시간, 자원, 역량이 부족한 상황에서는 위의 특성을 지닌 비즈니스 사용자가 가장 이해하기 쉬운 언어로 작성된 기술 작업이 성공 가능성을 최대화합니다. 구현.

이 텍스트는 저자 자신과 여러분 모두가 질문에 대한 표준화된 답변의 형태로 미래의 고객, 동료, 친척 및 지인에게 안전하게 보낼 수 있는 영구 링크의 존재를 위해 만들어졌습니다. "기술 사양이 필요합니까? 일반적으로 이것은 무엇입니까?"

그들이 말했듯이 - "천 단어 대신", 이 주제에 대해 Skype에서 4-5시간 동안 복음을 전할 때마다 이미 지루해지고 있으며 "기술 사양"의 정의에 노골적으로 말도 안 되는 말을 집어넣는 세계적인 경향이 점점 더 심해지고 있기 때문입니다. 수년에 걸쳐.

문제

사실은 용어에 대한 명확하고 이해하기 쉬운 정의뿐만 아니라 특정 형식이 있을 때 모든 조작 및 대체가 자신의 브리핑, 프로토타입, 즉석에서 발명된 설문지, 설명 및 단순히 들어오는 응용 프로그램으로 보인다는 것입니다. 적어도 비전문적입니다. 따라서 우리는 개념에 대한 과학적 정의부터 시작합니다.

기술 사양 - 원본 문서디자인을 위해 기술적 대상(제품). 기술 사양은 개발되는 개체의 주요 목적을 설정합니다. 기술 사양, 품질 지표 및 기술 및 경제적 요구 사항, 문서 작성(설계, 기술, 소프트웨어 등) 및 구성에 필요한 단계를 수행하기 위한 지침 및 특별 요구 사항. 참조 조건은 다음과 같습니다. 법적 문서- 수행을 위해 고객과 계약자 간의 계약에 애플리케이션이 포함되는 방식 디자인 작업그 기초는 목표, 목표, 원칙, 예상 결과 및 마감일을 포함하여 작업 순서와 조건을 결정합니다. 즉, 특정 작업 항목이 완료되었는지 여부를 판단할 수 있는 객관적인 기준이 있어야 합니다. 기술 사양 문구의 모든 변경, 추가 및 설명은 고객과 합의하고 승인을 받아야 합니다. 이는 설계 문제를 해결하는 과정에서 초기 데이터의 부정확성이나 오류가 발견될 경우 개발에 참여한 각 당사자의 유죄 정도와 이와 관련하여 발생한 손실의 분배를 판단하는 것이 필요하기 때문에 필요합니다. 이것으로. 해당 분야의 용어로서의 기술 사양 정보 기술– 개발, 구현 또는 통합을 위해 실행자에게 작업을 할당하는 데 필요한 포괄적인 정보가 포함된 법적으로 중요한 문서입니다. 소프트웨어 제품, 정보 시스템, 웹사이트, 포털 또는 기타 IT 서비스.

이해할 수 있는 언어로 번역

1) 기술과제 - 과제를 설정합니다. 이는 프로토타입, 스케치, 테스트, 디자인 프로젝트보다 먼저 와야 한다는 것을 의미합니다. 마인드맵, 데이터 흐름 다이어그램, 아키텍처는 이미 특정 작업의 완료이기 때문에 이것이 질문에 대한 답입니다. 그리고 질문 자체가 아직 모든 당사자에 의해 요청, 공식화 및 서명되지 않은 경우 모든 답변은 선험적으로 부정확할 것입니다. 그렇죠? 따라서 모든 프로젝트에 대한 작업의 시작은 문제를 공식화하는 것이며 문제 해결을 위한 12가지 옵션의 스케치를 열광적으로 검색하는 것이 아닙니다.

2) 실제로 새로운 내용은 논리적으로 첫 번째 지점부터 이어집니다. TK 자체의 텍스트는 "목표 및 목표" 장으로 시작해야 합니다. 이 장에서는 세계의 엔트로피를 높이려는 최근 시도가 추구하는 비즈니스 목표가 무엇인지 명확하게 설명합니다. . 어떤 문제도 해결하지 못하고, 아무것도 달성하지 못하며 "심심해서" 수행하는 목적 없는 작업은 공식적으로 기술 작업으로 간주되지 않으며 이제부터는 "보통 종이 조각"의 상태에 있습니다.

3) 제안된 디자인 컨셉이나 인터랙티브 프로토타입, 심지어 즉시 사용 가능한 웹사이트가 위의 비즈니스 문제를 해결하는지 어떻게 이해합니까? 더 이상 할 일이 없습니다. 다시 정의로 돌아가야 합니다. “... 예상 결과와 기한을 결정합니다. 즉, 이 작업 또는 저 작업 항목이 완료되었는지 여부를 판단할 수 있는 객관적인 기준이 있어야 합니다.” 즉, 기술 사양은 루블, 초, 톤 킬로미터 또는 섭씨 온도로 명확하게 측정 가능한 지표 없이는 존재할 수 없습니다. 간략한 내용이나 프로토타입, 기타 터무니없는 종이일 수도 있지만 기술 과제는 아닙니다.

여기에서 우리는 이 TOR에 동일한 지표를 취하고 측정하고 당사자가 악수를 하거나 재작업을 위해 프로젝트를 보내는 "수락 및 평가 절차" 장이 있어야 한다는 결론을 내립니다.

4) 기술 과제는 반드시 고객의 전반적인 사업 계획, 사업 개발 전략 및 시장 부문 분석과 일치해야 합니다. 이 모든 것을 통해 올바른 목표를 설정하고 정확한 측정 기준을 도출할 수 있으며, 이는 완성된 정보 제품을 적절하게 수용하는 데 사용됩니다. 고객의 사업 계획이 없으면 자동으로 기술 사양의 비전문적인 구현이 보장됩니다.

아웃소싱 스튜디오가 비즈니스 목표와 측정 가능한 비즈니스 지표를 소유자보다 더 잘 알고 있습니까? 분명히 그렇지 않습니다. 이는 올바른 기술 사양을 계약업체의 고용 직원이 아닌 고객의 대표가 작성해야 함을 의미합니다. 수행자가 스스로 작업을 설정하고 이를 평가하는 방법을 생각해낸 다음, 결국 완료된 작업에 대해 스스로 최종 점수를 매기는 것은 터무니없는 일입니다. 이상적으로는 그러한 "아마추어 활동"이 존재해서는 안 되지만 실제로는 모든 곳에서 발생하는 일이므로 기술 과제는 아무런 영향을 미치지 않습니다. 당신에게 필요한 도움프로젝트는 본질적으로 허구의 문서인 경우가 너무 많습니다. 그러지 마세요.

5) 완성된 기술 사양을 수정할 때마다 비용이 발생합니다. 당사자 중 한 사람이 마음을 바꾸거나, 잠을 충분히 자지 못하거나, 갑자기 돈을 절약하기로 결정했다는 이유로 "프로젝트 구성"을 자유롭게 끝없이 편집할 수는 없습니다. 기술 사양의 각 변경에 대한 가격도 관련 장에 미리 명확하게 명시되어야 합니다.

그런데 이론적으로 페이지나 기능 목록에 대한 모든 디자인 편집이나 변경에는 명확한 가격이 있어야 하며, 이 가격은 변경하기 전에 미리 지불해야 합니다. 개인적으로 저는 승인된 기술 사양의 편집 비용을 전체 프로젝트 예산의 30%로 추정해야 한다고 제안하지만 그렇지 않은 경우도 있습니다.

참조 조건에는 개발을 위한 시기와 총 예산은 물론 기존의 모든 자원과 제한 사항 목록을 미리 표시해야 한다는 점을 언급할 가치가 있습니까? - 아니, 너무 뻔할 것 같아.

그래서: 우리는 무엇을 하고 있나요? 무엇을 위해? 우리가 한 일을 어떻게 이해할 수 있습니까? 각 피벗 비용은 얼마입니까? - 종이에 적힌 이 모든 질문에 대한 답은 가장 실패한 프로젝트도 끌어낼 수 있는 “만약의 총알”입니다.

보안 질문

여기에 고객이 가장 자주 묻는 질문에 대한 답변을 나열하겠습니다.

1) 그렇다면 기술 사양 작성을 위한 공식 GOST도 있을 수 있을까요? - 네, 심지어 여러 개죠.

2) 뭐, 기술 사양에는 설명이 포함되어 있지 않습니다. 필수 페이지, 버튼 수, 사용된 라이브러리, 지침 등? - TOR 자체에는 없지만 부록에 이 모든 것을 넣을 수 있습니다. 물론 위에서 설명한 목표, 제한 사항 및 달성된 결과를 추가로 평가하는 방법을 사용하여 이 모든 것을 조정할 수 있습니다. 일반적인 캐릭터에 대한 설명까지 포함하여 최소한 모든 향후 콘텐츠를 게시하십시오. 그러나 작업에 대한 명확한 설명이 아니라 그 이후에 게시하십시오.

3) 그럼 그런 게 필요하지 않을까요? - 아마도 세상에 수천 명의 사람들이 태어날 때부터 눈이 멀고 잘 사는 것처럼 오늘날에는 수천 개의 사이트가 전혀 기술적 사양 없이 만들어지고 있을지도 모릅니다. 그러나 어디로 향하고 있는지 확인하고 의식적으로 결정을 내리고 얻은 결과를 독립적으로 평가하려면 기술 사양 없이는 할 수 없습니다.

4) 따라서 귀하와 Wikipedia는 기술 사양이 고객에 의해 작성되었다고 작성합니다. 그런데 어떻게 해야 할지 모르겠어요/시간이 없어요/그냥 혼자 하고 싶지 않아요. 어떻게 이런 일이 있을 수 있나요? - 기술 사양 개발을 귀하의 비즈니스, 작업, 대상 고객 및 요구 사항에 완전히 익숙하고 동시에 웹 개발의 모든 단계에 대해 철저하게 지식을 갖춘 제3자에게 아웃소싱합니다. 이 제3자는 일종의 "웹 공증인"이 될 것입니다. 즉, 계약자가 필요한 지표를 과소평가하지 않거나 마감 기한을 지연하지 않을 것이며 고객이 달성 가능한 지표를 설정하고 최종 승인 시 그렇지 않을 것이라는 보증인이 될 것입니다. 생성된 제품을 주관적으로 평가하고 이전에 기록된 요구 사항을 즉석에서 변경합니다.

5) 그리고 기술 사양이 법적 문서인 경우 아웃소싱 업체에게 비용을 지불하지 않고 소송을 제기하여 모든 것을 10번째로 다시 실행하도록 강요할 수 있습니까? - 문서가 올바르게 작성되면 성취도를 평가하기 위한 목표와 방법론이 표시됩니다. 문서에 당사자가 서명하고 계약에 언급된 경우(위탁 약관 자체는 계약이 아님) 물론 가능합니다. 그러나 일반적인 개요, 프로토타입, 예술 창작 레이아웃, FL의 안전한 거래로는 더 이상 그렇지 않습니다.

6) 작업이 일종의 스크럼이나 애자일을 사용하여 수행될 것이라고 말합니다. 이는 더 이상 구식 기술 사양이 필요하지 않음을 의미합니다. 그렇습니까? - 스스로 판단하십시오. 그들은 당신을 명확하게 가리는 이해할 수 없는 단어라고 부르고 이제 익숙하지 않은 용어를 기반으로 목표와 지표로 가득 찬 법적으로 유능한 문서를 포기하겠다고 제안합니다. Agile 자체는 "연말까지 최소 10,000 방문 달성"이나 "한 달 안에 사이트에서 25건 이상의 주문 달성"과 같은 목표를 세울 수 없으며 단지 회의를 개최하는 방법일 뿐이며 새로운 조직부주의한 직원. 여러 번 생각해보세요: "그들이 당신의 눈에 먼지를 던지고 있지 않습니까?" 실제로 전문적인 기술 사양은 새로운 스크럼에 해를 끼칠 수는 없지만 확실히 도움이 됩니다.