การแชร์โครงการซอฟต์แวร์ - การแก้ไขข้อขัดแย้ง [ปิด]

ฉันได้รับมอบหมายให้จัดการโครงการซึ่งเป็นแหล่งที่มาของนักพัฒนายูเครนบางคน

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

โครงการเกี่ยวข้องกับการจัดการกับสิ่งต่าง ๆ เช่น XMPP, RabbitMQ และฐานข้อมูล ในการพบกันครั้งแรก (มักจะเป็น IM) ฉันอธิบายอย่างละเอียดถึงสิ่งที่พวกเขาต้องทำ ดูเหมือนว่าพวกเขาจะเข้าใจ - และพวกเขามั่นใจมากว่าจะทำได้อย่างง่ายดาย

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

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

• พวกเขาฮาร์ดโค้ดบางสิ่งที่จำเป็นต้องแยกออกเป็นไฟล์กำหนดค่า
• มีไฟล์กำหนดค่าหลายไฟล์ที่ฉันต้องรวมไว้ในที่เดียว
• พวกเขาเขียนเอกสารไม่แน่นอน
• การเปลี่ยนแปลงเล็กน้อยอื่น ๆ

ฉันขอให้พวกเขาทำการเปลี่ยนแปลงเหล่านี้ (ยกเว้นเอกสารประกอบ) - และเรามีข้อโต้แย้ง

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

ในที่สุดตอนนี้พวกเขาได้ทำการเปลี่ยนแปลงและโครงการสิ้นสุดลงแล้ว แต่มันทิ้งคำถามไว้ในใจของฉัน ...

• พวกเขาทำสิ่งที่ต้องการ แต่ฉันต้องการให้ทำอย่างถูกต้องและด้วยเหตุนี้การเปลี่ยนแปลง ฉันไม่ยุติธรรมจริงเหรอ?

• ทำไมฉันถึงเห็นด้วยกับการให้โค้ดแก่พวกเขาโดยไม่มีข้อกำหนดคุณสมบัติการทำงาน?

• ทำไมฉันไม่แน่ใจว่าพวกเขาเข้าใจทุกอย่างเป็นครั้งแรก

ไม่มีใครพบตัวเองในตำแหน่งเดียวกันหรือไม่ คุณคิดว่ามีวิธีที่ดีกว่าในการจัดการโครงการภายนอกหรือไม่

- อัปเดต -

ขอบคุณสำหรับความคิดเห็นทั้งหมด - หลังจากไตร่ตรองถึงประสบการณ์ทั้งหมดฉันสามารถสรุปได้ ...

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

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

• ต้องการฟังก์ชั่นการใช้งานจากด้านข้างของพวกเขา - ยืนยันว่ามันจะถูกเขียนก่อนรหัสใด ๆ สิ่งนี้จะได้รับความสับสนและความเข้าใจผิดมากมาย

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

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

ก่อนอื่นนี่ไม่ใช่ปัญหาของการปิด shoring มันเป็นปัญหาการจัดการผู้ขาย

ใช่คุณทำผิดพลาดมาก ...

พวกเขาทำสิ่งที่ต้องการ แต่ฉันต้องการให้ทำอย่างถูกต้องและด้วยเหตุนี้การเปลี่ยนแปลง ฉันไม่ยุติธรรมจริงเหรอ?

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

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

ทำไมฉันไม่แน่ใจว่าพวกเขาเข้าใจทุกอย่างเป็นครั้งแรก

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

นี่คือวิธีทำในครั้งต่อไป ... ในสองขั้นตอน ...

ขั้นตอนที่ 1:ให้พวกเขารวบรวมข้อกำหนดดำเนินการวิเคราะห์ระบบและเขียนการออกแบบทางเทคนิคและ \ หรือ Spec ของการทำงาน (หรือเขียนด้วยตัวเอง) ตกลงราคาสำหรับระยะนี้ อย่าลืมอธิบายว่าคุณไม่ได้มีส่วนร่วมในการพัฒนา ให้แน่ใจว่าได้รวมเวลาสำหรับการประชุมในราคา

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

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

ฉันต้องการมันอย่างถูกต้อง

จากนั้นอย่า outsource หรือถ้าคุณแน่ใจว่าพวกเขาทำงานในทีมโครงการของคุณและคุณมีส่วนร่วมในการตรวจสอบโค้ดในเวลานั้น

โครงการแล้วเสร็จหลังจาก 3 สัปดาห์และส่งมอบสิ่งที่จำเป็น ณ จุดนั้นฉันเริ่มทบทวนรหัส

อีกครั้งคุณควรได้รับการตรวจสอบรหัสในระหว่างโครงการไม่ใช่หลังจาก

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

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

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

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

