그럴수있지

퇴근하고 같이 노는 친한 개발자 - 이상적인 협업모델과 분업

2025-05-28T03:21:27Z

우리가 일하는 현장은 효율성을 위해 '분업'이라는 시스템을 채택하고 있다. 개발자는 코드를 작성하고, 기획자는 제품 방향을 제시하는 방식이다. 그러나 이러한 구분은 사실 산업화 과정에서 생겨난 인위적인 경계일 뿐이다. 근본으로 돌아가 보면, 한 사람이 아이디어를 내고 그것을 직접 구현하는 것이 가장 자연스러운 형태였다. 레오나르도 다빈치같은 르네상스 시대의

개발자도 기획과 비즈니스를 알아야 합니다 - 엔지니어가 비즈니스를 이해할 때

2025-06-12T03:27:00Z

요즘 개발자는 단순하게 코드를 잘 작성하는것으로 제 역할을 다 한다고 말하기 어려워졌다. 점점 더 복잡해지는 비즈니스 환경에서 개발자는 기술적 솔루션을 제공하는 것을 넘어 비즈니스 문제를 실제로 해결하는 역할이 요구된다. 기획서가 있다고 하라도 단순히 코드를 작성하는 능력만으로는사용자와 시장의 니즈를 충족시키는 제품을 만들기 어렵다. 개발자가 기획과 비즈니

우리 모두는 실수를 합니다 - 개발자와 기획자의 실수를 통한 성장

2025-04-29T01:57:14Z

우리 모두는 실수를 합니다 실수는 인간이라면 누구나 피할 수 없는 경험이다. 아무리 뛰어난 개발자도, 경험 많은 기획자도 실수를 한다. 완벽을 추구하는 프로젝트 환경에서 실수는 보통 부정적으로 인식되지만, 실수를 어떻게 다루느냐에 따라 단순한 오류를 넘어 시너지를 창출하는 좋은 기회가 될 수 있다. 개발자와 기획자가 서로의 실수를 이해하고 함께 극복하는

회고를 통한 시너지 만들기 - 회고 ㄴㄴ, 뒷풀이 YES

2025-04-20T12:01:39Z

개발자가 어떤 사람인지 깊이 알아보고, 기획자는 어떤 일을 해야하는지 또 자세히 알아봤다. 이제 어떻게하면 이 두 직무간의 간극을 줄이고 시너지효과를 낼수 있는지 구체적인 방법을 알아보려고 한다. 첫 번째로 알아볼 수단은 ‘회고‘다. 회고의 사전적 의미는 “지나간 일을 돌이켜 생각하는 것“ 이다. 우리가 써오던 일기가 대표적인 예가 될 수 있다. 회고는 혼

개발자의 기술적 결정 이해하기 - 어쩌면 기획자의 결정보다 영향이 클 수도 있다

2025-04-08T03:58:46Z

개발자들이 내리는 기술적 결정은 단순한 취향이나 트렌드가 아니라 복잡한 트레이드오프와 깊은 고민의 결과물이다. 기획자로서 이러한 결정 과정을 이해하는 것은 효과적인 협업을 위한 필수 요소다. 기술 결정을 이해하면 더 나은 질문을 할 수 있고, 더 실현 가능한 대안을 제시할 수 있다. 특히 개발자들의 기술 선택이 그들의 커리어에 미치는 영향과 일상적인 기술적

적절한 질문과 대안 제시하기 - 멍청한 질문도 더러 있습니다

2025-04-09T11:36:10Z

질문을 어떻게 하느냐에 따라 질문을 듣는 사람은 생각하는 방법이 달라진다. "코끼리를 생각하지 마세요."라고 질문하면 코끼리를 떠올릴 수 밖에 없다. 질문은 소위 생각의 '프레임'을 만든다. 질문하는 방법에 따라 긍정적/부정적 반응을 어느정도 유도할수 있다. 개발자의 전문 역량을 통해 프로젝트 결과물을 만드는 만큼 그들의 긍정적 태도를 이끌어내는 건 필수적

기술 토론에 참여하는 기획자 - 기획자..도..들어가야 됩니까..?

2025-05-16T10:07:41Z

