Разработчики - не взаимозаменяемые части, и успешное создание любой сложной системы требует уникальных и разнообразных навыков всех членов целеустремленного коллектива.
Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений
Можно поддаться соблазну разбрасываться деньгами, как будто они растут на деревьях, опрометчиво полагая, что оплата повышает производительность. На самом деле здесь стоит хорошенько подумать, ведь сегодняшняя роскошь есть завтрашняя потребность. Деньги, подобно власти, оказывают на человека самое что ни на есть деструктивное влияние.
Дж. Ханк Рейнвотер “Как пасти котов”
Сегодня я начну публикацию цитат из книги Дж. Ханк Рейнвотера “Как пасти котов. Наставление для программистов, руководящих другими программистами”. Мое личное отношение к этой книге весьма неоднозначное. С одной стороны, закладок и подчеркиваний (а соответственно и цитат) набралось достаточное количество, но почему-то эта книга меня не зацепила. Вроде бы и написано все верно, и советов правильных много, и по делу все, но, чего-то мне в ней не хватило.
Еще раз повторюсь, что это мое личное мнение, многим другим людям эта книга очень и очень понравилась, поэтому я не исключаю, что дело скорее во мне. В любом случае я признаю, что в этой книге масса интересных моментов и отличных высказываний, ну а общее впечатление о здесь не очень-то и важно.
Личность в сегодняшних условиях - это опыт плюс прочитанная литература.
Введение
Заниматься менеджментом было бы значительно проще, если бы все подчиненные были как две капли воды похожи на своего начальника.
Введение
Чем лучше вы знаете людей, которыми вам предстоит руководить, тем выше шансы на успех.
Глава 1. Как привыкнуть к роли руководителя
Делегирование невозможно без доверия к своим подчиненным. Для того чтобы построить доверительные отношения, требуется некоторое время, но без них деятельность руководителя обречена на провал.
Глава 1. Мало быть крутым - смотри в оба!
Нам нужны программисты, которые не боятся сложностей, но те из них, которые любят усложнять все и вся, представляют серьезную опасность.
Глава 1. Какие бывают породы программистов
Если хотите похвалить человека, сделайте это на виду у всех. Если считаете нужным покритиковать его, не выносите свои оценки на суд публики. Дело не просто в вежливости - эти правила поведения важны в том смысле, что как похвала, так и порицание одного человека на самом деле оказывают грандиозное влияние на всю группу. Поверьте мне, публичное унижение не способствует повышению продуктивности работы группы. Напротив, похвала, высказанная при всех, причем искренне и по заслугам, способна творить чудеса.
Глава 1. Слава, почет и деньги
Не стоит забывать, что любой руководитель должен оценивать свои успехи исключительно по тому, насколько эффективно работают его подчиненные.
Глава 1. Слава, почет и деньги
Что-то в последнее время у меня не доходили руки до Цитатника, о чем я прошу прощения и постараюсь исправиться.
Сегодня будет продолжение цитат из замечательной книги Эдварда Йордона “Путь камикадзе”.
Почему люди штурмуют такие опасные горы, как Эверест, несмотря на риск и мучения? Почему они участвуют в марафонских забегах и доводят себя до физического изнеможения в многоборье? Потому что этим они бросают вызов окружающим. Еще больше возбуждает, если ты пытаешься совершить то, что до тебя никто не смог сделать. Например, из пяти миллиардов людей на планете только один может сказать: «Я был первым человеком, ступившим на Луну». Кто-то может подумать, что даже сама попытка совершить нечто подобное - это безумие и эгоизм, а другие, наоборот, хотели бы бросить вызов всем преградам в надежде завоевать славу и общественное признание.
Глава 1.4.2 Синдром покорителей Эвереста
Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?»
Глава 3.2 Допустимые компромиссы
Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать «грубую оценку» времени и количеству персонала, требуемым для реализации каких-либо частей проекта; и достаточно один раз сболтнуть об этом окружающим, как эти оценки могут превратиться в жесткие, не подлежащие изменению требования. Таким образом, в любой подобной ситуации менеджеру необходимо ответить что-либо наподобие: «Мне нужен один день (или неделя, или месяц - или даже час!), чтобы сделать необходимые расчеты, тогда я смогу дать оценку. Я отправлю ее по электронной почте».
Глава 3.4 Стратегии переговоров
Будьте настойчивы в отстаивании права формировать свою собственную команду. Можно ожидать от команды сверхурочной работы, но при этом помните, что они участвуют в марафоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Добейтесь для них щедрого вознаграждения, если проект закончится успешно, но не дразните их обещаниями будущих экстраординарных наград, потому что это только собьет их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудничеству; очень важно обладать необходимой квалификацией, однако еще более важно, чтобы она была дополнена психологической совместимостью. Все сказанное должно способствовать максимальному единению участников проекта.
Глава 4. Человеческий фактор в безнадежных проектах
Один из ключевых моментов в безнадежных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда. Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней - при условии правильного выбора этих 20 процентов.
Глава 5.1 Концепция "triage"
"Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди"
Поговорка ветеранов разработчиков
Глава 5.2 Важность управления требованиями
В действительности нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро - вот в чем заключается их определение «достаточно хорошего» ПО.
Глава 5.4 "Достаточно хорошее" программное обеспечение
Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое качество - хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.
Глава 5.4 "Достаточно хорошее" программное обеспечение
Сегодня я опять возвращаюсь к замечательной книге Джоэла Спольски “Джоэл о программировании”.
На этот раз здесь будут цитаты всего лишь из одной главы, главы 20 “Справочник бойца по проведению собеседования”. Мне кажется (хотя, нужно признать, что не только мне), что это одна из самых интересных и полезных глав из этой книги, в которой (спасибо, кэп) автор раскрывает проблемы проведения собеседований. Хотя эта тема достаточно избита, Джоэл умеет красиво (и главное с пользой дела) рассказать даже о таких, казалось бы банальных вещах.
Все соглашаются, что люди - самая главная часть программного проекта, но никто не знает толком, как решить эту проблему. Первое, что надо правильно сделать, если вы хотите, чтобы у вас были хорошие программисты, - это нанять правильных программистов. А это значит, что вы должны уметь определить, какие программисты правильные, что обычно делается во время собеседования.
Всегда старайтесь, чтобы каждого кандидата на работу интервьюировало не меньше шести человек, причем не менее пяти из них должны иметь одинаковый с ним ранг (т.е. программисты, а не менеджеры).
Гораздо, гораздо лучше отклонить хорошего кандидата, чем принять плохого. Плохой отнимет много денег и сил, а также время у других для исправления его ошибок. Увольнение нанятого по ошибке может отнять месяцы и оказаться очень сложным, если он будет склонен к сутяжничеству. Иногда просто невозможно кого-нибудь уволить. Плохие работники деморализуют хороших. При этом они могут быть плохими программистами, но прекрасными людьми, или им очень нужна эта работа, поэтому вам тяжело уволить их или их увольнение вызовет всеобщее неудовольствие, а могут быть и еще причины. Очень тяжелая ситуация.
Как же определить, что этого человека надо принять?
В принципе просто. Искать надо тех, кто:
1. Умен
2. Доводит дело до конца
На что нужно обращать внимание, задавая открытые вопросы?
Первое: Ищите увлеченность. Умный человек увлекается проектом, над которым работает. Он очень возбуждается, рассказывая о предмете... Плохие кандидаты просто равнодушны и не проявляют никакого энтузиазма во время интервью.
Второе: хорошие кандидаты стараются понятно излагать вещи на любом уровне. Я отказываю некоторым кандидатам, потому что, рассказывая о своем недавнем проекте, они были не в состоянии описать его языком, понятным нормальному человеку... Вам не стоит брать их на работу, потому что у них не хватает ума, чтобы понять, как сделать свои мысли понятными другим.
Третье: Если проект был групповым, посмотрите, есть ли у кандидата качества руководителя. Помните, умен и доводит дело до конца. Узнать о ком-либо, что он доводит дело до конца, можно, только проследив, была ли у него в прошлом тенденция доводить дело до конца.
Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:
Сложно сказать что-либо новое о легендарной книге Эда Йордона “Путь камикадзе”, т.к. она уже давно стала классической в своей области. В бумажном виде у меня есть только первое издание, а оригинал вышел еще в 1997 году (хотя автор вовсю уже работает над третьим, подробности можно почитать здесь). Но если немного перефразировать Фредерика Брукса (правда он говорил это по отношению к другой легендарной книге в области управления проектами - “Peopleware”): этой книге уготована долгая жизнь по той же причине, почему рассказы Гомера пережили тысячи лет: эти рассказы о людях, и они также верны сегодня, как и тысячу лет назад.
В существовании безнадежных проектов виновато высшее руководство, а также наивность и безрассудство пользователей.
Предисловие
Неразумное поведение корпораций заключается в том, что они делают одно и то же снова и снова, каждый раз ожидая различных результатов.
Глава 1.
Под безнадежным проектом я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%.
Глава 1.1 Определение безнадежного проекта
Другой способ охарактеризовать безнадежный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.
Глава 1.1 Определение безнадежного проекта
Наверно, слишком тягостно представить себе, что вы идиот, окружены идиотами и руководят вами идиоты. Наверно, вы рассматриваете как оскорбление даже саму возможность такого предположения.
Глава 1.3 Почему существуют безнадежные проекты?
Многие разработчики ПО клянутся, что не дадут втянуть себя в политические игры, поскольку они считают это не своим делом. Кроме того, они полагают, что все связанное с политикой, - отвратительно. Увы, уйти от политики невозможно; как только в какое-либо совместное предприятие войдут двое или более человек, тут же начнется политика.
Глава 1.3.1 Политика, политика, политика
Если вы - революционер или мученик, то можете повоевать с корпоративной культурой, но вряд ли у вас при этом хоть что-нибудь получится.
Глава 1.3.5 Менталитет "Морского Корпуса": Настоящие программисты могут работать без сна!
Вознаграждение бывает не только денежным. Иногда просто приятно получить похвалу от руководителя проекта или доказать самому себе, что вы можете не растеряться в сложившейся ситуации.
Глава 1.4.1 Риск высок, но и вознаграждение тоже
Вторая порция цитат из замечательной книги Джоэла Спольски “Джоэл о программировании”.
Вы хватаете за рукав первого попавшегося вам в коридоре человека и требуете, чтобы он поработал с кодом, который вы только что написали. Проделайте это пять раз и вы найдете 95% всех проблем с юзабилити в своем коде
("Корридорное тестирование")
Глава 3. Проводится ли юзабилити-тестирование на случайных людях?
Продвижение хороших кодеров выдвижением их на другие должности, где требуется писать на человеческом языке, а не на С++, служит классической иллюстрацией принципа Питера: люди продвигаются по службе, пока не достигнут своего уровня некомпетентности.
Глава 7. Как принимать на работу менеджера программы?
Многие неопытные менеджеры полагают, что могут "стимулировать" более быструю работу своих программистов, если будут задавать для них трудные, "напряженные" (нереалистично быстрые) графики. Я думаю, что такого рода мотивация - глупость. Если я выбиваюсь из графика, я чувствую себя обреченным, подавленным и немотивированным. Если же я работаю с опережением графика, я чувствую себя бодрым и работоспособным. Психологические игры с графиком очень опасны.
Глава 9. Ни в коем случае не позволяйте программистам занижать оценку времени.
Если у вас есть кучка деревянных кубиков, которые не помещаются в коробку, есть два выхода: взять коробку побольше или убрать некоторые кубики. Если вы думали, что сможете сделать продукт через 6 месяцев, а по графику получается 12, вам придется либо отложить выпуск продукта, либо отказаться от каких-то функций. Сделать кубики меньше вы не можете, а если вы считаете, что можете, значит, вы лишаете себя полезной возможности реально смотреть в будущее и лжете себе о том, что вы там видите.
Глава 9. График похож на набор кубиков
Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление
Глава 11. Тотальное уничтожение ошибок
Я заметил, что начиная с самой первой моей работы я как разработчик в среднем лишь два или три часа могу продуктивно писать код, и это меня изумляет. Когда я летом стажировался в Microsoft, то мой коллега-стажер рассказал мне, что фактически он ежедневно активно работал с 12 до 5. Пять часов, минус обед, и его бригада восхищалась им, потому что ему все удавалось сделать гораздо больше среднего. Я обнаружил, что со мной происходит то же самое. Я испытываю легкое чувство вины, замечая, как напряженно, по-видимому, работают все остальные, а у меня получается два или три часа настоящей работы в течение дня, и тем не менее я всегда был одним из самых результативных членов бригады. Видимо по этой причине "Peopleware" и экстремальное программирование настаивают на отмене сверхурочной работы и на строго 40-часовой рабочей неделе, будучи уверенными в том, что объем продукции команды от этого не уменьшится.
Глава 15. Огонь и движение
Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:
Сегодня речь пойдет о цитатах из книги “Джоэл о программировании” известного блогера Джоэла Спольски (www.JoelOnSoftware.com). Это имя уже давно известно многим людям, занятым в области разработки ПО, да и не только в ней. Книга мне понравилась, она написана очень простым и интересным языком, охватывает множество самых разнообразных тем из области разработки программного обеспечения.
По-сути, эта книга является “блуком” (одно из новых веяний в литературе, которое пошло от английских слов book (книга) и blog) и построена на основе наиболее известных статей Джоэла, которые были опубликованы автором на своем сайте. Но несмотря на публичную доступность материала, я все же отдаю предпочтение печатным изданиям; как мне кажется подобную литературу удобнее читать на диване с карандашом, а не перед компьютером. Но не зависимо от формы носителя информации, здесь вы сможете ознакомиться с наиболее выдающимися ее фрагментами, что позволит точнее сформировать ваше собственное к ней отношение:)
Более развернутое мнение об этой книге можно почитать на моем блоге или, как обычно, на сайте rsdn.ru.
Кроме того, с этого сообщения я постараюсь уменьшить количество цитат на одно сообщение, чтобы их было не более 5-6-ти. Если такой формат будет более удачным (или наоборот – менее удачным) – вперед, высказывайте свое мнение в комментариях.
Ну что ж, приступим:)
Ты никогда не стремился стать менеджером. Как и большинство разработчиков программ, с которыми я знаком, ты был бы гораздо счастливее, если бы тебе позволили спокойно сидеть и писать код. Но ты лучший разработчик, и когда с Найджелом, прежним руководителем группы, произошел этот несчастный случай на банджи и с лэптопом, всем показалось естественным, что на его место надо выдвинуть тебя, звезду команды.
Введение
Знаете, что я вам скажу? Управление программными проектами не имеет никакого отношения к программированию. Если вы до сих пор не занимались ничем, кроме написания кода, то вам предстоит открыть, что человеческие существа несколько менее предсказуемы, чем обычный процессор Intel.
Введение
Управление программными проектами требует совершенно иных навыков и приемов, нежели написание кода; это два совершенно различных и не связанных между собой поля. Написание кода так же отличается от управления проектом, как нейрохирургия от выпекания кренделей. Нет никаких оснований полагать, что у блестящего нейрохирурга, каким-то образом попавшего на производство кренделей в результате некоего разрыва в пространственно-временном континууме, окажется хоть малейшее представление о том, как делать эти самые крендели, даже если он окончил Гарвардский медицинский колледж. Но люди, однако, продолжают думать, что можно взять ведущего программиста и без какой-либо переподготовки перевести его в администраторы.
Введение
Я думаю, что некоторые крупнейшие ошибки - даже на самых верхних уровнях архитектуры - происходят из-за слабого или неверного понимания некоторых простых вещей на самых нижних уровнях. Вы построили замечательный дворец, но его фундамент никуда не годится. Вместо аккуратных бетонных плит навален булыжник. Здание выглядит прекрасно, но время от времени по совершенно непонятным причинам ванна начинает скользить по полу.
(О важности мышления на языке байтов)
Глава 2. Обращаясь к основам
В первоклассных командах не принято мучить программистов. Даже мелкие неприятности, вызываемые плохим инструментом, копятся и делают программистов сердитыми и мрачными. А сердитый программист - малопродуктивный программист.
Вдобавок ко всему, программистов очень легко подкупать, приобретая для них самые крутые и новые вещицы. Это гораздо более экономный способ заставить их трудиться, чем платить им более высокие, по сравнению с другими фирмами, зарплаты!
Глава 3. Стараетесь ли вы использовать для работы лучшие инструменты?
Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:
В этом сообщении я опубликую фрагменты диалогов и другие интересные цитаты из замечательной книги Тома Демарко “Deadline. Роман об управлении проектами”.
- Некоторые думать вообще не умеют. Такие люди обычно становятся директорами крупных компаний, вроде этой.
Лакса Хулигэн в разговоре с мистером Томпкинсом
Глава 1. Широчайшие возможности
- Найдите правильных людей. Потом, что бы вы ни делали, какие бы ошибки ни допускали, люди вытащат вас из любой передряги. В этом и заключается работа руководителя.
Томпкинс о роли руководителя
Глава 1. Широчайшие возможности
Он и раньше сталкивался с идиотскими и губительными для команды «наказаниями за отставание от графика», и сегодняшний разговор разбередил в нем эти воспоминания. Откуда у некоторых руководителей эта слепая вера в кнуты и штрафы? Неужели из них получаются такие же ужасные родители? Скорее всего, да.
Мысли мистер Томпкинса о пользе наказания
Глава 4. Завод по изготовлению CD-ROM
— Если вдуматься, для руководства проектом голова вообще не больно-то нужна. Больше всего нужны нутро, сердце и душа.
— Нутро, сердце и душа?
— Да. Настоящий руководитель чувствует ситуацию нутром, управляет людьми исключительно сердцем и может вдохнуть живую душу в проект, команду или всю организацию.
Диалог Белинды Бинды и мистера Томпкинса о роли руководителя
Глава 6. Лучший в мире руководитель
Душа команды - это как песчинка в ракушке, вокруг которой начинает нарастать самое ценное. Сообщество.
Белинда Бинда о душе команды
Глава 6. Лучший в мире руководитель
- Давайте знакомиться с людьми, а не с их резюме.
Белинда о подборе персонала
Глава 7. Подбор персонала
— Мы ищем таких руководителей, которые настолько хорошо подходят для своей работы, что могут менять мир вокруг себя и добиваться гармонии между этим миром и тем, что они делают вместе со своей командой.
Белинда о подборе руководителей
Глава 7. Подбор персонала
— Иногда бывает трудно смотреть в глаза своему начальнику и говорить, что не сможешь сделать работу вовремя. Куда проще взять и опоздать. Но тогда твой босс узнает об опоздании на четыре недели позже, и у него просто не останется возможности хоть как-то исправить ситуацию. Именно поэтому мы выработали такую вот полуанонимную систему. Конечно же, я знаю, кто сейчас приходил на «исповедь», но делаю вид, что он мне не знаком. А в результате всегда узнаю плохие новости вовремя.
Молли Макмора об общении разработчиков с их руководителями
Глава 7. Подбор персонала
В этом и заключается наша работа — находить для своих подчиненных такую должность, на которой проявятся все их скрытые способности. А в чем еще заключается руководство, если не в этом?
Белинда о роли руководителя
Глава 12. Человек, который умел считать
— Да ладно вам, — вмешался Аристотель. — Как будто вы раньше этого не знали. Наверняка в глубине души каждый из нас знает, что сверхурочная работа — верный способ снизить производительность.
— Да, в общем-то, это так, — задумчиво сказала Белинда. — Недостатки сверхурочной работы хорошо всем известны: усталость, отсутствие творческой энергии, ошибки…
— А также потеря времени в течение обычного рабочего дня, — добавил Аристотель.
— А это почему?
— Потому что люди знают, что все равно будут работать допоздна. Поэтому они могут позволить себе долгие и не очень нужные совещания, перерывы и тому подобное.
— Да уж точно. А если запретить работать сверхурочно, то им волей-неволей придется использовать рабочее время более эффективно.
— Именно.
— Значит, в список недостатков сверхурочной работы можно добавить еще и это. А те данные, которые привел нам Вальдо, ясно показывают: недостатки сверхурочной работы все равно перевешивают пользу от дополнительных усилий разработчиков. Как правильно сказал Аристотель, все мы в глубине души знаем
это.
— Так что же делать руководителю в трудной ситуации? — взволнованно спросил мистер Томпкинс.
— Что-то другое, — ответила ему Белинда. — Что-то более сложное: принимать на работу новых сотрудников, придумывать способы мотивации персонала, развивать командные отношения и поддерживать боевой дух, привлекать к проекту грамотных людей, устранять из процесса разработки все малоэффективные действия, реже устраивать совещания, не давать людям Том ДеМарко: «Deadline. Роман об управлении проектами» 121
работать сверхурочно, сократить работу над документацией. Однако мистера Томпкинса это ничуть не успокоило.
Диалог Аристотеля, Томпкинса и Белинды о вреде сверхурочных
Глава 15. Думать быстрее!
Не мне объяснять тебе, что когда разработчики не чувствуют поддержки и признания начальства, они редко создают сильные сплоченные команды.
Мелисса Альбер о кристаллизации команд
Глава 16. План работы по подготовке к летним Олимпийским играм
Я считаю, что в каждом из нас, в душе или на уровне подсознания, живет тайный страх: мы боимся показать, что соображаем хуже других. Вся наша раса заражена этим страхом. Каждый готов предположить, что его мыслительные способности ниже средних, поэтому ему надо прикладывать дополнительные усилия, чтобы разобраться в том, в чем другие разбираются с ходу. А теперь возьмем нашу ужасную спецификацию. Ты читаешь ее целый день и обнаруживаешь, что ничего не понимаешь. И тут приходит начальник и спрашивает: «Ну как? Как вам спецификация?» Что сказать? И мы врем! «Все в порядке, босс. То есть я хочу сказать, что документ этот весьма непростой, но дайте нам еще немного времени, и мы во всем разберемся…» И так поступает каждый!
Белинда о корпоративном мышлении и отношению к руководству
Глава 16. План работы по подготовке к летним Олимпийским играм
Кстати, у меня есть твердое убеждение: любую сложную вещь можно описать простыми словами. Если нам это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
Белинда о спецификациях
Глава 16. План работы по подготовке к летним Олимпийским играм
Дорога к мудрости проста,
Как этот краткий стих:
Ошибки смело совершай -
И станет меньше их.
Пит Хайн
Глава 18. Маэстро Диеньяр
Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:
Немногие знают, что помимо книг по управлению проектами и структурному анализу Том Демарко написал сборник рассказов под названием “Lieutenant America and Miss Apple Pie” и повесть “Dark Harbor House”.
Помимо компьютерных книг и художественной литературы у Тома Демарко есть и промежуточный вариант - “Deadline. Роман об управлении проектами”, в котором автор рассказывает историю мистера Томпкинса, менеджера проектами, который сталкивается с типичными проблемами управления программными проектами.
Во многом, темы этой книги пересекаются с темами из ставшей давно классической книги Демарко и Листера “Peopleware”. И хотя “Peopleware” написана замечательным языком и сама читается как художественное произведение, Демарко решил, что этого недостаточно и решил описать проблемы управления в виде настоящего романа.
Цитаты из этой книги я разбил на два сообщения, в этом сообщении я опубликую записи, который делал мистер Томпкинс в своей записной книжке, а отдельным сообщением я опубликую другие интересные цитаты.
Итак, перед вами целиком записная книжка мистера Томпкинса.
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
(Все остальное - административная ерундистика.)
1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3. Более того, если люди не справятся, вам придется выполнить свои обещания.
1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу.
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»
1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.
1. Определяйте размер каждого проекта.
2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.
3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком
сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к
рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с
непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
1. Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
1. Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какая-то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т.п.
4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)
1. Эту патологию невозможно вылечить снизу.
2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.
1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.
Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:
Ну а здесь, как не сложно догадаться, понравившиеся цитаты.
В книгах о менеджменте (которые я читал), говорится, что на 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. Обсуждение
Реальность - это убийство прекрасной теории бандой мерзких фактов.
Выводы
Продолжение цитат из книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".
Успешный программный проект не содержит секретов. Как хорошие, так и плохие новости должны распространяться вверх и вниз по иерархии проекта без ограничений.
Глава 7. Общедоступность индикаторов развития
Лучше подождать, пока продуктивный программист не станет доступным, чем ждать, пока первый доступный программист не станет продуктивным
Глава 7. Новые разработчики: доступные и хорошие
Разработка и обеспечение качества не должны выполняться одними и теми же людьми. Ответственный за обеспечение качества играет роль "адвоката дьявола", которую трудно или невозможно совместить с деятельностью разработчиков.
Глава 7. Организация команды проекта
Используя лишь самых продуктивных разработчиков, руководители проекта способны свести их с ума постоянными отвлечениями от основной работы, существенно замедляющими развитие проекта.
Глава 7. "Команды тигров"
Самой трудной частью сбора требований является не запись пожеланий пользователей, а исследовательская деятельность, направленная на помощь пользователям в определении своих пожеланий.
Глава 8. Разработка требований
Объясните пользователям, что прототип - это "не более чем прототип". Один из рисков, связанных с созданием прототипа пользовательского интерфейса, состоит в появлении нереалистичных ожиданий пользователей по поводу будущего развития проекта.
Глава 8. Создание простого прототипа пользовательского интерфейса
Качество - это степень удовлетворения программным продуктом требований, как утвержденных официально, так и подразумеваемых.
Глава 9. Обеспечение качества
Для высококачественного программного продукта число тестировщиков должно равняться числу разработчиков.
Глава 9. Тестирование системы
Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.
Глава 9. Тестирование системы
Поскольку целью архитектуры является упрощение программного продукта, архитектор должен сконцентрировать свое внимание на том, что можно исключить из продукта, а не на том, что можно включить в него.
Глава 10. Подсистемы и организация
В погоне за лучшим вы рискуете остаться ни с чем. Придерживайтесь минимализма, простоты, удовлетворяйте все требования и не пытайтесь найти единственное идеальное решение.
Глава 9. Определение готовности архитектуры
Лучше работать разумно и много, чем неразумно много!
Глава 12. Если микровеховый план не выполняется
В зависимости от длительности и предметной области проекта, период после выпуска - хорошее время для того, чтобы предложить команде ланч, предоставить дополнительный выходной или вовсе отправить ее в оплачиваемый отпуск на Гавайи. Ну а на досуге следует сделать выводы из накопленного опыта и заложить основу для будущего успеха.
Глава 18. Хронология проекта
Поощрение команды никогда не приведет к провалу, а ее угнетение - к успеху.
Глава 19. Желательные действия
Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".
Сегодня я решил опубликовать цитаты из книги Стива Макконнелла ""Остаться в живых! Руководство для менеджера программных продуктов". Книгу я читал уже довольно давно (года три назад) и тогда она на меня произвела двоякое впечатление. Первая часть книги, в которой автор сосредотачивается на общих сведениях, мне очень понравилась, а вот вторая, более конкретная, мне понравилась не очень сильно и я не решился применять советы автора на практике. Хотя у вас может быть и другое мнение:)
В целом, нужно сказать, что интересных мыслей в книге достаточно, о чем можно будет убедиться по цитатам. Цитат набралось много, поэтому я разбил их на две части.
На первой цитате я хочу остановиться подробнее. Во-первых, автором этой цитаты является не Стив Макконнелл, а Александр Милн, а во вторых, ее нельзя публиковать без рисунка, а в третьих, несмотря на то, что Милн, мягко говоря, не имеет никакого отношения к компьютерам, эта фраза имеет непосредственное отношение к разработке ПО.
Плюшевый медвежонок вслед за Кристофером Робином спускается по лестнице, считая затылком ступеньки - бум, бум, бум. Он знает - это единственный способ перемещаться с этажа на этаж, хотя иногда ему кажется, что должен быть и другой. И он бы догадался, что это за способ, если б его перестали колотить затылком о ступени и дали хоть чуточку подумать. Но чаще ему кажется, что никакого другого способа просто нет.
Об авторе
Исследователи обнаружили, что стоимость позднего исправления ошибки, внесенной в проект на ранней стадии (например, при формировании требований или архитектуры), в 50-200 раз выше, чем стоимость ее исправления сразу же после внесения.
Глава 3. "В начале потока" и "в конце потока"
Конус неопределенности задает ряд жестких предпосылок для оценки проектов. Так, он подразумевает, что на ранних стадиях проекта точно оценить проект не просто трудно, а теоретически невозможно. После окончания формирования требований область действия проекта будет зависеть от огромного числа решений на этапах создания архитектуры, детального проектирования и конструирования. Если кто-то берется оценить влияние этих решений до их принятия, то возможны два варианта: либо этот человек обладает даром предвидения, либо попросту плохо осведомлен о сущности программной разработки
Глава 3. Предпосылки для оценки проекта
В начале проекта вы можете определить для него либо фиксированные сроки и бюджет, либо фиксированный функциональный набор. Определить и то и другое одновременно - невозможно.
Глава 3. Предпосылки для оценки проекта
Добиться успеха в небольших проектах можно при благоприятном стечении обстоятельств простым напряжением силы воли, однако средние и крупные проекты требуют более систематического подхода
Глава 4. Навыки выживания
В некоторых организациях проблема финансирования программных проектов состоит в том, что менеджеры вынуждены делать запросы финансирования раньше, чем у них появляется возможность завершить значительную часть исследовательских работ. Такие запросы обречены на "промах", поскольку для осмысленного расчета оценок бюджета и сроков проекта о желаемом продукте известно слишком мало. Опыт программной индустрии свидетельствует о том, что оценки, создаваемые на ранних стадиях проектов, могут отличаться от действительных в большую или меньшую сторону до четырех раз.
Глава 4. Двухэтапный подход к финансированию
Любой участник среднего или крупного проекта не понаслышке знает, что очень многое в нем может пойти "не так"
Глава 4. Управление рисками
В силу загадочных для меня причин люди полагают, что можно контролировать проект, не выделяя для этой цели какую-то группу или отдельное лицо. Мое мышление и опыт говорят, что это невозможно
Глава 4. Контроль над проектом
Разработка программных продуктов требует творчества, интеллекта, инициативности, настойчивости и значительной степени внутренней мотивации. Любой эффективный подход к разработке программного обеспечения должен подразумевать, что в отсутствие интереса команды к проекту его успех сомнителен.
Глава 4. "Человеческое обеспечение"
Не пытайтесь мотивировать разработчиков эффективными выступлениями, недостижимыми результатами или денежными вознаграждениями
Глава 4. "Человеческое обеспечение"
Разработка программных продуктов - это процесс постоянных исследований и поиска, поэтому лучшая его поддержка - это спокойная обстановка, располагающая к размышлениям. Эффективная разработка программ требует от разработчиков такого же уровня концентрации, как от математиков или физиков. Можете ли вы представить Альберта Эйнштейна, сидящего за рабочим столом, вокруг которого ходит менеджер и раздраженно повторяет: "Альберт, теория относительности нужна нам прямо сейчас! Поторопись!"
Глава 4. "Человеческое обеспечение"
Работа среднестатистического менеджера требует переключения внимания каждые несколько минут. Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов.
Глава 4. "Человеческое обеспечение"
С точки зрения сложности компонентов программного продукта и их функциональности, успешная разработка проекта подчиняется принципу "чем меньше, тем лучше", действующему на всех этапах - от формирования требований до выпуска. Поскольку разработка программного продукта требует значительных интеллектуальных усилий, становится важно, чтобы участники проекта активно способствовали его максимальному упрощению, избавляя проект от излишней сложности.
Глава 4. Минимализм продукта
Французский писатель Вольтер говорил, что рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть. Этот подход применим и к программному проекту.
Глава 4. Минимализм продукта
Эффективные проекты контролируют изменения; неэффективные проекты находятся под контролем изменений.
Глава 6. Стрельба по движущейся цели
Хорошо организованные проекты неизбежно ищут компромисс между функциональным набором, бюджетом и расписанием
Глава 7. Цели в области действия проекта
Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".
Один из комментариев к первой части цитат книги Фредерика Брукса “Мифический человеко-месяц” навела на мысль, что одной цитаты из раздела “Радости профессий” недостаточно. Но этот раздел настолько потрясен, что я думаю будет не лишним выделить его в отдельное сообщение.
Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг - отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
Во-вторых, это удовольствие создавать вещи, которые могут быть полезны другим людям. Глубоко в душе мы испытываем потребность в том, чтобы другие использовали результаты нашего труда и считали их полезными. В этом отношении программная система по своей сути - то же, что и изготовленная ребенком подставка для карандашей "папе в подарок".
В-третьих, это очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей и наблюдения за их работой, круг за кругом демонстрирующей результаты изначально заложенных принципов. Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.
В-четвертых, это радость, получаемая от неизменного узнавания нового, проистекающего из неповторимой природы задачи. В том или ином отношении задача всегда ставится по-новому, и тот, кто ее решает, получает новые знания - либо практические, либо теоретические, либо те и другие вместе.
Наконец, наслаждение доставляет работа со столь податливым материалом. Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов. (Как мы позднее увидим, такая податливость таит свои проблемы.)
Однако программная конструкция, в отличие от поэтических творений, реальна, в том смысле, что она движется и работает, производя видимые результаты, которые отделимы от самой конструкции. Она печатает результаты, рисует картинки, производит звуки, приводит в движение рычаги. В наше время осуществилось волшебство мифа и легенды. С клавиатуры вводится верное заклинание, и экран монитора оживает, показывая то, чего никогда не было и не могло быть.
Таким образом, программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:
Помимо философских высказываний, в книге Дейва Томаса и Энди Ханта можно найти немало полезной информации и по управлению проектами.
Поскольку вы не работаете в безвоздушном пространстве, вам необходимо уметь общаться. Чем эффективнее это общение, тем более влиятельным вы становитесь.
Глава 1. Обращайтесь к людям
Одной из интересных особенностей оценки является тот факт, что интерпретация ее результата зависит от используемых вами единиц измерения. Если вы говорите, что для некоего действия потребуется 130 рабочих дней, то люди будут ожидать наступления этого события в достаточно узком интервале. Но если вы скажете «около шести месяцев», они будут знать, что этого события следует ожидать чрез 5-7 месяцев. Обе цифры обозначают одну и ту же продолжительность, но «130 дней», вероятно, подразумевает большую точность, чем вы полагаете.
Глава 2. Насколько точной является “приемлемая точность”?
Что сказать, если вас просят оценить что-либо?
Говорите: «Я вернусь к вам с этим позже».
Вы почти всегда можете добиться лучших результатов, если не будете торопиться… К оценкам, сделанным на ходу (например, у офисной кофеварки), придется возвращаться вновь и вновь (как, впрочем, и к кофе), теряя при этом покой.
Глава 2. Что сказать, если вас просят оценить что-либо
Всегда используйте управление исходным текстом программы
Всегда. Даже если ваша команда состоит из одного человека и продолжительность проекта составляет одну неделю. Даже если это прототип на выброс. Даже если материал, с которым вы работаете, не является исходным текстом программы. Убедитесь, что все находится под контролем – документация, номера телефонов, записки поставщикам, сборочные файлы, процедуры сборки и выпуска, крохотный сценарий (в оболочке), прожигающий эталонный компакт-диск, словом – все.
Глава 3. Управление исходным текстом программ
Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания "Пасторальной симфонии". Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Не собирайте требования – выискивайте их
Глава 7. Карьер для добычи требований
Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Глава 7. В поисках требований
Очень сложно создать успешный проект, в котором пользователи и разработчики обращаются к одному и тому же предмету под разными именами или, что еще хуже, обращаются к разным предметам, используя одно и тоже имя.
Глава 7. Поддержка глоссария
Однажды царь Фригии Гордий завязал узел, который никто не мог развязать. Было предсказано, что тот, кто сможет развязать его, станет властелином всей Азии. И вот пришел Александр Македонский, который разрубил узел своим мечом. Несколько иная интерпретация требований и все – он стал властителем всей Азии.
Глава 7. Разгадка невероятных головоломок
Не забывайте, что формальные методы разработки – это лишь один инструмент из вашего арсенала. Если после тщательного анализа вы почувствуете, что вам необходим формальный метод, берите его на вооружение, но помните, что несете ответственность. Никогда не становитесь рабом методологии, ведь кружки и стрелки обедняют своих хозяев. Прагматики смотрят на методологии критическим взглядом, затем берут лучшее из каждой и преобразуют их в набор практических технологий, который улучшается каждый месяц. Это является решающим моментом. Вы должны постоянно работать над усовершенствованием процессов. Никогда не делайте жесткие рамки методологии границами вашего собственного мира.
Глава 7. Должны ли мы использовать формальные методы?
Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Глава 8. Генерирование web-сайта
Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:
Часть 1. Философия программирования
Часть 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. Снова дробление
Сегодня я хочу опубликовать цитаты из замечательной книги Тома Демарко и Тимоти Листера "Человеческий фактор: успешные проекты и команды" (рецензия на моем блоге и сайте rsdn.ru). Как и книга Фредерика Брукса, эта книга произвела на меня сильное впечатление и является одной из самых любимых в библиотеке компьютерной литературы. В очередной раз перелистывая ее, понимаешь, насколько много в ней интересных мыслей и насколько эти мысли редко доходят до нужных голов и еще реже воплощаются на практике.
Из-за огромного количества, цитаты этой книги я также разбил на два сообщения, примерно пополам.
Серьёзные проблемы в нашей работе имеют не столько технологическую сколько социологическую природу.
Глава 1. Суть вопроса
Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
Глава 1. Миражи высоких технологий
Если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на тёмной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».
Глава 1. Миражи высоких технологий
Нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.
Глава 2. Менеджмент, простецкое определение
Вена, которая, по словам Билли Джоэла, ждёт тебя, – это последняя остановка на твоём жизненном пути. Когда ты окажешься там, все будет кончено. Если вам кажется, что участников проекта никогда не интересуют такие серьёзные вещи, подумайте получше. Ваши люди очень остро понимают, что человеку дана лишь одна короткая жизнь, и они слишком хорошо знают, что в этой жизни должно быть что-то поважнее, чем их глупая работа.
Глава 3. Письмо из дома
Сверхурочные сотрудников, сидящих на окладах, – это плод воображения наивного руководителя. Да, в паре лишних субботних часов, позволяющих уложиться в сроки и сдать проект в понедельник, может быть очевидная польза, но за ними всегда следует равносильный период компенсации, сокращения рабочего времени, позволяющий сотрудникам вернуться в ритм привычной жизни. В конечном итоге каждый час сверхурочных компенсируется часом недоработки. В краткосрочной перспективе такой компромисс может принести пользу проекту, но в долгосрочной польза нивелируется.
Глава 3. Сверхурочные не существуют
Сверхурочные похожи на спринт: он имеет смысл на последней стометровке марафонской дистанции для тех людей, у которых ещё остались силы, но если начать спринт на первом километре, вы только зря потеряете время. Если заставлять людей постоянно бежать в темпе спринта, они лишь потеряют уважение к руководителю. Лучшие из сотрудников уже все это проходили – они будут молчать и закатывать глаза, пока руководитель бредит, что эту работу просто необходимо закончить к апрелю. После этого они воспользуются компенсирующими недоработками и в конечном итоге каждую неделю будут работать не более сорока часов. Так реагируют лучшие; все остальные – просто трудоголики.
Глава 3. Сверхурочные не существуют
Осознание того, что большие ценности (семья, любовь, дом, молодость) принесены в жертву меньшим (работа), разрушительно. Оно заставляет человека, совершившего столь глупую жертву, искать отмщения. Он не пойдёт к шефу, чтобы спокойно и вдумчиво объяснить, что положение вещей должно измениться; он просто уйдёт – ещё один человек, который сгорел на работе. Так или иначе, его больше не будет.
Глава 3. Трудоголики
В личной жизни причины эмоциональных реакций многочисленны и разнообразны, но на рабочем месте главным источником душевных потрясений является самооценка, находящаяся под угрозой.
Глава 4. Качество? Если успеем
«Рынку абсолютно плевать на такой уровень качества». Прочтите эти слова и прослезитесь, потому что они почти всегда правдивы. Люди могут с пеной у рта говорить о качестве и горько жаловаться на его отсутствие, но когда приходит время платить за качество, их действительные ценности выходят на поверхность.
Глава 4. Бегство от совершенства
В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растёт, заполняя любое отведённое под неё время. Сейчас это мнение известно как закон Паркинсона.
Глава 5. Еще раз о законе Паркинсона
Даже в тех редких случаях, когда давление на человека остаётся единственным вариантом, руководитель должен это давление оказывать последним. Эффект гораздо сильнее, когда давление исходит от команды. Нам встречались случаи однородных команд, где руководителям пришлось бы занимать очередь, чтобы покричать на единственного человека, который не старается вмести со всеми.
Глава 5. А нашего Ивана вы видели?!
Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Глава 5. Университет Нового Южного Уэльса: некоторые данные
Назначение руководителя не в том, чтобы заставить людей работать, а в том, чтобы создать им условия для работы
Глава 6. Это и есть руководство
Есть миллион способов потерять рабочий день и ни одного, который бы компенсировал потерю
Часть 2. Офисная среда
Необходимость оставаться дома, задерживаться на работе, приходить раньше, чтобы спокойно поработать, – убийственное обвинительное заключение против офисной среды. Поразительно не то, что так часто нет возможности поработать на своём рабочем месте, поразительно, что все знают об этом и ничего никогда не делают, чтобы исправить положение
Глава 8. «С девяти до пяти здесь совершенно невозможно работать»
Поток – это состояние глубокого, почти медитативного погружения в работу. В этом состоянии человек испытывает лёгкое чувство эйфории и не замечает течения времени: «Я начал работать. Когда оторвался, прошло уже три часа». Человек не прикладывает сознательных усилий, потому что работа, кажется, идёт потоком.
Глава 10. Поток
К сожалению, поток нельзя «включать» по желанию. Требуется медленное погружение в предмет, не менее пятнадцати минут концентрации, прежде чем появится это состояние. В период погружения вы особенно чувствительны к шуму и остановкам. Шумная среда может затруднить или сделать невозможным вход в поток
Глава 10. Поток
Обещанная вторая часть цитат из замечательной книги Фредерика Брукса.
Как оказывается, что проект запаздывает на год?
... Сначала он запаздывает на один день.
Глава 14. Назревание катастрофы
Никто не любит и сам приносить дурные вести, поэтому они смягчаются без злого намерения ввести в заблуждение.
Глава 14. Вехи или помехи?
Каждому начальнику нужно два вида данных: информация о срывах плана, которая требует вмешательства, и картина состояния дел, чтобы быть в курсе.
Глава 14. Под ковром
Компьютерная программа - это послание человека машине. Строго выстроенный синтаксис и тщательные определения нацелены на то, чтобы бездумной машине стали понятны намерения человека.
Глава 15. Обратная сторона
Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
Глава 16 Серебряной пули нет - сущность и акциденция в программной инженерии
Серебряных пуль не только не видно в настоящее время, но в силу самой природы программного обеспечения маловероятно, что они вообще будут найдены — не будет изобретений, способных повлиять на продуктивность создания, надежность и простоту программного обеспечения так, как электроника, транзисторы и интегральные схемы — на аппаратное обеспечение компьютеров.
Глава 16. Неизбежны ли трудности? Трудности, вытекающие из сущности
Сложность программ является существенным, а не второстепенным свойством. Поэтому описания программных объектов, абстрагирующиеся от их сложности, часто абстрагируются от их сущности. Математика и физические науки за три столетия достигли больших успехов, создавая упрощенные модели сложных физических явлений, получая из этих моделей свойства и проверяя их опытным путем. Это удавалось благодаря тому, что сложности, игнорировавшиеся в моделях, не были существенными свойствами явлений. Но это не действует, когда сложности являются сущностью.
Глава 16. Глава 16. Неизбежны ли трудности? Трудности, вытекающие из сущности
Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол.
У разработчика программного обеспечения нет такой утешительной веры. Сложность, с которой он должен совладать, по большей части является произвольной, необоснованно вызванной многочисленными человеческими установлениями и системами, которым должны удовлетворить его интерфейсы. Системы различаются интерфейсами и меняются во времени не в силу необходимости, а лишь потому, что были созданы не Богом, а разными людьми.
Глава 16. Глава 16. Неизбежны ли трудности? Трудности, вытекающие из сущности
Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации.
Глава 16. Перспективные подходы к концептуальной сложности
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
Глава 16. Перспективные подходы к концептуальной сложности
Программисты принадлежат к наиболее интеллектуальной части общества, следовательно, они в состоянии изучать хорошие приемы.
Глава 16. Перспективные подходы к концептуальной сложности
Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было, нет и не будет
Александр Поуп "О критике"
В конце концов, я по происхождению программист, а оптимизм - это профессиональная болезнь данного ремесла
Глава 17. Анализ Харела
Любыми средствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языке не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода.
Глава 17. Объектно-ориентированное программирование: а медная пуля не подойдет?
Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем "одноразовые" компоненты
Эдвард Йордон
Глава 17. Что с повторным использованием?
История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.
Глава 19. Для чего понадобилось юбилейное двадцатое издание?
Архитектора можно сравнить с режиссером, а менеджера - с продюсером кинокартины
Глава 19. Центральные аргумент: концептуальная целостность и архитектор
Дополнительно привлекаемые на поздних стадиях проекта работники должны быть игроками команды, стремящимися войти в игру и вписаться в процесс, а не пытаться изменить или усовершенствовать сам процесс!
Глава 19. Насколько мифичен человеко-месяц? Модель и данные Бёма
Если согласиться, что, как я неоднократно доказывал на протяжении этой книги, творчество исходит от личностей, а не организационных структур и процессов, тогда главная задача менеджера программного проекта — создать организационную структуру и рабочий процесс, способствующий творчеству и инициативе, а не подавляющие их.
Глава 19. Сила отказаться от власти
Немногим Бог дает право зарабатывать на жизнь тем, чем они с радостью занимались бы по собственной воле, по увлечению. Я благодарен судьбе.
Эпилог. Пятьдесят лет удивления, восхищения и радости
Область связанных с компьютерами знаний претерпела взрыв, как и соответствующая технология. Будучи аспирантом в середине 50-х, я мог прочесть все журналы и труды конференций. Я мог оставаться на современном уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной жизни приходится с сожалением расставаться с интересами то в одной, то в другой подобласти, поскольку количество документов превысило всякую возможность справиться с ними. Масса интересов, масса замечательных возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие радости.
Эпилог. Пятьдесят лет удивления, восхищения и радости
Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:
