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

Ключевые уроки из моего экскурса в прошлое можно свести к трем моментам.

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

2. Чем проще ваше представление о том, чем вы занимаетесь, тем с большей энергией и целеустремленностью вы будете работать.Если сохранять простое представление о том, что мы делаем, то можно найти полезные сопоставления с другими способами создания вещей, которые существуют в окружающем нас мире. Перед вами откроется больше примеров и уроков из истории и современного производства, из которых можно будет что-нибудь позаимствовать, с чем-то провести сравнения или сопоставления. Это созвучно понятию, определяемому японским словом шошин (shoshin) – сознание начинающего [1]или открытое восприятие – основной части многих дисциплин боевых искусств. Любопытство и открытость – вот что предопределяет возможности развития, и для поддержания этого состояния требуется определенная практика. Чтобы сохранить способность обучаться чему-то новому, мы должны избегать искушения обрести узкий и непоколебимый взгляд на то, чем занимаемся.

3. Просто – отнюдь не означает легко.Лучшие атлеты, писатели, программисты и менеджеры стремились быть среди тех, кто всегда рассматривает свою деятельность как простую по сути, но в то же время и сложную. Следует помнить, что понятие простоты не является эквивалентом легкости. К примеру, что сложного в том, чтобы пробежать марафонскую дистанцию. Побежал – и не останавливайся, пока не пробежишь 42 км 195 м. Казалось бы, чего уж проще-то? Тот факт, что это нелегко, не опровергает простоты процесса. Возглавлять и управлять тоже нелегко, но природа этих процессов – направлять все в нужное русло на достижение намеченной цели – по своей сути проста.

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

При изучении истории разработки проектов возникает один простой вопрос: почему кто бы то ни было охотно страдает от ошибок и разочарований, которых можно было бы избежать? Если перед нами открыта как древняя, так и современная история работы над проектами и нам платят за то, чтобы мы совершали разумные поступки, независимо от того, откуда мы черпаем вдохновение, почему поощрения за извлечение уроков истории столь редко проявляются со стороны организаций? Хотя проекты завершаются или закрываются (а ведь многие проекты по разработке именно так и заканчиваются [2]) ежедневно, практически ничего не делается для изучения причин произошедшего. Создается впечатление, что менеджеры большинства организаций крайне редко поощряют людей за поиски сведений в этом направлении. Возможно, в этом проявляется страх перед тем, что будет найдено (и страх перед ответственностью за это). А может быть это просто отсутствие интереса с чьей-либо стороны к анализу неприятных или печальных событий, в то время как время вместо этого может быть потрачено на продвижение к следующему, новому изделию.

В книге Генри Петроски (Henry Petroski) «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage Books, 1992) автор описывает множество прорывов в разработках, происходивших благодаря провалам. В частности, такое случается из-за того, что провалы заставляют нас пристальнее к чему-нибудь приглядываться. Они требуют от нас пересмотра подзабытых предположений (трудно притворяться, что все в порядке, когда прототип горит ярким пламенем). Как говорил Карл Поппер (Karl Popper [3]), есть только два вида теорий: неправильные и несовершенные. Без провалов мы самонадеянно забываем, что наше понимание вещей не настолько совершенно, насколько мы думаем.