포털 개발을 위한 참조 조건. 소프트웨어 개발을 위한 올바른 기술 사양은 성공적인 프로젝트의 비결입니다. 기술 사양이 꼭 필요한가요? 기술 프로젝트

2표

좋은 하루 되세요, 독자 여러분. 클라이언트와 웹사이트 작업을 하는 것은 항상 어렵습니다. 일반적으로 고객은 "멋진 것"또는 "특이한 것은 없으며 다른 사람들과 같게 해주세요"를 원합니다. 추상적인 개념에 대해서는 동의하실 것입니다. 이것이 첫 번째 주문이라면 다음과 같은 비슷한 말에 만족할 수도 있습니다. "멋지네요. 창작의 자유를 주네요. 원하는 것은 무엇이든 할 수 있습니다." 경험을 통해 말씀드리자면, 이와 같은 것은 없습니다!

고객은 "멋지다"와 "다른 사람들처럼"에 대해 자신만의 이해를 가지고 있습니다. 당신이 추측하지 못하거나 기분이 좋지 않을 수도 있고, 그렇지 않으면 고객은 단순히 "그 정도 돈이면 이 남자(또는 여자)가 좀 더 일을 할 수 있다"고 결정할 것입니다. 이런 일이 발생하지 않도록 오늘은 웹사이트 개발을 위한 기술 사양이 어떻게 작성되는지 논의하겠습니다.

고객과 협력하기 위한 실행 계획

당신은 클라이언트를 찾습니다. 그는 돈을 지불할 준비가 되어 있고 당신은 일을 시작합니다. 어디서 시작하고 어떻게 진행해야 할까요?

  • 첫 번째 의사소통.

따라서 귀하는 초기 정보를 받았습니다. 이는 직접 방문(서비스를 직접 제공하는 경우) 또는 전화(클라이언트가 스스로 귀하를 찾는 경우)를 통해 발생할 수 있습니다. 고객이 귀하에게 온라인 상점을 원하고 그 자신이 보석 체인을 소유하고 있다는 것을 알고 있다고 가정해 보겠습니다. 즉시 사이트에 대한 대화를 시작하지 마십시오. 모두가 함께 한마음으로 준비할 수 있도록 약속을 잡으세요.

그 사람이 당신에게 원하는 것이 무엇인지 더 명확하게 알 수 있도록 정보를 보도록 동기를 부여하십시오.

  • 준비 및 첫 번째 브리핑.

고객에게 적합하다고 생각되는 사이트를 살펴보십시오. 일부 템플릿을 다운로드하고 사이트가 정확히 다음과 같이 보일 수 있다고 가정해 보세요. 재료는 많을수록 좋습니다. 고객에게 보여줄 것이 있고, 고객이 무엇을 좋아하고 무엇을 좋아하지 않는지에 대한 명확한 아이디어를 갖도록 하십시오. 시리즈의 추상적인 개념(아름다움, 편리함, 고품질)을 피하세요. 모든 사람은 이러한 범주에 대해 자신만의 생각을 가지고 있습니다.

이상적으로는 이러한 자료를 고객에게 하루 동안 맡기거나 회의 며칠 전에 우편으로 보내는 것이 좋습니다. 이 단계에서 고객은 일반적으로 포털에 특별히 관심이 없습니다. 그는 사실 직후에 진실을 잘라내고 다시 실행하고 새로운 것을 추가하도록 강요할 준비가 되어 있지만 사전에 아무것도 논의하지 않습니다. 따라서 유일한 방법은 가능한 한 많이 물어보고 모든 단어를 적어 두는 것입니다.

  • 기술 사양 작성 및 서명.

종이 조각이 많을수록 엉덩이가 더 깨끗해집니다. 클라이언트에서 가능한 모든 것을 적고 작성하고 서명하십시오. 그러면 보여줄 것이 있을 것입니다. 일반적으로 기술 사양을 작성할 때 귀하와 고객이 서로 의견을 달리하지 않고 법정에서 귀하의 사건을 변호하고 있다고 즉시 상상해 보십시오.

초고가 프로젝트를 말하는 것이 아니며 고객 여러분의 행운이 함께 하시길 바랍니다. 그러나 한 명의 세심한 고객이 당신의 기분을 오랫동안 망칠 수 있습니다. 당신은 더 이상 그 사람을 만나지 않기 위해 침을 뱉고 돈을 거부하고 싶을 것입니다. 이것은 이해할 수 있지만 처음에 자신을 전문가로 보여주고 모든 것을 철저히 연구하고 존경할만한 사람임을 보여주면 이렇게 할 필요가 없습니다.

어느 날 나는 매우 운이 좋았습니다. 회의에 오기 전에 고객은 문제를 연구하고 유능한 기술 사양뿐만 아니라 예술적 과제도 직접 작성했습니다. 즉, 문학과 상세 설명그것이 어떤 모습이어야 하는지. 나는 놀라움을 금치 못했고 그는 이렇게 대답했습니다. "우선 고통 전문가가 아니라 고객 자신이 원하는 것이 무엇인지 알아야한다고 믿습니다." 안타깝게도 이런 경우는 드물기 때문에 질문하고 처방하고 승인해야 합니다.

  • 개발 및 수신.

모든 것에 서명하고 나면 프로젝트 구현을 시작할 수 있습니다.

기술명세서에 있어서는 안 되는 것과 있어야 할 것은 무엇인가?

실제로 기술 사양에는 설계 자체에 관한 지침이 포함되어서는 안 됩니다. 프로그래머를 위한 웹사이트에 키보드를 그린 다음 시작한다고 적었습니다. 그런 것이 아니라 만화 스타일로 만들고 당신이 사슴이 아니라는 것을 증명하고 싶습니다. 자신이 전문가임을 더 잘 입증할수록 귀하에 대한 불만이 줄어들 것입니다!

