Eddie's storage

팀이 너무 커졌을 때 - 기술별(Front/Backend) 분리, 임시 피처팀, 외부 컨설턴트 활용 등 여러 실험이 있었으나, 결국 범용적 역할(제너럴리스트)로 전환이 가장 실질적 효과를 냄 - Mob 프로그래밍* 등 집단 협업은 지식 공유와 자기주도성, 책임감, 동기 부여를 촉진하며, 단일 분야 고집보다 결과 중심의 협업과 성장이 유리함 *Mob 프로그래밍: 한 명의 드라이버와 여러 명의 프로그래머가 하나의 PC로 코딩 또는 문서화 작업을 진행하는 개발 방식 - 단, 범용화의 부작용(전문성 저하, 번아웃 위험) 팀이 너무 클 때의 문제 동기/비동기(Slack 등) 스탠드업 대부분의 대화가 불필요 업무 전달 누락과 비공식 작업 발생 빈번 단순 보고서로 변질 다양한 분할/운영 실험 - 기술별(Ta..

이터레이션(Iteration, 반복)SW 개발 방법론 중 하나로, 프로젝트를 진행할 때 짧은 개발 주기를 반복하며 고객의 평가와 요구를 수용하는 방법. 이터레이션(Iteration)은 SW 개발 과정을 작은 단위로 나누어 진행하며 각 단계마다 실행 가능한 SW를 만들고 SW를 고객에게 제공하여 피드백(추가 요구사항, 변경사항)을 필요한 부분만 수용하여 반영합니다. (이 과정을 반복하여 점진적으로 SW 개선이 이뤄집니다)장점1) 큰 프로젝트를 작은 단위로 나누어 개발 주기 단축2) 고객 요구사항 신속 대응 가능 3) 개발 과정에서 발생할 수 있는 위험을 조기에 파악하여 리스크를 줄일 수 있음 각 이터레이션은 일정 기간 동안 진행되며 해당 기간 동안 작업을 완료하고 실행 가능한(개선된) SW를 고객에게 제..

빅테크 회사에서 '일을 끝냈다(Done)'는 것의 진짜 의미 - Done은 무한히 개선 가능한 시스템 속에서 회사가 만족하는 상태까지 마무리 짓고, 떠나는 것을 의미함 - 유능하지만 주도성이 부족한 엔지니어는 계속해서 사소한 개선만 반복하며 진짜 성과를 놓치게 됨 - 의사결정자에게 눈에 띄는, 명확한 결과물을 전달해야 "일을 한 것"으로 인정받을 수 있음 - 자신이 하는 일이 상위 관리자에게 얽히고 평가될 수 있는 형태인지 항상 점검해야 함 '일'은 완결될 수 없는 속성을 가짐 - 서비스 개발은 무한히 개선이 가능한 열린 시스템으로, 계속 관리가 필요함 덫에 빠진 유능한 엔지니어 - 스스로 모든 일을 감당하며 작고 연속적인 개선만 반복하는 엔지니어는 성과를 내고 있다고 느끼지만 - 상위 관..

프로젝트 배포일과 결함 배포일을 하나의 캘린더에서 보고 싶다는 팀 내 의견이 있었다.위 2개의 배포일 속성은 서로 다른 DB이다. 방법을 찾아보니단일 캘린더에서 2개 DB 데이터를 동시에 표시하는 방법은 없어 보이며,상단 탭 구분으로 각각 볼 수 있어서 이 방법을 채택했다. 만드는 방법은 아래와 같다. 빈 페이지(또는 이용중인 페이지)에서 /linked 입력링크된 데이터베이스 보기 클릭이후 연결할 DB 선택- 끝 -3줄로 요약될 만큼 만드는 방법은 쉬운 편이다.  p.s. 5개월 전에 한 번 만들어 봤는데, 방법을 까먹어서 이번에 다시 찾아봤다.아무래도 한 번 만들고 나면 이용만 하지, 다시 /linked 입력·생성할 일은 거의 없다.이번에 기록으로 남겨, 나중에 탐색 시간을 줄일 목적이다.

대부분의 소프트웨어 튜토리얼은 중요한 세부사항을 빠뜨리거나 독자의 기대에 맞지 않는 숨겨진 가정을 포함하여 독자가 과정을 재현할 수 없게 만듦간단한 몇 가지 규칙을 따르면 탁월한 튜토리얼을 작성하는 것이 생각보다 쉬움규칙1. 초보자를 위한 글쓰기더보기1.1. 대부분 튜토리얼을 찾는 사용자는 초보자 임을 감안하여, 초보자 수준으로 작성할 것 - 전문가 수준 용어 사용 지양 - 어려운 용어를 피하고 독자가 이해할 수 있는 간단한 언어로 작성   (예. React 튜토리얼에서는 "JSX transpilation" 대신 "React를 사용한 간단한 웹 페이지 생성"과 같은 설명 제공)2. 명확한 결과를 약속하는 제목 작성더보기2.1. 제목은 독자가 튜토리얼을 통해 무엇을 배울 수 있는지 구체적으로 전달해야 함 ..

