ในฐานะนักพัฒนาเดี่ยว คุณจัดการงานอย่างเป็นระบบอย่างไร?

xguru · 2024-06-25T11:05:01+09:00

ตอนทำงานกับทีม เป้าหมายระยะสั้นแบบ Scrum และ backlog งานที่เป็นระบบช่วยรักษาสมาธิและติดตามสิ่งที่ต้องทำได้มากจริง ๆ แต่พอพัฒนาคนเดียวกลับยังหาแนวทางที่เหมาะเจอไม่ได้ และมักจะออกนอกทางจนหลุดจากเป้าหมายอยู่บ่อย ๆ พวกคุณใช้เครื่องมือและเทคนิคอะไรเพื่อยึดเป้าหมายไว้ไม่ให้หลุด? CharlieDigital ใช้สมุดโน้ตกระดาษ ถ้าไม่จำเป็นต้องแชร์ข้อมูลกับใคร ก็ไม่มีอะไรดีไปกว่าสมุดสำหรับกางไอเดียทั้งหมดออกมาและคอยทบทวนซ้ำ ๆ ไม่ต้องล็อกอิน พกไปได้ทุกที่ จะนั่งที่ม้านั่งคิดไอเดีย หรือไปยิมแล้วจดความคิดก็ได้ เขียนเป้าหมายประจำวันเป็นเช็กลิสต์แล้วค่อย ๆ เช็กทีละข้อ ไม่จำเป็นต้องใช้ GitHub Projects อะไรแบบนั้นเพราะไม่ต้องแชร์สถานะกับคนอื่น olooney ใช้ไฟล์ TODO.md เขียนลิสต์ด้วย GFM (GitHub flavored markdown) แบบนี้ 1. [X] Dockerfile 2. [ ] Bulk Inference 3. [ ] CLI 4. [ ] Logging ด้านบนสุดมีเซกชันชื่อ 'backlog' สำหรับไอเดียในอนาคต, เซกชัน 'bugs' สำหรับบั๊กที่ต้องแก้ และเซกชันที่ไม่มีชื่อสำหรับรายการปัจจุบัน เมื่อถึง milestone อย่างเช่นการออกรุ่น ก็ลบรายการที่เสร็จแล้วทั้งหมดทิ้ง jasonb05 เขียนอะไรไว้ให้ตัวเองในอนาคตเยอะมาก Trello ที่มีคอลัมน์รายสัปดาห์ รายเดือน รายไตรมาส และรายปี เปิดสมุดโน้ตที่วางไว้ข้างเมาส์ 2a. หน้าซ้าย: เช็กลิสต์สิ่งที่ต้องทำประจำวันด้วยปากกาและกระดาษ (วันละ 2–3 บรรทัด) 2b. หน้าขวา: ร่างเล่น สเก็ตช์พล็อต โพสต์อิท ฯลฯ บันทึกการพัฒนาที่จดเรื่องรีเสิร์ช, URL, เปเปอร์, ความคิด, ไอเดีย, ความคืบหน้า, ส่วนขยาย ฯลฯ ทุกโปรเจ็กต์ใน GitHub จะมีโฟลเดอร์ dev/ สำหรับโน้ตพวกนี้ และตั้งชื่อไฟล์เป็น yyyymmmdd-n.txt สร้างไฟล์ใหม่ต่อโปรเจ็กต์ต่อวันตามความจำเป็น โพสต์อิทสีเหลืองสำหรับไอเดียชั่วคราว (แปะไว้ใต้จอ บนสมุด หรือบนไวท์บอร์ด) โดยทั่วไปจะเป็นคติที่ช่วยชี้ทิศทางของโปรเจ็กต์ (เช่น "ไม่มีใครอ่าน rtfm หรอก") ไวท์บอร์ด, คอลัมน์แยกตามโปรเจ็กต์, เอกสารพิมพ์ + แม่เหล็ก (กราฟความคืบหน้ารายเดือนของโปรเจ็กต์), โพสต์อิท, ไอเดียสำหรับโปรเจ็กต์ในอนาคต และของจุกจิกต่าง ๆ ฉันพยายามสื่อสารกับตัวเองในอนาคตมากเป็นพิเศษ มันช่วยจัดระเบียบความคิดปัจจุบันของฉัน เช่น ความคาดหวัง ความคืบหน้า อุปสรรค ฯลฯ อุปสรรคคือตัวฉันเอง ไม่ใช่งาน งานมักจะถูกวาดออกมาเป็นลำดับเลขหลังจากได้ 'คิดหนัก' แล้ว ฉันทำงานคนเดียวแบบนี้มา 8 ปีแล้ว ใช้ /dev dir และไฟล์ .txt มาตั้งแต่ช่วงเรียนปริญญาเอกต้นยุค 2000 สำหรับบันทึกการพัฒนาแบบเรียลไทม์ มันช่วยประหยัดเวลาได้มหาศาล (grep) อ้อ แล้วก็ทำสิ่งเดิมทุกวัน แทบทุกวัน เช่น ซัพพอร์ตลูกค้า โปรโมต เขียน โค้ด และ... ไม่ต้องคิดมาก แค่ทำงานนั้นแล้วไปงานถัดไป liampulles เวลาทำ side project, "การพัฒนาแบบขับเคลื่อนด้วย Readme" ช่วยสร้างแรงจูงใจและจำกัดขอบเขตงานได้ Tehnix ตั้งเป้าหมายรายวัน/รายสัปดาห์/รายเดือน แล้วจัดระบบด้วยแอปอย่าง Linear, Todoist, Notion เป้าหมายรายเดือนจะอยู่ในระดับสูงมากและมีไม่กี่ข้อ (เช่น "สร้าง PoC", "ออกแบบบล็อกใหม่และเปิดตัวอีกครั้ง") เป้าหมายรายสัปดาห์จะเฉพาะเจาะจงและจำกัดมากขึ้น (เช่น "ตัดสินใจแนวทางเรียก Rust จากโค้ด Swift" หรือ "ทำดีไซน์และสไตลิงของโพสต์ให้เสร็จ") เป้าหมายรายวันจะเฉพาะมาก (เช่น "ตั้งค่า UniFFI pipeline เพื่อสร้าง Swift bindings" หรือ "ใช้ธีมใหม่กับทั้งหน้าบล็อก") บางครั้งระหว่างลงมือทำก็มีงานใหม่แทรกเข้ามา จนต้องเลื่อนเป้าหมายรายวันไปเป็นวันถัดไป จนถึงตอนนี้วิธีนี้ช่วยเพิ่มสมาธิได้ดี และสามารถเลือกเป้าหมายรายวันจากรายการงาน/issue ที่กำลังทำอยู่จำนวนมากในหลายโปรเจ็กต์ โดยอิงจากจุดโฟกัสประจำสัปดาห์ ถ้าตั้งงานที่กำลังทำแต่ละอย่างเป็นโปรเจ็กต์ และกำหนดลำดับความสำคัญทันทีตอนเพิ่มงาน ก็จะมองเห็นได้ง่ายทั้งโปรเจ็กต์เล็กใหญ่ที่กำลังทำหรืออยากทำในอนาคต แม้จะชอบกระดาษ แต่ใช้ได้แค่กับเรื่องชั่วคราวเท่านั้น ชอบวิธีดิจิทัลมากกว่าเพราะเพิ่มไอเดียจากมือถือระหว่างเดินทางได้ง่าย และการพิมพ์ด้วยคีย์บอร์ดก็เร็วกว่ามาก อีกทั้งยังใช้รายการงานหลายชุดเป็นแหล่งเก็บข้อมูลระหว่างทำงานหรือค้นคว้าได้ด้วย OogieM จัดการเป็นโฟลเดอร์แยกภายใน Obsidian Vault ในโฟลเดอร์จะมีองค์ประกอบหลักที่คล้ายกัน มีโน้ตแบบคัมบังโดยใช้ปลั๊กอินคัมบังสำหรับโครงสร้างหน้าจอ (ในแต่ละหน้ามีฟีเจอร์หรือกิจกรรมอะไรบ้าง) มี roadmap note ที่เก็บรายละเอียดของแต่ละฟีเจอร์ มีโน้ตทั่วไปที่รวมงานต่าง ๆ ของแอปหรือคอมโพเนนต์นั้น ใช้ปลั๊กอิน tasks เพื่อติดตามสิ่งที่กำลังทำอย่างเจาะจง ในโฟลเดอร์นี้ยังมีเอกสารเสริม เช่น สกรีนช็อต เอกสารอ้างอิง และโน้ตอื่น ๆ ที่เกี่ยวกับแอปนั้นด้วย โปรเจ็กต์ของฉันคือชุดโปรแกรมสำหรับจัดการปศุสัตว์และการขึ้นทะเบียนสายพันธุ์หายาก เลยมีทั้ง Farm Mobile (Android), Farm Desktop (Python), Registry Web (Flask), Registry Desktop (Python) และ database schema (SQLite) แยกเป็น GitLab repository คนละตัว ตอนนี้มีผู้ร่วมงานเพิ่มอีก 3 คน เลยแชร์ Obsidian Vault ผ่าน Obsidian Sync ระบบที่เริ่มจากโซโลสามารถขยายมารองรับการทำงานเป็นทีมได้ robomartin ใช้ไฟล์ข้อความเรียบง่ายที่ได้แรงบันดาลใจจากคัมบังมาหลายปีแล้ว ใช้วิธีนี้จัดการทุกอย่าง ตั้งแต่โปรเจ็กต์เล็กไปจนถึงโปรเจ็กต์มูลค่าหลายล้านดอลลาร์ แต่ละโปรเจ็กต์มีไฟล์ล็อกหลัก และมีไฟล์เฉพาะตามสาขา (อิเล็กทรอนิกส์ เครื่องกล ออปติก การผลิต การทดสอบ ฯลฯ) เนื้อหาในไฟล์ log file -------------------------------- WORKING ON NOW -------------------------------- TO DO - - -------------------------------- IDEAS -------------------------------- RESOURCES -------------------------------- DONE kkfx จัดการด้วย Emacs/org-mode/org-roam ใช้ org-agenda ของโน้ตรายปีปัจจุบัน โดยโน้ตเป็นวันละหนึ่งไฟล์, หนึ่งไดเรกทอรีต่อปี และแบ่งไฟล์ตามช่วงเวลาไว้ในไดเรกทอรี org-roam ร่วมกัน วิธีนี้ช่วยลดจำนวนไฟล์ที่ org-agenda ต้องไล่อ่าน และลดเนื้อหาระยะยาวที่ย้ายข้ามปีในโน้ตสรุปรายปี makz ก่อนเลิกงานจะคอมเมนต์ไว้ในโค้ดว่า: "ตอนนี้กำลังทำงานนี้อยู่ และถ้าจะให้มันทำงานได้ ต้องทำ A, B, C..." ครั้งถัดไปที่เปิดตัวแก้ไขโค้ด ก็จะรู้ทันทีว่าต้องทำอะไร qntmfred มีเทมเพลต daily routine ใน Obsidian Daily Note มันช่วยให้โฟกัสกับวันนั้นและรู้สึกตื่นเต้นกับมัน เครื่องหมาย [X] แรกที่ให้ตัวเองในแต่ละวันคือการทำเช็กลิสต์กิจวัตรประจำวันให้เสร็จ เป็นชัยชนะฟรี ๆ สำหรับการเริ่มวันอย่างมีประสิทธิภาพ โน้ตส่วนใหญ่จริง ๆ แล้วเขียนด้วย Windows voice typing เลยคล้ายกับการทำ daily standup อีกอย่างคือฉันมักเปิดไลฟ์สตรีมไว้ตลอดทั้งวัน แม้ว่าจะมีคนดูแค่ตัวเองก็ตาม (แน่นอนว่าเป็นไลฟ์ส่วนตัว เลยทำทุกวัน แต่ทำไว้เผื่อต้องย้อนนึกว่าเมื่อประมาณ 20 นาทีที่แล้วกำลังทำอะไร/คิดอะไรอยู่ ก่อนที่จะหลงเข้าไปในโพรงกระต่ายอีกอัน จริง ๆ แล้ว Windows Recall ก็ดีเหมือนกัน) วันของฉันเลยดำเนินไปคล้ายกับเวลาทำงานกับคนอื่นในองค์กรที่มี 2 คนขึ้นไป (หรือที่เรียกว่าประชุม) mentos บอร์ด Trello ที่มีสามลิสต์คือ Done/Doing/ToDo ทำลิสต์ทุกอย่างที่ต้องทำ จัดลำดับความสำคัญ ย้ายรายการบนสุดไปที่ Doing แล้วเริ่มทำ เสร็จแล้วก็ย้ายไป Done จากนั้นดึงรายการถัดไปจาก ToDo แล้วทำซ้ำ ฉันยังใช้ลิสต์อื่นของ Trello สำหรับจัดการการ์ดรีเสิร์ช หรือเอาฟีเจอร์ที่ไม่จำเป็นต่อ v1 ออกจาก ToDo macNchz ชอบทำงานคล้ายกับตอนทำงานในทีมเล็ก ดูแล GitHub issues ที่เป็นเช็กลิสต์จำนวนมากและจัดหลวม ๆ เป็น milestone เพราะมันอยู่ใกล้โค้ด จึงจดโน้ตไว้เตือนจุดที่หยุดได้ง่ายผ่านลิงก์หมายเลขบรรทัด, code block ที่คัดลอกมาวาง หรือ draft PR ที่ลิงก์ไว้ เข้าถึงได้ง่ายมากจากทุกอุปกรณ์ ถ้ามีไอเดียผุดขึ้นมาหรือได้รับอีเมลเรื่องบั๊ก ก็สร้าง issue ได้ทันทีจากมือถือหรืออุปกรณ์อื่นที่ไม่ใช่เครื่องพัฒนา ยังเรียกคนอื่นเข้ามาช่วยทำได้ง่ายในจังหวะที่เหมาะสม มี API ที่ดีและการเชื่อมต่อหลากหลาย (เช่น สร้างหรือลิงก์ issue จากระบบติดตามข้อผิดพลาดได้โดยตรง) rerdavies ใช้ GitHub Projects ไม่ได้อยากแนะนำเป็นพิเศษ แต่การจัดการรายการงานและบั๊กจริง ๆ ก็ไม่ใช่วิทยาศาสตร์จรวด ฉันเคยใช้โซลูชันจัดการโปรเจ็กต์ราคาหลายแสนดอลลาร์ที่แย่กว่านี้มาก ถึง GitHub Projects จะทำตัวแปลก ๆ และดูเหมือนไม่มีใครรัก แต่มันก็พอเพียงในระดับฟังก์ชันพื้นฐาน มีหลายอย่างที่คิดว่าน่าจะทำให้อัตโนมัติได้ อย่างเช่นการย้ายไป sprint ใหม่ได้ในไม่กี่คลิก โดยไม่ต้องแก้ทุก query บน scrum board ด้วยมือ แต่มันก็ทำสิ่งที่คุณอยากทำได้ ดีกว่าต้องอยู่กับกระบวนการที่คนอื่นกำหนดไว้แบบแข็งทื่อและไม่ยืดหยุ่นมาก ในบางมุม ความมินิมอลอาจเป็นข้อดี ในเชิงจิตใจ นี่คือปัญหาการจัดการรายการ มันไม่ได้ซับซ้อนมาก และ GitHub Projects ก็จัดการรายการได้ดีสมบูรณ์แบบ เหตุผลหนึ่งที่แนะนำ GitHub Projects มากกว่ารายการงานแบบกระดาษหรือการ์ด คือ ผู้ใช้สามารถเห็นได้แบบสาธารณะว่ารายงานบั๊กและคำขอฟีเจอร์ถูกจัดการอย่างไร และยังเปลี่ยนสิ่งที่อยู่บน discussion board ให้เป็นรายงานบั๊ก หรือเป็นงานพัฒนา (รอทำหรือกำลังทำ) ได้ง่ายมาก กฎ Scrum ทั่วไปยังใช้เหมือนเดิม บั๊กทุกอันต้องแก้ก่อนเริ่มงานใหม่ และงานจะย้ายเป็นเสร็จสิ้นได้ก็ต่อเมื่อเสร็จสมบูรณ์จริง ๆ เท่านั้น คุณต้องมีลิสต์ ฉันชอบมีโครงสร้างแบบ sprint ครอบอยู่เหนือชุดงาน เพราะมันให้ milestone ที่มีประโยชน์ต่อการอัปเดตระหว่างทางและการปล่อยอย่างต่อเนื่อง leros ฉันแยกบทบาทของ product manager, project manager, software developer, marketing, business operations และผู้นำธุรกิจโดยรวม แล้วทำทีละบทบาทเท่านั้น ตัวอย่างเช่น นั่งในบทบาทผู้นำธุรกิจโดยรวมเพื่อกำหนดทิศทางเชิงกลยุทธ์ที่ต้องการ จากนั้นสวมหมวก product manager เพื่อตัดสินใจว่าจะสร้างอะไร จากนั้นก็ทำ project management และจัดลำดับความสำคัญของไอเดียนั้น จากนั้นเป็น product manager/designer เพื่อทำรายละเอียดของฟีเจอร์ที่จัดลำดับไว้แล้ว จากนั้นกันเวลาออกมาแยกต่างหากอย่างชัดเจน (มักทั้งวัน) เพื่อพัฒนาฟีเจอร์ เมื่อปล่อยฟีเจอร์แล้ว ก็สวมหมวกการตลาดและทำ product marketing ที่เกี่ยวข้อง นี่คือวงจรชีวิตแบบหนึ่งของการพัฒนาฟีเจอร์หนึ่งรายการ สิ่งที่อันตรายคือการกระโดดข้ามทุกบทบาทพร้อมกัน เพราะอาจทำให้ผลิตภาพลดลง บางเวลาต้องคิดเชิงกลยุทธ์ บางเวลาต้องสร้างสรรค์ และบางเวลาก็ต้องลงมือทำเฉย ๆ ซึ่งงานเหล่านี้ต้องใช้สภาวะความคิดคนละแบบ ฉันวางแผนทุกอย่างใน Notion โดยใช้คัมบังบอร์ดหลายชุดตามวัตถุประสงค์ urda ฉันใช้ระบบ 'ความรู้' แบบไล่ระดับ: จดความคิดที่ผุดขึ้นมาแบบสุ่ม โน้ต เศษข้อมูล ไดอะแกรม ฯลฯ ลงในสมุด Moleskine พกพา จากนั้นสิ่งเหล่านี้จะกลายเป็น 'ticket' ใน issue tracker หรือเป็น 'wiki' หรือ 'wiki update' บน wiki server ของฉัน ต่อจากนั้นก็พัฒนาเป็น snippet, configuration note, document of record, archive, runbook ฯลฯ สุดท้ายแล้ว การคอยอัปเดตเอกสารให้ทันสมัย หรือถ้าเจอ issue ก็โยนเข้า backlog ที่ถูกต้อง กลายเป็นเรื่องที่ 'เป็นธรรมชาติ' ไปเอง

