매우 빡빡한 일정으로 코딩하는 방법?


40

일정이 빡빡한 프로젝트를 진행하고 있습니다. 코딩하고 테스트 할 시간이 많지 않습니다 (매일 12 시간 이상 일하더라도 여전히 지연됨). 결과는 매우 약합니다. 코드도 매우 딜레마입니다.

이 프로그램은 많은 국가에 위치한 고객 회사의 모든 사무실에서 사용됩니다. 사용자 / 테스터의 오류 또는 일부 기능을 사용하는 방법을 모르는 오류에 대해 자정에 전화를 정기적으로받습니다.

이 프로젝트에서 3 년이 지난 후, 나는 스트레스를 많이 받고 오류와 전화 통화에 대해 매우 걱정하기 때문에 잘 수 없습니다.

몇 가지 질문이 있습니다.

  1. 3 년 동안 내가 작성한 모든 코드는 완벽한 사용 시나리오 코드입니다 (따라서 쉽게 깨짐). 제대로 설계되지 않았으며 단위 테스트가 없습니다. 이 사실 때문에 많은 문제가 있습니다. 따라서 프로젝트 일정이 빡빡 할 때 작동하는 코드를 작성하는 것이 가능한지 알고 싶습니다.
  2. 같은 시간에 더 나은 코드를 작성하려면 어떻게해야합니까?
  3. 잠을 잘 때 내 마음을 깨끗이하고 일에 대해 걱정하지 않으려면 어떻게해야합니까?

9
암시? 가장 명백한 그리고 당신은 그것을 알고 !!!
Aditya P

25
밤에는 전화기를 끄십시오. 한계를 설정하고 준수하십시오. 여기에는 두 가지 뚜렷한 문제가 있습니다. 첫 번째 문제 는 직원들에게도 생명이 있다는 것을 존중하지 않는 회사입니다.
Tim Post

34
일을 그만두고 새 것을 얻으십시오. 또한 단위 테스트를 수행하는 방법을 배우십시오
mauris

18
마감일은 경영진의 문제입니다. 마감일이 항상 그렇게 긴밀한 경우, 더 나은 견적을 제공하기 위해 노력해야합니다. 개처럼 행동 하여 생각했던 것을 충족시키지 마십시오 .
Steven Evers

4
EA 게임이 SnOrfus를 고용했다고 확신합니다.
Berin Loritsch

답변:


30

전화 금지

사용자가 전 세계에있는 경우 오전 4시에 전화를 받았을 때 전화를받을 것으로 예상 할 수는 없습니다. 전화 통화를 금지하고이 시나리오를 더 잘 수행 할 수있는 다른 통신 수단 (이메일 또는 일부 문제 추적 DB)으로 전환하려고합니다. 그러나 사무실에서도 예정된 전화 접근성 일정을 만듭니다. 그렇지 않으면 사무실에있는 동안 아무 것도 할 수 없습니다.

이것은 당신에게 소중한 수면과 휴식을 가져다 줄 것입니다.

빡빡한 일정

이 프로젝트가 3 년 동안 긴밀하게 계획된 경우, 누군가는 실제로 작동하지 않는 것을 의심해야합니다. 아마도 누군가 플래너에게 무언가, 특히 사용자 / 클라이언트와 관리자에게 이것이 죽음의 행진 프로젝트라는 것을 말해 줄 때입니다. 3 년간 개발되어 지연되고 있으며 버그로 가득합니다. 계획을 완전히 재평가하고 기존 코드를 리팩터링해야하며 수많은 문제가 해결 될 때까지 새로운 기능을 개발해서는 안됩니다.

혼돈에서 주문

상황을 예측하고 감당할 수있는 개발 방법론을 수립하십시오. 개발자 인 경우 전화가 올 때 전화를 걸면 업무를 수행 할 수 없습니다. 중단 할 때마다 15 분 정도 소요됩니다. 전화가 꺼져 있어야합니다 . 개발자이기 때문에 최소한 책상에 있어야합니다. 당신이 다른 사람에게 전화를 리디렉션 할 수 있다면 모든 호출 후에 당신을 귀찮게하지 않습니다.

일종의 인시던트 / 버그 데이터베이스를 설정하십시오. 매일 아침 시간을 내서 일을하고 새로운 사건의 우선 순위를 정하십시오 (자신, 팀 또는 고객 / 관리자). 이 우선 순위 순서대로 문제를 해결하고 전화 통화를 생각조차하지 마십시오.

만약

휴대 전화를 끌 수없고 사용자가 원할 때마다 전화를 걸 수 없다고 말할 수없는 경우 어떻게해야합니까? 사용자의 전화 번호가있는 경우 반대의 조치를 취하는 것이 좋습니다. 사용자가 전화를 걸면 알림을 보내고 해결되면 다시 전화하겠다고 알려줍니다. 자고있을 때 다시 전화하십시오. 그들이 자고 있다고 말하면 다음에 한밤중에 전화 할 때 답장을 기억하고 사용하십시오. 사람들은 보통 자신의 언어를 더 잘 이해합니다.

