프로세스 회의

1차

– 일정 뺄개 거의 없다는 이야기를 듣고…ㅋㅋㅋ

개발의 문제

  • 골목식당, 음식 낼 준비, 기계화 자동화,
  • 플레이댓 프로젝트 들어갈 큰 기능 요건만 정해진 상태에서 날짜가 픽스 된다. 왜 이렇게 진행되는가?
    1. 관리자페이지 레이아웃을 프로젝트마다 새롭게 만드는게 아니라 공통된 관리자 화면이 미리 준비되면 좋겠다. 공수를 줄일수 있을 것이다.
    2. 고객에게 필수적으로 필요한 질문리스트를 만들어 볼 수 있겠다
    3. 강좌기능 게시판 댓글 모델링을 분리해서 모듈화해볼 수도 있겠다.
    4. 유저 및 권한을 먼저 기획해주면 작업이 조금더 수월할 것 같다.
    5. 일정 음..
    6. 프로세스 정리를 해보자
    7. 사업부에서 경험해보는 큰 프로젝트기 때문에 시행착오는 있을 수 밖에 없으며 최대한 다음을 위해서라도 교훈을 빼낼 수 있는 것들은 빼내야한다.
    8. 저는 자바 개발자지만, 시일이 촉박한 프로젝트에 자바가 맞나라는 의문이 들때가 있다. 생산성 좋은 루비, php도 있는데..기술선택에대한 고민도 필요
    9. 게시판, 댓글 대댓글, 여러 관리 스케줄러 등 제로베이스에서 시작할줄 몰랐다. 시일이 촉박한데 회사에 축적된 다른 소스를 끌고와서 기본적인 게시판을 조금 고치는 방식등
    10. 기획쪽에 다른 프로젝트와 커뮤니케이션할때 어떻게 달랐는지 궁금하다.
    11. 프로젝트 후 base 프로젝트에 담을 수 있는 것들을 최대한 담고 다음 프로젝트에 활용하자
    12. base 프로젝트들을 따로 묶음으로 정리하자
    13. java dto 를 너무 만들어서 한스님이 알려주신 방법과 다르게 했더니..다시 늘려야할지도.. 차후 스프링 프로젝트할 때는 정리된 방법을 모색
    14. 이런 프로젝트는 선임 개발자급이 기획단계에함께 참여해야하지 않을지 몇몇 사안에서.. 알림톡 등 , si에서는 pl급 개발자
    15. 알림톡 같은 경우 프로젝트 수주당시 확인된 작업일까? 하는 의문.. 프로젝트 수주시에 확인되지 않는 작업들이 많이 추가되는 느낌..
    16. 우리가 프로젝트를 할 때 미리 공통화된 Admin페이지 디자인과 레이아웃을 준비 해두면 이 또한 나름의 브랜딩이 될것 같다.
    17. 미리 준비한 Base 프로젝트에는 여러가지 기능 고도화를 꾀해볼 수 있을 것이다. (게시판, 댓글에 다양한 기능이 있다면 마다할 고객 없을것, 관리자에게 웹푸시, 채팅, 모바일 앱레이아웃)
    18. docker 이미지를 이용하면 미리 세팅된 기본 환경을 미리 만들어 둘수는 없을까?
    19. 라이나 프로젝트의 경우, PL(개발 리더 ) 가 라이나 회의를 어느정도 참여하는것이 좋지 않았을까 생각해본다. 개발적으로 Migration, 여러가지 개발적인 재반사항들을 확인하고 협의를 PM이 하는데는 한계가 있지 않았을까 한다. 그리고 개발 기간 혐의를 할 때도 개발에서 부족함을 목소리 낼수 있지 않을까함
    20. 기획 관련 협의가 늦어지는데 개발 완료 일정은 변경할 수 없었는데, 계약관련해서 특정상황에 대해서 일정을 딜레이시킬수 있는 여지는 없었는가?
  • Social Impact 사업부 기초가 되는 프로젝트를 만들자
  • 프로젝트마다 제로베이스에서 시작되는 것은 잘못되었다.
  • 관리자페이지 레이아웃, 로그인, 회원(휴면, 탈퇴관리 포함), 게시판, 댓글 정도는 미리 구성이 가능하다.
  • 위 기능 이외에도 공통화할 수 있는 기능
  • 지속적으로 기능을 업그레이드 할 수 있다.(계속 만들면서, moqup같이 관리자끼리 푸시를 넣을 수도 있고, 우리가 수집하면 좋을 로그 분석자료도 얻을수 있게 하고, A/B테스트 가능하게 할수도 있을 것이다. 이런 것이 가능한 부분이 관리자 페이지 쪽이지 않을까)
  • 관리자페이지의 디자인이 우리회사의 브랜드 같은 느낌을 줄수도 있을 것
  • 개발자들의 새로운 기술 사용을 해보고 싶어하는 부분을 해당 프로젝트로 해볼수 있을 것이다. 특히 관리자 페이지에서는 SEO이슈가 적으므로..
  • 유저 테이블의 경우 기본 유저테이블을 만들고 1대1 로 연결하여 프로젝트마다 추가하면된다.

  • 백엔드 - Springboot + jpa or Django or rails, gradle, 예제데이터 입력부분도 바꾸자 ->
  • 프론트엔드 - react or vue , pwa 적용
  • Social Impact 기획에서도 공통되고 필수적인 질문을 모아서 정리하고 놓치지 않도록 표준화(?) 하면 좋을듯함 #div-social-sideproject 채널을 만들어서 해볼까?