(news.ycombinator.com)

53 คะแนน โดย xguru 2024-06-25 | 6 ความคิดเห็น | แชร์ทาง WhatsApp

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

CharlieDigital

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

olooney

ใช้ไฟล์ TODO.md
เขียนลิสต์ด้วย GFM (GitHub flavored markdown) แบบนี้
```
  1. [X] Dockerfile  
  2. [ ] Bulk Inference  
  3. [ ] CLI  
  4. [ ] Logging  
```
ด้านบนสุดมีเซกชันชื่อ 'backlog' สำหรับไอเดียในอนาคต, เซกชัน 'bugs' สำหรับบั๊กที่ต้องแก้ และเซกชันที่ไม่มีชื่อสำหรับรายการปัจจุบัน
เมื่อถึง milestone อย่างเช่นการออกรุ่น ก็ลบรายการที่เสร็จแล้วทั้งหมดทิ้ง

jasonb05

เขียนอะไรไว้ให้ตัวเองในอนาคตเยอะมาก
1. Trello ที่มีคอลัมน์รายสัปดาห์ รายเดือน รายไตรมาส และรายปี
2. เปิดสมุดโน้ตที่วางไว้ข้างเมาส์
  2a. หน้าซ้าย: เช็กลิสต์สิ่งที่ต้องทำประจำวันด้วยปากกาและกระดาษ (วันละ 2–3 บรรทัด)
  2b. หน้าขวา: ร่างเล่น สเก็ตช์พล็อต โพสต์อิท ฯลฯ
