PMBoK изучить. Но лучше сначала курсы пройти , основы понять. Самостоятельно PMBoK читать лучше потом.
Я вот ходил на http://www.projectmanagement.ru/pages.asp?pagesid=165, на мой взгляд очень качественно преподают. По крайней мере все по полочкам разложили, есть некий "скелет" база на которую можно уже самостоятельно "наматывать" знания и опыт.
Здравствуйте, snaphold, Вы писали:
S>Скажите основные вещи с изучения которых нужно начать, если хочу стать PM.
PMBoK — общеиндустриальный, это только малая часть, и не самая важная, хоть и необходимая. Надо обязательно включить в программу книги по человеческому фактору и организационному поведению. Из них — нужен как минимум хороший учебник по организационному поведению, например — Доблаева (общеиндустриальный), и "Peopleware" Тома ДеМарко (специфична для разработки ПО, и никак не заменяет, а дополняет учебники по организационному поведению).
А также, вне всякого сомнения, купить и прочесть "Deadline" Тома ДеМарко, который увязывает все воедино, и формирует правильный подход. С него можно начать, если времени мало, это самая важная книга. И еще не забыть парную ей "путь камикадзе" Эда Йордона.
Ну а потом — читать про управление рисками (ДеМарко) и управление требованиями (Вигерса). И на этом не останавливаться.
"Мифический человекомесяц" Брукса читать не надо, там слишком много балшыта, если принять его на веру — повредится мозг. Потом как-нибудь.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, snaphold, Вы писали:
S>>Скажите основные вещи с изучения которых нужно начать, если хочу стать PM.
G>PMBoK — общеиндустриальный, это только малая часть, и не самая важная, хоть и необходимая. Надо обязательно включить в программу книги по человеческому фактору и организационному поведению. Из них — нужен как минимум хороший учебник по организационному поведению, например — Доблаева (общеиндустриальный), и "Peopleware" Тома ДеМарко (специфична для разработки ПО, и никак не заменяет, а дополняет учебники по организационному поведению).
G>А также, вне всякого сомнения, купить и прочесть "Deadline" Тома ДеМарко, который увязывает все воедино, и формирует правильный подход. С него можно начать, если времени мало, это самая важная книга. И еще не забыть парную ей "путь камикадзе" Эда Йордона.
G>Ну а потом — читать про управление рисками (ДеМарко) и управление требованиями (Вигерса). И на этом не останавливаться.
G>"Мифический человекомесяц" Брукса читать не надо, там слишком много балшыта, если принять его на веру — повредится мозг. Потом как-нибудь.
Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно
Предлагаю вот начать с пунктов из этой книги:
1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое?
2. Еще интересует такой момент: вот этого Вебстера неоценили в миру. Стоит ли заявлять руководству о своих амбициях (особенно через голову, если твой прямой рук-ль против твоих амбиций) или же лучше ждать что прямой рук-ль тебя "поднимет"?
S>Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно
Лучше все-таки начать на мой взгляд с понимания что такое проект, какие 9 областей управления проектами существуют. Как это все должно работать.
То что собственно изложено в PMBoK.
Книжка Deadline несомненно интересная, но на мой взгляд учебником не является. Там нет изложения материала в структурированной форме, автор описывает свои проблемы и выражает свое мнение как бы ему казалось их можно решить.
В своде знаний PMBoK материал изложен стуктурированно, является общепризнанным стандартом управления проектами, с оговоркой что это всего лишь лучшие практики, но не готовое решение для управления любыми проектами.
Здравствуйте, snaphold, Вы писали:
S>Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно
Книга, все же, литературное произведение. Не стоит воспринимать все буквально.
S>Предлагаю вот начать с пунктов из этой книги: S>1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое?
"Правильные" означает "подходящие для работы". Если бы можно было подобрать универсальные характеристики, уверен, автор бы их привел. В каждом конкретном случае от человека требуется свой набор качеств. Искусство руководителя в том и состоит, чтобы понять какие качества в данном месте будут полезными, какие вредными, а какие не имеют значения, и подобрать нужного человека. Не думаю, чтобы этому можно было научиться по книжкам или на курсах. В противном случае не был бы так распространен функциональный подход к сотрудникам. Если хочешь научиться работать с людьми (а для хорошего менеджера это обязательно) единственный способ, ИМХО, поработать замом у адекватного руководителя.
S>2. Еще интересует такой момент: вот этого Вебстера неоценили в миру. Стоит ли заявлять руководству о своих амбициях (особенно через голову, если твой прямой рук-ль против твоих амбиций) или же лучше ждать что прямой рук-ль тебя "поднимет"?
Делать нужно то, что будет эффективно. В книге речь идет не об этом, а о том, что в крупной формализованной корпорации нет места толковым менеджерам среднего звена. Им не требуется принимать решения самостоятельно, на это есть принятый процесс. Вебстера не то чтобы недооценили, он просто не востребован, поскольку его можно успешно заменить "обезьяной с инструкцией".
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, snaphold, Вы писали:
S>>Предлагаю вот начать с пунктов из этой книги: S>>1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое? M>"Правильные" означает "подходящие для работы". Если бы можно было подобрать универсальные характеристики, уверен, автор бы их привел. В каждом конкретном случае от человека требуется свой набор качеств. Искусство руководителя в том и состоит, чтобы понять какие качества в данном месте будут полезными, какие вредными, а какие не имеют значения, и подобрать нужного человека. Не думаю, чтобы этому можно было научиться по книжкам или на курсах. В противном случае не был бы так распространен функциональный подход к сотрудникам. Если хочешь научиться работать с людьми (а для хорошего менеджера это обязательно) единственный способ, ИМХО, поработать замом у адекватного руководителя.
Красиво Вы написали)) но хочется на примере услышать, чтобы представлять "правильных людей". Ну вот стандартная компания: отдел разработчиков, отдел веб-дизайнеров, отдел тестирования, отдел PM. Какие они должны быть, правильные люди, рассматривая с точки зрения рук-ля отдела, PM и директора всего этого.
S>>2. Еще интересует такой момент: вот этого Вебстера неоценили в миру. Стоит ли заявлять руководству о своих амбициях (особенно через голову, если твой прямой рук-ль против твоих амбиций) или же лучше ждать что прямой рук-ль тебя "поднимет"? M>Делать нужно то, что будет эффективно. В книге речь идет не об этом, а о том, что в крупной формализованной корпорации нет места толковым менеджерам среднего звена. Им не требуется принимать решения самостоятельно, на это есть принятый процесс. Вебстера не то чтобы недооценили, он просто не востребован, поскольку его можно успешно заменить "обезьяной с инструкцией".
Здравствуйте, snaphold, Вы писали:
S>Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно S>Предлагаю вот начать с пунктов из этой книги: S>1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое?
Гхм. Я не могу объяснить, что есть "правильные люди" Чтобы пронять почему, читаем вот это, и думаем.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, snaphold, Вы писали:
S>>Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно S>>Предлагаю вот начать с пунктов из этой книги: S>>1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое?
G>Гхм. Я не могу объяснить, что есть "правильные люди" Чтобы пронять почему, читаем вот это, и думаем.
G>http://gaperton.livejournal.com/14664.html G>http://gaperton.livejournal.com/15705.html
ну в общем, дошел в книге до кач-в менеджера и понял, почему вас вопрос о правильных людях в тупик поставил внутренний голос только может сказать тот это человек или нет. Кстати у меня так было в жизни с девушкой. Она чем то тянула меня к себе, но внутр голос говорил "не надо", не послушал — потом пожалел
Правда мне интересно как быть в ситуации, где вроде всё и все говорит за то, чтобы сделать так, а внутр голос говорит по другому. Бывали у Вас в практике такие ситуации? Еще особенно если вышестоящее рук-во несогласно с твоим внутр голосом...
Здравствуйте, Dog, Вы писали:
S>>Скажите основные вещи с изучения которых нужно начать, если хочу стать PM. Dog>А что на это говорит ваш внутренний голос ?
ну вообще, работу, именно PM, мне кажется, можно разделить на:
1. умение контактировать с людьми
2. понимание предметной области
3. знание интсрументов для работы
4. опыт разработчика
Здравствуйте, Gaperton, Вы писали:
G>А также, вне всякого сомнения, купить и прочесть "Deadline" Тома ДеМарко, который увязывает все воедино, и формирует правильный подход. С него можно начать, если времени мало, это самая важная книга. И еще не забыть парную ей "путь камикадзе" Эда Йордона.
Я бы к ним еще и "Как пасти котов" Рейнвотера добавил
S>>>Скажите основные вещи с изучения которых нужно начать, если хочу стать PM. Dog>>А что на это говорит ваш внутренний голос ? S>ну вообще, работу, именно PM, мне кажется, можно разделить на:
Я о том , нужна ли она вам
Здравствуйте, snaphold, Вы писали:
S>>>Спасибо! Начал с Deadline. А давайте будем некоторые моменты в интерактиве обсуждать! Мне кажется это будет полезно S>>>Предлагаю вот начать с пунктов из этой книги: S>>>1. для успешного построения команды "Возьмите правильных людей". Что под этим имеется ввиду? Неконфликтные, образованные + опыт или другое?
G>>Гхм. Я не могу объяснить, что есть "правильные люди" Чтобы пронять почему, читаем вот это, и думаем.
G>>http://gaperton.livejournal.com/14664.html G>>http://gaperton.livejournal.com/15705.html
S>ну в общем, дошел в книге до кач-в менеджера и понял, почему вас вопрос о правильных людях в тупик поставил внутренний голос только может сказать тот это человек или нет.
...и опыт, сын ошибок трудных, и гений, парадоксов друг. И случай, Бог изобретатель.
Подбор правильных людей и обращение с ними — самый пожалуй важный элемент работы менеджера. Представьте, что вы играете в шахматы, вам надо выиграть, но ваши фигуры сами решают, как им ходить. Вы можете указывать им направление и общую стратегию, ободрять их, но непосредственно партию ведут они. Как вы воздействуете на систему? Самое сильное ваше воздействие, во многом определяющее исход партии — подбирать правильных людей, и ставить их на правильные, подходящие им роли — "ферзь", "слон". Вообще, возьмите в качестве аналогии футбол, он еще ближе. Футбол иллюстрирует важный элемент разоаботки, которого в шахматах нет — это командный вид спорта, и помимо стратегии важна сыгранность. Это — второй важнейший элемент, которого вам надо добится.
Я могу это попытаться формализовать, но от этого скорее будет для вас вред. Нельзя к этому подходить формально ни в коем случае, надо учитывать все факторы каждой индивидуальной ситуации, и каждый раз креативить заново, задействуя весь свой опыт и нитуицию. Нет тут никакой технологии, и не может быть, потому что вы работаете с людьми, а не отбираете кирпичи для дома. И даже если я напишу "правильно", вы все равно не поймете суть без "ключа". А чтобы наработать интуицию, вам опыт нужен и саморефлексия. Они послужат "ключом" для понимания книг.
А все остальное — дело техники, и влияет слабее. Вот тут, например, говорят — PMBoK. Обратите внимание — то, насколько вы аккуратно и красиво составляете и оформляете план, почти никак не влияет на успех проекта и его срок. Проект все равно займет столько, сколько займет, план это прогноз. Составление планов по классике — это непродуктивная деятельность, она не может являться главной. План становится полезным тогда, когда вы в его составлении смещаете акцент с PMBoK на суть вашей работы. План — это воплощение вашей стратегии — что, в каком порядке, и почему вы делаете. В этом суть плана, а не в Gantt Chart. Чтобы составить хороший план, надо хорошо понимать архитектуру системы, требования. В софте — планирование это по сути своей часть архитектурной работы, и неразрывно связано с предварительным проектированием. От такого планирования — есть value.
S>Правда мне интересно как быть в ситуации, где вроде всё и все говорит за то, чтобы сделать так, а внутр голос говорит по другому. Бывали у Вас в практике такие ситуации? Еще особенно если вышестоящее рук-во несогласно с твоим внутр голосом...
Здравствуйте, snaphold, Вы писали:
S>Правда мне интересно как быть в ситуации, где вроде всё и все говорит за то, чтобы сделать так, а внутр голос говорит по другому. Бывали у Вас в практике такие ситуации? Еще особенно если вышестоящее рук-во несогласно с твоим внутр голосом...
Берем дополнительное время, и преобразуем внутренний голос в список рисков, которые осмысленно учитываем. Если не получается, то забиваем на голос, выхватываем шашку наголо, и переходим в кавалерийскую атаку, а там разберемся по ходу. "Главное — ввязаться в драку." Иначе мы лишаем себя возможности ошибится и приобрести опыт.
G>Подбор правильных людей и обращение с ними — самый пожалуй важный элемент работы менеджера. Представьте, что вы играете в шахматы, вам надо выиграть, но ваши фигуры сами решают, как им ходить. Вы можете указывать им направление и общую стратегию, ободрять их, но непосредственно партию ведут они. Как вы воздействуете на систему? Самое сильное ваше воздействие, во многом определяющее исход партии — подбирать правильных людей, и ставить их на правильные, подходящие им роли — "ферзь", "слон".
Задача функционального руководителя а не ПМ решать кто лучше справится с задачей. У ПМ нет квалификации программиста чтобы понять кто лучше сделает конкретную работу.
G>Я могу это попытаться формализовать, но от этого скорее будет для вас вред. Нельзя к этому подходить формально ни в коем случае, надо учитывать все факторы каждой индивидуальной ситуации, и каждый раз креативить заново, задействуя весь свой опыт и нитуицию. Нет тут никакой технологии, и не может быть, потому что вы работаете с людьми, а не отбираете кирпичи для дома. И даже если я напишу "правильно", вы все равно не поймете суть без "ключа". А чтобы наработать интуицию, вам опыт нужен и саморефлексия. Они послужат "ключом" для понимания книг.
G>А все остальное — дело техники, и влияет слабее. Вот тут, например, говорят — PMBoK. Обратите внимание — то, насколько вы аккуратно и красиво составляете и оформляете план, почти никак не влияет на успех проекта и его срок.
В PMBoK говориться не только о планах. Там описан весь жизненный цикл проекта : инициация, планирование, мониторинг, завершение.
G>Проект все равно займет столько, сколько займет, план это прогноз. Составление планов по классике — это непродуктивная деятельность, она не может являться главной. План становится полезным тогда, когда вы в его составлении смещаете акцент с PMBoK на суть вашей работы. План — это воплощение вашей стратегии — что, в каком порядке, и почему вы делаете. В этом суть плана, а не в Gantt Chart.
В PMBoK воообще не затрагивается инструментарий. Там не говорится о том что вы должны это делать в MS Project или другой программе и обязательно использовать диаграммы ганта.
G>Чтобы составить хороший план, надо хорошо понимать архитектуру системы, требования. В софте — планирование это по сути своей часть архитектурной работы, и неразрывно связано с предварительным проектированием. От такого планирования — есть value.
Для этого есть специалисты которые детализируют план. ПМ никогда план не пишет в одиночку, это общая коллективная работа. Каждый специалист детализирует свой уровень работ.
Хочу подчеркнуть что PMBoK это общепризнанные сообществом ПМ паттерны. Deadline — признает только автор и часть людей которым книга понравилась.
Хотя в Deadline несомненно есть здравые мысли и нужно их иметь ввиду.
Но грубо говоря на собеседовании знания PMBoK будут как-то цениться , а вот то что вы прочитали Deadline никого интересовать особо не будет.
Здравствуйте, pashzhel, Вы писали:
G>>Подбор правильных людей и обращение с ними — самый пожалуй важный элемент работы менеджера. Представьте, что вы играете в шахматы, вам надо выиграть, но ваши фигуры сами решают, как им ходить. Вы можете указывать им направление и общую стратегию, ободрять их, но непосредственно партию ведут они. Как вы воздействуете на систему? Самое сильное ваше воздействие, во многом определяющее исход партии — подбирать правильных людей, и ставить их на правильные, подходящие им роли — "ферзь", "слон".
P>Задача функционального руководителя а не ПМ решать кто лучше справится с задачей. У ПМ нет квалификации программиста чтобы понять кто лучше сделает конкретную работу.
Я еще не видел успешно работающей матричной схемы, так что ничего не могу сказать про функционального руководителя.
Во-вторых, в нашей индустрии у "ПМ" чаще всего есть квалификация программиста, и это его обязанность подбирать людей на ключевые роли.
G>>Я могу это попытаться формализовать, но от этого скорее будет для вас вред. Нельзя к этому подходить формально ни в коем случае, надо учитывать все факторы каждой индивидуальной ситуации, и каждый раз креативить заново, задействуя весь свой опыт и нитуицию. Нет тут никакой технологии, и не может быть, потому что вы работаете с людьми, а не отбираете кирпичи для дома. И даже если я напишу "правильно", вы все равно не поймете суть без "ключа". А чтобы наработать интуицию, вам опыт нужен и саморефлексия. Они послужат "ключом" для понимания книг.
G>>А все остальное — дело техники, и влияет слабее. Вот тут, например, говорят — PMBoK. Обратите внимание — то, насколько вы аккуратно и красиво составляете и оформляете план, почти никак не влияет на успех проекта и его срок.
P>В PMBoK говориться не только о планах. Там описан весь жизненный цикл проекта : инициация, планирование, мониторинг, завершение.
И что? Это в корне меняет дело, да? У менеджера ближе к концу проекта остается все меньше и меньше контроля, почти все, что он может сделать для его успеха, он может сделать на раннем этапе. Впрочем, вы видимо говорите про тот тип менеджера, который для успеха проекта не может сделать ничего. Не до того ему будет — надо будет постоянно проверять по PMBoK, правильно ли он проект завершает, или нет.
G>>Проект все равно займет столько, сколько займет, план это прогноз. Составление планов по классике — это непродуктивная деятельность, она не может являться главной. План становится полезным тогда, когда вы в его составлении смещаете акцент с PMBoK на суть вашей работы. План — это воплощение вашей стратегии — что, в каком порядке, и почему вы делаете. В этом суть плана, а не в Gantt Chart.
P>В PMBoK воообще не затрагивается инструментарий. Там не говорится о том что вы должны это делать в MS Project или другой программе и обязательно использовать диаграммы ганта.
И я тоже не говорю, надо ли это делать в MS Project. А о том, что там ничего не говорится про WBS и диаграммы ганта, известные еще с первой половины 20 века, я вам просто не поверю, с вашего позволения.
К тому же, выкак и везде, отвечаете на частность, а не на основную мысль. Какая в конце концов разница, говорится в PMBoK о MS Project, или нет. Да пусть дае говорится.
G>>Чтобы составить хороший план, надо хорошо понимать архитектуру системы, требования. В софте — планирование это по сути своей часть архитектурной работы, и неразрывно связано с предварительным проектированием. От такого планирования — есть value.
P>Для этого есть специалисты которые детализируют план. ПМ никогда план не пишет в одиночку, это общая коллективная работа. Каждый специалист детализирует свой уровень работ. P>Хочу подчеркнуть что PMBoK это общепризнанные сообществом ПМ паттерны. Deadline — признает только автор и часть людей которым книга понравилась.
Cообщество ПМ, немногочисленное и далекое от народа, в массе своей успешно проваливает значительную часть проектов в нашей индустрии, в разработке софта и хайтеке вообще. Не будь статистика столь печальной, можно было бы к "общепринятым паттернам" относится с большим трепетом.
Что насчет "признания" автора Deadline, то у нас в индустрии он и его книги пользуются куда большей известностью и уважением, чем PMBoK. Человека, который претендует на руководящую роль в разработке софта, и который никогда не слышал имя автора Deadline, я сильно удивлюсь, и скорее всего, на работу не возьму, пусть он даже выучил PMBoK наизусть. Я практически уверен, что многие из моих коллег поступят таким же образом. Устроим голосование?
P>Хотя в Deadline несомненно есть здравые мысли и нужно их иметь ввиду.
Ага. И одна из этих мыслей — что PMBoK и техники вооще — далеко не главное в работе менеджера. Хотя, в PMBoK несомненно есть здравые мысли, которые нужно иметь в виду.
P>Но грубо говоря на собеседовании знания PMBoK будут как-то цениться , а вот то что вы прочитали Deadline никого интересовать особо не будет.
На собеседовании, если речь идет о разработке софта, PMBoK никому не вперся, ценится опыт руководства и успешные проекты. Если этого нет, то никакой PMBoK не поможет. А если он есть — то никакой ПМБОК не нужен.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, pashzhel, Вы писали:сделает конкретную работу.
G>Я еще не видел успешно работающей матричной схемы, так что ничего не могу сказать про функционального руководителя.
А вы в какой стране работаете ? Если Россия то у нас нужно отметить ранее были исключительно функциональные организации. Проектных очень мало.
Большинство в России это слабая матрица. Тенденция в сторону проектных.
Так что в России как правило всегда есть функциональный руководитель и он должен определять , в крайнем случае ведущие специалисты. Но не ПМ.
G>Во-вторых, в нашей индустрии у "ПМ" чаще всего есть квалификация программиста, и это его обязанность подбирать людей на ключевые роли.
Это плохо. Часто путают роль team-lead архитектора и ПМ или смешивают. К добру это не приводит. Тоже самое что программиста смешать с тестировщиком -не совместимые роли.
P>>В PMBoK говориться не только о планах. Там описан весь жизненный цикл проекта : инициация, планирование, мониторинг, завершение.
G>И что? Это в корне меняет дело, да?
Да, учитывая что автор исходной темы только разбирается ему может данная не совсем точная фраза исказить представление о теме.
P>>В PMBoK воообще не затрагивается инструментарий. Там не говорится о том что вы должны это делать в MS Project или другой программе и обязательно использовать диаграммы ганта.
G>И я тоже не говорю, надо ли это делать в MS Project. А о том, что там ничего не говорится про WBS и диаграммы ганта, известные еще с первой половины 20 века, я вам просто не поверю, с вашего позволения.
Там говориться, но не обязывается. Просто приводится как один из примеров представления.
G>Cообщество ПМ, немногочисленное и далекое от народа, в массе своей успешно проваливает значительную часть проектов в нашей индустрии, в разработке софта и хайтеке вообще. Не будь статистика столь печальной, можно было бы к "общепринятым паттернам" относится с большим трепетом.
Если говорить о нашей индустрии то образованных менеджеров очень мало. Большинство менеджеров вообще без образования работает.
Отсюда и печальная статистика на мой взгляд.
G>Что насчет "признания" автора Deadline, то у нас в индустрии он и его книги пользуются куда большей известностью и уважением, чем PMBoK. Человека, который претендует на руководящую роль в разработке софта, и который никогда не слышал имя автора Deadline, я сильно удивлюсь, и скорее всего, на работу не возьму, пусть он даже выучил PMBoK наизусть. Я практически уверен, что многие из моих коллег поступят таким же образом. Устроим голосование?
Зачем голосование. Давайте найдем в требованиях к вакансии ПМ хоть в одной знание Deadline, вакансии где явно требуют PMBoK есть 100%.
Я могу представить профессионального ПМ который не читал Deadline, но знает PMBoK ( или другой стандарт ), но вот чтобы наоборот — не могу.
Тоже самое как не могу представить профи математика который читал книгу "Увлекательная математика для чайников" какого-нибудь известного автора, но не знаюший школьную программу ).
P>>Хотя в Deadline несомненно есть здравые мысли и нужно их иметь ввиду. G>Ага. И одна из этих мыслей — что PMBoK и техники вооще — далеко не главное в работе менеджера.
В PMBoK также говорится и о мотивации, о ее необходимости, о личностных отношениях. Конечно там нет правил хорошего тона и прочего , но это уже узнается из других учебников.
То что в работе с людьми — главное это люди и человеческий фактор является основным, помоему очевидно. Для этого нет необходимости читать Deadline.
Потом как-нибудь.
