차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- 독서:코딩도_하고_사장도_합니다 [2024/03/22 00:45]
kwon37xi
+++ 독서:코딩도_하고_사장도_합니다 [2024/03/22 01:41] (현재)
kwon37xi
@@ 줄 6: / 줄 6: @@
 프로그래머가 어떻게 사업을 할까 해서 보았는데, 구체적으로 실무적인 내용을 기대했으나 에세이 형식이라서 실무적인 부분은 직접 찾아봐야 할 것으로 보인다.
 앞 부분은 프로그래머에게 이런 저런 충고 하는 이야기들.
+특히 자본주의의 이해에 대한 부분은 새겨 들어야 할 것 같다.
 > 고등학교 국어시간에 중국 당송8대가 중 한 사람인 송나라 문인 구양수의 삼다와 삼상에 대해 배웠다. 삼다는 글 잘 짓는 비결이 다독(학교에서는 이렇게 배웠으나 원문에는 다문(多聞 들을 문) 으로 되어 있다), 다작, 다상량, 즉 많이 읽고, 많이 짓고, 많이 생각하라는 뜻이다. 프로그램을 잘 만드는 비결 또한 이와 같다. p.108
@@ 줄 69: / 줄 71: @@
 > 발주기관의 우선 순위를 정한다.
 > 소프트웨어 개발을 발주하는 가장 큰 기관은 정부와 공기업 그리고 대기업이다. 정부 기관도 중앙 부처에서 부터 외청 기관, 지방 자치 단체에 이르기까지 그 수가 헤아릴 수 없이 많다. p.340
