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

Эта аббревиатура расшифровывается как «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). Если вы серьезно заинтересованы вопросами качества, их надо сделать частью концептуального документа и учитывать в процессе планирования.