Рубрика: Литература

Краткие тезисы из книги Т.Демарко Т. Листер Человеческий фактор: успешные проекты и команды

скачать книгу Т.Демарко Т. Листер Человеческий фактор: успешные проекты и команды

Основные цитаты:

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

Когда люди совершают ошибки, их следует поздравлять, потому что они получают деньги в том числе и за ошибки.

Единственное стабильное состояние в жизни проекта – трупное окоченение. Проект постоянно находится в движении. Человек, способный заставить проект шевелиться, стоит двух, просто выполняющих работу.

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

Под давлением люди работают не лучше, а всего лишь быстрее

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

Есть несколько характерных признаков того, что произошла кристаллизация команды. Самый важный – низкая текучесть кадров в проектах и в ходе выполнения чѐтко сформулированных заданий. Участники команды никуда не собираются идти, пока не сделают работу. При этом невозможно найти универсальный катализатор. Процесс слишком хрупок, чтобы им управлять

перечень элементов стратегии создания здоровой химии для процветающей организации:

• Возводить качество в ранг культа.

• Создавать многочисленные промежуточные финиши, приносящие удовлетворение.

• Внушать чувство элитарности.

• Допускать и поощрять неоднородность.

• Сохранять и защищать успешные команды.

• Раздавать стратегические, но не тактические указания.

К-О-М-А-Н-Д-Н-А-Я Р-А-Б-О-Т-А …Позволяет Простым Людям Достигать Непростых Результатов

Самый страшный грех руководителя – впустую тратить чужое время.

Вывод: книга, которую нужно перечитывать несколько раз.

Краткая идея и тезисы книги «Deadline. Роман об управлении проектами»

Самая основная мысль книги в том, что для руководителя важнее всего — это человек.
Его текущее моральное и физическое состояние, мысли, страхи.

Основные цитаты (на мой взгляд):

  Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.  Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени. Люди не начнут быстрее соображать, если руководство будет давить на них. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.

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

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

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

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

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

Безопасность и перемены

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

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

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

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

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

Собеседование и прием на работу

• Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
• Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
• Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
• Попросите наводку: тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
• Больше слушайте, меньше говорите.
• И все это сработает лучше, если вы слегка подтасуете колоду.

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

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

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

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

Играй в защите

• Сокращайте потери.
• Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
• Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
• Не пытайтесь создавать новые команды без необходимости: поищите в коллективе уже сложившиеся и сработавшиеся команды.
• Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
• Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
• День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
• Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

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

Извращенная политика

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

Сбор метрических данных

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

Процесс разработки и его улучшение

• Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
• Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
• Формальные программы, направленные на улучшение существующего процесса разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
• Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
• Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень CMM), скорее всего приведут к тому, что сроки только увеличатся.
• Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
• Что касается черезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

• Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
• Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
• Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
• Нельзя заставить людей делать что-то по-другому, если о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремяться.

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

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

Сердитый начальник

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

Туманные спецификации

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

Конфликт

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

Кто такой катализатор проекта

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

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

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

О персонале

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

Проблемы социологии

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

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

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

Злоба и скупость

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

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

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

Скачать книгу Краткая идея и тезисы книги «Deadline. Роман об управлении проектами»

«Мифический человеко-месяц, или Как создаются программные системы»
Ф.Брукс

Вводимые термины в книге:

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

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

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

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

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

Администратор — отвечает за деньги, людей, помещения, машины, и  контакты с административным механизмом организации в целом.

Редактор — Задача редактора — взять созданный хирургом черновик, критически переработать, снабдить ссылками и библиографией, проработать несколько версий и обеспечить публикацию.

Два секретаря — Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

Делопроизводитель — отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта, превращение программирования «из личного искусства в общественную деятельность»

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

Отладчик — планирует последовательность тестирования и создание среды для тестирования компонентов.

Языковед —  может найти эффективные способы использования языка для решения сложных, неясных и хитроумных задач. Иногда ему требуется провести небольшое исследование (два-три дня) для нахождения удачной технологии. Один языковед может работать с двумя или тремя хирургами.

Полезные цитаты из контекста:
Об удовольствии создания программ

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

про оценку времени выполнения задач

Во-первых, слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.

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

В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана «Антуан».

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

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

1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.

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

Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения. У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.

Закон Брукса

Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

Система 10

Концептуальная целостность

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

Оптимизация

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

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

Количество ошибок по времени внедрения

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

Концептуальные ошибки дороже, чем синтаксические. К.О.

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

Как растить выдающихся проектировщиков?

 • Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.

• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.

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

• Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.

Скачать книгу «Мифический человеко-месяц, или Как создаются программные системы»