프로젝트
Posted 2007. 7. 5. 14:58, Filed under: Study/Computer Science어제 우리 인턴들이 진행하는 프로젝트의 PM을 맡으신 이선임님이랑 회의를 했는데.
우리가 만들기로 했던 프로그램들을 어떻게 설계하고 역할을 나누어서 코딩을 할지, 그리고 분할된 모듈 사이에서 인터페이스나 뭐 그런걸 어떻게 할지 이야기를 했다.
학교 다닐 때 프로젝트를 하면 처음에는 함께 계획을 하지만 어느 순간부터는 조금 실력이 뛰어난 애들이 그냥 혼자 다하는 경우가 많지 않았느냐고 물어보셨는데 우리 모두가 그런 경험이 있다고 대답했다ㅋ (지난 학기 OS 프로젝트가 떠오른다..;)
그런 경우에는 보통 잘 참석안하고 코딩 실력이 부족한 사람을 일방적으로 비난하는 경우가 많은데 이것은 프로그래머의 입장에서만 생각한 거고, 프로젝트 매니저의 관점으로 본다면 처음부터 기획과 설계, 역할 분담이 잘못된 프로젝트 자체의 실패라는 것이다.
프로젝트 진행의 여러가지 면을 처음부터 고려하지 않았기 때문에 생긴 생산성 하락의 책임을 한 사람이 져서는 안된다. 애초에 충분히 이야기가 이루어져 상대방이 작성한 코드 및 자신이 작성한 코드에 대해 서로 이해하고 있다면 모두의 역량을 최대한으로 발휘하여 효율적인 진행이 가능하다는 것.
흔히 충분한 기획없이 혼자서 프로젝트를 주도하다 보면 자신만의 코드를 작성하게 되고 나중에는 다른 사람들이 코드의 이해는 커녕 프로세스의 흐름을 이해하는 것 조차도 힘들기 때문에 결국에는 손조차 대지 못하고 미안한 마음으로 구경만 하게 되는 경우가 발생하게 된다. 또한 사전 계획이 없기 때문에 프로그램은 수정이나 관리, 개선이 쉽지 않다. 무엇보다 다른 사람들이 도울 수 없다는게 결정적인 단점이 된다.
철저하게 사전에 기획하고 적절한 역할 분담을 통해 효율성을 높이고, 체계적으로 소스코드를 관리할 것!
-------
다음 학기 부터는 좀 잘해보자 ㅋ
혼자 붙들고 끙끙대면서 "내가 왜 이러고 있나, 저 자식은 뭔데 아무 것도 안하고 묻어가나" 이런 생각은 버리자.
그리고 묻어가는 존재가 되지도 말자.
내가 할 수 있는 일은 하는 것. 그리고 내가 할 수 있는 것만 하는 것.
다른 사람과 같이 프로그램을 작성하는 것 역시 중요하다.
언제까지나 혼자 붙들고 있을 수도, 묻어가기만 할 수도 없으니까 ㅋ
한 사람에게 의존도가 높으면 그만큼 리스크도 큰 법.
충분한 계획 아래 체계적으로 진행할 것.
그렇지만 막상 프로젝트 때가 되면 어찌 될지 모른다는 거 -_-;
------------
전에 이야기했던 것처럼 UI 부분과 메인은 혁민이가 짜고 재성이형과 나, 지형이가 거기에 사용하는 모듈을 작성하기로 했다.
대신에 화면에 표시한다거나 하는 UI 관련 코드에 대해서는 모두 다 이해하고 있기로.
난 디스어셈블 부분을 맡아서 구현하기로 했고, 기존에 존재하는 디스어셈블 소스를 분석하는 것부터 시작을 하기로 했다.사실, 굉장히 복잡하고 노가다성이 짙어서 별로 새로 짤 생각이 없기 때문에 기존의 간단한 오픈 소스코드를 바탕으로 코드를 이해하고 활용하는 방향으로 할 생각이다.
매일 조금씩이라도 시간을 내서 프로젝트를 진행하고 PM에게 진행상황을 알려야한다.
그리고 SVN을 통해서 소스코드를 투명하게 관리하며,
서로에게 디펜던시가 있는 코드가 거의 없으므로 나누어진 모듈 별로 작성하여 붙이는 걸로 결정-
부디 매끄럽게 잘 진행되길-
-----------
동시에 해야할 일이 여러 개가 있을 때 시간을 관리하는 것이 결코 만만치 않다.
전에 처음 입사했을 때, 한가지 시키면 하나만 계속 파고 그런 식으로 하는 것은 별로 도움이 되지 않는다고 충고를 들었었다.
자기 시간을 효율적으로 쪼개서 맡은 업무를 잘 끌고 가는 것이 진정한 능력이라고 생각한다.
우리가 만들기로 했던 프로그램들을 어떻게 설계하고 역할을 나누어서 코딩을 할지, 그리고 분할된 모듈 사이에서 인터페이스나 뭐 그런걸 어떻게 할지 이야기를 했다.
학교 다닐 때 프로젝트를 하면 처음에는 함께 계획을 하지만 어느 순간부터는 조금 실력이 뛰어난 애들이 그냥 혼자 다하는 경우가 많지 않았느냐고 물어보셨는데 우리 모두가 그런 경험이 있다고 대답했다ㅋ (지난 학기 OS 프로젝트가 떠오른다..;)
그런 경우에는 보통 잘 참석안하고 코딩 실력이 부족한 사람을 일방적으로 비난하는 경우가 많은데 이것은 프로그래머의 입장에서만 생각한 거고, 프로젝트 매니저의 관점으로 본다면 처음부터 기획과 설계, 역할 분담이 잘못된 프로젝트 자체의 실패라는 것이다.
프로젝트 진행의 여러가지 면을 처음부터 고려하지 않았기 때문에 생긴 생산성 하락의 책임을 한 사람이 져서는 안된다. 애초에 충분히 이야기가 이루어져 상대방이 작성한 코드 및 자신이 작성한 코드에 대해 서로 이해하고 있다면 모두의 역량을 최대한으로 발휘하여 효율적인 진행이 가능하다는 것.
흔히 충분한 기획없이 혼자서 프로젝트를 주도하다 보면 자신만의 코드를 작성하게 되고 나중에는 다른 사람들이 코드의 이해는 커녕 프로세스의 흐름을 이해하는 것 조차도 힘들기 때문에 결국에는 손조차 대지 못하고 미안한 마음으로 구경만 하게 되는 경우가 발생하게 된다. 또한 사전 계획이 없기 때문에 프로그램은 수정이나 관리, 개선이 쉽지 않다. 무엇보다 다른 사람들이 도울 수 없다는게 결정적인 단점이 된다.
철저하게 사전에 기획하고 적절한 역할 분담을 통해 효율성을 높이고, 체계적으로 소스코드를 관리할 것!
-------
다음 학기 부터는 좀 잘해보자 ㅋ
혼자 붙들고 끙끙대면서 "내가 왜 이러고 있나, 저 자식은 뭔데 아무 것도 안하고 묻어가나" 이런 생각은 버리자.
그리고 묻어가는 존재가 되지도 말자.
내가 할 수 있는 일은 하는 것. 그리고 내가 할 수 있는 것만 하는 것.
다른 사람과 같이 프로그램을 작성하는 것 역시 중요하다.
언제까지나 혼자 붙들고 있을 수도, 묻어가기만 할 수도 없으니까 ㅋ
한 사람에게 의존도가 높으면 그만큼 리스크도 큰 법.
충분한 계획 아래 체계적으로 진행할 것.
그렇지만 막상 프로젝트 때가 되면 어찌 될지 모른다는 거 -_-;
------------
전에 이야기했던 것처럼 UI 부분과 메인은 혁민이가 짜고 재성이형과 나, 지형이가 거기에 사용하는 모듈을 작성하기로 했다.
대신에 화면에 표시한다거나 하는 UI 관련 코드에 대해서는 모두 다 이해하고 있기로.
난 디스어셈블 부분을 맡아서 구현하기로 했고, 기존에 존재하는 디스어셈블 소스를 분석하는 것부터 시작을 하기로 했다.
매일 조금씩이라도 시간을 내서 프로젝트를 진행하고 PM에게 진행상황을 알려야한다.
그리고 SVN을 통해서 소스코드를 투명하게 관리하며,
서로에게 디펜던시가 있는 코드가 거의 없으므로 나누어진 모듈 별로 작성하여 붙이는 걸로 결정-
부디 매끄럽게 잘 진행되길-
-----------
동시에 해야할 일이 여러 개가 있을 때 시간을 관리하는 것이 결코 만만치 않다.
전에 처음 입사했을 때, 한가지 시키면 하나만 계속 파고 그런 식으로 하는 것은 별로 도움이 되지 않는다고 충고를 들었었다.
자기 시간을 효율적으로 쪼개서 맡은 업무를 잘 끌고 가는 것이 진정한 능력이라고 생각한다.