От мелких дел спасенья нет,Каждый рабочий день наваливается на меня новой грудой запросов от клиентов. Запросы, как водится, разного размера и разной срочности. Со сверхсрочными понятно - их приходится латать, отбросив всё остальное. Однако затем нужно это остальное тоже как-то упорядочить. Математикам и программистам знакома эта проблема: ввести общее отношение порядка на множестве, члены которого сравнимы в лучшем случае попарно, причём не все пары вообще сравнимы, а результаты некоторых сравнений не транзитивны.
Но выбирать спеши -
Не то оставишь крупный след
Несделанных больших.
Пит Хейн
Я отследил у себя несколько стихийно сложившихся эвристик:
1. Если удаётся сгруппировать запросы в некие категории (по проектам, по исполнителям, по затронутым модулям...), и при этом в какой-то категории оказываются всего один-два запроса - следует исполнить их прежде остальных, даже если они не слишком важны, просто чтобы уменьшить количество категорий. Меньше сущностей - проще вертеть их в голове.
2. Если какой-то запрос очень долго болтается в хвосте очереди с низким приоритетом, и до него никак не доходят руки - попробовать тихонько "забыть" о нём. Скорее всего, он никому не нужен. Если клиенты напомнят - извиниться и вернуть в очередь, с приоритетом повыше. Если не напомнят - туда ему и дорога.
3. Помнить, что работа менеджера - управлять, а не исполнять. Мелочи, которые проще и быстрее сделать самому, чем объяснять исполнителю, а потом ещё контролировать исполнение - можно делать самому, но только если делать больше нечего. Иначе всё-таки следует делегировать исполнение, даже если в итоге получится дольше и хуже - а то ведь вообще никогда и никак не получится.
4. Посредственное качество в сжатые сроки лучше, чем достойное качество в долгие сроки. (Стеная, додавливаю в себе совесть и навыки перфекциониста.) Всё равно клиенты тут же потребуют десятки исправлений и улучшений. Они сами точно не знают, чего хотят. Если знают точно - значит, они не окончательные пользователи, а только посредники-постановщики. Конечные пользователи всё равно потребуют переделывать.
5. Следствие из предыдущего: лучше быстро выдать клиенту неполный ответ на его запрос и пообещать дослать подробности позже (вероятно, никогда - см. пункт 2), чем долго молчать, собирая безупречный ответ.
6. Лучшим инструментом планирования был и остаётся простой текстовый файл, максимум - Excel и электронные заметки-липучки на десктопе. Если вам нужен сложный органайзер и автоматические планировщики - значит, что-то не так с вашим процессом. Вероятно, вам пора создавать под собой промежуточный слой управления и делегировать ему задания крупными пачками.
7. Помните, что менеджеры - представители древнейшей профессии. Ваша задача - не сделать продукт, а удовлетворить клиента. Редкий клиент хочет именно того, что формулирует в техническом задании. Задание-то может в итоге оказаться и наполовину не исполненным, а клиент будет счастлив. Весь фокус в том, чтобы удачно попасть в любимую позу и ритм движений клиента. Как именно? А вот тут-то и начинается Тёмная Сторона жизни менеджера...
Я пишу вопрос на чистой стороне визитки, помечаю категорию спецсимволом и (если не ленюсь, определенным цветом маркера). Далее визитки складываются в удобную колоду и тасуются так, как хочется мне.
Я бы уточнил: мелочи, о которых тебе кажется, что их быстрее будет сделать самому.
По сути майндмэп - это просто куча слов, произвольно связанных линиями, и по ценности презентации сравним с каким-нибудь tag cloud.
Впрочем, мне всё равно нечего с ним делать.
А можно название? В Ubuntu для меня это однозначно Tomboy, а вот в WinXP - глаза разбегаются от многообразия :)
А! Ну, явно не хватает одного замечания, касающегося того, что один старый клиент равен двум новым. И еще чего-то нет.