ฉันทำเองหรือทีมทำ? วิธีอธิบายผลงานของคุณในพอร์ตโฟลิโออย่างตรงไปตรงมา

ผลิตภัณฑ์ แคมเปญ การนำระบบไปใช้ และกระบวนการที่มีคุณค่าส่วนใหญ่เกิดจากการทำงานเป็นทีม

ดังนั้นการแสดงเพียงผลลัพธ์สุดท้ายยังไม่ได้บอกว่า ผู้เชี่ยวชาญคนใดคนหนึ่งมีบทบาทจริงอย่างไร

สำหรับผู้ที่ประเมินพอร์ตโฟลิโอ ความแตกต่างมีนัยสำคัญ:

"ฉันทำงานกับการออกแบบกระบวนการชำระเงินใหม่"

ไม่เหมือนกับ:

"ฉันนำการวิจัย ออกแบบขั้นตอนการชำระเงินใหม่ เตรียมต้นแบบ และทำการทดสอบการใช้งาน ส่วนการพัฒนาใช้งานจริงดำเนินการโดยทีมพัฒนาฝั่งผู้ใช้แยกต่างหาก"

คำอธิบายแบบที่สองช่วยให้ประเมินความสามารถจริงได้โดยไม่ลดทอนผลงานของผู้อื่น.

ปัญหานี้ไม่ได้เกิดขึ้นเฉพาะกับพอร์ตโฟลิโอด้านอาชีพเท่านั้น

ในวงการสิ่งพิมพ์ทางวิชาการ มีตัวอย่างอย่าง CRediT - Contributor Role Taxonomy มาตรฐานนี้อธิบายบทบาทการมีส่วนร่วม 14 ประเภท และถูกพัฒนาขึ้นเพื่อเพิ่มความโปร่งใสว่าใครรับผิดชอบส่วนใดของงานจริง CRediT อนุญาตให้หนึ่งคนมีหลายบทบาท และหนึ่งบทบาทมีหลายคนได้ อีกทั้งแนะนำให้ผู้มีส่วนร่วมสามารถตรวจสอบและยืนยันบทบาทที่ถูกระบุให้ตนเองได้ [1]

CRediT ใช้กับงานวิจัยและสิ่งพิมพ์ทางวิชาการเป็นหลัก ไม่ใช่มาตรฐานสำหรับพอร์ตโฟลิโอด้านอาชีพ อย่างไรก็ตาม แนวคิดสำคัญสามารถใช้ได้กว้างกว่า คือแทนที่จะพูดคลุมเครือว่า "ฉันเป็นส่วนหนึ่งของโครงการ" ควรระบุให้ชัดว่าผลงานจริงของคุณคืออะไร.

คำอธิบายโครงการทีมที่ดีสามารถสร้างจากข้อมูลหกส่วน:

1. บริบทของโครงการ
2. องค์ประกอบและขอบเขตของทีม
3. ความรับผิดชอบของคุณเอง
4. การกระทำและการตัดสินใจที่ชัดเจน
5. ชิ้นงานหรือหลักฐานการทำงาน
6. ผลลัพธ์และวิธีระบุความเชื่อมโยง

เป้าหมายไม่ใช่การเขียนรายงานยาว แต่คือการลดความคลุมเครือที่สำคัญที่สุด.

ก่อนอื่นอธิบายว่า ทีมกำลังทำอะไรอยู่จริง

เพียงระบุโดยย่อ:

• ปัญหาหรือเป้าหมาย,
• ประเภทของผลิตภัณฑ์หรือบริการ,
• ขนาดโดยประมาณ,
• ข้อจำกัดสำคัญ,
• ช่วงเวลาดำเนินงาน หากเกี่ยวข้อง.

ตัวอย่าง:

เป้าหมายของโครงการคือทำให้ขั้นตอนการซื้อในแอป B2B สั้นลง ผลิตภัณฑ์ทำงานในหลายตลาดยุโรปและให้บริการลูกค้าธุรกิจ

ข้อมูลนี้ช่วยให้ผู้อ่านเข้าใจบริบทก่อนประเมินผลงานของแต่ละคน.

ไม่จำเป็นต้องระบุชื่อทุกคน

ในหลายกรณี โครงสร้างแบบนี้ก็เพียงพอ:

