สิ่งนี้ทำให้สิ่งที่ฉันเริ่มคิดว่าเป็น "ความขัดแย้งนิรันดร์" (ระหว่างธุรกิจและวิศวกรรม) ฉันไม่มีวิธีแก้ปัญหาเนื่องจากเป็นปัญหาที่ไม่เคยหายไปไหน แต่คุณสามารถทำสิ่งต่างๆเพื่อช่วยบรรเทา
สิ่งที่ผู้คนมักจะไม่ตระหนักคือในขณะที่วิศวกรเราแค่สมมติว่าปัญหาของ "ธุรกิจที่ประสบความสำเร็จ" นั้นเป็นสิ่งที่มอบให้เสมอ เราต้องการให้โค้ดของเรานั้นดีและเรียบร้อยและบำรุงรักษาเพื่อให้เราสามารถเพิ่มคุณสมบัติใหม่และปรับแต่งที่มีอยู่อย่างรวดเร็วและมีลูกค้าขั้นต่ำที่ทำ QA ให้เราโดยการค้นหาเคสแปลก ๆ ที่จะถูกขัดขวางด้วยรหัสที่ดีกว่า การรักษาลูกค้าและรักษาความได้เปรียบในการแข่งขันด้วยฟีเจอร์และกลเม็ดเด็ดพรายที่ไม่มีใครสามารถผลิตได้เร็วพอทั้งคู่ชนะธุรกิจที่รหัสที่ดีส่งผลโดยตรงและแจ้งเหตุผลมากมายที่เราต้องการรหัสที่ดีกว่าในตอนแรก
ดังนั้นสะกดออกมา "เราต้องการทำ X ใน codebase ของเราเพราะหากเราไม่ทำมันจะส่งผลกระทบทางลบต่อธุรกิจเนื่องจาก Y" หรือ "... เพราะจะช่วยเพิ่มความสามารถของเราในการแข่งขันโดยการปรับปรุงความสามารถของเราในการปรับปรุงและคุณสมบัติใหม่ ๆ ."
และพยายามอย่างดีที่สุดเพื่อลองและรับหลักฐานที่เป็นรูปธรรมว่าการปรับปรุงกำลังทำงานอยู่ หากการปรับปรุงแอปย่อยบางส่วนส่งผลให้มีคุณสมบัติ / การปรับปรุงที่รวดเร็วขึ้นให้ตรวจสอบเครื่องมือที่ค้างอยู่ที่คุณอาจใช้เพื่อเป็นหลักฐานและชี้ไปที่การประชุมที่เหมาะสม
Egos มักจะมีปัญหา สิ่งหนึ่งที่ทีมวิศวกรรมต้องการอย่างมากคือการสร้างคุณค่าของการมีข้อตกลงบางอย่างกับแนวทางที่สอดคล้องกันในการแก้ปัญหาบางประเภทที่ทุกคนกำลังทำ Kool Aid d'jour เพราะพวกเขารู้ดีกว่า ไม่เป็นไรที่จะเชื่อว่าความชอบของคนอื่นนั้นแย่กว่าของคุณ แต่ความสอดคล้องของคุณค่ามากกว่าการถูกกว่าหากวิธีการของเขานั้นใช้การได้และเป็นข้อโต้แย้งที่คุณไม่สามารถเอาชนะได้ การประนีประนอมเพื่อความมั่นคงเป็นกุญแจสำคัญ เมื่อสิ่งต่าง ๆ สอดคล้องกันยากที่จะทำผิดเพราะวิธีการที่สอดคล้องกันมักจะเป็นวิธีที่เร็วที่สุด
- เลือกเครื่องมือที่เหมาะสม
มีกรอบการทำงานสองโรงเรียน / ชุดเครื่องมือ / ห้องสมุด / อะไรก็ตาม "ตั้งค่า 99% ของมันขึ้นมาสำหรับฉันดังนั้นฉันต้องรู้ / ทำน้อยมาก" กับ "อยู่ห่างจากตัวฉันเมื่อฉันไม่ต้องการให้คุณอยู่ที่นั่น แต่ช่วยฉันทำ DIY อย่างรวดเร็วและสม่ำเสมอกับสิ่งที่ฉันต้องการ ใช้กับแครอทแทนที่จะใช้หลักการ " ชอบอันที่สอง ความยืดหยุ่นและการควบคุมอย่างละเอียดไม่ควรเสียสละที่แท่นหมุนรอบหมุนเร็วเพราะเราไม่สามารถทำสิ่งนี้ได้เพราะเครื่องมือของเราจะไม่ยอมให้เรา "ไม่ใช่คำตอบที่ยอมรับได้และคำถามจะไม่เกิดขึ้นเสมอ - วิศวกรรมผลิตภัณฑ์เล็กน้อย / ใช้แล้วทิ้ง จากประสบการณ์ของฉันเครื่องมือที่ยืดหยุ่นได้มักจะถูกเปิดกว้างหรือทำงานรอบ ๆ อย่างไม่เหมาะสมและทำให้เกิดความยุ่งเหยิงที่ไม่อาจหยุดยั้งได้ บ่อยกว่าไม่ โซลูชันที่ยืดหยุ่น / ง่ายต่อการปรับเปลี่ยนนั้นสั้นหรือเร็วเพียงใดในระยะสั้นโดยไม่คำนึงถึง รวดเร็วยืดหยุ่นและดูแลรักษาได้ด้วยเครื่องมือที่เหมาะสม
- FFS, ถ้าวิศวกรไม่ได้ตัดสินใจ, อย่างน้อยก็รับอินพุตวิศวกรในการเลือกเครื่องมือ
ฉันเข้าใจว่านี่เป็นคำถามมุมมองของนักพัฒนา แต่ฉันอยู่ในสถานการณ์ที่มีการตัดสินใจทางเทคโนโลยีมากเกินไปกับการป้อนข้อมูลของวิศวกรเป็นศูนย์ นั่นมันอะไรกันแน่? ใช่ใครบางคนจะต้องโทรออกครั้งสุดท้าย แต่ได้รับความคิดเห็นที่มีคุณสมบัติถ้าคุณเป็นผู้จัดการที่ไม่ใช่ด้านเทคนิคไม่ใช่สิ่งที่คนขายหรือเว็บไซต์ตัวอย่างพูดเกี่ยวกับผลิตภัณฑ์ของตัวเอง สิ่งที่สัญญาว่าจะช่วยให้คุณประหยัดเงินเพราะคนไม่จำเป็นต้องฉลาดหรือปกป้องนักพัฒนาจากตัวเองนั้นเป็นสิ่งที่สกปรกและสกปรก จ้างคนที่คุณสามารถไว้วางใจได้ สะกดพวกเขาในสิ่งที่คุณต้องการจากสแต็คหรือโซลูชั่นเทคโนโลยีอื่น ๆ และใช้ข้อมูลของพวกเขาอย่างจริงจังก่อนที่จะตัดสินใจว่าเทคโนโลยี bandwagon จะกระโดดต่อไปอย่างไร
- มุ่งเน้นการออกแบบมากกว่าการใช้งาน
เครื่องมือสำหรับการติดตั้งและสามารถช่วยคุณได้ แต่สิ่งสำคัญอันดับแรกต้องเป็นสถาปัตยกรรมโดยไม่คำนึงถึงชุดของเล่นที่คุณมีสำหรับการสร้างสถาปัตยกรรมนั้น ในตอนท้ายของวันนั้น KISS และ DRY และปรัชญาที่ยอดเยี่ยมทั้งหมดที่ขยายออกจากเรื่องเหล่านั้นมากกว่าที่จะเป็นใน. NET หรือ Java หรืออาจเป็นบางสิ่งที่ทั้งฟรีและไม่ดูด
เมื่อฝ่าย biz ยืนยันว่าคุณทำในทางที่ไม่ดีให้บันทึกอีเมลนั้นโดยเฉพาะอย่างยิ่งส่วนที่คุณพูดว่าทำไมมันถึงต้องเสียค่าใช้จ่าย เมื่อการคาดการณ์ทั้งหมดของคุณเป็นจริงและเกิดปัญหาทางธุรกิจที่สร้างความเสียหายอย่างร้ายแรงนั่นคือเมื่อคุณมีข้อโต้แย้งมากมายสำหรับการพิจารณาทางวิศวกรอย่างจริงจังมากขึ้น แต่เวลาสิ่งต่าง ๆ อย่างระมัดระวัง ในช่วงกลางของช่วงเวลาที่ไฟลุกโชนเป็นช่วงเวลาที่ไม่ดีสำหรับ "I-บอก - คุณ - งั้น" ตามรหัสไฟ ดับไฟและนำรายการข้อกังวลที่ถูกเพิกเฉยไปก่อนหน้านี้ไปสู่การประชุม / การสนทนาย้อนหลังและพยายามให้ความสำคัญกับข้อกังวลทางวิศวกรรมที่แสดงและไม่สนใจและเหตุผลที่คุณเข้าใจว่าทำไมพวกเขาถึงถูกเพิกเฉยไม่ใช่ชื่อของคนจริงๆ การตัดสินใจที่จะไม่สนใจ คุณเป็นวิศวกร อยู่กับปัญหาไม่ใช่คน " เราแสดงความกังวลเกี่ยวกับ X เพราะเรากลัวว่าจะนำไปสู่ปัญหา Y เราได้รับคำสั่งจาก Z และให้จัดการกับมัน "