ในชีวิตการทำงาน แต่ละคนก็น่าจะได้พบเจอลูกค้าที่อยากหลีกเลี่ยงให้ไกลแต่หลีกเลี่ยงไม่ได้มานักต่อนักแล้ว ซึ่งทำความเอ็นดูให้คนทำงานมากน้อยต่างกัน
ในหนังสือ Web Redesign 2.0 | Workflow That Works ได้ร่างความ”น่ารัก” ของลูกค้าที่น่าหลีกเลี่ยงหรือพึงระวังเอาไว้หลายประการ ก็เลยอยากแชร์ไว้ให้ขำขำกัน แต่มีแต่ประการอย่างเดียวคงไม่ได้ประโยชน์ ก็เลยขอแชร์การรับมือในแต่ละประการจากประสบการณ์ตัวเองเอาไว้ด้วย เพราะในเมื่อเราต้องการเงิน เราจึงไม่หลีกเลี่ยง แต่ทำอย่างไรให้เจ็บตัวน้อยที่สุด
ความน่ารักที่ 1 : Has a “get-it-up-quick” attitude with unrealistic schedule requests
ลูกค้าแบบนี้คือลูกค้าที่คิดว่าการสร้างกรุงโรมใช้เวลาไม่ต่างกับการเผากรุงลงกา สร้างเรือโนอาไม่ต่างกับการพับกระทงใบตอง อาการนี้มักจะเป็นกับผู้บริหารระดับสูง หรือเจ้าของโปรเจคที่มาทางสายบริหาร ไม่ใช่สายจับกังอย่างพวกเรา
เท่าที่เจอ ผู้บริหารบางท่านจะมีทัศนคติว่า งานพัฒนาเว็บ/แอพ ก็เหมือนการลงแขกเกี่ยวข้าว เพิ่มคนเข้าไปมันก็จะเสร็จไวขึ้นเอง หรือนอนน้อยลงวันละสองสามชั่วโมงก็คงไม่เป็นไร เสาร์อาทิตย์ก็ต้องทำงานให้เป็นปรกติอยู่แล้ว
และจริงอยู่ที่ว่า งานพัฒนาเว็บ/แอพนั้นน่ะ ส่วนใหญ่ก็เจอ impossible deadline อยู่เรื่อย ๆ อยู่แล้ว แต่อย่างไรก็ตาม เราก็ควรหลีกเลี่ยง เพราะการรับ impossible deadline นั้น เป็นความเสี่ยงที่จะโดนค่าปรับในการทำงานล่าช้าเป็นอย่างมาก และยังสร้างวงจรอุบาทว์ในการค้างที่ทำงาน กินของไม่มีประโยชน์ นอนไม่เป็นเวลาอีกด้วย
วิธีรับมือกับลูกค้าแบบนี้ก็คือ การทำ Dev Timeline ให้เคลียร์ ก่อนที่จะลงมือทำ แต่อย่าบอกแค่วันเสร็จสมบูรณ์ตู้มแค่วันเดียวเพราะผลลัพธ์มักจะเป็นโกโก้ครันช์ในหลาย ๆ กรณี ให้ซอย Timeline เป็นช่วงเล็ก ๆ และแสดง Deliverables ตามระยะให้เขาเห็นว่าเรา Deliver บางอย่างได้เป็นระยะ ๆ นะ ระยะนี้เราจะ Deliver อะไรให้ได้บ้าง ลูกค้าแบบนี้บางส่วนจะเข้าใจและจะพอรับได้ แต่ทั้งนี้ทั้งนั้นต้องปรึกษาทีมงานก่อนนะว่าทำได้อย่างที่จะเสนอลูกค้าหรือไม่ เพราะลูกค้าแบบนี้ ถ้าไม่ได้เดดไลน์อย่างที่หวัง ทีมงานก็อย่าหวังจะเลทในสิ่งที่เสนอไปได้นัก
ความน่ารักที่ 2 : Wants to shortcut the process and feels it is a waste of time to address audience needs or overall strategy.
ลูกค้าแบบนี้มักจะเป็นคนที่ค่อนข้างกระตือรือร้นและมองไปถึงผลงานข้างหน้า อาจจะเป็นพวกถนัดด้นสด แต่ทั้งนี้ทั้งนั้น คือเขายังไม่เห็นประโยชน์ในการทำ research และวางกลยุทธ์เฉพาะเว็บ ซึ่งก็เป็นไปได้อีกว่า จะเป็นลูกค้า (หรือลูกน้องของลูกค้า) ที่ไม่ชำนาญในสายพัฒนานัก แต่ก็เป็นลูกค้าที่มั่นใจว่า ตัวเองมี insight ของลูกค้ามากพอแล้ว
ลูกค้าแบบนี้จึงชอบที่จะตั้งขึ้นมาว่า ตัวเองเป็นอะไรสักอย่างของลูกค้า (หรือในบางกรณี อาจจะเป็นทุกอย่างให้ลูกค้า โดยไม่ถามลูกค้าสักคำว่าที่อยากเป็นให้น่ะอยากได้ไหมในบริบทที่นำเสนอ) และลุยเดินหน้ากับการสร้างภาพให้ตัวเองเป็นอย่างที่ตั้งไว้ด้วยวิธีเดิม ๆ เช่น สร้างโลโก้ ทำโฆษณาเก๋ ๆ ออกข่าวรัว ๆ แล้วอีกไม่กี่ปีหรือแค่ข้ามปีก็เปลี่ยนอีก ตามแต่ว่าปีนี้อยากเป็นอะไร
วิธีรับมือกับลูกค้าแบบนี้ (ในกรณีที่คิดว่าเขายังมีเวลาให้ทำอยู่) คือ ต้องเข้าใจว่า โปรเจคของเราอาจจะอายุสั้นก็ได้ ไม่เป็นไร ไม่ใช่เรื่องของเรา ไม่ต้องไปพยายามเสนอให้มีกลยุทธ์ระยะยาวเพราะนั่นเป็นวิสัยทัศน์องค์กรซึ่งเราไม่มีหน้าที่ไปแก้ไข แต่ในเรื่องของความต้องการของ user/audience นั้น แนะนำว่า ค่อย ๆ แซะถามในมุมของลูกค้าไปเรื่อย ๆ เช่น ถามว่า “พี่ว่าลูกค้าพี่จะเปิดแอพของพี่ในกรณีไหนบ้างเหรอครับ” “พี่ว่าtarget userของพี่จะมีแอพอะไรอยู่ในมือถือของเขาบ้างคะ” “พี่คิดว่าคนที่จะเริ่มใช้แอพของพี่จะเป็นคนแถวไหนคะ” ก็จะช่วยให้ลูกค้าได้มองในมุม user บ้างแม้ว่าจะไม่มีการ research user เป็นจริงเป็นจังก็ตาม
ความน่ารักที่ 3 : Doesn’t know what the content should be but wants it to “look cool”
ลูกค้าแบบนี้ ไม่รู้ว่าตัวเองต้องการอะไร แต่ก็ไม่คิดว่านั่นคือปัญหา และมักจะเป็นลูกค้าที่สวมบทบาทเป็น master mind ลูกค้าแบบนี้คือลูกค้าที่มักจะบอกให้ทำมาสิบอันแล้วมาเลือก พอกัดฟันทำสิบอันจริง ๆ ก็มักจะไม่เลือกสักอัน แต่จะคิดเอาแต่ละอันลองมายำอย่างนั้นอย่างนี้ และใครต้องเป็นคนยำให้ดู ก็พวกตูนั่นแหละ
เป็นธรรมดาที่หลาย ๆ ครั้งเราจะเจอลูกค้าแบบนี้และชอบจ้างเรามาเป็นมือเป็นเท้าเฉย ๆ แต่เอาเข้าจริง ๆ แล้ว การทำงานให้ลูกค้าแบบนี้ เบิร์นสมองไม่ต่างกันเลยหรืออาจจะมากกว่าในส่วนที่ไม่ควรจะเบิร์นขนาดนั้น และอาจจะยังต้องมีเจโตปริยญาณในการอ่านใจลูกค้าได้อีกด้วย
วิธีรับมือก็คือ ใช้พื้นฐานจิตวิทยาที่เล่าเรียนมา และความกระตือรือร้นในการศึกษามนุษย์ที่พึงมี เข้าใจลูกค้าให้ได้มากที่สุด (เอาจริง ๆ เราก็ควรจะเข้าใจลูกค้าทุกคนให้ได้มากที่สุดอยู่แล้วนะ) ทำให้เขาไว้วางใจเราบ้าง (ซึ่งก็ควรทำอยู่แล้วอีกเช่นกัน) เพื่อยังมีสิทธิมีเสียงในการต่อรองงานที่ไม่จำเป็นได้ อย่างไรก็ตาม ให้ทำใจไว้ว่า สุดท้ายงานอาจจะออกมาเป็นอะไรที่เราไม่อยากบรรจุไว้ในเรซูเม่ แต่ก็ช่างเถอะถ้าเขาจ่ายตัง
ความน่ารักที่ 4 : Asks to create a demo site, says “the real one will come later”
ลูกค้าแบบนี้ต้องการผลลัพธ์โดยไม่ค่อยสนวิธีการ มักจะเร่งให้ไทม์ไลน์รวนไปอีกแบบ ซึ่งมันอาจหมายถึงการพยายามให้เราเอางานจากงวดที่ยังไม่จ่ายมาทำก่อน นั่นคือการกระทบ Budget Plan ไปด้วย
ในแง่หนึ่งก็เป็นที่เข้าใจได้ว่า คนเป็นลูกค้าก็อยากจะเห็นของที่จับต้องได้เร็ว ๆ มีน้อยรายที่จะสามารถอดทนรอเป็นเดือน ๆ เพื่อให้เห็นสิ่งดุ๊กดิ๊กอะไรบางอย่างให้อุ่นใจว่าทีมพัฒนาทีมนี้มันยังไม่เทเรา แต่การทำ demo site ก่อนกาลนั้น จริง ๆ ไม่เป็นผลดีแม้แต่กับตัวลูกค้าเอง deliverables อะไรก็ตามที่ออกไป ลูกค้าจะรับรู้เป็นสัญญาว่าเราจะทำเช่นนั้นเช่นนี้ แม้ว่า concept จะยังไม่ proof ก็ตาม
วิธีรับมือกับลูกค้าแบบนี้ (และอาจจะเวิร์คกับลูกค้าอื่นด้วย) คล้ายคลึงกับความน่ารักที่ 1 ก็คือ การซอยย่อย dev timeline แบ่ง deliverables ให้เห็น และตีโป่ง interactive prototype บางส่วนหลัก ๆ ให้ลูกค้าดูเล่นบ้างเป็นระยะ ทำ demo ในส่วนที่ proof concept จาก prototype แล้วตามไปเป็นต่อน ๆ
(ในส่วนของ paper prototype นั้น ส่วนตัวคิดว่า ถ้าจะใช้ภายในกลุ่มทีมงานก็ทำได้ แต่มักไม่ค่อยเวิร์คกับลูกค้ามากนัก)
ความน่ารักที่ 5 : Cannot give final approval or is not putting you in touch with the decision-makers
ลูกค้าแบบนี้มักเกิดในองค์กรใหญ่ที่เราเข้าไม่ถึงผู้บริหารหรือผู้ที่มีอำนาจตัดสินใจ พนักงานระดับล่างถึง senior ทำงานกันเอง แต่เบื้องบนไม่ได้ให้อำนาจการตัดสินใจกับคนทำงานมาด้วย ทั้ง ๆ ที่ก็ไม่ได้เข้าฟังหรือรับรู้ เห็นเพียงแต่ผลลัพธ์แล้วตัดสินลงมาอีกทีหลังจากที่คนทำงานเอางานใส่พานถวายขึ้นไปแล้ว ซึ่ง เป็นลูกค้าอีกแบบหนึ่งที่ทำงานด้วยโคตรยาก เพราะคนฟังไม่ได้ฟันธง คนฟันธงไม่ได้ฟัง ทำให้เกิดการทำงานซ้ำซ้อนซ้ำซากเป็นอย่างมาก หรืออยู่ ๆ อาจจะเกิด requirement ใหม่เพิ่มโดยเจรจาได้ยากเพราะคนทำงานก็ได้แต่รับคำสั่งมาบอกว่าเป็นความต้องการจากเบื้องบน ส่วนเบื้องบนก็ไม่มาเจรจากับเรา ไม่ได้มารับรู้ไทม์ไลน์กับเรา
วิธีรับมือกับลูกค้าแบบนี้ คือพับปณิธานการทำแอพให้คนใช้งานได้ดีเข้าหีบไป ทำตามใจคนฟันธงไปแหละ เธอจะไปคุยกับเซารอนได้ยังไงในเมื่อเธอไม่ได้เป็นคนถือแหวน แต่เพื่อต้องการป้องกัน requirement หรืออะไรที่กระทบกับไทม์ไลน์และ Budget ก่อนเริ่มงานควรมีเอกสารไทม์ไลน์และงบประมาณที่ Signed Off เรียบร้อยแล้วให้อุ่นใจ
ความน่ารักที่ 6 : Doesn’t have time to fill out the survey
ลูกค้าแบบนี้ ไม่ใช่ว่าเป็นลูกค้าที่แย่เสมอไป แต่อาจจะไม่มีเวลาเจียดมาทำเอกสารให้เราจริง ๆ ก็ได้ คล้ายคลึงกับความน่ารักที่ 2 ที่ไม่ได้ให้ความสำคัญกับช่วงเวลา survey & research อะไรนัก แต่ความน่ากลัวที่มากกว่าก็คือ แม้แต่ survey ที่เกี่ยวกับเรื่องตัวเอง ลูกค้าน่ารักแบบที่ 6 นี่ก็อาจจะยังไม่ทำเลย
ความซวยก็คือ พอเก็บ requirement ได้ไม่ครบ การนั่งเทียนก็บังเกิด เมื่อการนั่งเทียนผิดพลาดไปจากความเป็นจริง ลูกค้าที่ไม่มีเวลาทำ survey เหล่านี้จะมีเวลามาวิจารณ์งานทันทีว่ามันไม่ตรงกับสิ่งที่เป็นจริงอยู่
แต่ถ้าหากลูกค้ายังมีเวลาให้สัมภาษณ์และให้ observe อยู่ ก็จะถือว่า ความซวยนี้ไม่ร้ายแรงมากนัก อย่าลืมว่า การได้ข้อมูลจากลูกค้า ไม่ได้มาจากการกรอกแบบสอบถามอย่างเดียว เรายังมีวิธีอีกมากมายที่จะทำให้เราได้ข้อมูลมา ไม่ว่าจะเป็นการสังเกตการณ์ การสัมภาษณ์ การดูเอกสารที่มีอยู่ การดูคู่แข่ง หรือแม้แต่การไปฟ้องเจ้านายของลูกค้า (กรุณาทำด้วยความเสี่ยงของท่านเอง) ส่วนใหญ่ลูกค้าที่เป็นคนจ่ายเงินเขาไม่ค่อยขี้เกียจเกินไปจนมันทำให้สิ่งที่เขาต้องจ่ายไปสูญเปล่าหรอก
ความน่ารักที่ 7 : Small budget, swift deadline
ลูกค้าแบบนี้คือลูกค้าที่คิดว่าเว็บอาลีบาบาสร้างขึ้นได้ด้วยเงินไม่เกินสามหมื่นบาท เอาจริง ๆ เราไม่ค่อยจะตกอยู่ในสถานการณ์นี้เท่าไหร่หรอก เพราะพอรู้งบและสโคปปั๊บก็ปฏิเสธงานกันแล้วนอกจากจะร้อนเงิน ลูกกำลังจะเปิดเทอม คนที่บ้านอยากได้กุชชี่ หรือกำลังจะจมดอกเบี้ยที่กู้มาในอัตราที่สูงลิ่ว
อันดับแรกที่ต้องเข้าใจคือ ลูกค้าจำนวนมากไม่ได้อยู่ในวงการ เขาไม่รู้หรอกว่าการทำเว็บ ๆ หนึ่งต้องใช้เงินเท่าไหร่ เพราะฉะนั้น หลาย ๆ คนเขาไม่ได้งก เขาแค่ไม่รู้ ในขณะที่อีกหลาย ๆ คนรู้ แต่งกจริง ๆ
สมมติถ้าตกร่องปล่องชิ้นกันจริง ๆ แล้วล่ะก็ ถ้าไม่คิดว่าทำการกุศล ก็ต้อง reality check กันตั้งแต่ต้น เคลียร์สโคปกันให้ได้ตั้งแต่ต้น และ Sign off เป็นลายลักษณ์อักษรให้ได้ ถ้าเคลียร์ไม่ได้ตั้งแต่ต้น ก็ขอให้โกยเถอะโยม เพราะมันจะไม่ใช่ศูนย์แต่จะขาดทุนเอา ดีไม่ดีก็ขาดทุนเป็นอย่างมาก
อย่าไปเชื่อลูกค้า ทุก ๆ ครั้งที่ลูกค้าบอกว่า โปรเจคตัวเองไม่มีอะไรมาก
ความน่ารักที่ 8 : Unresponsive, cannot make decisions, does not email or call back in a timely manner
ลูกค้าแบบนี้มักจะเกิดในองค์กรใหญ่ที่โปรเจคเกิดโดยผู้บริหารระดับสูง แต่เข้าร่วมงานด้วยพนักงานระดับ operation หรือ senior จำนวนมาก ซึ่งแตกต่างกับความน่ารักที่ 5 ในแง่ที่ว่า ความน่ารักที่ 8 นั้น เราอาจจะเจอกับผู้บริหารที่กระตือรือร้นในการสร้างสิ่งใหม่ ๆ คนนั้นได้บ้าง
ปัญหาจะเกิดเมื่อไม่ได้มีการกำหนดคนที่รับผิดชอบในส่วนต่าง ๆ เอาไว้ หลาย ๆ ประเด็นมันจะตกอยู่ที่ฉนวนกาซ่าที่ไม่รู้ว่าใครเป็นเจ้าภาพในเรื่องนี้กันแน่ แม่จ๋าอันนี้ตอบว่าอะไร
วิธีการรับมือคือ เล็งเอาไว้ว่าถ้าโปรเจคล่าช้าใครจะเป็นคนที่มีตำแหน่งที่สูงที่สุดที่จะเดือดร้อนที่สุดในองค์กร พร้อมกับพยายามให้ลูกค้ากำหนดคนรับผิดชอบในส่วนต่าง ๆ ให้ได้มากที่สุด รวมไปถึงคนที่ทีมงานจะเอาไว้ถามทุกเรื่องที่ไม่รู้จะเอาไปลงกับใคร เราอาจจะต้องถึงเนื้อถึงตัวบางคนหากอีเมลหรือการโทรศัพท์เป็นสิ่งที่กั้นกลางระหว่างเราเอาไว้ รวมไปถึงการแสดงไทม์ไลน์ให้ผู้เกี่ยวข้องดูเป็นระยะว่า หากไม่ได้คำตอบในเรื่องนั้นนี้ภายในวันนั้นวันนี้ งานนี้จะเน่าเบอร์ไหน ถามใจเธอดู
ทั้งนี้ทั้งนั้น ต้องคอยระวังความล่าช้าที่จะลามไปถึงเรื่องของ Budget ในส่วนต่าง ๆ ด้วย ซึ่งควรจะชัดเจนในส่วนของ Proposal ที่ลูกค้า Sign Off เรียบร้อยแล้ว
ความน่ารักที่ 9 : Indecisive, changes mind frequently, unable to articulate feedback
ลูกค้าแบบนี้มักจะเกิดจากลูกค้ารายย่อยที่ไม่รู้ว่าตัวเองต้องการอะไร นึกภาพในหัวไม่ออก มโนไม่แจ่มหรือแจ่มเกินไป กลับมากลับมาได้ตลอดเวลา นอกจากจะทำให้กระทบเรื่อง Timeline ในการพัฒนาแล้ว บางทีอาจจะกระทบถึงโครงสร้างหลักกันเลยทีเดียว Navigation ทำมาดี ๆ อยู่ ๆ เอาอะไรเพิ่มเข้ามาไม่รู้ จากที่เรียบง่าย ก็กลายเป็นรุงรัง และมักชอบใช้วิธีการโทรศัพท์แทนการอีเมลและอื่น ๆ ที่เป็นลายลักษณ์อักษร
ลูกค้าแบบนี้จำเป็นต้องมี PM (project manager) ที่แข็งแรง ไม่ทำตัวเป็นเครื่องถ่ายเอกสาร ลูกค้าว่าไงก็เอามายัดให้ทีมเดฟหมด แบบนี้ จะรวนกันภายในทีมด้วย
การตั้ง Goal และ Objective พร้อม Sign Off ในส่วนนี้ เป็นสิ่งสำคัญ (มว้าก) เช่นเดียวกับ Proposal ที่ Sign Off ไปแล้ว (หวังว่า) ในขณะที่เราโอนอ่อนผ่อนตามความลังเลของลูกค้าได้ด้วยน้ำใจคนไทยที่หยวนหยวนกัน เราก็ยังมีเอกสารชี้ให้ลูกค้าดูว่า นั่นแน่ กลับไปกลับมาอีกละน้าตะเอง ด้วย และพยายามเก็บคำพูดของลูกค้าเป็นลายลักษณ์อักษรไม่ทางใดก็ทางหนึ่ง
นอกจากนั้นการทำ Versioning ก็สำคัญ เพราะวันดีคืนดี ลูกค้าอาจจะอยากย้อนกลับไปที่การตัดสินใจหมายเลข 1 ในขณะที่ตัดสินใจเรื่องเดียวกันนี้ไปแล้ว 26 หมายเลข เราจะได้ไม่ต้องกลับมาทำใหม่อีกรอบ และพยายาม document การคุยงานทุกอย่างให้เป็นหลักฐาน เพราะลูกค้าแบบนี้มักขี้ลืมว่าเคยคิดอะไรตัดสินใจอะไรออกมา
ความน่ารักที่ 10 : Wants to handle the creative and/or production aspects to “save money”
ลูกค้าประเภทนี้ ดูท่าเมืองไทยไม่ค่อยจะมีนะ มีแต่จะมีให้ทำเพิ่มให้ในราคาเท่าเดิม แต่เมื่อไหร่ที่เจอ ความปวดหัวก็คือ งานที่ลูกค้าพยายามจะลดงบประมาณโดยการเอาไปทำเองหรือเอาไปให้คนอื่นทำน่ะ มันไม่ค่อยจะถึงมาตรฐานที่ควรจะเป็นเท่าไหร่ เช่น การส่งรูปมาในรูปแบบ doc file , content ที่หลุดคอนเซปท์ออกไปอีกโลกนึงเลยเพราะไม่ได้มาอยู่ภายใต้ Style Guide เดียวกัน ต้องการจะจัดการ content เองโดยที่ไม่ได้จัดการให้เป็นระบบระเบียบที่เอื้อกับการนำไปให้ทีมพัฒนาใช้อย่างสะดวก
ถึงแม้ว่าบางอย่างจะสอนและแนะนำลูกค้าให้ทำให้เข้าที่เข้าทางได้ แต่นั่นก็หมายถึงว่า เราต้องใช้เวลาอีกส่วนหนึ่งเพื่อไปสอนอยู่ดี ซึ่งมักไม่ได้มีการคิดเงินเพิ่ม และไม่ได้ยืดไทม์ไลน์ให้ยาวขึ้นแต่อย่างใด
ส่วนใหญ่เราจะรู้ปัญหานี้ก่อนเริ่มทำงาน เพราะต้องตกลง Budget กันก่อน จึงนับว่าไม่ใช่ปัญหาที่ใหญ่โตอะไรนัก เพียงแต่ต้องเคลียร์ตั้งแต่เนิ่น ๆ และตกลงไทม์ไลน์ที่จะต้องทำและ Sign off เป็นเรื่องเป็นราว เพราะถ้าล่าช้าเพราะลูกค้าส่งงานช้าเองขึ้นมา เราจะได้ไม่ซวย
นอกจากนี้ก็ยังมีความน่ารักอีกหลาย ๆ ประการที่เจอกัน (ส่วนการจ่ายเลทเบี้ยวจ่ายเราจะไม่สามารถนับเป็นความน่ารักได้) จะเห็นได้ว่าส่วนใหญ่การรับมือจะเกี่ยวข้องกับเอกสารล้วน ๆ ไม่ว่าจะเป็นเอกสารที่ต้อง Sign off ตกลงกันเรื่อง Goal, Objective, Requirement เบื้องต้น, สโคปงานและสิ่งที่อยู่นอกสโคปงานที่อาจเกี่ยวข้อง การจัดเก็บเอกสารและ conversation ที่เกิดขึ้นเป็นลายลักษณ์อักษร รวมถึงการ versioning ที่อ้างอิง conversation เป็นส่วนที่ PM พึงกระทำเพื่อไม่ให้เกิดความขัดแย้งโดยไม่จำเป็นกับลูกค้า และทั้งนี้ทั้งนั้น ต้องเริ่มต้นด้วยการเข้าใจเนื้องานมากพอที่จะตี Timeline และ Budget ได้ใกล้เคียงความเป็นจริง
i am IA 