3. บันทึกการพัฒนาที่จดเรื่องรีเสิร์ช, URL, เปเปอร์, ความคิด, ไอเดีย, ความคืบหน้า, ส่วนขยาย ฯลฯ
- ทุกโปรเจ็กต์ใน GitHub จะมีโฟลเดอร์ dev/ สำหรับโน้ตพวกนี้ และตั้งชื่อไฟล์เป็น yyyymmmdd-n.txt
- สร้างไฟล์ใหม่ต่อโปรเจ็กต์ต่อวันตามความจำเป็น
1. โพสต์อิทสีเหลืองสำหรับไอเดียชั่วคราว (แปะไว้ใต้จอ บนสมุด หรือบนไวท์บอร์ด)
- โดยทั่วไปจะเป็นคติที่ช่วยชี้ทิศทางของโปรเจ็กต์ (เช่น "ไม่มีใครอ่าน rtfm หรอก")
1. ไวท์บอร์ด, คอลัมน์แยกตามโปรเจ็กต์, เอกสารพิมพ์ + แม่เหล็ก (กราฟความคืบหน้ารายเดือนของโปรเจ็กต์), โพสต์อิท, ไอเดียสำหรับโปรเจ็กต์ในอนาคต และของจุกจิกต่าง ๆ
ฉันพยายามสื่อสารกับตัวเองในอนาคตมากเป็นพิเศษ
- มันช่วยจัดระเบียบความคิดปัจจุบันของฉัน เช่น ความคาดหวัง ความคืบหน้า อุปสรรค ฯลฯ
- อุปสรรคคือตัวฉันเอง ไม่ใช่งาน
- งานมักจะถูกวาดออกมาเป็นลำดับเลขหลังจากได้ 'คิดหนัก' แล้ว
ฉันทำงานคนเดียวแบบนี้มา 8 ปีแล้ว
- ใช้ /dev dir และไฟล์ .txt มาตั้งแต่ช่วงเรียนปริญญาเอกต้นยุค 2000 สำหรับบันทึกการพัฒนาแบบเรียลไทม์ มันช่วยประหยัดเวลาได้มหาศาล (grep)
อ้อ แล้วก็ทำสิ่งเดิมทุกวัน แทบทุกวัน
- เช่น ซัพพอร์ตลูกค้า โปรโมต เขียน โค้ด และ... ไม่ต้องคิดมาก แค่ทำงานนั้นแล้วไปงานถัดไป

