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


12

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

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

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

ฉันยังสังเกตเห็นว่าเจ้านายของฉันกำลังวิจารณ์เกือบทุกอย่าง แม้แต่ข้อเสนอแนะที่ยึดตามของเขาเอง ...


1
ตามการบรรยาย SICP เริ่มเขียนโค้ดใน LISP :)
งาน

@Job - LISP ถูกออกแบบมาสำหรับเวิร์กโฟลว์นี้หรือไม่ ;)
Jimbo

เสียงกระเพื่อม (แต่จริง ๆ แล้วฉันอยากจะแนะนำ Clojure) อนุญาตให้หนึ่งในการเปลี่ยนแปลงที่รุนแรงในการออกแบบ เมื่อใช้อย่างถูกต้องจะช่วยให้สร้างเลเยอร์ตามเลเยอร์ของสิ่งที่เป็นนามธรรมและเปลี่ยนใจเพิ่มคุณสมบัติ ฯลฯpaulgraham.com/avg.html
งาน

คำตอบ:


12

สร้างต้นแบบ

เพียงเริ่มวาดหน้าจอที่ไม่ทำอะไรเลยในตอนแรก (สมมุติว่าคุณมีเพียงพอที่จะทำเช่นนั้น?)

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

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


เสียงนี้คุ้นเคยจริงๆ: 'a framework' อาจเป็นไปได้ว่าฉันควรรอให้สิ่งต่าง ๆ กลายเป็นหินหลังจากแสดงตัวอย่างอย่างน้อยสองหรือสามตัวอย่าง
Jimbo

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

4

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

สำหรับ 1,2 และ 3 คุณสามารถทำได้เล็กน้อยหากคุณไม่ใช่คนอาวุโส อย่างไรก็ตามสิ่งต่อไปนี้สามารถทำได้:

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

B - เตรียมการอ้างอิงบางอย่างเกี่ยวกับความสำคัญของข้อกำหนดเพื่อความสำเร็จของโครงการซอฟต์แวร์

C - เตรียมเขา 1 หน้าของสิ่งที่เป็นและไม่ Agile

D - เตรียมรายการอินพุตทั่วไปให้กับสเตจการออกแบบและโน้มน้าวเขาถึงค่าของแต่ละรายการ

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

F - ดูว่านักพัฒนาคนอื่นคิดอย่างไรกับผู้ชายคนนี้

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

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

น่าเสียดายที่บางคนไม่ยอมรับคำแนะนำ ดังนั้นระวังว่าคุณสื่อสารกับเขาอย่างไร

มันจะไม่เป็นไปด้วยดี!

โชคดี.


ขอบคุณสำหรับคำตอบที่ไม่ต้องเสียเงิน! ตำแหน่งปัจจุบันของฉันอยู่ระหว่างจูเนียร์และอาวุโสอย่างน้อยนั่นก็เป็นวิธีที่ฉันอธิบายตัวเองในช่วง A: เขาไม่มีใครไม่สนใจในเชิงลึกเชิงประจักษ์ B, C: ไม่ใช่ตอนนี้ ;-) อย่างน้อยเกี่ยวกับโครงการปัจจุบันเขารู้มากเกี่ยวกับวันการแก้ปัญหาวัน E เป็นความคิดที่ดี วันนี้ฉันเขียนตัวอย่างเล็ก ๆ เราคุยกันเยอะมากวันนี้ แม้ว่าฉันจะประหลาดใจเกี่ยวกับจำนวนคะแนนที่เขาไม่พอใจ คุณช่วยอธิบายสิ่งที่คุณหมายถึงด้วย D ได้ไหม
Jimbo

การออกแบบต้องใช้อินพุต ตัวอย่างเช่นตัวแบบข้อมูล (สร้างขึ้นที่การวิเคราะห์), กฎเกณฑ์ทางธุรกิจ, ข้อกำหนดด้านความปลอดภัย, กรณีการใช้งาน, สถาปัตยกรรมที่จำเป็น (มันคือเว็บ, แบบฟอร์ม windows หรืออะไร) อินพุตแตกต่างกันไปตามชื่อ mehtodology อย่างไรก็ตามพวกเขาทั้งหมดนำไปสู่การทำให้นักพัฒนาตระหนักถึงสิ่งที่การออกแบบควรเป็นเช่นนั้น
NoChance

4

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

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

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

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


3

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

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


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

3

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


2

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

และแน่นอนให้แน่ใจว่าเขาคิดว่ามันเป็นความคิดของเขา / เธอ (โดยเฉพาะเมื่อทุกอย่างผิดพลาด!)


เมื่อวิศวกรซอฟต์แวร์เปลี่ยนวิศวกรสังคมออนไลน์ .. :)
MattDavey

1
ปัญหาซอฟต์แวร์ส่วนใหญ่แก้ไขได้อย่างจริงจังการสื่อสารกับถุงน้ำแบบกึ่ง ๆ อื่น ๆ ซึ่งมักเป็นปัญหาเล็กน้อย ...
NWS

1

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

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

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


0

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

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