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


14

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

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

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

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

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

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

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

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

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

ขอบคุณมากสำหรับทุกความคิดเห็นและเวลาของคุณ


เปลี่ยนงานหรือไม่ ...
Robert Harvey

1
ความคิดเห็นเกี่ยวกับกระจกหลายอย่างนั้นเป็นจริงในประสบการณ์ของฉัน
Telastyn

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

4
คุณรู้หรือไม่ว่าลูกบอลโคลนขนาดใหญ่ใช้งานได้จริงใช่ไหม
เดนิสเดอ Bernardy

คำตอบ:


18

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

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

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

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

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

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

4
คำแนะนำที่ใช้งานได้บ่อยครั้งที่ devs คิดในแง่ของ codebase เท่านั้นไม่ใช่ในแง่ของธุรกิจและพลาดภาพใหญ่ ๆ ที่ประกอบขึ้นเป็นสิ่งที่เราทำและทำไมเราถึงทำ
gbjbaanb

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

10

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

ในกรณีที่คุณเลือกที่จะไม่ออกจาก บริษัท (บรรทัดแรกของคำถามที่ให้ไป):

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

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

สิ่งที่เลวร้ายที่สุดที่อาจเกิดขึ้นคือคุณกำลังมองหางานใหม่ซึ่งคุณควรทำอยู่ดี


2
ขออภัยฉันต้องลงคะแนนเพราะ OP บอกว่าเขาไม่ได้มองหาคำแนะนำตามสายของ "หางานใหม่"
KChaloux

4
@KChaloux - ขอบคุณสำหรับความคิดเห็น คำตอบส่วนใหญ่ของฉันไม่ได้ "มองหางานใหม่" แต่ฉันรู้สึกว่าการออกบิตนั้นอาจเป็นการก่อความเสียหายและทำให้เกิดคำตอบที่ไม่สมบูรณ์
Dan Pichelman

9

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

Investopedia (ลิงค์ที่สอง) อาจมีราคาที่ดีที่สุดในกรณีนี้

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

ดังที่คุณบันทึกไว้มีบางอย่างที่พลิกคว่ำที่จะอยู่ในโครงการเงินสดวัว

  • มันมีเสถียรภาพ
  • รับประกันระดับใหม่ของการพัฒนาเล็กน้อย
  • มีการแก้ไขข้อผิดพลาดอยู่เสมอเพื่อแก้ไขปัญหา

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

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

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

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

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

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


2
+1, ฉันเคยเห็น บริษัท ที่ทำงานในโหมดนี้มานานกว่าทศวรรษ เมื่อพวกเขามีความเฉื่อยบางอย่างพวกเขาจะวิ่งเป็นเวลานานนาน
GrandmasterB

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

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

5

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

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

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

กรณีธุรกิจต้องระบุว่าผลกระทบที่มีต่อรายได้ทางธุรกิจของ:

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

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

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

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

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

หมายเหตุสุดท้าย: หากผู้จัดการผลิตภัณฑ์ไม่สนใจสิ่งนี้ทั้งหมดคุณก็แพ้: กระโดดเรือ


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

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

ขอบคุณ ผู้จัดการ 'ผลิตภัณฑ์' ปัจจุบันเป็นโปรแกรมเมอร์ที่ได้กลายมาเป็นผู้จัดการและตอนนี้ก็เป็นผู้จัดการฝ่ายพัฒนาผู้จัดการผลิตภัณฑ์และผู้จัดการโครงการ
kami

@kami: น่าเสียดายที่เป็นสูตรที่รู้จักกันดีสำหรับการล่มสลายเนื่องจากการ"ปีเตอร์หลักการ: ทำไมสิ่งที่ผิดเสมอไป" หนังสือต้นฉบับ: The Peter Principle
Marjan Venema

4

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

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

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

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

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

สุดท้ายการเปลี่ยนแปลงที่จำได้ยากและต้องใช้เวลา แขวนอยู่ที่นั่นและเริ่มต้นเล็ก ๆ และสร้างขึ้น

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