liampulles

เวลาทำ side project, "การพัฒนาแบบขับเคลื่อนด้วย Readme" ช่วยสร้างแรงจูงใจและจำกัดขอบเขตงานได้

Tehnix

ตั้งเป้าหมายรายวัน/รายสัปดาห์/รายเดือน แล้วจัดระบบด้วยแอปอย่าง Linear, Todoist, Notion
เป้าหมายรายเดือนจะอยู่ในระดับสูงมากและมีไม่กี่ข้อ (เช่น "สร้าง PoC", "ออกแบบบล็อกใหม่และเปิดตัวอีกครั้ง")
เป้าหมายรายสัปดาห์จะเฉพาะเจาะจงและจำกัดมากขึ้น (เช่น "ตัดสินใจแนวทางเรียก Rust จากโค้ด Swift" หรือ "ทำดีไซน์และสไตลิงของโพสต์ให้เสร็จ")
เป้าหมายรายวันจะเฉพาะมาก (เช่น "ตั้งค่า UniFFI pipeline เพื่อสร้าง Swift bindings" หรือ "ใช้ธีมใหม่กับทั้งหน้าบล็อก")
บางครั้งระหว่างลงมือทำก็มีงานใหม่แทรกเข้ามา จนต้องเลื่อนเป้าหมายรายวันไปเป็นวันถัดไป
จนถึงตอนนี้วิธีนี้ช่วยเพิ่มสมาธิได้ดี และสามารถเลือกเป้าหมายรายวันจากรายการงาน/issue ที่กำลังทำอยู่จำนวนมากในหลายโปรเจ็กต์ โดยอิงจากจุดโฟกัสประจำสัปดาห์
ถ้าตั้งงานที่กำลังทำแต่ละอย่างเป็นโปรเจ็กต์ และกำหนดลำดับความสำคัญทันทีตอนเพิ่มงาน ก็จะมองเห็นได้ง่ายทั้งโปรเจ็กต์เล็กใหญ่ที่กำลังทำหรืออยากทำในอนาคต
แม้จะชอบกระดาษ แต่ใช้ได้แค่กับเรื่องชั่วคราวเท่านั้น ชอบวิธีดิจิทัลมากกว่าเพราะเพิ่มไอเดียจากมือถือระหว่างเดินทางได้ง่าย และการพิมพ์ด้วยคีย์บอร์ดก็เร็วกว่ามาก อีกทั้งยังใช้รายการงานหลายชุดเป็นแหล่งเก็บข้อมูลระหว่างทำงานหรือค้นคว้าได้ด้วย

