Piyorot

น้อยที่สุดคือสิ่งที่เราอยากทำ

มากที่สุดคือสิ่งที่คนอื่นคาดหวังจากเรา — เพื่อนร่วมงาน ลูกค้า พาร์ทเนอร์ นักลงทุน

เราอยากให้สัญญาที่ง่ายที่สุดเพื่อผลตอบแทนที่มากที่สุด

คนอื่นอยากให้เราสัญญาในเรื่องที่ยากที่สุดเพื่อผลตอบแทนที่น้อยที่สุด

ใจเราอยากทำน้อยแต่แรงดึงดูดของโลกบีบให้เราต้องทำมากเสมอ

เราต้านทานไหวหรือไม่?

ต้านทานไหวแปลว่าเราเริ่มต้นที่จะพูดคำว่าไม่ … บ่อยขึ้น และบ่อยขึ้น

ไม่ทำ ไม่เอา ไม่ซื้อ ไม่ขาย และไม่สนใจ

ต้านทานไม่ไหวแปลว่าเราเริ่มต้นที่จะพูดคำว่าได้ … บ่อยขึ้น และบ่อยขึ้น

ทำได้ ขายได้ ซื้อได้ เปลี่ยนได้ เพิ่มได้ และอะไรก็ได้

โปรเจกต์เมเนเจอร์ที่เก่งวัดกันอย่างไร? โปรดักท์เมเนเจอร์ที่โดนเด่นมีคุณสมบัติอะไร? …

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

สัญญาให้น้อยแต่ส่งมอบให้มาก … ยังใช้ได้ผลดีเสมอในทุกยุคทุกสมัย 🔥

--

--

คำถามที่เจอบ่อยๆ … เราควรทำงานไหนก่อน?

ในบริบทของการคิดใหม่ ทำสิ่งใหม่ ทำโปรดักท์ใหม่ … เรื่องที่สำคัญที่สุดคือการลดความเสี่ยง

ความเสี่ยงแปลว่าสิ่งที่ยังไม่เกิดขึ้น มันคือความไม่แน่นอน มันคือเรื่องที่เราไม่รู้จักและไม่เข้าใจมันดีพอ

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

“ตอนนี้อะไรคือสิ่งที่เราไม่รู้ อะไรคือความเสี่ยงที่ใหญ่หลวงที่สุด?” เช่น

  • ไม่รู้ว่าเทคโนโลยีนี้จะเวิร์คมั้ย?
  • ไม่รู้ว่าไอเดียบนกระดาษที่ดูน่าตื่นเต้น … เมื่อทำออกมาแล้วมันจะว้าวขนาดนั้นมั้ย?
  • ไม่รู้ว่าลูกค้าจะอยากใช้ระบบนี้มั้ย?

ทั้งหมดคือการลองผิดลองถูกให้เข้าใจมากขึ้น เพื่อทำเรื่องที่ไม่รู้ให้รู้

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

--

--

ทากส์ ซับทากส์ … ต้องละเอียดขนาดไหน?

คำตอบจากประสบการณ์ของตัวเองคือไม่มีกฎตายตัว สำคัญที่หลักการมากกว่า

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

เราไม่ควรรอให้มีคนอื่นมอบหมายทากส์มาให้เรา เราถึงจะเริ่มขยับตัว

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

  1. ฉันมีงานเลี้ยงที่บ้านเย็นพรุ่งนี้
  2. ฉันคิดว่าจะทำอาหารคาว 3 อย่าง อาหารหวาน 2 อย่าง
  3. ฉันคิดว่าน่าจะเป็นพาสต้า, ปลาอบเกลือ, ซี่โครงหมูบาร์บีคิว … แล้วก็เค้กแครอทกับพายแอปเปิ้ล

เอาแค่นี้ก่อน 3 ชั้น … เคลียร์มั้ย? เกือบๆ คำถามคือ

  1. พาสต้าอะไร? — เอาเป็นคาเปลลินี่ซอสเพสโต้ละกัน
  2. ปลาอะไร? — แซลม่อนน่าจะดี

