การออกแบบที่ดีในการประชุมขนาดใหญ่มีประสิทธิภาพเพียงใด

หลายครั้งที่ฉันได้เห็นโศกนาฏกรรมที่น่าเศร้า นี่คือสิ่งที่เกิดขึ้น:

1. การทบทวนการออกแบบทีมสำหรับโครงการใหม่
2. ฉันเห็นการออกแบบที่เรียบง่ายที่มีรูค่อนข้างน้อย
3. ฉันตั้งใจพูดถึงหลุมและวิธีหลีกเลี่ยง
4. คำเตือนจะถูกละเว้นด้วยความคิดเห็นเช่น "ที่ไม่เคยเกิดขึ้นในชีวิตจริง"
5. ในที่สุดสิ่งที่ "จะไม่เคย" เกิดขึ้น "เกิดขึ้น
6. การทบทวนการออกแบบทีมฉุกเฉินสำหรับโครงการที่เสียหาย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขณะที่การกระทำมีความสำคัญมากกว่าคำพูดคุณสามารถ:

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

• แสดงผลิตภัณฑ์คู่แข่งที่ระบุสิ่งที่กลุ่มคิดว่าเพียงพอเพียง 'มุมคดี' คุณจะประหลาดใจกับความยาวของ Google ที่จะคาดการณ์ข้อผิดพลาดในโปรแกรมสเปรดชีต

• ทำซ้ำโครงการสุดท้ายที่จำเป็นต้องมีการเขียนใหม่หนึ่งสัปดาห์ก่อนที่จะส่ง

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

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

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

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

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

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

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

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

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

วิธีนำแนวคิดของคุณไปปฏิบัติ

การประชุมครั้งแรกหมายถึงปัญหาที่ท้าทาย คุณแก้ไขปัญหาคุณเอาชนะความท้าทาย ความท้าทายเป็นสิ่งที่ดีไม่ใช่ปัญหา

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

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

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

2. การใช้คำของคุณเป็นสิ่งสำคัญมากที่นี่ " ฉันต้องการความช่วยเหลือจากคุณ "

3.ให้หัวหน้าเลือก "A", "B" หรือ "C" ในความเป็นจริงให้หัวหน้าสร้างตัวเลือก "D" โดยดึงส่วนจาก "A", "B" และ "C" สิ่งที่คุณกำลังทำคือปล่อยให้หัวหน้าของคุณเลือกได้

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

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