사무실 전화를 사용하고 휴대폰을 사용하여 근무 시간 외에는 전화를 걸 수없는 경우 사무실을 떠난 후 휴대 전화를 끄십시오. 당신은 12 시간 동안 거기에 있었고 일을 쉬어야 합니다. 휴대 전화가 개인 휴대 전화 인 경우 회사에서 새 휴대 전화를 가져와 사용자 / 클라이언트에게 알려야합니다. 고객이 나중에 개인 전화를 걸기 시작하면 (귀하의 비즈니스에서 연락을 취할 수 없기 때문에)

  1. 픽업하지 마십시오
  2. 친구에게 잘못된 번호를 알려주거나이 번호의 원래 사용자가 더 이상 사용하지 않는다는 답변을 받도록하십시오.

가장 중요한 것

기존 문제를 해결할 때까지 새로운 기능을 개발하지 마십시오. 우선 순위가 높고 중간 정도 인 것.


6
사용자에게 수동적으로 공격하지 마십시오. 회사에서 근무 외 시간에 전화를받을 것으로 예상하지 않는 경우에는 대답하지 마십시오. 근무중인 사람에게는 다른 번호가 필요합니다.
JeffO

@ Jeff O : 전적으로 동의합니다. 그러나 이것이 3 년 동안 진행된 이후로 비인간적 인 사람들의 전화에 응답 할 것으로 보인다.
Robert Koritnik

1
나는 당신이 그들 대신 선입견을 말하도록 제안 할 것입니다. 사람들이 당신을 불쾌하게 여기기 때문에 당신과 대화하고 싶지 않기 때문에 사람들이 자신의 언어를 더 잘 이해하는 것은 그리 많지 않을 것입니다.
Rei Miyasaka

3
"자고있을 때 다시 전화하십시오" "사람들은 보통 자신의 언어를 더 잘 이해합니다"좋은 말;)
Achu

2
솔직히 "만약"시나리오에 도달하면 가장 좋은 방법은 다른 곳을 찾는 것입니다. 12 시간 동안 계속해서 일하는 것은 건강에 해롭고, 통화 중일 때는 더욱 나빠집니다. 확실히, 그는 문제를 해결하기 위해 가능한 한 많은 노력을 기울여야하지만 다른 모든 것이 실패하면 그만 두어야합니다. 이 상황은 지속될 수 없습니다.
Dan Lyons

14

당신이 팀의 유일한 사람이 아니라면, 당신은 아마도 번 아웃 길을 절반 쯤 넘어서고 있다면 'pager'로 돌아가십시오. 그것은 지금 짐을 가볍게 할 것입니다.

그런 다음 경영진에게 기술 부채를 상환하기위한 단계를 계획해야한다고 주장해야합니다. 즉, 테스트, 코드 정리, 리팩토링을 의미합니다. 그리고 곧 일정을 잡아야합니다. 일반적으로 이것은 리팩토링이나 테스트가 아닌 새로운 코드 가 잠시 동안 존재 하지 않음 을 의미합니다 . 그렇지 않다면 더 나빠질 것입니다.

이 단계에서 코드베이스의 가장 번거로운 섹션을 선택하여 리팩터링하고 정리 한 후 테스트를 작성하여 똥을 테스트하십시오. 전화가 끊어 지거나 개발자가 열광하지 않고 처리 할 수있게되면 다른 단계의 기능을 사용할 수 있습니다 (원하는 경우). 이 시점에서 새 코드로 테스트를 작성하고 회귀를 계속 실행합니다. 지금은 소프트웨어가 다시 쓰기 경로에있는 것처럼 들립니다.

상사와 대화 할 때의 판매 포인트 :

  • 자동화 된 테스트는 회귀를 중지하거나 크게 줄일 수 있습니다
  • 안정성에 중점을두면 사용자가 작업 지연 / 파업이 줄어 듭니다.
  • 더 이상 자정 전화가 없으면 초과 근무 수당을 지불하지 않음
  • 더 이상 자정 전화를하지 않아도 개발자가 빨리 소모되지 않습니다.

그래도 솔직 해지자. 지금까지 회사는 이것이 무언가를하기에 충분히 큰 문제라고 생각하지 않았습니다. 당신은 화상을 입을 것입니다. 마치 경영진이 실제 개발 경험을 가진 사람은 아무도 없습니다. 보고 시작하십시오.


더 좋은 방법은, 당신을이 혼란에 빠뜨린 관리자에게 호출기를 주거나 우연히 짠 물통에 버리는 것입니다.
Stephen C

2
이 프로젝트가 3 년 동안 혼란스럽게 진행 되었다면, 기술 부서 단계가 몇 개월이 걸릴 것이라고 생각합니다. 먼저 새로운 기능 개발을 중단하고 가장 문제가 많은 문제의 20 %를 해결하고 (80 %가 거의 충돌하지 않기 때문에) 리팩토링을 시작해야합니다. 완료되면 다른 80 %를 터치 할 수 있습니다. 그러나 현재의 모든 문제가 해결 될 때까지 새로운 기능을 개발하지 마십시오. 왜? 버그를 빨리 해결할수록 해결하는 것이 더 저렴합니다. 귀하의 경우에는 더 이상 아무것도 싼 것처럼 보이지 않습니다.
Robert Koritnik

@Robert Koritnik : 물론입니다. +1
Steven Evers

13

약간의 생산성 향상을 달성 할 수있는 몇 가지 기술이있을 수 있지만 현재 5 %의 작업량 증가는 쓸모없는 것보다 나쁩니다. 여기서 놓친 실제 기술은 간단하고 기본입니다.