พอแล้ว เราในฐานะหัวหน้าทีม เรากำหนดขอบเขตของงานแค่นี้ … ที่เหลือคือหน้าที่ของคนทำ (พ่อครัว แม่ครัว) พวกเขาเลือกได้ว่าจะแบ่งงานให้เป็นทาสก์ที่ยิบย่อยลงไปอีกหรือไม่

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

มันไม่จำเป็นเลย ซับทากส์คือเรื่องเสียเวลาถ้ามันไม่ช่วยให้เราเห็นภาพรวมว่าต้องทำอะไรกันแน่

อย่าเขียนเพียงเพราะตำราสั่งให้เขียน อย่าเขียนเพื่อแค่การลงเวลาทำงาน อย่าเขียนเพียงเพื่อเอาไว้แทรคงาน … มีพ่อครัวคนไหนบ้างที่หั่นกระเทียมเสร็จแล้วต้องมารายงานหัวหน้าหรือมาติ๊กถูกที่เช็คลิสต์ว่าทำงานนี้เสร็จแล้ว

ทากส์ไม่ควรเป็นจุดเริ่มต้น ทากส์ไม่ควรถูกกำหนดขึ้นมาแบบลอยๆแล้วส่งต่อให้คนอื่นทำ

ทากส์ต้องมาจากคนทำ … คนทำที่เข้าใจดีว่าจะทำทากส์นี้ไปเพื่ออะไร

--

--

สถานภาพในจังหวะใดๆในการทำงาน เรากำลังมองหาเดดไลน์ปลอมๆในสองรูปแบบ

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

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

มันคือเดดไลน์ปลอม ทั้งสองด้าน และมีเราเพียงคนเดียวที่รู้ว่าเดดไลน์จริงคือวันไหน

คำถามคือ … ความไม่โปร่งใสตรงนี้ช่วยอะไรเราได้จริงหรือไม่?

หลายครั้งเราต้องการมันเพราะคำว่า “เผื่อเหลือเผื่อขาด” บีบคนทำงานเข้ามาแล้วยืดคนรับงานออกไป ในกรณีที่ยกตัวอย่างมาเราจะมีเวลาแก้ไขความผิดพลาดได้สองเดือน (พัฒนาสองเดือนแต่ส่งงานภายในสี่เดือน) … สิ่งนี้บอกอะไรเรา?

  1. เราไม่เชื่อใจทีมพัฒนา?
  2. เราไม่แน่ใจในการวางแผนของตัวเอง?

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

สองเดือนยืดมาเป็นสามเดือน …​ ทีมพัฒนาจะเริ่มเห็นว่า “อ่าว เกินมาเป็นเดือนแล้วไม่เหตุมีปัญหาอะไรใหญ่โตเกิดขึ้นเลย แสดงว่าที่บอกไว้ตอนนั้นก็โกหกกันหละสิ”

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

เดดไลน์ปลอมอาจจะเวิร์คแต่เดดไลน์ปลอมอาจจะไม่เวิร์ค

มันเวิร์คเพราะการเตรียมการรองรับความผิดพลาด มันไม่เวิร์คเพราะความไม่เชื่อใจระหว่างคนในทีมเดียวกันเอง

มันอาจจะเวิร์คแค่ตอนนี้และไม่มีทางที่มันจะเวิร์คตลอดไป

เดดไลน์ปลอมคือสัญลักษณ์ของความอ่อนแอในความสัมพันธ์กับคนในทีม

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

เดดไลน์ปลอมจำเป็นสำหรับคนนอก … เราควรเลือกพูดเรื่องจริงกับคนในและมีความลับบ้างกับคนนอก 😌

--

--

เราควรทำมากแค่ไหนกับเวอร์ชั่นแรก?

  1. ลูกค้าน้อยที่สุด เพราะ
  2. ฟีเจอร์จะน้อยที่สุด และ
  3. จะใช้คนน้อยที่สุด และ
  4. จะเขียนโค๊ดน้อยที่สุด และ
  5. จะสับสนในการสื่อสารน้อยที่สุด และ
  6. จะซัพพอร์ตน้อยที่สุด และ
  7. จะใช้เวลาน้อยที่สุด

