пятница, 25 декабря 2009 г.

Deadline. Роман об управлении проектами. Часть 2

Deadline

В этом сообщении я опубликую фрагменты диалогов и другие интересные цитаты из замечательной книги Тома Демарко “Deadline. Роман об управлении проектами”.

 

 

 

 

 

 

- Некоторые думать вообще не умеют. Такие люди обычно становятся директорами крупных компаний, вроде этой.
Лакса Хулигэн в разговоре с мистером Томпкинсом
Глава 1. Широчайшие возможности

- Найдите правильных людей. Потом, что бы вы ни делали, какие бы ошибки ни допускали, люди вытащат вас из любой передряги. В этом и заключается работа руководителя.
Томпкинс о роли руководителя
Глава 1. Широчайшие возможности

Он и раньше сталкивался с идиотскими и губительными для команды «наказаниями за отставание от графика», и сегодняшний разговор разбередил в нем эти воспоминания. Откуда у некоторых руководителей эта слепая вера в кнуты и штрафы? Неужели из них получаются такие же ужасные родители? Скорее всего, да.
Мысли мистер Томпкинса о пользе наказания
Глава 4. Завод по изготовлению CD-ROM

— Если вдуматься, для руководства проектом голова вообще не больно-то нужна. Больше всего нужны нутро, сердце и душа.
— Нутро, сердце и душа?
— Да. Настоящий руководитель чувствует ситуацию нутром, управляет людьми исключительно сердцем и может вдохнуть живую душу в проект, команду или всю организацию.
Диалог Белинды Бинды и мистера Томпкинса о роли руководителя
Глава 6. Лучший в мире руководитель

Душа команды - это как песчинка в ракушке, вокруг которой начинает нарастать самое ценное. Сообщество.
Белинда Бинда о душе команды
Глава 6. Лучший в мире руководитель

- Давайте знакомиться с людьми, а не с их резюме.
Белинда о подборе персонала
Глава 7. Подбор персонала

— Мы ищем таких руководителей, которые настолько хорошо подходят для своей работы, что могут менять мир вокруг себя и добиваться гармонии между этим миром и тем, что они делают вместе со своей командой.
Белинда о подборе руководителей
Глава 7. Подбор персонала

— Иногда бывает трудно смотреть в глаза своему начальнику и говорить, что не сможешь сделать работу вовремя. Куда проще взять и опоздать. Но тогда твой босс узнает об опоздании на четыре недели позже, и у него просто не останется возможности хоть как-то исправить ситуацию. Именно поэтому мы выработали такую вот полуанонимную систему. Конечно же, я знаю, кто сейчас приходил на «исповедь», но делаю вид, что он мне не знаком. А в результате всегда узнаю плохие новости вовремя.
Молли Макмора об общении разработчиков с их руководителями
Глава 7. Подбор персонала

В этом и заключается наша работа — находить для своих подчиненных такую должность, на которой проявятся все их скрытые способности. А в чем еще заключается руководство, если не в этом?
Белинда о роли руководителя
Глава 12. Человек, который умел считать

— Да ладно вам, — вмешался Аристотель. — Как будто вы раньше этого не знали. Наверняка в глубине души каждый из нас знает, что сверхурочная работа — верный способ снизить производительность.
— Да, в общем-то, это так, — задумчиво сказала Белинда. — Недостатки сверхурочной работы хорошо всем известны: усталость, отсутствие творческой энергии, ошибки…
— А также потеря времени в течение обычного рабочего дня, — добавил Аристотель.
— А это почему?
— Потому что люди знают, что все равно будут работать допоздна. Поэтому они могут позволить себе долгие и не очень нужные совещания, перерывы и тому подобное.
— Да уж точно. А если запретить работать сверхурочно, то им волей-неволей придется использовать рабочее время более эффективно.
— Именно.
— Значит, в список недостатков сверхурочной работы можно добавить еще и это. А те данные, которые привел нам Вальдо, ясно показывают: недостатки сверхурочной работы все равно перевешивают пользу от дополнительных усилий разработчиков. Как правильно сказал Аристотель, все мы в глубине души знаем
это.
— Так что же делать руководителю в трудной ситуации? — взволнованно спросил мистер Томпкинс.
— Что-то другое, — ответила ему Белинда. — Что-то более сложное: принимать на работу новых сотрудников, придумывать способы мотивации персонала, развивать командные отношения и поддерживать боевой дух, привлекать к проекту грамотных людей, устранять из процесса разработки все малоэффективные действия, реже устраивать совещания, не давать людям Том ДеМарко: «Deadline. Роман об управлении проектами» 121
работать сверхурочно, сократить работу над документацией. Однако мистера Томпкинса это ничуть не успокоило.
Диалог Аристотеля, Томпкинса и Белинды о вреде сверхурочных
Глава 15. Думать быстрее!

Не мне объяснять тебе, что когда разработчики не чувствуют поддержки и признания начальства, они редко создают сильные сплоченные команды.
Мелисса Альбер о кристаллизации команд
Глава 16. План работы по подготовке к летним Олимпийским играм

Я считаю, что в каждом из нас, в душе или на уровне подсознания, живет тайный страх: мы боимся показать, что соображаем хуже других. Вся наша раса заражена этим страхом. Каждый готов предположить, что его мыслительные способности ниже средних, поэтому ему надо прикладывать дополнительные усилия, чтобы разобраться в том, в чем другие разбираются с ходу. А теперь возьмем нашу ужасную спецификацию. Ты читаешь ее целый день и обнаруживаешь, что ничего не понимаешь. И тут приходит начальник и спрашивает: «Ну как? Как вам спецификация?» Что сказать? И мы врем! «Все в порядке, босс. То есть я хочу сказать, что документ этот весьма непростой, но дайте нам еще немного времени, и мы во всем разберемся…» И так поступает каждый!
Белинда о корпоративном мышлении и отношению к руководству
Глава 16. План работы по подготовке к летним Олимпийским играм

Кстати, у меня есть твердое убеждение: любую сложную вещь можно описать простыми словами. Если нам это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
Белинда о спецификациях
Глава 16. План работы по подготовке к летним Олимпийским играм

Дорога к мудрости проста,
Как этот краткий стих:
Ошибки смело совершай -
И станет меньше их.
                                                     Пит Хайн
Глава 18. Маэстро Диеньяр


Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:

Часть 1. Из записной книжки мистера Томпкинса

Часть 2. Остальные цитаты

Deadline. Часть 1. Из записной книжки мистера Томпкинса

Deadline

Немногие знают, что помимо книг по управлению проектами и структурному анализу Том Демарко написал сборник рассказов под названием “Lieutenant America and Miss Apple Pie” и повесть “Dark Harbor House”.

Помимо компьютерных книг и художественной литературы у Тома Демарко есть и промежуточный вариант - “Deadline. Роман об управлении проектами”, в котором автор рассказывает историю мистера Томпкинса, менеджера проектами, который сталкивается с типичными проблемами управления программными проектами.

Во многом, темы этой книги пересекаются с темами из ставшей давно классической книги Демарко и Листера “Peopleware”. И хотя “Peopleware” написана замечательным языком и сама читается как художественное произведение, Демарко решил, что этого недостаточно и решил описать проблемы управления в виде настоящего романа.

Цитаты из этой книги я разбил на два сообщения, в этом сообщении я опубликую записи, который делал мистер Томпкинс в своей записной книжке, а отдельным сообщением я опубликую другие интересные цитаты.

Итак, перед вами целиком записная книжка мистера Томпкинса.