계약때 작업 범위가 확정되지 않은것 같다. 알림톡, 데이터 마이그레이션,

여러가지 일정 기획 확정이 더딘 부분으로 인해 일단 작업을 시작하다보면, 데이터를 붙이다가도 어떤 부분은 덜 확정이 되어서 덜 붙여놓거나 다시 붙이기도하고 기타 등등… 한 소스를 자주 다시 보게되는 문제… 덜 그려져있거나.. 다시 물어보거나… 해야한다. 하다가 중지하고 다른거 하다가 또 다시 보기도하고.. 여러모로 비효율적.. 기획이 원래 확정이 덜된 상태에서 이렇게 진행이 되는 것이 맞나

계약은 어떻게 이루어지는지 모르겠으나 우리가 할 수 있는 일을 산정하고 이 기능 이기능은 몇일 걸리 겠다 산정한다. 보통에 개발자가 일정산정한 것보다 1.5 곱하기 2는 해야 여러가지 기능들이 합쳐졌을때 문제되는 부분이 여유있게 가져갈 수 있다.근데 오픈 일정은 불변으로 픽스 해두고 계속 기능 추가가 되는 상황 요구사항은 늘고, 이건 애초에 계산이 안맞는 거다. 요구사항이 있다고 해서 다들어줄 수 없다. 요구사항이 늘어나서 여러 문제거리가 생긴다면 서로의 신뢰에 금이 간다 오히려 마이너스다. 어느 특정일자까지 30여가지의 기능을 픽스 시키고 일정을 안배했는데, 만약에 추가 요구사항이나 이미 만든 기능을 수정하거나 하는 요청은 거기서 일자를 + 시켜야 한다. 일정을 + 시키지 않으면, 개발자 디자이너들의 야근이 플러스가 될뿐이다. 그러면 나오는 품질은 더더욱 기대할 수 없고 우리가 전달하는 제품의 질은 떨어질것이다. 우리의 일정산정 파악과 관리 도 부족했고, 그쪽에서 계속해오는 요구사항들을 막을 수도 없다. 그러면 우리는 야근을 불사르면서 일을 해야하나? 우리는 사회혁신을 이야기 하는데, 우리 회사 직원은 우리나라의 곪아 있는 관행중인 갑을 관계로 인해 직원들은 갑을 관계에 상처를 받는다.

데이터 이관 계획을 세웠으나 연습진행이…

소스를 미리 받아야한다. 데이터도 미리 받아야한다. 큰거 이관이 필요한프로젝트들 경우…

디자인이랑 기획이랑 다른경우가 꽤 있다.. 음.. 미리 만들어두어도 소용이 없을 데가 있다…

업무 방식이 기존에 해왔던거랑 좀 달라서 일을 찾지 못하고 해매는 경우가 있었다..

만들었던거 다시 보고 또 다시봐야된다 하도 바뀌어서… … 기획 픽스는 오픈 3개월 전에는 픽스 됬어야된다고봄, 지금 한달도 안남은 시점에서 아직도 논의 중인게 있는상태는 무언가 잘못된거임.

프로젝트 참여하기로한 인원중 4명이 퇴사를 했는데 정상적으로 오픈은 사실상 어려운일, 선화님이 퍼블치고, 안태님이 들어왔지만 두분다 온전히 업무가 어려움

무슨일이 추가 되고 무슨일이 추가될때마다.. 이건 해야한다 라고 이야기하는데, 우리쪽업무가 얼마나 남았는지 파악은 되지 않은채 해야한다고만 하면 우리 몸은 2개도 아니고 3개도아닌데 무조건 밤샘해야하나 그쪽입장은 생각하면서 왜 우리 입장은 생각하지 않나..

업데이트

적정인원은 백엔드 4 jquery 자바스크립트 다루는.. 전문 퍼블리셔 2 기획이 확정된채로 3개월은 달렷어야 가능하비 않앗을까 싶다

소셜 규칙중에 일정 공유하기가 있는데 공유해도 고객에 해야한다면 해야한다. 주말까지 일을 하는데 더 해야한다

