1인 개발자로서 어떻게 체계적으로 관리하시나요?
(news.ycombinator.com)- 팀과 함께 일할 때는 스크럼과 같은 단기 목표와 체계적인 작업 백로그가 집중력을 유지하고 해야 할 일을 추적하는 데 정말 도움이 되었음
- 하지만 혼자 개발할 때는 제대로 된 접근 방식을 찾지 못했고, 종종 옆길로 빠져 목표를 잃어버리곤 했음
- 여러분은 목표에 충실하기 위해 어떤 도구와 기법을 사용하시나요?
CharlieDigital
- 종이 노트북 사용
- 정보를 공유할 필요가 없을 때는 모든 아이디어를 펼쳐놓고 반복해서 확인하는 데 노트북만큼 좋은 것이 없음. 로그인할 필요도 없고, 어디든 가지고 다니며 벤치에 앉아 아이디어를 떠올리고, 헬스장에 가서 아이디어를 적어보세요.
- 매일의 목표를 체크리스트에 적어두고 하나씩 체크해 나가면 됨. 다른 사람과 상태를 공유할 필요가 없으니 GitHub 프로젝트 같은 것도 필요 없음
olooney
-
TODO.md
파일을 사용 - GFM(GitHub flavored markdown)으로 다음과 같이 리스트를 작성
1. [X] Dockerfile 2. [ ] Bulk Inference 3. [ ] CLI 4. [ ] Logging
- 향후 아이디어를 위한 '백로그'라는 섹션, 수정할 버그를 위한 '버그' 섹션, 현재 항목이 있는 이름 없는 섹션을 맨 위에 작성
- 릴리즈와 같은 마일스톤에 도달하면 완료된 모든 항목을 삭제
jasonb05
- 미래의 나에게 많은 글을 작성함
- 주, 월, 분기, 연도별 열이 있는 Trello
- 마우스 옆에 둔 노트북 열기
2a. 왼쪽 페이지: 펜과 종이로 일일 할 일 체크리스트. (하루에 2~3줄)
2b. 오른쪽 페이지: 스크래치, 플롯 스케치, 스티커 메모 등 - 리서치, URL, 논문, 생각, 아이디어, 진행 상황, 확장 기능 등을 기록하는 개발 일지
- 모든 깃허브 프로젝트에는 이러한 메모를 위한 dev/ 폴더가 있으며, 파일명은 yyyymmmdd-n.txt
- 필요에 따라 매일 프로젝트당 새 파일을 작성
- 임시 아이디어를 위한 노란색 스티커 메모(화면 하단, 노트북 또는 화이트보드에 붙임)
- 일반적으로 프로젝트의 올바른 방향을 제시하는 격언(예: "아무도 결코 rtfm하지 않을 것")
- 화이트보드, 프로젝트별 열, 인쇄물 + 자석(프로젝트 진행 상황 월별 도표), 스티커 메모, 향후 프로젝트를 위한 아이디어, 각종 물건들
- 나는 미래의 제 자신과 과도하게 소통하려고 노력함
- 기대치, 진행 상황, 장애물 등 현재 내 생각을 정리하는 데 도움이 됨
- 내가 장애물이지 작업이 아님
- 작업은 일반적으로 '열심히 생각'한 후에 숫자로 그려짐
- 8년 동안 혼자서 이렇게 일하고 있음
- 00년 초 박사 과정 시절부터 실시간 개발 일지를 위해 /dev dir 및 .txt 파일을 사용해 왔음. 수없이 많은 시간을 절약할 수 있었음(grep).
- 아, 그리고 매일 같은 일을 함. 거의 매일
- 예를 들어 고객 지원, 홍보, 글쓰기, 코딩, 그리고.... 생각할 필요 없이, 해당 작업만 하고 다음 일을 함
liampulles
- 사이드 프로젝트 진행시에는 "Readme 주도 개발"이 동기를 부여하고 스코프를 제한하는데 도움이 됨
Tehnix
- 일일/주간/월간 목표를 세우고, Linear, Todoist, Notion 등의 앱으로 이를 체계화
- 월별 목표는 매우 높은 수준이고 몇 개 정도임(예: "PoC 만들기", "블로그 재설계 및 재출시")
- 주간 목표는 보다 구체적이고 제한적(예: "Swift 코드에서 Rust를 호출하기 위한 접근 방식 결정" 또는 "게시물의 디자인 및 스타일링 완료")
- 일일 목표는 매우 구체적(예: "Swift 바인딩을 생성하기 위해 UniFFI 파이프라인 설정" 또는 "블로그 페이지 전체에 새 테마 구현")
- 때로는 구현 중에 새로운 일이 생겨서 일일 목표를 다음 날로 미루기도 함
- 지금까지는 이 방법이 집중력을 높이는 데 효과적이었고, 여러 프로젝트에서 진행 중인 많은 작업/이슈 목록에서 주간 중점 사항을 기준으로 일일 목표를 선택
- 진행중인 각 작업을 프로젝트로 설정하고, 작업을 추가할 때 즉시 우선순위를 지정해 놓으면 진행 중이거나 앞으로 하고 싶은 크고 작은 프로젝트를 쉽게 한눈에 파악할 수 있음
- 종이를 좋아하긴 하지만 일시적인 일에만 사용할 수 있음. 이동 중에 아이디어가 떠오를 때 휴대폰으로 쉽게 추가할 수 있는 디지털 방식을 선호. 또한 키보드로 글을 쓰는 것이 훨씬 더 빠르며, 작업을 하거나 무언가를 조사하는 동안 다양한 작업을 정보 저장소로 활용
OogieM
- Obsidian Vault 안에 각각 폴더로 관리
- 폴더에는 비슷한 공통 요소가 들어 있음
- 화면 구조(각 화면에 어떤 기능이나 활동이 있는지)를 위해 칸반 플러그인을 사용한 칸반 노트
- 각각의 기능에 대한 세부 사항이 담긴 로드맵 노트
- 해당 앱이나 구성 요소에 대한 다양한 작업이 포함된 일반 노트
- 작업 플러그인을 사용해 구체적으로 작업 중인 내용을 추적
- 이 폴더에는 특정 앱과 관련된 스크린샷, 참고 자료, 기타 노트와 같은 추가 문서가 들어 있음
- 내 프로젝트는 가축과 희귀 품종 등록을 관리하는 프로그램 모음임
- 그래서 Farm Mobile(Android), Farm Desktop(Python), 레지스트리 웹(Flask) 및 레지스트리 데스크톱(Python) 앱과 데이터베이스 스키마(SQLite)를 모두 별도의 GitLab 리포지토리로 가지고 있음
- 이제 3명의 공동 작업자가 추가되어 Obsidian Sync를 통해 Obsidian Vault를 공유. 솔로 시스템이 팀워크를 처리할 수 있도록 확장되었음
robomartin
- 수년간 칸반에서 영감을 받은 간단한 텍스트 파일을 사용중
- 소규모 프로젝트부터 수백만 달러 규모의 프로젝트까지 이 방식으로 모든 것을 관리
- 각 프로젝트에는 메인 로그 파일이 있고, 분야마다 고유한 파일(전자, 기계, 광학, 제조, 테스트 등)이 있음
- 파일의 내용
<프로젝트 이름> 로그 파일 -------------------------------- WORKING ON NOW <작업 중인 작업> -------------------------------- TO DO - <대시로 각 작업 시작> - <관련 하위 작업 또는 노트 들여쓰기> -------------------------------- IDEAS <자유 형식 노트> -------------------------------- RESOURCES <자유 형식 리소스> -------------------------------- DONE <완료된 내용을 이 섹션으로 이동> <원하는 경우 타임스탬프 남김>
kkfx
- Emacs/org-mode/org-roam 으로 관리
- 현재 연도 노트의 org-agenda, 노트는 하루에 한 파일씩, 1년에 한 디렉터리씩 공통 org-roam 디렉터리에 시간 단위로 파일로 나눔
- 이렇게 하면 org-agenda가 이동해야 하는 파일의 양이 줄어들고, 연도별 요약 노트에서 한 해에서 다른 해로 넘어가는 장기 실행 자료가 줄어듦
makz
- 퇴근하기 전에 코드에 댓글을 남김: "지금 이 작업을 하고 있는데, 작동하려면 A, B, C...를 해야 함"
- 다음에 코드 편집기를 열면 무엇을 해야 할지 정확히 알 수 있음
qntmfred
- Obsidian Daily Note에 데일리 루틴 템플릿이 있음. 그날에 대해 집중하고 설레게 만듦
- 매일 내 자신에게 주는 첫 번째 [X]는 일일 루틴 체크리스트를 완성하는 것
- 생산적인 하루를 시작하기 위한 공짜 W
- 실제로 대부분의 메모를 Windows 음성 타이핑을 사용해 작성하기 때문에 데일리 스탠드업을 하는 것과 비슷
- 또한 하루 종일 라이브 스트리밍을 하는 경우가 많기 때문에 시청자가 나 혼자뿐이더라도(물론 개인 라이브 스트리밍이기 때문에 매일 하는 것이지만, 내가 어떤 토끼굴에서 길을 잃기 전에 약 20분 전에 무엇을 하고 있었는지/생각하고 있었는지 상기시켜야 할 때를 대비해 하는 것. 사실 Windows 리콜도 좋음)
- 내 하루는 2인 이상의 조직에서 다른 사람들과 함께 일(일명 회의)할 때와 비슷하게 진행됨
mentos
- Done/Doing/ToDo 세 가지 목록이 있는 Trello 보드
- 해야 할 모든 일의 목록을 작성
- 우선순위를 정하기
- 맨 위에 있는 항목을 할 일 목록으로 옮기고 작업을 시작
- 완료되면 완료로 옮김. 다음 항목을 할 일 목록에서 빼고 반복
- 나는 트렐로의 다른 목록을 사용해 리서치 카드를 관리하거나 v1에 필요하지 않은 기능을 ToDo 목록에서 제거함
macNchz
- 소규모 팀과 함께 일하는 방식과 비슷하게 일하는 것을 좋아함
- 많은 항목이 포함된 체크리스트가 마일스톤으로 느슨하게 정리된 깃허브 이슈를 관리
- 코드에 가깝기 때문에 줄 번호 링크, 복사 붙여넣기 코드 블록 또는 링크된 PR 초안으로 쉽게 메모를 작성하여 잠시 중단한 부분을 기억할 수 있음
- 어떤 기기에서든 액세스하기가 매우 쉬워서 아이디어가 떠오르거나 버그에 대한 이메일을 받으면 휴대폰이나 개발 기기가 아닌 다른 기기에서 즉석에서 이슈를 빠르게 만들 수 있음
- 적절한 시점에 다른 사람을 불러서 바로 작업하도록 하는 것도 간단
- 좋은 API와 다양한 통합 기능(예: 오류 추적 시스템에서 직접 이슈를 만들거나 링크하는 기능)이 있음
- 많은 항목이 포함된 체크리스트가 마일스톤으로 느슨하게 정리된 깃허브 이슈를 관리
rerdavies
- 깃허브 프로젝트를 사용
- 특별히 추천하고 싶지는 않음
- 하지만 작업 목록과 버그를 관리하는 것은 사실 로켓 사이언스는 아님
- 수십만 달러가 드는 프로젝트 관리 솔루션을 사용해봤는데, 그보다 훨씬 더 형편없었음
- Github 프로젝트는 이상하게 동작 하고 사랑받지 못하더라도 최소한의 기능만으로는 충분
- 자동화할 수 있을 거라고 생각하는 많은 것들이 있음
- 스크럼 보드의 모든 쿼리를 수동으로 수정할 필요 없이 클릭 몇 번으로 새 스프린트로 롤오버하는 것과 같은 것들
- 하지만 당신이 하고 싶은 일을 할 수 있음
- 다른 사람이 정해놓은 프로세스에 따라 유연하지 못한 상태로 살아가는 것보다는 훨씬 나음
- 어떤 면에서는 미니멀리즘이 장점일 수도
- 자동화할 수 있을 거라고 생각하는 많은 것들이 있음
- 심적으로는 , 이것은 목록 관리 문제. 그리 복잡하지도 않음. 그리고 깃허브 프로젝트는 목록을 완벽하게 잘 관리함
- 종이 기반 또는 카드 기반 작업 목록보다 Github 프로젝트를 추천하는 한 가지 이유는
- 버그 리포트와 기능 요청이 어떻게 처리되고 있는지 사용자에게 공개적으로 볼 수 있다는 점
- 또한 토론 게시판에 올라온 내용을 버그 리포트로 전환하거나 개발 작업(지연 또는 활성)으로 전환하는 것이 매우 쉬움
- 일반적인 스크럼 규칙이 적용됨. 모든 버그는 새 작업을 하기 전에 수정되고, 작업은 완전히 완료된 경우에만 완료 상태로 전환
- 당신에겐 목록이 필요함. 나는 작업들의 위쪽에 스프린트 구조가 중간 업데이트와 지속적인 릴리스에 유용한 마일스톤을 제공하기 때문에 이를 좋아함
leros
- 나는 제품 관리자, 프로젝트 관리자, 소프트웨어 개발자, 마케팅, 비즈니스 운영, 전체 비즈니스 리더 등의 역할을 구분하여 한 번에 하나씩만 수행함
- 예를 들어,
- 전체 비즈니스 리더로 앉아 제가 원하는 전략적 방향을 결정할 수 있음
- 그런 다음 제품 관리자의 모자를 쓰고 무엇을 구축할지 결정
- 그런 다음 그 아이디어를 프로젝트 관리하고 우선순위를 정함
- 그런 다음 제품 관리자/디자이너가 되어 우선순위를 정한 기능을 구체화
- 그런 다음 완전히 따로 시간을 내서(보통은 하루 종일) 기능을 개발
- 기능이 출시되면 마케팅 모자를 쓰고 관련 제품 마케팅을 진행
- 이것이 하나의 기능을 개발하는 일종의 라이프사이클
- 위험한 것은 한 번에 모든 역할을 뛰어넘는것. 생산성이 떨어질 수 있음
- 전략적이어야 할 때, 창의적이어야 할 때, 그냥 실행해야 할 때가 있고, 이러한 작업에는 각기 다른 머리 공간이 필요함
- 나는 Notion에서 모든 계획을 세우면서 목적에 따라 몇 가지 다른 칸반 보드를 사용
urda
- 나는 계단식 '지식' 시스템을 사용함:
- 포켓용 몰스킨 노트에 무작위로 떠오르는 생각, 메모, 스크랩, 다이어그램 등을 기록
- 이것은 결국 이슈 트래커에서 '티켓'이 되거나 제 위키 서버에서 '위키' 또는 '위키 업데이트'가 됨
- 이는 결국 스니펫, 구성 노트, 기록 문서, 기록 보관, 런북 등으로 이어짐
- 결국에는 문서를 최신 상태로 유지하거나 이슈가 발견되면 올바른 백로그에 넣는 것이 '자연스러운' 일이 되었음
저는 어떤 것이든 자신에게 루틴화 하는 게 편한 방법이 최고라고 생각합니다. 다른 준비작업이 많아서 관리 문서를 열고 시작하는게 오래 걸리고 귀찮아 진다면 점점 멀어지게 되거든요. 책상 치우고 난 뒤에 어딘가 넣어둔 노트북을 꺼내서 펼치는 것 자체도 일처럼 느껴지니까요.
그런 점에서 전 집과 회사 컴터에 VS Code가 거의 켜져 있어서, 그 위에 띄워둔 "할일.txt"에 내용을 적고 지우고 하는 게 매일 일과입니다. 뭘 띄워야 할지 생각 안하고 루틴화 되어서 좋은 것 같아요. 내용은 GitHub Private Repo로 동기화 합니다.
저는 구글 스프레드 시트에 프로젝트 할 일을 30분에서 한 시간 단위로 쪼개서 전부 적어 놓고 완료까지 든 시간을 적습니다. 예측하기 좋고 하나씩 클리어하는 기분도 들고요.
여러 가지 방법을 시도해 봤지만, 아직 하나의 방법으로 정착하지 못했습니다. 현재는 메모를 Obsidian에서 하고 있으며, 실무는 리갈패드에 필요할 때마다 적고 있습니다.
이 또한, 휘발성 기억을 대체하기 위한 메모라서 그런지 시간이 지나면 무엇을 메모했는지 잊어버리는 경우가 많은것 같아요..
이 글을 참고해서 체계를 다시 잡아봐야겠습니다..