เหมือนมองหนังสือ ไลเซนส์ และฮาร์ดแวร์เป็น วัสดุสิ้นเปลือง แบบเดียวกับปากกาหรือกระดาษ วิธีนี้มักใช้ได้กับซอฟต์แวร์ local ขนาดเล็กอย่าง IDE
แต่ต้องมีเงื่อนไขก่อนว่าไว้ใจให้นักพัฒนามีสิทธิ์แอดมินได้ หรือฝ่าย IT ของบริษัทอนุญาตให้ติดตั้งได้
จะให้ทุกคนมีงบเล็กๆ ของตัวเอง หรือจัดการในระดับทีม/แผนกก็ได้ แต่พอถึงจุดที่ต้องรวมศูนย์ IT ทั้งบริษัท วิธีนี้มักใช้ไม่ค่อยได้ผล
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เกือบถูกแล้ว แต่ผมคิดว่าฝ่ายขายหรือฝ่ายการเงินเองก็แทบไม่มี อำนาจอนุมัติการซื้อ แบบนั้นเหมือนกัน ดังนั้นทุกคนจึงลงเอยด้วยการใช้เครื่องมือที่บริษัทอนุญาตหรือแพ็กเกจฟรี แล้วสุดท้ายก็ต้องไปขายให้หัวหน้าฟัง
ต้องโน้มน้าวด้วยเรื่องการประหยัดเวลา ทำให้โปรเจกต์โปร่งใสมากขึ้น และลดข้อจำกัด
เป็นไปได้ว่าที่ Excel ถูกใช้อย่างแพร่หลายก็เพราะเหตุนี้ด้วย เพราะมันเป็นเครื่องมือที่ทรงพลังที่สุดที่ IT ของบริษัทอนุญาตให้ใช้
ถ้าลองทำงานในฝ่ายขายหรือฝ่ายการเงินแล้วขออนุญาตติดตั้ง WSL ลงในพีซีดูจะเข้าใจเอง เหตุผลที่เว็บแอปได้รับความนิยมก็เพราะ IT ของบริษัทต้องรู้ก่อนถึงจะบล็อกได้
ผู้จัดการการตลาดอาจใช้บัตรตัวเองจ่าย Basecamp ได้ แต่ถ้าจะนำเครื่องมือแบบ self-hosted เข้ามา เรื่องจะใหญ่ทันทีเพราะต้องผ่านนโยบาย IT ที่ว่า “คอมพิวเตอร์เราจัดการเอง และวิธีทำงานก็เรากำหนดเอง”
มันรวมอยู่ในทุกไลเซนส์ m365 และไลเซนส์ถาวรก็มีราคาค่อนข้างถูกมาเป็นเวลานาน
พอมีคนพูดว่าควรอนุญาต WSL ให้ทีมขาย ก็อดถามไม่ได้ว่าเคยทำงานกับพนักงานขายจริงหรือเปล่า ในบริษัท 99% ต่อให้เป็นเซลส์ที่เก่งเทคที่สุดก็ยังแทบทำได้แค่ส่งไฟล์แนบอีเมลโดยไม่มีคนช่วย เลยไม่รู้ว่าจะใช้ WSL ไปทำอะไร
การต้องอนุมัติรายการซื้อยิบย่อยพวกนี้ทั้งหมดเป็นงานที่หนักมาก และถ้าไม่ตรวจสอบก็จะมีพวก subscription ที่ไม่ได้ใช้งานสะสมอยู่ทั่ว หรือซื้อของที่แทบไม่ช่วยบริษัทเลยจำนวนมาก
ในทางกลับกัน ฝ่ายการตลาดดูจะมีอำนาจซื้อมากพอสมควร ซึ่งน่าจะเพราะลักษณะงานเกี่ยวข้องกับการซื้อของสารพัดอยู่แล้ว
แค่แอปตัวเดียวโดนเจาะก็อาจทำให้ IT ทั้งบริษัทเสี่ยงได้ และแม้จะใช้การแยกส่วนหรือ zero trust ก็ยิ่งเพิ่ม attack surface และต้นทุนด้านความปลอดภัย
ในความเป็นจริง การซื้อแอป self-hosted เป็นส่วนที่ง่าย ส่วนที่ยากคือทำให้มันรันได้เสถียรทุกวันตลอดช่วงเวลาที่ธุรกิจต้องใช้ และบางกรณีก็มีกฎหมายบังคับให้เก็บข้อมูลไว้นานด้วย
แม้จะเป็นเครื่องมือที่ IT ฝั่งหน้างานร้องขอเอง บางส่วนอาจพอจัดการด้านเทคนิคได้ แต่บ่อยครั้งก็ทำไม่ได้เพราะไม่มีเวลา หรือเป็นแค่นักพัฒนา ไม่ใช่ผู้ดูแลระบบหรือเครือข่าย
สุดท้ายจึงต้องใช้ sandbox ที่แยกจาก IT ของบริษัท หรือยอมทิ้งความสะดวกอย่าง backup กับ AD ไป หรือไม่ก็ทำและดูแลเองแบบ shadow IT
เพราะแบบนี้เอง หนึ่งในเหตุผลที่ SaaS และคลาวด์ เติบโตก็คือช่วยผลักต้นทุนเหล่านี้ออกไปภายนอก
ถ้าต้องสู้เพื่อซื้อหนังสือราคา 50 ดอลลาร์ ก็คงเลือกบริษัทผิดแล้ว
แต่ก็มีกรณีที่นักพัฒนาบางคนสร้างบัญชีไม่เป็นทางการด้วยบัตรเพื่อทดสอบ Notion ภายใน แล้วเอาเอกสารสรุปสำคัญไปทำไว้ในนั้นก่อนส่งลิงก์ต่อ
ครึ่งบริษัทที่พยายามเปิดดูลิงก์นั้นก็ไปสร้างบัญชีกันแบบกลาย ๆ และเดือนถัดมา CFO ก็ได้รับ บิล 10,000 ดอลลาร์
เรื่องเล่าว่าไม่ควรให้นักพัฒนามีอำนาจซื้อ มักเริ่มต้นประมาณนี้
ที่บริษัท SaaS หลายแห่งไม่ค่อยมีตัวเลือกจ่ายล่วงหน้าหรือเพดานค่าใช้จ่ายแบบคงที่ ก็มีเหตุผลของมันอยู่ มันแทบจะเป็นการหลอกลวง
เลยยากจะเชื่อว่านี่คือ “จุดเริ่มต้นของเรื่องที่ทำให้นักพัฒนาไม่มีอำนาจซื้อ”
ตัวอย่างเช่น เครื่องมือกระจัดกระจายจนค้นหาข้อมูลด้วยการค้นครั้งเดียวไม่ได้ หรือแต่ละทีมต้องล็อกอินแยกกันคนละเครื่องมือ
ถ้าทีมต่าง ๆ ต่างคนต่างดูแลเครื่องมือที่มีทรัพย์สินทางปัญญาของบริษัทอยู่ข้างใน พอองค์กรต้องการทำ SOC compliance มันจะกลายเป็นฝันร้ายด้านคอมพลายแอนซ์
แต่การซื้อหนังสือหรือสื่อการเรียนรู้ ผมมองว่าโอเค
จากมุมของคนที่เคยตัดสินใจค่าใช้จ่ายด้านฮาร์ดแวร์ ซอฟต์แวร์ และบริการทางวิศวกรรมมากกว่า 100 ล้านดอลลาร์ต่อไตรมาส ถ้าคุณกำลังสร้างเครื่องมือสำหรับนักพัฒนา สิ่งแรกคือต้องทำให้บรรดานักพัฒนาปัจจุบันรู้สึกว่ามันมีประโยชน์มากและพร้อมออกหน้าเชียร์อย่างจริงจัง
ต้องไม่ไปแตะ รายการที่มีสิทธิ์วีโต้ อย่างสัญญาที่ไม่โปร่งใส การ lock-in ความปลอดภัยของข้อมูล/ความเป็นส่วนตัว และการผสาน single sign-on/การยืนยันตัวตน
ราคาก็ต้องสมเหตุสมผล การตั้งราคาที่แปรผันเชิงเส้นตามตัวแปรบางอย่างอาจฟังไม่ขึ้นในสเปรดชีตของฝ่ายการเงิน คิดเงินรายนักพัฒนาต่อเดือนนั้นเข้าใจง่าย ไฟลอยทั้งองค์กรยิ่งดีกว่า และบางกรณีราคาเหมาจ่ายไม่จำกัดทั้งองค์กรก็เหมาะกว่า
แม้ในโมเดลแบบสุดท้าย ก็ยังผลักต้นทุนสิ้นเปลืองอย่าง cloud compute หรือ storage ต่อไปได้ตามเดิม และถ้าสามารถ deploy ลงบัญชีคลาวด์ของลูกค้าโดยตรง ก็จะแก้ปัญหาเรื่องความปลอดภัยข้อมูลและความเป็นส่วนตัวได้ด้วย
ควรมี การควบคุมต้นทุน อย่างเพดานบิล เพดานการใช้งาน การจำกัดการตั้งค่าที่จะก่อให้เกิดค่าบริการแพง และรายงานการใช้งานที่ละเอียดเพียงพอ
ถ้าทำได้ดี ก็อาจไปถึงสัญญาหลายปีที่มี committed spend ได้ ต้องรักษาความน่าเชื่อถือของบริการ และทบทวนกับลูกค้ารายใหญ่ทุกไตรมาสเพื่อดูทั้งความพึงพอใจและความต้องการที่ยังไม่ถูกตอบสนอง
ยังสามารถมีบริการมืออาชีพขั้นสูงอย่างวิศวกรประจำหรือซัพพอร์ตเฉพาะทางแล้วคิดเงินเพิ่มได้ ซึ่งกำไรสูง และบางครั้งก็เป็นกุญแจสำคัญในการชนะหรือต่ออายุลูกค้าบางราย
เพราะภายในบริษัทลูกค้า ตัวผลิตภัณฑ์อาจเป็นที่ถกเถียงและมีฝ่ายต่อต้านที่ทำให้การนำไปใช้ล้มเหลวได้ ดังนั้นถ้าให้ทีม professional services รับหน้าที่ integration/implementation ช่วงแรก ก็จะช่วยลดการแทรกแซงจากด่านเฝ้าประตูของ IT และพาผลิตภัณฑ์ไปถึงมือผู้ใช้จริงได้
สำหรับผลิตภัณฑ์ที่ลูกค้าเชื่ออย่างแรงว่าทำเองได้ อย่าพยายามขายให้หนักเกินไป ต่อให้การประเมินนั้นผิด ตอนแรกคุณอาจชนะ แต่สุดท้ายก็มีแนวโน้มจะแพ้อยู่ดี
ปัญหาคือจะประเมิน ROI ของการสร้างเทียบกับการซื้อ เมื่อไร
การซื้อผลิตภัณฑ์ที่มีต้นทุน integration สูงมาก จริง ๆ ก็แทบไม่ต่างจากการสร้างเอง เพราะต้องใช้เวลานักพัฒนาไปกับ integration และเวลานั้นเดิมก็เอาไปทำอย่างอื่นหรือทำตัวผลิตภัณฑ์เองได้
แน่นอนว่าถ้าเห็นประเด็นนี้ตั้งแต่ช่วง proof of concept integration ก็ดี แต่แม้ในขั้นนั้นก็ยังต้องใช้เวลานักพัฒนาในการลงมืออยู่ดี
แล้วแต่บริษัท บริษัทเก่าที่เคยทำมีนโยบายว่า “หนังสือ ไลเซนส์ หรือแม้แต่ฮาร์ดแวร์อะไรก็ตามที่ช่วยให้งานง่ายขึ้น ถ้าจำเป็นก็ซื้อไปเลย ต้นทุนการบริหารจัดการ ที่ต้องใช้ตัดสินใจแพงกว่า ดังนั้นค่าเริ่มต้นคืออนุมัติทันที”
ถามว่านักพัฒนาแห่กันซื้อไม่ยั้งไหม ก็ไม่ และซื้อกันในระดับพอๆ กับก่อนมีนโยบายนี้ ชีวิตการทำงานจริงสะดวกขึ้นมาก
แต่ต้องมีเงื่อนไขก่อนว่าไว้ใจให้นักพัฒนามีสิทธิ์แอดมินได้ หรือฝ่าย IT ของบริษัทอนุญาตให้ติดตั้งได้
จะให้ทุกคนมีงบเล็กๆ ของตัวเอง หรือจัดการในระดับทีม/แผนกก็ได้ แต่พอถึงจุดที่ต้องรวมศูนย์ IT ทั้งบริษัท วิธีนี้มักใช้ไม่ค่อยได้ผล
ถ้าปล่อยไป 10 หรือ 20 ปี ภาพที่เห็นอาจต่างออกไปมาก อาจมี ต้นทุนที่เพิ่มขึ้น แบบช้าๆ และมองไม่เห็นสะสมขึ้นเรื่อยๆ และอาจกลายเป็นวัฒนธรรมที่คนซึ่งใช้น้อยกว่าต้องซื้อของเพื่อไม่ให้ตัวเองดูเหมือนประหยัดจนทำให้คนอื่นดูฟุ่มเฟือย
มีกลไกละเอียดอ่อนหลายอย่างที่ผลักให้ต้นทุนสูงขึ้น จึงต้องมีสิ่งที่ช่วยดันกลับในทางตรงข้าม ผมมองว่านี่ยังเป็นปัญหาที่แก้ไม่ตก
อาจตั้งเพดานงบที่ค่อนข้างกว้าง แต่บอกให้ชัดว่าไม่ได้หมายความว่าต้องใช้ให้หมด และอาจมีกติกาว่านำเงินส่วนหนึ่งของงบที่เหลือปลายปีไปบริจาคให้ที่ที่ทุกคนยอมรับว่าเหมาะสม
ประมาณว่า “ซื้อหนังสือได้ แต่จำไว้ว่าหนังสือเล่มนั้นทำให้เงินบริจาคให้ลูกม้าลดลง 5 ดอลลาร์” ถ้าเปลี่ยนเป็นพะยูน ผมอาจเสี่ยงต้องทำงานบน Chromebook
อย่างดีที่สุดก็มักไม่มีความสามารถนัก ลดจำนวนผู้จัดการลงสักไม่กี่คนแล้วเอาเงินเดือนส่วนนั้นมาเป็น งบตามดุลยพินิจ จะดีกว่า ทุกฝ่ายได้ประโยชน์
ผมไม่ต้องรู้ขั้นตอนการสั่งซื้อหรือจัดส่งของบริษัทเลย เลยคิดว่านี่เป็นวิธีที่ดีที่สุดเท่าที่เคยเจอ
ตอนเป็นพนักงานเคยเจอปัญหานี้ครั้งหนึ่ง ผมอยากได้ ThinkPad แต่ผู้บริหารยืนกรานจะเอา Dell ห่วยๆ สุดท้ายก็ได้ ThinkPad
นอกนั้นถ้าขอหนังสือหรือเครื่องมือก็มักได้ตามขอ แม้แต่คีย์บอร์ดแยกราคาแพงก็ยังได้
ตอนนี้พอมาเป็นฟรีแลนซ์ก็ซื้อสิ่งที่ต้องใช้เองเลย ซึ่งจริงๆ แล้วไม่ได้ต้องการอะไรมากนัก
“เครื่องมือสำหรับนักพัฒนา” ที่มีประโยชน์มากพอให้ยอมจ่ายเงินจริงๆ มีไม่มาก และที่คุ้มพอจะผนวกเข้ากับ workflow ของผมยิ่งมีน้อยกว่า ประเด็นสุดท้ายนี่สำคัญขึ้นเรื่อยๆ ตามกาลเวลา
ได้ Dell ห่วยๆ มา เครื่องพัง แล้วก็ได้ Dell ห่วยๆ อีก เครื่องพังอีก แล้วก็ได้ Dell อีก
เขาจะบอกว่า “เรามีสัญญากับ Dell เท่านั้น” แต่พอถามกลับว่าแล้วทำไมถึงไปทำสัญญากับ Dell ตั้งแต่แรก ก็จะเงียบกันไป แล้วสมองถึงค่อยเริ่มทำงาน
แล้วคุณก็จะตระหนักว่าช่วงที่ Dell พังคือช่วงเวลาที่ดีที่สุดในชีวิต เพราะกว่าจะฝ่าด่านใบสั่งซื้อและการเมืองเรื่องการสั่งซื้อหลายชั้นจนได้เครื่องใหม่มา ต้องใช้เวลา 5 วัน และระหว่าง 5 วันนั้นคุณก็ทำอะไรไม่ได้เลยเพราะนโยบายความปลอดภัยสุดโหดของบริษัท
ก็เลยได้นอน 5 วัน ติดต่อเพื่อนๆ และกลับมาเป็นมนุษย์อีกครั้ง
ผมรัก Dell ไม่เอา ThinkPad แล้ว
ส่วนเครื่องใช้ส่วนตัวผมใช้ MacBook
เคยทำงานที่บริษัทวิศวกรรมแห่งหนึ่งซึ่งเป็นบริษัทลูกที่ขับเคลื่อนด้วยฝ่ายขาย
ช่วงแรกเลี้ยงมื้อเที่ยง 100 ดอลลาร์ได้สบาย แต่ซื้อการ์ดราคา 30 ดอลลาร์สำหรับคอมพิวเตอร์ของผมกลับไม่ได้
กลับกัน ที่บริษัทแม่ซื้ออุปกรณ์ทดสอบราคา 5,000 ดอลลาร์ได้ง่ายมาก แต่ถ้าจะพาใครไปกินร้านฟาสต์ฟู้ดต้องกรอกฟอร์มสามชุด
พอใกล้หมดวาระงาน ท้ายที่สุดทั้งสองที่ก็แทบทำอะไรไม่ได้เลยถ้าไม่มีแบบฟอร์มนั้น
บริษัทเครื่องมือสำหรับนักพัฒนาที่ประสบความสำเร็จจำนวนมากหาเงินด้วยการ ทำการตลาดกับหัวหน้า ไม่ใช่นักพัฒนา และไม่ใช่แค่ในสายเทคนิค วงการอื่นก็เหมือนกัน
ถ้าพยายามซื้อของที่อยู่นอกขอบเขตหน้าที่ตัวเอง มันจะยุ่งยากแบบไร้เหตุผลมาก
ช่วงหลังบริษัทบอกว่า “มีบัตรบริษัทก็ใช้ไป” และค่าใช้จ่ายที่เกี่ยวกับอีเวนต์ก็มี EVP อนุมัติให้ แม้จะไม่ใช่เรื่องปกติ แต่ผมประทับใจที่พวกเขารู้ว่าบางครั้งต้องตัด ขั้นตอนราชการ ทิ้ง
ครั้งหน้าถ้าผมเบิกค่าใช้จ่ายธรรมดาๆ ก็คงต้องไปเถียงกับฝ่ายบัญชีเรื่องใบเสร็จแท็กซี่ 20 ดอลลาร์ที่ไม่มีต้นทางกับปลายทางแน่
ผมซื้อลิขสิทธิ์ซอฟต์แวร์เองแล้วไปจัดการในภาษี วิธีนี้ช่วยเลี่ยงการประหยัดแบบหลอกๆ ได้
การหาซื้อเครื่องมือที่เหมาะและราคาไม่แพงด้วยตัวเองทำให้ผมได้รางวัลในที่ทำงาน กลายเป็นคนที่ขาดไม่ได้ในบางโปรเจกต์ ได้ขึ้นเงินเดือน และเลือกงานที่อยากทำได้
Jetbrains license ของผมเป็นตัวอย่างชัดเจน ผมนึกไม่ออกเลยว่าจะรีแฟกเตอร์โค้ดโดยไม่มีมันได้อย่างไร
ถ้าบริษัทหยุดพยายามประหยัดต้นทุนแบบนี้ คู่แข่งในที่ทำงานของผมก็คงจะมีมากขึ้น
นายจ้างเก่าของผมเคยจ่ายค่าเดินทางต่อไมล์ต่ำ ผมเลยเอาส่วนต่างไปขอในแบบภาษีเป็นประจำ
แต่กับซอฟต์แวร์ ผมไม่แน่ใจว่าเกณฑ์การพิจารณาว่าเป็นค่าใช้จ่ายที่ยอมรับได้จะใช้แบบไหน
เพราะบริษัทส่วนใหญ่ไม่ยอมซื้อซอฟต์แวร์ที่ถูกต้องเหมาะสมกับงานให้ ผมเลยกลายเป็นคนที่ทำงานได้มีประสิทธิภาพที่สุดในทีม เพราะต่างจากคนอื่นตรงที่ผมทำได้เร็วและมีประสิทธิภาพ
ถ้าสามารถนำขึ้น Azure, AWS, Google Cloud ได้ เรื่องก็จะเปลี่ยนไป
แม้แต่ดินสอแท่งเดียวยังซื้อไม่ได้ถ้าไม่มีการอนุมัติ แต่บน คลาวด์ ของบริษัทกลับใช้เงินหลายพันดอลลาร์ได้โดยไม่มีใครถาม
แต่ครั้งนี้เขากลับเลือกใช้บริการ AWS ที่มีค่าใช้จ่ายเกิน 1,000 ปอนด์ต่อเดือน
พอได้รับใบเรียกเก็บเงินจากบัตรก็กลายเป็นปัญหาใหญ่ และตอนนั้นค่าบริการของเดือนถัดไปก็เกิดขึ้นไปมากแล้ว
หลังจากนั้นเลยต้องควบคุมให้เข้มงวดยิ่งขึ้น
แต่ถ้าซื้อไลเซนส์องค์กร ก็สามารถคืนทุนได้ทันทีจากเงินที่ประหยัดได้ เลยรู้สึกกดดันว่าควรลอง แม้มันจะไม่ใช่งานหลักของผมก็ตาม
terraform applyเข้ากับ ขั้นตอนอนุมัติของ SAP ได้โมเดลธุรกิจที่ให้นักวิศวกรรมเป็นผู้ตัดสินใจนั้นเป็นไปได้มากพอสมควร แต่จะจำกัดอยู่กับเครื่องมือที่นักวิศวกรรมสามารถทำ การปรับให้เหมาะสมเฉพาะจุด ได้โดยไม่ส่งผลโดยตรงนอกขอบเขตนั้น
IDE เป็นตัวอย่างที่ดีที่สุด ต่อให้บริษัทอนุญาตให้นักวิศวกรรมแต่ละคนเลือก IDE ส่วนตัวเพื่อเพิ่มประสิทธิภาพของตัวเอง ผลกระทบโดยรวมจากการตัดสินใจทั้งหมดนั้นก็อาจยังรับได้ ซึ่ง Jetbrains แสดงให้เห็นแล้ว
แต่ไม่ใช่ว่าเครื่องมือทุกอย่างจะเป็นแบบนั้น ข้อความต้นฉบับยกตัวอย่างที่อยู่ในหมวดที่สอง เช่น Redis, Terraform, AWS
ต่างจาก IDE เมื่อการตัดสินใจรายบุคคลในเรื่องฐานข้อมูล การจัดการโครงสร้างพื้นฐาน และโครงสร้างพื้นฐานคลาวด์แพร่กระจายออกไป มันจะกลายเป็นปัญหา บริษัทต้องดูแลสแตกที่หลากหลายเกินไป และผู้ขายก็ไม่สามารถทำสัญญาองค์กรที่มีความหมายได้เพียงเพราะบางทีมเลือก Redis
เพราะแบบนั้นจึงจำเป็นต้องมี มาตรฐานกลาง ในระดับหนึ่ง และเมื่อถึงจุดนั้น ผลกระทบของการเลือกและขนาดของไลเซนส์ก็ใหญ่ขึ้น จนไม่ใช่แค่ผู้นำฝั่งวิศวกรรมที่อยากมีสิทธิ์ออกเสียง แต่ฝ่ายการเงินก็ต้องการมีส่วนร่วมด้วย ซึ่งก็มีเหตุผลสมควร
และทันทีที่ฝ่ายการเงินเข้ามา คุณก็ต้องอธิบายให้เหตุผลของการเลือกด้วยภาษาที่นักวิศวกรรมส่วนใหญ่รับมือได้ยาก
อำนาจการซื้อของผมเป็นแบบนี้ ผมจะบอกหัวหน้าว่า “ถ้าซื้อเครื่องมือสำหรับนักพัฒนาตัวนี้ เราจะประหยัดเวลาของนักพัฒนาได้ X ชั่วโมง”
ตรงนี้แค่ให้ X มากพอเมื่อเทียบกับราคาของเครื่องมือก็พอ วิธีนี้ใช้ได้ผลพอสมควร เลยใช้บ่อย จนตอนนี้หัวหน้าเริ่มมองอย่างสงสัยแล้ว
ไม่ได้แปลว่าไม่มีเครื่องมือที่คุ้มค่า มีอยู่ แต่ หายากมาก