ทีม: ผู้จัดการผลิตภัณฑ์ นักออกแบบประสบการณ์ผู้ใช้ นักพัฒนาฝั่งผู้ใช้ 2 คน นักพัฒนาฝั่งเซิร์ฟเวอร์ 2 คน และผู้เชี่ยวชาญด้านคุณภาพ

ข้อมูลเพียงข้อนี้เปลี่ยนวิธีตีความคำอธิบายโครงการทั้งหมด

ผู้อ่านจะเห็นว่าผลลัพธ์ไม่ได้เกิดขึ้นจากคนเดียว และผู้เชี่ยวชาญทำงานอยู่ภายใต้การแบ่งความรับผิดชอบที่ชัดเจน.

นี่คือส่วนที่สำคัญที่สุด

แทนที่จะเขียนกว้าง ๆ ว่า:

"ฉันทำงานฝั่งผู้ใช้"

ให้เขียนให้ชัด:

"ฉันรับผิดชอบสถาปัตยกรรมโมดูลการชำระเงิน การนำกระบวนการชำระเงินไปใช้ การเชื่อมต่อกับ API การชำระเงิน และการตรวจทานโค้ดของการเปลี่ยนแปลงในส่วนนี้"

หากอาจเกิดความเข้าใจผิด ก็ควรบอกด้วยว่าคุณ ไม่ได้ ทำอะไร:

"ส่วนฝั่งเซิร์ฟเวอร์และการเชื่อมต่อผู้ให้บริการชำระเงินฝั่งเซิร์ฟเวอร์ดำเนินการโดยอีกทีมหนึ่ง"

การระบุแบบนี้ไม่ได้ทำให้พอร์ตโฟลิโอดูอ่อนลง แต่ทำให้น่าเชื่อถือขึ้น.

ชื่อตำแหน่งยังไม่ใช่คำอธิบายผลงาน

นักออกแบบประสบการณ์ผู้ใช้ระดับอาวุโส อาจนำกระบวนการวิจัยทั้งหมดในโครงการหนึ่ง แต่ในอีกโครงการอาจทำเฉพาะหน้าจอสุดท้าย

ดังนั้นให้แสดงการกระทำที่เชื่อมโยงกับความสามารถเฉพาะ:

• ฉันออกแบบสถาปัตยกรรมของโซลูชัน,
• ฉันทำการวิจัย,
• ฉันออกแบบลำดับขั้นตอน,
• ฉันวิเคราะห์ข้อมูล,
• ฉันเขียนส่วนสำคัญของการพัฒนา,
• ฉันจัดทำกลยุทธ์แคมเปญ,
• ฉันนำการเจรจา,
• ฉันประสานความเชื่อมโยงระหว่างทีม,
• ฉันตรวจสอบโซลูชันก่อนเปิดใช้.

ตัวอย่างที่มีคุณค่าที่สุดคือกรณีที่คุณสามารถอธิบายได้ด้วยว่า เหตุใดจึงตัดสินใจแบบนั้น.

หากสามารถแสดงโครงการได้ ชิ้นงานจะช่วยเชื่อมโยงคำอธิบายผลงานกับงานจริง

ตัวอย่างเช่น:

• หน้าจอผลิตภัณฑ์,
• ส่วนหนึ่งของอินเทอร์เฟซ,
• ต้นแบบ,
• ส่วนของโค้ด,
• ที่เก็บโค้ดสาธารณะ,
• รายงาน,
• แผนภาพ,
• สิ่งพิมพ์,
• สื่อแคมเปญ,
• ภาพถ่าย,
• เอกสารหรือส่วนที่สามารถเปิดเผยได้อย่างปลอดภัย.

ชิ้นงานไม่จำเป็นต้องพิสูจน์ทุกอย่าง จุดประสงค์คือช่วยให้ผู้อ่านเข้าใจว่า มีการสร้างอะไรจริงและสิ่งนั้นเชื่อมโยงกับผลงานที่อธิบายไว้อย่างไร.

ความเสี่ยงสูงสุดในการขยายบทบาทของตัวเองเกินจริงเกิดขึ้นเมื่ออธิบายผลลัพธ์

หากอัตราการเปลี่ยนเป็นลูกค้าของบริษัทเพิ่มขึ้น 25% หลังโครงการ นั่นไม่ได้หมายความโดยอัตโนมัติว่าคนคนเดียว ทำให้อัตราการเปลี่ยนเป็นลูกค้าเพิ่มขึ้น 25%