나는 기획자가 안 들어가도 되는 회의는 없다고 생각한다. 그런데 일 하다 보면 기획자가 초대받지 못하거나 자연스럽게 빠지게 되는 회의들이 있다. 대부분 기술적 의사결정을 하는 회의들이다. 어떤 기술을 사용할지 정하거나 시스템 설계를 논의하는 자리가 있고 코드리뷰나 특정 버그를 어떻게 해결할지 다루는 회의도 여기 해당한다. 여기 기획자가 들어가지 않는 이유는

자주쓰는 개발용어 마스터하기 - 최대한 애자일하게 아쌉으로 해볼게요

2025-03-30T03:00:53Z

기획직군과 개발자 사이에는 언어의 장벽이 있다. 같은 한국말 쓰는데 무슨 언어의 차이가 있으련만 싶지만 같이 대화를 해보면 금새 뭔가 다르다는것을 알게 된다. 오히려 말이 잘 안통하는 모국어가 다른 프로그래머 둘이 코드를 놓고 개발자끼리 대화를 하면 은근 말이 잘 통하기도 한다. 이런일이 발생하는 이유는 직군별로 사용하는 용어들이 있기 때문이다. 업계 용어

헐.. 얼마나 더 걸리는데요?(일정지연 대처하기) - 일정지연 원인 알아보고 적절히 대처하기

2025-04-01T11:16:21Z

문제가 생기고 일정이 지연되는 일은 권장사항은 아니지만, 자주 발생한다. 예상하지 못한일이 발생하기 마련이고 의심하지 않았던 부분에서 문제도 발생한다. 일정 지연이 발생하지 않도록 계획을 세우는것 만큼 이슈가 발생했을때 적절히 대처하는것이 중요하다. 게임사에서 맡았던 프로젝트 중에 A게임이 있었다. 시장에서 잘 알려진 제작사가 개발했고 다른 플랫폼에서 이미

개발자가 맘상하지 않는 피드백 - 답답하면 직접 개발하던가?

2025-03-19T10:20:10Z

피드백의 중요성과어려움 직장생활은 매번 피드백과 개선의 연속이다. 작업내용에 대해 상사나 동료들에게 피드백을 받고 개선점을 찾아 고쳐나간다. 그러다보면 작업물은 공동의 목표에 닿아가고, 만족에 다가가게 된다. 그런데 우리의 직장생활이 짜증나고 힘든건 그 피드백이 감정을 상하게 하고, 공동의 목표에 다가가는 것 같다는 느낌을 주지 않기 때문이다. 우리는

야근없는 프로젝트일정 만들기 - 한번하면 습관, 습관이 모이면 문화가되는 야근

2025-03-15T07:11:34Z

