본문 바로가기

Product Insight

(77)
개발자는 어디까지QA 를 해야할까? https://medium.com/@kth5604/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-qa%EB%A5%BC-%EC%96%B4%EB%8A%90%EC%A0%95%EB%8F%84-%EA%B9%8C%EC%A7%80-%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98-ae10e94ed296 개발자는 QA를 어느정도 까지 해야하나? 요약 medium.com 내 생각: - 초기 프로덕트 런칭 과정 개발자랑 , 걍 개발자랑 구분해야함 - 개발팀 꽤 있고 qa 팀있고 이런 개발자는 걍 논할 대상도 아님 초기팀에서 초기 프로덕트 런칭 과정에 있는 개발자라면, 도대체 QA를 어느정도 까지 해야하나? 바로결론: 개발자 실력에 따라 케이스 바이 케이스 개발실력 별로 없으면 기능개발만..
Css vs scss vs tailwind vs 어쩌구 걍 css 만 열심히 공부하면 다른건 다 됨 그리고 css도 매번 업데이트가 되고 이ㅏㅣㅅ음 scss 가 변수? css 도됨 scss 가 Nested ? css 도됨 https://velog.io/@my_suwan/CSS-CSS-Nesting [CSS] CSS Nesting CSS 중첩규칙 velog.io css 도 매번 업데이트가 되고 있음 물론 업데이트 된다고 실무에 사용하면 안되겠지만, 그래도 근본이다. css 근본 공부를 열심히 해야한다. 난 최근에 next 프레임워크에 module.css 로 작업하는데 아무런 부족함 없다 --- css 업데이트 참고 https://hyoni-k.tistory.com/179 CSS의 새로운 기능 (2022 구글 I/O 주요 기능) 2022 구글 I/O 개발자 컨퍼..
주니어 개발자 주니어 개발자는 사실 진짜 괜찮은 사람아니면 회사에서 뽑을 이유가 없다. 그리고 괜찮은 사람이 있다고해도 1명의 주니어 개발자를 서포트하려면 시니어 급 1명, 4~5년차 4명 정도가 든든히 버텨줘야 가능하다
내가 IT 프로덕트를 만드는 전략 스타트업에서 어떻게 IT 프로덕트를 만드는가 많은 난관이 있다. 사람, 자본, 시간, 기술력 너무 당연한 소리겠지만 MVP가 나와야한다. MVP는 그냥 대표가 들고다니면서 시연하는 용이면 그냥 대표가 노코드툴이다 그림판으로 만들면 되고, 내가 말하는 MVP는 변경가능하도록 개발 스택과 낮은 개발 러닝커브와 유지보수가 가능한 코드지만 낮은 비용으로 유지보수가 가능한 MVP를 만드는 것이다. 예를 들어 typescript 를 사용하지않는다. 1. 있는 자원을 사용한다. (현재 있는 자원을 사용한다.) 캐릭터를 좋아하는 디자이너가 있으면 그냥 활용한다. 프로덕트가 시장반응이 있으면 그리고 우리가 고객 여정 파이프라인을 잘 설정했다면 새로운 디자이너가 합류해 디자인 고도화 프로젝트를 띄울 수 있다. 2. 있는 ..
타입스크립트 왜 씀? in startup 많은 사람들이 타입스크립트를 써야한다고 하지만 나는 그렇게 생각하지 않는다. 타입스크립트는 프론트 개발자만 4,5명이면 써야한다. 회원이 4천명이 넘어가면 써야한다. 하지만 프론트 개발자가 1~3이면 걍 편한걸로 빠르게 개발해야한다. 그전에 사업의 기회를 놓치고 조직과 팀이 사라질 수 있다. 내가 언제나 하는 말이 있는데 개발자는 기획자와 대표가 상상할 수 있게 해줘야한다. 그럴려면 거점을 계속해서 만들어야한다. 타입스크립트를 스터디해서 들어가겠다? 노 타입스크립트 잘 모르는 조직이면 걍 안쓰면 된다.
7시는 이미 늦다 7시 기상 후 회사까지 네비를 찍어보면 57분 걸린다. 이미 늦었다. 진짜 말그대로 늦는다. 뭔가 이루고 싶다면, 남들과 다른길을 가고 싶다면 6시에는 시작해야한다 오래된 생각이다. 일찍와서 코딩좀 한두시간 해야한다. 자꾸 관리직으로 올라가고 사람만나도.. 내가 익힌 도구들은 항상 날카롭게 준비가 되어있어야한다. ------------------------- 5시 30분 기상 6시 out 한두시간 코딩 ------------------------- 요거 루틴화 하기!
기존운영개발과 프로덕트런칭개발의 분리 운영과 개발의 분리 남규가 프렌즈용으로 칸반보드를 만들어서 새롭게 생각할 거리가 생겼다. sprint 처럼 치고 오는거랑 운영하는 거랑 구분해야한다. 근데 실제로는 작은 규모에서 분리가 안된다. 그러면 한팀이 어떻게 운영과 개발을 같이 할수 있을까? 툴이나 업무관리에서 매니져가 확실히 분기를 해야한다. 칸반보드도 섞이지 말아야한다. 도메인의 분리가 필요하다. 평균이하들의 비지니스는 똑똑한 사람들보다 더 똑똑해야 살아남는다.
모빌리티 쪽 온 이유 (메모) 그럼 빨리 하고 싶을거 잖아.. 근데 왜 못하고 있어..!? Gips Picasso -> 내부적으로만 사용하네..? 코믹스택. 플랫폼을 하고 싶었어! 그래서 모빌리티쪽으로 왔다.