거절하는 법 배우기

거절해야한다는 것을 이미 알고있는 모든 비합리적인 기대에 대해서는 거절하십시오. 당신은 그들이 무엇인지 알고 있습니다. 그 정도는 분명하다. 지금 거절 할 수 없다면 할 수있는 직업을 찾으십시오. 현명한 고용주는이 기술이 바람직하다는 것을 알게 될 것입니다.


1
무엇보다도 이것은 필요한 기술입니다. 좋은 답변입니다!
Joe Z

8

아무것도 변경 되지 않으면 프로젝트가 실패 한다는 것을 이해하여 시작하십시오 . 이것은 필요한 작업을 수행하는 가장 중요한 단계입니다. 개발자는 하루에 12 시간 동안 노력할 수 없으며 유용한 코드를 생성 할 수 없습니다. 당신은 당신이 바보 같은 실수를 생성하고 당신이 매일 하루 전에했던 일을 고쳐야하기 때문에 실제로 진전을 잃는 지점에 도달합니다. 이미있는 것처럼 들립니다.

정신 건강을 다시 갖기 전에 해결해야 할 두 가지 주요 문제가 있습니다.

  • 경영진은 그들이하고있는 일 이 효과가 없다는 것을 알아야합니다 . 같은 실수를 계속 반복하면 같은 결과가 나옵니다. 뭔가 바뀌어야합니다.
  • 이미 가지고있는 것을 고칠 시간이 필요합니다. 즉, 공격 계획을 세우는 데 시간이 필요하고 8 시간의 근무일을 사용하여 공격 할 시간이 필요합니다.
  • 작업 방식을 변경해야합니다. 스트레스가 많을수록 더 많은 터널 비전이 있음을 이해하십시오. 문제를 해결하는 창의적인 방법을 생각하거나 스트레스를받을 때 문제가 발생하면 어떻게 될지 생각조차 할 수 없습니다. 말할 것도없이 심각한 건강 합병증의 가능성이 높아집니다. 스트레스 해소 방법을 찾고 스트레스 해소 방법을 찾으십시오.

상황을 해결하려면 경영진이 필요합니다. 문제는 그들이 고통을 느끼지 않는다는 것입니다. 그리고 당신은 그들의주의를 얻기 위해 뇌졸중으로 병원에 들어가기를 원하지 않습니다. 첫 단계는 경영진에게 현재 위치와 압력을 설명하는 것입니다. 그들이 얻지 못하면 다른 수준의 관리로 올라갑니다. 또는 근무 조건을 HR 부서에 설명하십시오. 하루 동안 8 시간 이상 장기간 근무하도록 요구 하는 것은 법을 위반하는 것일 수 있으며 HR 부서는이를 확실히 알고 있습니다.

경영진이 귀하의 항변을 듣는다고 가정하면 다음 조치를 취하려고합니다.

  • 출혈을 멈추십시오. 새로운 기능이 없으며 다른 사람이 서비스 요청을 처리합니다. 당면한 과제에 집중해야합니다.
  • 해결해야 할 가장 심각한 버그를 식별하고 수정하는 데 시간이 얼마나 걸리는지 알아 봅니다. 이것은 대략적인 추정치이며 숫자가 작을수록 많을수록 좋습니다. 하루 종일 회의와 중단을 설명하기 위해 경영진은 하루에 5 시간 동안 작업 한 결과를 바탕으로 견적이 필요합니다. 이로 인해 회의와 중단 시간이 3 시간 남았습니다.
  • 경영진이 이러한 중대한 버그에 대한 수정 된 일정에 동의하도록합니다.
  • 다른 사람이 당신을 위해 시험을 받도록 동의하십시오. 이것은 당신이 일을 할 수 없다는 것을 인정하지 않습니다. 이는 단순히 모든 릴리스가 이전보다 나은 품질 보증을 제공합니다.
  • 이제 고치세요. 문제를 재현하기 위해 단위 테스트를 작성하여 문제가 발생한시기를 알 수 있습니다. 더 중요한 것은 다른 곳에서 한 일이 다시 발생한 것인지 알 수 있습니다. 코드가 더 잘 작동하도록 리팩터링하십시오.

중요한 버그 수정 릴리스가 완료되면 다음 릴리스를 계획 할 차례입니다. 모든 기능과 버그 수정은 우선 순위를 정해야하며 보류중인 작업의 하위 집합을 중심으로 릴리스를 계획해야합니다. 직장 생활에 건강을 가져다 줄 때 스트레스 수준이 떨어지고 품질이 향상되며 전반적인 효율성이 높아집니다.


6

당신은 내가 거짓 경제 의 경우라고 생각하는 것으로 고통 받고있는 것처럼 보이며 , 작동하지 않는 것들에 더 오래 고수하면 문제가 더 악화됩니다.

일부 주요 지표 :

  • 비현실적인 일정 인 것 같습니다.
    • 경영진의 건전한 개발 관행에 대한 이해가 부족하다고 생각합니다.
    • 경영진의 이해 나 지원이 부족하다고 생각합니다.
  • 하루 12 시간 일.
  • 높은 수준의 스트레스.
  • 수면 부족.
  • 걱정.
  • 디자인 및 코드 품질에 대한 관심 부족
  • 단위 테스트 안전망 부족.

