คนในตำนานในตำนาน-เดือน

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

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

จัดพิมพ์โดย Frederick Brooks ย้อนกลับไปในปี 1975 (คุณจำปี 1975 ได้ไหม เมื่อการพัฒนาซอฟต์แวร์ 100% คล้ายกับการพัฒนาซอฟต์แวร์ในปี 2020?) หนังสือเล่มนี้ค่อนข้างมีชื่อเสียงในหมู่วิศวกรซอฟต์แวร์ โดยเฉพาะอย่างยิ่ง มีจุดหนึ่งในหนังสือทั้งเล่มที่มีชื่อเสียง (ฉันไม่เชื่อว่าผู้คนจะอ่านอะไร แต่ประเด็นนี้หากพวกเขาได้อ่านหนังสือเลย):

“...การเพิ่มผู้ชายให้มากขึ้น ไม่ได้ทำให้สั้นลง ตารางเวลา”

แก้ไขง่าย ต่อจากนี้ไปฉันจะจ้างผู้หญิงทำโครงการ (ดู การ กลับมาของราชา และการต่อสู้กับราชาแม่มดแห่งอังมาร์)

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

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

นี่คือกราฟจากหนังสือที่แสดงจุดนั้น:

นี่เป็นจุดที่ยุติธรรมอย่างยิ่ง นั่นเป็นเหตุผลที่ฉันได้ยินมันมากในที่ทำงาน ผู้ร่วมให้ข้อมูลแต่ละรายที่หมดแรงและผู้นำที่เหนื่อยล้าจะโยนมันทิ้ง — เราไม่สามารถไปได้เร็วกว่านี้ เราไม่สามารถทำอะไรได้มากกว่านั้น หยุดการจ้างงาน อ่าน The Mythical Man-Month และสิ้นหวัง! ทางออกเดียวคือหยุดการเติบโตและฆ่าบางโครงการ

เมื่อฉันเป็น CPO พูดว่า "เราจะทำสิ่งนี้!" มักจะตอบกลับไปว่า “ตกลง แล้วเราจะฆ่าอะไรดีล่ะ” The Mythical Man-Month เปลี่ยนการพัฒนาผลิตภัณฑ์ให้เป็นเกมที่ไม่มีผลรวม หากเราต้องการสิ่งหนึ่ง เราต้องหยุดอีกสิ่งหนึ่ง นั่นเป็นตำนานจริงๆ และฉันเรียกว่าฮอกวอช

และนำไปสู่ข้อสรุปที่เข้าใจผิดทางพยาธิวิทยา (เราจะมาพูดถึงเรื่องนี้) หนังสือเล่มนี้เห็นได้ชัดว่า บริษัท เทคโนโลยีที่เร็วที่สุดคือ บริษัท ที่จ้างคนทั้งหมดสี่คน - ชายสี่ คน เห็นได้ชัดว่า อะไรมากไปก็ช้าลงทั้งหมด ใครบางคนควรส่งสำเนาหนังสือของ Amazon, Apple และ Google เพื่อให้พวกเขาสามารถแก้ไของค์กรที่บวมอย่างเห็นได้ชัด

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

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

น่าแปลกที่คำตอบสำหรับคำถามนี้มาจากหนังสือเล่มเดียวกันของบรูกส์ นี่คือกราฟอื่นในบทเดียวกัน:

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

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

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

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

1. คุณจัดลำดับความสำคัญอย่างไร้ความปราณีในสถานที่ที่มีเธรดเดียว (สมมติว่างานในมือสำหรับทีมผลิตภัณฑ์)
2. คุณปรับขนาดด้วยการเพิ่ม แกน เพื่อจัดการกับงานอิสระ

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

มันคือทั้งหมดที่เกี่ยวกับการจัดการการพึ่งพา

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

ทางออกหนึ่งคือการรวบรวมทิศทางเชิงกลยุทธ์สำหรับบริษัทที่ลดหรือจำกัดการพึ่งพาผ่านพอร์ตโฟลิโอที่คัดสรรมาอย่างดี เรื่องตลกที่นี่คือหลายคนจะผลักดันเรื่องนี้ สมมติว่าฉันมีสองตัวเลือก อย่างแรกที่ฉันสามารถทำโปรเจ็กต์ A, B และ C ที่มีการประสานงานกันน้อยมาก (สมมติว่ามันส่งผลกระทบต่อผลิตภัณฑ์ที่ แตกต่างกัน ) และอีกตัวเลือกหนึ่งสำหรับโปรเจ็กต์ D1, D2 และ D3 ที่มีการพึ่งพาซึ่งกันและกันมากมาย ( สมมติว่าทั้งหมดส่งผลกระทบต่อผลิตภัณฑ์ เดียวกัน ) มักเป็นกรณีที่ เดือนคนในตำนาน ถูกเรียกใช้โดยขัดกับแผนเดิมมากกว่าแผนหลัง เพราะบนกระดาษมัน ดูเหมือนมากกว่า

อันที่จริงมัน "เน้น" น้อยกว่า แต่จากมุมมองของการพึ่งพาอาศัยกันนั้นยากน้อยกว่าจริง ๆ และด้วยเหตุนี้จึงยุติธรรมได้ดีกว่าด้วยการเพิ่มบุคลากร

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

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

