Category (393) 썸네일형 리스트형 PM과 하인리히 법칙 (매니저와 구성원) https://namu.wiki/w/%ED%95%98%EC%9D%B8%EB%A6%AC%ED%9E%88%EC%9D%98%20%EB%B2%95%EC%B9%99 하인리히의 법칙큰 실수는 굵은 밧줄처럼 여러 겹의 섬유로 만들어진다. Les fortes sottises sont souventnamu.wiki늦게 퇴근 + 피곤 빠르게 짧게 요약해서 대충 적겠다. 매니저는 힘들다. 혼자 프로젝트의 '재난' 이 발생하지 않게 노력하는 존재다. (위에 나무위키 참고)혼자 리스크를 부담한다. --- 리더 탓, 무능력한 리더가 고생시킨다.병사가 아닌 장교에게 책임을 물어라 --> 이것 정말 맞는말이고, 내가 좋아하는 말이다. 장교는 구성원들을 적재적소에 배치해야하는 책임이 있고,구성원들에게 비전을 제시해야한다. 근데.. 일정관리와 트래킹 두개로 나뉜다. 근데 사실 모든 걸 완벽하게 할 수 없다. 내 자신 업무를 트래킹하고, (내가 남들하고 Relation 이 있으니깐 관계가 있는 업무들은 자연스럽게 트래킹이 됨),팀을 일정관리 한다. 평가용으로 트래킹하는건 또 일을 하나 더 만드는거여서 안하는 편이다. IT 비지니스의 구조도 (주요요소) 내 인사이트는 아래와 같다. 경영 IT 프로덕트 / 서비스 / 마케팅 데이터 한국 스타트업이 밀리는 이유 예전에 내가 학생이거나 사회초년생일때는 '사회가 실패를 용납하는 분위기가 아니다''실패해도 다시 도전하는 환경이 아니여서 그렇다' 이런글을 뭔 사설이나 이렇게 접하곤 했었는데, 현업에 있으면서 이해를 했다. 스타트업이 잘되려면, 2)번이 창업을 계속 할 수 있어야한다. 1) 대학생 스타트업들이나, 사회초년생들의 스타트업들2) 스타트업 고인물 초보 스타트업에도 막 투자하겠지만 결국 투자수익율은 나와도 결국 끝까지 완주하는 경우가 드물다.스타트업 씬의 고인물들이 창업한 스타트업이 진짜다.( Exit도 해보고, 성공도 해보고, CIC 도 해보고..) 근데 중요한건 스타트업 씬의 고인물들도 돈이 있어야해서.. 결혼도 생각하고.. 가정도 생각하고도전을 할 수가 없는 부분도 있지만나이가 들고 경험이 쌓이면서사회.. [Mac] App shortcut 사용하기(노트앱 취소선) 문제)노트앱에서 취소선을 하려면 Format - font - Strikethrough (이것만 단축키가 없다!) 솔루션)Key board - App Shortcuts - Notes 등록하고노트에서 사용하는 취소선 명령어가 무엇인지 입력하면 된다.취소선은 Strikethrough 가 명령어였다! (난 shift+cmd+x 와 맵핑해놈)이후 노트앱에서 shift+cmd+x 을 사용하면 자동으로 취소선이 그어진다. 🥳 https://support.apple.com/ko-kr/guide/mac-help/mchlp2271/14.0/mac/14.0 Mac에서 앱에 대한 키보드 단축키 생성하기Mac에서 자신만의 단축키를 지정하여 앱이나 Finder에서 메뉴 명령을 수행할 수 있습니다.support.apple... 사람마다 다른 프로젝트 매니징을 해야한다. 프로젝트 매니징을 효과적으로 하기 위해서는 팀원의 역할과 경험에 맞게 관리를 구분해야 한다.**1. 역할에 따른 관리 방식**- **SI 인력**에는 명확한 기간과 테스트 기간을 제공해야 한다.- **주니어 스타트업 인재**에게는 가이드를 제공하고, 일정 확인 및 상호의존성 관리, 그리고 향후 3개월치 계획을 공유하는 정도로 관리한다.- **시니어 스타트업 인재**에게는 업무 트래킹만 충실히 제공하며 자율성을 존중한다.**2. 업무 방식에 따른 역할 분리** - 코어 프로젝트를 담당할 인력과 - 세부 작업을 담당할 인력, - 양쪽을 모두 소화할 수 있는 인력을 구분하여 역할을 배분해야 한다.**3. 효율성 관리와 균형** - 사람을 다룰 때 최상의 효율을 뽑아내는 것이 목표이지만, 그 과정.. 개발자와 기획자의 린 스타트업 차이 밑에 처럼 하기가 정말 어렵다. 밑에 스케이트보드에서 킥보드는 된다. 킥보드에서 자전거를 만들 때, 미리 설계를 못했으니 때리고 부셔야한다. 자전거 만들 때, 오토바이에 해당되는 내용까지 미리 설계를 하면 백엔드 오버헤드가 발생한다.때리고 부쉬는게 고통스럽고 상처도 많이 받지만, 최단거리다. 개발자가 2->3을 갈 때, 화가 많이 난다.기획자는 2 ->3을 갈 때, 1->2 처럼 갈 수 있을거라 생각한다. 기존 것을 활용해서 이어붙이면 가능할거라 생각한다. 물론 가능을 하지만, 그것은 때려 부쉬고 다시 만드는 것 보다 더 어렵고, 개발자 입장에서는 그것을 기획자말 대로 선뜻한다고 선택했을 때 '감당'할 수도 '책임'을 질 수도 없다. 그러면 어떻게 해야할까? 내 인사이트는 다음과 같다. 1. 대.. IT 프로젝트를 버전별 관리(APP, WEB) 앱은 버전별로 관리해서 사실 관리가 쫌 잡히는 편이고 웹은 즉시 즉시 업데이트가 되니깐 사실상 기능을 모아서 배포하기가 어렵다. 근데 이 모든건 초기 프로덕트가 있냐 없냐가 가장 중요하다. 그리고 즉시 말을 했을 때 대응할 수 있는가 -> 그렇다는 건 지금 주 업무가 비어있을 수도 있다.즉 주 파이프라인을 잡아야한다.다 대응가능한 웹 프론트 개발자가 있다고 해도 말이다.그리고 뒤에 '사소한 추가개발 및 잡 버퍼' 을 넣고 그때 짜잘한거를 몰아버리는 게 낫다. 앱은 기획에서 타겟 버전을 명시해주면 보다 쉽게 풀린다. 이전 1 2 3 4 5 6 7 8 ··· 50 다음
