Книга: Искусство управления IT-проектами

Сноски из книги

Сознание начинающего является начальным понятием дзен-буддизма. В канонической притче фигурирует пустая чаша: если сконцентрироваться на том, чем заполнена ваша чаша, в ней никогда не будет места для новых знаний. См. книгу Сюнрю Судзуки (Shunryu Suzuki) «Zen Mind, Beginner’s Mind» (Weatherhill, 1972).

Об этом свидетельствует отчет «CHAOS Report» (The Standish Group) – документ о бюджете, календарном плане и общих провалах проектов разработки программного обеспечения. Публикуется по адресу http://standishgroup.com/sample_research/.

Карл Поппер был одним из видных философов ХХ века. (См. http://en.wikipedia.org/wiki/Karl_Popper).

Из книги Джеймса Чайлза (James R. Chiles) «Inviting Disaster: Lessons from the Edge of Technology» (HarperBusiness, 2002).

Хорошее описание как матричного, так и других типов организации можно найти в книге Стивена Силбигера (Steven A. Silbiger) «The Ten-Day MBA» (William Morrow and Company, 1993) на с. 139–145. Впрочем, эту информацию можно найти практически в любой книге, посвященной теории управления.

Опубликована по адресу http://www.tompeters.com/col_entries.php?note=005297&year=1991.

Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: «Это те же десять минут или другие десять минут?» – но его шутку должным образом так и не оценили.

В оригинале «Feature-driven development». – Примеч. ред.

Сравнительное обсуждение традиционных и гибких методов разработки программных средств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility and Discipline: A Guide for the Perplexed» (Addison Wesley, 2003).

Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).

«Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).

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

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

Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.

См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.

Стандартная формула для метода PERT: лучший расчет + (4 ? наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.

Сравнить другие типы проектов вы сможете, обратившись по адресу http://www.joelonsoftware.com/articles/FiveWorlds.html.

Эндрю Стеллман (Andrew Stellman), один из научных редакторов данной книги, несколько раз угрожал мне физической расправой, если я не расскажу о качестве программного продукта, но эта глубокая тема так и не вписалась в рамки моей книги. Для начала порекомендую вам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. Эдвардса Дэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992) Филиппа Кросби (Philip Crosby).

Файзал Джафдат (Faisal Jawdat), один из научных редакторов данной книги, угрожал мне изощренными пытками, если я не отмечу всю иронию ситуации, в которой после всего сказанного я продолжал работать на Microsoft.

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

Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).

Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.

Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.

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

Дополнительный материал можно найти в книге Дональда Гауса (Donald Gause) и Джеральда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.

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

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

Во многом эта картина похожа на описанную в книге «Peopleware» Тома Демарко (Tom DeMarco) и Тимоти Листера (Timothy Lister) (Dorset House, 1999) или в книге «Planning Extreme Programming» Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) (Addison-Wesley Professional, 2000).

Выпуск 4.02, февраль 1996 г.

ThinkPak можно заказать на веб-сайте www.amazon.com.

Основные принципы веб-дизайна изложены в книге Стива Крага (Steve Krug) «Don’t Make Me Think» (New Riders Press, 2005), а типовые ошибки, допускаемые при разработке пользовательского интерфейса, рассмотрены в книге Джефа Джонсона (Jeff Johnson) «GUI Bloopers». Нанять консультанта по потребительским свойствам или дизайну можно на веб-сайте http://www.upassoc.org/people_pages/consultants_directory/index.html или обратиться к автору через веб-сайт www.scottberkun.com/services.

Чувство обреченности оказавшегося в плену у времени хорошо передано в песне группы They Might Be Giants под названием «Older»: «This day will soon be at an end, and now it's even sooner, and now it's even sooner. And now it’s sooner still». («День скоро подойдет к концу, и времени все меньше, меньше. И вот его почти что не осталось».)

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