Глава 4. Четыре основных правила менеджмента

1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
(Все остальное - административная ерундистика.)

Глава 4. Безопасность и перемены

1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Глава 5. Отрицательная мотивация

1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Глава 6. Части тела, необходимые для управления проектами

1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу.

Глава 8. Повышение производительности

1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»

Глава 8. Управление рисками

1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Глава 9. Играй в защите

1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Глава 12. Сбор метрических данных

1. Определяйте размер каждого проекта.
2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Глава 15. Что дает давление сверху

1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.
3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком
сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Глава 16. Сердитый начальник

1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Глава 16. Туманные спецификации

1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к
рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

Глава 17. Конфликт

1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с
непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Глава 18. Кто такой катализатор проекта

1. Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Глава 18. Человеку свойственно ошибаться

1. Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

Глава 19. О персонале

1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Глава 20. Проблемы социологии

1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какая-то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т.п.
4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

Глава 21. О патологической политике (еще раз)

1. Эту патологию невозможно вылечить снизу.
2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Глава 22. Злоба и скупость

1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.

Глава 23. Основы здравого смысла

1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.

 

Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:

Часть 1. Из записной книжки мистера Томпкинса

Часть 2. Остальные цитаты

понедельник, 21 декабря 2009 г.

Роберт Гласс. Факты и заблуждения профессионального программирования

Facts_and_FallaciesСовсем недавно я дочитал книгу Роберта Гласса “Факты и   заблуждения профессионального программирования”. В целом, книга понравилась, интересное и качественное произведение. Мое развернутое мнение можно почитать на моем блоге.

Ну а здесь, как не сложно догадаться, понравившиеся цитаты.

В книгах о менеджменте (которые я читал), говорится, что на 95% он (менеджмент) состоит из здравого смысла и на 5% - из советов не первой свежести, перекочевавших из прошлого десятилетия.
Глава 1. О менеджменте

Успех или провал проекта в первую очередь зависит от того, кто выполняет работу, а не от того, как она выполняется.
Глава 1. О менеджменте

В создании ПО важен человеческий фактор. ... Свою роль играют инструментальные средства. Важны и методы. И процессы. Но роль людей намного более значима.
Факт №1. Обсуждение

Разработка ПО - это интенсивная умственная деятельность, и среда, в которой она проходит, должна способствовать мышлению. Теснота и вызванные ею помехи в работе (намеренные или нет) сказываются на результатах весьма пагубно.
Факт №4. Обсуждение

В нашей современной культуре принято во что бы то ни стало укладываться в сроки (невозможные), жертвуя ради этого завершенностью и качеством.
Факт №12. Источник

Управление, сосредоточенное на контроле, не обязательно делает проект лучшим или даже более производительным.
Факт №13. Обсуждение

Если код программной системы предстоит модифицировать на 20-25% или больше, то проще и дешевле начать все заново и создать новый продукт. Этот порог низок (на самом деле он удивительно низок).
Факт №19. Источники

Некоторые исследователи говорят, что переизбыток паттернов (попытка применить их в тех программах, для которых они не подходят) может привести к появлению "непонятного ...кода, ...декораций на фасадах, построенных фабричным способом".
Факт №20. Полемика

Каждые 25% увеличения сложности задачи обусловливают 100% увеличения сложности программного решения. И еще запомните, что против этого нет никакого противоядия. Программные решения сложны, поскольку такова их природа.
Факт 21. Обсуждение

Чаще всего проекты, выходящие из-под контроля, на самом деле никогда и не были управляемыми.
Факт 23. Обсуждение

Если в комнате сидят несколько классных проектировщиков ПО и двое из них согласны друг с другом, то они образуют большинство.
Факт 27. Обсуждение

В целом считается, что переход от проектирования к кодированию проходит гладко. И зачастую это так и есть - до тех пор, пока код пишет тот же человек, который проектировал приложение.
Факт 29. Обсуждение

Обычно от проектировщика ожидают, что он спустится на тот уровень, где единицы кодирования представляют собой так называемые примитивы - фундаментальные программные единицы, которые хорошо известны и легко программируются. Это звучит очень просто. Но на самом деле это упрощенный взгляд. Трудности обусловлены тем, что у разных людей разные наборы примитивов. Что является фундаментальной программной единицей для одного, может не быть таковой для другого.
Факт 29. Обсуждение

Полное покрытие структурным тестированием гарантирует обнаружение лишь 25% ошибок в программном продукте.
Факт 33. Обсуждение

Закон Линуса: все ошибки становятся заметными, если на них обращено достаточно много глаз - with enough eyeballs, all bugs are shallow.
Факт 34. Обсуждение

Процесс отладки - это детективный жанр программирования. Преследуя неуловимую программную ошибку, вы перевоплощаетесь в Шерлока Холмса. И подобно Шерлоку Холмсу, вы должны призвать на помощь свой интеллект и любые поддерживающие его и доступные вам средства.
Факт 36. Обсуждение

Самое трудное в сопровождении ПО - это понять, как работает уже имеющийся продукт.
Факт 44. Обсуждение

О качестве (ПО) мы говорим так: "Когда я его увижу, я пойму, что это оно".
Глава 3. О качестве

Такое ощущение, что придумывание лозунгов ("Качество - задача номер один!") и методологий ("Тотальное управление качеством") есть главное средство руководителей в деле обеспечения качества программного продукта. Все это чуждо техническим специалистам и настраивает их враждебно. Не помогает делу и то, что в роли главного врага качества в большинстве программных проектов выступают сроки. Одной рукой менеджмент мотивирует и внедряет методики, а другой - держит сроки, под давлением которых и гибнет качество. Нельзя, как говорится, "и на елку забраться, и ничего себе не расцарапать". А большинство технарей достаточно умны, чтобы понимать это.
Заблуждение 2. Обсуждение

Человеку свойственно предсказывать будущее, опираясь на опыт прошлого. В конце концов, нельзя точно предсказать будущее, глядя в него же. Поэтому мы исходим из предположения, что вероятные события будущего будут похожи на те события, которые уже произошли. Иногда это предположение оправдывается. На самом деле довольно часто. Но иногда оно не оправдывается совершенно.
Заблуждение 9. Обсуждение

Реальность - это убийство прекрасной теории бандой мерзких фактов.
Выводы

четверг, 17 декабря 2009 г.

Остаться в живых. Часть 2

Survival_Guide

Продолжение цитат из книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Успешный программный проект не содержит секретов. Как хорошие, так и плохие новости должны распространяться вверх и вниз по иерархии проекта без ограничений.
Глава 7. Общедоступность индикаторов развития

Лучше подождать, пока продуктивный программист не станет доступным, чем ждать, пока первый доступный программист не станет продуктивным
Глава 7. Новые разработчики: доступные и хорошие

Разработка и обеспечение качества не должны выполняться одними и теми же людьми. Ответственный за обеспечение качества играет роль "адвоката дьявола", которую трудно или невозможно совместить с деятельностью разработчиков.
Глава 7. Организация команды проекта

Используя лишь самых продуктивных разработчиков, руководители проекта способны свести их с ума постоянными отвлечениями от основной работы, существенно замедляющими развитие проекта.
Глава 7. "Команды тигров"

Самой трудной частью сбора требований является не запись пожеланий пользователей, а исследовательская деятельность, направленная на помощь пользователям в определении своих пожеланий.
Глава 8. Разработка требований

Объясните пользователям, что прототип - это "не более чем прототип". Один из рисков, связанных с созданием прототипа пользовательского интерфейса, состоит в появлении нереалистичных ожиданий пользователей по поводу будущего развития проекта.
Глава 8. Создание простого прототипа пользовательского интерфейса

