ผู้พัฒนาควรโต้แย้งคุณสมบัติที่ไม่จำเป็นหรือเป็นอันตรายหรือไม่?


32

อะไรคือทัศนคติที่ดีจากนักพัฒนาเมื่อพูดคุยเกี่ยวกับคุณสมบัติใหม่และคือคุณสมบัติที่ไม่สำคัญ / น่าสงสัย?

สมมติว่าคุณกำลังพัฒนาภาษาจาวาบางอย่างเช่นภาษาและเจ้านายพูดว่า: "เราต้องการตัวชี้เพื่อให้นักพัฒนาซอฟต์แวร์สามารถทำเรื่องกับหน่วยความจำวัตถุได้โดยตรง!"

นักพัฒนาควรลดระดับความคิดลงเพราะเพิ่มความซับซ้อนและช่องโหว่ด้านความปลอดภัยที่คาดเดาไม่ได้หรือไม่หรือเขาควรทำอะไรถาม

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

อะไรคือการกระจาย "สามารถทำได้" ที่ดีที่สุดกับ "ไม่สามารถทำได้" สำหรับโปรแกรมเมอร์ปกติ

แก้ไข: คำถามไม่เกี่ยวกับเจ้านายที่ไม่ดี: D

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

ทัศนคติทั่วไปควรเป็น:

  1. ใช่เราจะทำมันไขความซับซ้อน
  2. อาจจะ
  3. ไม่การทำใหม่ทั่วไปและความหมายไม่ได้แสดงถึงการเปลี่ยนแปลง

สิ่งที่ควรเป็นปฏิกิริยาของนักพัฒนาที่ดี?


1
"หลักการของสถาปัตยกรรม" - หลักการใดที่? ตัวอย่างนี้แย่มากฉันจะเอามันออกไปจากคำถามของคุณ
Jeremy

@ Jeremy: ถูกต้องฉันไม่ใช่เจ้าของภาษาคงที่
Coder

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

คำตอบ:


26

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

หากเจ้านายของคุณยังไม่เห็นด้วยคุณก็ทำทุกอย่างที่ทำได้: คุณได้รับทีมและผู้จัดการของคุณมารวมกันและครอบคลุมข้อดีข้อเสียและแม้ว่าเจ้านายของคุณจะเลือกวิธีการที่ด้อยกว่า

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

นี่เป็นสถานการณ์ที่อ่อนโยนที่เกี่ยวข้องกับการเมืองการทำงาน แต่สามารถจัดการได้อย่างเป็นกันเอง


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

4
หากเจ้านายของคุณมีความอาฆาตแค้นที่จะจัดการกับคุณว่าคุณมีทางออกที่ดีกว่าคุณควรเขียนจดหมายลาออกพร้อมสำเนาสำหรับผู้ร่วมงานของคุณที่ระบุว่าคุณเลิกและทำไม เป็นความจริงที่บางครั้งผู้จัดการที่ไม่ดีได้รับการเลื่อนตำแหน่ง แต่การทำงานภายใต้เมื่อคุณมีวิธีการอื่นจะทำให้ปัญหาหมดไป
Jeff Welling

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

1
@Jeff Welling และฉันไม่เห็นด้วยกับคุณเกี่ยวกับการลงคะแนนด้วยเท้าของคุณ :) และฉันเห็นด้วยกับคำตอบนี้ในรูปแบบที่ถูกแก้ไขมากกว่าต้นฉบับ แต่ฉันคิดว่ามันเป็นคำตอบที่แตกต่างกันในตอนนี้
PeterAllenWebb

