คำถามติดแท็ก project-management

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

16 experience  project-management 

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

16 project-management 

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

16 project-management  agile 

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

16 productivity  project-management  code-quality 

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

15 design  project-management  time-management 

ในอีกด้านหนึ่งมีคำแนะนำที่บอกว่า "สร้างหนึ่งทิ้ง" หลังจากเสร็จสิ้นระบบซอฟต์แวร์และการเห็นผลิตภัณฑ์สุดท้ายเรารู้ว่ามีอะไรผิดพลาดในขั้นตอนการออกแบบและเข้าใจว่าเราควรทำอย่างไร ในทางกลับกันมี "เอฟเฟ็กต์ระบบที่สอง" ซึ่งบอกว่าระบบที่สองในรูปแบบเดียวกันที่ออกแบบมามักจะแย่กว่าระบบแรก มีคุณสมบัติหลายอย่างที่ไม่เหมาะสมในโครงการแรกและถูกผลักเข้าไปในรุ่นที่สองซึ่งมักจะนำไปสู่ความซับซ้อนและการออกแบบมากเกินไป นี่ขัดแย้งกับหลักการเหล่านี้หรือไม่? อะไรคือมุมมองที่ถูกต้องเกี่ยวกับปัญหาและพรมแดนระหว่างสองสิ่งนี้อยู่ที่ไหน ฉันเชื่อว่า "แนวทางปฏิบัติที่ดี" เหล่านี้ได้รับการส่งเสริมเป็นครั้งแรกในหนังสือน้ำเชื้อThe Mythical Man-Monthโดย Fred Brooks ฉันรู้ว่าปัญหาเหล่านี้บางอย่างได้รับการแก้ไขโดยวิธีการ Agile แต่ลึกลงไปปัญหายังคงเป็นหลักการที่ยังคงอยู่ ตัวอย่างเช่นเราจะไม่เปลี่ยนแปลงการออกแบบที่สำคัญ 3 sprint ก่อนที่จะเผยแพร่

15 design  project-management  programming-practices  project  principles 

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

15 project-management  senior-developer 

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

15 project-management  efficiency 

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

15 project-management  refactoring  issue-tracking 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันกำลังมองหาซอฟต์แวร์เพื่อจัดระเบียบและดูแลรักษาเอกสารภายในโครงการข้อมูลจำเพาะข้อกำหนด ฯลฯ ขณะนี้เราจัดเก็บเอกสารทั้งหมดเป็นไฟล์ MS Word DOC จำนวนมากในแหล่งเก็บข้อมูลการควบคุมแหล่งที่มาซึ่งทำให้เราสามารถควบคุมเวอร์ชันได้ แต่คุณไม่สามารถค้นหาข้อมูลนี้สร้างลิงค์ระหว่างพวกเขาจัดหมวดหมู่ทำงานร่วมกัน ข้อกำหนดการตั้งค่า: การติดตั้งเป็นศูนย์บนฝั่งไคลเอ็นต์ (อิงจากเว็บ) การควบคุมเวอร์ชันของเอกสาร คำอธิบายประกอบเอกสาร การเชื่อมโยงเอกสาร การค้นหาแบบเต็ม (เอกสารทั้งหมด) MS Word (* .doc) import \ export โปรแกรมแก้ไขข้อความ WYSIWYG ระบบที่ฉันค้นพบและทดลองใช้: มีเดียวิกิ XWiki ที่บรรจบกัน

15 project-management  documentation  knowledge-management  knowledge-base 

นักพัฒนาเขียนif/elseบล็อกด้วยคำสั่งโค้ดหนึ่งบรรทัดเช่น: if (condition) // Do this one-line code else // Do this one-line code อีกอย่างใช้วงเล็บปีกกาสำหรับพวกเขาทั้งหมด: if (condition) { // Do this one-line code } else { // Do this one-line code } ผู้พัฒนาสร้างวัตถุขึ้นมาก่อนแล้วจึงใช้มัน HelperClass helper = new HelperClass(); helper.DoSomething(); นักพัฒนาซอฟต์แวร์สร้างอินสแตนซ์ใหม่และใช้วัตถุในหนึ่งบรรทัด: new HelperClass().DoSomething(); นักพัฒนาง่ายขึ้นด้วยอาร์เรย์และforลูป: string[] ordinals = new string[] {'First', 'Second', …

15 project-management  productivity  coding-style 

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

15 project-management  code-quality 

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

15 project-management  agile  reporting 

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

15 productivity  project-management 

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

15 project-management