Качество - это степень удовлетворения программным продуктом требований, как утвержденных официально, так и подразумеваемых.
Глава 9. Обеспечение качества

Для высококачественного программного продукта число тестировщиков должно равняться числу разработчиков.
Глава 9. Тестирование системы

Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.
Глава 9. Тестирование системы

Поскольку целью архитектуры является упрощение программного продукта, архитектор должен сконцентрировать свое внимание на том, что можно исключить из продукта, а не на том, что можно включить в него.
Глава 10. Подсистемы и организация

В погоне за лучшим вы рискуете остаться ни с чем. Придерживайтесь минимализма, простоты, удовлетворяйте все требования и не пытайтесь найти единственное идеальное решение.
Глава 9. Определение готовности архитектуры

Лучше работать разумно и много, чем неразумно много!
Глава 12. Если микровеховый план не выполняется

В зависимости от длительности и предметной области проекта, период после выпуска - хорошее время для того, чтобы предложить команде ланч, предоставить дополнительный выходной или вовсе отправить ее в оплачиваемый отпуск на Гавайи. Ну а на досуге следует сделать выводы из накопленного опыта и заложить основу для будущего успеха.
Глава 18. Хронология проекта

Поощрение команды никогда не приведет к провалу, а ее угнетение - к успеху.
Глава 19. Желательные действия

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2

Остаться в живых! Часть 1

Survival_Guide

Сегодня я решил опубликовать цитаты из книги Стива Макконнелла ""Остаться в живых! Руководство для менеджера программных продуктов". Книгу я читал уже довольно давно (года три назад) и тогда она на меня произвела двоякое впечатление. Первая часть книги, в которой автор сосредотачивается на общих сведениях, мне очень понравилась, а вот вторая, более конкретная, мне понравилась не очень сильно и я не решился применять советы автора на практике. Хотя у вас может быть и другое мнение:)

В целом, нужно сказать, что интересных мыслей в книге достаточно, о чем можно будет убедиться по цитатам. Цитат набралось много, поэтому я разбил их на две части.

На первой цитате я хочу остановиться подробнее. Во-первых, автором этой цитаты является не Стив Макконнелл, а Александр Милн, а во вторых, ее нельзя публиковать без рисунка, а в третьих, несмотря на то, что Милн, мягко говоря, не имеет никакого отношения к компьютерам, эта фраза имеет непосредственное отношение к разработке ПО.

pooh

Плюшевый медвежонок вслед за Кристофером Робином спускается по лестнице, считая затылком ступеньки - бум, бум, бум. Он знает - это единственный способ перемещаться с этажа на этаж, хотя иногда ему кажется, что должен быть и другой. И он бы догадался, что это за способ, если б его перестали колотить затылком о ступени и дали хоть чуточку подумать. Но чаще ему кажется, что никакого другого способа просто нет.

Об авторе

Исследователи обнаружили, что стоимость позднего исправления ошибки, внесенной в проект на ранней стадии (например, при формировании требований или архитектуры), в 50-200 раз выше, чем стоимость ее исправления сразу же после внесения.
Глава 3. "В начале потока" и "в конце потока"

Конус неопределенности задает ряд жестких предпосылок для оценки проектов. Так, он подразумевает, что на ранних стадиях проекта точно оценить проект не просто трудно, а теоретически невозможно. После окончания формирования требований область действия проекта будет зависеть от огромного числа решений на этапах создания архитектуры, детального проектирования и конструирования. Если кто-то берется оценить влияние этих решений до их принятия, то возможны два варианта: либо этот человек обладает даром предвидения, либо попросту плохо осведомлен о сущности программной разработки
Глава 3. Предпосылки для оценки проекта

В начале проекта вы можете определить для него либо фиксированные сроки и бюджет, либо фиксированный функциональный набор. Определить и то и другое одновременно - невозможно.
Глава 3. Предпосылки для оценки проекта

Добиться успеха в небольших проектах можно при благоприятном стечении обстоятельств простым напряжением силы воли, однако средние и крупные проекты требуют более систематического подхода
Глава 4. Навыки выживания

В некоторых организациях проблема финансирования программных проектов состоит в том, что менеджеры вынуждены делать запросы финансирования раньше, чем у них появляется возможность завершить значительную часть исследовательских работ. Такие запросы обречены на "промах", поскольку для осмысленного расчета оценок бюджета и сроков проекта о желаемом продукте известно слишком мало. Опыт программной индустрии свидетельствует о том, что оценки, создаваемые на ранних стадиях проектов, могут отличаться от действительных в большую или меньшую сторону до четырех раз.
Глава 4. Двухэтапный подход к финансированию

Любой участник среднего или крупного проекта не понаслышке знает, что очень многое в нем может пойти "не так"
Глава 4. Управление рисками

В силу загадочных для меня причин люди полагают, что можно контролировать проект, не выделяя для этой цели какую-то группу или отдельное лицо. Мое мышление и опыт говорят, что это невозможно
Глава 4. Контроль над проектом

Разработка программных продуктов требует творчества, интеллекта, инициативности, настойчивости и значительной степени внутренней мотивации. Любой эффективный подход к разработке программного обеспечения должен подразумевать, что в отсутствие интереса команды к проекту его успех сомнителен.
Глава 4. "Человеческое обеспечение"

Не пытайтесь мотивировать разработчиков эффективными выступлениями, недостижимыми результатами или денежными вознаграждениями
Глава 4. "Человеческое обеспечение"

Разработка программных продуктов - это процесс постоянных исследований и поиска, поэтому лучшая его поддержка - это спокойная обстановка, располагающая к размышлениям. Эффективная разработка программ требует от разработчиков такого же уровня концентрации, как от математиков или физиков. Можете ли вы представить Альберта Эйнштейна, сидящего за рабочим столом, вокруг которого ходит менеджер и раздраженно повторяет: "Альберт, теория относительности нужна нам прямо сейчас! Поторопись!"
Глава 4. "Человеческое обеспечение"

Работа среднестатистического менеджера требует переключения внимания каждые несколько минут. Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов.
Глава 4. "Человеческое обеспечение"

С точки зрения сложности компонентов программного продукта и их функциональности, успешная разработка проекта подчиняется принципу "чем меньше, тем лучше", действующему на всех этапах - от формирования требований до выпуска. Поскольку разработка программного продукта требует значительных интеллектуальных усилий, становится важно, чтобы участники проекта активно способствовали его максимальному упрощению, избавляя проект от излишней сложности.
Глава 4. Минимализм продукта

Французский писатель Вольтер говорил, что рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть. Этот подход применим и к программному проекту.
Глава 4. Минимализм продукта

Эффективные проекты контролируют изменения; неэффективные проекты находятся под контролем изменений.
Глава 6. Стрельба по движущейся цели

Хорошо организованные проекты неизбежно ищут компромисс между функциональным набором, бюджетом и расписанием
Глава 7. Цели в области действия проекта

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2

среда, 16 декабря 2009 г.

Голосование: Нужен ли рисунок с обложкой книги в начале сообщения с циатами?

Уважаемые, читатели. У меня к вам вопрос: нужно ли в начале сообщения с цитатами вставлять рисунок с обложкой?
Я создал голосование, но т.к. большинство пользуется различного рода ридерами, то на главную страницу форума попадают редко, поэтому я прошу вас обратить на это внимание.
Можно обсуждать здесь, а можно просто проголосовать на главной странице блога.