OogieM

จัดการเป็นโฟลเดอร์แยกภายใน Obsidian Vault
ในโฟลเดอร์จะมีองค์ประกอบหลักที่คล้ายกัน
- มีโน้ตแบบคัมบังโดยใช้ปลั๊กอินคัมบังสำหรับโครงสร้างหน้าจอ (ในแต่ละหน้ามีฟีเจอร์หรือกิจกรรมอะไรบ้าง)
- มี roadmap note ที่เก็บรายละเอียดของแต่ละฟีเจอร์
- มีโน้ตทั่วไปที่รวมงานต่าง ๆ ของแอปหรือคอมโพเนนต์นั้น
ใช้ปลั๊กอิน tasks เพื่อติดตามสิ่งที่กำลังทำอย่างเจาะจง
- ในโฟลเดอร์นี้ยังมีเอกสารเสริม เช่น สกรีนช็อต เอกสารอ้างอิง และโน้ตอื่น ๆ ที่เกี่ยวกับแอปนั้นด้วย
โปรเจ็กต์ของฉันคือชุดโปรแกรมสำหรับจัดการปศุสัตว์และการขึ้นทะเบียนสายพันธุ์หายาก
- เลยมีทั้ง Farm Mobile (Android), Farm Desktop (Python), Registry Web (Flask), Registry Desktop (Python) และ database schema (SQLite) แยกเป็น GitLab repository คนละตัว
ตอนนี้มีผู้ร่วมงานเพิ่มอีก 3 คน เลยแชร์ Obsidian Vault ผ่าน Obsidian Sync ระบบที่เริ่มจากโซโลสามารถขยายมารองรับการทำงานเป็นทีมได้