น้อยที่สุดดีกว่าเสมอ … น้อยไม่ได้แปลว่าแย่หรือมาตรฐานต่ำ

น้อยคือการคัดเลือกมาอย่างดี ทั้งลูกค้า ฟีเจอร์ ทีมงาน เทคโนโลยี

น้อยคือความอยู่รอดของทีมเล็กๆ

ให้เวอร์ชั่นแรกมันไปได้สวยก่อน … แล้วค่อยคิดจะไปต่อเฟสสอง

--

--

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

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

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

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

องค์กรใหญ่ถูกสร้างมาเพื่อลดโอกาสการดีเลย์ลงให้ได้มากที่สุด องค์กรเล็กๆอย่างเราเทียบไม่ได้ในเรื่องนี้ ดังนั้นมันแปลว่า … จงภูมิใจในการดีเลย์ของตัวเอง 😑

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

ถ้างานจะไม่เสร็จ ถ้าเราช้ากว่ากำหนด … เราต้องบอกคนที่เกี่ยวข้อง

ไม่จำเป็นต้องรอให้พวกเขาถาม

ไม่จำเป็นต้องปิดบัง … เพราะความจริงจะปรากฎขึ้นในไม่ช้า … ซื่อสัตย์ไว้ก่อนดีกว่า

ไม่จำเป็นต้องให้คำสัญญาที่เรารู้อยู่แก่ใจว่าทำไม่ได้ … ความจริงใจขายได้เสมอ

--

--

บางทีการที่โปรเจกต์ดีเลย์เพราะคำว่า “อีกนิด”

  • มันติดพัน ฟีเจอร์นี้มันเกี่ยวข้องกับตัวที่แล้ว ขอทำเพิ่มอีกหน่อย
  • ไหนๆก็ไหนๆ บั๊กนี้ไม่ยาก แก้ไปเลยแล้วกัน
  • มีเวลาเหลือนิดนึง เอามาปรับหน้าจอนี้ก่อนนะ

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

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

กับคำถามที่ว่า “ทำไมงานนี้ไม่ได้ทำสักที?”

คำตอบคือเพราะเหตุนี้

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

การจัดลำดับความสำคัญของงานคือเรื่องสำคัญมาก … โปรเจกต์ดีเลย์ไม่ใช่เพราะไม่ทำงานแต่ทำผิดงานซะมากกว่า 👋

--

--

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

การตั้งเดดไลน์นั้นสำคัญอยู่เรื่องหนึ่ง …

นั่นคือมันเป็นเครื่องมือที่ช่วยบอกเราได้ดีว่า เมื่อไรควรจะหยุด

หยุดเรื่องนี้ หยุดฟีเจอร์นี้ หรือแม้หยุดทำโปรดักท์นี้แล้วปิดงานไว้เท่าที่ทำเสร็จ

มันเป็นการลองเดินลุยไปข้างหน้าด้วยความพยายามอย่างเต็มที่ แต่เมื่อมันไม่เวิร์ค … มันก็ไม่แปลกที่จะหยุด

มันเป็นเรื่องดีด้วยซ้ำ

เดดไลน์ช่วยให้เราต้องจัดลำดับความสำคัญตลอดเวลา และเดดไลน์คือปฏิกิริยาลูกโซ่

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

ในกรณีนี้ … งานหลังสำคัญกว่างานแรก เดดไลน์อันที่สองสำคัญกว่า นั่นแปลว่าถ้าวันนี้เราคิดว่างานชิ้นแรกยังไงๆก็ไม่เสร็จวีคนี้ และไม่ว่ายังไงก็ไม่น่าจะเสร็จเร็วๆนี้

หยุดเลยดีกว่า … หยุดแล้วจบงานไว้เท่าที่มีตอนนี้ (ถ้าเราทำซอฟต์แวร์อย่างมีกระบวนการจริงๆ อย่างน้อยเราก็จะมีฟีเจอร์บางส่วนที่ทำงานได้อย่างสมบูรณ์)

