Pivotal Tracker 서비스 종료

 (pivotaltracker.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • VMware Tanzu 부서에서 Pivotal Tracker 서비스의 종료(EOL)를 발표
  • 2025년 4월 30일까지 Pivotal Tracker 구독을 사용할 수 있으며, 이후 서비스가 종료됨
    • 그 전에 데이터를 내보내는 것을 권장
    • 2025년 4월 30일 이후에는 데이터 마이그레이션 지원이 제공되지 않음

FAQ

  • 어떤 계정이 영향을 받는가?
    • 무료, 후원(학술 또는 비영리), 월간/연간 유료, 엔터프라이즈 구독 플랜을 포함한 모든 계정이 영향을 받음
    • 2025년 4월 30일까지 사용 가능하며, 이후 갱신이나 거래는 발생하지 않음
  • 프로젝트 데이터를 어떻게 다운로드하는가?
    • 프로젝트 스토리, 에픽, 히스토리 및 파일 첨부를 내보내는 방법에 대한 도움말 센터의 CSV 내보내기 문서를 참조할 수 있음
    • 새로운 정보와 피드백을 바탕으로 추가 지침이 도움말 센터에 추가될 예정임
  • 과거 인보이스에 접근할 수 있는가?
    • 기존의 플랜 및 청구 페이지에서 과거 인보이스에 접근할 수 있음
  • 새로운 사용자나 계정을 생성할 수 있는가?
    • 초대 없이 Tracker에 가입하거나 새로운 계정을 생성할 수 없음
    • 그러나 협력자 한도를 초과하지 않는 한, 계정/프로젝트에 새로운 사용자를 초대할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 무료 사업 아이디어: 1인 개발자나 작은 팀으로 Pivotal Tracker 클론을 만들면 됨
    사업 아이디어를 어디서 찾느냐는 질문이 많은데, 지금처럼 사라지는 제품을 좋아한다고 공개적으로 말하는 사람이 많은 상황이 바로 검증된 기회임
    이미 사람들이 돈을 내던 제품이고 꽤 많은 사용자가 있었던 것으로 보이니, 그냥 제품을 복제하고 “Pivotal Tracker 클론”이라고 마케팅해도 VMWare가 신경 쓸 가능성은 낮음
    현재 Pivotal Tracker를 쓰는 회사를 조사해 데이터베이스를 만들고, 제품이 준비되면 콜드콜이나 이메일 영업을 할 수도 있음
    React나 Svelte, 호스팅 데이터베이스 같은 현대 기술을 쓰면 혼자나 아주 작은 팀으로도 비교적 단순하게 복제 가능한 제품임
    핵심은 작게 유지하는 것임. 매출이 비용을 정당화하지 못하거나, 벤처투자 압박으로 크게 가거나 망하라는 식이 되면 이런 사업은 무너짐
    $100/월짜리 Hetzner 서버, Go나 C# 같은 효율적인 백엔드, Svelte나 React 프런트엔드면 많은 고객을 감당할 수 있고, 나머지는 시간과 영업력의 문제임

    • 아침에 맡는 신선한 낙관주의 냄새가 좋긴 함
      가장 큰 난관은 빠르게 만들 수 있는 1인 개발자 대부분이 이미 좋은 직장에 다니고 있다는 점과, 이주하려는 사용자가 다른 결정을 내리기 전인 1월 1일쯤이 사실상 MVP++ 마감이라는 점임
      그리고 마이그레이션이 시작되자마자 저장소 비용이 급증할 테니, 출시 시점부터 과금 전략이 필요함
    • 핵심 제품은 비교적 단순하지만, Pivotal 같은 소프트웨어 패키지는 핵심 기능만으로 팔리는 게 아님
      실제 판매 포인트는 연동과 자동화 같은 부가가치이고, 이런 것들은 훨씬 더 오래 걸리고 더 많은 인력이 필요함
    • 가장 큰 위험은 사람들이 다음으로 나은 선택지인 Linear로 몰려갈 가능성임
    • 이 제품은 어떤 이유로든 사업이 접힌 것임. 요즘은 더 나은 도구가 있는 듯한데, 왜 침몰한 배를 따라 만들려는지 모르겠음
    • 도전 받아들임
      큰 회사용 웹앱을 여러 개 만들어봤고, Pivotal Tracker를 정말 좋아했으며 사라진 게 너무 아쉬움
      바로 편집기를 열고 내 Pivotal Tracker 계정에서 내보낸 데이터를 가져와, 이를 가져올 데이터 모델을 만들고 그다음 UI로 옮기는 작업을 시작했음
      기본 제품은 꽤 직관적이지만, 일부 기능이 발전해온 방식에는 섬세한 차이가 많음
      MVP에서 전부 담지는 못할 가능성이 크니, 새 제품이 이 틈새를 채우려 할 때 빠지면 정말 아쉬울 Pivotal Tracker의 핵심 기능이 무엇인지 궁금함
      다른 프로젝트 추적 도구에 흔한 기능 중 넓히거나 개선할 만한 부분도 보이는데, Pivotal Tracker가 기업에 팔리기 어렵게 만든 빠진 기능이 무엇이었는지도 알고 싶음
      이 스레드에 피드백을 남겨주면 계속 볼 예정이고, 다른 경쟁자가 개발로 한판 붙고 싶다면 그 피드백을 같이 봐도 됨
      출시 알림이나 다른 소식을 받고 싶으면 이메일 목록 https://mailchi.mp/73f113e474f1/robert-kohrs-blog에 가입하거나, 블로그 RSS https://robkohr.com를 팔로우하면 됨

  • Pivotal에서 항상 좋았던 점은 큐가 하나뿐이라는 게 눈에 보였다는 것임
    모두가 무자비하게 우선순위를 정하고 어려운 결정을 내리게 만들었음
    지금 이 순간 버그를 고치게 할지, 새 기능을 만들게 할지 결정해야 했고 둘 중 하나만 선택할 수 있었음
    덕분에 “모든 게 높은 우선순위”가 되는 딜레마를 피할 수 있었음

    • 커스터마이즈를 허용하지 않고, 구체적이고 정의된 상태만 고집한 점도 좋았음
      이슈는 할 일, 진행 중, 완료, 전달됨, 승인됨 정도가 전부였음
      Jira의 사용자 정의 이슈 상태는 특별한 종류의 지옥임
    • 바로 이 이유 때문에 Pivotal Tracker를 정말 좋아했음. 훨씬 더 집중된 도구였고, 지금까지 써본 작업 추적기 중 단연 가장 좋았음
      내 프로젝트 대부분이 코드와 관련돼 있어서 결국 GitHub Projects로 옮겼는데, 솔직히 집중도가 비슷함
      단점은 비기술 직군도 GitHub 계정이 필요할 수 있다는 점이지만, 실제로는 큰 장애물이 아니었음
    • 하나의 큰 큐 대신 고객별로 큐를 나누는 방식도 있음. 외부 고객, 내부 팀, 개발팀 자체 기술 부채 등을 별도 흐름으로 두는 방식이고, “JIT selection from independent streams: An alternative to the “big backlog” of work”에 설명돼 있음
      https://longform.asmartbear.com/jit-backlogs/
      각 고객이 자기 큐 순서를 관리하면 개발팀은 각 큐의 맨 앞 항목에 집중하면 됨
      물론 개발팀은 다음 몇 개 작업의 요구사항을 고객과 함께 명확히 해서 맨 앞 작업이 바로 착수 가능한 상태가 되게 해야 함
      이후 개발팀은 각 큐의 맨 앞 항목 중 무엇을 우선할지 고르고, 고객 작업 외에도 항상 기술 부채 1개와 버그 수정 X개를 진행 중으로 두는 식의 균형을 유지할 수 있음
    • 한 팀에서 써봤을 때는 항상 지나치게 단순하게 느껴졌음
      그래도 인정할 수밖에 없는 건, 우리는 보통 각 스프린트에 약속한 것을 실제로 전달했고 과도한 커밋이 언제 발생하는지도 꽤 명확했음

  • 안타까움. 써본 프로젝트 관리 도구 중에서는 Pivotal을 제일 덜 싫어했음
    자주 하는 일을 쉽게 하게 해줬고, 커스터마이즈를 sane한 수준으로 제한했음
    전반적으로 방해가 되지 않는 도구였음. Jira를 의미심장하게 바라보게 됨

    • 결국 Linear에 정착했는데, 방해가 되지 않음
      지금은 그렇다는 뜻임. 경쟁 제품들을 보면 기업가치를 정당화하려고 비대해지는 건 시간문제로 보임
      https://linear.app/
    • 동의함. 이 도구가 좋았던 이유 중 하나는 방치되고 있었기 때문이라고 봄
      모호한 새 기능들이 없고, 더 복잡한 대형 플랫폼 묶음의 일부가 아니라는 점이 좋았음
    • 동의함. 10년 넘게 Pivotal Tracker를 써왔고 지금도 쓰고 있음
      Jira와 몇몇 도구를 써봤지만 보통 관리 부담이 너무 크다고 느꼈음
      커스터마이즈와 일상 관리가 가벼운 대안이 뭐가 있는지 궁금함
    • 전 Pivotal 직원으로서 PT를 정말 좋아했음. Jira 같은 것들과 비교하면 더더욱 그랬음
      VMWare가 회사를 망가뜨릴 게 분명해 보였고, Broadcom은 그걸 더 확실하게 만들었음
      한때는 훌륭한 회사였음, Pivotal Labs 말임
      이제는 끝났음
    • https://www.shortcut.com은 Linear보다 덜 고집스럽고 Pivotal에 더 가까운 1:1 대안으로 느껴졌음
      다들 조금씩 비대해지고 있어서, 계속 기능을 추가하기보다 줄이는 쪽으로 가는 제품이 있었으면 함
      Linear도 결국 그렇게 될 미래처럼 보임

  • Pivotal Tracker에게 한 잔 따름. 이건 시대를 앞선 뛰어난 티켓 추적 및 프로젝트 관리 시스템이었음
    계약직 소프트웨어 엔지니어링을 하던 시절, Pivotal Tracker는 기능 요청이 미치는 영향을 고객에게 완벽히 보여주고 고객이 자기 사업에 맞는 절충을 직접 선택하게 해줘서 고객 관계 관리가 쉬웠음
    “이 새 기능을 바로 추가하고 싶나요? 문제없습니다. 다만 보시다시피 이걸 4점짜리 작업으로 이번 주에 끌어오면 나머지가 이틀 밀리고, 그러면 다른 걸 잘라내거나 출시일을 바꿔야 합니다”라고 설명할 수 있었음
    훌륭한 UI, 훌륭한 분위기였고 쓰는 즐거움이 있었음. PT는 사라져도 그 유산은 남을 것임

  • PT의 명복을 빔. 이 소프트웨어가 내 인생을 얼마나 바꿨는지 말로 다 못함
    Pivotal에서 일하던 시절, 아주 초기 Cloud Foundry 시절이었는데, 소프트웨어와 제품을 개발하는 법을 정말 많이 배웠음
    사람들과 밀접하게 일하는 법, 페어 프로그래밍의 힘, 반복 개발과 속도에 주의를 기울이는 법, 스토리를 쓰는 법, 시간이 지나며 형편없는 것을 다듬어가는 법을 배웠음
    이 기술들을 매일 쓰고 있고, 다른 어떤 것도 이에 근접하지 못함

    • 나도 같음. 15곳에서 일해봤지만 이곳은 완전히 달랐고, 페어 프로그래밍과 TDD가 제대로 수행되는 걸 본 유일한 곳이었음
      한 번은 버그가 전혀 없는 거래 제품 첫 버전을 배포한 적도 있음
      이후 다른 사람들에게 이 방식을 설명하려 하면, 동화라도 들은 것처럼 어깨를 으쓱했음
      다른 시스템 마이그레이션 중에 몇 번 더 시연할 기회가 있었고 매우 성공적이었으며 정신적·감정적 부담도 아주 낮았음
      테스트 케이스를 먼저 항목화하고, 가짜 구현을 만들고, 자주 커밋하고, 트렁크 기반 개발을 하고, 작은 스토리와 점진적 개선을 사용했음
      하지만 이를 설계된 성공으로 받아들이지 않았고, 보통은 편견이 너무 강해서 익숙한 소프트웨어 개발 원숭이 서커스 속 우연한 변동 정도로 봤음
      이제는 전 동문들을 위한 지원 모임이 필요한 단계임
    • Pivotal에서 일했던 다른 사람들에게도 비슷한 얘기를 들었음. 엔지니어링 팀이 꽤 멋졌던 것 같음
    • “시간을 들여 형편없는 것을 다듬는다”는 건 결국 반복하고 피벗한다는 뜻임

  • Shortcut(https://www.shortcut.com/)은 Pivotal Tracker의 괜찮은 대안임
    나는 거기서 엔지니어링 매니저로 일하고 있고, Pivotal Tracker 데이터를 Shortcut으로 가져오는 가져오기 도구(https://github.com/useshortcut/api-cookbook/tree/main/pivota...) 제작을 도왔음
    Shortcut은 팀 지향 제품이고 GitHub/Gitlab/Bitbucket 및 Slack 연동이 탄탄함

    • 여전히 열도 너무 많고 상태도 너무 많게 느껴짐
      Pivotal Tracker는 ice box, backlog, current iteration 정도였음
      Trello 지옥에 빠진 회사들을 보면 의도는 좋지만 상태가 자주 뒤섞이고 회색지대가 생김
      보드에 열이 10~15개쯤 있고, 완전히 난장판이 됨
    • 와, 이거 한때 Clubhouse라고 불리지 않았나? 과거가 확 떠오름
      오래전에 Papa에서 Clubhouse를 썼었음

  • 아직도 전담 팀이 있고 전진하는 오픈소스 자체 호스팅 추적·프로젝트 관리 도구가 있을까?
    예전에는 Phabricator 인스턴스를 자체 호스팅해서 썼고 꽤 좋아했지만, 업스트림 유지보수자가 떠나기로 한 건 납득할 만한 결정이었음
    이제 자체 호스팅 솔루션의 틈새가 크지 않은 것 같음
    낮은 복잡도의 대부분 사용 사례는 GitHub Issues 무료 티어가 커버하고, 더 복잡한 사례는 기업용 SaaS가 처리함

  • 이 소식은 슬픔. PT를 안 쓴 지 10년은 넘은 것 같지만, 그 전에는 3~4년 동안 많이 썼음
    다른 “애자일” 도구들과 비교하면 숨통이 트이는 도구였음
    아주 단순했고 모든 것이 한 화면에 있었고, 상태 간 이동도 쉬웠음
    우리 팀은 창 하나에 열어놓고 하루 종일 띄워둔 채 필요할 때마다 바꿀 수 있어서 좋아했음
    이후로 이 정도로 근접한 도구를 본 적이 없는 것 같음
    몇 년 만에 로그인해보니 아직도 사이드 프로젝트 두 개가 남아 있었음. 이제 내려받아야 할 때인 듯함

  • 2011년의 Pivotal Tracker 프로젝트를 열어봤는데, UX가 얼마나 좋았고 지금도 좋은지 놀랐음
    시각적으로는 낡아 보이지만 UX는 훌륭하다고 봄
    단순함은 높은 정보 밀도로 강화됨. 많지만 압도적이지 않음
    요즘 디자인 흐름은 정보 밀도를 너무 낮춰서 스크롤을 많이 하게 만들고, 무언가를 보기 위해 훨씬 더 많은 에너지와 시간을 쓰게 함
    항목을 “열어야” 할 때도 같은 화면에 머물러 있음. 모달도 없고 맥락 전환도 없음. 메타데이터, 설명, 대화만 있고 그 이상은 없음
    Linear에서는 프로젝트, 사이클, 보기, 프로젝트 때문에 완전히 길을 잃음
    지금은 GitHub Issues/Projects에 묶여 있지만 Pivotal의 단순함이 그리움
    방금 10MB짜리 Pivotal CSV를 내보냈음

  • 37Signals가 이런 걸 복제해서 https://once.com/로 팔아줬으면 함
    한 번 결제하고 직접 설치해 호스팅하는 방식이면 좋겠음

    • Basecamp에 보드 보기가 있어서 그렇게 하지는 않을 것임
답변달기