понедельник, 14 декабря 2009 г.

Джеймс Коплиен. Программирование на С++

Хотя книга Джеймса Коплиена “Программирование на С++. Классика CS” вышла уже более 15 лет назад, в ней находится немало количество интересных, способных заинтересовать современного программиста.
Более подробно об этой книге я писал на своем блоге, ну а здесь сосредоточатся исключительно цитаты.
 
Синтаксис языка до определенной степени формирует наше восприятие, но простое описание синтаксиса в "руководстве пользователя" станет всего лишь отправной точкой. Структура наших программ (а следовательно, и тех систем, которые мы строим) в основном определяется стилем и идиомами, используемыми для выражения архитектурных концепций.
Стиль отличает истинное мастерство от простой удачи. Эффективный стиль воспитания ребенка, программирования и вообще всего на свете строится на основе личного опыта или опыта других. Программист, который умеет правильно связывать возможности языка программирования с потребностями приложения, пишет превосходные программы. Но чтобы выйти на этот уровень, необходимо от правил и механического запоминания перейти к идиомам и стилю, а в конечном счете - к концептуальным и структурным абстракциям.
Предисловие. Изучение языка программирования

Изучение языка программирования имеет много общего с изучением естественного языка. Знание базового синтаксиса позволяет программисту писать простые процедуры и строить из них нетривиальные программы - подобно тому, как человек со словарным запасом в несколько тысяч иностранных слов способен написать нетривиальный рассказ. Но настоящее мастерство - совсем другое дело. Рассказ может быть нетривиальным, но от этого он не станет читаться "на одном дыхании", подчеркивая свободу владения языком его автора. Изучение синтаксиса и базовой семантики языка сродни 13-часовым курсам немецкого для начинающих: после прохождения таких курсов вы сможете заказать колбаски в ресторане, но для работы в Германии журналистом или поэтом их наверняка окажется недостаточно. Различие кроется в идиоматике языка.
Предисловие. Изучение языка программирования
 
В программировании, как и в естественных языках, пригодность и выразительность языковых конструкций базируется на важных идиомах. Хорошие идиомы упрощают работу прикладного программиста, подобно тому как идиомы любого языка обогащают общение. Программные идиомы являются "выражениями" семантики программирования, пригодными для многократного использования в том же смысле, в котором классы служат для многократного использования архитектурных решений и кода. В программировании, как и в естественных языках, пригодность и выразительность языковых конструкций базируется на важных идиомах. Хорошие идиомы упрощают работу прикладного программиста, подобно тому как идиомы любого языка обогащают наше общение. Программные идиомы являются "выражениями" семантики программирования, пригодными для многократного использования в том же смысле, в котором классы служат для многократного использования архитектурных решений и кода.
Предисловие. Изучение языка программирования
 
Как сказал Страуструп, хорошие навыки программирования и проектирования являются результатом личного вкуса, проницательности и опыта.
Глава 1. Проектирование и язык
 
Принцип замещения Барбары Лисков: ...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в контексте T, поведение P не изменяется при замене o1 на o2, то S является базовым типом для T.
Глава 6. Случайное наследование – омонимы в мире типов

Мифический человеко-месяц. Радости профессии

Один из комментариев к первой части цитат книги Фредерика Брукса “Мифический человеко-месяц” навела на мысль, что одной цитаты из раздела “Радости профессий” недостаточно. Но этот раздел настолько потрясен, что я думаю будет не лишним выделить его в отдельное сообщение.

Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
      Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг - отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
      Во-вторых, это удовольствие создавать вещи, которые могут быть полезны другим людям. Глубоко в душе мы испытываем потребность в том, чтобы другие использовали результаты нашего труда и считали их полезными. В этом отношении программная система по своей сути - то же, что и изготовленная ребенком подставка для карандашей "папе в подарок".
      В-третьих, это очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей и наблюдения за их работой, круг за кругом демонстрирующей результаты изначально заложенных принципов. Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.
      В-четвертых, это радость, получаемая от неизменного узнавания нового, проистекающего из неповторимой природы задачи. В том или ином отношении задача всегда ставится по-новому, и тот, кто ее решает, получает новые знания - либо практические, либо теоретические, либо те и другие вместе.
      Наконец, наслаждение доставляет работа со столь податливым материалом. Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов. (Как мы позднее увидим, такая податливость таит свои проблемы.)
      Однако программная конструкция, в отличие от поэтических творений, реальна, в том смысле, что она движется и работает, производя видимые результаты, которые отделимы от самой конструкции. Она печатает результаты, рисует картинки, производит звуки, приводит в движение рычаги. В наше время осуществилось волшебство мифа и легенды. С клавиатуры вводится верное заклинание, и экран монитора оживает, показывая то, чего никогда не было и не могло быть.
      Таким образом, программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.

Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:

Часть 1

Часть 2

Радости профессии

воскресенье, 13 декабря 2009 г.

Программист-прагматик. Часть 6. Управление проектами

Помимо философских высказываний, в книге Дейва Томаса и Энди Ханта можно найти немало полезной информации и по управлению проектами.

Поскольку вы не работаете в безвоздушном пространстве, вам необходимо уметь общаться. Чем эффективнее это общение, тем более влиятельным вы становитесь.
Глава 1. Обращайтесь к людям

Одной из интересных особенностей оценки является тот факт, что интерпретация ее результата зависит от используемых вами единиц измерения. Если вы говорите, что для некоего действия потребуется 130 рабочих дней, то люди будут ожидать наступления этого события в достаточно узком интервале. Но если вы скажете «около шести месяцев», они будут знать, что этого события следует ожидать чрез 5-7 месяцев. Обе цифры обозначают одну и ту же продолжительность, но «130 дней», вероятно, подразумевает большую точность, чем вы полагаете.
Глава 2. Насколько точной является “приемлемая точность”?

Что сказать, если вас просят оценить что-либо?
Говорите: «Я вернусь к вам с этим позже».
Вы почти всегда можете добиться лучших результатов, если не будете торопиться… К оценкам, сделанным на ходу (например, у офисной кофеварки), придется возвращаться вновь и вновь (как, впрочем, и к кофе), теряя при этом покой.
Глава 2. Что сказать, если вас просят оценить что-либо

Всегда используйте управление исходным текстом программы
Всегда. Даже если ваша команда состоит из одного человека и продолжительность проекта составляет одну неделю. Даже если это прототип на выброс. Даже если материал, с которым вы работаете, не является исходным текстом программы. Убедитесь, что все находится под контролем – документация, номера телефонов, записки поставщикам, сборочные файлы, процедуры сборки и выпуска, крохотный сценарий (в оболочке), прожигающий эталонный компакт-диск, словом – все.

Глава 3. Управление исходным текстом программ

Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания "Пасторальной симфонии". Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Не собирайте требования – выискивайте их
Глава 7. Карьер для добычи требований

Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Глава 7. В поисках требований

Очень сложно создать успешный проект, в котором пользователи и разработчики обращаются к одному и тому же предмету под разными именами или, что еще хуже, обращаются к разным предметам, используя одно и тоже имя.
Глава 7. Поддержка глоссария

Однажды царь Фригии Гордий завязал узел, который никто не мог развязать. Было предсказано, что тот, кто сможет развязать его, станет властелином всей Азии. И вот пришел Александр Македонский, который разрубил узел своим мечом. Несколько иная интерпретация требований и все – он стал властителем всей Азии.
Глава 7. Разгадка невероятных головоломок