Неплохой список вариантов можно найти по адресу http://www.ms.lt/ms/projects/toolkinds/organize.html.

По поводу споров вокруг программирования до выработки замысла рассказывается в книге Алана Купера (Alan Cooper) «The Inmates Are Running the Asylum» (Sams, 2004).

См. статью «The Art of UI Prototyping» по адресу http://www.scottberkun.com/essays/12-theart-of-ui-prototyping/.

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

По этому поводу у меня возникали споры с другими руководителями. Они не могут себе представить, что их выдающиеся разработчики все это время не занимаются программированием в полную силу. Здесь они, конечно, лукавят: если время программиста ценится столь высоко, его работа должна быть четко спланирована. Они меня спрашивали: «А чем же тогда заняться программистам?» – а я отвечал: «Ждать плана, на который не жалко потратить их время, или помогать команде в подготовке этого плана».

Поэтому некоторые команды держат технические условия в режиме управляемой блокировки входящей и исходящей информации. Это позволяет разным людям вносить поправки, не мешая друг другу. (Такое же поведение имитируется веб-приложением Google Docs.) Также следует заметить, что ничто так не раздражает, как блуждание по документу в поисках отличий от предыдущей версии. Какое бы средство для этого не использовалось, авторы должны регистрировать вносимые изменения, например, «В раздел 6 этот пункт был добавлен 20.07.2008».

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

Меня всегда настораживали красиво разрисованные и объемистые технические условия. Это явный намек на то, что руководителя проекта больше волнуют сами технические условия, а не то, что будет получено на выходе, или то, что он не доверяет своей команде. Хуже того, слишком пространное изложение технических условий свидетельствует о том, что сами условия, в конечном счете, так никто и не читал (исключение составляют условия создания ядерных реакторов или высокотехнологичного хирургического инструмента).

Упражнения по моделированию ситуации – это лучшее, что придумано для развития навыков принятия решений. Моделирование ситуации намного лучше самого преподавателя погружает студентов в гущу событий. Почитайте книгу Кларка Эбта (Clark Abt) «Serious Games» (Viking, 1970).

В книгу «The Ten-Day MBA» (Quill, 1999) Стивена Силбиджера (Steven Silbiger) включена небольшая глава, посвященная теории типового дерева решений. Книга весьма полезна тем, что охватывает основные темы большинства MBA-программ.

Изначально фраза звучала как «смерть от тысячи вырезок» и означала газетные вырезки. Шучу.

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

Краткую историю о списке аргументов «за» и «против» можно найти в памфлете «How to Make a Decision» (Who’s There, Inc., 2003), который можно приобрести по адресу http://www.knockknock.biz. На 32-х занимательных страницах под этим названием скрываются описания способов, вроде подбрасывания монетки, игры в «камень-ножницы-бумагу» и т. п.

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

Был ли я прав? На следующий день после того, как я принял это решение, наш ведущий разработчик, Чи Чу (Chee Chew), решил сделать все самостоятельно. Не говоря об этом ни мне, ни кому-либо другому, он работал сутками за счет своего личного времени. Первоначальный пятидневный расчет был сделан кем-то менее опытным, а он справился с разработкой основных элементов примерно за половину срока. На другой день я случайно зашел в его офис и обнаружил там сюрприз. Он, улыбаясь, продемонстрировал новую версию браузера с внесенными им изменениями. Я просто онемел.

Фламандский живописец 16 века, известный своими пейзажами и картинами из сельской жизни. Увидеть картину «Вавилонская башня» и прочитать полную биографию художника вы сможете по адресу http://en.wikipedia.org/wiki/Pieter_Brueghel_the_Elder.

Как выразился Петерс: «Если вы не привыкли странствовать [по чужим офисам], то поначалу вы испытаете настоящий ужас…». Для выстраивания подобных взаимоотношений с людьми нужно время, особенно если у людей нет причин относиться к вам с опаской.

