ต้องกำหนดวัตถุประสงค์สำหรับนักพัฒนาแม้ว่าวัตถุประสงค์จะไม่ได้ผล [ปิด]


84

เป็นที่ยอมรับกันโดยทั่วไปว่าการกำหนดวัตถุประสงค์ที่วัดผลได้สำหรับนักพัฒนาซอฟต์แวร์นั้นไม่ได้ผลเนื่องจากการให้ความสำคัญกับวัตถุประสงค์มากเกินไปอาจนำไปสู่พฤติกรรมที่สวนทางกับเป้าหมายขององค์กร (เรียกว่า " ความผิดปกติของการวัด ")

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

  1. กำหนดวัตถุประสงค์ที่วัดผลได้ซึ่งเพิ่มเติมจากงานปกติเช่น "ทำการฝึกอบรมเกี่ยวกับเทคโนโลยี X" "สร้างเอกสารสำหรับโค้ด Y ที่ไม่มีใครเข้าใจ" และอื่น ๆ เมื่อพูดถึงการประเมินผลงานประจำปีนักพัฒนาไม่ได้ให้คะแนนตามวัตถุประสงค์ที่เขียนไว้ แต่เป็นความเห็นของฉันเกี่ยวกับมูลค่าที่วัดไม่ได้ของงานปกติของพวกเขาเนื่องจากนั่นคือสิ่งที่ บริษัท ให้ความสำคัญ
  2. กำหนดวัตถุประสงค์ที่เฉพาะเจาะจงเช่น "วัน" งานที่ทำตามที่บันทึกไว้โดยระบบจัดการงาน "" จำนวนข้อบกพร่องที่นำมาใช้ "" จำนวนการผลิตที่เกิด " สิ่งนี้นำไปสู่การประมาณการที่สูงเกินจริงและการจัดประเภทข้อบกพร่องที่ไม่ถูกต้องเพื่อให้ได้ "คะแนน" ที่ดีขึ้น สิ่งที่น่าสนใจคือแม้แต่นักพัฒนาที่ทำคะแนนสูงในระบบนี้ก็ไม่ชอบเนื่องจากความไว้วางใจภายในทีมได้รับความเสียหายและพวกเขาไม่ได้รู้สึกว่าพวกเขาสมควรได้รับตำแหน่งสูงเสมอไป
  3. กำหนดวัตถุประสงค์ที่คลุมเครือซึ่งเป็นตัวแปรในหัวข้อ "ทำงานปกติให้ดี" เมื่อพูดถึงการประเมินผลประจำปีการให้คะแนนของพวกเขาจะสะท้อนถึงการปฏิบัติตามวัตถุประสงค์ แต่วัตถุประสงค์นั้นไม่สามารถวัดผลได้หรือบรรลุได้ซึ่งถูกมองข้ามไป

สิ่งเหล่านี้ไม่เหมาะ หากคุณเคยอยู่ในสถานการณ์คล้าย ๆ กันที่ต้องสร้างวัตถุประสงค์ที่มีความหมายและสามารถวัดผลได้สำหรับนักพัฒนาซอฟต์แวร์ทั้งๆที่มีหลักฐานยืนยันประสิทธิภาพของพวกเขาแนวทางใดที่เหมาะกับคุณที่สุด


คำถามที่เกี่ยวข้องฉันพบว่าไม่ค่อยตรงประเด็น:


อัปเดต (18 พฤศจิกายน 2552): มีการโหวตเพิ่มคะแนนสำหรับคำถามของฉัน 10 ครั้งและคำตอบที่ได้รับคะแนนสูงสุดมีเพียง 4 คะแนนโหวต (รวมถึงการโหวตจากฉันด้วย) ผมคิดว่านี่บอกเราบางสิ่งบางอย่างบางทีที่โจเอลและคนอื่น ๆ ที่มีสิทธิและภูมิปัญญารวมของ StackOverflow ไม่สามารถเกิดขึ้นกับใด ๆที่น่าสนใจวัดวัตถุประสงค์สำหรับนักพัฒนาที่ไม่สามารถ gamed โดยไม่ส่งผลกระทบต่อความจริง (unmeasurable) ค่าของพวกเขา งาน. ขอบคุณที่พยายาม!