2014년 부터 운영되던사이트 개발은 그 이전 부터 되었을거고 지속적으로 유지보수하고 기능을 추가했을 사이트다. 그런 사이트를 이기간에 기획하고 오픈이 애초에 잘못된거다

  • 프로젝트에 주도적으로 참여하며, 스스로 정한 일정은 지킨다. - 스스로 정하지만 고객이 필요하다고 하면 의미가 없어진다.
  • 문제가 발생할 가능성이 있거나 일정 변경이 필요한 경우 미리 공유한다. 공유를 하지만 고객이 필요하다고 하면 의미가 없어진다.

다우니님 퇴사가 왜 이렇게 급 퇴사인가, 보통은 사람을 구할 여유를 주기 위해 한달이라는 기간을 법적으로도 주고 있다. 지금 엄청난 프레셜를 받고 있는 프로젝트 진행속에 누군가는 해외여행에 교육에 다 허용해주어도 되는가? 휴가도 4일씩쓰고

모르겠다왜

순서가 완전 잘못되었다. 회원이 가장 먼저 정리 되어야 나중에 테스트도 편하고 진행이 편해지는데 회원이 가장 마지막에 정리되고 있다.

오픈이 3주남았는데 이렇게 큰 분량의 프로젝트가 이제 디자인이 나오고 퍼블들어가는게 정상적인가?

막판에 이렇게 다 던져주면 할수 있나..

정말 궁금한것중에 하나가.. 계약을 하면 디자인이 컨펌이 나지 않아도 미룰수 없나? 왜 그렇게 계약이 되어 있지? 계약을 해서 일정을 픽스시켜놓고 해야할일을 계속 추가하고 디자인을 컨펌이 안나서 다시 그려서 확정받으면서 시간을 낭비했는데 왜 일정은 그대로지 계약은 그렇게 밖에 할수 없는 것인가 계약은 정녕 그런것인가

지금 상황은 다른 부모 한테 자식이 몰매 맞고 있는데 부모는 그저 방치 하는거다.

공정 무역이라는것도 있는데, 공정계약 할 수 없나? 우리나라에서는 정녕..

고객과 100개의 기능을 3달 기간을 예상하고 계약을 했다. 근데 고객은 500개의 기능을 요구 한다. 기간은 3달이다 이거 괜찮은 계약인가?

커피 가게에서 커피 한잔 값을 내고 3000천원을 건낸 손님이 커피 2잔요구하고 3잔을 요구하면 쫒아 내야된다.

우리가 이게 커피를 만들어 달라는 건지 커피 공장을 지어 달라는 건지 구분을 못했을지도..

자바 프로젝트는 갑질하는 대상을 너무 많이 만난다… 진행을하먄서 업무량 가늠을 전혀 하고 있디 못하다 .. 이정도 기능에 얼마 정도 걸릴거라고 우리가 예상하고 추가기능이던 수정사항이던 일정파악을 해야하는데 그냥 해달라고 하면 무조건 받는다

이정도 프로젝트는 처음인가?

정말 힘든건 관리자가 아직도 우리 업무가 어느정도 되었고 어느정도 안되었는지 파악도 못하는거다.

정말 체계적으로 업무량 업무진행사항을 파악하지 않을 거면 이정도 프로젝트는 그냥 진행안하는게 좋다

관리자가 무조건 언제까지 되요 언제까지되요 언제까지 된데요 라고 이야기 할게 아니라 관리자가 이정도까지 됬으니 이정도까지 할수 있겠다 라고 막바지에 체크할게 아니라 개발 돌입 시작 부터 체크 할 수 있어야 된다.

입사 초기에 기획서를 봤을때 이게 이일정에 가능한 분량인가라는데에 의문이들었다. 근대 그때는 데이터 마이그레이션 할지도 몰랐고, 알림도 몰랐고, 1대1 채팅기능 까지 있을지 생각도 못했다. 이런 굵직굵직한거를 더 해야한다고 하면서도 일정은 바뀌지 않는다. 다지인 컨펌을 문제로 일정이 1-2주인가 미뤄지기는 했다고는 하나 중간에 프로젝트 참여개발자가 퇴사가 2명이다. 그이외에 부서내에 개발자 퇴사가 더있지만, 가용자원이 없는거다. 그냥 무조건 오픈 해야된다고 그러네

이런이런 일정 어렵울것 같다고 이야기 드려도 소용이 없다. 해야된다. 라고만 한다. 그러면 자원을 더 투입 해야된다 왜 안되는지 함께 알아보려고 해야한다.

간트차트처럼 일정을 세세하게 관리 해야한다.

이정도 양이면 기획이 적어도 3개월전에 확정짓고 열심히 퍼블리싱과 개발을 달려야 한다. 우리가그랬나? 한달도 안남았는데 기획이 바뀌고 그러지 않았나?