프로젝트 일정이 빡빡 할 때 작동하는 코드를 작성하는 것이 가능한지 알고 싶습니다.

짧은 대답은 그렇습니다. 긴 대답은 복잡하며 경영진과 고객을 대신하여 인식에 대한 큰 변화와 귀하의 노력이 필요하다는 것입니다.

같은 시간에 더 나은 코드를 작성하려면 어떻게해야합니까?

실제로는 시간을 절약하면서도 완벽한 결과를 얻을 수있는 모든 것을 할 수 있다고 가정하면 불가능합니다. 코드를 구현하는 데 걸리는 시간을 늘리는 기술을 적용해야합니다. 세부 정보를 정확하게 얻는 데 시간이 걸리기 때문입니다. 이것은 시간이 걸리고, 당신의 거짓 경제가 당신을 가장 아프게하는 곳입니다. 그러나 더 나은 방식으로 작업하면 코드의 품질이 향상되어 시스템의 취약성이 줄어 듭니다. 다시 한 번 더 설명하겠습니다.

잠을 잘 때 내 마음을 깨끗이하고 일에 대해 걱정하지 않으려면 어떻게해야합니까?

불안은 수면 부족을 유발하고, 수면을 잃으면 불안이 생깁니다. 이것이 있다면 악순환이며, 선택하지 않으면 불안의 사악한 쌍둥이 우울증으로 이어질 것 입니다. 내가 생각하기에 만성적 인 수면 상실은 운동 부족과 영양 부족으로 인해 만성 피로 가 발생할 가능성이 높다고 생각합니다 . 이 모든 것은 직장에서 직면하고있는 모든 문제와 가정 생활에서 직면 할 수있는 문제의 증상입니다. 이것은 거짓 경제의 가장 큰 증거가있는 곳이며 아마도 가장 먼저 다루어야 할 가장 심각한 문제 일 것입니다.

나는 또한 어떤 제안을 환영합니다.

나는 먼저 의료 전문가가 아니라고 진술해야하며, 어떤 행동을 취하기 전에 의사의 조언을 구해야합니다. 그러나 나는 당신이 당신의 글에서 묘사 한 경험들을 통해 살았으며, 그것이 다루기가 얼마나 어려운지, 그리고 그것에 대해 무언가를하는 것이 얼마나 중요한지를 알고 있습니다. 나는 우울증, 불안, 만성 피로, 스트레스 및 그와 함께 제공되는 다른 모든 소란을 겪었으므로 다음과 같은 경험을 바탕으로 조언을 해줄 것입니다.

  • 의사에게 가서 증상을상의하십시오. 피곤한 경우, 대부분 우울하거나 걱정되는 경우, 감기와 독감에 자주 걸리는 경우, 신체적 인 느낌이들 경우 의사에게 알리십시오. 의사가 허락되면 항 불안 또는 항우울제를 제공받을 가능성이 있습니다. 당신이 싫어하는 경우에도, 문에 자부심을두고 처방대로 그들을 가져 가라. 그들은 정말로 도움을주고, 앞으로 올 모든 것을 다룰 힘을 찾을 수있게합니다.
  • 좋은 심리학자에게 문제를 아는대로 토론하고, 문제에 대해 어떻게 생각하는지 탐구하고, 문제를 해결하기위한 전략을 개발하도록 도와 줄 수있는 사람을 찾으십시오. 당신이하도록 요청받은 것 중 일부는 무의미하거나 약간 소름 끼치는 것처럼 보일 수 있습니다. 어쨌든, 특히 마음을 깨끗하게하는 방법을 가르치는 데 도움이되기 때문에 다시 도움이됩니다.
  • 의존하지 않고 수면 문제를 악화시킬 수 있으므로 실제로 필요하지 않은 경우 수면제를 사용하지 마십시오. 개인적으로 나는 주말 후에 필요한 수면을 취할 수 없을 때만 복용하며, 보통 게으르고 충족되지 않은 주말을 보냈습니다.
  • 식단을 바꿔 보자. 카페인은 불안의 증가에 기여하기 때문에 진지하게 차단하십시오. 탄수화물을 줄이고식이 요법을 균형있게 유지하십시오. 즉, 더 많은 자연 과일과 채소를 먹고 소비하는 육류의 양을 줄이고 지방과 기름을 줄입니다. 청량 음료를 자르고 포기할 수없는 경우 하루에 커피 한 잔으로 제한하십시오. 다이어트는 피로 퇴치를 돕는 데 중요합니다. 또한, 마지막 식사를 일찍 먹어서 배가 고프지 않도록하십시오.
  • 매일 운동하십시오. 최소한 일주일에 한 번은 최소한의 운동을하고, 최소한 땀을 흘리기까지 매일 30 분 이상 걷거나 자전거를 타십시오. 이렇게하면 수면과 피로에 도움이되는 신체적으로 피곤해집니다.
  • 수면 습관을 바꾸십시오. 일찍 일어나서 일을하려고하므로, 생각보다 일찍 잠자리에 들어야합니다. 잠을 잘 수 없다면, 어두운 방에서 휴식을 취하고 지루한 것을 읽고 실제로 잠들 수 없다면 걱정하지 마십시오.