16
ฉันชอบวิธีการ DUMB: "Do Ur Most Best"
Robert S.

3
ลิงก์เสียจำนวนมาก
crh225

ลิงค์เสีย
Rodrigo Leite

คำตอบ:


21

แนวทางใดได้ผลดีที่สุดสำหรับคุณ

วัตถุประสงค์เดียวเท่านั้น: ผ่านการตรวจสอบโค้ด / การตรวจสอบโดยเพื่อนโดยมีฉันเป็นผู้ตรวจสอบโดยที่ฉันไม่พบข้อบกพร่องหรือมีคำวิจารณ์อื่นใดฉันจึงขอให้คุณทำซ้ำ

หมายเหตุ:

  • ฉันไม่ได้วัดความสามารถในการจ้างงานใหม่ให้เสร็จเร็วและไม่สนับสนุนให้ทำ: ฉันต้องการให้คนอื่นเรียนรู้วิธีการทำงานให้เสร็จสมบูรณ์ (เพราะถ้ายังไม่เสร็จดีก็จะไม่เสร็จ)
  • ผู้คนได้เรียนรู้สิ่งที่ฉันมองหาในการตรวจสอบโค้ดดังนั้นจึงเป็นโอกาสในการเรียนรู้และมาตรการควบคุมคุณภาพไม่ใช่แค่วัตถุประสงค์ในการจัดการเท่านั้น
  • ความคิดเห็นของฉันจะมีสองประเภท:
    1. นี่คือข้อบกพร่องคุณต้องแก้ไขก่อนที่จะเช็คอิน
    2. ตามข้อเสนอแนะฉันจะทำเช่นนั้นและเช่นนั้น
  • หลังจากนั้นไม่นานบทวิจารณ์ของฉันเกี่ยวกับรหัสของบุคคลหนึ่งจะหยุดค้นหารายการที่ "ต้องแก้ไข" ใด ๆ (ณ จุดนี้ฉันไม่จำเป็นต้องตรวจทานงานของพวกเขาอีกต่อไป)

ขอบคุณฉันชอบสิ่งนี้ เมื่อฉันตรวจสอบโค้ดของพวกเขาฉันมักจะค่อนข้างกังวลเกี่ยวกับสิ่งที่ไม่เร่งด่วน แต่ในระยะยาวเช่นการตั้งชื่อตัวแปรและรูปแบบรหัส วัตถุประสงค์เช่นนี้อาจกระตุ้นให้พวกเขาคิดตามแนวของฉันได้เร็วขึ้น!
Paul Stephenson

6
ฉันชอบสิ่งนี้เช่นกัน แต่มันอาจนำไปสู่รูปแบบการพัฒนาที่ไม่ชัดเจนซึ่งทุกคนพยายามทำให้คุณพอใจด้วยค่าใช้จ่ายที่เป็นไปได้ของรหัสที่ดีที่สุดอย่างเป็นกลาง คุณแก้ไขข้อผิดพลาดในแนวทางของตัวเองกี่ครั้งในช่วงหลายปีที่ผ่านมาคุณคาดว่าจะยังคงถูกรีดออกไปอีกกี่ข้อ?
Ed Guiness

1
สำหรับฉันการตั้งชื่อตัวแปรและรูปแบบรหัสอยู่ในประเภทที่ 2 ยกเว้นว่าสไตล์นั้นไม่ดีจริงๆเช่นการนำตัวแปรตัวเดียวมาใช้ซ้ำเพื่อจุดประสงค์ที่แตกต่างกันมากเกินไปฉันอาจบอกว่า "คุณจะต้องทำใหม่เพราะมันซับซ้อนเกินไปสำหรับฉันที่จะตรวจสอบฉันไม่เห็น 'โดยการตรวจสอบ' ว่าถูกต้องหรือไม่" .
ChrisW

เห็นได้ชัดว่าฉันรู้ว่าอะไรคือสิ่งที่ดีที่สุด :-) แต่ใช่พวกเขาอาจใช้เวลาสร้างความพอใจให้กับนิสัยแปลก ๆ ของฉันแทนที่จะทำสิ่งที่มีประโยชน์มากกว่า ฉันคิดว่ามันจะทำงานได้ดีสำหรับนักพัฒนารุ่นใหม่มากกว่ามือเก่าที่ช่ำชอง
Paul Stephenson