ในช่วงเดียวกันอาจมีสิ่งอื่นเปลี่ยนแปลงด้วย:

• ราคา,
• ข้อเสนอ,
• การตลาด,
• ประสบการณ์ผู้ใช้,
• โครงสร้างพื้นฐาน,
• ปัจจัยตามฤดูกาล,
• แหล่งที่มาของผู้เข้าชม,
• งานของสมาชิกทีมคนอื่น.

อธิบายผลลัพธ์ด้วยระดับความแน่นอนเท่าที่คุณสามารถให้เหตุผลรองรับได้จริง.

1. ความรับผิดชอบโดยตรง
"ฉันลดเวลาของกระบวนการนี้จาก 12 นาทีเหลือ 4 นาทีด้วยการทำขั้นตอนที่ฉันรับผิดชอบให้เป็นอัตโนมัติ"

ใช้เมื่อความเชื่อมโยงระหว่างการกระทำของคุณกับผลลัพธ์เป็นโดยตรงและมีเหตุผลรองรับ

2. ผลลัพธ์ร่วมกัน
"เราร่วมกันออกแบบกระบวนการเริ่มต้นใช้งานของผู้ใช้ใหม่ หลังเปิดใช้ อัตราการทำขั้นตอนเสร็จเพิ่มขึ้น 18%"

ใช้เมื่อผลลัพธ์เกิดจากงานของหลายคน

3. ผลงานที่เป็นส่วนหนึ่งของการเปลี่ยนแปลงใหญ่กว่า
"ฉันรับผิดชอบการออกแบบกระบวนการชำระเงินใหม่ซึ่งเป็นส่วนหนึ่งของการปรับปรุงกระบวนการซื้อในภาพรวม หลังเปิดใช้โปรแกรมทั้งหมด บริษัทมีอัตราการเปลี่ยนเป็นลูกค้าเพิ่มขึ้น"

ใช้เมื่อขอบเขตงานของคุณเป็นเพียงหนึ่งในหลายปัจจัย

4. ผลลัพธ์ในฐานะบริบทของโครงการ
"โครงการจบลงด้วยยอดขายเพิ่มขึ้น 40% ขอบเขตงานของฉันครอบคลุมสถาปัตยกรรมฝั่งผู้ใช้และการนำกระบวนการชำระเงินไปใช้"

ใช้เมื่อคุณรู้ผลลัพธ์รวมของโครงการ แต่ไม่มีหลักฐานเพียงพอที่จะระบุว่าส่วนใดเกิดจากงานของคุณ.

เมื่อโครงการมีหลายคน คำอธิบายที่ดีควรตอบคำถามสองข้อพร้อมกัน:

ทีมส่งมอบอะไร?

และ

แต่ละคนรับผิดชอบอะไร?

ตัวอย่าง:

โครงการ: เวอร์ชันแรกของแอปด้านโลจิสติกส์
ทีม: นักออกแบบประสบการณ์ผู้ใช้ นักพัฒนาฝั่งผู้ใช้ นักพัฒนาฝั่งเซิร์ฟเวอร์
ผลลัพธ์ร่วม: เวอร์ชันแรกของผลิตภัณฑ์ที่ใช้งานได้และพร้อมสำหรับการทดลอง
นักออกแบบประสบการณ์ผู้ใช้: การวิจัย เส้นทางผู้ใช้ ต้นแบบ การออกแบบอินเทอร์เฟซ
นักพัฒนาฝั่งผู้ใช้: สถาปัตยกรรมฝั่งผู้ใช้ การพัฒนาเว็บแอป
นักพัฒนาฝั่งเซิร์ฟเวอร์: API แบบจำลองข้อมูล การเชื่อมต่อระบบ

คำอธิบายแบบนี้ช่วยเพิ่มความแข็งแรงให้ทั้งทีมและผู้เชี่ยวชาญแต่ละคน.

ในบางโครงการ คำอธิบายระดับการมีส่วนร่วมแบบง่ายมีประโยชน์:

บทบาทนำ - ฉันนำขอบเขตนี้และรับผิดชอบการตัดสินใจสำคัญ
ความรับผิดชอบร่วม - ฉันแบ่งความรับผิดชอบกับคนอื่นหนึ่งคนหรือมากกว่า
บทบาทสนับสนุน - ฉันสนับสนุนขอบเขตนี้แต่ไม่ใช่ผู้รับผิดชอบหลัก