한달도 안남은 상황에서 개발 요구사항을 받으러 다니는건 좀 이상하지 않나..

사람을 투입 해야할지 말아야할지 모르는 건 우리가 얼마나 할수 있을지 모르는거다 그것도 문제다.

진척상황을 물을 게 아니라 기능 내지 페이지 리스트를 리스팅하고 어느 까지 되었는지 확인 해야하지 않을지…

예측 실패 세부 계획이 없음 예측 실패는 3개 사이트 4-5년 운영한 사이트의 요구사항을 적게 보았음 세부계획이 없는 채로 계속 요구사항 받기 바빴음

솔직히 개발기간 재대로 잡으면 6-7개월 짜리 인데 이렇게 하면 정당한 댓가 없이 대기업만 배불리는 꼴이다.

업무 효율을 늘리려면 야근을 없애야한다. 야근을 원천적으로 금지해야한다. 야근이 있다고 당연히 생각하고, 프로젝트가 막바지에 미친듯 야근하는게 당연하다고 생각하는것부터 없애야한다. 학생들이 벼락 치기를 하는 이유는 관리를 안해서이다. 벼락치기가 늘 일상이니깐 야근을 없애야 업무량을 적극적으로 관리하고 프로젝트 크기를 가늠할 것이다. 야근이 늘 일상적으로 있으니깐 업무량 파악을 안하는 것이다. 프로젝트가 사장님 보고가 코앞이라는데 누구하나 전체 프로젝트가 얼마나 안되있고 얼마나되어 있는지 모른다. 업무량을 파악 하지 않는 습관은 야근이 일상이기 때문이다 라고 생각합니다.

긍정과 부정의 가치는 똑같다. 긍정은 어떠한 행동에 대한 추진력을 주고, 부정은 여러가지 사안에 대해 안정감을 준다.

잘은 모르지만 .. 라이나 프로젝트는 프로젝트 수주때 부터 진행 그리고 현재 까지 너무 긍정 일변도 였다고 생각한다. 프로젝트 수주때에도 우리는 이 사안을 잘 할 수 있을 꺼야 라는 긍정적인 태도만이 아닌 이 프로젝트를 과연할 수 있을까라는 생각으로 면밀하게 검토했었어야한다. 3개 사이트 4-5년동안 운영업체를 개별적으로 끼고 있던 사이트들이 갖추어진 기능들이 적을리 없다. 그 3개 사이트들이 하나로 통합한다? 요구사항이 적을리 없다. 애초에 이 프로젝트를 하기로 하고 참여했던 시점부터 해야할 업무량 파악에 실패했다.

그리고 진행과정에서도 퇴사자가 속출하는 가운데, 그래도 잘할 수 있을거야라는 긍정적인 자세만을 유지했다. 구체적인 계획 없이..사장님 보고가 코앞인 시점에서 우리는 우리가 얼마나 업무를 진행했고, 얼마나 못했는지 알지도 못했다. 코앞에 닥쳐서야 프론트는 부랴부랴 미친듯 퍼블리싱을 치고 백엔드는 완성된 퍼블리싱에 데이터를 붙여나갔다. 프로젝트 시작 단계부터 중간중간에 해당 프로젝트를 성공하기 위한 지속적인 검토가 없었다. 프로젝트 진행이 실패할 지도 모르는 요소에 대해서 긍정의 파워로 무시되었다고 본다. 프로젝트를 성공적이고 안정적으로 진행하려면 지속적으로 실패할 만한 요소에 대해서 판단하고 또 판단해야 한다.

그리고 프로젝트를 성공하기 위한 세밀한 계획이 필요하다. 이 또한 존재하지 않았다. 이 정도 규모의 프로젝트는 개인적으로 최소한 3개월 전에 기획 및 디자인이 확정되고 간트차트같은것에 준하는 페이지별, 기능 테스트 계획과 일정이 내부적으로 확정되었어야된다고 본다. 그래야 3개월 내 기간에서도 추가적인 요구사항에 목표일정에 맞추어서 할 수 있는일인지 없는 일인지 판단할 수 있다. 우리는 그러한 것이 없었기에, 3개월 도 남지 않은 시점에서 기획이 확정되지 않은것이 수두룩했고, 1대1 채팅 기능까지 작지 않은 기능들이 무분별하게 추가되었다. 프로젝트에 대한 세밀한 계획 절대적으로 필요하다.

라이나 프로젝트를 실패라는 관점으로 보고 차후에는 실패를 반복하지 않아야할 것이다.