@edg: นั่นเป็นเรื่องจริงเกี่ยวกับ "ตำหนิ" และ "พยายามทำให้ฉันพอใจ" แต่รหัสของพวกเขาก็ต้องผ่านการทดสอบระบบกล่องดำของ QA ด้วยเช่นกัน และการตัดสินของฉันว่าฉันสามารถรักษารหัสของพวกเขาได้หรือไม่หากจำเป็นนั้นเป็นการวัดที่มีวัตถุประสงค์ (ไม่ใช่แค่เชิงอัตวิสัย) ใช่หรือไม่?
ChrisW

14

โดยส่วนตัวแล้วฉันพยายามตั้งวัตถุประสงค์สองประเภท:

  • วัตถุประสงค์ที่มุ่งเน้นธุรกิจ (นี่คือเหตุผลที่เราได้รับเงินหลังจากทั้งหมด) ตัวอย่างเช่น "เสร็จสิ้นโครงการ X ภายในวันที่ 1 มิถุนายน 2009") วัตถุประสงค์เหล่านี้มักใช้ร่วมกันกับสมาชิกหลายคนในทีม (และพวกเขาตระหนักถึงสิ่งนี้) ทีมสามารถทำเกินวัตถุประสงค์โดยนำโครงการมาก่อนหรือเกินฟังก์ชันที่จำเป็น บุคคลสามารถทำเกินวัตถุประสงค์ได้โดยการสร้างฟังก์ชันการทำงานที่มากขึ้นการมีข้อบกพร่องน้อยลงหรือการฝึกสอนและสนับสนุนสมาชิกคนอื่น ๆ ในทีม

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

ฉันรู้สึกว่าสิ่งสำคัญคือ:

  • วัตถุประสงค์คือ SMART
  • วัตถุประสงค์สอดคล้องกับความต้องการของธุรกิจ
  • คุณใส่ "งานปกติ" ไว้ในวัตถุประสงค์อันที่จริงแล้วนี่คือวัตถุประสงค์ที่สำคัญที่สุด!
  • พนักงานมีโอกาสบางอย่างที่จะทำเกินวัตถุประสงค์ที่คุณตั้งไว้

สุดท้ายฉันจะอยู่ห่างจากเมตริกซอฟต์แวร์เป็นวัตถุประสงค์ - พวกเขาง่ายเกินไปที่จะเล่นเกมและอาจไม่ให้สิ่งที่คุณต้องการ ฉันจะใช้เฉพาะเมตริกที่ฉันต้องการฝึกสอนใครบางคนให้เข้าหรือออกจากพฤติกรรมเฉพาะ


9

ทั้งหมดนี้ทำให้เกิดความจริงที่ว่า "ผู้บริหารระดับแรก" และฝ่ายบริหารส่วนใหญ่ไม่รู้จักพนักงานของตน แทนที่จะเป็นส่วนหนึ่งของการวางแผนและการพัฒนาแบบวันต่อวันสิ่งต่างๆเช่น SMART จะปรากฏขึ้น หากผู้จัดการต้องใช้เวลากับคนที่ทำงานจริงมากขึ้นก็ไม่จำเป็นต้องทำสิ่งนี้

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


1
โดยพื้นฐานแล้วฉันเป็นหัวหน้าทีมและฉันเป็นส่วนหนึ่งของการวางแผนและพัฒนาแบบวันต่อวัน ฉันยังคิดว่าระดับประสิทธิภาพของนักพัฒนาแต่ละคนนั้น "ชัดเจน" แต่มันเป็นความคิดเห็นส่วนตัวของฉันและไม่สอดคล้องกับวัตถุประสงค์ดังนั้นพวกเขาจึงกลายเป็นสิ่งที่ไม่มีจุดหมาย ฉันควรจะเพิกเฉยต่อพวกเขาทั้งหมด!
Paul Stephenson

ประเด็นคือคุณไม่สามารถวัดผลทางวิทยาศาสตร์ได้ที่นี่ดังนั้นการพยายามทำสิ่งนั้นจึงถึงวาระและคุณควรใช้เวลาอยู่ที่อื่น imo martinfowler.com/bliki/CannotMeasureProductivity.htmlมีเนื้อหาเกี่ยวกับเรื่องนี้
Martin Wickman

