ข้อผิดพลาดทั่วไปในการสื่อสารกับลูกค้า: วิธีไม่ทำให้ลูกค้าผิดหวัง

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

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

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

อย่าล้มเหลวในการสื่อสารขั้นพื้นฐานกับลูกค้า

ลองนึกภาพการสื่อสารกับลูกค้าเหมือนกับที่คุณสื่อสารกับเพื่อนร่วมงาน เพื่อนฝูง หรือบุคคลอื่นๆ ที่คุณต้องการแสดงความสุภาพ

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

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

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

อย่างไรก็ตาม สิ่งต่าง ๆ ไม่ได้เรียบง่ายหรือเป็นเส้นตรงในโลกของการพัฒนาซอฟต์แวร์

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

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

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

การสื่อสารกับลูกค้าที่มีข้อบกพร่องทำให้เกิดความคาดหวังที่ไม่สมจริง

ดังนั้นในตอนแรกฉันกล่าวว่าลูกค้าต้องมีความคาดหวังมากมายเกี่ยวกับโครงการใช่ไหม? ใช่ไหม. ระยะเวลา.

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

นี่คือสิ่งที่เปรียบเทียบกันอย่างรวดเร็ว: คุณซื้อแท็บเล็ตทางออนไลน์และได้รับการจัดส่งภายใน 10 วัน วันที่ 8 ทางร้านแจ้งว่ามีปัญหาและการจัดส่งล่าช้าเป็นสัปดาห์ เพื่อชดเชยความไม่สะดวก ร้านค้าปลีกสัญญาว่าจะให้เครดิตร้านค้า 75 ดอลลาร์แก่คุณ

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

คุณจะได้รับแท็บเล็ตในวันถัดไป ไม่มีบริการพิเศษไม่มีเครดิตร้านค้า ตอนนี้เป็น คุณ ที่ผิดหวัง!

"อะไร? เมื่อวานคุณบอกว่าฉันจะได้ข้อเสนอที่ดีกว่านี้! นั่นไม่ยุติธรรม! ฉันบอกเด็ก ๆ แล้วว่า… “

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

นักพัฒนาโดยเฉพาะฟรีแลนซ์สามารถหลีกเลี่ยงสถานการณ์ที่คล้ายคลึงกันในการสื่อสารกับลูกค้าได้อย่างไร?

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

• ฟังลูกค้า.

• วิเคราะห์ปัญหาของพวกเขา

• วิเคราะห์วิธีแก้ปัญหาที่เสนอ

• ตรวจสอบให้แน่ใจว่าอยู่ในงบประมาณ/กำหนดการ

• สุดท้าย ไปข้างหน้าและนำเสนอข้อเสนอแนะของคุณ

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

อย่าถือว่าคุณรู้สิ่งที่ลูกค้าต้องการ

ถอดความ Mary Schmich สุภาพสตรีและสุภาพบุรุษของชั้นเรียน '17: ฟังลูกค้า ถ้าฉันสามารถเสนอเคล็ดลับได้เพียงข้อเดียวสำหรับอนาคต การฟังลูกค้าก็คงจะเป็นเช่นนั้น

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

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

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

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

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

ไม่เข้าใจสิ่งที่ลูกค้าร้องขอ

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

อะไร???

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

ประการที่สอง ไม่ใช่ทุกคนที่เป็นนักเขียนที่มีทักษะสูง พวกเขาพยายามพูด A แต่จบลงด้วยการอธิบาย B

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

“อ้อ แต่ในกรณีของฉัน ฉันไม่ได้รับเอกสารใดๆ ฉันแค่นั่งกับลูกค้าและพวกเขาอธิบายทุกอย่างให้ฉันฟังในขณะที่ฉันจดบันทึก”

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

ในตอนท้าย คุณต้องแน่ใจว่าไม่มีความกำกวมหรือความเข้าใจผิด

ทำไมคุณไม่ควรส่งมอบทุกอย่างที่ลูกค้าขอโดยไม่ต้องคิด

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

ผิด!

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

คุณจะประหลาดใจเมื่อเห็นว่าคำตอบคือ "ไม่" กี่ครั้ง

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

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

ต้นแบบ—อย่าเขียนเอกสารที่กว้างขวาง

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

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

โปรดทราบว่าความเข้าใจผิดเหล่านี้อาจเลวร้ายยิ่งกว่าเดิมหากลูกค้าไม่มีพื้นฐานทางเทคนิค

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

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

หยุดเสียเวลาในการโน้มน้าวลูกค้าว่าคุณพูดถูก

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

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

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

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

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

รู้ว่าเมื่อใดควรมุ่งมั่นสู่กำหนดเวลา

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

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

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

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

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

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