개발와 일정 협의를 할때, A개발자는 특정 한 페이지를 만든데 3일쯤 걸린다고 한다. B개발자 또한 특정 한페이지를 만드는데 3일쯤 걸린다고 한다. 근데 그러면 A와 B개발자가 각자 3일씩이니깐 일정을 3일 잡으면 될까? 각자가 실제로 3일씩 걸려서 마무리 했다고 해도, A가 만든 시스템 B가 만든 시스템을 연결해두었을때 문제가 생길 가능성이 있기때문이다. 이러한 요소가 2개를 연결하는게 아니라 2개가 되고 3개가되고 수십개를 서로 연결한다면, 문제가 생길 확률은 곱하기로 늘어난다.

개발자가 일정을 보통 나름 고민하고 버퍼를 잡아서 일정을 이야기 한다. 하지만 개발자가 버퍼를 잡아서 이야기 하지만, 개발자도 나름의 능력없는 개발자로 비춰지는걸 좋아하지않으므로 무한정 버퍼를 잡지는 않는다. 최소한만 잡는다 보통.. 이러한 상황에서 개발자가 특정페이지를 3일걸린다고 이야기했을때, 정말 아름다운 상황이 전개되어 3일만에 끝을 낼수 있겠지만, 그러지 못한 경우가 많다. 이유는 개발자가 그 페이지 작업만 하는게 아닐뿐더러, 슬랙에서 문의오면 답해야되고, 다른 프로젝트에서 오류상황을 맞딱뜨리면 대응해야되고, 그리고 업무는 병렬로 할수 있는게 있지만, 반드시 앞선 단계가 끝나야 그다음 단계를 할수 있는 일도 많다. 업무를 진행하고 싶어도 못하는 경우가 많다. …

우리 회사의 웹에이전시 파트는 빵집과 비슷하다, 근데 우리 회사는 주문받은 빵만 판다, 어느정도 정형화되어 찍어낸 빵을 고객에게 제시하는것도 필요하지 않을까

골목식당을 떠올려보자

  1. 식당은 오픈 하기전에 미리 많은 준비를 한다. 빨리 그리고 제대로 음식을 내기 위해 오픈전에 많은 준비를 한다. 우리도 그와 비슷하다. 고객의요구사항 이외에 최대한 준비물들을 갖추어놓아야한다.
  2. 골목식당을 보다보면 백종원이 늘 요구하는게 있다.자기가 감당할 수 있는 고객들을 끊어서 받고, 일단 식당안에 들어온사람들에게 최선을 다한다. 우리는 그러고 있나? 수많은 도킹건에 전전 긍긍하며, 무리하게 프로젝트를 수주하고, 외주개발자들을 부득이하게 많이 쓰고 있지는 않나?

변화는 좋으나 변화를 하다보면 본질을 잊으면 안된다. 사회혁신을 위한 단체들을 돕기 위해 슬로워크가 만들어 지지 않았나? 대기업위주의 프로젝트는 그것에 반하는 것 아닌가

이 글은 그냥 일기입니다. 좁디 좁은 저만의 관점입니다. 잘못된 정보나 잘못된 판단이 있을 수 있습니다.

  1. 오픈전 1대1 채팅 큰 작업을 미뤄달라고 부탁드렸는데, 해당 기능들은 미뤄지지 않았다. 의사소통 미스
  2. 그룹알림 작업, 그사이에 여러 수정사항 요청 건들이 있어 일주일 정도 작업이 지체 되었다, 하지만 고객에게 전달되지 않았다 주말근무를 했다. 개인적으로 부담되는 사안이라 빨리끝냇고 싶기도 했다.
  3. 웹 알림, 그룹알림작업을 끝내고 웹알림을 들어가려고 했으나, 다른 작업으로인해 라이나에 미루었다고 이야기를 들었다.그래서 신경쓰지 않고 있었다. 그러나 추가 작업 일정 논의할때 보면 9월 20일이라고 이미 픽스가 나있었다. 원래 웹알림 작업이 근무일 10일 기간을 예상하고 잡은 업무인데, 저에게는 휴가를 제외하면 5일남았다.
  4. 회원파트에 문자메세지 일정을 감안하고 있지 않았다. 다른 일정 잡혀있었는데 또 치고 들어왔다.

결론적으로 나는 이미 정해진 일정이 있는데 치고들어오거나 통보되지 않은 일정을 나의 주말시간과 야근으로 늘 감내해야하나?