당신은 어떤 스타일로 무엇을 그려야하는지 알고 있습니다. 당신은 브랜드 인지도를 높이거나 사람들이 이런 곳에서 휴가를 보내도록 동기를 부여하는 과제에 직면해 있습니다. 이 작업을 어떻게 구현할 것인지가 문제입니다. 또한 누락된 점은 고객이 코드 작성 방법과 사용할 도구를 알려주는 것이었습니다.

작업 명세서에 "합의되지 않은 모든 것은 수행자의 재량에 따라 수행됩니다."라는 문구를 포함시키십시오. 그리고 이 줄을 작은 글꼴로 만들 필요는 없습니다. 미리 생각하게 하고 프로젝트가 이미 준비되었을 때 꿈을 꾸지 마십시오. 물론, 작은 변화를 줄 수 있고 또 해야 합니다. 좋은 평판은 미래의 고객을 확보하는 열쇠입니다. 그러나 때로는 고객이 자신의 소망 때문에 너무 짜증나서 살고 싶지 않을 수도 있습니다.

다시 한 번 기술 사양에는 "편리함", "아름다움", "고품질" 등 추상적인 개념이 포함되어서는 안 된다는 사실에 주목하고 싶습니다. 경계를 명확하게 하라: 검색의 편리성보다는 날짜나 자료별로 필터링을 작성하는 것이 좋다.

그리고 서명도 잊지 마세요. 모든 것이 심각하므로 고객은 이를 이해해야 합니다.

일반적으로 작은 것에주의를 기울이는 것이 좋습니다. 거품을 낸 여성이 당신에게 다가와서 급히 거대한 재킷의 단추를 풀어 커다란 스카프가 튀어나오는 것을 상상해 보십시오. 그는 가방에서 100번을 접어 구겨진 18장짜리 지폐를 꺼내 근처의 물건으로 펴려고 한다. 얼굴이 빨개지고 명확하지 않음: "여기에 제가 작성하고 짧게 만들었습니다. 이것이 귀하의 웹사이트 모습이 될 것입니다. 서명하십시오."

또 다른 변형. 한 젊은 남자가 당신의 사무실을 두드리며 천천히 옷을 벗고 서류 가방에서 서류철을 꺼내 천천히 열어서 한가롭게 작은 종이 한 장만 보라고 권유하고 금색 펜을 내밀며 이 문서에 서명하라고 권유합니다.

첫 번째 예의 젊은 여성이 엄청난 일을 하게 하고, 그녀는 천 권의 책을 읽고, 선택할 수 있는 18개의 예를 그렸고, 기본적으로 모든 것을 스스로 했습니다. 그녀는 귀하의 회사를 번영과 세계적인 명성으로 이끌 믿을 수 없을 정도로 멋진 프로젝트를 만들 수 있습니다. 두 번째 예의 청년은 아무것도 할 줄 모르고 인터넷에서 샘플을 인쇄했는데 전혀 적합하지 않습니다.

나는 고객이 잔소리, 소원 및 변경으로 가난한 여성을 고문하고 즉시는 아니더라도 두 번째로 청년의 프로젝트를 받아 들일 것이라고 확신합니다. 그것은 당신이 무엇을 할 수 있는지에 관한 것이 아니라 당신이 어떻게 행동하고 당신이 만들어내는 인상에 관한 것입니다.

웹 사이트 개발을 위한 기술 사양을 생성할 수 있는 GOST가 있으며 장기적인 실습이 있습니다. 국가 표준이 항상 삶의 현실에 맞는 것은 아닙니다. 이 두 부분을 결합해 보겠습니다.

시 행정을 위한 기술 사양을 작성하든 전설적인 Vasily Pupkin을 작성하든 콘텐츠는 GOST에 따라 작성하는 것이 가장 좋습니다. 이것을 미리 배우십시오.

다음과 같습니다.

  1. 용어 사전
  2. 일반 조항
  3. 개발대상
  4. 문서의 목적
  5. 요구 사항 그래픽 디자인대지
  6. 웹사이트 디자인 요구 사항
  7. 디자인 컨셉 승인 절차
  8. 기능 요구 사항
  9. 웹 사이트 프레젠테이션 요구 사항
  10. 콘텐츠 관리 시스템 요구 사항
  11. 액세스 공유 요구 사항
  12. 담보 유형에 대한 요구 사항
  13. 정보 지원 요구 사항
  14. 소프트웨어 요구사항
  15. 기술 요구 사항
  16. 언어 지원 요구 사항
  17. 인체 공학 및 기술 미학에 대한 요구 사항
  18. 프로젝트 승인 및 납품 요구 사항
  19. 정보 작성 요구 사항
  20. 인력 요구 사항
  21. 유통 제공 절차
  22. 사이트 이전 절차는 다음과 같습니다. 기술적 수단고객

사실, 이 순서대로 작업을 수행하여 문서를 작성할 필요는 없지만 이해하기 쉽도록 이 계획에 따라 알려 드리겠습니다. 이 기사 마지막 부분에 기사의 이 부분에 제공된 기록을 기반으로 다운로드하여 작업할 수 있는 샘플을 첨부합니다. 이 템플릿은 다음과 같은 점에서 좋습니다. 모두, 결코 필요하지 않은 것조차도. 하지만 스스로 처리하고 불필요하다고 생각되는 불필요한 쓰레기를 삭제해야 합니다.

용어 사전

