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

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

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

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

ลองจินตนาการถึงการสื่อสารกับลูกค้าเหมือนกับที่คุณสื่อสารกับเพื่อนร่วมงานเพื่อนหรือใครก็ตามที่คุณเอื้อเฟื้อเผื่อแผ่

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

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

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

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

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

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

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

การสื่อสารกับลูกค้าที่ไม่ดีส่งเสริมความคาดหวังที่ไม่เป็นจริง

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

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

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

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

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

'ที่? คุณเพิ่งบอกฉันเมื่อวานนี้ว่าฉันจะได้รับข้อเสนอที่ดีกว่านี้! มันไม่ยุติธรรม! ฉันบอกเด็ก ๆ ไปแล้ว ... ”

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

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

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

• รับฟังลูกค้า.

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

• วิเคราะห์โซลูชันที่เสนอ

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

• สุดท้ายส่งข้อเสนอแนะของคุณ

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

อย่าถือว่าคุณรู้ว่าลูกค้าต้องการอะไร

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

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

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

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

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

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

ไม่เข้าใจว่าลูกค้ากำลังขออะไร

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

ที่???

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

เป็นรูปแบบองค์ประกอบหรือหลักการ

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

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

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

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

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

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

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

ไม่ถูกต้อง!

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

คุณจะแปลกใจกี่ครั้งที่คำตอบคือ 'ไม่'

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

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

ต้นแบบ - อย่าเขียนเอกสารจำนวนมาก

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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