3번작업의 경우 9월 20일이라고 픽스가 났는데 업무량은 픽스가 나지 않았다. 고객에게 확인해야하는 사안도 여럿 많고.. 업무량이 픽스나지 않았는데 왜 일정은 픽스 인가


  1. 프로젝트 진행시 세부계획을 가져달라.
    • 퍼블리싱할 페이지는 몇개의 페이지이며, 퍼블리싱은 페이지별로 언제끝나고, 백단의 기능 개별적으로 상세하게 언제 끝날지 계획을 가지고 있어야 한다.
    • 경험담 : 라이나 프로젝트 진행 때 라이나 사장 앞에서 보고를 해야하는 시점이 있었는데, 사장 보고 3일전인가 라이나 담당자가 미리 확인을 위해 배포해달라는 요청이 있었다. 그 때는 백엔드 쪽은 어느정도 준비가 되어 있었으나, 프론트엔드 쪽은 디자인이 한 번 엎어지면서 연기되어 거의 90퍼센트 이상 퍼블리싱이 안되어 있었으며, 당연히 백단과 연결된 기능도 붙지 않은 상태였는데, 이렇게 준비가 되어 있지 않은 상황이라는 것을 파악조차 못하고 있었다. 제발 기능 동작좀 되게 해달라는 이야기가 참 슬프고도 웃음도 나면서 화가 나는 상황이었다. 그 날 이후로 거의 한달인가 한달 반 정도 되는 기간 동안 미친듯이 퍼블리싱을 치고 화면에다가 기능 붙이고.. 새벽 2-3시에 자고 6시에 몸이 아픈채로 일어났다.
  2. 개발 진행이 20퍼센트가 되기전에 제발 기획을 마무리 지어달라.
    • 기획이 확정되지 않으면 개발을 진행할 수없다. 확정되지 않은채 개발을 진행하게되면 나중에 다시 고쳐야한다. 오픈이 가까워온 시기에 기획이 확정되거나 달라지면, 수많은 수정이 가해져야 한다.
    • 경험담 : 라이나 프로젝트가 개발 시작을 3월 중순 오픈이 7월 중순, 기획이 모두 확정된 것이(사이트 오픈시 메뉴 한정.. 오픈을 다 못해서 한달동안 계속 추가 개발을 했다.), 오픈 한달도 안남은시점, 그 사이에 미리 확정된 기능들도 기획이 고쳐지는 것도 허다했으며.. 확정되지 않은 기능들로 인해 얼추 개발했다가 다시 수정하는 것도 많았다. 라이나의 경우 안정적으로 개발하려면 모든 세부 계획이 4월 중순에는 확정됬어어야 한다고 본다.
  3. 계약서를 쓰고 오픈날짜를 확정짓기전에 기획확정을 적어도 80퍼센트로 마무리지어달라
    • 마음같아서는 기획확정을 100퍼센트로 만들어놓고 오픈날짜를 픽스시켜달라고 하고 싶지만, 고객의 사정상..그리고 고객 자신 조차도 자신이 필요한 요구사항을 파악하기 힘든다는 것도 충분히 이해한다.
    • 만약에 80퍼센트가 확정이 되지 않은채 오픈날짜를 확정짓는다면, 그에 맞추어 기획을 늘리면 안된다. 고객이 필요하다고해서, 고객에게 더 좋은 기능과 더 나은 홈페이지를 만들어 주기 위한 명목으로 페이지를 늘리고, 기능을 늘려 잡으면 개발자는 그냥 삶을 포기하란 소리다. 적절하게 기획을 오픈날짜에 맞추어 간소화해야되며 반드시 필요한 기능이라면 견적을 늘려잡고 돈을 더 받고 인력을 더 투입 해야한다.
    • 기획서 모듈이 큰 역할을 할 것이다.
    • 경험담 : 플레이댓, 큰기능 목록(기능정의서?)에 보니 대략 10~20개 정도의 큰기능만 적혀있다. 세부기획서는 거의 갖추어지지 않았다. 근데 오픈일자는 한달하고 6일 뒤 11월 6일로 픽스되어 있네? 개발능력이 부족해 2달 안주면 절대 못한다고했고, 사실상 보이콧하고 라이나 운영을 맡기로 한것이다.
  4. 계약에 없는 기능을 자꾸 추가하지말자
    • 프로젝트를 진행하다보면, 계획에 없던 것들이 자꾸 추가되어 들어오는데, 그 때마다 정말로 계약에 있는 것인가 하는 의구심이든다.
    • 경험담 : 라이나프로젝트 시에.. 1대1 나눔거래 메뉴에, 오픈 두달도 안남은 시점에서 거래자들끼리 채팅을 넣어야 한단다..안된다고 뻐팅겼다.. 현재 채팅기능이 개발은 되어 있지만, 일반적으로 채팅 구현은 웹소켓 통신을 이용해야하는데, 사실상 작업이 너무 커져서 일정시간마다 리로드 하는 방식으로 대체했다. 거기다가 읽음 확인 기능.. 채팅 삭제 기능.. 카카오톡이 아니자나요 음..여튼 이 사례가 정말로 계약서에 썻던 내용인지 의구심이 들었던 사례다.
  5. 단가가싼 프로젝트를 수주하고 개발을 진행했다면, 자바의 경우 운영을 맡아서 여유있게 본전을 뽑아야한다. 싸게하는 프로젝트는 보통 운영을 맡는 것을 전제로 수주한다.

  6. 소셜임팩트때 서로간의 업무 약속 중에 일정을 미리 공유하기가 있는데 공유해도 고객에 해야한다면 해야한다. 주말까지 일을 하는데 더 해야한다
    • 프로젝트에 주도적으로 참여하며, 스스로 정한 일정은 지킨다. - 스스로 정하지만 고객이 필요하다고 하면 의미가 없어진다.
    • 문제가 발생할 가능성이 있거나 일정 변경이 필요한 경우 미리 공유한다. 공유를 하지만 고객이 필요하다고 하면 의미가 없어진다.
  7. 순서가 완전 잘못되었다. 회원이 가장 먼저 정리 되어야 나중에 테스트도 편하고 진행이 편해지는데 회원이 가장 마지막에 정리되고 있다.

  8. 자바 프로젝트는 갑질하는 대상을 너무 많이 만난다…대기업, 공공기관 진행을하면서 업무량 가늠을 전혀 하고 있디 못하다 .. 이정도 기능에 얼마 정도 걸릴거라고 우리가 예상하고 추가기능이던 수정사항이던 일정파악을 해야하는데 그냥 해달라고 하면 무조건 받는다

  9. 일기 - 업무 효율을 늘리려면 야근을 없애야한다. 야근을 원천적으로 금지해야한다. 야근이 있다고 당연히 생각하고, 프로젝트가 막바지에 미친듯 야근하는게 당연하다고 생각하는것부터 없애야한다. 학생들이 벼락 치기를 하는 이유는 관리를 안해서이다. 벼락치기가 늘 일상이니깐 야근을 없애야 업무량을 적극적으로 관리하고 프로젝트 크기를 가늠할 것이다. 야근이 늘 일상적으로 있으니깐 업무량 파악을 안하는 것이다. 프로젝트가 사장님 보고가 코앞이라는데 누구하나 전체 프로젝트가 얼마나 안되있고 얼마나되어 있는지 모른다. 업무량을 파악 하지 않는 습관은 야근이 일상이기 때문이다 라고 생각합니다.

  10. 일기 - 긍정과 부정의 가치는 똑같다. 긍정은 어떠한 행동에 대한 추진력을 주고, 부정은 여러가지 사안에 대해 안정감을 준다.

