신기한 연구소

안녕하세요~

오랜만에 SI 프로젝트에 투입되면서

그동안 몇 번의 SI 프로젝트 관련된 기억들을 정리해서 

SI 프로젝트에 투입되기 전 미리 확인하면 좋을 정보를 공유해봅니다.

항상 겪게 되는 문제이긴 하지만

막상 닥치면 순간 알고도 속을 수밖에 없는 상황이 있습니다.

바로 영업, PM 등 관리자들이 투입 전 하는 거짓말 1순위라고 할 수 있는데.

- "기존 시스템 그대로 옮기는 거니까 별거 없어~."

- "금방 해."

- "머리 쓸 것도 없어. 그냥 기존 로직 그대로 보고 그대로 옮기면 되니까 야근도 없을걸~"

- "새로 하는 것이 아니니 엄청 쉽지."

이 말이 사실인 경우는 거의 없다고 보면 됩니다.

가끔 맞는 경우도 있지만..

우선 정말 기존 시스템을 기대로 옮기는 경우는 거의 없습니다.

기존 시스템이 정말 완벽에 가깝게 잘 구성되어 있고

사용자 입장에서도 큰 불만도 개선 사항도 없으면

그대로 옮기기가 맞습니다.

그냥 사용하면 되는 것을 왜 옮기냐고요?

기존 장비의 노후, 기존 개발 환경이 더 이상 지원되지 않거나

새로 유행하는 언어 또는 환경이 필요해서입니다.

개발자의 유행도 한몫합니다.

지금 델파이, 파워빌더 개발자를 찾는 건 힘들거든요.

하지만 보통 사용자는 현재 시스템에 불만이 있는 경우가 많습니다.

느리거나,

기능이 부족해서 일부 수작업을 해야 하거나,

더 편한 화면이 필요하거나,

새로운 업무가 추가되었지만 시스템에 미반영되었거나 혹은

기존 시스템에 넣기엔 전반적 개선이 필요해 불가능하다는 통보를 받았다거나.

그래서 기존 시스템의 약점, 부족한 점, 그리고 더 필요한 점을 요건 정의해서

새로 구축을 하기 원합니다.

그러면 차세대로 새로 구축하면 되는데 

왜? 기존 시스템을 보완한다는 표현을 사용할까요?

당연 비용 때문입니다.

새로 차세대를 진행하려면 기간도 그에 맞게 필요하고

그만큼 인력과 비용이 필요하게 됩니다.

하지만 간단하게 기존 시스템 기반을 바탕으로

조금만 개선(? 뻥임)하는 목적으로 하자고 하면

굳이 긴 기간도 필요치 않고 적은 비용으로 진행할 수 있는 명분이 생기기 때문입니다.

하지만 실상은 거의 차세대 수준이 되고 맙니다.

결국 개발자는 빙산의 일각만 보고 투입되었다가

그 아래 거대한 얼음 덩어리를 보고 기겁하게 됩니다.

예전 같으면 야근에 주말 근무를 밥 먹듯 하면서 

불쌍한 개발자들만 고생했지만

이제는 어찌 되었건 주 52시간이라는 법의 테두리에

어느 정도 보호를 받을 수 있게 되었으니까요.

그래도 프로젝트 팀원이 되었다면

어려운 환경이라도 최대한 효율적으로 개발을 해야 합니다.

기본적인 업무 분석은 시간이 걸리더라도 해야 합니다.

업무의 바탕 없이 개발을, 옮기는 작업이라도, 한다면 내가 큰 버그가 될 수 있습니다.

개발자 간의 소통도 중요합니다.

지금 프로젝트도 서로 의사소통이 거의 없는데 (이런 곳은 처음이네요)

그러다 보니 중복 개발이 발생하고

그로 인해 시간이 비효율적으로 사용되고 있습니다.

다른 개발자가 먼저 만든 부분이

나와 같거나 비슷하면 활용해서 1시간 이내로 처리할 수 있는 것을

새로 만들면 1~2일이 걸릴 수 있기 때문이거든요.

혹시 데이터베이스의 칼럼을 그대로 사용하는지

명칭을 변경하는지도 확인해야 합니다.

그게 은근 시간이 많이 걸린답니다.

간단하게 프로그램을 만들어 사용해도 됩니다.

개인적으로 기존 시스템을 그대로 옮기는 프로젝트를 좋아하지 않습니다.

개발이라기 보단 그냥 노동? 같이 느껴지거든요.

기존 시스템을 기반으로

업무, 시스템을 분석하고

새로운 시스템을 구축한다면 재미있습니다.

하지만 업무도 모르고 내가 분석하고 설계하는 것이 아니라면

과연 개발이라 부를 수 있을까?라는 생각이 자주 드네요.

관리자의 마인드도 중요합니다.

정말 이 프로젝트를 성공적으로 운영하려는 것인지..

단순히 꼰데? 인지

관리자라면 개발자들이 일정에 맞게 프로젝트를 진행할 수 있도록

정말 하인처럼 일을 해야 합니다.

당장 필요 없는 작업을 지시해서 개발자의 업무 흐름을 깨고

일정을 방해하는 어리석은 관리자가 되면 안 됩니다.

우선순위를 잘 정해서

가장 우선해야 하는 작업에 집중할 수 있도록 하고

그다음 순위별로 작업을 할 수 있게 일정을 잘 잡아야 합니다.

복잡한 자동차 엔진을 완성하기 위해 집중하는 엔지니어에게

