Сделано

Я пришел к ним, интересуясь эффективными методами разработки приложений и программного обеспечения. Обратил внимание на другие области, чтобы узнать, как там решаются важнейшие задачи и проблемы проектов. Cтал разбираться в организации таких проектов, как космический телескоп «Хаббл» и «Боинг 777». Можно ли заимствовать что-то из их спецификаций и планирования? Есть ли сходство в управлении проектами между моими программистами и строителями афинского Парфенона или небоскреба «Крайслер-билдинг» в Нью-Йорке? А в чем отличия и чему учит их анализ?

Возьмем, к примеру, редакторов газет, которые ежедневно «производят» информацию. Ведь они занимались мультимедиа (иллюстрациями и словами) задолго до того, как появилась идея публикаций. А съемки художественного фильма? Запуск «Аполлона-13»? Изучая эти вопросы, я смог найти новые способы управления проектными командами.

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

Перечислю ключевые выводы своих исторических исследований.

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

2. Чем проще вы воспринимаете свои задачи, тем эффективнее и сосредоточенее выполняете работу. Простой взгляд на свою деятельность поможет найти больше примеров и уроков из истории и современных отраслей, позаимствовать их, найти сходства или различия. Это похоже на японскую концепцию шошин, что означает «сознание новичка»[6], или открытый разум, – важную часть многих боевых искусств. Пытливый и открытый ум делает возможным рост и требует немало практики. Познание нового требует выйти за узкие рамки «безопасного» восприятия своей работы.

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

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

УЧИМСЯ НА ОШИБКАХ

Человеческие существа отличаются практически уникальной [среди животных] способностью учиться на чужом опыте, но при этом удивляют очевидным нежеланием делать это.

Дуглас Адамс[7]

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