1
@ PeterAllenWebb ฉันเห็นสิ่งที่คุณพูด (สำหรับสิ่งที่คุ้มค่าฉันแก้ไขคำตอบที่อาจทำให้การอภิปรายนี้พิจารณา) แต่ในความคิดของฉันถ้าเป็นกลุ่มรวมถึงเจ้านายของคุณคุณครอบคลุมข้อดีและข้อเสียและเจ้านายเลือกทางออกที่ด้อยกว่าอย่างชัดเจน เขา / เธอควรได้รับการเรียกร้องจากมัน ผมเข้าใจความต้องการที่พบบ่อยผู้จัดการต้องปรับสัญญาณรบกวนที่ไม่เห็นด้วยเห็น แต่ฉันนี้ดูเหมือนว่ากรณีของผู้จัดการไม่อยากจะยอมรับว่าเขาเป็นคนผิด - ข้อบกพร่องในการใด ๆผู้จัดการ IMO
Jeff Welling

14

หากหัวหน้าของคุณบอกให้คุณทำสิ่งที่โง่คุณควร (กรุณา) อธิบายว่าทำไมมันถึงโง่

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


ไม่มีปัญหากับเจ้านายมันเกี่ยวกับคุณสมบัติที่มีส่วนที่ซ่อนอยู่ของภูเขาน้ำแข็ง
Coder

3
@Coder: ในกรณีนี้คุณต้องทำให้ผู้บริหารทราบว่าจะต้องทำการวิเคราะห์ก่อนที่คุณจะสามารถเริ่มพัฒนาได้
FrustratedWithFormsDesigner

1
ฉันเห็นด้วยกับ FrustratedWormFormsDesigner คำขอเวลาวิเคราะห์นั้นมักจะสมเหตุสมผลและมักจะเพียงพอที่จะรับคุณลักษณะที่ส่งไปยังเครื่องเขียนสำรองยกเว้นว่าจำเป็นจริงๆ
PeterAllenWebb

9

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

หากคุณสมบัติที่ถูกขอให้ละเมิดหลักการหลักบางประการของแอปพลิเคชัน (เช่น "เพิ่มปุ่มสีน้ำเงิน!" ไปยัง UI ที่ระบุไว้และออกแบบมาให้มีปุ่มสีแดงตามคำขอของลูกค้าเท่านั้น) ฉันคิดว่ามันใช้ได้ ถาม "ทำไม" และพูดถึงว่ามันขัดกับการออกแบบที่สร้างไว้แล้ว

ในท้ายที่สุดเกือบทุกอย่างคือ "สามารถทำได้" (อาจไม่ยากจากมุมมองทางเทคนิคในการเพิ่มปุ่มสีแดงไปยัง UI สีฟ้าเท่านั้น) มันเป็นคำถามที่มากกว่า "ควรทำอย่างไร"


ในการตอบคำถามที่แก้ไขของคุณฉันคิดว่าคำตอบควรเป็น # 2 "อาจ" รอการตรวจสอบและวิเคราะห์เพิ่มเติม

คุณไม่ต้องการที่จะตอบ # 1 "ใช่โดยไม่มีเงื่อนไข" เพราะคุณอาจติดอยู่กับสิ่งที่คุณไม่สามารถส่งมอบในเวลาที่กำหนด

คุณไม่ต้องการที่จะตอบ # 3 "ไม่มันทำงานมากเกินไป" เพราะดูเหมือนว่าคุณจะไม่ร่วมมือและยากโดยไม่จำเป็น


6

จากมุมมองของนักพัฒนา: อย่าบอกใครเลยว่าต้องจ่ายค่าใช้จ่ายที่พวกเขาไม่มีในสิ่งที่พวกเขาต้องการ คุณอาจบอกพวกเขาว่าพวกเขาไม่สามารถซื้อได้ในราคานั้นหรือว่าพวกเขาไม่สามารถมีวิธีที่พวกเขาคิดมาตั้งแต่แรก

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

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

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

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


นี่เป็นคำตอบที่ดีมาก น่าเสียดายที่ฉันเห็นว่าการยอมรับคุณสมบัติบางอย่างจะนำไปสู่รหัสที่ไม่ปลอดภัย - "ไม่มีการตรวจสอบข้อผิดพลาด", "กรณีมุมไม่ได้รับการจัดการ" ฯลฯ และเมื่อคุณสมบัติดังกล่าวได้รับการยอมรับขั้นตอนต่อไปคือ จ่ายสำหรับพวกเขา
Coder