CRediT ใช้การแบ่งลักษณะคล้ายกันสำหรับบทบาทผู้มีส่วนร่วม [1]

หลักการสำคัญง่ายมาก: ระดับความรับผิดชอบควรเข้าใจได้ชัดเจน.

สำหรับโครงการร่วมที่สำคัญ ควรตรวจสอบว่าคำอธิบายผลงานของคุณไม่ขัดอย่างชัดเจนกับความเข้าใจของผู้ร่วมโครงการคนอื่นเกี่ยวกับบทบาท

CRediT แนะนำให้ผู้มีส่วนร่วมสามารถตรวจสอบและยืนยันบทบาทที่ระบุให้ตนได้ [1]

ในพอร์ตโฟลิโอด้านอาชีพ ไม่จำเป็นต้องมีขั้นตอนอนุมัติอย่างเป็นทางการสำหรับทุกประโยค กฎเชิงปฏิบัติง่ายกว่านั้นคือ: อย่าอ้างความรับผิดชอบในงานที่จริงแล้วมีคนอื่นเป็นผู้นำ.

การอธิบายผลงานของคุณไม่ควรสับสนกับการตัดสินเรื่องลิขสิทธิ์

ตามกฎหมายลิขสิทธิ์ของโปแลนด์ สิทธิ์โดยหลักเป็นของผู้สร้าง และหากมีผู้สร้างร่วมก็ถือร่วมกัน สำหรับผลงานที่สร้างขึ้นภายใต้ความสัมพันธ์การจ้างงาน นายจ้างอาจได้สิทธิ์เชิงเศรษฐกิจในขอบเขตที่กฎหมายและความสัมพันธ์การจ้างงานกำหนด [2]

ในทางปฏิบัติ ควรแยกสามคำถาม:

ฉันมีส่วนในการสร้างโครงการหรือไม่?
ฉันเป็นผู้สร้างหรือผู้สร้างร่วมขององค์ประกอบใดโดยเฉพาะหรือไม่?
ฉันมีสิทธิ์เผยแพร่วัสดุในพอร์ตโฟลิโอหรือไม่?

คำตอบ "ใช่" ต่อคำถามแรกไม่ได้ตัดสินอีกสองข้อโดยอัตโนมัติ.

ไม่ใช่ทุกโครงการจะสามารถนำมาแสดงหรืออธิบายรายละเอียดได้

กฎหมายโปแลนด์เกี่ยวกับการต่อต้านการแข่งขันที่ไม่เป็นธรรมคุ้มครองข้อมูลที่เป็นความลับทางการค้า รวมถึงข้อมูลทางเทคนิค เทคโนโลยี การจัดการองค์กร และข้อมูลอื่นบางประเภทที่มีมูลค่าทางเศรษฐกิจและถูกเก็บเป็นความลับ [3]

ดังนั้นในโครงการลับ การลบเพียงชื่อลูกค้าอาจยังไม่เพียงพอ รายละเอียดอื่นอาจเปิดเผยข้อมูลที่ได้รับการคุ้มครองได้

กฎที่ปลอดภัยกว่าคือ:

อธิบายเฉพาะสิ่งที่คุณมีสิทธิ์เปิดเผยจริงตามกฎหมายที่ใช้บังคับ สัญญา ความยินยอม และสิทธิ์อื่นที่คุณมี.

คำอธิบายโครงการโดยทั่วไปไม่จำเป็นต้องใช้ข้อมูลส่วนตัวของทีมทั้งหมด

GDPR กำหนดหลักการต่าง ๆ รวมถึงความชอบด้วยกฎหมาย การจำกัดวัตถุประสงค์ และการใช้ข้อมูลให้น้อยที่สุด หมายความว่าควรใช้ข้อมูลส่วนบุคคลเฉพาะเท่าที่จำเป็นต่อวัตถุประสงค์นั้น [4]

หากอธิบายทีมเพียงว่า:

นักออกแบบประสบการณ์ผู้ใช้ 1 คน นักพัฒนาฝั่งผู้ใช้ 2 คน นักพัฒนาฝั่งเซิร์ฟเวอร์ 1 คน และผู้เชี่ยวชาญด้านคุณภาพ 1 คน

ก็ไม่มีเหตุผลโดยอัตโนมัติที่จะเผยแพร่ชื่อ รูปภาพ ที่อยู่อีเมล หรือข้อมูลส่วนบุคคลอื่นของเพื่อนร่วมงาน

