คุณควรเรียกเก็บเงินจากลูกค้าชั่วโมงที่ใช้ไปกับการเดินทางผิดหรือเปล่า [ปิด]


17

ฉันใช้ความท้าทาย CSS เล็ก ๆ เพื่อแก้ปัญหาให้กับลูกค้าและฉันจะได้รับค่าตอบแทนรายชั่วโมง ในที่สุดฉันก็แก้ไขมันใช้เวลา 5 ชั่วโมง แต่ฉันใช้เวลาประมาณ 25% ในการติดตามผิดลองใช้วิธีแก้ปัญหา CSS3 ที่ใช้งานได้เฉพาะในเบราว์เซอร์ล่าสุดและในที่สุดก็พบว่าไม่มีทางเลือกอื่นผ่านทาง JS ฉันควรเรียกเก็บเงินจากลูกค้าที่ 25% หรือไม่

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

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


คุณประมาณการเบื้องต้นอะไรให้ลูกค้าของคุณ?
JK

2
คุณหวังว่าจะได้งานเพิ่มจากลูกค้าหรือไม่ คุณต้องการสร้างความสัมพันธ์แบบใด
Steve Jackson

@Jonathan: ดูการแก้ไขของฉัน
Lea Verou

1
สำเนาซ้ำที่เป็นไปได้: programmers.stackexchange.com/questions/38415/…
Steve Jackson

1
มันไม่ซ้ำกันฉันอ่านกระทู้นั้นก่อนที่ฉันโพสต์คำถามของฉัน เขากำลังพูดถึงการเรียนรู้สิ่งใหม่ ๆ ไม่ใช่ทำงานผิดทาง
Lea Verou

คำตอบ:


24

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

โดยทั่วไปในกรณีเหล่านั้นฉันสร้างความแตกต่างระหว่างสามสถานการณ์:

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

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

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


ฉันไม่คิดว่านักพัฒนา "ธรรมดา" จะแก้ปัญหาได้เลย แต่สำหรับคนที่มีประสบการณ์ CSS มากกว่าโดยเฉลี่ยมันอาจจะเป็นอันดับสอง
Lea Verou

1
@La Verou: เมื่อฉันพูดถึง "นักพัฒนาโดยเฉลี่ย" มันเป็นเรื่องส่วนตัวมาก นอกจากนี้ยังขึ้นอยู่กับระดับของคุณและสิ่งที่ลูกค้าคิดเกี่ยวกับระดับของคุณ หากลูกค้าของคุณรู้ว่าคุณเป็นคนที่ดีที่สุดและจ่ายให้คุณหลายพันดอลลาร์ต่อวันความ "เฉลี่ย" อัตวิสัยจะสูงกว่าหากลูกค้าของคุณคิดว่าคุณเป็นลิงรหัส
Arseni Mourzenko

ฉันพูดถึงการประชุมใหญ่เกี่ยวกับ CSS และเขารู้ดีว่า :) แต่ฉันไม่ทำเงินหลายพันดอลลาร์ต่อวันอย่างแน่นอน: p (มีนักพัฒนาเว็บไซต์คนใดบ้างที่ทำได้)
Lea Verou

4
ฉันจะคำนึงถึงอัตราของคุณด้วย หากอัตราของคุณสูงมากคุณคาดว่าจะดีกว่าค่าเฉลี่ยดังนั้นชัดเจนอาจหมายถึงสิ่งอื่น ๆ อีกมากมาย หากอัตราของคุณต่ำมากคุณไม่คาดว่าจะสูงกว่าค่าเฉลี่ยสิ่งนี้จะชัดเจนน้อยลง
Martin York

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

33

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

IMHO นั่นไม่ใช่การติดตามที่ผิด นั่นเป็นการพัฒนาซอฟต์แวร์ตามปกติ

ถ้าฉันเป็นคุณฉันจะเก็บเงินเต็ม 4 ชั่วโมง


1
ฉันชอบวิธีที่คุณคิด: p :)
Lea Verou

2
ฉันเห็นด้วยตามธรรมชาติการวิจัย / การออกแบบเป็นพื้นที่ที่แม้แต่การเลี้ยวผิดก็มีความสำคัญ แสดงให้เห็นว่าบางสิ่งบางอย่างใช้งานไม่ได้ (และทิ้งร่องรอยไว้) ทำให้การบำรุงรักษาง่ายขึ้นเพราะคนต่อไปจะไม่ลองทำ
Matthieu M.

1
นั่นเป็นวิธีที่อาชีพอื่นทำ โปรแกรมเมอร์เท่านั้นที่เป็น "ผู้สูงศักดิ์" (หรือวางไว้ตรงๆไร้เดียงสา) แม้แต่คิดเกี่ยวกับการไม่เรียกเก็บเงินสำหรับทุกชั่วโมงที่ทำงานกับปัญหาของลูกค้า
quant_dev