Мне не удалось найти никаких ссылок на данную модель. Я слышал о первых трех уровнях, но не смог найти источника. Другой удачной моделью является модель Сатир, которую Вейнберг (Weinberg) использовал в своих книгах. См., например, книгу «The Satir Model: Family Therapy and Beyond», Вирджиния Сатир (Virginia Satir) и др. (Science and Behavior Books, 1991). Да, это книга по терапии. Но если вас беспокоит данное обстоятельство, это именно та книга, которую вам следует прочитать.

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

Обширный список словесных нападок, разбитый на категории и сопровождаемый примерами, вы можете найти по адресу http://www.vandruff.com/art_converse.html. Только, пожалуйста, не используйте его как руководство к действию.

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

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

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

Прекрасный пример краткости в общении дает одна невероятная история из жизни Виктора Гюго. Когда была издана книга «Les Mise rables», Гюго послал своему издателю телеграмму с вопросом о первых отзывах. Его телеграмма была предельно краткой и состояла из одного знака: «?». Полученный им ответ также состоял из одного знака: «!». Очевидно, объем начальных продаж был впечатляющим. Поучительным в этой истории может быть то, что два человека, хорошо знающие и понимающие друг друга, могут общаться куда эффективнее, чем те, кто друг друга не знает. Этим еще раз подтверждается важность развития взаимоотношений с сотрудниками.

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

Лучше всего начать с книг «The Facilitator's Fieldbook» Тома Джастиса (Tom Justice) (American Management Association, 1999) и «Mining Group Gold» Томаса А. Кейзера (Thomas A. Kayser) (McGraw-Hill, 1991).

Дополнительную информацию о SCRUM можно найти по адресам http://c2.com/cgi/wiki?ScrumMeetings или http://www.controlchaos.com/.

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

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

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