หากต้องการเผยแพร่คำรับรอง คำพูด รูปภาพ หรือข้อมูลอื่นของบุคคลใดโดยเฉพาะ ให้ตรวจสอบฐานทางกฎหมายที่เหมาะสมและขอบเขตการใช้วัสดุที่ได้รับอนุญาต.

หากเงื่อนไขความร่วมมืออนุญาตให้อธิบายประสบการณ์ในระดับทั่วไป คุณอาจพิจารณาแสดง:

• ประเภทของปัญหาโดยไม่ระบุตัวลูกค้า,
• บทบาทของคุณ,
• หมวดหมู่ความสามารถที่ใช้,
• ประเภทความรับผิดชอบ,
• กระบวนการตัดสินใจในระดับทั่วไปที่เหมาะสม,
• ผลลัพธ์เฉพาะเท่าที่สามารถเปิดเผยได้.

อย่าสร้างภาพหน้าจอ ข้อมูล หรือผลลัพธ์ปลอมเพื่อแทนที่วัสดุที่เป็นความลับ

หากไม่แน่ใจว่าข้อมูลใดสามารถเปิดเผยได้หรือไม่ ปลอดภัยกว่าที่จะยังไม่เผยแพร่จนกว่าจะตรวจสอบให้ชัดเจน.

ความแตกต่างเล็กน้อยของถ้อยคำสามารถสื่อระดับความรับผิดชอบได้อย่างชัดเจน

ฉันรับผิดชอบ... - ระบุขอบเขตของคุณชัดเจน
ฉันเป็นผู้นำ... - แสดงความรับผิดชอบต่อทิศทางหรือการดำเนินงานของขอบเขตหนึ่ง
ฉันร่วมสร้าง... - แสดงว่าผลลัพธ์มีผู้สร้างมากกว่าหนึ่งคน
ฉันสนับสนุน... - อธิบายบทบาทสนับสนุนอย่างตรงไปตรงมา
ฉันเป็นส่วนหนึ่งของทีมที่... - แยกการมีส่วนร่วมส่วนบุคคลออกจากผลลัพธ์รวมของทีม
หลังเปิดใช้โครงการ บริษัทบันทึกว่า... - แสดงผลลัพธ์เป็นบริบทโดยไม่ยกผลทั้งหมดมาเป็นของตนเอง

หลีกเลี่ยงการพูดอัตโนมัติว่า "ฉันทำทั้งหมด" เมื่อขอบเขตจริงเป็นงานร่วมกัน.

1. ใช้ถ้อยคำแบบบุคคลเดียวกับโครงการที่หลายคนร่วมทำ

2. แสดงผลทางธุรกิจแต่ไม่อธิบายขอบเขตงานของตัวเอง

3. นำเทคโนโลยีของผลิตภัณฑ์ทั้งหมดมาเป็นความสามารถของตัวเอง ทั้งที่ไม่ได้ทำงานกับทุกส่วน

4. แสดงการออกแบบภาพสุดท้าย โค้ด หรือกลยุทธ์ โดยไม่บอกว่าส่วนใดเป็นสิ่งที่คุณสร้างจริง

5. ไม่กล่าวถึงผู้มีส่วนร่วมสำคัญในกรณีที่บทบาทของพวกเขาจำเป็นต่อการเข้าใจโครงการ

6. บอกเป็นนัยถึงความสัมพันธ์เชิงเหตุผลระหว่างงานของคุณกับผลลัพธ์ที่คุณไม่สามารถพิสูจน์ได้.

โครงการ
กำลังสร้างอะไรและต้องการแก้ปัญหาอะไร?

ทีม
มีบทบาทใดเข้าร่วมโครงการ?

ความรับผิดชอบของฉัน
ฉันรับผิดชอบส่วนใดโดยตรง?

การกระทำและการตัดสินใจของฉัน
ฉันทำหรือนำอะไรอย่างชัดเจน?

การร่วมงาน
ส่วนใดสร้างร่วมกับคนอื่น?

ชิ้นงาน
ฉันมีสิทธิ์แสดงอะไรตามกฎหมาย?

ผลลัพธ์
โครงการบรรลุอะไรและผลงานของฉันเชื่อมโยงกับผลนั้นอย่างไร?