창문이 작다, 휠 디자인이 촌스럽다는 요구를 해서

엔진 제작의 집중도를 떨어트린다면..

어려운 환경이라면 더 효율적으로 프로젝트가 진행될 수 있도록

모두가 잘 협조해야 하겠습니다.

안녕하세요. 신기한 연구소입니다.

긴 시간 유지보수업무를 하다 보니 개발의 감이 떨여졌다고 할까요?

그렇다고 빡쎈 SI를 하고 싶지는 않지만

유지보수에서 철수한 뒤 소속된 회사에서 놀 수만 없으니

결국 SI에 투입하게 되었네요.

회사의 직급은 부장이지만 개발자로 시작해서 지금까지 개발자로 많은 시간을 보내왔고

PL급 개발자의 역할도, 작은 사이트의 PM도 경험하면서

SI 프로젝트를 좀 더 요령껏 즐기는 방법에 대해 많은 생각을 하게 되었답니다.

보통 SI 프로젝트를 생각하면 월화수목금금금과 같이 주말도 없이 근무를 하거나

매일 늦은 시간까지 야근을 하는 고통스러운 상황이 떠오를 겁니다.

필자만의 노하우가 있다고 생각은 하지만

다른 사람들은 어떻게 생각할지 모르겠네요.

그래도 SI 프로젝트에 대한 고통스러운 시간을 상상하며 투입되는 것보단

미리 준비를 한다면 잘 진행하는데 도움이 되지 않을까 싶네요.

지금 프로젝트를 진행하면서 다시금 떠오르는 생각들이 있어서

간단히 적어봅니다.

1. 담배 피우는 시간이 아까워서 끊었다.

사실 흡연은 개인의 자유이면서 기호식품입니다.

하지만 보통 근무시간에 담배를 필 수 있는 시간은 하루 1시간 휴게시간인데

보통은 아무 때나 밖에 나가서 피우고 옵니다.

그만큼 근무할 시간이 줄어들게 됩니다.

또한 정말 간단하게 담배 하나 피우고 화장실 다녀오면 좋겠지만

삼삼오오 모여서 짧게는 20-30분에서 길게는 1시간 넘게 담배 타임을 갖기도 합니다.

담배를 피우고 오면 몸은 더 피곤해지고 일의 능률도 떨어지게 됩니다.

2, 일의 우선순위 정하기.

보통 프로젝트를 하면 업무를 배정받게 되는데요.

배정을 받으면 가장 먼저 일의 우선순위를 정하고 진행해야 합니다.

분석의 시간이라고 하는데요.

분석하면서 가볍게 처리할 수 있는 부분과

난이도가 높은 부분들을 분류해서

계획을 잘 세워야 합니다.

그냥 화면 단위로 일정을 잡다 보면

너무 쉽게 끝나서 여유롭게 놀면서? 진행하다가

막판에 고난도 프로그램이 나와 고전하는 경우를 종종 봐왔거든요.

어려운 것을 빨리 찾아서 미리미리 준비를 해야 하고

SI는 진행 일정도 공유를 해야 하기 때문에

쉬운 부분을 개발해서 진도를 맞추고 어려운 부분은 짬짬이 미리 해두는 게 좋답니다.

3. 개발 중에는 중요한 부분부터 처리하자.

한참 개발하고 있는데 PM이나 품질 쪽에서 연락이 옵니다.

빠듯한 일정 맞추기도 힘든데

줄이 안 맞다거나 정렬이 하나 안맞다거나 날짜 포맷 하나 틀린 것이 있다면서

결함 처리를 해달라고 합니다.

물론 처리해야 하는 것이 맞지만

빨리 기능들이 오류 없이 잘 구현되고 나서 처리해도 늦지 않습니다.

오히려 저런 요구를 개발 중에 계속하다 보면

개발자들은 일의 흐름도 끊길 뿐만 아니라 

바빠 죽겠는데 짜증만 나겠죠?

그런 부분은 잘 취합해서 중간에 간단하게 어필한 후

기능 개발에 집중할 수 있도록 도와주고

완료된 후 요청해도 늦지 않습니다.

통합 테스트하는데 껍데기는 깔끔하게 예쁘게 잘 나왔는데

누르는 족족 오류가 나는 것보단

우선 약간 엉성해 보여도 기능들이 오류 없이 잘 처리되는 것이 더 낫답니다.

줄 좀 안 맞고 정렬 좀 틀어진 건 그리 중요한 게 아니거든요.

4. 환경에 빨리 적응하고 개발자들과 커뮤니케이션을 잘 하자.

개발자들과 커뮤니케이션은 정말 중요합니다.

그리고 선임들께 출퇴근 하면 인사는 했으면 좋겠네요.

그건 기본 예의가 아닐까 생각됩니다.

바로 옆, 앞, 뒤에 앉으면서

출퇴근할 때 인사도 안 하고...

필요할 때만 질문 정도만 하는 메마른 환경은

힘든 SI 프로젝트가 더 힘들어질 수도 있습니다.

커뮤니케이션이 필요한 이유는 정보입니다.

같거나 비슷한 부분이 있으면

공유가 되고 중복되는 일을 하지 않아도 되거든요.

세상이 아무리 개인주의가 돼간다 하지만

프로젝트는 팀을 이뤄서 진행해야 합니다.

각자의 역할도 중요하지만

서로 도와주면서 배려하는 환경에서 개발한다면

즐거운 SI 프로젝트가 되지 않을까요?