ข้อโต้แย้งใน Mythical Man-Month คือเมื่อคุณเพิ่มคนในโครงการซอฟต์แวร์ การสื่อสารจำเป็นต้องเพิ่มขึ้นในเชิงเรขาคณิต ตัวอย่างเช่น หากคุณมี 3 คนในโครงการ นั่นคือ 3 สายของการสื่อสาร แต่ถ้าคุณมี 4 นั่นคือ 6 บรรทัดของการสื่อสาร ในกรณีนี้ บุคคลพิเศษ 1 คนจะเพิ่มการสื่อสารเป็นสองเท่า! สนุก. (แน่นอนว่านี่เป็นการทำให้การสื่อสารในโครงการพัฒนาซอฟต์แวร์ง่ายเกินไป)

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

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

ดังนั้นจึงมีการเริ่มต้น แต่การพึ่งพาอาศัยกันนั้นมีหลายรูปแบบนอกเหนือจากโค้ด ผมขอยกตัวอย่างจาก Mailchimp

ความเสี่ยงจากประสบการณ์ของลูกค้า: ต้นทุนที่ซ่อนอยู่ (แต่ยอมรับได้) ของงานไฟร์วอลล์

เนื่องจากลูกค้าของ Mailchimp มักจะเป็นเจ้าของธุรกิจขนาดเล็กที่เป็นมือใหม่ด้านการตลาด (และมีเจ้าของธุรกิจขนาดเล็กหลายล้านรายที่หันมาเป็นนักการตลาดทั่วโลก) เราจึงต้องมอบประสบการณ์ที่ราบรื่นและเข้าใจได้ทันที แบบ end-to-end เราไม่ได้รับความหรูหราในการประกอบสัตว์ประหลาดเมฆของแฟรงเกนสไตน์โดยการซื้อกิจการในลักษณะที่ผู้เล่นระดับองค์กรสามารถทำได้ เราไม่สามารถรายงานเกี่ยวกับซอฟต์แวร์ที่มีการบูรณาการที่ไม่ดีกับที่ปรึกษาและผู้จัดการบัญชี

ในฐานะสินค้าอุปโภคบริโภค (คิดว่า Instagram หรือ Nintendo Switch หรือ Roomba) เราต้องใช้งานได้ทันที สำหรับแพลตฟอร์มการตลาดแบบ all-in-one ที่มุ่งหวังที่จะขับเคลื่อนธุรกิจของคุณ นั่นเป็นเรื่องยาก! และนั่นหมายความว่า Mailchimp แต่ละรายการสร้างขึ้นจะต้องเชื่อมต่อกันอย่างราบรื่นจากมุมมองของประสบการณ์

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

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

นอกเหนือจากการแก้ไขครั้งที่สามที่ฉันได้กล่าวไว้ข้างต้น การใช้เครื่องมือและเฟรมเวิร์กแทนการเฝ้าสังเกตการณ์และประตูเวที มีวาล์วปล่อยอื่น: แลกเปลี่ยนประสบการณ์ลูกค้าโดยเจตนา โดยเฉพาะอย่างยิ่ง เราสบายใจที่จะปล่อยประสบการณ์ที่ ตัดการเชื่อมต่อ จากส่วนที่เหลือได้ที่ไหน (นั่นคือ มาตรฐานย่อย) การยอมรับความเสี่ยงและก้าวไปข้างหน้าคืองานของผู้นำผลิตภัณฑ์ ดังนั้นคุณใช้เกณฑ์บางอย่างเพื่อแยกแยะ (บางทีอาจไม่ได้ถือพื้นที่ใหม่ที่มีการเข้าชมต่ำของแอปให้เป็นไปตามมาตรฐานประสบการณ์เดียวกันกับ "วัวเงินสด" ของคุณ) และตัดสินใจ (เช่นการทำซ้ำและการเรียนรู้ภาษาโปแลนด์ในบริเวณใกล้เคียง นวัตกรรม) แน่นอนว่าสิ่งนี้ครอบคลุมมากกว่าการออกแบบ

คุณสามารถลัดวงจรกฎของ Brooks ได้ตลอดเวลาโดยเลือกที่จะพยายามไฟร์วอลล์ ซึ่งรวมถึงความพยายามที่ไม่ควรถูกไฟร์วอลล์ในโลกที่สมบูรณ์แบบ!

“

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

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

อย่าลืมด้านที่นุ่มนวลกว่าของการปรับขนาด

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

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

ความเชื่อที่แข็งแกร่งใน Mythical Man-Month โดยทีมงานในตัวของมันเองสามารถนำข้อสรุปมาสู่ความเป็นจริงได้ โดยพื้นฐานแล้วมันเทียบเท่ากับความเชื่อในการบินในปีเตอร์แพน หากทีมเชื่อว่าการปรับขนาดจะทำให้พวกเขาช้าลง และพวกเขาไม่ซื้อการเปลี่ยนแปลง พวกเขาจะชะลอตัวลงอย่างแน่นอน

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