Это часть закона Брэнда называется «Pace Law». Взято из вопроса, ежегодного задаваемого редакцией журнала «Edge», который в 2004 году звучал так: «По каким законам вы живете?» (см. http://www.edge.org/q2004/page6.html#brand).

Можете также почитать книгу Ричарда Шелла (Richard Shell) «Bargaining for Advantage» (Penguin Books, 2000). В ней приводится больше тактических приемов и технологий, чем в книге «Getting to Yes», и она очень хорошо подойдет для углубленного изучения данного вопроса.

Именно здесь переговоры могут усложниться. Если Фрэд не верит в то, что вы готовы воспользоваться вашими возможностями, он станет рассматривать ваш вариант BANTA по-другому. Он может сказать вам следующее: «Вы же не хотите, чтобы я здесь сидел и умирал?» Переговоры становятся сложнее, когда люди блефуют, вводят в заблуждение относительно их интересов или не испытывают особого доверия к другой стороне. В менее надуманных ситуациях все становится на свои места, как только реализуются варианты BANTA. Если бизнесмен действительно способен на лучшую сделку, то он в конечном счете ее добьется. А если не способен, то он уступит.

Неформальное введение в основы эмоциональной динамики вы найдете в замечательной книге Лео Ф. Баскалья (Leo F. Buscaglia) «Living, Loving & Learning» (Ballantine Books, 1985). Более формализованное введение изложено в книге Джона Брэдшоу (John Bradshaw) «Bradshaw On: The Family» (Health Communications, 1990).

Лучше всего рассматривать начинающие фирмы как созидательные силы, стремящиеся к новшествам. Обычно они представляют собой небольшие тесно сплоченные и усердно работающие группы людей. Здесь желателен именно «дефицит» людских ресурсов, поскольку только он придает всем особую независимость. Довольно интересные аргументы о пользе и рисках новаторских работ приведены в книге Поля Грехема (Paul Graham) «Hackers and Painters» (O’Reilly, 2004).

Роб и Эрик из команды «Samuel Field Y» Дагластон, штат Нью-Йорк, дали мне в области тренерских и руководящих навыков намного больше, чем все последующие тренеры по баскетболу в школе и колледже. Если вы знаете этих людей, передайте им, пожалуйста, чтобы они связались со мной.

Эта аббревиатура расшифровывается как «read the fucking manual», то есть «прочти эту чертову инструкцию!» или (в армейском варианте) «учи матчасть!» – Примеч. ред.

См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.

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

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

Дополнительное обсуждение вопроса о том, когда говорить «да», а когда «нет», можно найти в эссе Ричарда Бреннерса (Richard Brenners) «Saying No: A Short Course» по адресу http://www.ayeconference.com/Articles/Sayingno.html.

См. книгу Роберта Гласса (Robert Glass) «Software Runaways» (Prentice Hall, 1997).

См. статью «How to detect bullshit» по адресу http://www.scottberkun.com/essays/53-how-todetect-bullshit/.

Анализ критического пути детально расписан во многих учебниках по управлению проектами. Краткое изложение можно найти по адресу http://en.wikipedia.org/wiki/Critical_path. Более глубоко эта тема изложена в книге Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

Карл фон Клаузевиц был известным прусским военным мыслителем 19 века (см. http://en.wikipedia.org/wiki/Clausewitz).

Модель зрелости производственного процесса (Capacity maturity model, CMM), предложенная институтом по разработке программного обеспечения (Software Engineering Institute), определяет ряд очень хороших приемов управления IT-проектом в стадии миттельшпиля (см. http://www2.umassd.edu/SWPI/sei/tr25f/tr25.html и http://www.sei.cmu.edu/cmm/).

Из книги «Managing the Software Process» (Addison-Wesley Professional, 1989).

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

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

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

Из книги «Web Project Management: Delivering Successful Commercial Web Sites».

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

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

О планах тестирования и общих методиках контроля качества можно узнать из книги Рэкса Блэка (Rex Black) «Managing the Test Process» (Microsoft Press, 1999). Если вы серьезно заинтересованы вопросами качества, их надо сделать частью концептуального документа и учитывать в процессе планирования.

Из первого тома «System Thinking» книги Вейнберга (Weinberg) «Quality Software Management» (Dorset House, 1991), стр. 272–273.

Из первого тома «System Thinking» книги Вейнберга (Weinberg) «Quality Software Management» (Dorset House, 1991), стр. 272–273.

Неплохую подборку полезных инструментов и процессов вы найдете по адресу http://www.martinfowler.com/articles/continuousIntegration.html.

См. эссе Джоула Сполски (Joel Spolsky) «Painless Bug Tracking» по адресу http://www.joelonsoftware.com/articles/fog0000000029.html.

Если вас интересуют подробности на эту тему, наибольшую ценность могут представить следующие два источника: книга Тома Демарко (Tom Demarco) «Controlling software projects» (Prentice Hall, 1986) и том 1 «Systems thinking» книги Джеральда Вейнберга (Gerald Weinberg) «Quality Software Management» (Dorset House 1991).

Разработка на основе тестирования может стать одним из действенных подходов к решению задач качества разработки на ранних этапах и уберечь от больших наплывов обнаруживаемых ошибок. Обратите внимание на следующий материал: http://en.wikipedia.org/wiki/Test_driven_development.

Из первого тома «Systems thinking» книги Вейнберга (Weinberg) «Quality Software Management», стр. 250

См. книгу Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison-Wesley, 1999), стр. 69.

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

Советы по поводу качественного выполнения постпрограммы можно найти по адресу http://www.scottberkun.com/essays/.

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

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

Из словаря «Random House College dictionary» (1999).

Из книги «Roundtable on Project Management».

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

Организационные изменения даются нелегко. Прежде чем самому браться за дело, определенно нужно изучить предмет. Я советую начать с книги Джона П. Коттера (John P. Kotter) «Start with Leading Change» (Harvard Business School Press, 1996).

Оглавление книги