ให้ฉันเริ่มต้นด้วยเรื่องตลกเกี่ยวกับกองทัพ ผู้บัญชาการออกคำสั่งให้กลุ่มทหาร Stroybat: "เรากำลังขุดจากรั้วจนถึงพระอาทิตย์ตกดิน!" สถานการณ์ที่คล้ายกันอาจเกิดขึ้นกับนักพัฒนา ทุกคนในทีมอาจถามว่า “จบเมื่อไหร่” แน่นอนว่างานในพื้นที่นี้สามารถดำเนินต่อไปได้เป็นเวลานาน ในการพัฒนาซอฟต์แวร์และการพัฒนาออกแบบเว็บไซต์จำเป็นต้องทราบระดับความพึงพอใจของลูกค้า
เป็นที่ยอมรับกันโดยทั่วไปว่าผู้จัดการโครงการเท่านั้นที่จำเป็นต้องรู้ข้อมูลทั้งหมดในโครงการ ในทางกลับกันอาจมี สถานการณ์ความขัดแย้งหากความคิดเห็นของผู้จัดการโครงการและความคิดเห็นของลูกค้าเกี่ยวกับโครงการขั้นสุดท้ายจะแตกต่างกัน และอีกหนึ่งสถานการณ์หากผู้จัดการโครงการที่มีความเข้าใจในขั้นตอนสุดท้ายของโครงการพัฒนาไม่พอใจกับเงินเดือนและพรุ่งนี้เขาจะย้ายไปทำงานอื่น?
งานด้านเทคนิค(TOR) เป็นเอกสารอย่างเป็นทางการที่ควบคุมทุกขั้นตอนของการพัฒนาการออกแบบเว็บไซต์หรือผลิตภัณฑ์ซอฟต์แวร์ ผิดที่จะถือว่านี่เป็นการแจกแจงเงื่อนไขของลูกค้าแบบยาว จาก ที.เคคาดว่าจะมีความชัดเจนและรัดกุมเกี่ยวกับรายละเอียดของการสร้างและลักษณะของผลิตภัณฑ์ขั้นสุดท้าย ไม่ควรสับสนกับสัญญาซึ่งระบุรายละเอียดของความรับผิดชอบของคู่สัญญา การตกลงร่วมกัน และปัญหาขององค์กรอื่นๆ
งานด้านเทคนิคสำหรับการพัฒนาการออกแบบเว็บไซต์จะต้องวาดขึ้นไม่ว่าโครงการจะมีขนาดเท่าใดก็ตาม ปัญหาไม่ได้อยู่ที่ขนาด แต่เป็นมุมมองที่แตกต่างกันเกี่ยวกับผลลัพธ์สุดท้ายของกระบวนการเดียวกันในแง่มุมต่างๆ ระหว่างผู้รับเหมาและลูกค้า การไม่ตกลงในรายละเอียดทั้งหมดอาจทำให้เสียแรง เวลา และเงินโดยเปล่าประโยชน์ เสื่อมเสียชื่อเสียงและไมตรี.
ดังนั้นเราจะพยายามเปิดเผยภูมิปัญญาทั้งหมดของการเขียนข้อกำหนดทางเทคนิคสำหรับการพัฒนาการออกแบบเว็บไซต์ สำหรับนักออกแบบ สิ่งสำคัญคือไม่ต้องเขียนกระดาษเป็นกองหนาๆ แต่ผลลัพธ์ที่ได้นั้นสำคัญ นั่นคือเว็บไซต์ที่สร้างขึ้นอย่างมืออาชีพ เงื่อนไขการอ้างอิงที่เป็นลายลักษณ์อักษรสำหรับการพัฒนาไซต์จะสะท้อนถึงทัศนคติที่เอาใจใส่ต่อผู้เข้าร่วมโครงการทุกคนและแสดงทิศทางของการพัฒนา การพัฒนาเว็บ.
นอกจากนี้ยังควรจดจำว่า TK มีข้อ จำกัด หลายประการ ขั้นแรก เราจะพูดถึงการรวบรวมข้อกำหนดทางเทคนิคโดยใช้วิธีการเรียงซ้อน แต่ใช้วิธีอื่นสำหรับกรณีอื่น ประการที่สอง ควรแยกความแตกต่างระหว่างการร่าง TOR สำหรับพอร์ทัลขนาดใหญ่และ TOR สำหรับไซต์ที่มีงบประมาณต่ำ ความแตกต่างคือขนาดของเอกสาร ยิ่งปริมาณมากเท่าใด การพัฒนาก็จะยิ่งใหญ่ขึ้นและน่าเบื่อมากขึ้นเท่านั้น ใน TOR ปริมาณมากสำหรับการพัฒนาการออกแบบไซต์จะมีพิธีการมากมาย แต่ขนาดของ TOR ขึ้นอยู่กับความซับซ้อนของการพัฒนาโครงการมากกว่าขนาดของมัน
งานด้านเทคนิคที่เขียนอย่างดีควรตอบคำถามอะไรบ้าง? เงื่อนไขการอ้างอิงสำหรับการพัฒนาการออกแบบไซต์มีความสำคัญสูงสุดสำหรับผู้เข้าร่วมโครงการ เช่น ผู้จัดการโครงการ นักพัฒนา และลูกค้า ผู้ใช้หลักของไซต์จะเป็นลูกค้าและผู้เยี่ยมชมไซต์ในอนาคต ตามนี้ในเงื่อนไขการอ้างอิงจำเป็นต้องระบุรายละเอียดผู้ที่จะใช้ไซต์ อาจเป็นพนักงานบริษัทและผู้มาติดต่ออื่นๆ รายละเอียดดังกล่าวมีความสำคัญเนื่องจากมีข้อมูลสำคัญที่สามารถสร้างข้อกำหนดสำหรับการพัฒนาการออกแบบไซต์
ขั้นตอนของการพัฒนาการออกแบบเว็บไซต์คืออะไร? เราได้กล่าวถึงข้างต้นนี้แล้ว ในแง่ของการอ้างอิง กระบวนการทั้งหมดในการทำงานในโครงการได้รับการลงนามอย่างละเอียด ขั้นตอนดังกล่าวเป็นมาตรการที่จำเป็นอย่างยิ่ง เนื่องจากไม่มีวิธีการพัฒนาแบบเดียว จึงจำเป็นต้องเขียนประเด็นหลักทั้งหมดของการพัฒนาใน TOR และอธิบายรายละเอียดแต่ละประเด็น สุดท้ายลูกค้าจะได้อะไร? การพัฒนาการออกแบบเว็บไซต์เริ่มต้นด้วยงานด้านเทคนิคและจบลงด้วยงานนั้น คุณต้องหารือเกี่ยวกับงานด้านเทคนิคแต่ละรายการร่วมกับลูกค้า ตรวจสอบทุกอย่าง ชี้แจงทุกอย่าง ToR เป็นหลักฐานของงานที่ทำ
คุณต้องการอะไรในการเริ่มพัฒนาการออกแบบเว็บไซต์ บางครั้งปัญหานี้ถูกแยกออกมาในเอกสารแยกต่างหาก เช่น ในสัญญา แต่สำหรับการเตรียม TK ก็มีความสำคัญเช่นกัน คำตอบสำหรับคำถามนี้ขึ้นอยู่กับจำนวนผู้เชี่ยวชาญที่เกี่ยวข้อง โปรแกรมที่จะใช้ ฯลฯ
ในส่วนแรกและในบทนำของ ToR จะอธิบายถึงพิธีการและวลีทั่วไป เอกสารส่วนนี้เปลี่ยนแปลงเป็นครั้งคราวและเฉพาะในบางแห่งเท่านั้น เช่นเดียวกับในเอกสารส่วนใหญ่ ในส่วนทั่วไปจะเขียนข้อมูลเกี่ยวกับลูกค้าและผู้รับเหมา รายละเอียด ข้อมูลทางกฎหมาย และสถานะของเอกสาร หากคุณพลาดบางอย่างในส่วนนี้ ก็ไม่เป็นไร เนื่องจากข้อมูลพื้นฐานของแผนดังกล่าวจะอยู่ในสัญญา
1. สถานที่ เงื่อนไข และเงื่อนไขการปฏิบัติงานเกี่ยวกับการซ่อมแซมสถานที่ (ต่อไปนี้จะเรียกว่างาน):
1.1. สถานที่ทำงาน:
สถานที่ที่ไม่ใช่ที่อยู่อาศัยเลขที่ 50 ตั้งอยู่บนชั้น 5 ของอาคารตามที่อยู่:
1.2. เงื่อนไขการทำงาน:
งานจะต้องดำเนินการตามข้อกำหนดในการอ้างอิงนี้สำหรับการปฏิบัติงานในการซ่อมแซมสถานที่ (ต่อไปนี้จะเรียกว่าข้อกำหนดในการอ้างอิง) ความคืบหน้าของงานจะถูกควบคุมโดยลูกค้า ปิดตัวลง ระบบวิศวกรรมเครือข่ายหรือส่วนต่าง ๆ ของพวกเขาจะทำโดยข้อตกลงล่วงหน้ากับลูกค้าและฝ่ายบริหารทรัพย์สินและ ทรัพยากรที่ดินการบริหารเมืองตเวียร์
งานจะดำเนินการตามการประมาณการในท้องถิ่นสำหรับการปฏิบัติงานในการซ่อมแซมสถานที่ (ภาคผนวกของสัญญาฉบับที่ลงวันที่ (ต่อไปนี้จะเรียกว่าสัญญา))
1.3. เวลาตอบสนอง:
ผู้รับเหมาตกลงที่จะเริ่มทำงานหลังจากลงนามในข้อตกลงนี้โดยคู่สัญญาไม่ช้ากว่าวันถัดจากวันที่ตกลงประมาณการในท้องถิ่นสำหรับการซ่อมแซมสถานที่กับแผนกการจัดการทรัพย์สินและทรัพยากรที่ดินของการบริหารเมืองตเวียร์ เพื่อให้งานทั้งหมดเสร็จสิ้นและโอนผลงานให้กับลูกค้าภายใน 30 (สามสิบ) วันตามปฏิทินนับจากวันที่เริ่มงาน
2. ลักษณะทั่วไปของงาน:
การดำเนินงานซ่อมแซมอาคารที่ไม่ใช่ที่อยู่อาศัยเลขที่ 50 ซึ่งตั้งอยู่บนชั้น 5 ของอาคารตามที่อยู่: (ต่อไปนี้จะเรียกว่าอาคารสถานที่)
3. ข้อกำหนดสำหรับคุณภาพและความปลอดภัยของงาน:
3.1 ข้อกำหนดด้านคุณภาพ ข้อกำหนดทางเทคนิคของงานและตัวบ่งชี้อื่น ๆ ที่เกี่ยวข้องกับการพิจารณาความสอดคล้องของงานที่ดำเนินการตามความต้องการของลูกค้านั้นกำหนดโดยกฎและข้อบังคับอาคารปัจจุบัน (ต่อไปนี้จะเรียกว่า SNiP) ชุดของกฎสำหรับการก่อสร้าง (ต่อไปนี้จะเรียกว่า SP) แผนก รหัสอาคาร(ต่อไปนี้เรียกว่า VSN) กฎอนามัยและบรรทัดฐาน (ต่อไปนี้เรียกว่า SanPiN) มาตรฐานของรัฐ(ต่อไปนี้จะเรียกว่า GOST) ข้อมูลจำเพาะ(ต่อไปนี้ มธ.), บรรทัดฐาน ความปลอดภัยจากอัคคีภัย(ต่อไปนี้จะเรียกว่า NPB) กฎ ความปลอดภัยจากอัคคีภัย(ต่อไปนี้เรียกว่า PPB) กฎสำหรับการติดตั้งระบบไฟฟ้า (ต่อไปนี้เรียกว่า PUE) และเอกสารข้อบังคับอื่น ๆ
ในระหว่างการปฏิบัติงานจำเป็นต้องปฏิบัติตามเทคโนโลยีและวิธีการทำงานข้อกำหนดด้านสิ่งแวดล้อมสุขอนามัยและสุขอนามัยไฟและมาตรฐานอื่น ๆ ที่บังคับใช้ในดินแดน สหพันธรัฐรัสเซีย:
บรรทัดฐานและกฎการก่อสร้าง SNiP "ความปลอดภัยของแรงงานในการก่อสร้าง";
กฎหมายของรัฐบาลกลาง -FZ "ข้อบังคับทางเทคนิคเกี่ยวกับความปลอดภัยของอาคารและโครงสร้าง";
กฎหมายของรัฐบาลกลาง -FZ "เกี่ยวกับความปลอดภัยจากอัคคีภัย";
บรรทัดฐานและกฎการก่อสร้าง SNiP "ความปลอดภัยจากอัคคีภัยของอาคารและโครงสร้าง";
มาตรฐานความปลอดภัยจากอัคคีภัย NPB 244-97 “วัสดุก่อสร้าง วัสดุตกแต่งและวัสดุปิดผิว วัสดุปูพื้น. หลังคา, กันซึมและวัสดุกันความร้อน ตัวบ่งชี้ความปลอดภัยจากอัคคีภัย
กฎหมายของรัฐบาลกลาง -FZ "ข้อกำหนดทางเทคนิคเกี่ยวกับข้อกำหนดด้านความปลอดภัยจากอัคคีภัย"
3.2. เสี่ยงต่อการเสียชีวิตจากอุบัติเหตุหรือความเสียหายจากอุบัติเหตุ สถานที่ที่ไม่ใช่ที่อยู่อาศัยเมื่อปฏิบัติงานจนเป็นที่ยอมรับของลูกค้า ผู้รับเหมาจะเป็นผู้รับผิดชอบ
4. ข้อกำหนดสำหรับองค์กรของการทำงาน:
4.1. ต้องทำงานในวันธรรมดา: วันจันทร์ วันอังคาร วันพุธ วันพฤหัสบดี เวลา 09.00 - 18.00 น. วันศุกร์ เวลา 09.00 - 16.45 น. การจัดทำงานในวันเสาร์ดำเนินการตามข้อตกลงล่วงหน้ากับลูกค้าตั้งแต่เวลา 09.00 น. ถึง 16.00 น.
4.2. ผู้รับเหมามีหน้าที่ต้องมั่นใจในการปฏิบัติงานจากวัสดุของเขาด้วยกำลังและวิธีการของเขาเอง องค์ประกอบของวัสดุระบุไว้ในประมาณการท้องถิ่นสำหรับการปฏิบัติงานในการซ่อมแซมสถานที่ (ภาคผนวกหมายเลข 1 ของข้อตกลง)
4.3. เฉพาะผู้เชี่ยวชาญที่มีคุณสมบัติเหมาะสมตามประเภทที่กำหนด กฎหมายข้อบังคับทำหน้าที่ในด้านการก่อสร้าง ไม่อนุญาตให้ดึงดูดผู้เชี่ยวชาญที่ไม่มีถิ่นที่อยู่และชาวต่างชาติโดยไม่ได้ลงทะเบียนอย่างถูกต้องและได้รับอนุญาตให้ดึงดูดแรงงานต่างชาติ เมื่อภาระผูกพันดังกล่าวถูกกำหนดขึ้นโดยปัจจุบัน กฎหมายของสหพันธรัฐรัสเซีย.
4.4. การป้องกันวัสดุอุปกรณ์อย่างเหมาะสม อุปกรณ์ก่อสร้างและทรัพย์สินอื่น ๆ ของผู้รับจ้างในระหว่างปฏิบัติงาน ผู้รับจ้างจะต้องจัดหาให้
5. ข้อกำหนดสำหรับวัสดุและอุปกรณ์
5.1. คุณภาพและความปลอดภัยของวัสดุและอุปกรณ์ที่ใช้ในการทำงานต้องเป็นไปตามข้อกำหนดบังคับของข้อบังคับทางเทคนิค มาตรฐานของรัฐสำหรับความปลอดภัยทางไฟฟ้า เครื่องกล และอัคคีภัย เสียง ระดับการรบกวนทางวิทยุอุตสาหกรรม ความต้านทานต่อการรบกวนทางแม่เหล็กไฟฟ้า และ ข้อกำหนดด้านสุขอนามัย, มาตรฐานสุขอนามัยและกฎและได้รับการยืนยันโดยการประกาศความสอดคล้อง ใบรับรองความสอดคล้อง และข้อสรุปด้านสุขอนามัยและระบาดวิทยา
5.2. วัสดุทั้งหมดต้องมีใบรับรองที่เหมาะสม ข้อสรุปด้านสุขอนามัยและระบาดวิทยา เอกสารข้อมูลทางเทคนิคและเอกสารรับรองคุณภาพอื่นๆ ต้องมอบสำเนาใบรับรองเหล่านี้ ฯลฯ ให้กับลูกค้าไม่เกินสองวันปฏิทินก่อนเริ่มงานโดยใช้วัสดุและอุปกรณ์เหล่านี้
6. ข้อกำหนดสำหรับการจบงาน
6.1. การเตรียมสถานที่สำหรับการถือครอง งานซ่อม(การถอดท่ออากาศที่ไม่ใช้แล้ว โครงสร้างโลหะ , ท่อประปา, อุดท่อระบายอากาศที่ไม่ได้ใช้ในผนัง)
6.2. ผนังหุ้ม ผนังไม้ด้วยอุปกรณ์ของช่องเทคโนโลยีภายใต้ แผนที่ทางภูมิศาสตร์, กล้องวิดีโอ,เทคนิคการขยายเสียง. อุปกรณ์ชั้นวางท่อสำหรับวางและยึดแผงวิดีโอแบบไร้รอยต่อ
ต้องขัด drywall ที่ติดตั้งก่อนติดกาว ควรทารองพื้นก่อนขัดและหลังขัด ใช้ไพรเมอร์เจาะลึก การติดวอลล์เปเปอร์แบบไม่ทอเพื่อทาสีด้วยสีน้ำ พื้นผิวของวอลล์เปเปอร์และสีของสีควรตกลงกับลูกค้า
6.3. การติดตั้งฝ้าเพดานแบบแขวน.
สำหรับเพดานของสถานที่ให้ใช้ - เพดานระงับ "อาร์มสตรอง" และกระเบื้องเพดาน "ไบคาล"
6.4. ซ่อมพื้น.
รื้อเสื่อน้ำมันและแท่นเก่าออกจากพื้น ติดตั้งช่องเทคโนโลยีและช่องสำหรับเชื่อมต่ออุปกรณ์ที่ติดตั้ง ปรับระดับด้วยซีเมนต์ปาด วาง ลามิเนตชั้นไม่ต่ำกว่า 32 สี "บีช" สีที่ตกลงกับลูกค้า แท่นควรเป็นพลาสติกสี "บีช" พร้อมช่องเคเบิล พื้นไม่ควรมีข้อบกพร่องพื้นควรเรียบไม่มีช่องว่างที่มองเห็นได้
6.5. อุปกรณ์ของพาร์ติชันระหว่างห้อง
พาร์ติชั่นควรทำจากแผ่นยิปซั่มพร้อมฉนวนกันเสียงและหน้าต่างกระจกสองชั้นแบบเลื่อนในห้องควบคุมควรทำรองพื้นก่อนเติมและหลังการขัดด้วยไพรเมอร์เจาะลึก การวางด้วยวอลล์เปเปอร์ที่ไม่ทอสำหรับการระบายสีด้วยสีน้ำ พื้นผิวของวอลล์เปเปอร์และสีของสีควรตกลงกับลูกค้า ติดตั้งประตูทางเข้าและประตูในสถานที่ติดกันตามที่ตกลงกับลูกค้า
6.6. รื้อวงกบหน้าต่างเก่า, แผงขอบหน้าต่างไม้, ติดตั้งบล็อกหน้าต่างจากหน้าต่างกระจกสองชั้น PVC สองห้อง, แผงขอบหน้าต่างพลาสติก
สีของหน้าต่างกระจกสองชั้นเป็นสีขาว หน้าต่างต้องมีส่วนเปิดอย่างน้อย 1/3 ของพื้นที่ ช่องหน้าต่างต้องติดมู่ลี่และม่านม้วนสีตามที่ตกลงกับลูกค้า ขอบหน้าต่าง - พลาสติกลึกอย่างน้อย 50 ซม.
6.7. การซ่อมแซมเครื่องสำอางของแบตเตอรี่เครื่องทำความร้อนส่วนกลาง
การติดตั้งเครื่องควบคุมอุณหภูมิ การติดตั้งหน้าจอ drywall พร้อมกับ การระบายอากาศพอใจ ควรทารองพื้นก่อน สีโป๊วและหลังจากขัดด้วยไพรเมอร์เจาะลึก การวางด้วยวอลล์เปเปอร์ที่ไม่ทอสำหรับการระบายสีด้วยสีน้ำ พื้นผิวของวอลล์เปเปอร์และสีของสีควรตกลงกับลูกค้า
7. ข้อกำหนดสำหรับงานไฟฟ้า
7.1. ดำเนินการไฟฟ้าตามโครงการ สายไฟฟ้า(ข้อ 9 ของข้อกำหนดในการอ้างอิง)
7.2. ในการผลิต งานไฟฟ้าเป็นไปตามข้อกำหนดของ SNiP 3.05.06-85 "อุปกรณ์ไฟฟ้า" ติดตั้งซ็อกเก็ตในช่องเคเบิลที่ติดตั้งที่ระยะอย่างน้อย 0.5 ม. จากระดับพื้น การติดตั้งภายนอก
7.3. ติดตั้งสวิตช์บอร์ดไฟฟ้า (ES) พร้อมติดตั้ง 9 เบรกเกอร์วงจร(การป้องกันอัตโนมัติของเครือข่ายสถานีบริการน้ำมัน ).
7.4. ในการส่องสว่างและส่องสว่างตามซอกต่างๆ ด้วยการ์ด ให้ใช้หลอดประหยัดไฟที่เป็นมิตรกับสิ่งแวดล้อม
7.5. วางสายไฟฟ้าทั้งหมดอย่างเปิดเผยตามแนวผนังในช่องเคเบิล เหนือเพดานแขวนในท่อลูกฟูกที่ไม่ติดไฟ วางสายไฟฟ้าบนพื้นในท่อโลหะหรือโปรไฟล์โลหะ จัดให้มีช่องว่างทางเทคโนโลยีสำหรับการวางสายเคเบิล
7.6. เชื่อมต่อสายไฟจากผู้บริโภคเข้ากับสวิตช์บอร์ดที่ติดตั้งพร้อมกับเซอร์กิตเบรกเกอร์ วางสายไฟและเชื่อมต่อ สวิตช์บอร์ดสำนักงานกลาง (ห้องหมายเลข 41) ผ่านเบรกเกอร์
7.7. แผ่น เส้นทางเคเบิลที่จะกำหนดเมื่อเสร็จงาน
7.8. ระหว่างการติดตั้ง ให้ใช้สายเคเบิลที่มีตัวนำทองแดงเป็นฉนวน PVC ในปลอก PVC ที่ไม่ติดไฟ ซึ่งผลิตตามมาตรฐาน GOST 22483 “ตัวนำทองแดงที่เป็นสื่อกระแสไฟฟ้าสำหรับสายเคเบิล สายไฟ และสายไฟ พารามิเตอร์หลัก ความต้องการทางด้านเทคนิค". ซ็อกเก็ตต้องเป็นไปตามมาตรฐานยุโรป วัสดุและอุปกรณ์ทั้งหมดต้องมีใบรับรอง หนังสือเดินทางทางเทคนิค และเอกสารอื่น ๆ ที่รับรองคุณภาพตาม ข้อกำหนดของ PUE, SNiP และ PPB วัสดุทั้งหมดต้องเป็นของใหม่และผลิตไม่เกินไตรมาสที่ 1 ของปี 2012
8. ข้อกำหนดสำหรับระยะเวลาการประกันคุณภาพงาน
ระยะเวลาการรับประกันคุณภาพสำหรับงานที่ทำโดยคำนึงถึงวัสดุที่ใช้ควรเป็น 36 เดือนในจำนวน 100% นับจากวันที่ลงนามในใบรับรองการยอมรับสำหรับงานที่ทำ (แบบฟอร์ม KS-2) ในระหว่าง ระยะเวลาการรับประกันผู้รับจ้างมีหน้าที่ต้องกำจัดข้อบกพร่องใด ๆ อันเป็นผลมาจากการทำงานภายใต้สัญญาด้วยค่าใช้จ่ายของตนเองภายในระยะเวลาไม่เกิน 15 (สิบห้า) วันตามปฏิทินนับจากวันที่ลูกค้าร้องขอ
9. แผนภาพการเดินสายไฟ
ฉันจำเนื้อหาเกี่ยวกับการออกแบบไซต์และโปรแกรมในภาษารัสเซียได้น้อยมาก ซึ่งเขียนโดยผู้เขียนที่พูดภาษารัสเซียได้ สิ่งนี้อำนวยความสะดวกโดยการพัฒนาที่เน้นการส่งออกเป็นหลัก (นอกชายฝั่ง) และการขาดประสบการณ์จำนวนมากในการสร้างผลิตภัณฑ์ข้อมูลในประเทศของเรา
ฉันหวังว่าบทความนี้จะเป็นประโยชน์กับนักพัฒนาและผู้จัดการฝ่ายไอทีที่เคยประสบปัญหาในการรวบรวมเอกสารคุณภาพสูงสำหรับการพัฒนาเว็บไซต์ เอกสารที่นอกเหนือจากกระดาษที่ชำรุดแล้วอย่างน้อยก็มีประโยชน์
เบื้องต้น
ทำไมต้องร่างงานด้านเทคนิค (TOR) สำหรับไซต์
ไม่ว่าคุณจะใช้วิธีการพัฒนาแบบใด และไซต์ของคุณมีขนาดเท่าใดก็ตาม คุณจะต้องเผชิญกับคำถามไม่ว่าในกรณีใด: "และเมื่อเราทำงานเสร็จ เราจะเข้าใจได้อย่างไรว่าเราทำเสร็จแล้วจริงๆ" ในการพัฒนาทั้งซอฟต์แวร์และไซต์ใดๆ ปัญหาที่พบบ่อยคือไม่มีใครมองเห็นจุดสิ้นสุด ในแง่หนึ่ง เราสามารถพูดได้ว่าผู้จัดการโครงการควรมีวิสัยทัศน์สุดท้ายของโครงการ แต่จะเป็นอย่างไรหากผลิตภัณฑ์ขั้นสุดท้ายตรงกับภาพลักษณ์ของผู้จัดการ แต่ไม่ตรงกับความคาดหวังของลูกค้า และถ้าในระหว่างโครงการ 3 ผู้จัดการเปลี่ยน?
ผลที่ตามมาของกฎเก้าสิบเก้าสิบของพาร์กินสัน:
โค้ด 90% แรกใช้เวลา 90% ของการพัฒนา โค้ดที่เหลืออีก 10% ใช้เวลาในการพัฒนา 90% ที่สอง
จากหนังสือของ อ.คูเปอร์ "โรงพยาบาลจิตเวชในมือผู้ป่วย"
ToR ไม่ใช่แค่รายการข้อกำหนด แต่เป็นเอกสาร หากสัญญาควบคุมกระบวนการขององค์กรและความสัมพันธ์ทางการเงิน TOR จะควบคุมกระบวนการพัฒนาและผลลัพธ์สุดท้าย
ในกรณีนี้ ไม่สำคัญว่าไซต์จะพัฒนามากหรือน้อย ปัญหาของความคาดหวังที่ไม่ตรงแนวสามารถเกิดขึ้นได้โดยไม่คำนึงถึงจำนวนเงินที่ใช้ไป เฉพาะผลที่ตามมาอาจแตกต่างกัน
บทความนี้เกี่ยวกับอะไร
บทความนี้เกี่ยวกับสิ่งที่มีประโยชน์ในกระบวนการเขียนข้อกำหนดทางเทคนิคสำหรับเว็บไซต์ รวมถึงสิ่งที่ควรทำอย่างแน่นอน แต่บทความนี้ไม่เกี่ยวกับวิธีการเขียน เอกสารโครงการ. ท้ายที่สุดแล้ว งานหลักของนักออกแบบไม่ใช่การเขียนเอกสารเจ๋งๆ แต่เป็นการออกแบบเว็บไซต์ เอกสารที่ดีเป็นเพียงภาพสะท้อนของแนวทางและความเคารพต่อผู้เข้าร่วมทุกคนในการพัฒนา
ฉันจะเพิ่มข้อจำกัดบางอย่าง
เมื่อใดก็ตามที่ฉันพูดถึงการเขียนข้อกำหนดทางเทคนิค ฉันหมายถึงวิธีการพัฒนาน้ำตก ในกรณีของตัวเลือกอื่นๆ (เช่น การเขียนโปรแกรมขั้นสูง) เอกสารอื่นๆ จะถูกร่างขึ้นและมักจะเป็นไปตามหลักการอื่นๆ นี่คือหนึ่ง
มันคุ้มค่าที่จะแยก TK สำหรับไซต์ขนาดเล็กและขนาดใหญ่ นี่คือสอง ความแตกต่างระหว่างโครงการขนาดเล็กและขนาดใหญ่ไม่ได้อยู่ในปริมาณของเอกสารที่ส่งออก แต่อยู่ในขั้นตอนการพัฒนา หากคุณมีเพียง 4 คนในทีมโครงการ ทุกคนรู้จักกันมานานแล้ว เราถือว่าไม่มีพิธีการ หาก "แผนก" หลายแห่งมีส่วนร่วมในการพัฒนา และทีมโครงการประกอบด้วยพนักงานมากกว่า 10 คน (ถึงไม่สิ้นสุด) มีเพียงกระบวนการเท่านั้นที่สามารถจัดการฝูงชนนี้ได้ กระบวนการนี้ทำให้เกิดพิธีการ และพิธีการจะทิ้งร่องรอยไว้ในรูปแบบเอกสาร
ในความเป็นจริง ความหนาของเอกสารขึ้นอยู่กับความซับซ้อนของกระบวนการมากกว่าขนาดของโครงการ
เราจะไปตามทางที่ยากที่สุด
ทีเคตอบคำถาม
TK ถูกสร้างขึ้นครั้งแรกสำหรับผู้เข้าร่วมการพัฒนาหลายคน:
- ผู้พัฒนาโครงการ (นักออกแบบและโปรแกรมเมอร์)
- ผู้จัดการโครงการ.
- ลูกค้า.
- ข้าราชการ (อาจไม่มีส่วนร่วมในโครงการ แต่ควรนับรวมด้วย)
เมื่อมองย้อนกลับไปที่กลุ่มผู้เข้าร่วมข้างต้น อาจสันนิษฐานได้ว่า TOR ควรตอบคำถามของพวกเขาก่อน ตามหลักการแล้ว เอกสารก่อนโครงการทั้งหมดในวิธีการเรียงซ้อนจะถูกสร้างขึ้นในลักษณะที่จะลบคำถามในกระบวนการพัฒนา
แล้วทีเคตอบคำถามอะไร?
เว็บไซต์สำหรับใครและทำไม?
ไซต์ถูกสร้างขึ้นสำหรับลูกค้าและสำหรับลูกค้าของเขา เหล่านี้คือผู้ใช้ที่จัดตั้งขึ้นของโครงการในอนาคต
ตัวเลือกที่ดีที่สุดคือถ้าในเงื่อนไขการอ้างอิง คุณอธิบายถึงผู้ใช้ทั้งหมดของไซต์ ทั้งภายในและภายนอก คำอธิบายนี้อาจรวมถึงการตลาด ข้อมูลประชากร ข้อมูลโซเชียล เป้าหมายและวัตถุประสงค์ของผู้มีโอกาสเป็นผู้ใช้ ข้อกำหนดสำหรับไซต์ในอนาคต
งานของลูกค้าและผู้ใช้จะได้รับการแก้ไขอย่างไร?
ที่จริงแล้ว หากคุณไม่ตอบคำถามนี้ การเขียนข้อกำหนดทางเทคนิคก็สามารถถือเป็นเอกสารได้ นี่เป็นคำถามพื้นฐานและสำคัญ สามารถอุทิศบทความแยกต่างหากได้ดังนั้นเราจะไม่พูดถึงรายละเอียดในตอนนี้
โครงการจะถูกสร้างขึ้นอย่างไร?
ดังที่ฉันได้เขียนไว้ข้างต้น บางครั้ง TOR (หรืออาจเป็นเอกสารแยกต่างหาก) จะอธิบายขั้นตอนการพัฒนาโครงการ สิ่งนี้จำเป็นอย่างยิ่งหากเราพิจารณาว่าไซต์สามารถพัฒนาได้ตามวิธีการพัฒนาที่แตกต่างจากวิธีการพัฒนาที่ใช้ในบริษัท ซึ่งตามกฎแล้วไม่ได้อธิบายไว้ในเอกสารใดๆ คุณสามารถทรมานตัวเองด้วยความฝันถึงมาตรฐาน ISO ได้นานเท่าที่คุณต้องการ แต่จะแสดงให้ลูกค้าที่พิถีพิถันดูอย่างไร?
จากข้อมูลของ GOST ระบุว่ามี "ขั้นตอนการพัฒนาระบบ" แยกต่างหาก ในส่วนนี้ คุณไม่สามารถอธิบายกระบวนการอย่างละเอียดมากเกินไปและติดตั้งเหตุการณ์สำคัญได้
ผลลัพธ์จะเป็นอย่างไร
TK เริ่มพัฒนาและยุติการพัฒนา
ตามหลักการแล้ว คุณควรอ่านทุกประเด็นของ TOR ร่วมกับลูกค้า ตรวจสอบกับระบบที่ได้รับ และหลังจากนั้นหนึ่งสัปดาห์ให้พูดว่า: "อืม ทุกอย่างดูเหมือนจะเสร็จเรียบร้อยแล้ว”
“TOR เป็นวิธีการตรวจสอบงานที่ดำเนินการ” - วลีดังกล่าวเขียนขึ้นในการแนะนำ TK ของฉันหลายตัว
สิ่งที่จำเป็นสำหรับการเปิดตัวโครงการต่อไป?
นี่เป็นคำถามที่ลูกค้าควรได้รับคำตอบในทางที่ดี นี่เป็นการให้คำปรึกษาแล้ว แต่ในบางกรณีจะต้องดำเนินการในขั้นตอนการออกแบบ จำเป็นต้องวางแผนจำนวนงาน ซอฟต์แวร์และฮาร์ดแวร์ที่จำเป็น ฯลฯ
TK ประกอบด้วยอะไรบ้าง?
ฉันได้ไป ตลอดทั้งชั่วโมงในการตัดสินใจ: อธิบายองค์ประกอบของ TK ในรูปแบบของโครงสร้างที่ชัดเจนเฉพาะหรือเพียงแค่พูดถึงสิ่งที่ควรมี เมื่อมองย้อนกลับไปที่ TOR ทั้งหมดของฉัน ฉันได้ข้อสรุปว่าโครงสร้างของเอกสารนี้มีการเปลี่ยนแปลงบ่อยครั้งขึ้นอยู่กับปัจจัยหลายประการที่บ่งชี้อย่างชัดเจนว่าโครงสร้างนั้นเปรียบเสมือนคำแนะนำที่ไม่ถูกต้องในการเลือกชุดสูท ลองนึกภาพว่ามีคนบอกให้ใส่อะไรไปงานราตรีโดยไม่รู้ด้วยซ้ำว่าคุณจะไปไหน
ข้อมูลทั่วไป
ส่วนแรกของ ToR ประกอบด้วยบทนำและ ข้อมูลทั่วไปเกี่ยวกับเอกสารและโครงการโดยรวม บทนำควรเขียนเพียงครั้งเดียวและตลอดชีวิต ตามกฎแล้ววลีนามธรรมดังกล่าวเขียนไว้ที่นั่นว่าในแต่ละโครงการใหม่จำเป็นต้องแก้ไขคำสองสามคำเท่านั้น
ข้อมูลทั่วไปรวมถึง:
- ข้อมูลเกี่ยวกับลูกค้าและนักแสดง
อย่าลืมระบุผู้รับผิดชอบในแต่ละด้าน มีการระบุเอกสารบนพื้นฐานของการพัฒนา ตามกฎแล้วเอกสารดังกล่าวเป็นสัญญา สถานะของเอกสารปัจจุบันและความเป็นส่วนตัว - การกำหนดโครงการ
ระบุ: ผลิตภัณฑ์ที่ได้จะใช้สำหรับอะไร - เป้าหมายของการสร้างและงานที่ทรัพยากรต้องแก้ไข
ในแง่หนึ่ง นี่เป็นส่วนที่ค่อนข้างสั้น แต่ในแง่ของความสำคัญของการทำอย่างละเอียด หากเป้าหมายและวัตถุประสงค์ไม่ชัดเจนและไม่สามารถวัดผลได้ การปฏิบัติตามเป้าหมายนั้นค่อนข้างยาก - คำอธิบายของผู้ชมโครงการ
ข้อมูลสำคัญในการพัฒนาเว็บไซต์ที่ดีและถูกต้อง เป็นที่ชัดเจนว่าข้อมูลเกี่ยวกับผู้ชมไม่เพียง แต่จำเป็นต้องรวบรวมอย่างถูกต้องเท่านั้น แต่ยังมีความสำคัญยิ่งกว่าเพื่อให้สามารถใช้ข้อมูลนี้ได้
คำอธิบายของผู้ชมไม่ควรมีเพียงข้อมูลที่นักการตลาดชื่นชอบมาก (ข้อมูลประชากร ความต้องการ การแบ่งกลุ่ม ฯลฯ) แต่ยังรวมถึงข้อมูลที่จะเป็นประโยชน์ต่อนักออกแบบและนักวางแผนด้วย: ผู้ใช้แก้ปัญหาอะไร เป้าหมายของเขาคืออะไร ทำงานกับไซต์สิ่งที่ดึงดูด อลัน คูเปอร์แนะนำให้อธิบายผู้ชมของไซต์ว่าไม่ใช่กลุ่มคนจำนวนมากที่ไร้ใบหน้า แต่ให้แยกแยะตัวละครออก เพื่ออธิบายภาพรวมของบุคคลที่เฉพาะเจาะจง - ข้อกำหนดและคำจำกัดความ.
ในเอกสารขนาดใหญ่ คุณจะสามารถใช้คำศัพท์และสำนวนสแลงจำนวนมากที่นักการตลาดหรือผู้บริหารระดับสูงไม่ค่อยเข้าใจ พวกเขาสามารถอ่านเอกสารนี้ได้ ดังนั้นจึงควรจัดเตรียมรายการคำจำกัดความสำหรับพวกเขา ฉันไม่ได้ยกยอตัวเองด้วยความหวังว่ารายการนี้ได้รับการอ่านอย่างน้อยหนึ่งครั้งในชีวิต แต่ฉันสามารถอ้างถึงได้เสมอ
ส่วนทั่วไปเบื้องต้นของเอกสารประกอบด้วยข้อมูลเกี่ยวกับสิ่งที่เราเริ่มต้นเมื่อออกแบบ แน่นอนในกระบวนการซักถามผู้เชี่ยวชาญของลูกค้า ข้อมูลจะสะสมมากขึ้นเป็นลำดับ แต่ไม่มีใครสนใจที่จะอ่าน
ข้อมูลนี้ถูกรวบรวมเป็นส่วนหนึ่งของโครงการ
ขอบเขตโครงการ
หากคุณย้ายออกจากบ้านของคุณและหันกลับไปมองจากระยะไกลคุณจะไม่สามารถแยกแยะรายละเอียดของโครงสร้างได้ คุณสามารถนับจำนวนหน้าต่างได้ แต่คุณไม่สามารถแยกแยะได้ว่าพวกเขาทำจากวัสดุอะไร คุณสามารถชื่นชมสถาปัตยกรรมได้ (แน่นอน คุณไม่สามารถ "ชื่นชม" บ้านทุกหลังได้) แต่คุณสามารถคาดเดาได้เฉพาะหลักการของหน้าต่างเท่านั้น การก่อสร้าง คุณจะไม่สามารถมองเห็นด้านในของอพาร์ทเมนท์หรือคำที่เขียนไว้บนประตูทางเข้า
ขอบเขตของโครงการใกล้เคียงกัน หลังจากอ่านบทนี้แล้ว ทุกคนควรจินตนาการถึงสิ่งที่จะได้รับในกระบวนการพัฒนา แต่ไม่ต้องลงรายละเอียดเลย คุณเขียนว่า "การลงทะเบียนผู้ใช้" จะทำงานบนเว็บไซต์ แต่ไม่ได้เขียนว่าจะทำงานอย่างไรหรือผู้ใช้จะต้องกรอกข้อมูลในฟิลด์ใด
ระดับกรอบของการออกแบบไม่ว่าในกรณีใด ๆ จะต้องผ่านโครงการใด ๆ ดังนั้นการเขียนลงไปจะไม่ฟุ่มเฟือย นอกจากนี้หัวหน้าใหญ่ทั้งในส่วนของผู้พัฒนาและลูกค้าไม่ชอบอ่านเป็นเวลานาน แต่พวกเขาชอบที่จะรับรู้ทุกสิ่งที่เกิดขึ้น ควรเขียนส่วนนี้สำหรับพวกเขาเช่นกัน
ขอบเขตโครงการเขียนขึ้นในรูปแบบของสถานการณ์สำหรับวิธีที่ผู้ใช้โต้ตอบกับไซต์ และอธิบายการทำงานโดยรวมและการโต้ตอบกับอินเทอร์เฟซ
สถาปัตยกรรมข้อมูลและอินเทอร์เฟซ
ส่วนที่อุทิศให้กับสถาปัตยกรรมข้อมูล (IA) ของไซต์ไม่ได้มาตรฐานตามมาตรฐานใด ๆ ที่เป็นที่รู้จัก (ผู้เขียนยังไม่คุ้นเคยกับมาตรฐานดังกล่าว) แต่ใครก็ตามที่พัฒนาเว็บไซต์จะเข้าใจว่า IA เกือบจะเป็นสิ่งสำคัญที่คุณต้องรู้ในการพัฒนาเว็บไซต์ IAs จะกำหนดลักษณะของไซต์และทำงานร่วมกับผู้ใช้
ในการอธิบาย IA คุณจะต้องอธิบายจากบนลงล่าง:
- โครงสร้างเว็บไซต์ นี่คือสิ่งที่เรียกว่าต้นแบบระดับสูง
- เทมเพลตหน้า ต้นแบบระดับต่ำที่อธิบายอินเทอร์เฟซของไซต์โดยตรง
- คำอธิบายเนื้อหา คำอธิบายแบบตารางของเนื้อหาในแต่ละหน้าของไซต์
โครงสร้างเว็บไซต์
แผนผังเว็บไซต์จัดทำขึ้นในรูปแบบกราฟิกโดยใช้หนึ่งในสัญลักษณ์ที่รู้จักกันดี ได้แก่ Visio หรือ Garrett ฉันแนะนำให้คุณวาดแผนผังเว็บไซต์ เพราะในกรณีนี้โครงสร้างที่ได้จะมองเห็นได้ชัดเจนที่สุดและสะดวกในการใช้งานต่อไป ในแง่หนึ่ง อาจดูเหมือนว่าการเขียนแผนผังเว็บไซต์ในรูปแบบของรายการจะง่ายกว่ามาก แต่เมื่อคุณนึกถึงความเชื่อมโยงระหว่างส่วนต่าง ๆ ของเว็บไซต์ คุณจะเริ่มวาดสี่เหลี่ยมบนกระดาษโดยไม่รู้ตัว .
บทความทั้งหมดเขียนขึ้นเกี่ยวกับวิธีที่คุณสามารถวาดโครงสร้างไซต์โดยใช้สัญลักษณ์โดยใช้ Visio ดังนั้นเราจะไม่พูดถึงเรื่องนี้ บทความนี้เขียนเป็นภาษาอังกฤษ แต่คุณสามารถใช้งานได้ง่าย
อย่าลืมกำหนดหมายเลขให้กับแต่ละหน้าแผนผังเว็บไซต์ สิ่งนี้จะต้องใช้ในขั้นตอนคำอธิบายเนื้อหา
เคล็ดลับที่เป็นประโยชน์เมื่อวาดแผนผังเว็บไซต์:
- อย่าละทิ้งสถานที่ พยายามจัดบล็อกให้แยกออกจากกัน สิ่งนี้จะช่วยให้สามารถอ่านแผนที่ได้ง่ายขึ้น
- อย่าหดตัว โดยหลักการแล้วสามารถอ่านข้อความที่พิมพ์เป็น 4 ขนาดได้ แต่นี่เป็นเหตุผลของความเกลียดชังอยู่แล้ว
- จัดแนว "สี่เหลี่ยม" ของหน้าให้สัมพันธ์กันโดยเรียงเป็นแถว สิ่งนี้จะปรับปรุงการรับรู้ของระดับการซ้อนหน้า
- อย่าข้ามเส้น พยายามหลีกเลี่ยงจุดตัดกันของสายสื่อสารจำนวนมาก หากตัดกันจะต้อง "กระโดด" ทับกัน ผู้ที่มีส่วนร่วมในการวาดไดอะแกรมการทำงานที่มหาวิทยาลัยจะเข้าใจฉัน
- เซ็นชื่อในบัตร เซ็นชื่อในการ์ดเช่นเดียวกับแต่ละบล็อก สิ่งนี้จะทำให้สับสนน้อยลงในภายหลัง
- บันทึกไฟล์บ่อยๆ ซ้ำซาก แต่คุณต้องจำสิ่งนี้ไว้ ไม่จำเป็นต้องระลึกถึงญาติของผู้พัฒนาโปรแกรม Visio อีกครั้งในความเป็นจริงพวกเขาไม่ต้องตำหนิอะไรเลย
ฉันมักจะวางแผนผังเว็บไซต์ในส่วนแอปพลิเคชัน ตามกฎแล้วมีขนาดใหญ่มากจนไม่สมจริงที่จะวางไว้ตรงกลาง TK
เทมเพลตหน้า
ในระดับแผนผังไซต์ แต่ละหน้าจะแสดงให้เราเห็นว่าเป็นเพียง “สี่เหลี่ยมจัตุรัส” บนแผ่นกระดาษ สำหรับนักออกแบบ นักออกแบบเลย์เอาต์ และโปรแกรมเมอร์ การพัฒนาเว็บไซต์นั้นไม่เพียงพอ คุณต้องทราบการมีอยู่และตำแหน่งของบล็อกข้อมูลและฟังก์ชันในหน้าของไซต์ด้วย ดังนั้นเราจึงไปยังเทมเพลตไซต์ ตามหลักการแล้ว แต่ละช่องควรมีรายละเอียดตามเค้าโครงของแต่ละหน้า นี่คือการสร้างต้นแบบเว็บไซต์ การใช้การสร้างต้นแบบขึ้นอยู่กับรูปแบบการทำงานที่เป็นที่ยอมรับใน บริษัท พัฒนา แต่ควรตระหนักว่าสิ่งนี้มีราคาแพงมากสำหรับลูกค้า
เพื่อลดความซับซ้อน มีเทมเพลตอินเทอร์เฟซไซต์จำนวนหนึ่งที่อธิบายไว้หลังแผนผังไซต์
คำอธิบายของเทมเพลตประกอบด้วย 3 ส่วน:
- รายการเทมเพลต มีการระบุประเภทหลักของเพจและอธิบายการใช้งาน
- แม่แบบทั่วไป บล็อกหลัก มีการอธิบายบล็อกหลักของเพจเพื่อลดการซ้ำซ้อนของข้อมูล
- คำอธิบายของแต่ละเทมเพลตตามรายการ เทมเพลตถูกวาดในแพ็คเกจกราฟิกใดๆ (Adobe Illustrator, Adobe InDesign, MS Visio ฯลฯ) จากนั้นเสริมด้วยคำอธิบายสั้นๆ
การจอง: เทมเพลตอินเทอร์เฟซของไซต์ไม่ควรสับสนกับเทมเพลตในระบบซอฟต์แวร์ที่ไซต์จะทำงาน เทมเพลตอินเทอร์เฟซอธิบายจำนวนหน้ามาตรฐานที่เพียงพอสำหรับการออกแบบไซต์
ตัวอย่างสเปรดจาก TOR พร้อมคำอธิบายของเทมเพลตอินเทอร์เฟซ (ไวร์เฟรม)คำอธิบายเนื้อหา
ส่วนที่ยาวที่สุดและน่าเบื่อที่สุดของงาน คำอธิบายของเนื้อหาควรรวมถึงรายการของทุกหน้าของไซต์ที่มีการระบุข้อความ รูปภาพ ฯลฯ ที่วางไว้ในแต่ละหน้าอย่างชัดเจน นอกจากนี้ยังระบุว่าเทมเพลตใดที่ใช้สำหรับหน้านี้ (ดูด้านบน) ฉันแนะนำให้ใช้สเปรดชีตสำหรับสิ่งนี้
เป็นไปไม่ได้เสมอไปในขณะที่เขียน TOR เพื่อทราบอย่างแน่นอนว่าเนื้อหาใดในเว็บไซต์: จำนวนหน้าข้อมูลที่แน่นอน การจัดวางข้อมูลกราฟิก ดังนั้นอย่าคิดว่าใน ส่วนนี้คำอธิบายที่ถูกต้องที่สุดจะได้รับ บ่อยครั้งไม่เป็นเช่นนั้น แต่ถ้าคุณอธิบายเนื้อหาที่จำเป็นในขั้นตอนนี้ ผู้จัดการโครงการจะสามารถจัดทำแผนการจัดส่งเนื้อหาและประเมินจำนวนข้อมูลนี้ที่จะรวมอยู่ในไซต์ได้ ลูกค้าจะมีรายการสิ่งที่ต้องเตรียมและแก้ไขต่อหน้าต่อตาเสมอ
คำอธิบายเนื้อหาที่ดีเป็นกุญแจสำคัญในการวางแผนงานในขั้นตอนของการเปิดตัวไซต์และการป้อนข้อมูล
การทำงาน
คำอธิบายเกี่ยวกับฟังก์ชันการทำงานของไซต์ในเงื่อนไขการอ้างอิงเป็นหนึ่งในส่วนสำคัญ โดยเฉพาะอย่างยิ่งสำหรับไซต์ที่มีซอฟต์แวร์จำนวนมาก เช่น อีคอมเมิร์ซ บริการออนไลน์ เป็นต้น
GOST เป็นตัวอย่างที่ดีของคำอธิบายการทำงาน ฉันขอแนะนำให้ปฏิบัติตามมาตรฐานเมื่ออธิบายถึงฟังก์ชันการทำงานของโปรแกรมที่พัฒนาขึ้นภายในเฟรมเวิร์กของไซต์ ควรอธิบาย: ระบบทั่วไป, การทำงานทั่วไปของระบบย่อยและโมดูล , ความสัมพันธ์ระหว่างระบบย่อยและโมดูลระหว่างกัน และสุดท้าย การแจงนับฟังก์ชันทั้งหมดของโมดูลที่มีมากหรือน้อย คำอธิบายโดยละเอียดการทำงานของพวกเขา. สำหรับแต่ละโมดูล จะต้องอธิบายวัตถุที่สร้างหรือใช้ในโปรแกรม
คุณยังสามารถอธิบายโครงสร้างของฐานข้อมูล อัลกอริทึมการทำงานเบื้องต้น แต่เงื่อนไขการอ้างอิงนั้นไม่ต้องการสิ่งนี้ ตาม GOST ควรอธิบายรายละเอียดดังกล่าวในเอกสารเพิ่มเติม: แบบร่างและการออกแบบทางเทคนิค
บางครั้งในการพัฒนาไซต์ขนาดใหญ่ คุณต้องนั่งเป็นเวลานานเพื่ออธิบายการทำงานทั้งหมดของส่วนภายนอกและภายในของไซต์ นักพัฒนาบางคนไม่เห็นด้วยกับรายละเอียดดังกล่าว พวกเขาเชื่อว่าควรอธิบายฟังก์ชันการทำงานอย่างผิวเผินเพื่อให้ "ลูกค้าเข้าใจ" ไร้สาระสิ้นดี! จากประสบการณ์ฉันสามารถพูดได้ว่าไม่มีรายละเอียดที่ไม่จำเป็น ในกรณีที่เกิดปัญหาในโครงการ ผู้จัดการโครงการทั้งสองฝั่งจะกลายเป็นผู้เสพจดหมายที่หายาก! พวกเขาพิสูจน์อักษร TK ขึ้นๆ ลงๆ เพื่อพยายามพิสูจน์กรณีของตน ดังนั้น หากฟังก์ชันการทำงานใน TOR สะกดออกมาในลักษณะทั่วไป ลูกค้าจะยังคงบังคับให้เขาทำในสิ่งที่ต้องการ
ความต้องการ
ควรมีส่วนที่แยกต่างหากสำหรับข้อกำหนดสำหรับโครงการหรือโครงการเพื่อสิ่งแวดล้อม ข้อกำหนดที่สามารถอธิบายได้ในเงื่อนไขการอ้างอิงสำหรับไซต์:
- ข้อกำหนดทางเทคนิคสำหรับระบบ
- ข้อกำหนดสำหรับบุคลากร
- ข้อกำหนดด้านความน่าเชื่อถือ
- ข้อกำหนดสำหรับการยศาสตร์และความสวยงามทางเทคนิค
- ข้อกำหนดสำหรับการปกป้องข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาต
- ข้อกำหนดเพื่อความปลอดภัยของข้อมูลในกรณีที่เกิดอุบัติเหตุ
- ข้อกำหนดเกี่ยวกับประเภทของหลักประกัน
- ข้อกำหนดของซอฟต์แวร์
- ข้อกำหนดสำหรับการสนับสนุนข้อมูล
- ข้อกำหนดสำหรับวิธีการทางเทคนิค
อาจมีข้อกำหนดเฉพาะหลายประการ
ข้อกำหนดทั้งหมดจะต้องมีการกำหนดอย่างชัดเจนและพยายามไม่ลืมสิ่งใดจากด้านการพัฒนาโครงการของคุณ
แน่นอนว่าในโครงการขนาดเล็กไม่จำเป็นต้องเขียนข้อกำหนดทั้งหมดข้างต้น ตัวอย่างเช่น บ่อยครั้งไม่มีพนักงานบนเว็บไซต์ ดังนั้นส่วนดังกล่าวจึงถูกข้ามไป
อื่น
ในกระบวนการจัดการโครงการ คุณอาจสังเกตเห็นว่าสถานการณ์เกิดขึ้นนอกเหนือขอบเขตของข้อกำหนดในการอ้างอิง บางทีคุณอาจพลาดบางสิ่งไป หรือมีสถานการณ์ฉุกเฉินเกิดขึ้นโดยที่คุณคาดไม่ถึงมาก่อน ทั้งหมดนี้จะช่วยให้คุณพัฒนาเอกสารต่อไป นำข้อมูลใหม่ๆ มาให้ ซึ่งจะช่วยให้คุณใช้ในการสื่อสารกับลูกค้าและแก้ไขปัญหาได้
อะไรต่อไป?
TOR ถูกร่างขึ้น ลงนามและเข้าทำงาน อะไรต่อไป? การทำงานกับเขาจบลงในขั้นตอนนี้หรือไม่? เลขที่
โครงการไม่ได้เป็นไปตามเส้นทางที่วางแผนไว้ล่วงหน้าเสมอไป เราพยายามปรับปรุง เปลี่ยนแปลง ความต้องการของลูกค้ามักจะเปลี่ยนแปลง ข้อกำหนดในการอ้างอิงเป็นเอกสาร ไม่ใช่แท็บเล็ต เนื่องจากข้อกำหนดสำหรับการเปลี่ยนแปลงโครงการ เงื่อนไขการอ้างอิงควรเปลี่ยนแปลงด้วย โดยปกติจะทำกับเอกสารเพิ่มเติมพร้อมรายการการเปลี่ยนแปลง โดยธรรมชาติแล้วพวกมันจะถูกรวบรวมเฉพาะในกรณีที่จำเป็นจริง ๆ เท่านั้น ในทางปฏิบัตินั้นหายาก
นอกจากนี้คุณควรเตรียมพร้อมว่าในกระบวนการศึกษาข้อกำหนดทางเทคนิคอย่างลึกซึ้งผู้เข้าร่วมการพัฒนาทั้งหมดจะพบข้อผิดพลาดในกระบวนการทำงานในโครงการ จำนวนข้อผิดพลาดในเอกสารขนาดใหญ่เป็นสัดส่วนโดยตรงกับความยาวและแปรผกผันกับเวลาที่ใช้ในการเขียน เพราะ ขาดเวลาไปเรื่อย ๆ คาดว่าจะมีข้อผิดพลาดใน TOR เกิดขึ้น
ในส่วนที่แห้ง
ฉันเขียนบทความนี้เมื่อกว่าปีที่แล้ว เวลาผ่านไปค่อนข้างนานและในช่วงเวลานี้ฉันไม่ได้เขียน TK ขนาดใหญ่แม้แต่ตัวเดียว แต่เมื่ออ่านข้อมูลที่นำเสนออีกครั้งฉันเห็นด้วยกับทุกสิ่งที่เขียนที่นี่ ดังนั้น TK ที่ดีสำหรับไซต์ควรประกอบด้วย:
- ข้อมูลทั่วไปเกี่ยวกับเอกสารและผู้แต่ง
- เป้าหมายและวัตถุประสงค์ของเว็บไซต์
- คำอธิบายของผู้ใช้ไซต์ เป้าหมายและวัตถุประสงค์ของพวกเขา
- ขอบเขตโครงการ
- สถาปัตยกรรมข้อมูล (IA) ของเว็บไซต์: แผนผังเว็บไซต์ เทมเพลต คำอธิบายอินเทอร์เฟซ
- คำอธิบายเนื้อหาของไซต์
- คำอธิบายการทำงานของเว็บไซต์
- คำอธิบายของกระบวนการและเหตุการณ์สำคัญ หากจำเป็น
- รายการข้อกำหนดทุกประเภทเมื่อพัฒนาไซต์และตรวจสอบงานที่ได้รับ
หวังว่าข้อมูลจะเป็นประโยชน์ต่อผู้อ่านในวงกว้าง
ลิงค์ที่มีประโยชน์
- GOST 34.602-89
ยูริ ชิลยาเยฟ
Yuri Shilyaev, มินสค์. นักออกแบบเว็บไซต์ ที่ปรึกษา ผู้อำนวยการสำนักงาน Minsk of Arts Internet Solutions