+> 수주하려는 분야의 완성 제품을 보유하고 있어야 한다. 근사한 제품 이름도 짓고 저작권 등록도 하고 가격도  책정하여 홈페이지에 공개한다. ... 보유 기술이나 솔루션은 무얼 말하는지 애매할뿐더러 잠재적 능력에 불과하다. 반면에 제품은 발주업체에게 이미 실현된 능력으로 보인다. p.341
+>  완성된제품이 있다면 이것을 해당 프로젝트의 필요 소프트웨어로 포함시킬 수 있다. 이것은 마치 필요한 하드웨어 장비나 OS, DBMS 처럼 따로 구입해야할 품목으로 가격을 책정할 수 있다는 뜻이다.
+> 만약 완제품 형태가 아닌 반제품 개념의 라이브러리 형태로 가지고 있다면 어떻게 해야 할까? 이때도 무조건 완제품으로 브랜드를 만들고 유저당, 서버당, 프로세서당 얼마라는 가격을 매기고 이와 같은 방식으로 해야 한다. p.342
+> 규모가 큰 SI 프로젝트의 하청을 받아 개발 용역을 수행하는 것은 통제할 수 없는 여러 위험 요소가 있다. 우선 하청의 단계가 많아지면 단가가 떨어지고 수익성이 나쁘다. ... 이런 방식의 개발 용역에는 하청을 주는 회사와 위험 요소를 감안하여 확신한 계약을 따로 맺는 게 좋다.
+> 반면에 소프트웨어만 단독으ㄹ 발주하는 프로젝트는 규모가 작기 때문에 발주사로부터 직접 수주할 수 있다. p.343
+> 입찰하는 큰 프로젝트보다는 수의계약하는 작은 프로젝트 여러 개가 수익성  면에서더 나을 수 있다. p.344
+> 프로젝트의 금액 규모가 크면 그만큼 위험 부담도 커진다. 따라서 회사의 재무 상태를 감안하여 일정 금액 이상의 프로젝트에는 참여하지 않는게 안전하다. p.344
+> 다음 프로젝트에서 보상하겠다는 말로 이번에는 싸게 해달라고 하거나, ' 전략적제휴'나 장기적으로 볼 때 'win-win' 이라는 등으로 공짜나 단가를 낮출 것을 제의받을 때가 있다. 나는 이런 요구에 한 번도 응해본 적이 없다. 시야가 좁아서인지 몰라도 소프트웨어 개발 용역 시장에 '다음은 없다'는 생각을 갖고 있다. p.345
+> 보통 1 Man/Month 당 1천 2백만원에 미치지 못하면 참여하지 않았다. p.346
+> 발주받고 싶은 기관의 관련 업무를 미리 파악하고 프로젝트 기획서를 작성하여 담당 부서에 전달할 필요가 있다. ... 설령 나중에 이 프로젝트가 공정한 경쟁 입찰에 붙여진다 하더라도 공고 후 10여 일 남짓의 기간에 작성된 제안서가 미리 1년 전부터 준비하고 다듬어진 제안서를 이기기는 힘들다.
+> 특히 1억 원 미만의 수의계약이 가능한 비교적 작은 프로젝트의 기획서를 여러 건 만들어두고, 이것을 그해 9월 정도에 발주기관 담당자의 손에 들어가도록 하는게 중요하다. p.348
+> 프로젝트의 성공은 기술력으로만 이루어지지 않는다. 기술력은 필요조건이고 거기에 발주사 사람들과의 좋은 인간관계라는 충분조건이 더해져야 성공할 수 있다. p.348
+> 인간관계의 첫걸음은 인사성이다. 특히 발주사로 파견 나가는 직원은 어떻게 인사해야 하는지  철저히 교육시켜 보내야 한다. 아는 사람이든 모르는 사람이든 언제 어디서 마주치든 시도 때도 없이 무조건 인사하도록 한다. 모르는 사람에게는  어떻게 인사할 것인가, 아는 사람에게 상황에 맞는 적절한 인사말 멘트는 무엇인가 등의 인사법에 대한 회사의 규정을 만들어놓는 것도 좋다. p.348
+> (프로젝트 이름에 현업 전문가의 "이름 약자type" 같이 넣어주는 식)으로 참여한 현업 전문가(domain expert)를 대접해 줄 요소를 잘 찾아봐야 한다. 중간 발표나 최종 발표 등의 행사에도 참여한 전문가에게 의향을 물어 한 부분을 직접  설명하도록 하면 좋다.완료보고서, 매뉴얼등에도 이름을 올려준다. p.350
+> 완료 기한을 반드시 지킨다
+> 기한 안에 마치지 못할 것 같으면 반드시  해야할 기능의 우선 순위를 정하고 완료일까지 가능한 부분만 마치고 모두 마친것으로 완료보고서를 쓰고 검수를 통과하는 능력도 필요하다. 사소하게 미진한 것들은 하자보수 기간에도 얼마든지 보충할 수 있다. p.350
+> 4~6개월마다 중간 발표를 한다.
+> 중간 발표에는 문서로만 프레젠테이션 할 게 아니라 그때까지 만덜어진 소프트웨어의 결과를 보여주는게 중요하다. 따라서 중간 발표에 맞춰 내부 로직이 완성되지 않았어도 현업 사람들에게 보여줄 수 있는 기능을 먼저 만들 필요가 있다. p.351
+> 정부나 공기업은 달라고 조르지 않아도 기다리면 무조건 주게 되어 있다. p.352
+> 후속 프로젝트 수주가 가능한 발주사는 그쪽에서 미안해할 수 있는 분위기를 만들어서 졸라야 하고, 떼어 먹힐 염려가 있을 때는 악착같이 그야말로 수단 방법 가리지 말고 졸라야 한다. p.353
+>  프리랜서를 쓰면 당장의 프로젝트 수행에는 도움이 될 수 있어도 유지보수와 후속 프로젝트에 이르기까지 길게 보면 문제가 많다는 생각에서였다.
+> 나는  프리랜서를쓸 일 있으면 다른 회사와 계약을 맺고 하청을 주는 방식을 택했다. p.353
+> 하자보수 기간에 매달 보고서를 제출한다
+> 우리는 매달 하자보수 보고서를 작성하여 발주사에 공문으로 보냈다. 그 달에 무엇을 고쳤고 고객에게 어떤 문의를 받고 어떻게 대처혔는지 상세한 일지를 적어보냈다. .. '앞으로 이런 기능이 추가로 있었으면 좋겠다는 의견이 있었다'는 식으로 적었다. p.354
+> 10-10 사업 생존에 성공한 후 가장 먼저 해야 할 일은 무엇있까? 바로 창접자의 충분한 수입이다. 창업자의 급여를 현실화하고, 이후에 발생하는 수익에 대해서는 곧바로 배당할 수 있다. 더 이상 몸빵을 해서는 안 되며 충분한 보상이 이루어질 수 있는 조건이라 하겠다. p.360
+> 관리 체계를 최적화하여 비용의 누수를 막고, 인건비 이외의 다른 관리비의 비중을 최소로 하여, 상대적으로 인건비 비중을 높여야 한다는 뜻이다. 전체 비용에서 인건비 비중이 70% 이하로 떨어지면 아마도 만족할 만한 수익을 내기 어려울 것이다. 80% 이상을 목표로 해야 한다. p.362
+> 업무프로세스를 빠짐없이 정의한 다음, 이에 따른 업무 매뉴얼을 작성하고 알맞은 인력을 배치한다. ... 업무 프로세스 정립의 가장 큰 목적은 적은 인원으로도 잘 돌아가는 최적의 관리 체계를 만들기 위함이다. 그래야 10명 이내의 적은 이원으로 야근을 하지 않으면서, 휴가를 가거나 퇴사하고 새로운 인원으로 교체되어도 업무의 공백이 생기지 않는다. p.364
+> 나중에 골머리 썩고 싶지 않으면 함부로 지분을 나누지 말자. 사업의 세계는 죽고 못사는 형제 같은 사이라도 언젠가는 헤어지고, 돈 앞에 장사 없다는 게 진리다. p.371
+> "창업자가 과반 이상 최대한 많은 지분을 확보하며 자기 회사를 만들고, 남은 지분을 몇 배수로 할증하여 투자를 받는 게 기본이다. 투자한 사람에게 투자금 액면 그대로 지분을 나눠주는 바보는 없다. ..." p.380
+> "잘되도 문제 안되도 문제인 지금 회사는 접고 진짜 당신 회사를 만들어라. 그동안 들인 돈과 시간은 비싼 수업료를 낸 셈치고 이제부터 진짜 창업을 해라. 첫째는 투자받지 마라...." p.380
+> 제품 소개하는 발표를 할 때 결정권자의 반응을 최우선으로 살펴야 하고, 그분의 기분을 좋게 하고 만족을 주면 성공 확률이 높다는 걸 청조 씨는 깨달았다. p.387
+> 예고된 댓가는 인간의 창조적 문제 해결을 현저히 떨어뜨린다고 한다. p.413
+> 성과급은 예고하지 말고 약속하지 말고 확실한 성과를 낸 직원에게만 불시에 지급해야 효과가 있다. p.414
+> 작은 회사의 직원 동기부여 팁
+>> 1. 성과급 제도를 운영하지 않는다. 성과를 냈으면 이듬해 급여에 반영하여 확정한다.
+>> 2. 중소기업 업계 평균 이상의 급여를 지급한다.
+>> 3. 자질구레하고 큰 의미 없는 복지 정책을 없애고 관리 비용을 줄여 직원의 급여를 높이는 데 집중한다.
+>> 4. 심리적인 안정 상태에서 스트레스 없이 일할 수 있는 분위기를 만든다.
+>> 5. 일에 대한 성취감이 최고의 동기부여과 되도록 만드는게 중요하다.
+>> 6. 결국 회사에서 주입하는 동기부여는 의미가 없고, 자발적 동기에 의해 일하는 문화를 만들어야 한다. p.415
+> 카를 융은 '무의식을 의식화하지 않으면 무의식이 우리 삶의 방향을 결정하게 되는데, 바로 이것을 두고 우리는 '운명'이라고 부른다'고 했다. p.427
+> 오너프로그래머가 하는 10-10(직원 10명 10억매출) 사업은 가장 큰 스트레스가 인간관계, 그중에서도 직원과의 관계에서 온다. 직원 모두를 오너가 상대해야 하기 때문이다. 그 스트레스에서 벗어나려면 적어도 20명 이상,매출은 연간 30억 원 이상인 회사로 키워야 한다. 이때부터는 직원  모두를직접 상대할 필요가 없다. p.429

권남

사용자 도구

사이트 도구

차이

문서 도구