История инженерных проектов показывает, что большинство из них имеет ярко выраженные общие черты. У них есть требования, план и ограничения. Они зависят от умения общаться, принимать решения, сочетать креатив и логику. Как правило, проекты предполагают определенный график работы, бюджет и клиентов. А главное, основная задача проекта объединить работу разных людей в единое целое и создать нечто полезное для других (клиентов). Мы можем использовать HTML, C++ или бетон и сталь, но для всех проектов существуют общие неизменные принципы.
Я пришел к ним, интересуясь эффективными методами разработки приложений и программного обеспечения. Обратил внимание на другие области, чтобы узнать, как там решаются важнейшие задачи и проблемы проектов. Cтал разбираться в организации таких проектов, как космический телескоп «Хаббл» и «Боинг 777». Можно ли заимствовать что-то из их спецификаций и планирования? Есть ли сходство в управлении проектами между моими программистами и строителями афинского Парфенона или небоскреба «Крайслер-билдинг» в Нью-Йорке? А в чем отличия и чему учит их анализ?
Возьмем, к примеру, редакторов газет, которые ежедневно «производят» информацию. Ведь они занимались мультимедиа (иллюстрациями и словами) задолго до того, как появилась идея публикаций. А съемки художественного фильма? Запуск «Аполлона-13»? Изучая эти вопросы, я смог найти новые способы управления проектными командами.
Однако ответы не всегда очевидны. Не могу обещать, что вы быстрее выпустите продукт или научитесь лучше планировать благодаря этим источникам информации. Однако я точно знаю, что, вернувшись в мир программного обеспечения после путешествия в далекие области знаний, я по-новому взглянул на собственные процессы и инструменты. Многие полезные подходы и сравнения, которые мне удалось отыскать, никогда не упоминались на лекциях по информатике в колледже. Их не обсуждали на конференциях технологического сектора и о них никогда не писали в отраслевых журналах.
Перечислю ключевые выводы своих исторических исследований.
1. Управление проектами и разработка ПО не сакральные знания. Любая современная инженерно-техническая деятельность лишь очередной вклад в многовековую историю созидания и творения. Технологии и навыки меняются в отличие от ключевых проблем инженеров. Все задачи, будь то языки программирования или методы разработки, уникальны в том или ином смысле, однако являются производной других задач. И если мы хотим позаимствовать как можно больше знаний из прошлого, нужно быть готовыми исследовать оба аспекта уникальность и преемственность и сравнивать свои задачи с тем, что было раньше.
2. Чем проще вы воспринимаете свои задачи, тем эффективнее и сосредоточенее выполняете работу. Простой взгляд на свою деятельность поможет найти больше примеров и уроков из истории и современных отраслей, позаимствовать их, найти сходства или различия. Это похоже на японскую концепцию шошин , что означает «сознание новичка», или открытый разум, важную часть многих боевых искусств. Пытливый и открытый ум делает возможным рост и требует немало практики. Познание нового требует выйти за узкие рамки «безопасного» восприятия своей работы.
3. Простой не значит легкий. Ведущие спортсмены, писатели, программисты и менеджеры воспринимают свои занятия как нечто простое и при этом сложное. Помните, что простой и легкий разные вещи. К примеру, пробежать марафон простая задача. Вы начинаете бежать и не останавливаетесь, пока не преодолеете 42 километра. Куда уж проще? То, что это нелегко, не отменяет простоты задачи. Быть лидером и менеджером тоже сложно, но по своей природе делать работу определенным образом ради достижения определенной цели это просто.
Я буду возвращаться к этим концепциям во многих главах. Так что, если я ссылаюсь
на примеры, которые выходят за рамки стереотипов разработки программного обеспечения, надеюсь, вы поймете почему. И когда я пишу, что принимать решение или планировать график простые функции управления, я ни в коем случае не имею в виду, что их легко осуществить.
Человеческие существа отличаются практически уникальной [среди животных] способностью учиться на чужом опыте, но при этом удивляют очевидным нежеланием делать это.Дуглас Адамс
В своей книге «Инжиниринг и человеческий фактор: роль ошибки в успешном дизайне» (To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992) Генри Петроски объясняет, что ошибки нередко приводили к прорывам в разработках. Отчасти это происходит потому, что ошибки вынуждают нас быть внимательнее. Они требуют, чтобы мы пересмотрели предположения и принципы, о которых забыли (сложно притворяться, что все хорошо, когда прототип горит синим пламенем). Как говорил Карл Поппер, есть только два типа теорий: ошибочные и недоработанные. Без неудач мы самонадеянно забываем, что наше понимание несовершенно.