제 경험에 국한된 얘기지만..
"보고서 제출해주세요."
"PT 준비 해주세요"
"개발계획 작성해주세요" 또는 "설계서 작성해주세요"
이런 요구하면
경력 5년차건 10년차건 거의 모든 개발자들이 엄청 당황해 하고..
심지어 울먹거리면서 일하기 힘들어 하는데... 도대체 왜 이럴까요?
업무라는게 코딩만 해서 해결되는게 아닌데 왜 .... ;;;;; 하;;;;
(하긴해도 문서작성 개판인 경우가 많기도 하고..)
개발자들은 왜 문서작업을 싫어 할까요? 112
SIGNATURE
크롬확장앱 쿠키스트림 https://chrome.google.com/webstore/detail/cookystream-manager/ffgaiddifghkcdkhjmgmmlgmdplnemfo?hl=ko&authuser=0 크롬확장앱 쿠키탭 https://chrome.google.com/webstore/detail/%EC%BF%A0%ED%82%A4%ED%83%AD%EA%B4%80%EB%A6%AC%EC%9E%90/ghgecjpngbcgilomnmakjpflpommdbmm?hl=ko&authuser=0 블로그 https://scv-life.tistory.com/
그거 다 고려해도 싫어라 합니다.
문서 작성시간도 업무시간으로 다 쳐줘도 그래요
업무라는게 좋은 일만 할 수 없잖아요.
자기가 원하는 것만 하는 것도 말이 안되죠.
문제는 귀찮은건 어쩔수 없죠 ㅋㅋㅋ 좋아서 하긴 힘들기도 하고 ㅎㅎㅎ
말꼬리는 삼가하시죠..
위 댓글에 대한 글인데... 이런식의 공격은 무슨 의미가 있는건지 모르겠네요
기분이 상하고 말게 아니라..
아무 쓸잘데기 없는 말꼬리 잡기는
글의 본질을 바꿔버리기도 하고 주제를 바꿔버리기도 하죠
저도 머릿속에선 할말이 한가득인데 막상 키보드 앞에 앉으면 진도가 참 안나가더군요 ㅋㅋ
아뇨 그렇지 않습니다. (제경험이지만..)
문서 작성 잘하는 개발자는 오히려 더 잘해요.
그래서 다들 개발PM 하는거지만요
문서작업을 개발자 업무시간으로 쳐주지도 않으면서 시키기도 합니다..
그럼 개발은 일정맞춰 다 해야되고 밤새가면서 문서도 써야하고..
안 그런곳이면 빨리 현실을 인정하고 열심히 문서작업 해야죠..
개발업무가 코딩만 하지 않잖아요.
심지어 커밋 메시지도 개판으로 쓰는데;;;
요즘 학을 뗍니다.
개발에도 방해가 되기때문이죠..(문서로써 나중에 나오는 부작용도 상당;;;)
괜히 테크니컬라이팅 하는 사람을 따로 붙혀주는게 아니기도.. 하지요..
그럼 누가 작성해야할까 싶네요.
문서 없는 회사가 있는지도 궁금합니다.
저희는 개발 관련 문서는 전무합니다.
알아보기 쉬운 코드 / 커밋 로그로 해결되지 않는 일은 외부 솔루션 문제 외엔 없었습니다. 근데 그건 또 그쪽이 작성해야 할 문서니 문서작성은 전혀 하지 않습니다.
꼭 갑사에 보고해야 하는 일이 있는 SI가 아니고서야 문서작성이 개발 영역에서 필요한 것 같진 않습니다.
흔히 말하는 '애자일 조직' 이기 때문인 것 같기도 하네요.
개발자간 의사소통은 어떻게 하셨는지 궁금하네요
API 문서, ERD 등은 필수 일텐데요.
요즘은 특히 MSA 구조로 잡아가는 상황에서
서로 문서로 얘기하지 않으면 개발 다시하는 경우가 대부분인데 말이죠
API문서는 자연스럽게 필요 없습니다. 그걸 자동으로 추출해 주는 툴들이 많으니까요.
Swagger 나 Spring REST Docs 같은 것을 사용합니다.
추출 후에도 굳이 '문서'의 형태로 보진 않고, Swagger 의 경우 그대로 import 할 수 있는 Rest Client를 이용해 직접 호출해 가며 파악합니다.
ERD도 굳이 문서가 필요하진 않습니다.
굉장히 특별한 DB를 쓰지 않는 한 DB 자체에서 ERD 추출해주는 툴이 많으니까요.
대부분의 프로젝트에서 '설계' 는 단독설계가 많지 협업 설계는 어불성설이기 때문에 (DB의 경우)가장 능력있거나 할 수 있는 사람이 도맡아 설계, 그 후에 DB 자체를 가지고 파악합니다.
DB 외적 설계도
'각자 자리에서 할 수 있는 최선을 다 하고'
연결고리에 대해서는 정해진 룰을 따릅니다.
이 룰에 대한 관련 위키가 있긴 하네요. 하지만 이것도 절대 명제에 가깝고 고쳐야 할 때는 회의를 통해 상호 협의하에 회의현장에서 즉시 바꾸기 때문에, 이 또한 '문서 작성' 과는 거리가 멉니다.
굳이 따지자면 위키 최초 작성자가 유일한 문서 작성자였긴 했겠군요.
올바른 MSA라면 특정 MS가 순식간에 뚝 떨어져 나가도 나머지 기능에 지장이 없어야 합니다. 그런 식으로 작업합니다. 하나의 MS가 하나의 프로젝트가 되는 것을 지향하기 때문에, 별도의 설계 과정은 없습니다.
의견 감사 합니다.
사실 sweager 같은 자동 툴을 생각못하고 얘기드렸네요.;
진정한 MSA구조로 가면 개별적으로 동작해야 하는 것도 사실이긴 하죠.
소설을 쓰라는게 아니라서
사실 미사여구 같은 것은 필요 없습니다.
시스템 아키텍처 설계서 만들어 오라는 것도 힘들어하는데요..
미사여구는 필요없고요. 그걸 왜 만들었는지 앞뒤 사정과 히스토리 파악이라도 되면 좋겠습니다.
아무 문서도 코멘트도 없는 스파게티 코드 분석해야 하는 후임자 입장에서는 너무 힘드네요.
개발에 들어가면..가장 먼저 하는게 문서작업이었습니다..
클래스, 함수, 변수, 리턴값 등등 개발에 관련한 문서를 1차로 만들어 관련된 파트에 넘기고..
그 다음 부터 코딩을 시작하더라구요..
와!! 처음엔 미쳤네..했었지만.. 결국엔..필요한 일이었습니다..
변경 수정이 필요하면 문서를 수정하고 코딩을 하는..
//
그때 저도 제대로 배웠어야 했는데 말이죠..
최대한 저도 그렇게 체계적으로 일을 가르키려고 하는데..
하질 않으니 방법이 없네요..ㅠㅠ
문서화가 중요합니다.. 연차가 쌓이면..자연스럽게 깨닫게 될겁니다.
근데 모듈 설계도 안한 상태에서 코딩부터 들어가는 방식은.. 별로 추천하고 싶지는 않습니다.
내가 이렇게 코딩했다..를 문서화 한것과..
내가 이렇게 해야지 라고 문서화 한 이후에 코딩한 것과는 결과물 자체가 같을 수는 없겠죠..
라고 개인적으로 생각합니다.
막상 개발시간은 안 주는 경우 많습니다
영업이나 경영쪽에서는 회의에서 일정만 쪼면
개발 그까이꺼 대충 그냥 아는거 꺼내기만 하면 금방 되는 줄 알거든요
제대로 된 개발을 하려면 아래 사항들이 충족이 되어야합니다
0. 깔끔하게 정의된 업무 프로세스
1. 요구사항의 구체화
2. 1번에 따른 개발 명세
3. 예상되는 여러가지 조건( 벨리데이션 등)
4. 단위 테스트 시나리오 개요
통합테스트는 pl 이나 pm 등 그 위쪽에서
그동안 개발해왔던 분들은
저런거 없이 그냥 닥치는 대로 해서..
해달라고 하면 당황하는거죠
연습도 안되어있구요
이런 문화와 환경을 만들어줘도 안한다는게 문제 아닐까 싶긴 하거든요..ㅠㅠ
스스로 하면 좋은 데 불이익을 받아야 움직인다면,
사람 탓보다는 불이익을 주는 정책이 없는 탓을 하고 사장님께 정책을 정하자고 하세요.
대부분의 경우 사람 탓만큼 부질 없고 무 의미하는 논의는 없습니다.
회사가 클려면 시스템을 만들어야 합니다. 사람에 기대면 회사의 미래가 없어요.
기댈 수 있는 시스템 급 좋은 사람은 극히 드뭅니다.
커밋할떄도 간단한 10글자 미만으로 기재하고 하라고해도 안하고 하는 XX들 널렸습니다.
매번 전화해도 안바뀌니..매번 해야죠..전화를..ㅠㅠ;
제가 커밋 메시지 가지고 광분할때 많긴 한데..
저만 그런게 아니군요;;
워터폴 조직의 좋은 사례를 말씀해주셨고, 이는 애자일에서 지양하는 길이기도 합니다.
애자일에서도 기본 설계내용은 들어갑니다.
개발자간 커뮤니케이션 문서 필수 입니다.
https://bcho.tistory.com/992
잘 읽어보았습니다. 근데 결국 본문의 출처인 그 '외국 분' 의 생각은, 애자일을 해봤더니 내가 볼 때 이런 게 부족하더라, 이렇게 보완하자, 라는 내용에 가까운 듯 합니다.
세상 많은 조직과 상황에 애자일이 반드시 정답일 수는 없겠으나, 애자일 추구하는 가치 중 하나는
'포괄적인 문서보다 작동하는 소프트웨어를 가지고 커뮤니케이션하자' 라는 것입니다.
(민법 공부하던 시절 교수님 말씀이 떠오르네요. '원칙이 있으면 예외가 있는거다. 근데 그렇다고 예외가 더 중요한 건 아니고 원칙이 가장 중요하다')
혹여 피치 못할 상황에 '문서'가 필요해도 '문서 작성'의 과정을 거치지 않는 것이 중요하다고 생각합니다.
문서라는 것이 이미 오랜 세월 숙련된 사람이 아니면 작성 그 자체에 어려움을 느끼기 때문이죠.
현대 사회에는 이런 것들을 도와주는 많은 툴들이 있고, '문서 작성을 해라' 라는 지시에 어려움을 느끼는 사람에게는 '이런 툴을 적용해봐라' 라고 하면 아주 흥미롭게 진행할 것 같습니다.
의견 감사합니다.
맞죠. 요구사항이 정리가 되지 않으면 다 만들어 놓고 고객이 이거 아니다 라고 하면 멘붕이에요.
명세서가 있으면 좋겠지만 1번과 4번만이라도 있다면 개발 품질이 확 올라갑니다.
컨플런스 사용중입니다.
누구나 할 수 있는 일이지만 안하던 업무를 갑자기 맡기면 잠시 막막하고 스트레스가 심합니다.
그걸 이해 못하고 계속 시키다 보면 어느순간 남는 사람이 별로 없는거죠;;
PT잘하는 개발자는 흠... 제 경우는 개발을 이해만 하는 기획자의 느낌이 듭니다. ㅋㅋㅋ
개발계획이나 설계서는 상세사양 쪽 (개발자가 필요한) 으로만 작성 요구하면 깔끔하게 잘 해줄겁니다.
고객이 필요로 하는 설명이나 이쁘게, 남들이 이해를 잘하게.. 뭐 이런식으로 요구하면 머리싸매고 기피하죠
그쵸.. 맞습니다.
하지만 누군가는 해야하는 것이 회사업무죠;;;
그 "누군가" 가 왜 개발자 인건 지는 모르겠네요.
말씀 들어보면 뭔가 조직에 체계가 없고 과도하게 개발자를 혹사 시키나 하는 의구심이 듭니다.
위에서 읽을 수 있는 형태로 . 보고서로 만들어야 하니. . 그게 참 시간이 걸리는 일이죠.
어렵기도 합니다.
그래서, 관리자 커리어로 바뀐 지금은, 반대로 개발자들의 언어/세계를 이해하도록 문과들한테 공부하라고 합니다.
서로 이해가 필요합니다.
1년후의 내가 읽을 거다 라는 생각으로 저는 쓰고 있습니다. 대체 이 코드를 왜 넣었는지 이 기능이 왜 필요했었던 건지 그런게 파악이 되기만 하면 됩니다.
근근이 문제 해결하고 끙끙 대면서 스케줄 맞추는 사람들은 확고한 미래 계획같은거 절대 못세우고
지금 시점에서 작성한 문서 몇일 뒤 되면 다 의미 상실해버립니다...
진짜 흘러가는 상황에 맞는 계획과 문서 유지하려면 매일매일 그것만 하다가 하루가 끝 나버리죠...
"왜 우리 직원들은 존나 잘난 사람이 아니지??" 오히려 반대의 생각을 가지고
체계적으로 일을 진행하고 가르치려고 하는겁니다.
그 개발프로세스 체계 없이 개발을 해 나아간다는게 말이 안되거든요.
개발자간 의사소통을 하기 위해 가장 필요한게 문서 입니다.
이를 위해 나온게 UML이기도하고요.
하지만 몸에 익히지 않으면 소용 없는거죠.
PT라는게 대단한거 아닙니다.
팀내 기술 공유를 위한 PT 였습니다.
효율을 위한 체계인데 체제 준수가 되려 비용로스를 발생시키는 요인이 되기도 하는 경우가 비일비재하죠
능통한걸 원하는게 아니라
부족해도 해보거나 참여하는걸 원하는거죠.
대상이 틀린 것 같습니다.
개발자간 의사소통을 위한 자료들입니다.
개발자분들이 시간이 없는게 그런 절차를 제대로 지키지 않아서 기록이 남지 않으니 본인 또는 다른 사람이 싸지른 X 치우는데 시간을 허비하기 때문이지요.
초반에 계획서 제대로 만들어서 기록 다 남기면 나중에 시간 단축이 얼마나 많이 되는데요 ㅎㅎ
습관이 안들어서 그렇습니다.
매우 공감합니다. 남이 짠 코드 엉망이라고 다시 짜야 한다고들 흔히 얘기하는데 문서도 없고 코멘트도 없어서 내용 파악을 사실상 할 수 없어 그런 경우가 태반입니다.
그런데 저도 15년쯤 경험에 지금껏 PPT를 만들어 (누구한테?) 설명하라는 요구는 한번도 들은적이 없네요.
그래도 요즘에는 코드 컨벤션 맞추는건 당연하고 풀리퀘가 필수인 경우가 많아서 코드리뷰는 활발하게 하는편입니다.
학교에서 훈련이 안되어 있어요
코딩과제도 문서작업까지 채점해야해요
설계 - 설계의 문서화 - 코딩 - 검증
이 기본이라고 봅니다.
프로젝트의 단위, 개발 인력의 수와 상관없이 중요하다고 봅니다.
테스트 및 검증이라는 것을 하기 위해서 이전에 설계한 내용이 참 중요하고
개발자간 의사소통을 할때도...(서로 니탓 시전할때도)
개발 문서가 근거 자료로 사용되는데
그걸 안할려고만 하니.. 답답합니다.
(1인 개발자면 필요 없지만..)
코딩하기 전에 테스트 문서를 쓰는게 진짜 품질에 엄청 도움이 되죠.
설계부터 쓰고 코딩하는게 어렵다면 코딩 중간이나 마지막 단계에서 정리차원에서라도 써보면 자체 코드리뷰 효과가 있어서 못 보던 버그도 잡게 되고요.
다 힘들다고 해도 인터페이스 문서는 진짜 꼭 써야 합니다. 누군가는 딴 소리를 하기 마련이니 증거가 있어야죠.
다른 회사는 잘 하는데 그회사만 그러면 좀 그 회사 개발자들이 좀 떨어지는거구요.
어짜피 요즘 회사에서 하는 일이라는게 혼자하는 일이 아니고 작게는 몇명 많게는 수십수백이 같이 협력해야 결과물이 나오는 이상, 서로간의 communication을 이해서라도 약속된 프로세스를 바탕으로 문서를 통해서 소통하는게 필요하죠.
그걸 이해못하고 자기가 하는 코딩 이외의 모든걸 다 쓸데없는 오버헤드라고 인식한다면 그 사람은 이정도 사이즈의 업무를 하기는 어렵다고 봐야겠지요.
매우 공감합니다. 혼자하는 프로젝트가 아닌 이상 문서는 소통수단이죠.
혼자 같은 코드를 몇년 짠다고 해도 이 고객 저 고객 상대하다가 3년전에 짠 코드 들여다보면 코드만 봐서는 내가짠 것도 뭐가뭔지 기억 안 납니다. 커밋할때 한두줄이라도 적어놓고 코멘트라도 좀 달아놔야 몇년후에 봤을 때 이해가 됩니다.
스파게티 코드 문서하나 없이 분석하다가 전임자 찾아가 물어봐도 자기가 왜 그렇게 했는지 대답도 못 하더군요. 코드 여기저기에 같은 일하는 중복 코드가 엄청 많아요. 개 답답...
예를 들어 SW구조 설계서를 달라고해서 문서양식에 맞게 작성해서 줬는데 이게 뭐냐고 다시 하라더군요.
그래서 실제 SW구조랑 완전히 다르게해서 모양만 그럴듯하게 만들어주니까 진작에 이렇게 하시지하는데 참 어이가 없더군요
2. 'PPT 문서작성'이 본연 업무가 아닌 경우 그게 부담스럽기도 하고요.
3. 대부분 개발자(다른 업종 실무자 포함)들은 그런 문서작성은 본인들의 고유업무라고 생각하지도 않고.
4. PM이나 회사나 고객이 그 문서작성 하는 시간을 따로 확보해 주지도 않는다는거죠. (확보해주는 경우엔, 보통 실무 업무기간에서 떼어서 확보해주죠..?)
5. 결국, 한정된 업무기한에 일이 두배가 되는데 좋아라 할 사람이 얼마나 있겠어요.
5.5 밤세워 눈 벌게가지고 기한내에 그 문서작업 해가지고 올라갔더니 내용은 보지도 않고 비쥬얼이나 서식이나 줄간격 오타가지고 까이면... 날라차기 마렵죠...
단 한번도 문서 작성을 해본적없네요 개발관련해서...
근데 돈을 많이 주면 할거 같습니다
회사 운영하는 입장에서 어떻게 그게 가능한 건지도 모르겠지만 어쨌건 엄청 부럽네요.
근데 최근 퇴사후 자영업 중인데 ㅜㅡㅜ 이제 요구하네요 근데 돈을 많이 주길래 군소리 없이 해주기로 했습니다
그럼 기술 이전인데 돈 많이 받으세요~
본인께서 처한 상황을 그대로 전달해주셔야 읽는 분들이 그나마 제대로 인식하는데,
본인의 머리 속에서 불필요하게 가공하거나 정제를 안하면 읽는 분들도 힘들어요.
=> 이런 화법이 최악 입니다.
어쨌건 그러지 마시고,
님이 한 명 씩 데리고 님이 그려주세요.
처음에 보여주고 나중에 숙달 되면 다 합니다.
일은 천천히 하는 거예요. 한 명씩 데리고 천천히...그리고 배운 그 한 명이 다른 한 명한테 가르쳐 주고요.
저도 밟았던 실패의 전철 사례 같은데...부디 일을 잘게 나누고 계획을 짜서 천천히 하세요.
쓰고 보니, 님이 하시고자 하는 개발 프레임웍 전파 작업에 대한 계획도 없으신 건 마찬가지 같네요. ㅎㅎ
참고로, 인생에서 잘 안되는 거의 모든 일은 항상 내가 부족해서 더라구요.
조언에 대해서는 조금 더 생각해 보겠습니다.
감사합니다.
펌웨어도 개발하고 테스트베드에 장치 설치/연동도 하고 개발 문서도 작성하고 성능인증시험도 다니고
과제 보고서도 작성합니다.
올해는 2개 과제를 마무리해야 하는데... 11월에 1개, 12월에 1개 이렇게 보고서를 제출해야 하네요. 쩝~
이렇게 다닌지 만 6년이 넘었네요.
내년 말에 와이프 사업하는데로 합칠 예정이네요.
저도 20년전쯤 사회초년생일땐 문서 작성하는게 그렇게도 싫더군요.
개발할 일정도 빠듯한데... 내 일 아닌거 하는 느낌이었습니다. ㅋ
지금은??? 해야될거 하는거죠 뭐~
일반적 업무랑 다르다는 건, 일 하거나, 이직할 때 별 도움도 안되는데 시간은 엄청 잡아먹으면서 결국 기획 담당 만큼의 퀄리티는 안나오니 한 소리나 듣는...
개발자들끼리 기술공유하는 pt 입니다.
보고pt는 팀장인 제가 하는거죠
페이지만 차지하는 문서니까요
문서다운 문서(다시 보게될 가치가 있는)를 요구했는지도 점검해야 합니다
시간 주면 어렵지는 않은데 첫문서작성시 조심해야 합니다
산으로 가는 친구들이 많아요
괜히 악보 전담 조수가 있는 게 아니죠.
뭘 해야 할지 잘 몰라요.
이런 작업을 싫어해서 많이 기분이 상하신 것 같습니다
사업의 요구사항 기획서가 완벽히 나온 상태에서
야근 안하고 개발 문서 작업할수 있는 상황이면 해주죠.
요구사헝 계속 바뀌고 추가되고 기획서는 개판이고 이러니 무슨 문서 작업 ㅋㅋㅋ
그냥 못해요..배운적이 없으니까요. 자신없어 하는거죠.
그래서 코딩처럼 문서 작성하는 방법에 대한 지속적인 교육, 연습이 필요합니다.
하지만 대다수 개발자들은 이런저런 핑계를 대며 문서 작성을 배우거나 연습하려 하지 않습니다.
상황은 이해하지만 이런 개발자들은 성장의 한계가 명확하고 남들에게 명확히 설명을 못하는 그저그런 결과물만 내놓게 되는거죠.
글쓴이의 의견에 일정부분 동의합니다.
문서 작업은 대표적으로 실리와 효율의 반대편에 있는 업무에 해당합니다. 왜냐면 문서는 대체로 “형식”을 갖추기를 요구하고 외적으로 깔끔하게 정리된것을 잘쓴문서라고 봅니다. 개발자들에게는 취약한 영역이며 그래서 점점 추세가 문서작업은 줄이고 confluence, jira 등에 무형식의 텍스트로 남기는걸로 가는거죠.
세계적으로도 개발자들이 문서 및 사무업무보다 Code와 함께하는 시간에 집중할 수 있도록 여러가지 협업도구, 문서화기록 툴 등이 나오는거구요.
그냥 음성나오는 벽을 보는 느낌 ㅎㅎ
처음에 정해진 프로젝트가 순차적으로 정상적으로 이루어졌다면 당연히 문서는 만들기 쉽죠.
요구사항과 일정이 수시로 바뀌면서 코드를 스파게티같이 작성했는데, 이를 정리하라고 말하면 정리가 될 수가 없지요. 시킨 사람 본인은 그동안 바뀐 히스토리를 정리가 가능하실까요?
제가 문서 작성할 때는 파일이름과 함수 리스트만 별도로 뽑은 다음, 그걸 참고하여 문서시킨 사람이 만족하는 형식으로 소설을 써서 넘겼습니다.
프로그램 만드는 사람 입장에선, 문서를 잘만들 사람이면 코드도 잘만들기 때문에 굳이 문서를 보지 않아도 코드만 보고도 이해가 가능하니 문서가 필요없습니다. 문서를 제대로 못만드는 사람이 만드는 건 문서를 보나 코드를 보나 어차피 이해가 안되니 쫓아가서 물어보든가 다시 짜든가 합니다.
질문의 의도가 다른사람의 의견을 듣기 위해서 인가요?
아니면 내주장이 맞다고 확인하기 위해서 인가요?
왜 싫어하고 힘들어 하는걸 이해 못하시죠?
모든 사람이 다 글쓴이와 같아야 하나요?
한말씀 드리고 싶은건 "그건 님 생각이고요!!"