Не забывайте, что формальные методы разработки – это лишь один инструмент из вашего арсенала. Если после тщательного анализа вы почувствуете, что вам необходим формальный метод, берите его на вооружение, но помните, что несете ответственность. Никогда не становитесь рабом методологии, ведь кружки и стрелки обедняют своих хозяев. Прагматики смотрят на методологии критическим взглядом, затем берут лучшее из каждой и преобразуют их в набор практических технологий, который улучшается каждый месяц. Это является решающим моментом. Вы должны постоянно работать над усовершенствованием процессов. Никогда не делайте жесткие рамки методологии границами вашего собственного мира.
Глава 7. Должны ли мы использовать формальные методы?

Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Глава 8. Генерирование web-сайта

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 5. Тестировние и отладка


Тестирование и отладка занимает в книге достойное место. Книга не заменит специализированную литературу по отладке, но все же будет полезна многим разработчикам.
 
Английское слово bug (ошибка) используется для описания "объекта, вызывающего ужас" уже начиная с XIV века. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказалась первой, кто наблюдала компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе "завелся жучок", и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.
Глава 3. Отладка
 
Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: "А вот и я!".*
Звучит просто, но разъясняя проблему вашему собеседнику, вы должны явно заявить о тех вещах, которые считаете само собой разумеющимися при просмотре текста вашей программы. Поскольку вам приходится озвучивать некоторые из этих положений, вы можете по-новому взглянуть на суть данной проблемы – неожиданно для самого себя.
* Почему "резиновый утенок"? Один из авторов книги, Дэйв Хант, учился в лондонском Империал колледже и много работал совместно с аспирантом, которого звали Грег Паг и которого Д. Хант считает одним из лучших известных ему разработчиков. На протяжении нескольких месяцев Грег носил при себе крохотного желтого резинового утенка, которого он ставил на край монитора во время работы. Прошло некоторое время, пока Дэйв не отважился спросить…
Примечание: один очень известный bug-slayer (речь идет о Джоне Роббинсе), считает, что лучшие отладчики – это кошки, а не утята… Но это уже, скорее, дело вкуса :-)
Глава 3. Рассказ о резиновом утенке
 
Вероятно, ошибка кроется в операционной системе, компиляторе или продукте независимого производителя – но это не должно быть первой мыслью, приходящей вам на ум. Скорее всего, ошибка существует в тексте разрабатываемого приложения. Обычно выгоднее полагать, что прикладная программа некорректно обращается к библиотеке, нежели то, что нарушена сама библиотека. Даже если проблема заключается в продукте независимого производителя, то перед тем, как представлять отчет об ошибках, вам в любом случае надлежит исключить ошибки в вашей собственной программе.
Глава 3. Процесс исключения
 
 
Если ваша программа обнаруживает, что произошло событие, которое считалось невозможным, программа теряет жизнеспособность. Начиная с этого момента, все действия, которые она совершает, попадают под подозрение, так что выполнение программы необходимо прервать как можно быстрее. В большинстве случаев мертвая программа приносит намного меньше вреда, чем испорченная.
Глава 4. Аварийное завершение не означает “отправить в корзину для мусора”
 
Предположим, Фреду дано задание написать программу. Фред составляет некую программу, пробует ее запустить, и она вроде бы работает. Фред пишет еще один фрагмент, пробует его запустить, и снова все работает. В такой обстановке проходит еще несколько недель, но внезапно программа прекращает работать, и, потратив несколько часов на устранение дефекта, Фред все еще не знает, в чем причина. Фред может потратить много времени, копаясь с этим фрагментом, без перспективы на восстановление работы программы. И что бы он ни делал, кажется, что программа никогда не будет работать правильно.
Фред не знает, почему программа сбоит, потому что не знает, почему она работала вначале. Она лишь казалась работающей в условиях ограниченного «тестирования», которое проводил Фред, но это было лишь стечением обстоятельств. Находясь в плену ложной уверенности, Фред впал в забытье. Большинству интеллектуалов знаком этот образ Фреда, но мы знаем его лучше. Мы ведь не полагаемся на стечение обстоятельств, не так ли?
Глава 6. Программирование в расчете на стечение обстоятельств

Тестируйте ваши программы, в противном случае это сделают ваши пользователи
Глава 6. Культура тестирования
 
Большинство разработчиков ненавидят тестирование. Они стремятся тестировать осторожно, подсознательно ощущая, в каком месте программа может сбоить, и избегая слабых мест.
Глава 8. Безжалостное тестирование
 
Несоответствие критериям удобства использования является дефектом такого же порядка, как деление на ноль.
Глава 8. Тестирование удобства использования

Если тестировщик обнаруживает дефект, это должно быть в первый и последний раз – обнаружение дефекта человеком. Автоматизированные тесты должны быть модифицированы для проверки наличия этого дефекта, начиная с момента его первоначального обнаружения, всякий раз, без каких-либо исключений, не обращая внимания на степень тривиальности, жалобы разработчика и его фразу "Этого больше не случится".
Глава 8. Кольцо сжимается

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Программист-прагматик. Часть 4. Проектирование

Проблема сцепления (cohesion) и связности (coupling) беспокоит архитекторов в самых различных областях уже много лет; в области разработки ПО эта тема поднималась еще Эдвардом Йордоном и Ларри Константайном тридцать лет назад. И хотя тема построения слабосвязного ПО не является единственной темой по проектированию ПО, именно она проходит красной нитью через всю книгу “Программист-прагматик”.

Термин «ортогональность» заимствован из геометрии. Две линии являются ортогональными, если они пересекаются под прямым углом, например оси координат на графике. В терминах векторной алгебры две такие линии являются независимыми. Если двигаться вдоль одной из линий, то проекция движущейся точки на другую линию не меняется.
Этот термин был введен в информатике для обозначения некой разновидности независимости или несвязанности. Два или более объекта ортогональны, если изменения, вносимые в один из них, не влияют на любой другой.
Глава 2. Что такое ортогональность?

Ничто не вечно, и если вы всерьез полагаетесь на некоторое явление, то этим вы практически гарантируете, что оно непременно изменится.
Глава 2. Обратимость

Вместо того, чтобы высекать решения на камне, рассматривайте их так, как будто они начерчены на морском песке. В любой момент может накатить волна и смыть их.
Глава 2. Обратимость

Перед тем как вы займетесь созданием любого прототипа, основанного на программе, убедитесь, что все понимают – вы пишите одноразовую программу. Прототипы могут быть обманчиво привлекательными для людей, которые не знаю, что это всего лишь прототипы. Вы должны очень четко уяснить – эта программа одноразовая, незавершенная и не может быть завершена.
Легко впасть в заблуждение из-за очевидной завершенности демонстрационного прототипа, и спонсоры проекта или менеджмент могут настаивать на развертывании прототипа (или его потомства), если вы заранее не определите, что можно ожидать от прототипа. Напомните им, что вы, конечно, можете создавать великолепный прототип новой модели автомобиля из бальзовой древесины и клейкой ленты, но вы же не поедете на нем в час пик!

Глава 2. Как не надо использовать прототипы

Жизнь не стоит не месте.
Не могут стоять на месте и программы, которые мы пишем. Чтобы не отставать от сегодняшнего, близкого к кошмару, темпа изменений, необходимо приложить все усилия для написания программ слабосвязанных и гибких, насколько это возможно. В противном случае мы придем к тому, что наша программа быстро устареет или станет слишком хрупкой, что не позволит устранять ошибки, и может в конечном итоге оказаться в хвосте сумасшедшей гонки в будущее.

Глава 5. Гибкость против хрупкости