프로그래머라는 직업이 야근이 많다는건 이제 일반상식이 되었다. 개발자 격언중에는 “The best coding happens after midnight.”(최고의 코딩은 자정 이후에 이뤄진다) 라든지 “A developer’s real work begins when the office turns silent.”(개발자의 진짜업무는 사무실이 조용해지고나서부터

몰입의 시간과 회의관리의 기술

2025-03-12T02:57:08Z

개발자의 시간은 왜 다른가? 우리는 매일 수십/수백번이나 다른사람들에게 메시지를 전달하며 지낸다. 짧은 농담이나 온라인 메신저를 통해 대화할때 보낼 텍스트는 길이가 짧고 깊이 생각할 시간이 필요하지 않다. 하지만 누군가에게 편지를 쓰거나 보고자료를 작성한다면 더 많은시간 집중해야 한다. 한창 집중하는 중에 전화가 오거나 급한 요청이 들어와 잠시 다른업무를

변경요청 관리와 스코프 조절 - Scope creep에 빠지지 않는방법

2025-03-05T12:05:47Z

왜 변경요청을 관리해야 할까? 상사의 지시를 받아 경영진을 위한 보고자료를 준비한다고 생각해보자. 중요한 보고일 경우 아침저녁으로 진행상황을 체크하곤 한다. 그런데 아침에 지시사항대로 온종일 작업한 것을 퇴근 전에 방향성을 바꿔버리면 기분이 어떨까? 그것도 좋다, 변경된 지시사항을 토대로 야근하며 작업했더니 다음날 다시 전날 아침 버전으로 방향성이 원복되

우선순위 조정과 타협점 찾기 - 항상 더 중요한게 있다는 개발자들

2025-03-01T08:18:22Z

주변에서 충분한 개발자와 기간을 가지고 프로젝트를 진행한다는 이야기는 나는 들어본 일이 없다. 항상 개발자는 부족하고, 일정은 여유가 없다. 지켜본 바로는 3-4년동안 300억이상을 들여 충분한 시간과 돈을 투자한 프로젝트도 마지막에 가서는 “리소스가 부족해서 힘들것 같아요.“라는 이야기가 심심치않게 들린다. 일하면서 습관처럼 사용하는 ‘백로그’라는 용어가

API문서 먼저 검토하기 - 기획자가 그런것도 봐야해요?

2025-02-26T04:12:50Z

왜 API문서를 먼저 봐야 할까? 볼 수 있다는 가정하에 내용을 미리 알면 나한테 이득이 되기 때문이다. 지금도 그렇지만 5년전을 생각하면 직접 API문서를 보는 기획자/PM은 매우 드물었다. Twillio 나 Stripe같은 기업이 읽기 좋은 API문서의 기준을 세운 이래로 많은 사람들이 이 분야에 공을 들이기 시작했고, 이제는 많은 기업들이 누구나 파악

개발자가 선호하는 기획서 - IA, 화면정의서, 기능정의서... 작성할게 너무많다

2025-04-16T05:17:10Z

기획자가 협업하는 동료들에게 생각을 전달하는 여러가지 방법이 있다. 찾아가서 화이트보드에 그려가며 말로 설명할수도 있고, 이메일이나 메신저를 통해 소통할 수도 있다. 그런데 보통은 다양한 제목의 문서들, ‘화면기획서‘, ‘스토리보드‘, ’기능정의서’, ‘메뉴구조도‘등의 문서를 작성해서 전달하게 된다. 각 문서는 회사별로 각각의 형식이 있다. 불필요하게 작성

기획자는 뭘 하는 사람이지? - 서비스 기획 / PM / PO

2025-03-24T21:25:47Z

사전에서 기획의 정의를 찾아보면 “일을 꾀하여 계획함”이라고 나온다. 기획자는 기획하는 사람을 칭하니 무언가 일을 꾀어내고 계획해서 달성하도록 만드는 사람이 된다. 여기서 하고자 하는 ’일‘과 이를 달성하기 위한 ’계획‘이 기획자 업무의 핵심이다. 어떤 일을 맡게 될지는 모르지만 조직이 원하는 방향을 명확히 설정하는것이 중요하다. 뜻하는 바가 무엇인지 정

애자일이 만든, 쉼없이 달리는 개발자들 - 개발 페러다임의 변화가 우리에게 준것

2025-02-15T05:18:35Z

보통의 IT기업에서 직장생활을 하는 개발자 아무개를 상상해보자. 매일 아침 눈을뜨면 스마트폰 알림을 확인한다. 혹시나 슬랙 장애방에 이슈가 올라오진 않았는지 체크하고 가슴을 쓸어내린다. 출근해서 어제 요청온 회의에 들어갔더니 ‘긴급‘하게 이번주까지 새로운 기능을 추가하라는 지시가 탑다운으로 내려왔다고 한다. 한창 업무를 진행하고 저녁에 있을 코드 배포를 준

노코드 플랫폼과 개발자의 역할 - 새로운 개발 패러다임과 그에따른 개발자의 역할 변화

2025-05-23T21:47:17Z

‘소프트웨어 개발의 민주화‘라는 말이 있다. 코드가 전혀 필요 없거나 거의 필요없는 No-code / low-code 개발 플랫폼이 등장함에 따라 특정 그룹만이 수행할 수 있었던 소프트웨어 개발을 이제 많은 사람들이 만들고 누릴 수 있게 되었다는 말이다. No-code Platform들의 소개 페이지를 가볍게 읽어보면 쉽게 내가 원하는 웹사이트나 앱 같은

원격 근무와 사내메신저 - Slack, 끝나지 않는 업무

2025-05-23T21:47:20Z

어느 정도 규모 있는 기업이라면 이제 사내 메신저 사용은 흔한 일이다. Microsoft Teams, 네이버웍스, Slack 등 유명한 업무용 메신저를 사용하지 않더라도 카카오톡이나 Telegram 등 메신저를 사용하니 메신저에서 자유로운 직장인은 거의 없을 것이다. 저녁에 친구들과 저녁 식사를 하면 메신저 알림이 오는 일은 흔하고, 꺼 둔 경우에도 습관적