의학적으로 관련된 모든 내용을 살펴 보았으므로 작업에 대해 무엇을 할 수 있는지 살펴 보겠습니다.

  • 누군가가 Pomadoro Technique 사용을 제안했습니다. 이것은 시간 복싱이라고도하며 좋은 생각이라고 생각합니다. 기본적으로 20-25 분 동안 집중적으로 집중하면 약간의 휴식이 필요합니다. 나는 당신이 일어나서 약 3-5 분 동안 움직일 것을 제안하고, 눈을 쉬기 위해 거리를 들여다 본다. 그 시간 동안 당신의 작업에 대해 생각하지 마십시오. 음료를 마시거나 화장실로 돌아 다니거나 사무실에서 간단한 철자법으로 이동하십시오.
  • 상사와의 관계에 따라 업무 일정이 건강에 영향을 미치는 문제를 해결하고 논의 할 수있는 방법을 찾으십시오. 회사의 고객을 실망시키는 위험을 원치 않으며 계속해서 업무를 수행 할 수있는 전략을 시도하고 개발하고 싶다고 말하십시오. 당신의 건강 문제를 해결할 시간을 내십시오. 그러나 다음과 같이 여기에서 작동중인 허위 경제를 설명하는 것이 더 좋기 때문에이를 최후의 수단으로 사용하십시오.
    • 피로 노동자는 효율성이 크게 저하되는 반면, 피로가없는 근로자는 짧은 시간에 더 많은 일을 할 수있는 능력이 있으며, 나는 당신을 뒷받침하기 위해 사용할 수있는 수치와 연구를 제공하려고 노력할 것입니다. 좋은 상사라면 이것을 필요로하지 않아도됩니다. 다음 기사가 유용 할 수 있습니다. 기사 1 , 기사 2 , 기사 3
    • 약간의 세부 사항에 대한 테스트와주의를 생략하면 나중에 비용이 발생합니다. 기술 부채 개념을 출발점으로 살펴보십시오 .
  • 근무 시간을 하루 8 ~ 9 시간으로 줄이십시오.
  • 휴가 기간을 예약하고 조용한 곳으로 잠시 가십시오. 당신이하는 모든 일이 자동차를 숲으로 몰고 일주일 동안 야영하는 것입니다. 배터리를 재충전하기 위해 잠시 동안 아무것도하지 마십시오.

실제 프로그래밍 관련 사항의 관점에서 :

  • Clean Code and Refactoring 책을 읽고 시간을내어 기술을 적용하십시오. 이것들은 코드 품질 문제를 다루는 데 도움이 될 것입니다. 앞에서 언급했듯이 일이 오래 걸리는 것처럼 보이지만 이전에 일한 방식으로 인한 혼란과 문제를 처리하는 데 시간이 덜 걸립니다.
  • 코드 품질을 향상시키기 위해 개발 환경에 통합 할 수있는 도구를 찾으십시오. 예를 들어 Visual Studio에서 개발하는 경우 Resharper 및 NCrunch와 같은 도구를 사용하면 종교적으로 사용할 경우 전체 효율성을 크게 높이고 이미 언급 한 책에 설명 된대로 이미 좋은 기술을 적용 할 수 있습니다. .
  • 단위 테스트를 작성하고 테스트 우선 접근 방식을 사용하십시오. 이로 인해 속도가 가장 느려지는 것처럼 보이지만 테스트 시간이 길어지면 디버깅 시간이 단축되고 테스트 된 코드를 변경할 수 있다는 확신을 가질 수 있으므로 전반적인 개발 속도가 빨라집니다. 요구 사항을 충족하고 코드를 만족시키지 않는 테스트를 작성하십시오. 이것은 테스트 노력을 건설적으로 집중시켜 테스트에 소요되는 시간을 최소화해야합니다.

무엇보다도 가장 중요한 것은 자신부터 시작하여 기대치를 관리해야합니다. 당신은 인간 일 뿐이며 주어진 시간에 많은 일을 할 수 있습니다. 당신은 당신의 상사의 기대를 관리해야하고, 당신의 상사 나 직접적으로 고객의 기대를 관리해야합니다. 이것은 당신이하는 일을 진지하게 우선시하는 것을 의미합니다. 새로운 기능에 대한 시간과 버그에 대한 시간을 할당하고 마감일이 지났다고 가정합니다. 배송 날짜가 단축 될 가능성을 다룰 때는 중요한 기능 만 제공하고 나머지 기능은 "가능하면 좋을 것"으로 남겨 두십시오. 다음 배달 날짜, 다시이 프로세스를 진행하여 이전 배달의 "가지고있는 것"의 우선 순위 등을 증가시킵니다. 최소 시작점으로 개발 방법론에이를 구축하십시오. 프로세스를 조정하여 효율성을 향상시킬 수있는 위치를 확인하기 위해 몇 번의 배송 후에 검토합니다. 가장 큰 효율성은 라이프 스타일 변화에서 비롯 될 수 있지만 문서 작업 및 최종 사용자 간의 의사 소통과 관련된 오버 헤드를 줄이는 등 작업 효율화를 위해 항상 할 수있는 일은 거의 없습니다.