เมื่อฉันถามหนึ่งในนักพัฒนาว่าเขารู้จัก XMPP หรือไม่เขาบอกว่าเขาทำงานกับมันเป็นครั้งแรก

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

ทำไมฉันถึงเห็นด้วยกับการให้โค้ดแก่พวกเขาโดยไม่มีข้อกำหนดคุณสมบัติการทำงาน?

มีเพียงคุณเท่านั้นที่สามารถตอบคำถามนี้ได้ด้วยตัวเอง แต่ถือเป็นประสบการณ์การเรียนรู้ในครั้งต่อไป

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

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

มันก็โอเคสำหรับส่วนใหญ่ แต่มีปัญหาที่สำคัญบางอย่าง:

• พวกเขาฮาร์ดโค้ดบางสิ่งที่จำเป็นต้องแยกออกเป็นไฟล์กำหนดค่า
• มีไฟล์กำหนดค่าหลายไฟล์ที่ฉันต้องรวมไว้ในที่เดียว
• พวกเขาเขียนเอกสารไม่แน่นอน
• การเปลี่ยนแปลงเล็กน้อยอื่น ๆ

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

ฉันทำการนำเสนอเมื่อไม่นานมานี้เกี่ยวกับความแตกต่าง มันถูกเรียกว่า "Global Outsourcing, 10 เคล็ดลับในการเสริมพลังธุรกิจของคุณ" นี่คือบทสรุปของ 10 เคล็ดลับ (นี่มาจากมากถึง 400 โครงการเอาต์ซอร์ซ):

ตัวเลือก

1. หลีกเลี่ยงการเข้าร่วมประมูลต่ำสุดและสูงสุด เห็นได้ชัดว่าคุณไม่ต้องการรับความเสี่ยงจากผู้ที่เสนอราคาต่ำกว่าและผู้ประมูลสูงสุดมักจะมีค่าน้อยกว่าค่ามัธยฐาน

2. ตรวจสอบการจัดอันดับ (หรือการอ้างอิง) ฉันมักจะตรวจสอบการอ้างอิงและการให้คะแนน

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

B. การกำกับดูแล

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

2. กรอบปฏิเสธที่กำหนดเอง หรือคุณมีความเสี่ยงที่จะผูกติดอยู่กับมันหรือมากกว่านั้นโดยเฉพาะกับนักพัฒนาที่เขียนมัน)

3. กำหนดมาตรฐาน เกี่ยวข้องกับเคล็ดลับก่อนหน้า การใช้มาตรฐานจะเพิ่มมูลค่าของซอร์สโค้ดของคุณเนื่องจากสามารถเข้าใจได้โดยนักพัฒนาจำนวนมาก

4. ตรวจสอบต้นทบทวนบ่อย ปัญหาส่วนใหญ่สามารถ "ปรับ" ถ้าคุณตรวจทานซอร์สโค้ดหลังจากสัปดาห์แรกหรือที่ทำงาน

C. กลยุทธ์

1. ผู้ให้บริการทดสอบกับโครงการขนาดเล็ก ก่อนที่ฉันจะให้โครงการใหญ่แก่ผู้ให้บริการฉันทดสอบกับโครงการขนาดเล็กหนึ่งหรือสองโครงการ

2. ยอมรับผู้ชนะการประมูลหลายเพื่อลดความเสี่ยง สำหรับโครงการที่สำคัญฉันเลือกผู้ประมูลสองหรือสามคนจากนั้นฉันก็จะใช้งานได้ดีที่สุด ทำงานได้ดีที่สุดกับโครงการขนาดเล็ก (ต่ำกว่า $ 5,000)

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

ฉันเห็นด้วยอย่างยิ่งกับคำตอบของ maple_shaft

คุณยอมรับรหัสและฉันคิดว่าเขียนเช็คแล้วตรวจสอบรหัสคุณเรียงลำดับจากนั้นทำทุกอย่างย้อนหลัง

ทำไมฉันถึงเห็นด้วยกับการให้โค้ดแก่พวกเขาโดยไม่มีข้อกำหนดคุณสมบัติการทำงาน?

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

ทำไมฉันไม่แน่ใจว่าพวกเขาเข้าใจทุกอย่างเป็นครั้งแรก

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

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

คุณโชคดีที่พวกเขาทำการเปลี่ยนแปลงที่คุณต้องการ พวกเขาอาจพูดได้ว่า: โชคดี

ไม่มีใครพบตัวเองในตำแหน่งเดียวกันหรือไม่ คุณคิดว่ามีวิธีที่ดีกว่าในการจัดการโครงการภายนอกหรือไม่

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

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