Шпионы, диссиденты, революционеры и им подобные часто организованы в небольшие группы, называемые ячейками. Хотя отдельные личности в каждой ячейке могут знать друг о друге, они не знают ничего об участниках других ячеек. Если одна ячейка раскрыта, то никакое количество "сыворотки правды" неспособно выбить из ее участников информацию об их сподвижниках вне пределов ячейки. Устранение взаимодействий между ячейками убережет всех.
Мы полагаем, что этот принцип хорошо бы применить и к написанию программ. Разбейте вашу программу на ячейки (модули) и ограничьте взаимодействие между ними. Если один модуль находится под угрозой и должен быть заменен, то другие модули должны быть способны продолжить работу.

Глава 5. Несвязанность и закон Деметера

Когда мы запрашиваем у объекта определенную услугу, то мы хотим, что бы эта услуга оказывалась от нашего имени. Мы не хотим, чтобы данный объект предоставлял нам еще какой-то объект, подготовленный третьей стороной, с которым нам придется иметь дело для получения необходимой услуги.
Глава 5. Сведение связанности к минимуму

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 3. Инструменты

Многие авторы говорят о важности инструментов, но так, как об этом сказали Хант и Томас не может написать никто. Мне эта мысль авторов настолько понравилась, что я решил выделить ее в отдельное сообщение.

Каждый ремесленник отправляется на поиски заработка, имея при себе походный набор инструментов. Столяру могут пригодиться линейки, шаблоны, пара ножовок, несколько рубанков, тонкие стамески, сверла и зажимы, киянки и струбцины. Эти инструменты он будет тщательно выбирать и настраивать, каждому из них будет уготована определенная работа, и, что наверное самое важное, каждый из них, оказавшись в умелых руках столяра, найдет свое место под солнцем.
После этого придет черед обучению и притирке. Каждому инструменту будут присущи свои особенности (и хитрости), и каждый из них потребует, чтобы с ним обращались по-своему. При работе столяр держит каждый инструмент особым образом и затачивает его под особым углом. Пройдет время, и от работы инструмент износится до того, что рукоятка превратится в слепок руки столяра, а режущая поверхность сравнится с углом, под которым столяр держит инструмент относительно рабочей плоскости. В этот момент инструменты станут проводниками идей от головы столяра к конечному продукту – они станут продолжением рук мастера. Со временем в арсенале столяра прибавятся новые орудия – резальные машины, лазерные станки для резки под углом, направляющие шаблоны "ласточкин хвост" – все это чудеса технологического прогресса. Но можно поспорить, что по-настоящему столяр счастлив только тогда, когда держит в руках инструмент из старого походного набора и слышит, как рубанок поет свою песню, выстругивая деревянную заготовку.
Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать. Начните с походного универсального набора инструментов. По мере того как вы приобретаете опыт и сталкиваетесь с специальными требованиями, ваш набор пополняется. Стоит уподобиться ремесленнику и пополнять набор регулярно. Старайтесь не прекращать поисков лучшего способа сделать что-либо. Оказавшись в ситуации, когда вы обнаруживаете, что ваших инструментов недостаточно, поищите иное, возможно, более мощное средство для осуществления задуманного. Ваши приобретения должны исходить из существующей необходимости.
Глава 3. Походный набор инструментов

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 2. Дублирование информации

Это вторая часть цитат из книги Энди Ханта и Дейва Томаса “Программист-прагматик. Путь от подмастерья к мастеру”.

Тема дублирования информации занимает в книги авторов значительное место, поэтому я решил выделить цитаты по этой теме в отдельное сообщение.

Принцип “Не повторяй себя” (DRY – Don’t Repeat Yourself):
Каждый фрагмент знания должен иметь единственное однозначное, надежное представление в системе
Глава 2. Пороки дублирования

Если меняется одно, придется вспомнить и об изменении других, или же ваша программа будет поставлена на колени ввиду противоречий. Вопрос не в том, вспомните ли вы о необходимом изменении или нет; вопрос в том, когда вы об этом забудете.
Глава 2. Пороки дублирования

Программистов учат комментировать создаваемый ими текст программы: удачный текст программы снабжен большим количеством комментариев. К сожалению, им никогда не объясняли, зачем тексту программы нужны комментарии: неудачному тексту требуется большое количество комментариев.… Комментарии неизбежно устаревают, а ненадежные комментарии хуже, чем отсутствие комментариев вообще.
Глава 2. Навязанное дублирование

Вы пишите документацию, затем создаете текст программы. Что-то меняется, и вы исправляете документацию и обновляете текст программы. Что-то меняется, и вы исправляете документацию и обновляете текст. И документация, и текст содержат представления одного и того же знания. И все мы знаем, что в суматохе, когда приближается контрольный срок, а важные заказчики высказывают требования, обновление документации стараются отложить.
Глава 2. Навязанное дублирование

Каждый проект испытывает давление времени – силы, которая может двигать лучшими из нас, заставляя идти напролом.
Глава 2. Нетерпеливое дублирование

Все, что вы пытаетесь делать, способствует развитию среды, где проще находить и многократно использовать существующий материал, чем создавать его самому. Но если это непросто (имеется ввиду непросто повторно использовать существующий код), люди просто не будут этого делать. И если вы будете не в состоянии многократно использовать этот материал, вы рискуете заняться дублированием знаний.
Глава 2. Коллективное дублирование

Программа должна иметь комментарии, но слишком большое их количество может быть так же плохо, как и малое.
В общем, комментарии должны обсуждать, почему выполняется та или иная операция, ее задачу и ее цель. Программа всегда демонстрирует, как это делается, поэтому комментирование – избыточная информация и нарушение принципа DRY.
Глава 8. Комментарии в программе

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 1. Философия программирования

Сегодня я хочу опубликовать цитаты из замечательной книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”. Это одна из наиболее цитируемых и популярных книг в компьютерной индустрии, популярность которой обусловлена потрясающим стилем изложения и, что самое главное, огромным количество умных мыслей.

Мое более развернутое мнение можно посмотреть на моем блоге или на сайте rsdn.ru.

В предыдущих сообщениях, если в книге встречалось слишком большое количество цитат, я разбивал на части таким образом, чтобы в первой части была первая часть книги, а во второй части – вторая и т.д.. В этой книге цитат особенно много, но в отличие от других книг они покрывают разную тематику. Поэтому я разбил цитаты по темам, но т.к. философия программирования занимает центральное место книги, этой теме посвящено целых три части (части 2 и 3 относятся к философии программирования).

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Итак, начнем. Часть 1. Философия программирования.

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

Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологий заверяют в том, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей.
Разумеется, эти утверждения неверны. Простых ответов не существует. Не существует такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существует лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств.
И в этот момент на сцену выходит прагматизм. Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширным, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.
От авторов

Авторы призывают вас во время работы думать только о работе – только так вы останетесь программистом-прагматиком. Это не случайная оценка существующей практики, а критическая оценка каждого принимаемого вами решения – в течение каждого рабочего дня и по каждому проекту. Никогда не пользуйтесь автопилотом. Думайте постоянно, критикуя свою работу в реальном масштабе времени. Старый девиз фирмы IBM “ДУМАЙ!” является своего рода мантрой для программиста-прагматика.
Думай! О своей работе

