관리자로서 항상 최첨단의 작업을 생성 할 수는 없습니다. 일부 프로젝트는 유지 관리 모드에서 실행되며 회사에 건전한 무료 현금 흐름을 생성합니다.
이 프로젝트에서 개발자가해야 할 일은 무엇입니까? 나는 브랜드를 브랜딩 할 생각을하고 있었지만 여기서 많은 도움을받을 수 있었다.
편집 : 제안에 대해 모두 감사합니다. 지금까지 우리가 가진 것은 다음과 같습니다.
답변:
유지 관리 모드의 프로젝트의 경우 다음에 어떤 것이 있는지 생각해보십시오. 결국 고객에게 매력을 줄 수있는 것은 무엇입니까? 노후화를 피하려면 새로운 기능, 성능 향상 또는 단순화가 필요합니까? 다시 시작하면 일부 프로젝트를 병합 할 수 있습니까? 다른 도구, 언어 또는 프로세스로 구축해야합니까? 아무도 고려하지 않은 개선 사항이나 지침이 있습니까? 개발자에게 이러한 질문에 대한 답변을 요청하십시오. 프로토 타입을 제작하십시오. 새로운 언어 나 프레임 워크를 사용해보십시오. 프로젝트에 새로운 모바일 인터페이스를 제공하십시오.
마감 기한이 없을 때 대안을 실험하는 것이 더 쉽습니다. 무딘 시간을 사용하여 경쟁자를 능가하십시오.
당신은 그들에게 그들의 시간을 점유 할 무언가를 제공해야합니다. 유지 관리 모드의 프로젝트는 종종 각 개발자로부터 주당 40 시간을 요구하지 않습니다. 그렇다면 소프트웨어에 문제가있을 수 있지만 질문을하는 방식에 따라 할 일이 많지 않은 동안 개발자를 차지할 아이디어를 찾고 있다고 가정합니다. 나는 당신의 재정 예산이 무엇인지 모르지만, 소프트웨어 컨퍼런스에 보내는 것과 같은 인센티브가 도움이 될 것이라고 생각합니다. 또 다른 제안으로는 일주일에 15 시간 동안 자신의 관심사를 명시 적으로 탐색 할 수 있습니다. 정렬 알고리즘이나 데이터베이스 디자인에 대해 관심이있는 사람이있을 수 있습니다. 귀하의 비즈니스와 직접 관련이 없을 수도 있지만 결국에는 지식이 향상되어 혜택을받지 못할 것이라고 생각할 수 없습니다. 아무 일도하지 말고 강요하지 마십시오. 해야 할 일이 많지 않은 경우 다른 일로 시간을 보내도록하십시오. 웹을 무작위로 탐색하는 것이 아니라 조금 탐색하도록하기 위해 그들이하는 일에 대한 요약을 요청하는 것이 공정하다고 생각합니다.
실제로 흥미로운 프로젝트는 매우 드 rare니다. 그리고 연구에 따르면 직원의 행복은 사회와 재미에 크게 좌우됩니다. 그들은 왜 현재 직장을 그만 두지 않을지를 묻는 동료들을 언급 합니다.
그렇기 때문에 건물에서 소리 치지 않고 웃을 때 항상 행복해야합니다.
또 다른 한 가지 이유는 소득 창출 프로젝트가 모든 사람의 이익을위한 것이라는 점을 분명히하는 것입니다. 소득, 직업 등이 없습니다. 작업을 수행해야합니다. 온보드. 사람들이 깨닫지 못하는 경우가 있습니다.
그런 다음 하중을 나눕니다. 지루하고 성가신 작업의 제한을 유지하는 방법을 시도하십시오 (일의 종류에 따라, 평일을 나누고, 작업을 나누는 등) 다른 사람들이 할 때 모든 혼란에 빠지는 느낌을 아무도 갖지 않습니다. 재미있는 것들.
그런 다음 재미있는 것들로 꾸며보십시오. 그리고 개발자들에게 이야기하면 좋은 아이디어가있을 수 있습니다.
종종이 프로젝트는 평범하고 평범한 프로그래머에게 유용합니다. 프로그래밍에 관심이없고 청구서를 지불하는 방법으로 만 보는 사람들. 이제 뭔가를 이해하십시오. 나는 그들이 약한 프로그래머이기 때문에 당신의 삶을 비참하게 만들고 싶어하기 때문에 이것을 말하고 있지 않습니다. 나는 이것들이 보통 그들의 일이 그들의 삶에서 성취의 원천이라고 기대하지 않는 종류의 사람들이기 때문에 이것을 말하고 있습니다. 그것의 소리에 따르면, 이들은 저압, 꾸준한 수입원처럼 들립니다. 아마도이 근로자들은 쉽고 압력이 낮은 일을 기꺼이 받아들입니다.
물론 그렇다고해서 그들이 둔한 일을하고 잊어 버릴 수 있다는 의미는 아닙니다. "A 플레이어"에게 80 % 재미있는 작업 / 20 % 둔한 작업, "B 플레이어"는 50/50, "C 플레이어"는 20/80 일 수 있습니다.
나는 지루하고 흥미롭지 않은 프로젝트에서 일한 적이 없다는 것을 인정해야하므로 귀하의 질문을 이해하지 못할 것입니다. 그리고 저는 생활을위한 엔터프라이즈 시스템을 개발합니다. :) 진지하게, 실제로는 프로그래머가 "지루한"작업으로 인해 예상보다 훨씬 덜 귀찮다는 것을 알았습니다. 아무도 점검하지 않는 작업 표 작성과 같은 쓸모없는 일은 훨씬 더 큰 문제입니다. 그 말은 :
프로그래머의 선호도를 알고 있어야합니다. 일부 프로그래머는 GUI를 좋아하지 않으며 일부 프로그래머는 SQL을 멀리합니다. 한 프로그래머에게는 지루한 작업이 다른 프로그래머에게는 재미있을 수 있으므로 해당 환경 설정을 존중하십시오. 어떤 이유로 든 작품을 그런 식으로 나눌 수 없다면 경쟁을 증가 시켜서 흥미롭게 만드십시오-자신의 역할을 가장 먼저 끝내는 사람과 경쟁하게하십시오. 품질 보증 관련 버그 Microsoft는 기업 문화로 유명하여 프로그래머가 다양한 접근 방식으로 경쟁하고 최종적으로 가장 좋은 방법을 선택하거나 각 방법의 가장 좋은 부분을 최종 제품에 통합합니다.
제품의 일부를 소유하고 제어 할 수 있으면 참여도가 크게 증가합니다. 대조적으로, 누군가가 당신의 작업을 미세 관리하는 것보다 더 지루한 것은 없습니다. 또한 모든 사람들이 미워하는 반복적 인 작업이 있다면 더 큰 그림을 설명해야합니다. 그것이해야 할 일이며 매주 그것을하는 사람과 그 사람을 회전시키는 것만으로도 충분합니다.
나는 이런 종류의 프로젝트를 더 흥미로운 프로젝트의 경로로 사용하여 성공을 보았습니다.
신입 및 중급 개발자가 모두 "지루한"프로젝트에서 시니어 개발자 (대부분 다른 프로젝트에있는 사람들)에게 질문을하는 경우 유지 보수 영역에서 더 잘 수행할수록 아마도 당신은 새로운 작업에 대한 미래의 참여를 얻고, 당신이 괜찮은 팀을 가지고 있고 가끔 팀 변경을 실제로 수행하고 때로는 팀이 스스로 조정할 새로운 작업에 대한 주요 개발자를 끌어 들일 것이라고 가정합니다.
팀이 나쁘거나 팀이 아주 좋은 경우이 방법이 효과가 없을 수 있습니다.