robomartin

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

เนื้อหาในไฟล์

<ชื่อโปรเจ็กต์> log file  
-------------------------------- WORKING ON NOW   
<งานที่กำลังทำ>  

-------------------------------- TO DO   
- <เริ่มแต่ละงานด้วยขีดกลาง>  
  - <ย่อหน้าสำหรับงานย่อยหรือโน้ตที่เกี่ยวข้อง>  

-------------------------------- IDEAS  
<โน้ตอิสระ>  

-------------------------------- RESOURCES  
<ทรัพยากรแบบอิสระ>  

-------------------------------- DONE  
<ย้ายสิ่งที่เสร็จแล้วมาที่เซกชันนี้>  
<ใส่ timestamp ไว้ถ้าต้องการ>

kkfx

จัดการด้วย Emacs/org-mode/org-roam
ใช้ org-agenda ของโน้ตรายปีปัจจุบัน โดยโน้ตเป็นวันละหนึ่งไฟล์, หนึ่งไดเรกทอรีต่อปี และแบ่งไฟล์ตามช่วงเวลาไว้ในไดเรกทอรี org-roam ร่วมกัน
วิธีนี้ช่วยลดจำนวนไฟล์ที่ org-agenda ต้องไล่อ่าน และลดเนื้อหาระยะยาวที่ย้ายข้ามปีในโน้ตสรุปรายปี

makz

ก่อนเลิกงานจะคอมเมนต์ไว้ในโค้ดว่า: "ตอนนี้กำลังทำงานนี้อยู่ และถ้าจะให้มันทำงานได้ ต้องทำ A, B, C..."
ครั้งถัดไปที่เปิดตัวแก้ไขโค้ด ก็จะรู้ทันทีว่าต้องทำอะไร

qntmfred

