Скотт Беркун - Искусство управления IT-проектами

Именно здесь переговоры могут усложниться. Если Фрэд не верит в то, что вы готовы воспользоваться вашими возможностями, он станет рассматривать ваш вариант 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.