313devgrp

나는 아래글의 내용에 몇가지 의문을 제기한다.개발자의 성과를 측정하는 지표가. Code 에 한정되어 있다는 것이다.물론 틀린말은 아니다. 아니. 틀렸다.우리는 생각을 확장 시켜야 한다.이런 생각을 해 보았는가? " 개발자가 목표하는 바가 무엇인가? "" 어떤 지시를 받고, 이런 코드를 생산하고 있는가? " 코드의 생산성이 개발자의 성과가 아니다.회사의 성과 기준은. 개발자에게 지시했던 요구사항이 기준이 되어야 한다. 어째서, 이미 틀렸을 수도 있는 코드를 가지고 지표를 만들고 있는가?  출처 : https://medium.com/proofer-blog/%EB%8F%84%EB%9D%BC-%EB%A9%94%ED%8A%B8%EB%A6%AD-dora-metrics-%EC%A7%80%ED%91%9C%EB%8A%9..

출처 : https://www.hankyung.com/article/2024080531721 현대차 이어 현대오토에버 손 들어줘…'PIP 적법성' 인정 "근무성적 등 개선 가능성 없어사회통념상 고용 유지 어렵다"회사 능력개선 기회 부여도 고려 기업 '저성과자 교육' 확대 전망 속객관적 판단 기준 만드는 게 중요  개발자인데도 기본 코딩 능력을 갖추지 못한 데다 개선 의지도 없고 근무 태도조차 불량한 저성과자의 해고는 정당하다는 대법원 판단이 나왔다. 지난 1월 현대자동차의 저성과자 해고를 적법하다고 인정한 데 이은 대법원의 결정이다. 회사 측이 자체 프로그램을 통한 자구 노력을 한 경우 법원이 해고를 인정하는 판결이 잇따르고 있어 주목된다. 이번 판결로 기업의 저성과자 향상 프로그램(PIP) 도입이 확대..

PLE의 정의- 소프트웨어를 개발할 때 체계적인 재사용 기법을 적용함으로써 동일 영역에서 다양하게 특화된 소프트웨어를 신속하게 개발할 수 있는 효과적인 매커니즘을 제공하는 접근 방법- 컴포넌트가 플러그인 될 수 있는 프레임워크를 제공하는 아키텍처를 기반으로 필요한 컴포넌트를 선택적으로 조립함으로써 시장의 요구사항에 맞는 시스템을 생산하는 방식PLE의 등장 배경- 컴포넌트 기반의 개발 자체가 재사용성을 높여주지 않음- 재사용성을 고려해 주의 깊게 개발하지 않으면 컴포넌트를 재사용하기 어려움PLE의 구성1. 핵심자산(Core Asset) 개발 과정- 한 도메인에 속한 여러 어플리케이션들의 공통적인 Feature을 핵심자산으로 모델링하고, 이를 재사용할 수 있도록 구체화하는 작업- 하나의 시스템 또는 유사한 ..

A-RMS 솔루션 개발을 완료 했습니다.지난 10년간의 노력으로 IT 현실을 바로잡을 소프트웨어 이며,요구사항 기반의 ( requirement ) 프로젝트 관리 시스템 입니다.많은 관심을 부탁드리며, 곧 실제 사례를 기반으로어떻게 IT 회사의 고질병을 고쳐서 경쟁력을 확보하는지 증명하도록하겠습니다. 많은 기대 부탁드립니다.

출처 : A Three-Step Framework For Solving Problems 문제 해결을 위한 3단계 프레임워크 * 에어비앤비에 입사해 배운 점 중 하나는 무엇보다도 문제 정의를 올바르게 하는 것이 중요하다는 것입니다. * 프로젝트를 실패로 이끄는 많은 요인이 있지만 해결 중인 문제를 오해하는 것보다 더 확실한 건 없습니다. * 에어비엔비에서 저와 팀이 해결해야 할 진짜 문제는 "여행자가 다른 여행자와 어울리고 싶어한다"가 아니라    "여행자는 관광지가 아닌 양질의 일을 찾고 싶어한다"라는 사실을 너무 늦게 깨달았습니다. * 다른 여행자들과 어울리는 것은 실제 문제가 아니라 이에 대한 한 가지 해결책이었을 뿐입니다. * 문제를 해결하는 가장 중요한 단계는 문제 정의를 완성하는 것입니다.  *..

