แนะนำ "เวลา 20%" ในที่ทำงาน [ปิด]

30

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

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

ฉันลองหลายครั้งเพื่อแนะนำรูปแบบ 20% / Skunk ที่ทำงานกับนายจ้างคนก่อนหน้าของฉันโดยไม่ประสบความสำเร็จ

ฉันจะปรับการจัดการให้ดีขึ้นได้อย่างไร อะไรคือวิธีที่ "ถูกต้อง" ในการเข้าถึงการจัดการในลักษณะนี้

development-environment

— dannywartnaby
แหล่งที่มา

11

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

— Dan Diplo

@Dan theregister.co.uk/1999/10/27/what_the_hell ;) มันเป็นคำที่ใช้เพื่ออธิบาย "นักพัฒนาเริ่มต้นการทำงานยกเลิกการวางแผน" ที่ บริษัท โดยทั่วไปแล้วงานนอกเวลา บริษัท บางแห่งอนุญาตให้พนักงานใช้เวลาทำงานกับสิ่งที่พวกเขาชอบ - บางครั้งงานนั้นกลายเป็นงานที่ บริษัท สามารถใช้หรือผลิตภัณฑ์ที่จะปล่อย

— dannywartnaby

2

@danny นั่นไม่ใช่ทั้งหมดที่ฉันเข้าใจคำว่า: คุณกำลังอธิบาย "20% เวลา" ของ Google ฉันค่อนข้างสงสัยว่า Lockheed's Skunk Works ทำอะไรที่ไม่ได้วางแผนมาก่อน แต่มันคือ "กลุ่มภายในองค์กรที่ได้รับเอกราชในระดับสูงและไม่ถูกขัดขวางจากระบบราชการมอบหมายให้ทำงานในโครงการที่ก้าวหน้าหรือเป็นความลับ" (อ้างอิงจากหน้า Skunk Works ของ WP)

— Frank Shearar

1

@SteveBennett: ตรงกันข้ามกับตรรกะอย่างสุดขีดของเวลา 20% คือการใช้ประโยชน์ 100%, ทำงานในไซโลทำงาน, ความเชี่ยวชาญระดับสูง, การบัญชีสำหรับเวลาที่ใช้ในแต่ละฟังก์ชั่น, และจำนวนมาก, มากมายและขยะมากมาย

— azheglov

1

นี่เป็นคำถามเพิ่มเติมสำหรับสถานที่ทำงาน แต่ได้มีการถามไปแล้ว - ที่ทำงานสถานที่การ

— แลกเปลี่ยน / คำถาม / 468/ …

45

เหตุผลหลักสำหรับเวลา 20% คือเพื่อให้การใช้กำลังการผลิตที่ 80% มากกว่าที่ 100%

คุณสามารถนึกถึงองค์กรพัฒนาซอฟต์แวร์เป็นระบบที่เปลี่ยนคำขอคุณลักษณะเป็นคุณลักษณะที่พัฒนาขึ้น คุณสามารถจำลองพฤติกรรมของมันโดยใช้ทฤษฎีการเข้าคิว

ทฤษฎี

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

ความโน้มเอียงทางคณิตศาสตร์สามารถถามเกี่ยวกับ "การสุ่ม" นี้: จะต้องมีการกระจายความน่าจะเป็นบางอย่างดังนั้นขนาดของคิวจะโดยเฉลี่ยคืออะไร? คณิตศาสตร์ (ทฤษฎีแถวคอย) มีคำตอบสำหรับสิ่งนั้น: ถ้าทั้งกระบวนการมาถึงและกระบวนการบริการคือมาร์คอฟดังนั้น N = rho ^ 2 / (1-rho)

(โดยที่ rho คือสัมประสิทธิ์การใช้งานเท่ากับอัตราส่วนของบริการและอัตราการมาถึงหากกระบวนการไม่ใช่มาร์คอฟคณิตศาสตร์จะซับซ้อนกว่า แต่ไม่เปลี่ยนข้อสรุป)

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

การปฏิบัติ

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

เวลา 20% จึงเป็นคำตอบทางวิทยาศาสตร์ต่อปัญหาของการเพิ่มประสิทธิภาพผลลัพธ์ทางเศรษฐกิจ: หลีกเลี่ยงสถานะคิวสูงโดยหลีกเลี่ยงอัตราส่วนการใช้ประโยชน์ที่ทำให้พวกเขา มันเป็นความหย่อนที่ทำให้ระบบตอบสนอง

ข้อสรุปในทางปฏิบัติหลายประการปฏิบัติตามทันที:

หากคุณกำลังพิจารณาเวลา 20% และทำบัญชีต้นทุน (เวลาของนักพัฒนาต้นทุน X แต่ / และ บริษัท สามารถ / ไม่สามารถจ่ายได้) คุณกำลังทำผิด
หากคุณจัดสรร 20% ถึงวันศุกร์ทุกสัปดาห์คุณทำผิด
หากคุณตั้งค่าระบบการส่ง / ตรวจสอบ / อนุมัติโครงการเวลา 20% คุณกำลังทำผิด
หากคุณกรอก Timesheets คุณจะทำผิด
หากคุณใช้นวัตกรรมเป็นตัวกระตุ้นเวลา 20% แสดงว่าคุณทำผิด ในขณะที่ผลิตภัณฑ์ใหม่ออกมาจากโครงการ 20% พวกเขาไม่ใช่จุด หาก บริษัท ของคุณไม่สามารถคิดค้นสิ่งใหม่ได้ในช่วงเวลาทำการหลักนั่นเป็นปัญหา!
เวลา 20% ไม่เกี่ยวกับความคิดสร้างสรรค์ อย่าบอกว่าคุณจะปลดปล่อยความคิดสร้างสรรค์ของคุณด้วยเวลา 20% ถามว่าทำไมคุณถึงไม่สร้างสรรค์พอในช่วงเวลาหลัก

คำตอบสำหรับคำถามในความคิดเห็น

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

คิมก็ยังคงเป็นวัฒนธรรมบางส่วน การอ้างอิงทางวัฒนธรรมที่ใกล้เคียงที่สุดที่ฉันนึกได้ก็คือระดับการทำงานร่วมกันของแบบจำลองมาร์แชลที่เรียกว่าการเปลี่ยนแปลงองค์กร มันเกิดขึ้นในตอนท้ายของการเปลี่ยนแปลงแบบลีนที่ประสบความสำเร็จหรือมีอยู่ในองค์กรที่สร้างแบบลีนตั้งแต่เริ่มต้น ( นี่คือลิงค์ไปสู่เอกสารสีขาวของ Bob Marshall (PDF) )

ข้อมูลอ้างอิง

ตรรกะข้างต้นได้รับการสนับสนุนอย่างดีในวรรณคดีวิศวกรรมซอฟต์แวร์ แมรี่และทอม Poppendieck นัยไว้ในหนังสือของพวกเขาดำเนินการผลิตแบบลีน 2006 การพัฒนาซอฟต์แวร์ Donald Reinertsen ในหนังสือหลักการของการพัฒนาผลิตภัณฑ์ปี 2009 (บทที่ 3) ให้การรักษาอย่างจริงจังในเรื่องนี้ด้วยสูตรและกราฟ

— azheglov
แหล่งที่มา

ว้าวคำตอบที่ดี ฉันไม่เคยคิดมาก่อน - มองว่ามันเป็นวัฒนธรรมเสมอ +1

— Kim Burgess

น่าสนใจมาก ... สิ่งหนึ่งที่ฉันไม่คิดเลย: ทำไมคิวถึงมีขนาดเล็กมากถึง 80% ก็เพราะมีความจุฟรีจนถึงจุดนั้น หาก 20% ของความจุของคุณได้รับคำสั่งให้เติมรายการที่ไม่ได้อยู่ในคิวคุณก็จะลดความจุของคุณลงเหลือ 80% และ 80% เป็น 100% ใหม่ของคุณ ขวา?

— Dan Ray

@KimBurgess: ฉันเพิ่มความคิดเห็นในความคิดเห็นของคุณไปยังคำถาม & คำตอบในตอนท้ายของคำตอบ

— azheglov

@DanRay: ถูกต้องแล้ว! ฉันเพิ่มคำถาม & คำตอบในตอนท้ายของคำตอบ

— azheglov

3

ฉันหวังว่าฉันจะลงคะแนนได้สิบครั้ง

— Daniel Daranas

12

สิบสี่เดือนหลังจากที่ฉันเขียนคำตอบนี้ฉันได้คำตอบที่ดีกว่ามาก

ฉันไม่ได้ทำงานในสถานที่ที่งานดังกล่าวได้รับการยอมรับอย่างเป็นทางการ แต่จากการสนทนาของฉันและความพยายามที่จะเรียนรู้เกี่ยวกับการฝึกฝนนี้ฉันพบสิ่งนี้ - ส่วนใหญ่เวลา "20%" ไม่ใช่:

มันเป็นวัฒนธรรมและไม่ใช่นโยบาย
ผู้บริหารระดับสูงไม่สามารถกำหนดได้
มันไม่สามารถก่อตั้งโดยคณะกรรมการพัฒนา
ไม่ใช่ 32 ชั่วโมงสำหรับสิ่งนี้และ 8 ชั่วโมงสำหรับสิ่งนั้น

— azheglov
แหล่งที่มา

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

— dannywartnaby

