(no subject)
Дочитал Кайта
Сейчас читаю
Дж. Ханк Рейнвотер
Как пасти котов. Наставление для программистов, руководящих другими программистами
СПб.: Питер, 2006 г., 256 стр.
Перевод с англ. Ю. Гороховского
Herding Cats: A Primer for Programmers Who Lead Programmers, by J. Hank Rainwater
Thanks to geni.
На этой странице:
Краткое содержание
12 .... Предисловие
15 .... Об авторе
16 .... О научном редакторе
17 .... Об иллюстраторе
18 .... Благодарности
20 .... Введение
26 .... Глава 1. Как привыкнуть к роли лидера
46 .... Глава 2. Как руководить собой
63 .... Глава 3. Как вести стаю за собой
81 .... Глава 4. Как организовать успех
107 ... Глава 5. Как вести совещания
124 ... Глава 6. Философия и методы технического лидера
147 ... Глава 7. Закат лидера
167 ... Глава 8. Восход лидера
193 ... Глава 9. Как ужиться с начальством
205 ... Глава 10. Слова без песни
228 ... Послесловие. Снова в плавание
233 ... Приложение А. Как ухаживать за живностью - электронный администратор
237 ... Приложение Б. Как дать скотине в глаз - критический обзор кода электронного администратора
243 ... Библиография. Ресурсы для специалистов по выпасу котов
250 ... Алфавитный указательПолное содержание
12 .... Предисловие
15 .... Об авторе
16 .... О научном редакторе
17 .... Об иллюстраторе
18 .... Благодарности
20 .... Введение
20 .... Структура книги
24 .... Кому и зачем стоит прочесть эту книгу
24 .... Стиль и позиция
26 .... Глава 1. Как привыкнуть к роли лидера
27 .... Правда ли, что настоящие руководители ходят в черном?
Насколько важно быть крутым?
Насколько вы крутой?
Мало быть крутым - смотри в оба!
30 .... Как руководить чокнутыми, чудаковатыми, странными и обычными программистами
Какие бывают породы программистов
Распространенные породы
Архитектор
Конструктивист
Художник
Инженер
Ученый
Лихач
Редкие породы
Волшебник
Минималист
Аналогист
Трюкач
Дворняги
Разгильдяй
Тормоз
Любитель
Профан
Эклектик
Умение обращаться с представителями разных пород
Кошачьи разборки - соревнование по шипению и царапанию
40 .... Слава, почет и деньги
Мотивирование деньгами
42 .... Уровень мышления
44 .... Как вы адаптируетесь
46 .... Глава 2. Как руководить собой
46 .... Взгляд в зеркало
48 .... Рай, ад, чистилище и ваше место во вселенной
Ваша работа в корне меняется
Вам нужно заново учиться оценивать свои успехи, увлечения, амбиции
50 .... Естественный отбор и время
Избегайте ненужных, неэффективных совещаний
Не планируйте слишком мало или слишком много
Бессмысленно ожидать чего-либо при отсутствии контроля
Проектируйте архитектуру, прежде чем выбирать технологию
Баланс между чистотой и практичностью
Не выполняйте задания, а распределяйте их
Документируйте то, что вы делаете или планируете делать
54 .... Оценка вашей производительности
55 .... Контролируйте свои слабости
58 .... Ответы
61 .... Кошачьи разборки - похоронный марш
63 .... Глава 3. Как вести стаю за собой
63 .... Как справиться с административными функциями
66 .... Как не отвлекаться на раздражители
68 .... Когда проект разрастается
Нереалистичный план проекта
Анализ требований
Создание проектного решения
Реализация проектного решения
Тестирование программного обеспечения
Исправление ошибок
Развертывание программного обеспечения
Реалистичный план проекта
Анализ требований
Обсуждение результатов анализа с сотрудниками отдела
Создание проектного решения
Макетирование проектного решения
Оценка макетов
Пересмотр проектного решения
Реализация высокоуровневых объектов проектного решения
Тестирование высокоуровневой интеграции
Оценка системы на предмет соответствия требованиям
Создание компонентов системы
Интеграция и тестирование компонентов
Повторная оценка системы на предмет соответствия требованиям
Тестирование комплектной системы
Исправление неисправностей системы в преддверии альфа-тестирования
Начало альфа-тестирования
Исправление ошибок, выявленных на этапе альфа-тестирования
Начало бета-тестирования
Разработка стратегии развертывания
Исправление ошибок, выявленных на этапе бета-тестирования
Тестирование стратегии развертывания
Тестирование конечного продукта
Развертывание программного обеспечения
72 .... Как объединить усилия тех, кто гуляет сам по себе
73 .... Опасность!
74 .... Как сформировать команду и как ее поддерживать
Как нанимать сотрудников
Кошачьи разборки - блюз одинокого ферзя
Как увольнять сотрудников
Денежное поощрение и продвижение сотрудников по службе
Как готовить преемника
79 .... Ну хватит уже!
81 .... Глава 4. Как организовать успех
82 .... Как превратить информацию в знания и действия
Бумажная волокита
Безбумажная волокита
Электронный администратор
Задача как объект - основной организующий принцип электронного администратора
Отображение и систематизация заданий
90 .... Как выработать собственные навыки администрирования
91 .... Как организовать контроль
Информационный поток
Назначение заданий
Архитектура
Рабочие часы
Ожидания
Взаимоотношения
98 .... Как повысить организованность в масштабах всей компании
Руководство продуктами
Определение проекта
Руководство процессами
Тестирование
Руководство инфраструктурой
Организуйте сотрудничество и уединение
Предоставляйте лучший инструментарий
105 ... В конце рабочего дня
107 ... Глава 5. Как вести совещания
107 ... Еженедельные совещания
110 ... Проектные совещания
114 ... Кошачьи разборки - чужак
116 ... Беседы один на один
117 ... Совещания с другими группами
119 ... Ретроспективные совещания
120 ... Телеконференции
121 ... Время между совещаниями
122 ... Консенсус и действия в результате совещаний
124 ... Глава 6. Философия и методы технического лидера
125 ... Как уразуметь свою роль и придерживаться ее
126 ... Конструировать или выращивать
127 ... Примат архитектуры
Проектные ограничения в архитектурном планировании
Аналитические позиции как средство управления проектными ограничениями
Свежий взгляд на проектирование
Нулевой этап проектирования
Этапы проектирования 1, 2, 3, 2, 1, 4...
Принципы проектирования
Принципы успеха
138 ... Кошачьи разборки - не спи за рулем
139 ... Кодовая полиция
Следите за законностью
Наиболее распространенные нарушения
Нарушение стандартов
Слабая связность и сильная взаимозависимость
Скорый суд и неотвратимость наказания
143 ... Философия в действии
Конкретный пример философии в действии - Леонардо да Винчи
Ложка дегтя
145 ... Перспективы
147 ... Глава 7. Закат лидера
148 ... Обличие тьмы
148 ... Негативные эталоны в менеджменте
150 ... Мелочная опека
Всезнайка
Диктатор
Генерал
Кошачьи разборки - самодур
Советы тем, кто увлекается мелочной опекой
155 ... Неорганизованные руководители
Скарлетт О'Хара
Временщик
Новичок
158 ... Гений не на месте
160 ... Строители империй тьмы
162 ... Заигрывание с дьяволом
Вы достигли своего предела
Вы прыгнули выше головы
Вас бесит критика
163 ... Как выжить в период упадка и восстать из пепла
164 ... Как избежать заката
167 ... Глава 8. Восход лидера
168 ... Фундаментальные принципы лидерства
Понимание
Передача знаний
Делегирование
Проверка
Участие
176 ... Надстройка
Наставничество
Вознаграждение
Исправления
Предвидение
Адаптация
182 ... Пойдут ли за вами?
Принуждение
Долг
Восхищение
Вознаграждение
Знание
185 ... Возрастные аспекты лидерства
187 ... Как лидеру сочетать форму и содержание
Энди Гроув - агрессивный параноик
Билл Гейтс - одержимость и расчетливость
Вы - _____________ (введите недостающее слово)
190 ... Резюме
Лидерство формируется в практической деятельности
Отталкивайтесь от основных принципов лидерства
193 ... Глава 9. Как ужиться с начальством
193 ... Как понять, чем живет ваша начальница
195 ... Честность и принципиальность против подтасовок и лжи
197 ... Как помочь начальнице удачно спланировать процесс
Дисциплина
Компетентность
Уверенность
Ответственность
Упорство
Командные усилия
199 ... Знайте свой потолок
200 ... Как ожидать неожиданность
201 ... Как преодолеть безынициативность компании
Следите за тенденциями в отрасли
Экспериментируйте с новыми методами и приемами
Учитесь чувствовать время
Не забывайте, что интересы клиента на первом месте
204 ... Резюме
205 ... Глава 10. Слова без песни
206 ... Распределенная рабочая сила
Суть проблемы
Решение
Планирование
Взаимодействие
Проверка
Личные контакты
210 ... Культурный фактор в менеджменте
Язык и культура
Мотивация чужаков и контроль над ними
Кошачьи разборки - иностранный легион
213 ... Оценка методологий разработки программных средств
Программная инженерия
MSF
Экстремальное программирование
Гибкая разработка
Мастерство - ядро любого успеха
221 ... Технологические революции
223 ... Экономические несчастья
224 ... Одиночество руководителей
Уделяйте время исследовательской работе
Как превратить административные функции в инженерные
Стратегическое планирование как наука
Учитесь ценить человеческие отношения
226 ... Финал
228 ... Послесловие. Снова в плавание
228 ... Руль
229 ... Парус
231 ... Якорь
233 ... Приложение А. Как ухаживать за живностью - электронный администратор
237 ... Приложение Б. Как дать скотине в глаз - критический обзор кода электронного администратора
237 ... Контекст и происхождение программного продукта
237 ... Правила игры
Следовал ли я стандартам?
Как насчет связности и взаимозависимости?
Другие достоинства и недостатки
Как проводится подключение к базе данных?
Какую роль в моей программе исполняют структуры записей?
Есть ли в коде волшебные числа?
242 ... Заключение
243 ... Библиография. Ресурсы для специалистов по выпасу котов
Разработка программного обеспечения
Классические труды
Выдающиеся работы
Примечательные работы
Полезные работы
Общие работы по менеджменту
Работы по языкам программирования
Разные работы
250 ... Алфавитный указательЦитаты
стр. 13. В конце концов, личность в сегодняшних условиях - это опыт плюс прочитанная литература. ...
стр. 29. Тем не менее возьму на себя смелость вас предостеречь: становясь руководителями, даже самые крутые ...
стр. 30. Элен Алман (Ellen Ullman) "Close to the Machine" ...
стр. 37. Лично я предпочитаю термину "жучок" (bug) словосочетания "программная аномалия" (program anomaly) и...
стр. 40. Если хотите похвалить человека, делайте это на виду у всех. Если считаете нужным покритиковать его,...
стр. 52. Вы уже много раз слышали: если у вас не хватает времени даже на то, чтобы сделать все правильно, гд...
стр. 53. Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования - только начальн...
стр. 54. ... смотрите на прототип как на продолжение документа, а не как на начало проекта. Прототипы служат...
стр. 65. Если уж у вас есть задача организовать производство программного продукта, остальные сведения, отвл...
стр. 71. В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласс (Robert Gl...
стр. 80. Если попробовать свести содержание этой главы к нескольким четким и удобоваримым принципам, получит...
стр. 81. Организованный менеджер сам создает для себя условия, в которых его лидерские качества начинают рас...
стр. 96. Ричард Карлсон (Richard Carlson), заслуживший за свою книгу "Don't Sweat the Small Staff" исключите...
стр. 114. Дипломатия - это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и посто...
стр. 120. Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и под...
стр. 122. Итак, участвую в совещаниях или ведя совещания, придерживайтесь следующих принципов. * Не превращай...
стр. 128. Марк и Лора Сьюелл (Mark & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейш...
стр. 129. Проектные ограничения - это те факторы, которые необходимо учитывать с самого начала процесса разра...
стр. 130. Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько о...
стр. 136. ... принципы кодирования, подобные следующим: * Следование стандартам программирования, принятым дл...
стр. 138. По его понятиям, быстрое исправление кода сводилось к созданию очередной глобальной константы, пере...
стр. 140. Кейперс Джонс (Capers Jones) в своей книге "Applied Software Measurement" утверждает, что наиболее ...
стр. 143. Некачественная или случайная архитектура приводит к таким последствиям: * сверхтрудное сопровождени...
стр. 164. Начните с людей. Найдите тех, кто пострадал из-за допущенных вами ошибок, и извинитесь перед ними. ...
стр. 207. Документы же должны быть не средством, а результатом сотрудничества. ...
стр. 209. В отсутствие начальника люди начинают валять дурака - это в природе человека. Как с этим бороться? ...
стр. 212. Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом зна...
стр. 13
В конце концов, личность в сегодняшних условиях - это опыт плюс прочитанная литература.
стр. 29
Тем не менее возьму на себя смелость вас предостеречь: становясь руководителями, даже самые крутые программисты не всегда идеально справляются со своими новыми обязанностями. У них возникает непреодолимое желание самим работать надо проектами, которые, по идее, нужно делегировать подчиненным. Они тратят уйму времени на обзоры кода, хотя на это хватит и часа. Они пытаются вылизать все комментарии и отступы. Иногда они бросают попытки объяснить окружающим, что они от этих окружающих хотят, и пытаются все делать сами.
стр. 30
Элен Алман (Ellen Ullman) "Close to the Machine"
стр. 37
Лично я предпочитаю термину "жучок" (bug) словосочетания "программная аномалия" (program anomaly) и "открытие недокументированной характеристики" (Undocumented Feature Offering, UFO).
стр. 40
Если хотите похвалить человека, делайте это на виду у всех. Если считаете нужным покритиковать его, не выносите свои оценки на суд публики. Дело не просто в вежливости - эти правила поведения важны в том смысле, что как похвала, так и порицание одного человека на самом деле оказывают грандиозное влияние на всю группу. Поверьте мне, публичное унижение не способствует повышению продуктивности работы группы. Наоборот, похвала, высказанная при всех, причем искренне и по заслугам, способна творить чудеса.
стр. 52
Вы уже много раз слышали: если у вас не хватает времени даже на то, чтобы сделать все правильно, где же вы его найдете на то, чтобы все переделать?
стр. 53
Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования - только начальный этап разработки документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить о реализации решения в объектах кода. У вас всегда будет искушение, когда поджимает время (а разве бывает иначе?), слепить все "по-быстрому", однако надо быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программный продукт, который можно будет в дальнейшем дополнять и обновлять.
стр. 54
... смотрите на прототип как на продолжение документа, а не как на начало проекта. Прототипы служат для обоснования готовой концепции, в то время как программные продукты представляют собой реализацию готового проекта.
стр. 65
Если уж у вас есть задача организовать производство программного продукта, остальные сведения, отвлекающие от этой задачи, независимо от того, насколько важными они кажутся, нужно отложить.
стр. 71
В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласс (Robert Glass) составил список наиболее распространенных "программных катастроф", который я привожу в порядке снижения их значимости.
1. Неадекватное специфицирование задач проекта (51%).
2. Неудовлетворительные планирование и оценка (48%).
3. Применение новой для данной компании технологии (45%).
4. Негодная/отсутствующая методология руководства проектом (42%).
5. Нехватка ведущих специалистов группы (42%).
6. Срыв договоренностей производителями аппаратного/программного обеспечения (42%).
Robert L. Glass, Software Runaways (Upper Saddle River, NJ: Prentice Hall, 1998)
стр. 80
Если попробовать свести содержание этой главы к нескольким четким и удобоваримым принципам, получится, что руководитель:
* расставляет приоритеты и борется с раздражителями (фокусируется на поставленных задачах);
* совершенствует свои навыки в области руководства проектами и прорабатывает все их детали;
* пресекает низкое качество кодирования, пока оно не пустило в проекте корни;
* стремясь по достоинству оценивать технологические новинки, учится быстро усваивать неизвестную информацию;
* благоразумно относится к кадровому обеспечению и понимает, что именно от людей зависит конечный успех проекта.
стр. 81
Организованный менеджер сам создает для себя условия, в которых его лидерские качества начинают расцветать.
стр. 96
Ричард Карлсон (Richard Carlson), заслуживший за свою книгу "Don't Sweat the Small Staff" исключительной похвалы, рассуждает об обещаниях следующим образом:
"Некоторые обещания, которые мы даем окружающим людям, на первый взгляд, и не кажутся таковыми. Иногда мы даем их, сами того не сознавая. Чего стоят выражения типа "я тебе перезвоню позже", "я подъеду к тебе на работу", "на следующей неделе я вышлю тебе экземпляр моей книги", "я с удовольствием куплю ее тебе", "если тебя понадобится сменить, дай мне знать". Даже невинные в первом приближении фразы типа "без проблем" представляют для сказавшего некоторую опасность - дело в том, что их часто воспринимают как предложение выполнить некоторое действие, хотя на самом деле вы либо не хотите этим заниматься, либо не располагаете для этого достаточными ресурсами. Фактически, сказав так, вы позволили собеседнику высказать к вам более серьезную просьбу, чем раньше, - ведь это не проблема!"
стр. 114
Дипломатия - это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.
стр. 120
Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и подобными действиями вы только подогреваете нашу и без того пожароопасную индустрию, в которой программисты при оценке своих попыток соблюдения контрольных сроков проявляют себя убежденными идеалистами.
стр. 122
Итак, участвую в совещаниях или ведя совещания, придерживайтесь следующих принципов.
* Не превращайте совещание в партсобрание. Участие в совещаниях - это тоже работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмысленно.
* При проведении проектных совещаний обязательно подготавливайте четкий план действий. Руководите разумно и учитывайте фактор группового поведения.
* Проводя беседы с сотрудниками один на один, следуйте принципам, характерным для совещаний в более крупном составе: пытайтесь достичь консенсуса и выстроить план действий.
* Проводя совещания с нетехническими специалистами, помните, что вы олицетворяете образ технаря. Пытайтесь доносить сложные идеи простым языком. Попытки произвести на бухгалтерских работников впечатление, жонглируя таинственными сокращениями, вряд ли прибавит вам уважения. На таких совещаниях ведите себя как педагог. В то же время исполняйте эту роль предусмотрительно, избегайте высокомерия.
* Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.
* Старайтесь свести количество телеконференций к минимуму. Путем тщательной подготовки и составления четкого плана старайтесь делать их как можно насыщеннее.
стр. 128
Марк и Лора Сьюелл (Mark & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана. С точки зрения этих авторов, любой архитектор должен:
* в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;
* хорошо разбираться в предметной области клиента - будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;
* получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;
* иметь комплексные познания в технологической области - для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;
* наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;
* уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.
Marc T. Sewell and Laura M. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002.
стр. 129
Проектные ограничения - это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже:
* Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?
* Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?
* Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?
* Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.
* В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.
* Достаточна ли компетентность персонала для сопровождения систем, простроенных на основе новых технологий? Если в конструировании применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?
стр. 130
Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько общих аналитических позиций, формулируя их в виде вопросов.
* Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)
* Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?
* Каков механизм взаимодействия компонентов, благодаря которому система функционирует?
* Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?
* Как предполагается поставить систему клиенту?
стр. 136
... принципы кодирования, подобные следующим:
* Следование стандартам программирования, принятым для данного языка. Это обеспечивает единообразие методик конструирования объектов, применяемых разными программистами. (В этом контексте имеет полное право на существование метафора строительства.)
* Поощрение связности объектов. Не следует воспринимать объекты как контейнеры для размещения совокупности процедур - скорее это органы, выполняющие конкретную функцию. Как известно, сердце не пытается дышать, а легкие не качают кровь.
* Ограничение взаимозависимости объектов. В отсутствие серьезных аргументов в пользу иной точки зрения взаимозависимость приносит одни неприятности, превращая сопровождение в сплошной кошмар. Чтобы однажды сделанные взаимозависимыми объекты превратить в независимые, требуются дополнительные временные и финансовые ресурсы.
стр. 138
По его понятиям, быстрое исправление кода сводилось к созданию очередной глобальной константы, передающей информацию между объектами, с попутным загаживанием своего рабочего места остатками тут же поедаемого хот-дога.
стр. 140
Кейперс Джонс (Capers Jones) в своей книге "Applied Software Measurement" утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками:
1. Они проводят точные измерения продуктивности и качества программных продуктов.
2. Они тщательно планируют и оценивают программные продукты.
3. У них работают квалифицированные менеджеры и технические специалисты.
4. У них адекватные организационные структуры.
5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.
6. Их сотрудники работают в достойных условиях.
стр. 143
Некачественная или случайная архитектура приводит к таким последствиям:
* сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;
* нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;
* размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.
Ниже перечислены последствия неадекватного проектирования:
* из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;
* модификация в одном месте приводит к нарушению в нескольких других;
* вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.
стр. 164
Начните с людей. Найдите тех, кто пострадал из-за допущенных вами ошибок, и извинитесь перед ними. Не ищите себе оправданий - признайте свою неправоту. Не вдавайтесь в сентиментальность или драматизм - просто дайте знать, что вы сожалеете о том, что случилось, и двигайтесь дальше. Незаслуженно пострадавшие ждут, когда перед ними извинятся, и если вы признаете свои ошибки, вас будут уважать за честность. Дело не в том, чтобы установить теплые отношения, а в том, чтобы восстановить фундамент лидерства. Необходимость ставить точки на "i" в ваших отношениях с персоналом не слишком приятна, но без этого не обойтись. Если вы ранее успели проявить лидерские качества, сотрудники вас простят. Не обманывайте их ожидания - не извиняйтесь по электронной почте. Если обида носит личный характер, то и извиняться надо без посредников - в конце концов, никто не заставляет вас документировать свои огрехи.
стр. 207
Документы же должны быть не средством, а результатом сотрудничества.
стр. 209
В отсутствие начальника люди начинают валять дурака - это в природе человека. Как с этим бороться? Сравнительно эффективный мониторинг возможен только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения.
стр. 212
Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.
Сейчас читаю
Дж. Ханк Рейнвотер
Как пасти котов. Наставление для программистов, руководящих другими программистами
СПб.: Питер, 2006 г., 256 стр.
Перевод с англ. Ю. Гороховского
Herding Cats: A Primer for Programmers Who Lead Programmers, by J. Hank Rainwater
Thanks to geni.
На этой странице:
Краткое содержание
12 .... Предисловие
15 .... Об авторе
16 .... О научном редакторе
17 .... Об иллюстраторе
18 .... Благодарности
20 .... Введение
26 .... Глава 1. Как привыкнуть к роли лидера
46 .... Глава 2. Как руководить собой
63 .... Глава 3. Как вести стаю за собой
81 .... Глава 4. Как организовать успех
107 ... Глава 5. Как вести совещания
124 ... Глава 6. Философия и методы технического лидера
147 ... Глава 7. Закат лидера
167 ... Глава 8. Восход лидера
193 ... Глава 9. Как ужиться с начальством
205 ... Глава 10. Слова без песни
228 ... Послесловие. Снова в плавание
233 ... Приложение А. Как ухаживать за живностью - электронный администратор
237 ... Приложение Б. Как дать скотине в глаз - критический обзор кода электронного администратора
243 ... Библиография. Ресурсы для специалистов по выпасу котов
250 ... Алфавитный указательПолное содержание
12 .... Предисловие
15 .... Об авторе
16 .... О научном редакторе
17 .... Об иллюстраторе
18 .... Благодарности
20 .... Введение
20 .... Структура книги
24 .... Кому и зачем стоит прочесть эту книгу
24 .... Стиль и позиция
26 .... Глава 1. Как привыкнуть к роли лидера
27 .... Правда ли, что настоящие руководители ходят в черном?
Насколько важно быть крутым?
Насколько вы крутой?
Мало быть крутым - смотри в оба!
30 .... Как руководить чокнутыми, чудаковатыми, странными и обычными программистами
Какие бывают породы программистов
Распространенные породы
Архитектор
Конструктивист
Художник
Инженер
Ученый
Лихач
Редкие породы
Волшебник
Минималист
Аналогист
Трюкач
Дворняги
Разгильдяй
Тормоз
Любитель
Профан
Эклектик
Умение обращаться с представителями разных пород
Кошачьи разборки - соревнование по шипению и царапанию
40 .... Слава, почет и деньги
Мотивирование деньгами
42 .... Уровень мышления
44 .... Как вы адаптируетесь
46 .... Глава 2. Как руководить собой
46 .... Взгляд в зеркало
48 .... Рай, ад, чистилище и ваше место во вселенной
Ваша работа в корне меняется
Вам нужно заново учиться оценивать свои успехи, увлечения, амбиции
50 .... Естественный отбор и время
Избегайте ненужных, неэффективных совещаний
Не планируйте слишком мало или слишком много
Бессмысленно ожидать чего-либо при отсутствии контроля
Проектируйте архитектуру, прежде чем выбирать технологию
Баланс между чистотой и практичностью
Не выполняйте задания, а распределяйте их
Документируйте то, что вы делаете или планируете делать
54 .... Оценка вашей производительности
55 .... Контролируйте свои слабости
58 .... Ответы
61 .... Кошачьи разборки - похоронный марш
63 .... Глава 3. Как вести стаю за собой
63 .... Как справиться с административными функциями
66 .... Как не отвлекаться на раздражители
68 .... Когда проект разрастается
Нереалистичный план проекта
Анализ требований
Создание проектного решения
Реализация проектного решения
Тестирование программного обеспечения
Исправление ошибок
Развертывание программного обеспечения
Реалистичный план проекта
Анализ требований
Обсуждение результатов анализа с сотрудниками отдела
Создание проектного решения
Макетирование проектного решения
Оценка макетов
Пересмотр проектного решения
Реализация высокоуровневых объектов проектного решения
Тестирование высокоуровневой интеграции
Оценка системы на предмет соответствия требованиям
Создание компонентов системы
Интеграция и тестирование компонентов
Повторная оценка системы на предмет соответствия требованиям
Тестирование комплектной системы
Исправление неисправностей системы в преддверии альфа-тестирования
Начало альфа-тестирования
Исправление ошибок, выявленных на этапе альфа-тестирования
Начало бета-тестирования
Разработка стратегии развертывания
Исправление ошибок, выявленных на этапе бета-тестирования
Тестирование стратегии развертывания
Тестирование конечного продукта
Развертывание программного обеспечения
72 .... Как объединить усилия тех, кто гуляет сам по себе
73 .... Опасность!
74 .... Как сформировать команду и как ее поддерживать
Как нанимать сотрудников
Кошачьи разборки - блюз одинокого ферзя
Как увольнять сотрудников
Денежное поощрение и продвижение сотрудников по службе
Как готовить преемника
79 .... Ну хватит уже!
81 .... Глава 4. Как организовать успех
82 .... Как превратить информацию в знания и действия
Бумажная волокита
Безбумажная волокита
Электронный администратор
Задача как объект - основной организующий принцип электронного администратора
Отображение и систематизация заданий
90 .... Как выработать собственные навыки администрирования
91 .... Как организовать контроль
Информационный поток
Назначение заданий
Архитектура
Рабочие часы
Ожидания
Взаимоотношения
98 .... Как повысить организованность в масштабах всей компании
Руководство продуктами
Определение проекта
Руководство процессами
Тестирование
Руководство инфраструктурой
Организуйте сотрудничество и уединение
Предоставляйте лучший инструментарий
105 ... В конце рабочего дня
107 ... Глава 5. Как вести совещания
107 ... Еженедельные совещания
110 ... Проектные совещания
114 ... Кошачьи разборки - чужак
116 ... Беседы один на один
117 ... Совещания с другими группами
119 ... Ретроспективные совещания
120 ... Телеконференции
121 ... Время между совещаниями
122 ... Консенсус и действия в результате совещаний
124 ... Глава 6. Философия и методы технического лидера
125 ... Как уразуметь свою роль и придерживаться ее
126 ... Конструировать или выращивать
127 ... Примат архитектуры
Проектные ограничения в архитектурном планировании
Аналитические позиции как средство управления проектными ограничениями
Свежий взгляд на проектирование
Нулевой этап проектирования
Этапы проектирования 1, 2, 3, 2, 1, 4...
Принципы проектирования
Принципы успеха
138 ... Кошачьи разборки - не спи за рулем
139 ... Кодовая полиция
Следите за законностью
Наиболее распространенные нарушения
Нарушение стандартов
Слабая связность и сильная взаимозависимость
Скорый суд и неотвратимость наказания
143 ... Философия в действии
Конкретный пример философии в действии - Леонардо да Винчи
Ложка дегтя
145 ... Перспективы
147 ... Глава 7. Закат лидера
148 ... Обличие тьмы
148 ... Негативные эталоны в менеджменте
150 ... Мелочная опека
Всезнайка
Диктатор
Генерал
Кошачьи разборки - самодур
Советы тем, кто увлекается мелочной опекой
155 ... Неорганизованные руководители
Скарлетт О'Хара
Временщик
Новичок
158 ... Гений не на месте
160 ... Строители империй тьмы
162 ... Заигрывание с дьяволом
Вы достигли своего предела
Вы прыгнули выше головы
Вас бесит критика
163 ... Как выжить в период упадка и восстать из пепла
164 ... Как избежать заката
167 ... Глава 8. Восход лидера
168 ... Фундаментальные принципы лидерства
Понимание
Передача знаний
Делегирование
Проверка
Участие
176 ... Надстройка
Наставничество
Вознаграждение
Исправления
Предвидение
Адаптация
182 ... Пойдут ли за вами?
Принуждение
Долг
Восхищение
Вознаграждение
Знание
185 ... Возрастные аспекты лидерства
187 ... Как лидеру сочетать форму и содержание
Энди Гроув - агрессивный параноик
Билл Гейтс - одержимость и расчетливость
Вы - _____________ (введите недостающее слово)
190 ... Резюме
Лидерство формируется в практической деятельности
Отталкивайтесь от основных принципов лидерства
193 ... Глава 9. Как ужиться с начальством
193 ... Как понять, чем живет ваша начальница
195 ... Честность и принципиальность против подтасовок и лжи
197 ... Как помочь начальнице удачно спланировать процесс
Дисциплина
Компетентность
Уверенность
Ответственность
Упорство
Командные усилия
199 ... Знайте свой потолок
200 ... Как ожидать неожиданность
201 ... Как преодолеть безынициативность компании
Следите за тенденциями в отрасли
Экспериментируйте с новыми методами и приемами
Учитесь чувствовать время
Не забывайте, что интересы клиента на первом месте
204 ... Резюме
205 ... Глава 10. Слова без песни
206 ... Распределенная рабочая сила
Суть проблемы
Решение
Планирование
Взаимодействие
Проверка
Личные контакты
210 ... Культурный фактор в менеджменте
Язык и культура
Мотивация чужаков и контроль над ними
Кошачьи разборки - иностранный легион
213 ... Оценка методологий разработки программных средств
Программная инженерия
MSF
Экстремальное программирование
Гибкая разработка
Мастерство - ядро любого успеха
221 ... Технологические революции
223 ... Экономические несчастья
224 ... Одиночество руководителей
Уделяйте время исследовательской работе
Как превратить административные функции в инженерные
Стратегическое планирование как наука
Учитесь ценить человеческие отношения
226 ... Финал
228 ... Послесловие. Снова в плавание
228 ... Руль
229 ... Парус
231 ... Якорь
233 ... Приложение А. Как ухаживать за живностью - электронный администратор
237 ... Приложение Б. Как дать скотине в глаз - критический обзор кода электронного администратора
237 ... Контекст и происхождение программного продукта
237 ... Правила игры
Следовал ли я стандартам?
Как насчет связности и взаимозависимости?
Другие достоинства и недостатки
Как проводится подключение к базе данных?
Какую роль в моей программе исполняют структуры записей?
Есть ли в коде волшебные числа?
242 ... Заключение
243 ... Библиография. Ресурсы для специалистов по выпасу котов
Разработка программного обеспечения
Классические труды
Выдающиеся работы
Примечательные работы
Полезные работы
Общие работы по менеджменту
Работы по языкам программирования
Разные работы
250 ... Алфавитный указательЦитаты
стр. 13. В конце концов, личность в сегодняшних условиях - это опыт плюс прочитанная литература. ...
стр. 29. Тем не менее возьму на себя смелость вас предостеречь: становясь руководителями, даже самые крутые ...
стр. 30. Элен Алман (Ellen Ullman) "Close to the Machine" ...
стр. 37. Лично я предпочитаю термину "жучок" (bug) словосочетания "программная аномалия" (program anomaly) и...
стр. 40. Если хотите похвалить человека, делайте это на виду у всех. Если считаете нужным покритиковать его,...
стр. 52. Вы уже много раз слышали: если у вас не хватает времени даже на то, чтобы сделать все правильно, гд...
стр. 53. Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования - только начальн...
стр. 54. ... смотрите на прототип как на продолжение документа, а не как на начало проекта. Прототипы служат...
стр. 65. Если уж у вас есть задача организовать производство программного продукта, остальные сведения, отвл...
стр. 71. В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласс (Robert Gl...
стр. 80. Если попробовать свести содержание этой главы к нескольким четким и удобоваримым принципам, получит...
стр. 81. Организованный менеджер сам создает для себя условия, в которых его лидерские качества начинают рас...
стр. 96. Ричард Карлсон (Richard Carlson), заслуживший за свою книгу "Don't Sweat the Small Staff" исключите...
стр. 114. Дипломатия - это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и посто...
стр. 120. Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и под...
стр. 122. Итак, участвую в совещаниях или ведя совещания, придерживайтесь следующих принципов. * Не превращай...
стр. 128. Марк и Лора Сьюелл (Mark & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейш...
стр. 129. Проектные ограничения - это те факторы, которые необходимо учитывать с самого начала процесса разра...
стр. 130. Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько о...
стр. 136. ... принципы кодирования, подобные следующим: * Следование стандартам программирования, принятым дл...
стр. 138. По его понятиям, быстрое исправление кода сводилось к созданию очередной глобальной константы, пере...
стр. 140. Кейперс Джонс (Capers Jones) в своей книге "Applied Software Measurement" утверждает, что наиболее ...
стр. 143. Некачественная или случайная архитектура приводит к таким последствиям: * сверхтрудное сопровождени...
стр. 164. Начните с людей. Найдите тех, кто пострадал из-за допущенных вами ошибок, и извинитесь перед ними. ...
стр. 207. Документы же должны быть не средством, а результатом сотрудничества. ...
стр. 209. В отсутствие начальника люди начинают валять дурака - это в природе человека. Как с этим бороться? ...
стр. 212. Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом зна...
стр. 13
В конце концов, личность в сегодняшних условиях - это опыт плюс прочитанная литература.
стр. 29
Тем не менее возьму на себя смелость вас предостеречь: становясь руководителями, даже самые крутые программисты не всегда идеально справляются со своими новыми обязанностями. У них возникает непреодолимое желание самим работать надо проектами, которые, по идее, нужно делегировать подчиненным. Они тратят уйму времени на обзоры кода, хотя на это хватит и часа. Они пытаются вылизать все комментарии и отступы. Иногда они бросают попытки объяснить окружающим, что они от этих окружающих хотят, и пытаются все делать сами.
стр. 30
Элен Алман (Ellen Ullman) "Close to the Machine"
стр. 37
Лично я предпочитаю термину "жучок" (bug) словосочетания "программная аномалия" (program anomaly) и "открытие недокументированной характеристики" (Undocumented Feature Offering, UFO).
стр. 40
Если хотите похвалить человека, делайте это на виду у всех. Если считаете нужным покритиковать его, не выносите свои оценки на суд публики. Дело не просто в вежливости - эти правила поведения важны в том смысле, что как похвала, так и порицание одного человека на самом деле оказывают грандиозное влияние на всю группу. Поверьте мне, публичное унижение не способствует повышению продуктивности работы группы. Наоборот, похвала, высказанная при всех, причем искренне и по заслугам, способна творить чудеса.
стр. 52
Вы уже много раз слышали: если у вас не хватает времени даже на то, чтобы сделать все правильно, где же вы его найдете на то, чтобы все переделать?
стр. 53
Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования - только начальный этап разработки документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить о реализации решения в объектах кода. У вас всегда будет искушение, когда поджимает время (а разве бывает иначе?), слепить все "по-быстрому", однако надо быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программный продукт, который можно будет в дальнейшем дополнять и обновлять.
стр. 54
... смотрите на прототип как на продолжение документа, а не как на начало проекта. Прототипы служат для обоснования готовой концепции, в то время как программные продукты представляют собой реализацию готового проекта.
стр. 65
Если уж у вас есть задача организовать производство программного продукта, остальные сведения, отвлекающие от этой задачи, независимо от того, насколько важными они кажутся, нужно отложить.
стр. 71
В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласс (Robert Glass) составил список наиболее распространенных "программных катастроф", который я привожу в порядке снижения их значимости.
1. Неадекватное специфицирование задач проекта (51%).
2. Неудовлетворительные планирование и оценка (48%).
3. Применение новой для данной компании технологии (45%).
4. Негодная/отсутствующая методология руководства проектом (42%).
5. Нехватка ведущих специалистов группы (42%).
6. Срыв договоренностей производителями аппаратного/программного обеспечения (42%).
Robert L. Glass, Software Runaways (Upper Saddle River, NJ: Prentice Hall, 1998)
стр. 80
Если попробовать свести содержание этой главы к нескольким четким и удобоваримым принципам, получится, что руководитель:
* расставляет приоритеты и борется с раздражителями (фокусируется на поставленных задачах);
* совершенствует свои навыки в области руководства проектами и прорабатывает все их детали;
* пресекает низкое качество кодирования, пока оно не пустило в проекте корни;
* стремясь по достоинству оценивать технологические новинки, учится быстро усваивать неизвестную информацию;
* благоразумно относится к кадровому обеспечению и понимает, что именно от людей зависит конечный успех проекта.
стр. 81
Организованный менеджер сам создает для себя условия, в которых его лидерские качества начинают расцветать.
стр. 96
Ричард Карлсон (Richard Carlson), заслуживший за свою книгу "Don't Sweat the Small Staff" исключительной похвалы, рассуждает об обещаниях следующим образом:
"Некоторые обещания, которые мы даем окружающим людям, на первый взгляд, и не кажутся таковыми. Иногда мы даем их, сами того не сознавая. Чего стоят выражения типа "я тебе перезвоню позже", "я подъеду к тебе на работу", "на следующей неделе я вышлю тебе экземпляр моей книги", "я с удовольствием куплю ее тебе", "если тебя понадобится сменить, дай мне знать". Даже невинные в первом приближении фразы типа "без проблем" представляют для сказавшего некоторую опасность - дело в том, что их часто воспринимают как предложение выполнить некоторое действие, хотя на самом деле вы либо не хотите этим заниматься, либо не располагаете для этого достаточными ресурсами. Фактически, сказав так, вы позволили собеседнику высказать к вам более серьезную просьбу, чем раньше, - ведь это не проблема!"
стр. 114
Дипломатия - это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.
стр. 120
Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и подобными действиями вы только подогреваете нашу и без того пожароопасную индустрию, в которой программисты при оценке своих попыток соблюдения контрольных сроков проявляют себя убежденными идеалистами.
стр. 122
Итак, участвую в совещаниях или ведя совещания, придерживайтесь следующих принципов.
* Не превращайте совещание в партсобрание. Участие в совещаниях - это тоже работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмысленно.
* При проведении проектных совещаний обязательно подготавливайте четкий план действий. Руководите разумно и учитывайте фактор группового поведения.
* Проводя беседы с сотрудниками один на один, следуйте принципам, характерным для совещаний в более крупном составе: пытайтесь достичь консенсуса и выстроить план действий.
* Проводя совещания с нетехническими специалистами, помните, что вы олицетворяете образ технаря. Пытайтесь доносить сложные идеи простым языком. Попытки произвести на бухгалтерских работников впечатление, жонглируя таинственными сокращениями, вряд ли прибавит вам уважения. На таких совещаниях ведите себя как педагог. В то же время исполняйте эту роль предусмотрительно, избегайте высокомерия.
* Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.
* Старайтесь свести количество телеконференций к минимуму. Путем тщательной подготовки и составления четкого плана старайтесь делать их как можно насыщеннее.
стр. 128
Марк и Лора Сьюелл (Mark & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана. С точки зрения этих авторов, любой архитектор должен:
* в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;
* хорошо разбираться в предметной области клиента - будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;
* получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;
* иметь комплексные познания в технологической области - для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;
* наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;
* уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.
Marc T. Sewell and Laura M. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002.
стр. 129
Проектные ограничения - это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже:
* Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?
* Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?
* Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?
* Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.
* В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.
* Достаточна ли компетентность персонала для сопровождения систем, простроенных на основе новых технологий? Если в конструировании применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?
стр. 130
Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько общих аналитических позиций, формулируя их в виде вопросов.
* Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)
* Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?
* Каков механизм взаимодействия компонентов, благодаря которому система функционирует?
* Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?
* Как предполагается поставить систему клиенту?
стр. 136
... принципы кодирования, подобные следующим:
* Следование стандартам программирования, принятым для данного языка. Это обеспечивает единообразие методик конструирования объектов, применяемых разными программистами. (В этом контексте имеет полное право на существование метафора строительства.)
* Поощрение связности объектов. Не следует воспринимать объекты как контейнеры для размещения совокупности процедур - скорее это органы, выполняющие конкретную функцию. Как известно, сердце не пытается дышать, а легкие не качают кровь.
* Ограничение взаимозависимости объектов. В отсутствие серьезных аргументов в пользу иной точки зрения взаимозависимость приносит одни неприятности, превращая сопровождение в сплошной кошмар. Чтобы однажды сделанные взаимозависимыми объекты превратить в независимые, требуются дополнительные временные и финансовые ресурсы.
стр. 138
По его понятиям, быстрое исправление кода сводилось к созданию очередной глобальной константы, передающей информацию между объектами, с попутным загаживанием своего рабочего места остатками тут же поедаемого хот-дога.
стр. 140
Кейперс Джонс (Capers Jones) в своей книге "Applied Software Measurement" утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками:
1. Они проводят точные измерения продуктивности и качества программных продуктов.
2. Они тщательно планируют и оценивают программные продукты.
3. У них работают квалифицированные менеджеры и технические специалисты.
4. У них адекватные организационные структуры.
5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.
6. Их сотрудники работают в достойных условиях.
стр. 143
Некачественная или случайная архитектура приводит к таким последствиям:
* сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;
* нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;
* размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.
Ниже перечислены последствия неадекватного проектирования:
* из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;
* модификация в одном месте приводит к нарушению в нескольких других;
* вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.
стр. 164
Начните с людей. Найдите тех, кто пострадал из-за допущенных вами ошибок, и извинитесь перед ними. Не ищите себе оправданий - признайте свою неправоту. Не вдавайтесь в сентиментальность или драматизм - просто дайте знать, что вы сожалеете о том, что случилось, и двигайтесь дальше. Незаслуженно пострадавшие ждут, когда перед ними извинятся, и если вы признаете свои ошибки, вас будут уважать за честность. Дело не в том, чтобы установить теплые отношения, а в том, чтобы восстановить фундамент лидерства. Необходимость ставить точки на "i" в ваших отношениях с персоналом не слишком приятна, но без этого не обойтись. Если вы ранее успели проявить лидерские качества, сотрудники вас простят. Не обманывайте их ожидания - не извиняйтесь по электронной почте. Если обида носит личный характер, то и извиняться надо без посредников - в конце концов, никто не заставляет вас документировать свои огрехи.
стр. 207
Документы же должны быть не средством, а результатом сотрудничества.
стр. 209
В отсутствие начальника люди начинают валять дурака - это в природе человека. Как с этим бороться? Сравнительно эффективный мониторинг возможен только при наличии формального плана сдачи сотрудниками результатов и при условии тщательной проверки его выполнения.
стр. 212
Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.