มีเทมเพลต daily routine ใน Obsidian Daily Note มันช่วยให้โฟกัสกับวันนั้นและรู้สึกตื่นเต้นกับมัน
เครื่องหมาย [X] แรกที่ให้ตัวเองในแต่ละวันคือการทำเช็กลิสต์กิจวัตรประจำวันให้เสร็จ
- เป็นชัยชนะฟรี ๆ สำหรับการเริ่มวันอย่างมีประสิทธิภาพ
โน้ตส่วนใหญ่จริง ๆ แล้วเขียนด้วย Windows voice typing เลยคล้ายกับการทำ daily standup
อีกอย่างคือฉันมักเปิดไลฟ์สตรีมไว้ตลอดทั้งวัน แม้ว่าจะมีคนดูแค่ตัวเองก็ตาม (แน่นอนว่าเป็นไลฟ์ส่วนตัว เลยทำทุกวัน แต่ทำไว้เผื่อต้องย้อนนึกว่าเมื่อประมาณ 20 นาทีที่แล้วกำลังทำอะไร/คิดอะไรอยู่ ก่อนที่จะหลงเข้าไปในโพรงกระต่ายอีกอัน จริง ๆ แล้ว Windows Recall ก็ดีเหมือนกัน)
วันของฉันเลยดำเนินไปคล้ายกับเวลาทำงานกับคนอื่นในองค์กรที่มี 2 คนขึ้นไป (หรือที่เรียกว่าประชุม)

mentos

บอร์ด Trello ที่มีสามลิสต์คือ Done/Doing/ToDo
- ทำลิสต์ทุกอย่างที่ต้องทำ
- จัดลำดับความสำคัญ
- ย้ายรายการบนสุดไปที่ Doing แล้วเริ่มทำ
- เสร็จแล้วก็ย้ายไป Done จากนั้นดึงรายการถัดไปจาก ToDo แล้วทำซ้ำ
ฉันยังใช้ลิสต์อื่นของ Trello สำหรับจัดการการ์ดรีเสิร์ช หรือเอาฟีเจอร์ที่ไม่จำเป็นต่อ v1 ออกจาก ToDo

macNchz

ชอบทำงานคล้ายกับตอนทำงานในทีมเล็ก
- ดูแล GitHub issues ที่เป็นเช็กลิสต์จำนวนมากและจัดหลวม ๆ เป็น milestone
  - เพราะมันอยู่ใกล้โค้ด จึงจดโน้ตไว้เตือนจุดที่หยุดได้ง่ายผ่านลิงก์หมายเลขบรรทัด, code block ที่คัดลอกมาวาง หรือ draft PR ที่ลิงก์ไว้
  - เข้าถึงได้ง่ายมากจากทุกอุปกรณ์ ถ้ามีไอเดียผุดขึ้นมาหรือได้รับอีเมลเรื่องบั๊ก ก็สร้าง issue ได้ทันทีจากมือถือหรืออุปกรณ์อื่นที่ไม่ใช่เครื่องพัฒนา
  - ยังเรียกคนอื่นเข้ามาช่วยทำได้ง่ายในจังหวะที่เหมาะสม
  - มี API ที่ดีและการเชื่อมต่อหลากหลาย (เช่น สร้างหรือลิงก์ issue จากระบบติดตามข้อผิดพลาดได้โดยตรง)

rerdavies

ใช้ GitHub Projects
- ไม่ได้อยากแนะนำเป็นพิเศษ
- แต่การจัดการรายการงานและบั๊กจริง ๆ ก็ไม่ใช่วิทยาศาสตร์จรวด
- ฉันเคยใช้โซลูชันจัดการโปรเจ็กต์ราคาหลายแสนดอลลาร์ที่แย่กว่านี้มาก
ถึง GitHub Projects จะทำตัวแปลก ๆ และดูเหมือนไม่มีใครรัก แต่มันก็พอเพียงในระดับฟังก์ชันพื้นฐาน
- มีหลายอย่างที่คิดว่าน่าจะทำให้อัตโนมัติได้
  - อย่างเช่นการย้ายไป sprint ใหม่ได้ในไม่กี่คลิก โดยไม่ต้องแก้ทุก query บน scrum board ด้วยมือ
- แต่มันก็ทำสิ่งที่คุณอยากทำได้
  - ดีกว่าต้องอยู่กับกระบวนการที่คนอื่นกำหนดไว้แบบแข็งทื่อและไม่ยืดหยุ่นมาก
  - ในบางมุม ความมินิมอลอาจเป็นข้อดี
ในเชิงจิตใจ นี่คือปัญหาการจัดการรายการ มันไม่ได้ซับซ้อนมาก และ GitHub Projects ก็จัดการรายการได้ดีสมบูรณ์แบบ
เหตุผลหนึ่งที่แนะนำ GitHub Projects มากกว่ารายการงานแบบกระดาษหรือการ์ด คือ
- ผู้ใช้สามารถเห็นได้แบบสาธารณะว่ารายงานบั๊กและคำขอฟีเจอร์ถูกจัดการอย่างไร
- และยังเปลี่ยนสิ่งที่อยู่บน discussion board ให้เป็นรายงานบั๊ก หรือเป็นงานพัฒนา (รอทำหรือกำลังทำ) ได้ง่ายมาก
กฎ Scrum ทั่วไปยังใช้เหมือนเดิม บั๊กทุกอันต้องแก้ก่อนเริ่มงานใหม่ และงานจะย้ายเป็นเสร็จสิ้นได้ก็ต่อเมื่อเสร็จสมบูรณ์จริง ๆ เท่านั้น
คุณต้องมีลิสต์ ฉันชอบมีโครงสร้างแบบ sprint ครอบอยู่เหนือชุดงาน เพราะมันให้ milestone ที่มีประโยชน์ต่อการอัปเดตระหว่างทางและการปล่อยอย่างต่อเนื่อง