이 모든 일에 적극적으로 대처하십시오. 상사에게 문제를 개선하기 위해 함께 협력 할 수 있으며 궁극적으로 귀하와 회사 전체에 잘 반영 될 수 있음을 상사에게 보여주십시오.

또한 지금 과감한 결정을 내리지 마십시오. 건강과 업무량을 다룰 때까지 기다렸다가 어떻게 지내는지보십시오. 마음이 더 깨끗 해지고 기분이 좋아지면 기분이 더 나아질 지 결정할 시간이 될 것입니다. 내가 기본적으로 말하는 것은 한 번에 하나의 문제를 처리하고 나머지는주의를 기울일 필요가있을 때까지 조금 끓 이도록하는 것입니다.


4

일정이 빡빡하면 반복하지 말아야 합니다. 가장 많이 사용되는 방법을 식별하고 많이 재사용하도록하십시오.

오늘 작업 할 내용을 계획하고 적어두고 고수하십시오. 한 번에 기억해야 할 내용을 7 개 이하로 제한하십시오.

한 걸음 더 나아가 다른 사람들의 일을 반복하지 않을 것입니다. 가능할 때마다 언어 라이브러리를 사용하십시오. 가능하면 타사 라이브러리를 사용하십시오.

작성하는 데 시간이 더 걸리는 것처럼 보이지만 한 가지만 수행하는 메소드를 목표로합니다. 나는 결정을 내리거나 일을하는 방법을 제한합니다. 커플 링이 감소하는 동안 코드의 응집력이 증가해야합니다. 테스트가 더 쉬워야합니다. 이것은 점진적인 분해에 적합합니다.

최대한 단순화하십시오. 사소한 일에 대한 생각을 피할 수있는 템플릿, 체크리스트 및 모든 기술을 사용하십시오.

중단을 피해야합니다. 각 중단 시간은 약 15 분입니다. 당신의 시간을 보호하십시오.

이 기간이 길면 성능이 저하되기 시작하면 집으로 돌아가십시오. 12 시간 동안 지속적으로 근무하는 경우 8 시간 동안 근무할 수있는 성과에 대한 성과입니다. 성능이 얼마나 나빠지는지 알 수 없습니다. 운동을하고 휴식을 취하려면 4 시간이 더 걸립니다. 낮에 낮잠을 자거나 점심 식사 후 몇 시간을 쉬십시오.


4

내가 당신이라면, 나는 매니저와 이야기하고 그들이 설정하는 마감일이 비현실적이라고 설명합니다. 만약 당신이 그렇게 계속 일한다면, 그들은 모든 것이 잘된다고 생각할 것입니다, 그들은 당신이 겪고있는 문제를 알지 못할 것이고 매일 시스템에 더 잘 작성되지 않은 코드를 추가하게 될 것입니다. 당신의 일이 더욱 복잡해집니다.

대안으로 항상 다른 작업으로 전환 할 수 있습니다 :-)


2

당신이하는 모든 것을 추적

시간을내어 모든 일을 추적하고 귀하와 팀이 얼마나 많은 시간을 소비하는지 추적하십시오. 결과적으로 경영진에게 무엇을해야하는지 다르게 보여줄 수 있습니다. 자신이하고있는 일과 다른 사람들이보고 한 문제를 해결하는 데 얼마나 많은 시간을 소비하고 있는지에 대한 냉혹 한 사실이 없다면 변경이 필요하다는 것을 확신시키기가 훨씬 더 어려울 것입니다. 정확한 시간을 위해서는 모든 사람이 모든 시간을 추적해야합니다. 이는 지난 3 주 동안 동일한 시간에 처음부터 다시 구축 할 수있는 시스템을 수정하여 80 시간을 보냈다는 의미입니다.

사물을 바꾸려고 노력하십시오

수집 한 추적 및 다른 사람들이 소프트웨어 개선 계획을 세우기 위해 제안한 훌륭한 제안을 사용하십시오. 가장 큰 문제를 일으키는 소프트웨어 부분을 선택하십시오. 일반적인 관리 가능한 속도로 물건을 가져올 것이라고 생각되는 계획을 세우십시오. 일할 시간을 줘

떠날 시간이 될 수 있다는 사실에 대비하십시오

경영진이 사물을 바꾸고 당신과 함께 일하기를 원하지 않는다면 앞으로 나아가 야 할 때입니다. 나는 당신이 불타고 있다는 것을 다른 사람들에게 동의합니다. 이력서와 포트폴리오 준비를 시작하십시오. 상황이 개선 될 수 있으며 계속 이동할 필요는 없지만 경영진이 변경을 위해 사지 않으면 계속 진행하십시오. 당신의 정신 건강은 당신을 너무 많이 빼앗아가는 직업에 머무르는 것보다 중요합니다.


이 데이터가 경영진에게 전달 될 경우 직원이 시간을 관리하는 방식에있어 사소한 불완전 성이 매우 중요 할 수 있기 때문에 "모두 추적"부분에 동의하지 않아야합니다. 이것은 직원의 스트레스를 악화시킬 것입니다.
Acumenus 2018 년

2

신의 사랑을 위해, 프로젝트 관리자는 어디에 있습니까?

생산적인 시간을 설정하는 데 도움이되는 프로젝트 관리자가 없으면 시간이 필요합니다. 개발 시간을 고수하고 스코프 크리프를 제한하며 기대치를 관리하는 데 전념하는 사람이 필요합니다.