Во время экскурсии по Итонскому колледжу в Англии турист спросил садовника, как ему удается содержать лужайки в столь идеальном состоянии. «Это несложно, - ответил садовник, вы просто стряхиваете росу каждое утро, выкашиваете лужайку через день и утрамбовываете раз в неделю».
«И это все?» - спросил турист.
«Абсолютно все, - ответил садовник, - если заниматься этим на протяжении 500 лет, то ваша лужайка будет не хуже».
Великие лужайки, как и великие программисты, нуждаются в ежедневном уходе. В ходе беседы консультанты в области менеджмента не преминут вставить японское слово «кайдзен». «Кайдзен» - японский термин, означающий политику непрерывного внедрения большого количества мелких усовершенствований. Считается, что «кайдзен» стала одной из основных причин резкого роста производительности и качества в японской промышленности, и эту политику стали применять во многих странах. «Кайдзен» применима и к отдельным личностям. Каждый день необходимо работать, оттачивая свои навыки и добавляя в свой репертуар новые произведения. В отличие от итонских газонов, для достижения результата потребуются дни. Годы спустя вы будете поражаться своему преуспеванию и карьерному росту.
От авторов. Непрерывность процесса

Некоторые здания, расположенные в старых кварталах города, находятся в хорошем состоянии и чистоте, тогда как другие представляют собой жуткие развалины. Почему? Исследователи в области преступности и упадка больших городов открыли удивительный механизм, запускающий процесс быстрого превращения чистенького, нетронутого жилого дома в полуразрушенную и заброшенную трущобу.
Причина – одно-единственное разбитое окно.
Одно разбитое окно, стекло в котором не меняется в течение длительного времени, развивает в обитателях здания ощущение заброшенности – ощущение, что властям нет дела до того, что происходит со зданием. Затем разбивается другое окно. Люди начинают мусорить. На стенах появляются похабные надписи. Возникают серьезные повреждения строительной конструкции. За относительно короткое время здание портится, несмотря на стремление владельца отремонтировать его, и ощущение заброшенности становится реальностью.
«Теория разбитого окна» дала полицейским участкам в Нью-Йорке и других больших городах стимул: навалиться всем миром на решение малых проблем ради сдерживания больших. И это срабатывает: сосредоточение усилий на первоочередном решении проблем разбитых окон, похабных надписей и других малых правонарушений привело к сокращению уровня тяжких преступлений.
Глава 1. Энтропия в программах

понедельник, 7 декабря 2009 г.

Человеческий фактор. Успешные проекты и команды. Часть 2

Результат любого предприятия скорее зависит от того, кто делает работу, а не от того, как она делается. Однако современная теория управления почти не обращает внимания на поиск и сохранение подходящих людей. На какие бы курсы по управлению вы ни пошли, вы мало что услышите об этом.
Теория управления намного больше интересуется ролью начальника как главного стратега и тактика предприятия. Вас учат, что руководить – все равно что играть в военную настольную игру. В такой игре нет необходимости считаться с личностями или отдельными талантами; победа или поражение зависит от ваших решений, где и когда расставить свои безликие пешки
Часть 3. Подходящие люди

Слово непрофессиональный  часто употребляется для обозначения неожиданного и угрожающего поведения. Все, что может обеспокоить слабого руководителя, непрофессионально почти по определению. Так что попкорн – это непрофессионально. Длинные волосы – непрофессионально, если растут на мужской голове, но совершенно приемлемо, если на женской. Плакаты любого вида – это непрофессионально. Удобная обувь – непрофессионально. Танцы вокруг стола, когда происходит что-то хорошее, – непрофессионально. Хихикать и смеяться – непрофессионально. (Улыбаться можно, но не слишком часто.)
Глава 14. Кодовое слово: Профессионализм

Наш бизнес не столько технологический, сколько социологический, он больше зависит от способностей сотрудников общаться между собой, чем от их способности общаться с машинами. Поэтому в процессе найма необходимо уделять главное внимание хотя бы некоторым аспектам социологии и человеческого взаимодействия
Глава 15. Организация проб

Мы избегаем измерения текучки по той же причине, по которой заядлые курильщики избегают долго и всерьёз беседовать со своими докторами о долголетии: много хлопот, а в результате все равно плохие новости
Глава 16. Счастливы работать здесь

В наших организациях более всего раздражает, что они хороши лишь настолько, насколько хороши люди, набирающие в них сотрудников
Глава 17. Тайный смысл Методологии

Объемная документация - часть проблемы, а не часть решения
Глава 17. Безумие Методологии

Ничто не может лишить сотрудников мотивации настолько эффективно, насколько это сделает осознание ими того факта, что руководство считает их некомпетентными
Глава 17. Безумие Методологии

Испытывая недоверие со стороны начальства, люди не слишком склонны объединяться в команду
Глава 20. Оборонительная позиция руководства

Типичные шаги, направленные на ускорение сдачи продукта, обычно приводят к снижению качества
Глава 20. Снижение качества продукта

Определенно существуют случаи, когда сжатые, но не запредельно, сроки могут быть для команды приятным вызовом. Но что никогда не будет полезным, так это идиотские сроки сдачи
Глава 20. Идиотские сроки сдачи

Большинство организаций не стремятся к разрушению команд сознательно. Просто они так себя ведут
Глава 20. И опять на ту же грустную тему

Успех порождает успех, а продуктивная гармония - еще более продуктивную гармонию
Глава 21. Что здесь происходит?

Лучший успех – тот, в котором нет очевидного участия руководства, а команда работает как содружество равных. Лучший начальник – тот, кто может повторять это раз за разом, не давая участникам команды догадаться, что ими «руководят». Таких руководителей их собственные коллеги считают просто удачливыми. У них все получается словно само собой. У них есть команды, рвущиеся в бой, проекты, быстро набирающие ход, и до самого конца все вокруг такого руководителя работают с энтузиазмом. Эти руководители никогда не напрягаются. Выглядит все настолько просто, что никто не верит, что они вообще руководят.
Глава 21. Что здесь происходит?

Визуальное наблюдение просто смешно для сотрудников проекта по разработке. Визуальное наблюдение - это для заключенных
Глава 22. Освобождающие уловки

Между превосходным ремесленником и подмастерьем существует связь естественного авторитетного характера – учитель знает, как делать работу, а ученик – нет. Подчинение такому авторитету не роняет ничьего достоинства, не исключает инициативу, не делает невозможным установление связей с коллегами. Неуверенность, требующая повиновения, есть полная противоположность естественному авторитету. Она гласит: «Я существо другой касты, я руководитель. Я принадлежу к классу мыслящих. Мои подчинённые наняты лишь для того, чтобы выполнять мои решения».
Глава 22. Кто здесь главный?

Команда - это сеть, а не иерархия. Несмотря на уважение к понятию лидерства (культовое слово в нашей области), лидерству здесь просто нет места.
Глава 23. Сетевая модель поведения команды

Где-то в глубинах нашей родовой памяти затаилась мысль, что работа должна быть в тягость. Если вам нравится делать что-либо, это уже не работа. Если вам это очень нравится, то это, должно быть, греховное занятие. Вам не следует этим заниматься слишком много, а может быть, и вообще. А уж платить за это вам точно не следует. Вам, наверное, следует найти что-то другое, что больше похоже на работу. Тогда вы будете уставать, скучать и вообще будете несчастны – как все остальные.
Часть 5. Удовольствие от работы? Здесь?

Препятствуйте критическим замечаниям вроде "Это дурацкая идея", поскольку дурацкие идеи часто наводят других людей на умные мысли.
Глава 24. Мозговой штурм

Здравый смысл и порядок - несомненно, желанные составляющие рабочего дня. Но еще остается время для приключений, глупостей и небольших доз созидательного беспорядка.
Глава 24. Обучение, путешествия, конференции, торжества, отдых