ข้อจำกัด
มีส่วนใดที่ฉันเปิดเผยไม่ได้เพราะความลับหรือสิทธิ์ของบุคคลอื่นหรือไม่?

ถามตัวเองเจ็ดข้อ:

1. ผู้อ่านรู้หรือไม่ว่าทีมมีขนาดเท่าไร?

2. ชัดเจนหรือไม่ว่าฉันรับผิดชอบอะไรโดยตรง?

3. ฉันหลีกเลี่ยงการนำงานของคนอื่นมาเป็นของตัวเองหรือไม่?

4. ผลลัพธ์ถูกอธิบายด้วยระดับความระมัดระวังที่เหมาะสมหรือไม่?

5. ฉันมีสิทธิ์ตามกฎหมายในการเผยแพร่วัสดุที่ใช้หรือไม่?

6. ฉันหลีกเลี่ยงการเปิดเผยข้อมูลส่วนบุคคลหรือข้อมูลลับที่ไม่จำเป็นหรือไม่?

7. คนภายนอกสามารถดูจากคำอธิบายนี้แล้วเข้าใจได้หรือไม่ว่าฉันใช้ความสามารถใดจริง?

หากคำตอบชัดเจน คำอธิบายโครงการจะเริ่มทำหน้าที่เป็นหลักฐานของความสามารถ ไม่ใช่เพียงเรื่องเล่าที่น่าสนใจ.

คำอธิบายโครงการที่ดีที่สุดไม่จำเป็นต้องเลือกระหว่าง:

"ฉันทำสิ่งนี้"

กับ

"ทีมทำสิ่งนี้"

สามารถแสดงความจริงทั้งสองอย่างพร้อมกันได้:

ทีมส่งมอบผลลัพธ์ที่ชัดเจน และฉันรับผิดชอบส่วนที่เฉพาะเจาะจง การตัดสินใจ และการดำเนินงาน

ความแม่นยำระดับนี้ช่วยให้ประเมินผู้เชี่ยวชาญได้โดยไม่ลดคุณค่าผลงานของผู้อื่น.

พอร์ตโฟลิโอไม่ควรเป็นการแข่งขันเพื่อสร้างคำกล่าวอ้างที่ใหญ่ที่สุด

คุณค่าจะเพิ่มขึ้นเมื่อผู้ดูสามารถเข้าใจว่า:

สร้างอะไรขึ้นมา ใครทำงานกับมัน คุณรับผิดชอบอะไร คุณทำอะไรด้วยตัวเอง และผลลัพธ์ใดที่สามารถเชื่อมโยงกับผลงานของคุณได้อย่างสมเหตุสมผล

คำอธิบายที่แม่นยำไม่ได้ทำให้ความสำเร็จดูน้อยลง

ตรงกันข้าม มันแสดงว่าคุณเข้าใจความรับผิดชอบของตัวเอง ทำงานร่วมกับคนอื่นได้ และนำเสนอผลลัพธ์ของงานอย่างตรงไปตรงมา.

[1] CRediT - Contributor Role Taxonomy, NISO
เปิดแหล่งข้อมูล

[2] กฎหมายโปแลนด์ว่าด้วยลิขสิทธิ์และสิทธิ์ที่เกี่ยวข้อง - มาตรา 8-12, ELI
เปิดแหล่งข้อมูล

[3] กฎหมายโปแลนด์ว่าด้วยการต่อต้านการแข่งขันที่ไม่เป็นธรรม - มาตรา 11, ข้อความรวมที่เผยแพร่ในปี 2026
เปิดแหล่งข้อมูล

[4] ระเบียบ (EU) 2016/679 - GDPR, มาตรา 5, EUR-Lex
เปิดแหล่งข้อมูล

หมายเหตุด้านวิธีการ: CRediT เป็นมาตรฐานสำหรับบทบาทผู้มีส่วนร่วมในงานวิจัยและสิ่งพิมพ์ทางวิชาการ บทความนี้ใช้เป็นตัวอย่างของการระบุผลงานอย่างโปร่งใส แต่ไม่ได้เสนอว่าเป็นมาตรฐานสำหรับพอร์ตโฟลิโอด้านอาชีพ องค์ประกอบหกข้อของคำอธิบายโครงการและสี่วิธีในการอธิบายความสัมพันธ์กับผลลัพธ์เป็นโมเดลเชิงบรรณาธิการที่เสนอในเนื้อหานี้.