당신은 생계를 위해 창조적 인 일을합니다. 고객과 사용자 사이에 장벽이 없다면 어떻게 개발에 효과적으로 집중할 수 있습니까?

좋은 PM은 많은 것들에 좋을 수 있습니다 ...

1. '고전력'카드를 재생하려면 :

사용자가 새로운 기능을 사용하려고했지만 버그 수정 릴리스에 집중할 시간이 정말 필요합니다. 사용자와 대화해야한다고 누가 말했습니까? 계약서 작성은 귀하의 책임입니까? 고객의 기대치를 관리하는 것이 당신의 일입니까? 계약 조건을 지시 할 최종 결정 권한이 있습니까?

아니? 그렇다면 왜 고객과의 상호 작용에 대한 책임은 전적으로 귀하에게 있습니까? 개발은 어렵고 많은 집중력이 필요합니다. 개발 시간을 되 찾을 수있는 능력이 필요하며 좋은 PM과 좋은 변명으로 그렇게 할 수 있습니다.

고객이 PM과 비교 한 내용에 관계없이 고객이 사양 이외의 수정에 대해 귀찮게 시작하면 말입니다.

"사양 이외의 변경 사항을 협상하는 것이 급여 수준 이상입니다."

공손한 말입니다, 나는 ***를주지 않습니다.

그들에게 'Scope Creep Dog'를 아프게하여 그것을 따라 가십시오.

"사양을 변경하려면 PM과 연락해야합니다."

이제 내버려 둬 개발자와 직접 상호 작용하는 사용자의 능력은 제거 할 수있는 권한으로 허용됩니다. 그렇지 않으면 경영진이 실패한 것입니다.

2. 기대치 관리 101

올바른 생각에 누가 당신이 미친 일정을 수행 하고 연중 무휴 기술 지원을 처리 할 수 있다고 생각합니다 . 당신의 시간은 소중하고 공예에 전념해야하기 때문에 누군가 당신을 위해 일 어설 필요가 있습니다.

이는 귀하가 근무하는 회사뿐만 아니라 고객에게도 적용됩니다. 고객이 너무 밟으면 언제든지 요청할 수 있습니다 ...

"이 서비스는 계약서에 작성 되었습니까?"

그렇지 않은 경우 요청을 거부 할 권리가 있습니다. 잘못 이해하지 마십시오. 고객을 만족시키기 위해 그 이상을 넘어가는 것이 좋지만 고객에게 기대하는 것과 호의로 제공하는 것의 차이점을 알려주는 것도 중요합니다.

당신이 일하는 회사에게는 메시지를 전할 누군가가 필요합니다.

"필요한 업무가 급여 수준과 동등해야합니까?"

즉, 그들은 훨씬 낮은 지불 위치 인 전화 기술 지원을하는 데 시간의 50 %를 소비하기 위해 연간 60k를 지불하고 있습니까? 이것은 브로치하기에 위험한 주제이므로 좋은 사례를 만들려면 신뢰할 수있는 PM이 필요합니다. 당신이 그에게해야 할 주장은 ...

"연간 60K를 지급 받지만 잠재적 생산성의 절반이 정신 업무에 낭비되고 있습니다."

아니면 저를 고용하여 저학년 직책을 채우는 데 절반의 시간을 허비하게함으로써 기꺼이 그 투자에서 돈을 잃고 있습니다. 믿거 나 말거나, 잠재력을 극대화하여 장기적으로 더 많은 돈을 벌 수 있습니다.

비즈니스와 관련하여 윈윈 상황을 제시 할 수 있다면 회사의 입장을 바꾸는 것이 훨씬 쉬운 일입니다. 이 협상을 위해 협상 마스터가 될 필요는 없습니다. 물론 회사의 자원이 제한되어 있으면 역효과를 낳을 수 있습니다.

3. 모두가 때때로 치어 리더를 사용할 수 있습니다

좋은 PM은 당연히 사람들이 될 것입니다. 그들이하는 일의 핵심은 사람들 관계입니다. 좋은 PM은 고객이 듣고 싶지 않은 것을 말하고 행복하게 떠나도록 할 수 있습니다.

또한 때가 어려워 질 때 도덕적 지원의 훌륭한 원천이 될 수 있습니다. 요청하면 좋은 PM이 처리하기에 간단한 사기 부스트가 너무 많아서는 안됩니다. 당신 편에 누군가가 필요합니다. 그렇지 않으면 사기가 떨어지고 일이 압도적으로 느껴집니다.


조직에서 기대치를 관리 할 책임이있는 사람이 없으면 경영진이 실패하고 상급자가 프로젝트가 얼마나 나쁜지 알지 못할 수도 있습니다.

이것이 전염병과 같은 회사에서 일하는 것을 피하는 주된 이유입니다. 나는 누군가가 더 높은 곳을 가진 소기업을 위해 일할 수있을만큼 운이 좋았다. 나는 누가 확신을 갖고 말해야하는지에 대해 누가 정직하게 논의하고 필요한 경우 조치를 취할 수 있는지에 대해 솔직하게 이야기 할 수있다.

비즈니스 요구 사항을 준수하고 방해 요소를 관리 할 수있는 사람이 필요합니다. 당신이 그것을 가지고 있지 않고 앞으로 그것을 찾을 희망이 없다면, 행운을 빌어 ...