맥킨지의 일하는 방식 - 문제해결과정경영 환경의 변화가 커질수록 체계적, 논리적으로 문제에 접근하는 방식의 중요성이 커짐 어떤 문제에나 전략적 시각을 가지고 체계적, 논리적으로 접근하는 방식의 활용이 중요함 우리에게 필요한 과제 접근 방식은...일상의 과제도 새로운 시각에서 검토할 수 있도록 하고해결해야할 과제에 대해 큰 그림을 잃지 않으면서도, 세부적 이슈까지 구조화하여 면밀히 검토할 수 있도록 하며,정교하면서도 목적에 맞는 효과적/효율적 분석을 가능하게 하고,프로젝트 팀의 어려운 과제 해결 역량을 키워줄 수 있어야 함왜 7 Steps 문제 해결 접근 방식인가? 가장 중요한 문제를 명확히 정의하고 우선순위화를 통해 핵심에 집중함 사실과 데이터 기반의 가설을 사용함으로써 문제 해결 스피드를 높임 문제를 ..

맥킨지 7S 모델(맥킨지 7S 프레임워크)1980년대 개발한 경영 모형변화 - 모델 발생 이유조직 관점폐쇄적인 시스템 → 개방적인 시스템(주어진 환경과 상호작용)경영의 전제 조건'합리성' → '사회성'새로운 조직 관점 7개 요소각 요소는 우선순위를 갖지 않으며, Mesh형 구조 관계를 갖는다.구조전략시스템공유가치스킬스타일구성원세부사항하드한 요소구조(Structure)조직구조, 업무분장, 협력 메커니즘핵심분석질문)회사 조직은 어떻게 구성되는가?조직구조는 어떠한가?각 부서 간 활동이 어떻게 조율되고 있는가?소비자의 수요 변화에 어떻게 대처할 것인가?전략(Strategy)기업이 외부 환경에 대한 변화에 대응하거나 예상하여 계획하는 일련의 행동비즈니스의 목적과 조직의 경쟁우위 제고를 위한 방법핵심분석질문)우리의..

끝 없는 개발 추가/수정사항을 처리하기 위한 단계별 해결 전략에 대한 이야기입니다. "완료" 정의하기: 프로젝트 시작 전에 "완료"가 무엇인지 명확히 정의하고, 이를 문서화하여 범위 확장을 방지함(c.f. 킥오프)MVP* 수용하기: 완벽을 목표로 하지 않고 "충분히 좋은" 상태를 목표로 함. 기본 버전을 먼저 출시하고 나중에 개선함*MVP(Minimum Viable Product, 최소 기능 제품): 프로젝트의 핵심 가치를 가장 먼저 검증할 수 있는 최소한의 기능프로젝트 시간 제한: 프로젝트에 마감일을 설정하여 긴급성을 부여하고 기능 확장을 방지함작은 일 완료 연습: 작은 프로젝트나 작업을 정기적으로 완료하여 "완료"에 대한 두려움을 줄이고 성취감을 키움아이디어와 구현 분리: 새로운 아이디어가 떠오르면 ..

킥오프목적프로젝트의 공식적인 시작을 알리고, 모든 팀원들이 프로젝트의 목표와 계획에 대해 공통된 이해를 갖도록 하는 회의내용프로젝트의 목적, 목표, 계획(업무 우선순위 포함), 범위, 일정, 주요 마일스톤, 위험 요소, QnA 등을 논의팀원 간의 협업 방식을 정립하고, 초기 작업을 배정'성공 기준' ('완료 기준' 포함)회의록 공유온보딩목적새로운 팀원들이 프로젝트에 빠르게 적응하고, 필요한 정보를 습득할 수 있도록 돕는 과정내용프로젝트의 배경, 목표, 주요 이해관계자, 팀 구조, 사용되는 도구 및 프로세스 등을 소개팀원들이 자신의 역할과 책임을 명확히 이해할 수 있도록 지원

보편적인 정보를 현회사에 맞추어 진행하였습니다.프로젝트 산출물은 프로젝트의 각 단계에서 생성되는 문서나 자료를 의미합니다. 크게 둘로 나눌 수 있습니다.1. 관리 산출물 : 주로 PM이 작성하며, 프로젝트 계획, 진행, 종료를 관리하기 위한 문서착수 문서: 프로젝트 시작 전에 작성하는 문서(현회사에서는 생략 됨)계획 문서: 일정, 인력 등의 계획을 수립하는 문서(노션 페이지 속성 '일정', '담당자' 등으로 대처)수행 문서: 프로젝트 진행 중 작성하는 문서(노션 페이지로 대처)종료 문서: 프로젝트 마무리 시 작성하는 문서(비고. 회고)2. 수행 산출물 : 실무자(QA, 기획자, 개발자 등)가 작성하며, 프로젝트 실제 작업을 기록하는 문서분석 문서: 요구사항 분석 및 시스템 분석 문서(결과: 기획서)설계 ..