เดดไลน์ไม่ได้มีไว้เพื่อตะบี้ตะบันทำๆๆ ทำให้เสร็จตามนั้น

เดดไลน์มีไว้ให้เราสำรวจตัวเองว่าเมื่อไรจะหยุด

เดดไลน์มีไว้ให้เราต้องจัดลำดับความสำคัญของงานโดยรวมตลอดเวลา

--

--

เมื่อไรจะเสร็จ?

คำถามที่เจอประจำ กับคำตอบที่ไม่เคยจะแม่นยำ

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

“เสร็จเมื่อไรไม่รู้ แต่รู้ว่าไม่น้อยกว่าสามเดือนแล้วก็ไม่เกินหกเดือนแน่ๆ” 🤷🏻‍♀️

เออ เข้าท่าจะตายตอบแบบนี้

มันแสดงให้เห็นว่าเด็กคนนี้เข้าใจคำว่าโปรเจกต์ เมเนจเม้นท์ดี

  • การประเมินคือประเมิน (แปลว่าเดานั่นแหละ)
  • การให้คำสัญญาแบบเป๊ะๆคือความเสี่ยง
  • การมองระยะเวลาในการทำงานควรมองเป็นช่วงเวลา
  • ช่วงเวลาคือกรอบที่มีคำว่า “อย่างน้อย” และ “อย่างมาก”
  • เป็นการบอกกลายๆว่าถ้าอยากให้เสร็จเร็วก็ลดปริมาณและความซับซ้อนของงานลงสิ

ผมเองก็เป็นแฟนพันธุ์แท้ในมองงานแบบนี้ เพราะมันทำให้ทุกคนในทีมมองโลกตามความจริง

ในทีมผมเองจึงวางภาพกว้างๆ … แบบกว้างมากๆว่า ภายในสามเดือนนี้อยากจะเห็นอะไรเสร็จออกมาบ้าง ไม่ใช่รายละเอียด ไม่ใช่ลิสต์ของฟีเจอร์ แต่เป็นระดับโปรดักท์ เช่น ภายในไตรมาสแรกปีนี้

  • อยากได้ระบบแรกที่พร้อมขาย ทั้งเวป และแอป
  • อยากได้ระบบที่สองที่เดโม่ได้ เอาเวป กับแอปสำหรับแอดมิน
  • อยากได้ระบบที่สามที่เดโม่ได้ เอาเวป กับแอปสำหรับผู้ใช้หลัก

แค่นี้ ที่เหลือคือการแก้ปัญหารายสัปดาห์และรายวัน … นี่คือโปรเจกต์เมเนจเม้นท์ในโลกแห่งความจริง

--

--

จริงหรือไม่ที่เราต้องการ “แผน” เพื่อบรรลุเป้าหมาย?

ไม่จริง

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

ทำไม?

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

เมื่อเราคิดว่าเราวางแผนเสร็จแล้ว … แผนนั้นก็หมดอายุทันที

เพราะงานไม่ใช่แผนที่เป็นอดีต งานคือปัจจุบันและอนาคต

เพราะเป้าหมายคืออนาคต นั่นแปลว่าเราต้องการงานเพื่อทำให้เป้าหมายเป็นจริง ไม่ใช่แผน

คำถามคือจะทำอย่างไรให้เราทำงานได้ดีที่สุดเพื่อบรรลุเป้าหมายที่ตั้งไว้

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

ข้อมูลคือพระเจ้าในกรณีนี้

เราไม่ต้องการแผนที่ตายตัว เราต้องการเป้าหมาย (Goal) หลักชัยสำคัญ (Milestone) และความฉลาด (Information — Intelligence — Dashboard)

นั่นคือหน้าที่ของเรา (ในฐานะผู้นำหรืออะไรก็ตามแต่) ที่ต้องจัดหามาให้ทีมให้ได้

--

--

Piyorot

Piyorot

A member of Mutrack and Inthentic. I lead, learn, and build with vision, love and care. https://piyorot.com