8

วัตถุประสงค์ที่วัดได้ที่ฉันเคยเห็น:

  • ผ่านการสอบใบรับรอง
  • ค้นคว้าเทคโนโลยี X และนำเสนอเกี่ยวกับเรื่องนี้
  • จำนวนการสร้างการเปลี่ยนแปลงที่ทำลายที่กระทำ
  • จำนวนบทความวิกิที่เขียนเกี่ยวกับการจัดการความรู้ภายใน

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


1
ทั้งหมดยกเว้นการทำลายงานสร้างคือแนวทางของฉัน 1: สิ่งที่เกิดขึ้นคือนักพัฒนาที่ดีบอกว่า "ฉันยุ่งมากกับการทำโครงการสำคัญที่คุณขอให้ฉันทำดังนั้นฉันจึงไม่ได้ทำการนำเสนอหรือเขียนบทความ" ฉันไม่สามารถลงโทษพวกเขาสำหรับสิ่งนี้ดังนั้นวัตถุประสงค์จึงไร้ความหมาย
Paul Stephenson

1
กับสิ่งที่พอลพูดและฉันมีปัญหากับบางสิ่งที่ไม่จีรังเหมือนการเขียนบทความวิกิ - มันดีไหม? ยังอยู่ไหม แล้วการแก้ไขการมีส่วนร่วมล่ะ พวกเขามีเวลาว่างสำหรับเรื่องนี้หรือไม่?
annakata

8

ต้องกำหนดวัตถุประสงค์สำหรับนักพัฒนาแม้ว่าจะไม่ได้ผลก็ตาม

หากนักพัฒนาของคุณไม่ทำงานบางทีวัตถุประสงค์บางอย่างอาจเป็นเพียงสิ่งที่พวกเขาต้องการเพื่อสร้างแรงจูงใจให้พวกเขา? ;-)


3
+1 สำหรับอารมณ์ขัน: ฉันสงสัยว่ามันคลุมเครือ แต่ตัดสินใจเฉพาะในกรณีที่คุณเข้าใจผิดโดยเจตนา :-)
Paul Stephenson

2
โปรดทราบว่ามีคนเปลี่ยนชื่อเป็น "แม้ว่าพวกเขา (วัตถุประสงค์) จะไม่ได้ผล" ตั้งแต่นั้นมาฉันได้เพิ่มความกระชับให้เหลือเพียงแค่ "แม้ว่าวัตถุประสงค์จะไม่ได้ผล" เพียงแค่เพิ่มความคิดเห็นสำหรับใครก็ตามที่สับสนกับคำตอบนี้!
Paul Stephenson

7

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


1
กำหนด "ออกกำลังกาย" หากคุณเพียงแค่ใช้เครื่องมือการครอบคลุมการรับโค้ดเพื่อดำเนินการโดยไม่ต้องใช้งานจริงก็ทำได้ง่าย
Kent Boogaart

@ เคนท์ฉันหมายถึงการออกกำลังกาย == ดำเนินการ คุณช่วยขยายได้ไหมว่าการดำเนินการไม่ออกกำลังกายและฉันยินดีที่จะอัปเดตคำแนะนำของฉัน
Ed Guiness

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

ขอบคุณสิ่งนี้อาจใช้งานได้เนื่องจากการทดสอบหน่วยจะกลายเป็นส่วนสำคัญในการพัฒนาและการบำรุงรักษา อาจมีปัญหากับคนที่เขียนแบบทดสอบหน่วยที่ไร้ค่าเพื่อให้บรรลุวัตถุประสงค์เมื่อพวกเขาสามารถทำงานที่มีประโยชน์มากขึ้นได้
Paul Stephenson

เห็นด้วยอาจจะมีวิธีการเล่นเกมการวัดที่เฉพาะเจาะจงอยู่เสมอประเภทใดที่ช่วยเสริมจุด OPs
Ed Guiness

4