잘은 모르지만 .. 라이나 프로젝트는 프로젝트 수주때 부터 진행 그리고 현재 까지 너무 긍정 일변도 였다고 생각한다. 프로젝트 수주때에도 우리는 이 사안을 잘 할 수 있을 꺼야 라는 긍정적인 태도만이 아닌 이 프로젝트를 과연할 수 있을까라는 생각으로 면밀하게 검토했었어야한다. 3개 사이트 4-5년동안 운영업체를 개별적으로 끼고 있던 사이트들이 갖추어진 기능들이 적을리 없다. 그 3개 사이트들이 하나로 통합한다? 요구사항이 적을리 없다. 애초에 이 프로젝트를 하기로 하고 참여했던 시점부터 해야할 업무량 파악에 실패했다.

그리고 진행과정에서도 퇴사자가 속출하는 가운데, 그래도 잘할 수 있을거야라는 긍정적인 자세만을 유지했다. 구체적인 계획 없이..사장님 보고가 코앞인 시점에서 우리는 우리가 얼마나 업무를 진행했고, 얼마나 못했는지 알지도 못했다. 코앞에 닥쳐서야 프론트는 부랴부랴 미친듯 퍼블리싱을 치고 백엔드는 완성된 퍼블리싱에 데이터를 붙여나갔다. 프로젝트 시작 단계부터 중간중간에 해당 프로젝트를 성공하기 위한 지속적인 검토가 없었다. 프로젝트 진행이 실패할 지도 모르는 요소에 대해서 긍정의 파워로 무시되었다고 본다. 프로젝트를 성공적이고 안정적으로 진행하려면 지속적으로 실패할 만한 요소에 대해서 판단하고 또 판단해야 한다.

그리고 프로젝트를 성공하기 위한 세밀한 계획이 필요하다. 이 또한 존재하지 않았다. 이 정도 규모의 프로젝트는 개인적으로 최소한 3개월 전에 기획 및 디자인이 확정되고 간트차트같은것에 준하는 페이지별, 기능 테스트 계획과 일정이 내부적으로 확정되었어야된다고 본다. 그래야 3개월 내 기간에서도 추가적인 요구사항에 목표일정에 맞추어서 할 수 있는일인지 없는 일인지 판단할 수 있다. 우리는 그러한 것이 없었기에, 3개월 도 남지 않은 시점에서 기획이 확정되지 않은것이 수두룩했고, 1대1 채팅 기능까지 작지 않은 기능들이 무분별하게 추가되었다. 프로젝트에 대한 세밀한 계획 절대적으로 필요하다.

