จะยืนหยัดได้อย่างไรเมื่อเพื่อนร่วมงานละเลยกระบวนการ?

14

ปัญหาที่ฉันกำลังเผชิญ:

สมาชิกในทีมของฉันเริ่มทำงานในโครงการที่ไม่มีเอกสารการทำงาน / เทคนิคพร้อมแม้ว่ากระบวนการของ บริษัท ของเราจะกำหนดสิ่งเหล่านี้ก่อนที่จะเริ่ม
สมาชิกในทีมของฉันยอมรับราคาถูก, การแก้ปัญหาที่ไม่มีโครงสร้างและจะดำเนินการจริงๆแฮ็กที่ไม่ดีเป็นซอฟต์แวร์โดยไม่ต้องคิดสองครั้งเมื่อบันทึกการบริหารจัดการโครงการที่พวกเขามี 'เวลา จำกัด'
สมาชิกในทีมของฉันเริ่มทำงานในโครงการที่ทำงานร่วมกับโครงการที่ยังไม่เสร็จจากทีมอื่นซึ่งยังไม่ได้ทดสอบและยังไม่เสร็จ (ก่อให้เกิดงานพิเศษมากมาย)
การปรับปรุงและขั้นตอนทั้งหมดของซอฟต์แวร์ไม่ได้รับการวางแผนอย่างเหมาะสมและมักส่งผลให้ front-end / design ไม่เสร็จสิ้นเมื่อผู้พัฒนา back-end ต้องเริ่มทำงาน

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

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

สมาชิกในทีมของฉันบ่นมาก - แต่ต่อกันเท่านั้น They keep on going - whatever the situation is. ผลลัพธ์?

ฉันเติบโตไม่มั่นคงบางทีฉันเอง
นี่เป็นสิ่งที่ควรจะเป็นใช่ไหม

คำถามของฉัน? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

นั่นคือโดยไม่ต้องมองเช่นนักพัฒนาที่น่ารำคาญบางคนที่กำลังมองหาสิ่งที่จะเลวตลอดเวลา

project-management teamwork

— Wesley van Opdorp
แหล่งที่มา

นี่คืองานของ QA เพื่อให้แน่ใจว่ากระบวนการได้รับการปฏิบัติตาม

— mouviciel

เรามีทีมงานบริหารฝ่ายขายฝ่ายบริหารโครงการและทีมพัฒนา QA ขาด - น่าเสียดาย

— Wesley van Opdorp

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

— mouviciel

เจ้านายของคุณพูดว่าอะไรเมื่อคุณพูดถึงเรื่องนี้กับเขา

8

ไม่ทุกคนจริงๆเห็น?

ฉันเคยมีสถานการณ์ที่เราต้องการปรับปรุงกระบวนการ เราสร้างโพรพอพโพลของกระบวนการที่แตกต่างกันและทุกคนก็เห็นด้วย

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

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

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

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

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

หวังว่าจนกว่าพวกเขาจะรู้ตัวหรือคุณเปลี่ยนงาน

— keppla
แหล่งที่มา

2

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

— MaR

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

— keppla

1

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

— MaR

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

— keppla

3

บางทีมันอาจจะเป็นคุณ

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

บางทีคุณทุกคนควรจะพบกันกลางและลองใช้วิธีการที่คล่องตัวและมีปฏิสัมพันธ์ แต่มีโครงสร้าง

— Homde
แหล่งที่มา

1

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

— keppla

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

— เป็

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

— keppla

2

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

— บาย

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

— Homde

2

ใครเป็นผู้รับผิดชอบคนเหล่านี้ ใครบางคนจ้างพวกเขาและบางคนสามารถยิงพวกเขา / ถือพวกเขารับผิดชอบ

"บริษัท ของฉันต้องการ ... " ไม่มีความหมายหากไม่มีการบังคับใช้

คุณไม่สามารถตอบสนองความต้องการด้านเวลาที่ไม่อนุญาตสำหรับกระบวนการผลิต

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

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

— JeffO
แหล่งที่มา

2

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

หากคุณต้องการเปลี่ยนพฤติกรรมของพวกเขาการเตือนพวกเขาอย่างต่อเนื่องเกี่ยวกับกฎอาจไม่ได้ผลมากนัก มีแนวโน้มที่จะนำไปสู่พวกเขาไม่สนใจคุณ พยายามหาวิธีในการเปลี่ยนกระบวนการเพื่อให้พวกเขารู้สึกว่ามีประโยชน์มากขึ้นในขณะที่ยังคงติดตามกระบวนการ คุณสามารถใช้การตรวจสอบรหัสบางประเภทตรวจสอบรหัสของกันและกันและเรียนรู้จากกันและกันเพื่อป้องกันการแฮ็กไม่ให้เป็นรหัสการผลิตได้หรือไม่ คุณสามารถเปลี่ยนวิธีการจัดการข้อมูลจำเพาะ (docs / ext.interfaces / front-end) จากการตัดสินใจแบบเสร็จแล้วและไม่เสร็จเป็นขาวดำเป็นกระบวนการสหกรณ์ได้มากขึ้น ช่วยจบไหม (และคุณควรยอมรับว่าความต้องการจะเปลี่ยนแปลง)

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

— Jaap
แหล่งที่มา

2

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

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

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

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

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

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

— bethlakshmi
แหล่งที่มา