ฉันคิดว่าการมีเป้าหมายที่เฉพาะเจาะจงล่วงหน้าเช่น SMART (บางทีเราอาจจะทำงานที่เดียวกันก็ได้) ดูเหมือนจะเป็นความคิดที่ดีในทางปฏิบัติ แต่มันไม่ได้เป็นประโยชน์สำหรับทีมส่วนใหญ่

ปัญหาคือการเปลี่ยนแปลงเป้าหมายที่เพิ่มขึ้นของเรา การเปลี่ยนแปลงทางธุรกิจและในฐานะนักพัฒนาเราจำเป็นต้องตอบสนองและตอบสนองอย่างเหมาะสมและในกรอบเวลาที่เหมาะสม

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


3

เรามีเมตริกจำนวนมากที่รวบรวมเมื่อโปรแกรมเมอร์ทำงานเช่น:

  • จำนวน SLOC ที่เปลี่ยนแปลง / เพิ่ม
  • จำนวนข้อผิดพลาด / ข้อบกพร่องที่ฉีดเข้าไปในขั้นตอนต่างๆของกระบวนการ (ในระหว่างการตรวจสอบโดยเพื่อนการตรวจสอบโดยเพื่อนโพสต์การเผยแพร่)
  • เปลี่ยนคำขอที่ตอบสนอง / ปฏิเสธ
  • เอกสารที่เป็นทางการ (คำอธิบายเวอร์ชันซอฟต์แวร์เอกสารการออกแบบ ฯลฯ )

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

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

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


2

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

เช่นหากมีการริเริ่มของแผนกเพื่อลดจำนวนตั๋วที่มีปัญหาคุณสามารถตั้งเป้าหมายของแต่ละบุคคลตามจำนวนตั๋วที่เกี่ยวข้องกับซอฟต์แวร์ที่พวกเขาดูแล

เนื่องจากการพัฒนาซอฟต์แวร์เป็นเรื่องที่ต้องใช้ความร่วมมือกันอย่างมากดังนั้นการตั้งเป้าหมายในระดับทีมจึงเหมาะสมกว่าและจากนั้นให้คะแนนบุคคลตามการมีส่วนร่วมของพวกเขาต่อทีม


1
+1 สำหรับการตั้งเป้าหมายในระดับทีมเท่านั้น การตรึงทิคเก็ตปัญหาไว้ที่ตัวบุคคลเป็นการลดการกระตุ้นทำลายสปิริตของทีมและมักจะทำให้การวัดสถานการณ์ที่แท้จริงผิดเพี้ยนและไม่ถูกต้องโดยเฉพาะอย่างยิ่งหากจำนวนตั๋วปัญหาที่เป็นไปได้ค่อนข้างต่ำ (เช่นประมาณหนึ่งคนต่อผู้พัฒนา)
Paul Stephenson

1

วัตถุประสงค์ที่ฉันชอบคือ:

ขอ N ความคิดเห็นเชิงบวกเกี่ยวกับการมีส่วนร่วมของคุณในโครงการจากลูกค้าโครงการ

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


จะเกิดอะไรขึ้นถ้าคุณทำงานทั้งปีในโครงการเดียวที่ยังไม่ได้จัดส่งให้กับลูกค้า? 0 รีวิว จะเป็นอย่างไรหากคุณทำงานบนเว็บไซต์ทั่วไปโดยไม่มีรายชื่อลูกค้า
jmucchiello

1
ในทั้งสองกรณีคุณยังคงทำงานในโครงการที่มีลูกค้าไม่ว่าจะเป็นภายในหรือไม่ก็ตาม คุณกำลังร้องขอให้มีการตรวจสอบการมีส่วนร่วมของคุณกับลูกค้าไม่ใช่การตรวจสอบโครงการ
ณัฐ

1

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

การกำหนดนักพัฒนาที่มีประสิทธิภาพเป็นอีกองค์ประกอบหนึ่งของสิ่งนี้ เป็นคนที่แก้ไขจุดบกพร่องได้ดีที่สุด? ใหม่ทำงานเร็วที่สุด? งานใหม่พร้อมการทดสอบและเอกสารแม้ว่าจะยังไม่เสร็จเร็ว? สิ่งที่คุณเรียกว่ามีประสิทธิภาพ เนื่องจากคำตอบมาตรฐาน"ขึ้นอยู่กับ"ควรได้รับการชี้แจงที่นี่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.