8

โปรแกรมส่วนใหญ่ที่เราเขียนเราเขียนเพราะวิธีแก้ปัญหาไม่สามารถทำได้ในทันที ทุกอย่างเกี่ยวกับการเรียนรู้สิ่งใหม่ ลูกค้าไม่ได้จ่ายเงินให้คุณสำหรับผลิตภัณฑ์ เขาจ่ายเงินให้คุณสำหรับการเรียนรู้วิธีการสร้างผลิตภัณฑ์และให้ผลลัพธ์ (และถ้าเขาเรียกมันว่า "ท้าทาย" ตัวเองเขาคาดหวังให้คุณเรียนรู้บางอย่าง) ดู "Waltzing with Bears" โดย Tom de Marco และ Timothy Lister - "หากโครงการไม่มีความเสี่ยงอย่าทำอย่างนั้น"

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

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


เขาไม่ได้เรียกมันว่าเป็นการท้าทายตัวเองเขาไม่รู้เลยว่ามันเป็นสิ่งที่ท้าทาย (แม้ว่าเขาอาจจะพบว่ามันยากที่จะตัดสินใจที่จะ outsource มัน)
Lea Verou

downvoters จะโปรดแสดงความคิดเห็นว่าทำไมสิ่งนี้จึงถูก downvote
Lunivore

5

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

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

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


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

5

คำถามเหล่านี้ทำให้ฉันบ้า ...

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

โปรแกรมเมอร์จำเป็นต้องเริ่มประเมินค่าเวลาของพวกเขาให้มากขึ้น


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

5

สิ่งที่คุณทำเป็นเรื่องปกติอย่างสมบูรณ์ Fred Brooks กล่าวถึงปรากฏการณ์นี้ในบท "วางแผนจะทิ้ง One Away" ของหนังสือเล่มสุดท้ายของเขาเกี่ยวกับวิศวกรรมซอฟต์แวร์ "The Mythical Man-Month"

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


4

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

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

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

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


1
+1 คำตอบนี้ไม่ได้ถูกเน้นหนัก ทั้งคำตอบที่ได้รับการโหวตสูงสุดนั้นหายไปอย่างสิ้นเชิงจุด "สิ่งที่เป็นโซลูชั่นที่คุ้มค่าให้กับลูกค้า" Heck บางครั้งเราเรียกเก็บเงินจากลูกค้า 3 เท่าของความพยายามที่เรามีเพราะนั่นอาจจะยังถูกกว่าเขามากกว่าทางออกใด ๆ ที่เขาจะได้รับจากคู่แข่ง
Doc Brown

2

ขึ้นอยู่กับข้อตกลงเดิม

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


2

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

นั่นเป็นวิธีที่อาชีพอื่นทำ ไม่มีเหตุผลว่าทำไมโปรแกรมเมอร์ควรทำอย่างอื่น

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


1

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

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


1

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

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

ในกรณีของฉันมันจะสิ้นหวังถ้าฉันไม่สามารถคิดค่าใช้จ่ายสำหรับการเดินไปในทางที่ผิดเพราะฉันมักจะทำงานในสิ่งต่าง ๆ เช่นนี้:

ป้อนคำอธิบายรูปภาพที่นี่

... พยายามเอาชนะอัลกอริทึมการแบ่งย่อย Catmull-Clark อายุเกือบ 40 ปีที่ได้รับการยึดมั่นในอุตสาหกรรมและปรับปรุงซ้ำ ๆ โดย บริษัท เช่น Microsoft และ Pixar โดยพยายามให้ผลลัพธ์ที่เข้าใจง่ายขึ้นในขณะที่ยังคงแข่งขันกับ บริษัท ใหญ่ ๆ เหล่านี้ ความเร็วที่ชาญฉลาด

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

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

ความไม่แน่นอน

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

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

เขากำลังพูดถึงการเรียนรู้สิ่งใหม่ ๆ ไม่ใช่ทำงานผิดทาง

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


0

ขึ้นอยู่กับว่าคุณเสนอโครงการอย่างไรและโครงการสามารถเรียกเก็บเงินได้อย่างไร

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

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

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

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

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

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


-1

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


ฉันไม่ชอบมากนักเพราะลูกค้าแพ้ตลอดเวลาในกรณีที่ไม่ใช่กรณีที่ "ไม่ดี"
Lea Verou

มีความแตกต่างระหว่างกรณี "ไม่ดี" และ "แย่ที่สุด" เป็นกรณี หากเป็นกรณีที่เลวร้ายที่สุดฉันรับความเสียหาย
เดฟ

อืมจุดดี แต่ถ้าเป็นกรณี "ดี" จะเป็นอย่างไร
Lea Verou

จากนั้นเป็นชั่วโมง ฉันจะเรียกเก็บเงินคุณจำนวน x ต่อชั่วโมงสูงถึงชั่วโมง
เดฟ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.