leros

ฉันแยกบทบาทของ product manager, project manager, software developer, marketing, business operations และผู้นำธุรกิจโดยรวม แล้วทำทีละบทบาทเท่านั้น
ตัวอย่างเช่น
- นั่งในบทบาทผู้นำธุรกิจโดยรวมเพื่อกำหนดทิศทางเชิงกลยุทธ์ที่ต้องการ
- จากนั้นสวมหมวก product manager เพื่อตัดสินใจว่าจะสร้างอะไร
- จากนั้นก็ทำ project management และจัดลำดับความสำคัญของไอเดียนั้น
- จากนั้นเป็น product manager/designer เพื่อทำรายละเอียดของฟีเจอร์ที่จัดลำดับไว้แล้ว
- จากนั้นกันเวลาออกมาแยกต่างหากอย่างชัดเจน (มักทั้งวัน) เพื่อพัฒนาฟีเจอร์
- เมื่อปล่อยฟีเจอร์แล้ว ก็สวมหมวกการตลาดและทำ product marketing ที่เกี่ยวข้อง
- นี่คือวงจรชีวิตแบบหนึ่งของการพัฒนาฟีเจอร์หนึ่งรายการ
สิ่งที่อันตรายคือการกระโดดข้ามทุกบทบาทพร้อมกัน เพราะอาจทำให้ผลิตภาพลดลง
บางเวลาต้องคิดเชิงกลยุทธ์ บางเวลาต้องสร้างสรรค์ และบางเวลาก็ต้องลงมือทำเฉย ๆ ซึ่งงานเหล่านี้ต้องใช้สภาวะความคิดคนละแบบ
ฉันวางแผนทุกอย่างใน Notion โดยใช้คัมบังบอร์ดหลายชุดตามวัตถุประสงค์

urda

ฉันใช้ระบบ 'ความรู้' แบบไล่ระดับ:
- จดความคิดที่ผุดขึ้นมาแบบสุ่ม โน้ต เศษข้อมูล ไดอะแกรม ฯลฯ ลงในสมุด Moleskine พกพา
- จากนั้นสิ่งเหล่านี้จะกลายเป็น 'ticket' ใน issue tracker หรือเป็น 'wiki' หรือ 'wiki update' บน wiki server ของฉัน
- ต่อจากนั้นก็พัฒนาเป็น snippet, configuration note, document of record, archive, runbook ฯลฯ
สุดท้ายแล้ว การคอยอัปเดตเอกสารให้ทันสมัย หรือถ้าเจอ issue ก็โยนเข้า backlog ที่ถูกต้อง กลายเป็นเรื่องที่ 'เป็นธรรมชาติ' ไปเอง

6 ความคิดเห็น

xguru 2024-06-30

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

ในแง่นั้น เครื่องคอมที่บ้านและที่บริษัทของผมแทบจะเปิด VS Code ค้างไว้ตลอด ดังนั้นการพิมพ์และลบเนื้อหาบน 할일.txt ที่เปิดค้างอยู่บนนั้นจึงเป็นกิจวัตรประจำวันไปแล้ว ผมว่าแบบนี้ดีเพราะไม่ต้องคิดว่าจะต้องเปิดอะไร และมันกลายเป็นรูทีนไปเอง ส่วนเนื้อหาก็ซิงก์ด้วย GitHub Private Repo ครับ

mytory 2024-06-26

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

devsepnine 2024-06-26

ผมคิดว่าส่วนใหญ่จะใช้ trello นะครับ ลิสต์รายการไว้แล้วก็จัดระเบียบ description...
เข้าถึงได้จากที่ไหนก็ได้ด้วย...

tested 2024-06-25

ผมสร้างเซิร์ฟเวอร์ส่วนตัวบน Discord แล้วแยกเป็นหมวดหมู่/ช่องต่าง ๆ เพื่อใช้จัดการงานอย่างเป็นระบบและใช้ส่วนตัว เช่น TODO ครับ

porteleaf 2024-06-25

ลองมาหลายวิธีแล้ว แต่ก็ยังไม่สามารถลงตัวกับวิธีใดวิธีหนึ่งได้ ตอนนี้ผมจดบันทึกใน Obsidian ส่วนงานที่ทำจริงจะเขียนลงกระดาษ legal pad เมื่อจำเป็น
อีกอย่าง ดูเหมือนว่ามันจะเป็นบันทึกเพื่อทดแทนความจำระยะสั้น เลยทำให้พอเวลาผ่านไปก็มักจะลืมว่าตัวเองเคยจดอะไรไว้บ้าง..
คงต้องลองอ้างอิงจากโพสต์นี้เพื่อจัดระบบใหม่อีกครั้ง..

hwan0317 2024-06-25

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