라이나 프로젝트를 실패라는 관점으로 보고 차후에는 실패를 반복하지 않아야할 것이다.

개발와 일정 협의를 할때, A개발자는 특정 한 페이지를 만든데 3일쯤 걸린다고 한다. B개발자 또한 특정 한페이지를 만드는데 3일쯤 걸린다고 한다. 근데 그러면 A와 B개발자가 각자 3일씩이니깐 일정을 3일 잡으면 될까? 각자가 실제로 3일씩 걸려서 마무리 했다고 해도, A가 만든 시스템 B가 만든 시스템을 연결해두었을때 문제가 생길 가능성이 있기때문이다. 이러한 요소가 2개를 연결하는게 아니라 2개가 되고 3개가되고 수십개를 서로 연결한다면, 문제가 생길 확률은 곱하기로 늘어난다.

개발자가 일정을 보통 나름 고민하고 버퍼를 잡아서 일정을 이야기 한다. 하지만 개발자가 버퍼를 잡아서 이야기 하지만, 개발자도 나름의 능력없는 개발자로 비춰지는걸 좋아하지않으므로 무한정 버퍼를 잡지는 않는다. 최소한만 잡는다 보통.. 이러한 상황에서 개발자가 특정페이지를 3일걸린다고 이야기했을때, 정말 아름다운 상황이 전개되어 3일만에 끝을 낼수 있겠지만, 그러지 못한 경우가 많다. 이유는 개발자가 그 페이지 작업만 하는게 아닐뿐더러, 슬랙에서 문의오면 답해야되고, 다른 프로젝트에서 오류상황을 맞딱뜨리면 대응해야되고, 그리고 업무는 병렬로 할수 있는게 있지만, 반드시 앞선 단계가 끝나야 그다음 단계를 할수 있는 일도 많다. 업무를 진행하고 싶어도 못하는 경우가 많다.

긍정과 부정의 이야기 긍정 일변도인 사람은 개인적으로 동료에게 죄를 짓고, 사회에게 죄를 짓는 거라고 생각한다. 어떠한 문제가 생겨도 어떠한 불합리함이 생겨도 나만 행복하면되

  1. 일기 - 우리 회사의 웹에이전시 파트는 빵집과 비슷하다, 근데 우리 회사는 주문받은 빵만 판다, 어느정도 정형화되어 찍어낸 빵을 고객에게 제시하는것도 필요하지 않을까

    골목식당을 떠올려보자

    1. 식당은 오픈 하기전에 미리 많은 준비를 한다. 빨리 그리고 제대로 음식을 내기 위해 오픈전에 많은 준비를 한다. 우리도 그와 비슷하다. 고객의요구사항 이외에 최대한 준비물들을 갖추어놓아야한다.
    2. 골목식당을 보다보면 백종원이 늘 요구하는게 있다.자기가 감당할 수 있는 고객들을 끊어서 받고, 일단 식당안에 들어온사람들에게 최선을 다한다. 우리는 그러고 있나? 수많은 도킹건에 전전 긍긍하며, 무리하게 프로젝트를 수주하고, 외주개발자들을 부득이하게 많이 쓰고 있지는 않나?

    변화는 좋으나 변화를 하다보면 본질을 잊으면 안된다. 사회혁신을 위한 단체들을 돕기 위해 슬로워크가 만들어 지지 않았나? 대기업위주의 프로젝트는 그것에 반하는 것 아닌가

    이 글은 그냥 일기입니다. 좁디 좁은 저만의 관점입니다. 잘못된 정보나 잘못된 판단이 있을 수 있습니다.

  2. 오픈전 1대1 채팅 큰 작업을 미뤄달라고 부탁드렸는데, 해당 기능들은 미뤄지지 않았다. 의사소통 미스
  3. 결론적으로 나는 이미 정해진 일정이 있는데 치고들어오거나 통보되지 않은 일정을 나의 주말시간과 야근으로 늘 감내해야하나?
  4. 고객말은 진리다? 리더 채널 어디선가 시스님이 어딘가 항공사 CF에서 스튜어디스가 고객에게 친절하게 하는 모습을 보고 디지털 전신인 소셜임팩트 사업부가 생각났다고 하는 그런 이야기를 보았다.

낙관주의와 비관주의에 대한 담론

저는 비관주의자에 가깝습니다. 여행을 간다고 했을때 여행이 즐거울 것 보다는 여행에서 생길 문제들을 걱정하죠, 새로운 일을 할 때도 늘 걱정이 앞서며, 걱정가불하는 경향도 있습니다. 정말 재미없는 사람이죠, 저는 광진님께서 인용해주신 시몬페레스의 글을 보고 사실 역겹다고 생각했습니다.