เป็นเรื่องปกติหรือไม่ที่นักพัฒนาซอฟต์แวร์จะแนะนำแนวคิดเกี่ยวกับคุณสมบัติให้กับเจ้าของผลิตภัณฑ์? [ปิด]


16

ฉันเพิ่งเริ่มทำงานในฐานะนักพัฒนาซอฟต์แวร์เมื่อไม่นานมานี้โดยทำงานเป็นผู้ดูแลระบบมาก่อน

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

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

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


15
แน่นอนว่าโปรแกรมเมอร์มักจะรู้หลายสิ่งหลายอย่างที่เจ้าของผลิตภัณฑ์ไม่เคยได้ยินมาก่อน ทำการพัฒนาเว็บไซต์มีบริการ apis ไลบรารีและปลั๊กอินและรายการส่วนต่อประสานผู้ใช้จำนวนเท่าใดก็ได้ เรามักจะทำงานร่วมกับลูกค้าที่ไม่มีความคิดคร่าว ๆ มากกว่าสิ่งที่พวกเขาต้องการทำ แต่ไม่มีความรู้ว่าอะไรคือวิธีการทั่วไปในการนำพวกเขาไปใช้หรือคุณสมบัติเพิ่มเติมที่เป็นไปได้
thorsten müller

1
คุณรู้สึกไม่พอใจหรือมีผลกระทบด้านลบต่อการไม่แนะนำคุณสมบัติหรือไม่? ดูเหมือนว่า บริษัท ของคุณต้องการส่งเสริมการปฏิบัติและไม่ลงโทษผู้ที่ไม่ทำ
JeffO

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

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

คำตอบ:


2

ขึ้นอยู่กับว่าคุณหมายถึงอะไรโดยแนวคิดเรื่องคุณสมบัติ

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

ในระบบที่พัฒนาแล้วผู้พัฒนาอาจแนะนำวิธีแก้ปัญหาที่รู้จักซึ่งอาจทำให้เกิดการซ้ำได้

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


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

1
ดังนั้นคุณกำลังบอกว่าสัญญาณเตือนดังขึ้นเมื่อนักพัฒนานึกถึงความคิดที่ว่าเจ้าของผลิตภัณฑ์ไม่ได้คิด ทำไมมันถึงเป็นสิ่งเลวร้าย
Stefan Billiet

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

47

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

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


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

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

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

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

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

5

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

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

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

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

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

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

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

และถ้าคุณอยู่ในทีมที่มีวิศวกรความต้องการ

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

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

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

สรุป 2: หากมีวิศวกรความต้องการในทีมไปที่พวกเขาด้วยคำแนะนำคุณลักษณะของผลิตภัณฑ์ คุณไม่ต้องการถุงมือกำมะหยี่ในครั้งนี้

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

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

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

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

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

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


+1 นั่นเป็นคำตอบที่ครอบคลุมจริงๆ "การสรุปผลการวิจัย" TL;DRทำงานเป็นดี
James Khoury

4

ใช่มันเป็นเรื่องปกติ

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

ฉันเป็นคนที่เฉยเมยเกินไปฉันควรจะริเริ่มและเริ่มผลักดันแนวคิดไปยังเจ้าของผลิตภัณฑ์หรือไม่?

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


ดูเหมือนว่าที่ Google devs ใช้เวลาส่วนหนึ่งไปกับการเป็นเจ้าของผลิตภัณฑ์
JeffO

พนักงานของ Google ที่ทำงานในโครงการของตัวเองนั้นไม่เหมือนกันเว้นแต่คุณกำลังพูดถึงการริเริ่มอื่น ๆ
Robbie Dee

@RobbieDee ใช่แล้ว พวกเขาทำงานในโครงการของพวกเขา แต่ google ขายบริการที่มาจากโครงการ
BЈовић

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