GOST에 따르면 문서는 용어집으로 시작해야 하지만 실제로는 끝에 작성하게 됩니다. 여기서는 고객과 작업할 때 사용할 조건을 제공해야 합니다. 호스팅, 웹 사이트 및 기타 말도 안되는 것이 무엇인지 알려주십시오. 이 모든 넌센스는 인터넷에서 다운로드할 수 있습니다.

그러나 이러한 이단적인 주장 외에도 귀하와 고객이 서로 의견이 다를 수 있는 용어를 언급할 필요가 있습니다. 당신은 한 가지를 의미하지만 그는 그 단어에 완전히 다른 의미를 부여합니다.

일반 조항

이 시점에서 우리는 실제로 무엇을 하려는지, 왜 하려는지에 대한 질문에 대답해야 합니다.

개발대상

우리가 할 일은 거의 명확합니다. 클라이언트는 이 정보를 거의 즉시 제공합니다. 사이트의 운영 목적, 즉 고객에게 어떤 이점이 있는지 이해하는 것이 더 중요합니다. 모든 고객이 사이트를 통해 수익을 창출하기를 원하는 것은 분명합니다. 이 공식은 작동하지 않습니다.

고객이 어떻게 돈을 벌지, 그의 목표가 무엇인지 생각해보십시오. 온라인 상점이라면 판매를 해야 하고, 기업 웹사이트라면 '브랜드 충성도 높이기', 회사 활동 알리기 등 아름다운 문구를 좋아합니다.

문서의 목적

여기서는 이 문서가 얼마나 중요한지 알려드립니다. 우리는 이것이 단순한 트릭이 아니라는 것을 보여줍니다. 하지만 와! 우리는 법적 용어를 사용합니다. 이 부분은 인터넷에서 복사할 수 있지만, 작성한 내용을 주의 깊게 읽는 것을 잊지 마세요!

그건 그렇고, 같은 부분에 고객과 사전에 논의하지 않은 모든 것이 양심에 남아 있다는 정보를 포함해야합니다. 그가 "잊었다", "마음을 바꿨다", "모든 것을 완전히 다르게 원한다"면 당신이 원하는 것은 무엇이든 자유롭게 할 수 있습니다.

웹사이트 그래픽 디자인 요구 사항

웹사이트 디자인 요구 사항

여기에서는 사이트 디자인, 거기에 있어야 할 내용, 준수해야 할 사항(기업 색상, 글꼴 등)을 일반적인 용어로 설명해야 합니다. 일반적으로 자세히 설명하지 마세요.

디자인 컨셉 승인 절차

이 부분에서는 다시 법률 용어를 사용하여 고객을 위협합니다. 당신은 그에게 포토샵으로 만든 사진 형태의 웹사이트 디자인을 제공하겠다고 말했습니다. 지정된 기간 내에 시청할 의무가 있습니다. 그런 다음 우리는 귀하에게 편집 내용을 제공할 것이며 귀하는 그가 사슴인지 여부에 대해 생각하고 이러한 변경이 얼마나 논리적인지 그리고 "수정"을 수행할지 여부를 조정하고 이해하게 될 것입니다.

기능 요구 사항

여기에서는 우리가 실제로 무엇을 하려는지 설명합니다. 우리는 시각적 구성 요소를 설명합니다. 이 장은 메인 페이지, 내부 및 사이트 구조를 설명하는 세 부분으로 구성됩니다.

조심하세요. 이것은 더 많이 쓰는 것이 더 좋은 중요한 포인트입니다. 예를 들어 '관련 뉴스' 섹션이 있어야 합니다. 무엇을 하시겠습니까? 주제에 가장 가까운 기사를 계산하는 알고리즘을 작성하거나, 사이트에 추가된 최근 5개 기사 목록을 제공하거나, 텍스트 작성자가 이 블록에 독립적으로 링크를 삽입할 기회를 갖게 됩니까?

웹 사이트 프레젠테이션 요구 사항

  1. 사이트 구조: 사이트에 어떤 카테고리(제목)가 포함될 것인지 설명합니다.
  2. 홈 페이지: 주요 요소에 대한 개략적인 그림과 설명이 있는 것이 가장 좋습니다.
  3. 내부 페이지: 이전 단락과 동일합니다. 내부 페이지의 다이어그램 및 설명.

온라인 상점을 만드는 경우 여기에 주문 페이지 다이어그램, 결제 확인 등을 삽입할 수도 있습니다. 표준 템플릿과 다른 페이지를 설명하세요.

콘텐츠 관리 시스템 요구 사항

내 블로그는 WordPress를 사용하여 웹사이트를 만드는 사람들을 위한 것입니다. 그러므로 나는 이 점에 큰 중요성을 부여하지 않을 것이다. 우리는 이 엔진을 사용할 것이며 그것으로 충분할 것이라고 말합니다.

제어 시스템을 직접 만들려면 모든 것이 훨씬 더 복잡해집니다. 다이어그램을 다시 그려서 일반적인 요구 사항, 섹션 관리, 콘텐츠 및 설정을 설명해야 합니다. 달라질 각 요소를 그립니다.

액세스 공유 요구 사항

본질적으로 그들은 사용자가 언제, 왜 등록이 필요한지 알고 싶어합니다. 닫는 섹션은 무엇이며 독자가 안전하게 사용할 수 있는 섹션은 무엇입니까? 정보 제공 또는 판매용 명함 사이트인 경우 완전히 공개되며 VKontakte에서는 예를 들어 다음 사이트에 액세스할 수 있습니다. 개인 페이지접근이 제한되어 있으며 로그인 및 비밀번호를 입력한 후에만 수행할 수 있습니다.

담보 유형에 대한 요구 사항

정보 지원 요구 사항