ในกรณีของ Atlassian การตัดสินใจมาจากด้านบน แต่ฉันคิดว่าพวกเขามีพนักงานที่เหมาะสมนักพัฒนาที่พร้อมสำหรับมัน ยังคงโพสต์บล็อกนี้: blogs.atlassian.com/developer/2009/02/…รายงานปัญหาเล็กน้อยเกี่ยวกับการใช้งานของพวกเขาและแม้ว่าพวกเขากล่าวว่าพวกเขาต้องการทำการทดสอบต่อไปพวกเขายังไม่ได้อัปเดตสู่สาธารณะมากกว่า ปีครึ่ง ฉันคอยติดตาม

— azheglov

6

" Skunkworks " ไม่เหมือนกับเวลา 20% เวลา 20% ดังที่คุณกล่าวไว้ - เวลาที่ผู้พัฒนาเลือกเองว่าจะทำอะไร Skunkworks แตกต่างอย่างสิ้นเชิง โครงการ skunkworks เป็นโครงการที่มีมูลค่าสูงและมีค่าใช้จ่ายสูงดำเนินการโดยทีม (มักจะเป็นทีมงานผู้เชี่ยวชาญด้านปรมาจารย์) ที่ไม่ได้รายงานไปยังผู้บริหารระดับสูงและทีมตัดสินใจด้วยตัวเองว่าโครงการควรดำเนินการอย่างไรโดยไม่มีทิศทางการจัดการ . โครงการเหล่านี้มักถูกกระตุ้นด้วยยุทธวิธีหรือธุรกิจจำเป็นต้องทำอะไรบางอย่างให้เสร็จ แต่ก็ไม่มีงบประมาณเพียงพอ ถ้ามีอะไรที่ต้องทำให้เสร็จมันก็ทำไปแล้ว - งบประมาณถูกสาป

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

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

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

— John Dibling
แหล่งที่มา

1

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

— Matt Olenik

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

— John Dibling

คำตอบที่เป็นประโยชน์จริงๆ John ขอบคุณ เป็นเรื่องที่น่าสนใจที่คุณพบว่าการขาดทิศทางและเสรีภาพในการประดิษฐ์ผลงานเป็นปัจจัยที่ช่วยให้เวลา 20% ไม่ทำงานสำหรับนักพัฒนาบางคนเนื่องจากเป็นหัวใจของแนวคิด ฉันเดาว่านักพัฒนาบางคนจะต้องได้รับเป้าหมายที่ชัดเจนเพื่อให้ได้สิ่งที่ดีที่สุด ฉันเดาว่าวัฒนธรรมน่าจะเป็น "ใช้เวลา 20% ในการสร้างบางสิ่งบางอย่าง แต่ถ้าคุณทำไม่ได้ก็โอเคอาจใช้เวลาทำสิ่งที่ดีกว่า - มันไม่จำเป็นต้องเป็นโครงการปัจจุบันของคุณ" .. ?

— dannywartnaby

มันแปลกมากฉันได้พบคำว่า "skunk works" เป็นครั้งแรกในหนังสือที่อธิบายถึงโครงการที่มีมูลค่าสูง แต่ราคาต่ำซึ่งเริ่มต้นจากโครงการสัตว์เลี้ยงที่เป็นความลับสำหรับนักพัฒนาคนหนึ่งและต่อมาเปลี่ยนทิศทางขององค์กรโดยสิ้นเชิง

— Spoike

4

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

ฉันเข้าร่วมเริ่มต้นเมื่อก่อตั้งขึ้นและเป็นเวลาเกือบหนึ่งปีที่ฉันเป็นนักพัฒนาซอฟต์แวร์คนเดียว ฉันใช้จ่าย 20% ของฉันโดยมีสองสิ่ง:

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

เวลาไม่ได้วัดอย่างแม่นยำแน่นอนว่าไม่ใช่ 32 + 8 ชั่วโมงบางครั้งมีสิ่งเร่งด่วนที่ต้องทำเมื่อมีเวลาไม่พอที่จะตัด 20% อีกครั้งฉันมีเวลาว่างมากขึ้น

ฉันทำงานจากระยะไกลและเราใช้แชทแคมไฟร์ของ 37signal เพื่อสื่อสารและติดตามการปรากฏตัวของกันและกันและชั่วโมงเหล่านี้ถูกติดตามว่า "ทำงาน" ชั่วโมงฉันเข้าสู่ระบบแชทและพร้อมให้เพื่อนร่วมงานแม้ว่าจะทำให้ มันชัดเจนว่าตอนนี้ฉันไม่ได้ทำงานในโครงการของเรา

— อัตติลาโอ
แหล่งที่มา

3

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

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

— คริส
แหล่งที่มา

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

— dannywartnaby

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

— คริส