Социология имеет большее значение, чем технология или даже деньги. Работа должна приносить продуктивное удовлетворение. Если работа не приносит радости, ничто другое уже не стоит внимания.
Глава 26. Как пробудить Хольгера

Люди ненавидят перемены…

Дело в том, что люди ненавидят перемены…

Я хочу убедиться, что вы меня поняли.

Люди действительно ненавидят перемены.

Очень сильно ненавидят.
                            Стив Мак – Менамин ( Steve McMenamin ) The Atlantic Systems Guild
Глава 30. Как сделать перемены возможными

И следует учесть, нет занятия более сложного, более сомнительного в перспективе, более опасного, чем быть во главе новых порядков. Врагами тебе становятся все те, кому на руку прежние порядки, а робкими защитниками – все те, кто может получить выгоду от новых.
                            Никколо Макиавелли «Государь» (1513)
Глава 30. А теперь послушаем другого знаменитого системного консультанта

Основная реакция на перемены не логическая, но эмоциональная.
Глава 30. Классная идея, босс. Займусь немедленно

Неспособный измениться никогда не станет лучше.
                                                      - Том Демарко (1997)
Глава 30. Классная идея, босс. Займусь немедленно

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

Предприятия интеллектуальной сферы должны осознавать, что именно вложения в человеческий капитал важнее всего. Хорошие компании давно это поняли
Глава 31. Под дудку Уолл-стрит

Обучение ограничено способностью организации сохранять своих людей
Глава 32. Опыт и обучение

Дробление особенно вредоносно, когда две задачи требуют качественно различных рабочих привычек. Так, смешивание проектирования (требующего много времени на погружение, относительной тишины и качественного времени взаимодействия с небольшой группой людей) с задачей поддержки по телефону (требующей постоянного прерывания, постоянной доступности, быстрой смены фокуса) гарантированно минимизирует ход работы над той из задач, которая требует большего сосредоточения.
Глава 33. Снова дробление

Человеческий фактор. Успешные проекты и команды. Часть 1

Сегодня я хочу опубликовать цитаты из замечательной книги Тома Демарко и Тимоти Листера "Человеческий фактор: успешные проекты и команды" (рецензия на моем блоге и сайте rsdn.ru). Как и книга Фредерика Брукса, эта книга произвела на меня сильное впечатление и является одной из самых любимых в библиотеке компьютерной литературы. В очередной раз перелистывая ее, понимаешь, насколько много в ней интересных мыслей и насколько эти мысли редко доходят до нужных голов и еще реже воплощаются на практике.

Из-за огромного количества, цитаты этой книги я также разбил на два сообщения, примерно пополам.

Серьёзные проблемы в нашей работе имеют не столько технологическую сколько социологическую природу.  
Глава 1. Суть вопроса

Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
Глава 1. Миражи высоких технологий

Если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на тёмной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».
Глава 1. Миражи высоких технологий

Нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.
Глава 2. Менеджмент, простецкое определение

Вена, которая, по словам Билли Джоэла, ждёт тебя, – это последняя остановка на твоём жизненном пути. Когда ты окажешься там, все будет кончено. Если вам кажется, что участников проекта никогда не интересуют такие серьёзные вещи, подумайте получше. Ваши люди очень остро понимают, что человеку дана лишь одна короткая жизнь, и они слишком хорошо знают, что в этой жизни должно быть что-то поважнее, чем их глупая работа.
Глава 3. Письмо из дома

Сверхурочные сотрудников, сидящих на окладах, – это плод воображения наивного руководителя. Да, в паре лишних субботних часов, позволяющих уложиться в сроки и сдать проект в понедельник, может быть очевидная польза, но за ними всегда следует равносильный период компенсации, сокращения рабочего времени, позволяющий сотрудникам вернуться в ритм привычной жизни. В конечном итоге каждый час сверхурочных компенсируется часом недоработки. В краткосрочной перспективе такой компромисс может принести пользу проекту, но в долгосрочной польза нивелируется.
Глава 3. Сверхурочные не существуют

Сверхурочные похожи на спринт: он имеет смысл на последней стометровке марафонской дистанции для тех людей, у которых ещё остались силы, но если начать спринт на первом километре, вы только зря потеряете время. Если заставлять людей постоянно бежать в темпе спринта, они лишь потеряют уважение к руководителю. Лучшие из сотрудников уже все это проходили – они будут молчать и закатывать глаза, пока руководитель бредит, что эту работу просто необходимо закончить к апрелю. После этого они воспользуются компенсирующими недоработками и в конечном итоге каждую неделю будут работать не более сорока часов. Так реагируют лучшие; все остальные – просто трудоголики.
Глава 3. Сверхурочные не существуют

Осознание того, что большие ценности (семья, любовь, дом, молодость) принесены в жертву меньшим (работа), разрушительно. Оно заставляет человека, совершившего столь глупую жертву, искать отмщения. Он не пойдёт к шефу, чтобы спокойно и вдумчиво объяснить, что положение вещей должно измениться; он просто уйдёт – ещё один человек, который сгорел на работе. Так или иначе, его больше не будет.
Глава 3. Трудоголики

В личной жизни причины эмоциональных реакций многочисленны и разнообразны, но на рабочем месте главным источником душевных потрясений является самооценка, находящаяся под угрозой.
Глава 4. Качество? Если успеем

«Рынку абсолютно плевать на такой уровень качества». Прочтите эти слова и прослезитесь, потому что они почти всегда правдивы. Люди могут с пеной у рта говорить о качестве и горько жаловаться на его отсутствие, но когда приходит время платить за качество, их действительные ценности выходят на поверхность.
Глава 4. Бегство от совершенства

В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растёт, заполняя любое отведённое под неё время. Сейчас это мнение известно как закон Паркинсона.
Глава 5. Еще раз о законе Паркинсона

Даже в тех редких случаях, когда давление на человека остаётся единственным вариантом, руководитель должен это давление оказывать последним. Эффект гораздо сильнее, когда давление исходит от команды. Нам встречались случаи однородных команд, где руководителям пришлось бы занимать очередь, чтобы покричать на единственного человека, который не старается вмести со всеми.
Глава 5. А нашего Ивана вы видели?!

Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Глава 5. Университет Нового Южного Уэльса: некоторые данные

Назначение руководителя не в том, чтобы заставить людей работать, а в том, чтобы создать им условия для работы
Глава 6. Это и есть руководство

Есть миллион способов потерять рабочий день и ни одного, который бы компенсировал потерю
Часть 2. Офисная среда

Необходимость оставаться дома, задерживаться на работе, приходить раньше, чтобы спокойно поработать, – убийственное обвинительное заключение против офисной среды. Поразительно не то, что так часто нет возможности поработать на своём рабочем месте, поразительно, что все знают об этом и ничего никогда не делают, чтобы исправить положение
Глава 8. «С девяти до пяти здесь совершенно невозможно работать»

Поток – это состояние глубокого, почти медитативного погружения в работу. В этом состоянии человек испытывает лёгкое чувство эйфории и не замечает течения времени: «Я начал работать. Когда оторвался, прошло уже три часа». Человек не прикладывает сознательных усилий, потому что работа, кажется, идёт потоком.
Глава 10. Поток

К сожалению, поток нельзя «включать» по желанию. Требуется медленное погружение в предмет, не менее пятнадцати минут концентрации, прежде чем появится это состояние. В период погружения вы особенно чувствительны к шуму и остановкам. Шумная среда может затруднить или сделать невозможным вход в поток
Глава 10. Поток