이 부분은 단순히 귀하의 인식을 보여주고 귀하가 어떤 전문가인지, 귀하가 알고 있는 정교한 용어가 무엇인지 고객에게 다시 한 번 보여주기 위해 만들어졌습니다.

책상이나 베개 밑이 아닌 서버의 특정 위치에 데이터를 저장할 것이라고 말합니다. 프로그래밍 언어를 사용하세요.

귀하는 다음에만 이미지를 게시할 것을 약속합니다. gif 형식또는 jpg, 페이지는 특정 무게를 초과하지 않습니다. 그건 그렇고, 좋은 지적입니다. 그런 다음 고객이 눈을 부풀리고 다른 것이 필요하다고 말하면이 항목을 보여주고 다음과 같이 말할 수 있습니다. "글쎄, 당신은 체중에 대해 서명했습니다. 나는 아무것도 모릅니다. 이 모든 것이 불가능합니다!"

여기서 언급할 수 있는 또 다른 유용한 점은 제공되는 콘텐츠를 제한하는 것입니다. 범위를 정의해야 합니다. 모든 콘텐츠를 수행하고 있습니까, 아니면 생성하고 있습니까? 계정관리자라면 고객에게 로그인과 비밀번호를 알려주고 고객이 알아내도록 하세요!

소프트웨어 요구사항

  1. 여기서는 호스팅 또는 서버에 대해 이야기하고 있습니다. 내 블로그는 Timeweb에서 작업하는 크리에이터를 대상으로 하기 때문에( https://timeweb.ru ) - 모든 것이 매우 간단합니다. 당신이 "우리" 중 하나가 아니라면 다음을 살펴봐야 합니다. 명세서. 예를 들어, 매우 똑똑한 사람이 멋진 웹사이트를 만든 다음 호스팅에 연결하려고 시도하지만 기술 사양이 너무 높아 러시아의 어떤 호스팅도 이를 처리할 수 없습니다. 꼭 필요한 아이템이지만, 개발 분야의 초보자에게는 해당되지 않는 아이템입니다.
  2. 여기서는 포털에 모바일 버전, 휴대용 장치에 적합하거나 다음을 통해서만 열 수 있습니다. 구글 크롬, 다른 브라우저의 왜곡은 우리를 전혀 괴롭히지 않습니다.

언어 지원 요구 사항

사이트가 두 가지 언어로 만들어질까요, 아니면 러시아어만 필요할까요?

인체 공학 및 기술 미학에 대한 요구 사항

다시 한번 우리는 디자인의 주요 원칙을 간략하게 언급합니다. 모든 것이 명확하고 간단하며 균일합니다. 로고는 어디에서나 볼 수 있으며 연락처 정보. 모든 것이 훌륭하고 모든 것이 훌륭합니다.

프로젝트 승인 및 전달 요구 사항

정보 작성 요구 사항

이 시점에서 우리는 우리가 해야 할 일과 작업이 더 빠르고 더 좋게 진행되도록 고객이 우리에게 제공해야 하는 것이 무엇인지 알려줍니다. 그는 일반적으로 정보와 사진이 필요합니다.

또한 그가 무언가를 수정하거나 변경하려면 유사한 계약을 다시 작성해야 하며 귀하가 서명하거나 서명하지 않을 것임을 다시 한 번 씁니다.

인력 요구 사항

사이트를 사용할 수 있는 사람 예를 들어, 일부 회사는 코드로 작업하고 일반 사람들을 위한 제어 시스템에는 신경도 쓰지 않습니다. 사이트에서의 기본 작업을 위해서는 직원의 상당한 지식이 필요합니다. 이 경우 요점은 관련이 있지만 우리의 경우에는 낙서된 종이일 뿐입니다.

유통 제공 절차

작업이 완료되면 고객에게 무엇을 줄 것입니까? 로그인, 비밀번호, 앞뒤.

기술 사양의 가격을 입력합니다.

이미 이해하셨듯이 기술 사양의 주요 임무는 중요하지만 이해하기에는 그리 많지 않습니다. 그러나 그 추가 기능은 자신에 대한 올바른 인상을 만들고 모든 종류의 변경으로부터 보호하는 것입니다.

이 문서에 관한 모든 것이 인상적이어야 합니다! 사전심사를 위해 우편으로 보내실 경우 반드시 이용해주시기 바랍니다. PDF 형식. 그리고 클라이언트는 아마도 편집으로 인해 자신을 고문하고 싶지 않을 것이며 당신을 전문가로 생각할 것입니다. 작은 일이지만 중요한 일입니다. Word 문서를 변환하려면 서비스를 사용할 수 있습니다 https://smallpdf.com/ru/ .

배경에 로고를 삽입하는 것을 잊지 마세요. 자기 회사또는 귀하의 브랜드를 선택하고 연락처를 삽입하세요. 홈페이지에서 빠르고 효율적으로 발급 가능 https://logaster.ru .

그게 전부입니다. 여러분이 해야 할 일은 제가 특별히 여러분을 위해 만든 예제를 다운로드하는 것뿐입니다. 이는 다르지 않을 몇 가지 템플릿 포인트를 이해하고 기초로 삼는 데 도움이 되며 작업은 완료됩니다.

이제 당신은 안전하게 고객에게 갈 수 있으며 불완전하다는 비난을 두려워하지 않을 수 있습니다.

TK 템플릿 다운로드

여러분의 노력에 행운이 있기를 바라며 다시 뵙겠습니다. 내 블로그를 구독하고 최고의 혜택을 받으세요 유용한 정보, 이는 고객을 위한 좋은 웹사이트를 개발할 때 확실히 유용할 것입니다.

참조 조건은 계약자와 고객 모두에게 중요합니다. 이는 계약자가 고객이 원하는 것을 더 잘 이해하고, 고객 측의 갑작스러운 "원함"을 보장하고, 작업 완료 작업 속도를 높이는 데 도움이 됩니다. 고객에게 - 그가 원하는 것을 정확히 말하고, 품질 관리를 단순화하고, 받기 위해 정확한 비용서비스. 기술 사양을 올바르게 작성하는 방법과 이를 사용하여 나중에 수행할 작업에 대해 이야기하겠습니다.

기술 사양이란 무엇입니까?

기술 사양은 향후 제품에 대한 모든 요구 사항을 반영하는 문서입니다. 모든 기술 요구 사항을 설명합니다. 일반적으로 기술 사양은 다음 형식으로 작성됩니다. 텍스트 문서, 드물게 - 다른 형식으로.

TK는 모든 웹사이트 개발자가 사용합니다. 이는 레이아웃 디자이너, 프로그래머 및 디자이너가 클라이언트의 요구 사항을 더 잘 이해하고 기대에 부응하는 리소스를 만드는 데 도움이 됩니다. 또한 기술 사양은 다음과 같은 다른 모든 영역에서도 사용됩니다.

  • 응용 프로그램 개발;
  • 주택 디자인;
  • 텍스트 작성 및 기타.

기술 사양에 따라 작업하면 분쟁 및 장기간의 소송 위험이 최소화됩니다.

기술 사양 작성 방법: 웹 사이트의 기술 사양 구조

시작하기 전에:

  • 기술 사양을 누가 작성할 것인지 결정
  • 용어를 설명하세요
  • 주관적인 용어는 피하세요

언뜻 보면 사이트에 대한 기술적 요구 사항은 클라이언트가 작성해야 하는 것처럼 보입니다., 그는 자원을 주문하고 이에 대한 요구 사항을 제시하기 때문입니다. 실제로 두 사람 모두 프로세스에 참여해야 합니다. 고객은 요구 사항을 말하고 수행자는 이를 구체적이고 정확하며 명확하게 기록합니다. 예를 들어, 클라이언트는 모든 사용자에게 적합한 웹사이트를 원한다고 말하고 개발자는 PC, 노트북, 태블릿, 스마트폰 등 4가지 사용 가능한 크기에 대한 적응성에 대한 요구 사항을 지정합니다.

용어의 명확화는 매우 중요한 포인트입니다.. 고도로 전문화된 모든 용어를 처음부터 설명하는 것이 좋습니다. 클라이언트는 바닥글, CMS 또는 물고기가 무엇인지 항상 알 수는 없습니다. 설명이 더 간단하고 명확할수록 양측 모두에게 기술 사양이 더 명확해집니다.

주관적인 용어는 불필요한 논란을 일으킬 수 있습니다.. “디자인은 아름다워야 한다”라고 쓰지 마세요. 아름다움에 대한 모든 사람의 개념은 다릅니다. "편리한", "사용하기 쉬운", "큰"이라는 질적 형용사에도 동일하게 적용됩니다. 특정 숫자와 매개변수를 사용합니다. 예를 들어 색상 구성표나 요소 배열을 설명합니다.

기술 사양의 구조는 무엇이든 가능합니다. 예를 들어, 우리는 웹사이트에 대한 간단한 참조 용어 구조를 제공합니다.

사이트 설명

어떤 유형의 사이트가 필요한지, 누가 사용할지, 왜 만들어지는지 알려주세요. 예를 들어 온라인 상점, 제품 판매를 위한 랜딩 페이지 또는 10페이지로 구성된 명함 웹사이트가 필요하다고 적습니다. 정확한 페이지 수를 모르는 경우 대략적인 페이지 수를 표시해 주십시오.

프로젝트에 특정 사항이 있는 경우 타겟 청중, 설명해보세요. 이는 고객의 관심을 끌 수 있는 리소스를 만드는 데 도움이 됩니다. 예를 들어 기사에 적절한 언어를 사용하거나 젊은이나 노년층의 관심을 끄는 디자인을 사용하는 것입니다.

구조에 대해 알려주세요

구조에 대한 아이디어 없이는 정상적인 웹사이트 개발이 불가능합니다. 사이트에 어떤 페이지가 포함될 것인지 설명하고 해당 페이지의 중첩 수준을 표시합니다. 이 작업은 다양한 방법으로 수행할 수 있습니다.

  • 계획
  • 테이블
  • 목록

가장 중요한 것은 결국 메뉴에 어떤 페이지가 위치할지, 어디로 이어질지, 각 섹션에 어떤 상위 페이지가 있는지 명확하다는 것입니다. 순서도를 사용하는 것이 좋습니다. 순서도는 목록이나 표보다 더 간단하고 이해하기 쉬우며 몇 초 안에 사이트의 전체 구조를 평가하는 데 도움이 됩니다.


블록 다이어그램 형태의 간단한 구조의 예

각 페이지에 무엇이 나올지 설명하세요.

사이트 페이지가 어떻게 보이는지 알려주세요. 각 요소의 위치를 ​​명확하게 보여주기 위해 프로토타입 형식으로 이를 수행하는 것이 좋습니다. 예를 들어, 사이트 헤더에 무엇이 있을 것인지, 피드백 양식이 어디에 있을 것인지, 자유 사이드 열에 무엇이 있을 것인지 등을 목록으로 설명할 수 있습니다.

사이트의 모든 페이지가 거의 유사한 경우(예를 들어 명함 웹사이트를 만들 계획이라면 두 가지 프로토타입을 사용하면 됩니다.) 홈페이지그리고 다른 섹션. 유사한 페이지로 구성된 여러 그룹이 있는 경우(예: 온라인 상점 카탈로그의 섹션, 기사가 포함된 블로그, 배송/조립/설치 서비스에 대한 설명) 각 그룹에 대해 고유한 프로토타입을 만드는 것이 좋습니다.


웹사이트 홈페이지 프로토타입의 예: 모든 것이 간단하고 편리하며 이해하기 쉽습니다.

디자인 요구 사항 설정

개발된 레이아웃이 있다면 훌륭합니다. 기술 사양에 간단히 삽입할 수 있습니다. 그렇지 않은 경우 색상 구성, 사용된 이미지, 로고에 대한 요구 사항을 설명해야 합니다. 예를 들어:

  • 디자인에 사용할 수 있는 기업 색상과 절대 사용할 수 없는 색상을 나타냅니다.
  • 사이트 헤더에 있어야 하는 로고를 제공하세요.
  • 페이지, 메뉴, 바닥글, 콘텐츠에 사용할 글꼴을 지정하세요.

명확한 요구 사항이 없는 경우, 즉 고객이 사이트에 대한 자신의 비전을 공식화할 수 없는 경우 고객에게 여러 표준 레이아웃을 제공하여 개별적으로 레이아웃을 선택하거나 개발한 다음 이에 동의할 수 있습니다. 이는 기술 사양이 승인되기 전에 완료되어야 합니다. 그렇지 않으면 취향의 차이로 인해 프로젝트가 크게 지연될 수 있습니다.

도구, 코드, 호스팅, 도메인에 대한 요구 사항 설명

어떤 도구를 사용할 수 있고 어떤 도구를 사용할 수 없는지 미리 아는 것이 필요합니다. 별도의 블록에 설명하십시오.

  • WordPress, Joomla, Modex 등 어느 사이트에 사이트가 있어야 합니까?
  • 사용할 수 있는 프로그래밍 언어(PHP, JavaScript, HTML 등)
  • 사이트는 어떤 호스팅과 어떤 도메인 영역에 위치해야 합니까? 도메인 이름사용될 수 있다
  • 어느 소프트웨어 플랫폼사용할 수 있습니다 - .NET, OpenGL, DirectX
  • 등등

클라이언트가 사용된 용어에 대해 아무것도 이해하지 못하는 경우 WordPress와 Modex, HTML의 PHP, zone.com의 도메인과 zone.ru의 도메인 간의 차이점을 설명하세요. 고객에게 적합하도록 함께 요구 사항을 작성하십시오.

사이트 운영 요구 사항 지정

기본적으로 사이트는 다음을 포함한 모든 장치의 사용자에게 작동해야 합니다. 다른 브라우저, 해커의 공격을 견뎌내고 1000명의 사용자가 동시에 방문해도 다운되지 않습니다. 하지만 이것을 별도의 블록으로 작성하는 것이 좋습니다. 표시하여주십시오:

  • 귀하가 수용할 수 있는 웹 사이트 로딩 속도 또는 표준 값은 1~5초입니다.
  • 브라우저 간 호환성 - 사이트를 열어야 하는 브라우저를 지정합니다.
  • 반응성 - 디자인이 적응해야 하는 화면 크기와 사용되는 장치를 지정합니다.
  • 부하에 대한 저항 - 사이트가 "다운"되지 않도록 동시에 사이트에 몇 명의 사람이 있어야 합니까?
  • 해커 및 dDos 공격에 대한 저항: 사이트는 소규모 공격을 견뎌야 합니다.

현장 운영 시나리오를 적어보세요

사용자가 사이트와 상호 작용하는 방법과 이에 대한 응답으로 리소스에서 어떤 작업이 발생해야 하는지 설명합니다. 이는 사용자가 작업 중에서 선택할 수 있는 경우 간단한 번호가 매겨진 목록이나 분기된 알고리즘의 형태로 수행될 수 있습니다. 대화형 서비스가 많은 경우 각 서비스에 대한 시나리오를 작성하세요.


웹사이트에 대한 가장 간단한 시나리오의 예

콘텐츠를 제작하는 사람이 누구인지 알아보세요.

일부 개발자는 텍스트를 직접 작성하고 일부는 카피라이터에게 주문하고 다른 개발자는 물고기를 사용합니다. 개발 서비스에 콘텐츠 제공이 포함되어 있는지 즉시 확인하시기 바랍니다. 그렇다면 다음과 같은 추가 요구 사항을 즉시 지정할 수 있습니다.

  • - Advego, Text.ru, Content.Watch에 따르면 95% 이상
  • 메스꺼움(스팸) - Advego에 따르면 10% 이하, Text.ru에 따르면 65% 이하입니다.
  • Glavred에 따른 점수 - 최소 6.5점 또는 7점

물론, 다양한 서비스가 만병통치약은 아니지만 서비스가 "부담스럽거나" 과도한 스팸이 될 위험을 최소화합니다. 또한 텍스트의 품질을 평가하는 정확한 기준이 나타나는 방식입니다.

마감일 지정

이것은 종종 잊혀집니다. 대부분의 기술 과제는 마감일을 지정해야 합니다. 그렇지 않으면 개발이 몇 달, 6개월 또는 몇 년 동안 지연될 수 있습니다. 잘못된 표현을 사용하지 마십시오(예: "한 달에"). 예를 들어 2018년 12월 1일과 같이 정확한 날짜를 입력하세요.

생활 꿀팁:협력 계약의 부록으로 참조 조건을 작성하는 것이 좋습니다. 이렇게 하면 웹사이트 개발을 위한 모든 요구 사항을 설정하고 분쟁이 발생할 경우 법정에서 승리할 수 있습니다.

기억하세요: 각 기술 사양에는 여러 가지 주요 블록이 포함되어야 합니다.

  • 목표 및 목표 - 일반적인 기술 사양을 만든 이유, 제품으로 수행하려는 작업
  • 제품은 어떤 모습이어야합니까 - 일반적인 용어 설명
  • 기술 요구 사항- 집의 면적, 텍스트의 양, 애플리케이션 기능 등
  • 마감일 - 분쟁을 피하는 데 중요합니다.

소프트웨어 기술 사양 작성의 예

우리는 소프트웨어를 만들어야 합니다. 기술 요구 사항은 다음과 같습니다.

설명: 모든 권위 있는 사이트에서 키워드로 기사를 검색하는 프로그램입니다. 권위 있는 사이트의 주소는 수동으로 입력해야 합니다.

소프트웨어가 수행해야 하는 작업:입장 후 예어신뢰할 수 있는 출처로 미리 입력된 사이트의 기사를 찾고 일치하는 항목 목록을 다음 형식으로 표시합니다.

  • 링크
  • 기사 제목
  • 리드 단락

일치하는 항목이 10개보다 많으면 페이지당 10개씩 나누어야 합니다.

기술 요구 사항:프로그래밍 언어 - 무엇이든 상관없습니다. 가장 중요한 점은 프로그램을 수정하여 온라인 서비스로 출시할 수 있다는 것입니다. 이상적으로는 서비스가 10초 안에 검색해야 합니다.

마감일: 2018년 9월 15일까지.

당연히 이 기술 사양은 개선될 수 있습니다. 예를 들어 설명하겠습니다. 참조 용어를 더욱 명확하고 단순하며 편리하게 만들기 위해 어떻게 개선할 수 있다고 생각하시나요?

기술 사양이란 무엇입니까? 이를 수행하는 방법과 용도는 무엇입니까? 예, 샘플, 팁 및 권장 사항.

누군가가 당신을 완벽하게 이해해 준다면 얼마나 좋을까. 당신은 몇 가지 문구를 제시했고 여기에 정확히 당신이 상상했던 것이 있습니다. 불행히도 그런 식으로 작동하지 않습니다.

정보 인식의 문제는 영원합니다. "깨진 전화" 효과는 흔히 발생합니다. 하지만 단순히 작업을 설정하는 방법을 모른다면 어떨까요? 예, 이런 일도 발생하며 어떻게든 작업해야 합니다. 그런데 어떻게 해야 할까요? 설정한 작업의 결과가 기대치를 충족하는지 확인하려면 기술 사양을 작성하세요.

기술 사양이란 무엇입니까?

기술 사양(또는 TOR)은 계약자가 제공하는 제품 또는 서비스에 대한 고객의 요구 사항을 포함하는 문서입니다. 간단한 말로: 나는 이런 식으로 7 개의 서로 직교하는 선이 있고 일부는 빨간색이고 일부는 무색이되도록 원합니다 (자료 끝에서 이 주제에 대한 비디오를 시청하는 것이 좋습니다).

디자인 부서

이 문서는 A4 페이지 한 장이나 한 권 전체를 차지할 수 있으며, 모두 문서에 포함된 작업과 희망 사항에 따라 다릅니다. 예를 들어, 소규모 제품에 대한 기술 사양을 작성할 수 있습니다. 방문 페이지(한 페이지 사이트) 또는 기계 학습 및 기타 기능을 갖춘 복잡한 소프트웨어입니다.

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

  • 수행자에게 작업을 할당합니다.
  • 마지막에 얻고 싶은 것이 무엇인지 자세히 설명합니다.
  • 작업 순서에 동의합니다.
  • 구현 후 작업을 평가하고 승인합니다.
  • ...(댓글에 옵션을 추가하세요).

실제로 기술 사양에는 위 목록보다 훨씬 더 많은 목적과 장점이 있습니다. 개인적으로 기술 사양이 해결하는 주요 작업은 기대(나의 기대)에서 최소한의 편차로 필요한 것을 구현하는 것입니다.

기술 사양 덕분에 구현 시간, 비용, 최종 제품 또는 서비스의 선언된 특성 준수 여부에 대해 언제든지 문의할 수 있습니다.

사실 이것은 고객과 계약자가 작성하는 심각한 문서입니다. 당사자들의 처벌과 의무가 규정된 범위 내에서. 다양한 GOST가 있습니다. Habré에 대해 자세히 알아보세요.

기술 사양 개발

예를 들어, "어른용" 게임에 관해 이야기하는 경우 개발을 위한 기술 사양 모바일 애플리케이션아니면 웹사이트, 그럼 이건 별도의 작업, 많은 돈이 지불됩니다. 일반적으로 전직 또는 현직 최고 기술 책임자(CTO)에게 도움을 요청합니다.

수염을 기르는 것은 선택사항입니다

프로젝트/작업의 범위에 따라 이 사람은 귀하가 원하는 모든 것을 수집하고 이를 기술 언어로 번역하며 아마도 스케치(대략 어떤 모습이어야 하는지)를 준비하고 완성된 문서를 제공합니다. 다음으로 이 문서를 수행자(회사 내 팀 또는 아웃소싱 팀)에게 전달하고 돈, 마감일에 동의하고 작업을 시작합니다.

팁: CTO는 팀에 있어야 합니다. 그렇지 않으면 구현 프로세스 중에 뭔가를 놓칠 가능성이 높습니다. 당신은 모든 것에 대한 지식이 충분하지 않습니다. 기술 사양 작성에 참여한 사람이 이를 확인합니다.

기술 사양은 무엇으로 구성되어 있나요?

모든 것은 선택한 템플릿에 따라 달라지지만(조금 더 나아가 템플릿/예제에 대한 링크를 제공하겠습니다) 기술 사양에 포함된 기본 블록이 있습니다.

  1. 프로젝트/작업에 대한 설명입니다. 완료해야 할 프로젝트나 작업이 무엇인지 간략하게 작성합니다.
  2. 목적과 목표. 프로젝트의 목표는 무엇입니까?
  3. 요구 사항. 필요한 디자인, 기능, 기술.
  4. 작품 설명. 무엇을, 언제, 어떻게 할 것인가?
  5. 통제 및 승인 절차. 작품이 어떻게 받아들여질지, 완성된 것으로 간주될 수 있는 것은 무엇인지.
  6. 응용 프로그램. 스케치, 스케치, 프로토타입.

작업 비용은 일반적으로 계약서의 별도 부록에 포함되지만 당사자가 기술 사양 자체에 금액을 명시하는 경우 발생합니다.

읽기를 방해해서 죄송합니다. 내 텔레그램 채널에 가입하세요. 새로운 기사 발표, 디지털 제품 개발 및 성장 해킹 등 모든 것이 있습니다. 너를 기다리고있어! 계속하자...

기술 사양의 예

기술 사양 개발은 복잡한 과정임에도 불구하고 매우 흥미롭습니다. 귀하의 임무는 최종 결과의 그림을 재현한 다음 이를 부분적으로 설명하는 것입니다.

업데이트에 대한 기술 사양 중 하나의 예 스마트 앱 TV. 더 복잡하고 복잡한 제품에 대한 작업은 기술 부서 동료의 도움을 받아 작성되었습니다. 주저하지 말고 팀원에게 도움을 요청하고 가능한 한 자주 프로세스에 참여시키세요. 그리고주는 것을 잊지 마세요 피드백! 결과도 모르고 노력과 시간을 투자하는 것보다 더 나쁜 것은 없습니다. 그 사람의 조언이 업무에 어떻게 도움이 되었는지 알려주세요. 그렇지 않으면 일방적인 게임이 됩니다.

온라인 상점 개발을 위한 참조 조건

모바일 애플리케이션 개발을 위한 참조 조건

사이트 참조 조건

서비스/업데이트에 대한 참조 약관

더 많은 샘플이 필요하면 Google에 문의하세요.

주요 권장 사항은 이렇게 하는 것입니다. 문제는 어머니의 게으름이 모든 사람을 압도하고 그것에 저항하기가 쉽지 않다는 것입니다. 모든 의지력을 모아 기술 사양 작성을 시작하세요. 멈추지 말고 그냥 작성하세요. "완벽하게" 작동하지 않는다고 걱정하지 마세요. 비밀을 알려 드리겠습니다. 이런 일은 절대 일어나지 않습니다. 그냥 쓰시면 매번 점점 더 좋아질 것입니다.

이렇게 되어야 한다

기술 사양 작성에 대한 나의 첫 번째 기초는 몇 년 전에 나타나기 시작했습니다. 저는 디자이너들과 협력하여 광고 소재 제작 작업을 설정했습니다. 광고 캠페인. 일관되지 않게 원했고 많은 시간과 설명을 낭비하게 되었습니다. 시간이 지남에 따라 작업 설정은 일종의 의미 블록으로 바뀌기 시작한 다음 기술 사양과 같은 것으로 바뀌기 시작했습니다.

예를 들어, "사이트의 좋아요 버튼" 작업의 경우:

  1. 설명: 우리 웹사이트에 "좋아요" 버튼을 만들어야 합니다.
  2. 목적 및 목표: 사용자 참여, 좋아요 수에 따른 자료 발행/등급 지정.
  3. 요구 사항: 다음 디자인(예: 유사한 항목에 대한 링크), 기능(모든 사용자가 사진을 평가하고 좋아할 수 있으며 사이트 시스템은 좋아요 수를 고려하고 자료 출력을 변경함), 기술(데스크톱에서 사용 가능) 및 사이트의 모바일 버전).
  4. 작업 설명: 버튼 레이아웃을 위한 3가지 옵션 그리기(준비 날짜: 10/01/17), 좋아요를 기반으로 자료 배포 시스템 개발(날짜: 10/14/17), 기능 테스트(날짜: 10/16/17) ), 출시(날짜: 17/10/17)
  5. 작업 수락: 사용자가 좋아요 버튼을 누르면 시스템이 클릭수를 계산하고 자료 전달이 변경됩니다.
  6. 응용 프로그램: 스케치, 스케치, 유사한 기능이 작동하는 프로젝트의 예.

작업에 필요한 구조의 섹션과 부분을 직접 남겨 두십시오. 예를 들어 여섯 번째 블록인 "애플리케이션"은 기능 요구사항에서 설명할 수 있습니다. 기본 조언: 어떤 식으로든 기술 사양의 구조에 따라 작업을 설명합니다. 이렇게 하면 놓치지 않을 거예요 중요한 점불필요한 질문으로부터 자신을 보호하고 동료의 삶을 더 편하게 만드십시오.

여기요

기술적인 작업이 무엇인지, 어떻게 수행하는지 살펴보았습니다. 이제 작업을 명확하고 명확하게 설정하고, 자신의 생각을 다른 사람에게 전달하고, 추가 설명에 소요되는 시간을 절약할 수 있습니다. 이제 이 모든 일을 어떻게 해야 할지 아시기를 바랍니다.

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

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

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

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

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

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

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

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

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

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

  • 기술 사양의 일반 조항

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

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

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

  • 프로젝트 목표

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

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

  • 기능 요구 사항

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

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

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

  • 마감일

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

  • 보고

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

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

  • 책임

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

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

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

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

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