3
ฉันไม่เห็นด้วยอย่างสมบูรณ์ นักพัฒนาที่ให้สิ่งที่คนต้องการมากกว่าสิ่งที่พวกเขาต้องการ (หรือความเสียหายของพวกเขาที่ได้รับในสิ่งที่พวกเขาต้องการ) เป็นนักพัฒนาที่น่ากลัว
David Schwartz

2
@David Schwartz - มีการพยายามกำหนดสิ่งที่ต้องการและสิ่งที่พวกเขาต้องการ คุณไม่สามารถบอกลูกค้าของคุณได้ว่าพวกเขาไม่มีอะไรเพราะมันอาจทำให้เกิดปัญหาที่แน่นอนที่สุดที่สามารถเข้ารหัสได้
Ramhound

10
99 ครั้งจาก 100 มีธุรกิจที่ต้องการความต้องการตามที่ระบุไว้เสมอ คุณต้องค้นหาและพบกับสิ่งที่ต้องการเสมอแม้ว่าจะไม่ได้พบในรูปแบบที่แน่นอนของความต้องการ และคุณไม่สามารถบอกพวกเขาอย่างตรงไปตรงมาได้ว่าสิ่งที่พวกเขาต้องการไม่สามารถทำได้เพราะพวกเขาจะได้ยินว่าคุณไม่สามารถให้สิ่งที่พวกเขาต้องการ นั่นคือสิ่งที่พวกเขาจ่ายเงินให้คุณเพื่อให้และพวกเขาสามารถตัดคุณได้อย่างง่ายดายและให้รหัสแก่คนอื่นที่จะให้สิ่งที่พวกเขาต้องการจดหมายและตำหนิปัญหาใด ๆ กับการทำงานของคุณ .
KeithS

2
@ KeithS: แน่นอน! ขอบคุณที่บอกว่ามันดีกว่าที่ฉันจะทำได้
David Schwartz

5

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

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

ยิ่งคุณแสดงให้เห็นถึงความสามารถในอดีตที่ผ่านมายิ่งคุณมีเวลามากขึ้นที่จะต้องประกาศคุณสมบัติเป็นความคิดที่ไม่ดี ที่สามารถมาพร้อมกับเวลาและบันทึกการประสบความสำเร็จ ที่กล่าวว่าคุณควรแสดงความกระตือรือร้นเสมอเพื่อตอบสนองคำขอเนื่องจากเป็นสิ่งที่ลูกค้าของคุณต้องการ คุณควรแสดงการจองตามประสบการณ์ของคุณและเมื่อคุณมีแล้วมันจะกลายเป็นปัญหาที่ไม่ใช่ปัญหาใน 90% ของกรณีเพราะคุณจะเริ่มการสนทนาที่เป็นต้นเหตุของปัญหาซึ่งก็คือ: ทำไมพวกเขาขอให้คุณเพิ่ม สถานที่นี้ในสถานที่แรก? ถึงตอนนี้คุณสามารถเสนอทางเลือกหรืออาจยอมรับว่าถึงแม้ว่าคุณลักษณะที่ร้องขอจะแนะนำปัญหา แต่ก็ยังจำเป็น

แน่นอนว่าเป็นไปได้ว่าคุณผิด วิศวกรรมซอฟต์แวร์ไม่สนุกใช่ไหม


3

เนื่องจากคำถามนั้นค่อนข้างคลุมเครือฉันจะพูดคุยกับฉันเล็กน้อย

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

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


2

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

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

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

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


2

ขอโทษนะ แต่คำถามนี้ฟังดูเหมือนผู้เยาว์ที่ขอคำแนะนำจากพ่อ หากเป็นกรณีนี้ผู้พัฒนาที่ดีจะต้องยอมรับบัญญัติเหล่านี้:

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

