Кто в теме подскажите литературу.

опять ты

(0) Гарри Поттера читай, там все есть

(2) Очень фундаментальный труд.

wiki:Getting_Things_Done

КЭП говорит, что надо гуглить по фразе 'task management'

(5) По этому запросу и по "управление задачами" вываливается куча ссылок на ПО. А вот на литературу почти нет ссылок.

time management

все теории управления учат двум вещам касаемые сабжа

1. Как растравить приоритеты и оценить ресурсоемкость
2. Как использовать имеющиеся ресурсы

собственно на мой взгляд это две РАЗНЫХ задачи,
первая в Российских реалях почти не выполнимая, а вторая носит скорее теоретическую значимость.

Конечно нужно стремится, только все книги по сабжу не приблизят автора ни на один шаг, а скорее отдалят от цели. Для достижения цели нужно или чутье начальника (если оно есть то сабжа не было-бы) или анализ каждой конкретной ситуации.

http://www.iteam.ru/publications/project/section_36/article_2495
http://snipurl.com/26qa0n0

Я ищу теорию не о личных задачах. А систему управления заданиями для группы разработчиков. Задача поступает от руководителя проектом (это может быть и внедрение и сопровождение), ее принимает исполнитель, по завершении сдает на проверку и дальше задача либо дорабатывается либо сдается заказчику
У нас есть самодельная система учета заданий написанная под нужды франча. ДО этого использовали Redmine. конфа писалась стихийно, без плана. Хочу ее переделать, но перед этим хочется ознакомиться с теорией по данному вопросу.

http://snipurl.com/26qaaue

wiki:ITIL

(11) Я техподдержку пытаюсь отделить от разработки. Хотя может быть это и не правильно.

(10) ntjhbq

(10) Теорий разработки  множество есть: водопад, эджайл и др

(13) Правильное стремление. Но сложность в том, что поддерживать должен тот, кто разрабатывал.

(16) Смотря что под этим понимать. Если говорить, что поддерживать должен тот человек который разработал, то я с этим не согласен. А если говорить о том что поддерживать должна та компания которая разработала, то с этим я частично согласен.

(17) В узле будут ошибки, которые грамотнее человека, который его непосредственно делал, в принципе не исправит. Вопрос: как это обеспечить, не отдергивая разработчика от его текущих задач??? Если он будет не доделав одно дело, начинать другое по 10 раз на дню - проект до пенсии будет делаться.

+(18) >в принципе  н и к т о  не исправит

(10) просто интересно, чем Redmine не удовлетворил, что пришлось делать свою нетленку?

(20) В первую очередь не возможностью что-либо там дорабатывать. Точнее можно, но 1с-никам проще делать это на 1С. Было желание вести учет в одной базе.
Еще были проблемы с администрированием RedMine. Часто возникали какие-то мелкие проблемы на которые приходилось тратить много времени.

(21) А в одной базе это как? Типа рабочая УПП и в ней блок учета задач, привязанный к данным учета?

(21) code review как делаете, когда молодой специалист говорит что задача сделана?

(22) У нас не УПП. А в остальном да.

(23) За каждым клиентом закреплен куратор. Молодым большие задачи не даем. Сначала с ним проговариваем всю реализацию. Я объясняю задачу, он ее обдумывает. Потом рассказывает как будет делать. Если все ОК начинает делать. Потом при сдаче работ он показывает не только готовый вариант, но и код.

различные адаптации гибких методологий разработки типа скрама агила в э... горбатую спину "руководителя"

(24) Я УПП для пример привел.

(0) wiki:Project_Management_Body_of_Knowledge

(0) а на какик вопросы по-твоему должна отвечать эта теория?

тыщи их.  от гибкого wiki:Scrum, до жестко регламентированного wiki:Rational_Unified_Process

и вот еще wiki:%CA%E0%ED%E1%E0%ED