제품 판매후에도 지속적(recurring)인 수익 창출을 의미하는 ‘리커링 비즈니스’(recurring business)라고 한다. 어제 ( 09-02 ) 한국 아틀라시안 총판인 Dmove 와 ARMS 를 설명드리면서 요구사항 기반의 ( RMS ) 프로젝트 메니지먼트 시스템 ( PMS ) 을 말씀 드리며, 아키텍쳐까지의 이야기를 하는 와중에 이런생각이 들었습니다. ARMS 는. 플랫폼을 포괄하는 소프트웨어 였구나. ARMS 의 플랫폼도 고객사에 제공하여, 리커링비지니스를 이어가되 실제 비용을 추가로 받는게 아닌 더 많은 서비스를 통한 Lockin 에 집중하는 리커링 비지니스를 방향으로 해야 할 것 같다는 생각이 들었습니다.

출처 : https://www.thestartupbible.com/2024/03/business-before-technology.html참조 : https://313.co.kr/php/gnuboard5/bbs/board.php?bo_table=notice&wr_id=16&page=2 A-RMS By 313DEVGRP www.a-rms.net 회사의 가장 중요한 목표는 돈을 벌 수 있는 제품과 서비스를 만드는 건데, 굉장히 많은 개발자들이 자신에게 월급을 주는 회사의 목표와는 상관없는 생각과 행동을 한다는 것이었다. 개발자들이 항상 명심해야 하는 건 바로 이들이 해결하고자 하는 문제의 솔루션이 본인들이 소속된 기업의 비즈니스 목표와 매출에 직접적으로 기여해야 한다는 점이다.  개발자들도 회사의 조직원이고,..

^^

결국 무엇인가를 잘 하려면. 오랜 시간동안 해야 하고, 오래 하다보면, 경험이 쌓이고, 노하우가 쌓이면, 보다 좋은 결과를 얻을 확률이 높아진다. 하지만? 어느 누구도 그 노력의 시간을 성공이란 보상으로 보장을 해주지 않는다. 도리어 실패의 단초에 대한 의견이 적날하게 피드백 되는경우가 더 많지. 그럼에도 오래 해야 한다는 명제는 변하지 않는다. 시도하고. 관심을 가지고. 더 확장하고. 깊게 파고들지 않으면 결국은 제 자리에 있을테고 , 시간은 흐를테니 말이다. 이 과정을 견딘다는 것이. 얼마나 고통스러운 일인지...누구나 다 안다. 그게 성공을 담보하지 못한다는 두려움까지 말이다. 그래서 꼭 말하고 싶었다. 오랜시간 동안 무언가를 꾸준히 하는 사람들은 많지 않습니다. 그래서 오래 할 수록. 경쟁은 줄어..

XML 에서 json으로 Properties는 YML으로 Maven은 Gradle로 Spring은 Spring boot로 ... 그렇다. 원래 있었다. 그것도 아주 정교하게 말이다. 그런데 여기서 시작된다. 많은 사람들이 이야기 하기 시작한다. "불편해..." 기존 체계의 불편함보다는. 그들은 기존 체계의 깊이를 이해하기가 싫은거다. 물론 기존체계의 문제점을 지적하는 데코도 필수이겠지만. ( 몇비트의 tag duplication 중복 등. ) 시니어들이 그들의 기술 체계를 발전시키는 욕망은. 깊이보다는 확장에 무게를 두는 시대였다. 그러니 대동단결하여 변화가 이루어진 케이스다. 변화의 탈을 뒤집어 쓰고 개선이라는 미명아래. 간소화를 주장하지만. 실제 필드에서 개발하려고 하면. 그 간소화가 확장포인트를 찾..