1

와우 와우 와우! 당신의 말 카우보이 잡아!. 당신은 모든 개발이 잘못되어있는 것 같습니다. 코딩하는 동안 일부 소프트웨어 기본 사항이 누락되었습니다. 네 기초를 닦으십시오. 인생은 훨씬 쉬워 질 것입니다.

지금 학교 시간으로 돌아 가기

  1. 빠른 개발-테이밍 소프트웨어 일정 *
  2. 신화적인 남자-월 *

* 필독


2
다음 질문-빡빡한 일정에 따라 일부 책을 읽고 코딩하는 방법 :-D
Ventsyslav Raikov

1
@Bond-친구, 우리는 프로젝트를 시작하기 전에 이미 그 책을 읽었어야합니다. 그렇지 않다면 지속적인 학습이 소프트웨어 개발의 일부라는 것을 알아야합니다. 우리는 독서가 일상 업무의 일부가 아닌 것으로 생각해서는 안됩니다. 우리는 이미 매일 한동안 독서를 했어야했다. 소프트웨어 개발자가 근무 시간 중에도 일부 시간을 읽을 권리가 있다고 생각합니다. 개인적으로 하루에 5 페이지를 읽는 것보다 큰 영향을 미치는 것을 보았습니다. 지금 읽기 시작하면 다음 프로젝트에서 시간을 절약 할 수 있습니다.
Imran Omar Bukhsh

나는 당신에게 절대적으로 동의합니다, 나는 매일 읽습니다. 그러나 나는 하루에 12 시간 (위 질문에 코드를 의미한다고 가정)을 사용하지 않습니다. 내가한다면, 나는 어떤 책도 읽지 않을 것입니다. 일보다 삶에 더 많은 것이 있습니다.
Ventsyslav Raikov

@Bond-사실, 그러나 우리가 올바른 방식으로 일하지 않으면 많은 생명이 남지 않을 것입니다. 우리 회사에서는 하루 5 시간 일합니다. 약 1.5 년 만에 크롤링 엔진을 만들었습니다. 한 달에 백만 명이 넘는 방문자가 있습니다.
Imran Omar Bukhsh

1

TODO 목록을 만들고 필요에 따라 정렬하고 무조건 무조건 순서를 고수하는 것을 좋아합니다.

다음에 무엇을해야하는지 궁금해하는 시간을 줄이면 얼마나 많은 시간을 절약 할 수 있을지 놀랄 것입니다.


1

지금 할 수있는 일은

  • 동료와 페어링
  • 작성하거나 변경하는 모든 코드는 충분히 훌륭하다는 데 동의해야합니다. 페어 프로그래밍으로 프로그램을 페어링 할 수없는 경우에만 피어 리뷰를 수행하십시오.
  • 이탈하지 마십시오!

이것은 최소한 지금부터 당신이하는 일이 두 사람에 의해 승인되었으므로 희망적으로 그 코드 비트를 개선하고 있음을 의미합니다.

다른 작업은 관리에 달려 있습니다. 당신은 그들에게이 질문에 답을 보여줄 수 있습니다!


페어 프로그래밍에 강력하게 반대해야합니다. 독립적 인 사상 가나 창의적 사고 방식은 아닙니다. 또한 팀 동료 검토를 대체하지 않습니다.
Acumenus 2018 년

1

전화 통화를 금지하고 엄격한 "버그는 버그 추적기로만 이동"규칙을 구현합니다. 그런 다음 오늘의 첫 번째 이동은 새로 입력 한 버그를 분류하고, 속임수를 정리하고, 우선 순위를 정하고, 버그 수정에 대한 작업을 시작하는 것입니다. 그리고 버그 수정이 실제로 버그를 수정하고 새로운 버그를 도입하지 않도록하십시오.

마지막 부분은 어떻게합니까? 기존 코드에 테스트 케이스를 개조하여. 함수가 있다면, 함수가 예상 한 것을 입력하고 출력하는지, 그리고 정크를 주면 제대로 작동하지 않는지 테스트하십시오. 일종의 자동화 된 UI 테스트를 사용하여 통합 및 성능을 앞뒤로 테스트하십시오.

실제로 코드 문제를 해결하기 위해 새벽 3시에 침대에서 나오지 않습니다. 그렇다면, 당신은 당신이 얻는 모든 것을받을 자격이 있습니다.



0

의사 나 변호사와 같은 소프트웨어 개발 라이센스가 필요한 유일한 이유는 귀하와 귀하와 같은 개발자입니다. 그렇게하면 최소한의 기본 프로그래밍 모범 사례를 따르지 않기 때문에 라이센스를 취소 할 수 있습니다. 그것은 무능한 사람들로부터 업계를 보호 할뿐만 아니라, 프로그래머가 모범 사례를 따르지 말 것을 요구하는 관리자로부터 유능한 프로그래머를 보호 할 것입니다.

참고로, 거의 모든 사람들이 촉박 한 마감일을 정합니다. 그러나 자신이하는 일을 알고있는 개발자는 장기적으로 작업을 더 빨리 수행 할 수 있기 때문에 모범 사례를 따릅니다. 그런 다음 그들은 3 년 동안 12 시간 동안 일할 필요가 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.