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

1 นาที 11 วินาที
ผู้ก่อตั้งที่พยายามไล่ตามคู่แข่งรายใหญ่ทีละฟีเจอร์ มักลงเอยด้วยโปรดักต์ที่อืดและรกไปหมด Jason Fried และ David Heinemeier Hansson จึงแนะให้สร้างแค่ครึ่งเดียวพอ ในหนังสือ Getting Real ทำน้อยลง สร้างโปรดักต์ได้เร็วกว่าคู่แข่ง สองหุ้นส่วนผู้อยู่เบื้องหลังบริษัทซอฟต์แวร์ 37signals บอกตรง ๆ ว่า ถ้าคู่แข่งออกฟีเจอร์สิบอย่าง คุณออกห้าอย่างก็พอ แล้วให้ความเรียบง่ายเป็นเหตุผลที่คนเลือกคุณ
แนวคิดนี้คือหัวใจสำคัญของหนังสือทั้งเล่ม ทีมเล็กที่ตั้งใจทำให้น้อยลง ทั้งเรื่องฟีเจอร์ คน การประชุม และขั้นตอนที่ขวางกั้นลูกค้า จะเดินเกมได้เร็วกว่าและสร้างงานได้ดีกว่าทีมใหญ่ที่ทำทุกอย่าง บทเรียนเหล่านี้มาจากการสร้างเว็บแอปพลิเคชันอย่าง Basecamp แต่ใช้ได้กับทุกคนที่กำลังเริ่มทำสิ่งใหม่ ไม่ว่าจะทำในบริษัทหรือข้างนอก
ต่อจากนี้คุณจะได้รู้ว่าควรสร้างอะไร ใครควรเป็นคนสร้าง จะปกป้องเวลาทำงานและตัดรายการฟีเจอร์อย่างไร ไปจนถึงวิธีออกแบบและเปิดตัว เกือบทุกขั้นตอนคือการตัดบางอย่างทิ้ง คุณจึงเริ่มทำได้ตั้งแต่สัปดาห์นี้
1 นาที 51 วินาที
การเดินตามรอยเจ้าตลาดดูเหมือนจะเป็นทางที่ปลอดภัยในการเริ่มต้นธุรกิจ แต่ Fried และ Hansson มองว่านั่นคือกับดัก และโปรดักต์ที่ทั้งคู่สร้างขึ้นใช้เองในออฟฟิศก็ชี้ให้เห็นทางออกที่ดีกว่า
1 นาที 57 วินาที
ทีมขนาดใหญ่และแผนงานระยะยาวอาจดูเหมือนจุดแข็ง จนกระทั่งวันหนึ่งลูกค้าอยากได้สิ่งใหม่ขึ้นมาแบบปุ๊บปั๊บ กฎง่าย ๆ เรื่องจำนวนคนจะช่วยอธิบายว่าทำไมทีมเล็กถึงขยับตัวได้ไว ในขณะที่บริษัทใหญ่กลับเปลี่ยนทิศทางได้ยากลำบาก
1 นาที 54 วินาที
ทีมอาจเสียเวลาเป็นสัปดาห์ไปกับการเถียงกันในเรื่องที่ลูกค้าไม่ทันสังเกตเห็นด้วยซ้ำ แอปจดงานที่ต้องทำซึ่งมีเป้าหมายสั้น ๆ แค่สู้กับกระดาษโน้ต จะชี้ให้เห็นว่าทำไมเราควรตัดสินใจเรื่องหลัก ๆ ก่อน แล้วค่อยเก็บความสมบูรณ์แบบไว้ทีหลัง
1 นาที 53 วินาที
ช่วงเช้าตรู่และดึกดื่นมักทำให้เรารู้สึกว่าทำงานได้งานเป็นพิเศษ ซึ่งมันมีเหตุผลซ่อนอยู่ ผู้เขียนจึงนำเหตุผลนั้นมาเปลี่ยนเป็นกฎเหล็กเรื่องการประชุม การถูกขัดจังหวะ และการทลายกำแพงระหว่างแผนก
1 นาที 57 วินาที
สัญชาตญาณมักบอกให้เรารวบรวมผู้เชี่ยวชาญที่เก่งที่สุดเท่าที่เงินจะจ้างไหว แต่ Fried และ Hansson กลับขอเลือกคนฝีมือกลาง ๆ ที่มีพลังบวกมากกว่า และรู้ด้วยว่าจะไปหาคนแบบนี้ได้จากที่ไหน
1 นาที 47 วินาที
ทุกฟีเจอร์ในแผนงานมักฟังดูมีเหตุผลเมื่อมองแยกทีละตัว และนั่นแหละคือปัญหา สูตรคำนวณง่าย ๆ กับคำพูดของ Steve Jobs ในงานนำเสนอภายในครั้งหนึ่ง จะช่วยสอนวิธีตัดใจให้คุณเอง
1 นาที 52 วินาที
ลูกค้าไม่เคยมองเห็นระบบหลังบ้านอันชาญฉลาดที่ซ่อนอยู่ข้างใต้ แต่เห็นแค่สิ่งที่ปรากฏอยู่ตรงหน้าเท่านั้น ความจริงข้อนี้จะเปลี่ยนลำดับขั้นตอนในการสร้างโปรดักต์ และเปลี่ยนสิ่งที่ควรตัดทิ้งจากเมนูตั้งค่าไปเลย
1 นาที 45 วินาที
โปรดักต์ดี ๆ มักจะเสียลูกค้าไปตั้งแต่ก้าวแรก ผู้เขียนได้เล่าถึงเทคนิคเล็ก ๆ น้อย ๆ ตอนเปิดตัว ที่ช่วยเปลี่ยนคนขาจรที่แค่แวะมาดูให้กลายเป็นลูกค้าที่ยอมจ่ายเงิน รวมถึงวิธีที่ Apple ใช้ในการขายเครื่องเล่นเพลงด้วย
1 นาที 24 วินาที
Getting Real สรุปจบที่วิธีคิดเพียงข้อเดียว คือให้มองทุกสิ่งที่เพิ่มเข้ามาว่าเป็นต้นทุน ไม่ว่าจะเป็นฟีเจอร์ใหม่ คนใหม่ การประชุมอีกนัด นักลงทุนอีกราย หรือการตั้งค่าอีกข้อในเมนู แต่ละอย่างทำให้บริษัทอุ้ยอ้ายและปรับตัวช้าลง แถมยังดึงความสนใจไปจากสิ่งสำคัญไม่กี่อย่างที่ลูกค้าตั้งใจมาหา อย่าง Basecamp ก็เกิดขึ้นเพราะบริษัทออกแบบเว็บไซต์ของทั้งคู่ต้องการเครื่องมือสื่อสารกับลูกค้า แต่หาของดี ๆ ไม่ได้
ในมุมของผู้เขียน ความเล็กคือข้อได้เปรียบที่ควรนำมาใช้ บริษัทใหญ่มักพูดกับลูกค้าด้วยภาษาทางการที่เย็นชาเหมือนหุ่นยนต์ แต่ทีมเล็กสื่อสารได้อย่างเป็นมนุษย์ เป็นมิตร ตรงประเด็น และไม่จำเป็นต้องทำตัวให้ดูใหญ่เกินจริง
หนังสือเล่มนี้ฝากวิธีลงมือทำไว้ไม่กี่ข้อ เขียนประโยคเดียวว่าโปรดักต์ของคุณมีไว้ทำไม ให้สั้นเหมือนคำว่า สู้กับ Post-it หั่นรายการฟีเจอร์ลงครึ่งหนึ่ง แล้วหั่นซ้ำอีกครั้ง กันเวลาครึ่งวันทำงานไว้ไม่ให้ใครกวน จำกัดเวลาประชุมไม่เกิน 30 นาที และให้คนได้ลองใช้สิ่งที่คุณสร้างภายในไม่ถึงหนึ่งนาที โดยไม่มีสัญญาผูกมัด
กระดาษ Post-it ไม่เคยต้องมีเมนูตั้งค่า และส่วนใหญ่แล้ว สิ่งที่คุณกำลังสร้างก็ไม่ต้องมีเหมือนกัน
โปรดักต์ชิ้นแรกจำนวนมากต้องล้มเหลว เพราะคนสร้างพยายามไล่ตามคู่แข่งรายใหญ่ทีละฟีเจอร์ รับคนเร็วเกินไป วางแผนไกลเกินตัว และหมดเวลาทั้งวันไปกับการประชุม Jason Fried และ David Heinemeier Hansson สองผู้อยู่เบื้องหลังบริษัทซอฟต์แวร์ 37signals ยืนยันว่า ทีมเล็กเอาชนะได้ด้วยการตั้งใจทำให้น้อยลง ทั้งคู่ถอดบทเรียนจากการสร้างเว็บแอปพลิเคชันอย่าง Basecamp และ Ta-Da List ออกมาเป็นวิธีทำงานที่กระชับ เริ่มจากสร้างสิ่งที่ตัวเองต้องการ ใช้เงินตัวเองลงทุน และใช้ทีมแค่สามคน ปกป้องช่วงเวลายาว ๆ ที่จะไม่มีใครมารบกวน รับคนที่กระตือรือร้นและทำได้หลายอย่าง โดยชะลอการรับคนให้นานที่สุด หั่นรายการฟีเจอร์ลงครึ่งหนึ่ง แล้วหั่นซ้ำอีกครึ่ง ออกแบบหน้าจอก่อนเขียนโค้ด และไม่ต้องมีเมนูตั้งค่าให้ผู้ใช้ ส่วนตอนเปิดตัว ก็ทำให้สมัครได้ไว คิดเงินรายเดือน และไม่ต้องมีสัญญาผูกมัด แม้คำแนะนำเหล่านี้จะมาจากวงการซอฟต์แวร์ แต่คนอ่านทุกสายงานจะได้วิธีคิดที่นำไปใช้ได้จริงติดตัวไป นั่นคือการมองว่าทุกสิ่งที่เพิ่มเข้ามา ไม่ว่าจะเป็นฟีเจอร์ คนใหม่ หรือการประชุม ล้วนเป็นต้นทุนที่ต้องพิสูจน์ให้ได้ว่าคุ้มค่าพอที่จะมีอยู่
ผู้ก่อตั้งและคนที่ลุยเดี่ยวซึ่งกำลังวางแผนทำโปรดักต์ชิ้นแรกด้วยทุนน้อยและทีมขนาดจิ๋ว
ผู้จัดการโปรดักต์และนักออกแบบที่ต้องรับมือกับคำขอเพิ่มฟีเจอร์และการประชุมที่ไม่รู้จักจบสิ้น
ผู้จัดการในบริษัทใหญ่ที่อยากให้ทีมเล็กของตัวเองขยับตัวได้คล่องแคล่วเหมือนสตาร์ตอัป
Jason Fried ร่วมก่อตั้ง 37signals ที่ชิคาโกในปี 1999 โดยเริ่มจากการเป็นบริษัทออกแบบเว็บไซต์ ก่อนจะหันมาสร้างเว็บแอปพลิเคชันในปี 2004 ประเดิมด้วย Basecamp เป็นตัวแรก เขาเดินสายบรรยายทั่วโลกในเรื่องการเป็นผู้ประกอบการ การออกแบบ และการบริหาร ส่วน David Heinemeier Hansson โปรแกรมเมอร์ชาวเดนมาร์กที่คนรู้จักกันในชื่อ DHH เป็นผู้สร้างเว็บเฟรมเวิร์ก Ruby on Rails ร่วมก่อตั้ง Basecamp และเป็นทั้งหุ้นส่วนและประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ 37signals ทั้งคู่ยังร่วมกันเขียนหนังสือเรื่อง ReWork และ Remote ซึ่งติดอันดับขายดีของ New York Times ทั้งสองเล่ม
ผู้ฟังมองว่าหนังสือเล่มนี้อ่านได้กระชับคุ้มเวลาและให้แนวทางที่นำไปใช้ได้จริงทั้งในด้านธุรกิจและการพัฒนาตัวงาน พวกเขาชื่นชมงานเขียนคุณภาพสูง โดยมีผู้ฟังคนหนึ่งพูดถึงการใช้ถ้อยคำที่สั้นกระชับและการจัดรูปเล่มที่เนื้อหาเน้นๆ ไม่เยิ่นเย้อในความยาว 200 หน้า ผู้ฟังบอกว่าหนังสือเล่มนี้ช่วยสร้างแรงจูงใจ ซึ่งมีคนหนึ่งบอกว่ามันกระตุ้นให้ลงมือทำสิ่งต่างๆ ให้เสร็จ และรู้สึกว่าเป็นการใช้เวลาที่คุ้มค่าอย่างแท้จริง
ว้าว นี่คือแรงกระตุ้นเตือนสติที่ผมต้องการพอดี เพื่อที่จะได้เลิกทำโปรเจกต์เสริมของตัวเองให้ซับซ้อนเกินจำเป็น แล้วปล่อยของออกไปจริงๆ สักที Fried และ Hansson มีวิธีในการตัดพวกเนื้อหาไร้สาระแบบองค์กรออกไปจนหมด และโฟกัสเฉพาะสิ่งที่สร้างความเปลี่ยนแปลงให้กับผู้ใช้ได้จริงๆ คติของพวกเขาที่ให้สร้าง 'ผลิตภัณฑ์เพียงครึ่งเดียว ไม่ใช่ผลิตภัณฑ์ที่ทำแบบครึ่งๆ กลางๆ' ได้เปลี่ยนมุมมองที่ผมมีต่อแผนงานฟีเจอร์ไปโดยสิ้นเชิง แต่พูดกันตามตรง หนังสือเล่มนี้ค่อนข้างเอาความคิดตัวเองเป็นที่ตั้งและบางครั้งก็ดูออกจะหยิ่งๆ ไปสักหน่อย โดยเฉพาะเรื่องการรับเงินทุนจากภายนอก แต่ถ้าคุณอยากจะเอาจริงเอาจังกับการปล่อยโค้ดออกไปใช้งาน ก็ไม่มีคู่มือไหนจะดีไปกว่ารวมบทความที่น้อยแต่มากและมีพลังหมัดฮุกเล่มนี้อีกแล้ว มันใช้ได้จริง เดินเรื่องเร็ว และสร้างแรงบันดาลใจได้อย่างแท้จริงสำหรับใครก็ตามที่ให้คุณค่ากับการลงมือทำมากกว่าการวางแผนไม่รู้จบ
ดูเพิ่มเติมแค่บทที่ว่าด้วยการออกแบบหน้าจอที่ยังว่างเปล่าเพียงบทเดียว ก็ทำให้หนังสือเล่มนี้คุ้มค่าตัวแล้ว ทีมส่วนใหญ่โฟกัสไปที่ 'สถานะในอุดมคติ' ของแอปตัวเอง แต่ Fried และ Hansson เตือนเราว่าความประทับใจแรกเกิดขึ้นเมื่อหน้าจอยังว่างเปล่าอยู่ มันคือบทเรียนชั้นครูเรื่องความเข้าอกเข้าใจในประสบการณ์ของผู้ใช้ ผมพบว่าปรัชญา 'Getting Real' เป็นจุดเริ่มต้นที่สมบูรณ์แบบในการเข้าสู่แนวคิดแบบอะไจล์และลีนโดยไม่มีศัพท์แสงที่ชวนสับสน บอกตรงๆ ว่าตอนแรกผมก็ไม่ค่อยเชื่อเรื่องกฎ 'ไม่ต้องมีเอกสารระบุรายละเอียดงาน' ของพวกเขาหรอก แต่พอได้เห็นว่าเราเสียเวลากับการทำเอกสารไปมากแค่ไหน ผมก็เริ่มจะเห็นด้วยแล้ว นี่คือหนังสือที่ต้องอ่านสำหรับใครก็ตามที่อยากสร้างซอฟต์แวร์ที่ผู้คนใช้งานแล้วสนุกไปกับมันจริงๆ มันเร็ว หมัดฮุกหนักหน่วง และนำไปใช้ได้จริงอย่างเหลือเชื่อ
ดูเพิ่มเติมเล่มนี้ไม่เชิงว่าเป็นหนังสือเสียทีเดียว แต่มันเป็นเหมือนแถลงการณ์สำหรับยุคสมัยใหม่ของการพัฒนาแบบลีนมากกว่า มันปฏิเสธวัฒนธรรมแบบ 'ยิ่งมากยิ่งดี' ที่ทำลายแอปพลิเคชันเยี่ยมๆ มานักต่อนักแล้ว ผมชอบที่พวกเขาเน้นย้ำว่าอินเทอร์เฟซก็คือตัวผลิตภัณฑ์ ไม่ใช่แค่เปลือกที่คุณเอามาแปะไว้ตอนจบโปรเจกต์ การโฟกัสไปที่ของ 'จริง' อย่างการใช้ภาพจำลอง HTML แทนที่จะเป็นภาพร่างนิ่งๆ ทำให้คุณเจอจุดที่ติดขัดได้เร็วกว่ามาก มันเป็นหนังสือที่ช่วยปลุกพลังและทำให้คุณรู้สึกว่าไม่จำเป็นต้องมีทีมขนาดมหึมาหรือเงินทุน VC หลายล้านเพื่อที่จะสร้างความเปลี่ยนแปลงให้โลกใบนี้ ถ้าคุณเบื่อหน่ายกับเอกสารสเปกงานที่บวมเป่งและการประชุมที่ไม่รู้จบ หนังสือเล่มนี้จะกลายเป็นเครื่องมือชิ้นโปรดชิ้นใหม่ของคุณ มันกระชับ ชัดเจนในจุดยืนของตัวเอง และจำเป็นอย่างยิ่งสำหรับผู้ประกอบการสายลุยเดี่ยวทำเองทุกอย่าง
ดูเพิ่มเติมในที่สุดก็ได้ฤกษ์อ่านหนังสือคลาสสิกเล่มนี้สักที และน่าประหลาดใจมากที่คำแนะนำด้านการออกแบบส่วนใหญ่ยังคงทันสมัยอยู่เลย ข้อโต้แย้งหลักที่ว่า 'การเขียนคำก็คือการออกแบบอินเทอร์เฟซ' ควรเป็นสิ่งที่ผู้จัดการผลิตภัณฑ์และนักออกแบบทุกคนต้องอ่าน ผมชอบที่เขาเน้นเรื่องขั้นตอนของ 'หน้าจอที่ยังว่างเปล่า' ซึ่งเป็นจุดที่ผู้ใช้ส่วนใหญ่มักจะตัดสินใจกันจริงๆ ว่าแอปของคุณคุ้มค่ากับเวลาของพวกเขาหรือไม่ ข้อบ่นเพียงอย่างเดียวของผมคือมันให้ความรู้สึกล้าสมัยไปนิดในเรื่องการปฏิเสธบทบาทของผู้เชี่ยวชาญเฉพาะทางอย่างเด็ดขาด การเป็นคนรู้รอบด้านมันก็ยอดเยี่ยมอยู่หรอก แต่บางครั้งคุณก็ต้องการผู้เชี่ยวชาญ ถึงอย่างนั้น หนังสือเล่มนี้ก็เขียนด้วยความชัดเจนและกระชับจนวางไม่ลงเลยจริงๆ เป็นหนังสือ 200 หน้าที่อ่านจบไวและอัดแน่นไปด้วยสามัญสำนึกสำหรับโลกซอฟต์แวร์
ดูเพิ่มเติมเคยสงสัยไหมว่าทำไมโปรเจกต์ซอฟต์แวร์ของคุณถึงเลยกำหนดส่งตลอด? หนังสือเล่มนี้เสนอทางออกที่แหวกแนวมาก นั่นคือ ล็อกเวลาและงบประมาณไว้ แล้วปรับเปลี่ยนขอบเขตงานแทน มันเป็นแนวคิดง่ายๆ ที่ผู้จัดการส่วนใหญ่กลัวที่จะนำไปใช้จริง แต่ผู้เขียนก็ยกเหตุผลที่น่าเชื่อถือมาอธิบายว่าทำไมนี่ถึงเป็นวิธีเดียวที่จะทำให้ไม่ประสาทเสียไปเสียก่อน จากประสบการณ์ของผม กระบวนการตัดสินใจแบบ 'เมื่อถึงเวลาจำเป็น' ที่พวกเขาอธิบายไว้ ช่วยป้องกันการเสียแรงเปล่าไปกับปัญหาที่อาจจะไม่เกิดขึ้นจริงด้วยซ้ำได้เยอะมาก เนื้อหาถูกจัดเป็นหัวข้อสั้นๆ กระชับได้ใจความหัวข้อละสองหน้า ทำให้ย่อยง่ายระหว่างเดินทางไปทำงาน แม้เรื่องราวเกี่ยวกับการทำธุรกิจด้วยทุนตัวเองบางส่วนจะให้ความรู้สึกเหมือนเหมาะกับกลุ่มคนที่เฉพาะเจาะจงมากๆ แต่แนวคิดเรื่องการบริหารจัดการโปรเจกต์นั้นเป็นสากลมาก นี่คือคู่มือระดับ 4 ดาวที่แข็งแกร่งสำหรับใครก็ตามที่กำลังสร้างผลิตภัณฑ์ดิจิทัล
ดูเพิ่มเติมหยิบเล่มนี้ขึ้นมาอ่านบนเครื่องบินแล้วก็อ่านจบก่อนเครื่องแตะพื้นเสียอีก นี่คือหนังสือธุรกิจที่มีประสิทธิภาพที่สุดเท่าที่ผมเคยเจอมาอย่างไม่ต้องสงสัยเลย โดยให้ความสำคัญกับเวลาของคุณในฐานะผู้อ่านเหนือสิ่งอื่นใด คำแนะนำเรื่องการข้ามการใช้ข้อความจำลอง 'lorem ipsum' ไปเลย แล้วหันมาใช้ข้อมูลจริงระหว่างขั้นตอนการออกแบบ เป็นสิ่งที่ผมจะนำไปใช้ทันที ผมเสียเวลาไปหลายต่อหลายชั่วโมงมากเกินไปแล้วกับการดูภาพจำลองสวยๆ ที่พังไม่เป็นท่าทันทีที่ใส่เนื้อหาจริงลงไป หนังสือเล่มนี้มีเนื้อหาไม่ยาว แต่ทุกหน้ามีมุมมองที่นำไปใช้ได้จริงหรือคำคมเฉียบๆ ที่ติดอยู่ในหัวคุณ มันอาจจะไม่ได้เจาะลึกเรื่องสถาปัตยกรรมทางเทคนิค แต่มันคือบทเรียนชั้นครูในเรื่องวิธีคิดเชิงผลิตภัณฑ์ แนะนำอย่างยิ่งสำหรับคนยุ่งๆ ที่เกลียดทฤษฎีที่ยืดยาวเยิ่นเย้อ
ดูเพิ่มเติมหลังจากได้ยินชื่อ 37signals มาหลายปี ในที่สุดผมก็ได้ลองเจาะลึกหนังสือเล่มนี้ และผมก็ประหลาดใจในทางที่ดีมากที่มันนำมาประยุกต์ใช้ได้จริงขนาดนี้ ผมทำงานด้านการฝึกอบรมในองค์กร ไม่ใช่ด้านซอฟต์แวร์ แต่แนวคิดเรื่องการย่นระยะเวลาและตัด 'สิ่งที่ไม่สำคัญ' ออกไปนั้นโดนใจเต็มๆ เรามักจะใช้เวลาหลายเดือนในการวางแผนโปรแกรมที่ความจริงแล้วสามารถทำต้นแบบออกมาได้ภายในสัปดาห์เดียว มุมมองของผู้เขียนเรื่อง 'ขอบเขตงานที่ยืดหยุ่น' เป็นตัวเปลี่ยนเกมสำหรับการบริหารจัดการโปรเจกต์ในทุกสายงานเลย ผมชอบส่วนที่พูดถึงการปฏิบัติต่อผลิตภัณฑ์ของคุณเหมือนเป็นคนคนหนึ่งที่มีน้ำเสียงและบุคลิกที่ชัดเจนเป็นพิเศษ มันเป็นมุมมองที่ตรงไปตรงมาและให้ความรู้สึกสดชื่นเกี่ยวกับวิธีทำงานให้สำเร็จโดยไม่ต้องมีความเทอะทะแบบองค์กรทั่วไป มีอยู่สองสามส่วนที่เน้นเรื่องเทคนิคจ๋าเกินไปอย่างเห็นได้ชัด แต่สาระสำคัญหลักนั้นเป็นสากลและสร้างแรงบันดาลใจได้ดี
ดูเพิ่มเติมในฐานะนักพัฒนาที่ทำงานในองค์กรขนาดใหญ่ ผมพบว่าคำแนะนำในเล่มนี้มีทั้งส่วนที่ดีและส่วนที่ยังก้ำกึ่ง ผู้เขียนสนับสนุนแนวคิดแบบ 'รักษาขนาดให้เล็กเข้าไว้' ซึ่งให้ความรู้สึกสดชื่นอย่างเหลือเชื่อถ้าคุณกำลังจมอยู่กับกองประชุม แต่หลายอย่างในนั้นก็ดูไม่น่าจะทำได้จริงสำหรับระบบที่ซับซ้อน พูดตรงๆ เลยนะ แนวคิดที่ว่าคุณควรสร้างเพื่อตัวเองไปเลยแล้วตลาดจะตามมาเอง เป็นการมองอะไรที่ง่ายเกินไปจนน่าอันตรายสำหรับภาคธุรกิจแบบ B2B ส่วนใหญ่ อย่างไรก็ตาม ส่วนที่พูดถึงการออกแบบสำหรับ 'หน้าจอว่างเปล่า' และความสำคัญของการเขียนคำใน UI นั้นเป็นขุมทรัพย์ล้ำค่าสุดๆ เป็นหนังสือความยาว 200 หน้าที่อ่านได้สบายๆ และท้าทายสมมติฐานเดิมๆ ของคุณ แม้ว่าคุณจะไม่สามารถนำทุกเคล็ดลับไปใช้ได้ก็ตาม ผมขอแนะนำให้อ่านเพื่อล้างสมองเปิดรับมุมมองใหม่ๆ แต่อย่าคาดหวังว่ามันจะเป็นแผนงานที่ครอบคลุมสำหรับสตาร์ทอัพระดับโลก
ดูเพิ่มเติมฟังนะ ปรัชญาในเล่มนี้โดยพื้นฐานแล้วก็คือวิธีทำธุรกิจแบบ 'ต้นบอนไซ' นั่นแหละ คือการจงใจชะลอการเติบโตเพื่อให้ยังสามารถจัดการสิ่งต่างๆ ได้ ถ้าคุณเป็นผู้ประกอบการที่อยากจะรักษาขนาดให้เล็กและใช้ทุนตัวเอง นี่คือคัมภีร์ไบเบิลของคุณเลยล่ะ แต่มันก็ไม่ได้เหมาะกับทุกคน ผู้เขียนดูจะรังเกียจแนวคิดเรื่องการขยายขนาดธุรกิจหรือการหาผู้เชี่ยวชาญ ซึ่งให้ความรู้สึกเหมือนเป็นสูตรสำเร็จที่จะนำไปสู่ภาวะหมดไฟในท้ายที่สุดสำหรับผู้ก่อตั้งส่วนใหญ่ที่ผมรู้จัก ถึงจะพูดอย่างนั้น ผมก็ปฏิเสธไม่ได้ว่าแนวทาง 'น้อยแต่มาก' สำหรับการทำฟีเจอร์ คือบทเรียนที่สำคัญอย่างยิ่งสำหรับอุตสาหกรรมนี้ สไตล์การเขียนตรงไปตรงมาอย่างเหลือเชื่อและหลีกเลี่ยงเนื้อหาน้ำท่วมทุ่งแบบหนังสือธุรกิจทั่วไป ซึ่งผมชื่นชมจริงๆ เป็นหนังสือที่ชวนให้ขบคิด ซึ่งจะทำให้คุณพยักหน้าเห็นด้วยไม่ก็กัดฟันด้วยความหงุดหงิดไปเลย
ดูเพิ่มเติมไม่เป็นอย่างที่ผมคาดหวังไว้เลยเมื่อเทียบกับกระแสอวยขั้นสุดเกี่ยวกับ 37signals แม้จะมีเกร็ดความรู้ที่ใช้ได้อยู่บ้างเกี่ยวกับการออกแบบอินเทอร์เฟซ แต่หนังสือส่วนใหญ่กลับให้ความรู้สึกเหมือนเป็นการรวมคำพูดสวยหรูที่ซ้ำซากและมองอะไรตื้นเขินเกินไป การบอกให้ผู้คน 'สร้างเพื่อตัวเองไปเลย' เป็นการเพิกเฉยต่อความเป็นจริงของการวิจัยตลาดและความต้องการของผู้ใช้สำหรับ 90% ของอุตสาหกรรมซอฟต์แวร์ มันพูดง่ายที่จะให้คำแนะนำแบบนี้เมื่อคุณมีผลิตภัณฑ์ที่ประสบความสำเร็จอยู่แล้ว แต่สำหรับสตาร์ทอัพหน้าใหม่ มันให้ความรู้สึกที่แคบจนน่าอันตราย น้ำเสียงค่อนข้างดูแคลนใครก็ตามที่ไม่ได้เดินตามเส้นทางเฉพาะของพวกเขาในการทำธุรกิจด้วยทุนตัวเองและรักษาขนาดให้จิ๋วเข้าไว้ ถ้าคุณกำลังมองหากลยุทธ์ทางธุรกิจที่นำไปใช้ได้จริงและมีความละเอียดอ่อน คุณไปหาอ่านที่อื่นจะดีกว่า มันเป็นหนังสือที่อ่านจบได้เร็วมาก แต่ท้ายที่สุดแล้วกลับขาดความลึกซึ้งที่ผมหวังไว้
ดูเพิ่มเติมJason Fried และ David Heinemeier Hansson ยืนยันว่า ทีมเล็กที่ตั้งใจทำให้น้อยลงจะเอาชนะทีมใหญ่ที่พยายามทำทุกอย่างได้ แทนที่จะมัวลอกเลียนแบบคู่แข่ง ให้หันมาสร้างโปรดักต์ที่เรียบง่ายและมีฟีเจอร์น้อยลง เริ่มต้นด้วยทีมประมาณสามคน ปกป้องเวลาทำงานไม่ให้หมดไปกับการประชุม ออกแบบหน้าจอก่อนลงมือเขียนโค้ด และทำให้ขั้นตอนการสมัครและจ่ายเงินเป็นเรื่องง่ายที่สุด บทเรียนเหล่านี้กลั่นกรองมาจากการสร้างเว็บแอปพลิเคชันอย่าง Basecamp
ผู้เขียนแนะนำให้เริ่มต้นทำโปรเจกต์ด้วยคนแค่สามคน สำหรับเว็บแอปพลิเคชัน สามคนนี้ได้แก่นักพัฒนา นักออกแบบ และตำแหน่งที่เรียกว่า sweeper ซึ่งทำหน้าที่เชื่อมงานออกแบบกับงานพัฒนาเข้าด้วยกัน ส่วนในธุรกิจอื่น จะหมายถึงคนดูแลเทคโนโลยีหลัก คนดูแลการพัฒนาธุรกิจ และคนดูแลเรื่องการเงิน ทั้งคู่บอกว่าถ้าคนสามคนยังสร้างโปรดักต์เวอร์ชันแรกออกมาไม่ได้ แปลว่าไอเดียนั้นใหญ่เกินตัวและควรย่อขนาดลงมา
Fried และ Hansson แนะนำให้นับจำนวนฟีเจอร์ที่วางแผนไว้ทั้งหมดแล้วหารสองเพื่อให้ได้ฟีเจอร์พื้นฐาน จากนั้นให้หารสองซ้ำอีกครั้งเพื่อคัดเอาเฉพาะสิ่งที่ขาดไม่ได้จริง ๆ ให้เน้นสร้างสิ่งที่ตัวคุณเองอยากใช้ เปิดตัวทันทีที่มันดีพอเหมือนที่ Mark Zuckerberg ทำกับ Facebook ในยุคแรก และให้ปฏิเสธคำขอเพิ่มฟีเจอร์ส่วนใหญ่ไปก่อน เช่น คำขอให้ปรับแต่งรูปแบบตัวอักษรในแอปแชต
ผู้เขียนมองว่าการประชุมคือการดึงเวลาไปจากการทำงานจริง เพราะคนมักจะคุยฟุ้งออกไปไกลกว่าเรื่องตรงหน้า ทั้งคู่จึงแนะนำให้จำกัดเวลาประชุมไว้ไม่เกิน 30 นาทีอย่างเคร่งครัด เรียกคนเข้าให้น้อยที่สุด และไม่ต้องเข้าประชุมใด ๆ ที่ไม่มีหัวข้อชัดเจน นอกจากนี้ยังแนะนำให้กันเวลาครึ่งหนึ่งของทุกวันทำงานไว้เป็นช่วงปลอดการพูดคุย โทรศัพท์ หรืออีเมล เพื่อให้ทุกคนมีสมาธิจดจ่อกับงานจนเข้าสู่สภาวะ in the zone ได้
ไม่ใช่เลย แม้ตัวอย่างในเล่มจะมาจากเว็บแอปพลิเคชัน แต่ผู้เขียนชี้ว่าบทเรียนเหล่านี้มีประโยชน์กับผู้บริหาร นักการตลาด นักออกแบบ และผู้ประกอบการทุกคน การรักษาขนาดทีมให้เล็ก การรับคนที่กระตือรือร้นและทำได้หลายอย่าง การลดการประชุม การจัดทีมคละสายงาน การเลี่ยงสัญญาระยะยาว และการคุยกับลูกค้าด้วยน้ำเสียงที่เป็นมิตรและเป็นมนุษย์ ล้วนนำไปปรับใช้ได้ไกลกว่าแค่วงการซอฟต์แวร์มาก
มีสรุปแบบเสียง
เก็บแนวคิดสำคัญจาก Getting Real ทำน้อยลง สร้างโปรดักต์ได้เร็วกว่าคู่แข่ง ของ Jason Fried พร้อมหนังสือนอนฟิกชันอีก 5,000+ เล่ม