2

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

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

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

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

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

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


1

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

ในกรณีนี้ฉันขอแนะนำกลยุทธ์ลดความเสี่ยง ภาพที่คุณกำลังพิจารณาที่จะเพิ่ม WCF / บริการเว็บใน API ของคุณซึ่งอาจยอดเยี่ยมหรือซับซ้อนมากโดยไม่มีรางวัล:

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

1

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

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

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

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


1

ปัญหาที่ฉันเห็นคือการใช้คำโต้แย้งของคุณ

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

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

หากไม่เป็นเช่นนั้นอาจเป็นเวลาที่ดีที่จะประมวลผลให้พวกเขา!


1
  1. ตระหนักว่าคุณไม่รู้ทุกอย่างและไม่สามารถทำทุกอย่างได้

  2. หากคุณแน่ใจว่าเป็นความคิดที่ไม่ดีให้พูดสิ่งที่ไม่ดี

  3. หากพวกเขาพยายามที่จะผลักดันคุณพูดอย่างใดอย่างหนึ่ง - ต้องการเวลามากขึ้นในการวิเคราะห์ถ้าคุณต้องการเวลามากขึ้นหรือบอกว่าเราไม่ได้พบทางออกที่ดีในการแก้ไขปัญหานี้

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


0

ในสถานการณ์ที่เหมาะคุณจะต้องมี Lead Developer ที่ทำการตัดสินใจขั้นสุดท้ายทางด้านเทคนิคและ Business Lead ที่จะทำการตัดสินใจขั้นสุดท้ายในด้านธุรกิจ คำถามนี้จะตอบคำถามหลักสองข้อ:

1) อะไร ลูกค้าต้องการอะไร

2) ได้อย่างไร เราจะทำสิ่งนี้ได้อย่างไรจากมุมมองของเทคโนโลยี

สิ่งที่ลูกค้าต้องการคือผู้มีอำนาจตัดสินใจสูงสุดเนื่องจากเป็นผู้ตัดสินใจชำระเงิน


0

ในฐานะนักพัฒนาคุณไม่ควรสนใจว่าจะต้องใช้ข้อกำหนดใดบ้าง

อย่างไรก็ตามคุณควรอธิบายว่ามีบางสิ่งที่ไม่สมจริงและมีวิธีที่ดีกว่าหรือไม่


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

@Attila คุณเข้าใจผิด "ไม่ดำเนินการเกี่ยวกับโครงการ" และ "ไม่ดำเนินการว่าผู้จัดการโครงการร้องขอคุณลักษณะนี้หรือไม่" เป็นสิ่งที่แตกต่าง
BЈовић

0

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


0

นี่เป็นงานประจำวันสำหรับฉันและที่จริงฉันดีใจที่เป็น

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

แน่นอนว่ามันรุนแรงเมื่อทุกคนต้องการฟีเจอร์ X และคุณท้ายบอกว่า "มันอาจจะไม่ดี" แต่สุดท้ายแล้วทุกคนพยายามทำให้แอปพลิเคชันที่ปลอดภัยมั่นคงและเสถียร (บำรุงรักษาได้ยืดหยุ่น ฯลฯ ... ) และทุกเสียงควรนับ

ตอบคำถามของคุณไม่ใช่ส่วนหนึ่งของงานของนักพัฒนา (ซึ่งก็คือการพัฒนา) แต่มันเป็น "พิเศษ" ที่ให้คุณภาพและการทำงานเป็นทีม


0

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

อย่างไรก็ตามหากอำนาจที่ตัดสินใจว่าจะเพิ่มคุณสมบัติใหม่คุณควรทำงานให้ดีที่สุดเท่าที่จะทำได้ มันเป็นความท้าทาย

และหากคุณสมบัติใหม่นั้นโง่เกินไปหรือสภาพแวดล้อมการทำงานที่เสแสร้งเกินไปก็ถึงเวลาที่จะหางานใหม่

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