Управление проектами, связанными с IT, осложнено мифами и сказками вокруг индустрии программирования.
IT (сокращение от англ. Information Technology) — информационные технологии.
Содержание:
1. Миф об уникальности отрасли производства программного обеспечения
2. Запредельная сложность программирования
3. Миф о великом программисте
4. Разработчик программного кода не должен быть главным в проекте
Эти мифы постоянно внедряются в неокрепшие умы, в том числе «вдалбливаются» новичкам индустрии.
Основная почва подобных мифов — противоречие между интеллектуальностью и сложностью работы с одной стороны, и самыми обычными свойствами персонала и проектов — с другой стороны.
Умение абстрагироваться от подобных мифов приходит с опытом.
Миф об уникальности отрасли производства программного обеспечения
Производство или создание ПО (программного обеспечения) не является чем-то особенным. С точки зрения бизнеса, здесь происходят те же процессы, что и в других отраслях: пищевой промышленности, строительстве и так далее. Что бы по этому поводу не говорили продавцы автоматизированных систем.
Законы развития, становления и окупаемости проектов при написании программ, сайтов, автоматизированных систем управления – те же.
Поэтому разговоры об уникальности разработчиков ПО, специфике управления проектами, особых путях развития бизнеса — не более чем миф.
Да, темпы бизнеса несколько выше, но в остальном то же самое. Но все это только на первый взгляд, если не смотреть глубже.
При более глубоком анализе видно, что некоторые особенности в данной отрасли все-таки есть. Многие отрасли производят либо продукт, либо услугу, либо и то, и другое. Программисты тоже создают продукты: программное обеспечение. Данный продукт, как правило, не применяется сам по себе.
Что такое программа? Это машинный код, понятный только компьютеру, гаджету, серверу, сетевому оборудованию, – и не более того. Простой человек, обычное оборудование, не оснащенное «компьютерными мозгами», не в состоянии понять данный машинный код.
Таким образом, программисты создают продукт, которым может воспользоваться только машина, автомат, компьютер, гаджет, какое-либо иное устройство, оснащенное внутри себя «конечным автоматом», как принято говорить на сухом языке научных определений.
А что есть «конечный автомат»? Это устройство, которое может совершать только конечный набор различных действий. То есть это не человек, не группа людей, не коллектив, не народ. Это лишь машина или оборудование, или игрушка какая-нибудь, или что-то гораздо более серьезное.
Все это означает, что программисты делают продукты, которые затем кто-то должен куда-то как-то «встроить». Иными словами, тот, кто управляет программистами, должен всегда помнить, что встраивать программный код в некий компьютер будет программист. А вот дальше налаживать работу того оборудования, куда программист встроил свой код, – это придется делать тому, кто управляет программистом. Программист в итоге легко может «умыть руки», что обычно он и делает.
Вот так, может быть, немного сложно, можно показать, что программисты на самом деле не создают совсем уж конечный продукт. Они создают то, что потом (по времени) или сразу (одновременно с созданием программного обеспечения) требует дальнейшего развития и продвижения.
То есть, по сути, программисты не несут ответственность за конечный продукт, который будет предложен на рынок. Потому ими, программистами, не так просто управлять, как это может показаться сначала. Трудно управлять теми, кто не несет полной ответственности за сам конечный продукт.
«У меня все работает!» –
такой ответ часто приходится слушать менеджеру программных проектов от исполнителей, от разработчиков кода, от программистов, в ответ на любые претензии к созданному программному обеспечению со стороны руководства проекта или со стороны конечных пользователей, потребителей. И это, пожалуй, самое сложное возражение, с которым приходится постоянно бороться менеджерам проектов, где разрабатывается помимо всего прочего и программное обеспечение.
Миф о запредельной сложности программирования
На самом деле производство современного программного продукта не сложнее, чем, например, производство автомобиля, рекламного фильма или лекарственного препарата. В этих индустриях успешно справляются с задачами и проектами. И это тоже лишь на первый взгляд, если не углубляться в детали.
Да, современные технологии предельно сложные. Попробуйте организовать производство тех же процессоров, что стоят внутри каждого персонального компьютера! Сложнейшие процессы, сложнейшие технологии, сверхчистые материалы, сверхвысокий вакуум и прочее – не хватит места в статье для перечисления проблемных областей.
А что есть программирование? Это рабочий стол программиста, оснащенный, разве что мощным компьютером, несколькими мониторами, с доступом компьютера к отдельным опять же мощным серверам, дисковым системам хранения данных и прочее. И во главе стола сидит умный работник, знающий компьютерные языки, языки программирования – далеко не всегда достаточно, чтобы программист знал только один какой-то язык, часто требуется знание нескольких языков.
Чем это сложнее, чем, скажем, опытный станочник, работающий за пультом управления обрабатывающего центра?
Или чем это сложнее работы опытного конструктора, проектирующего аппараты для дальних космических перелетов? Конечно, не сложнее.
Однако работа программиста имеет свою специфику. Любой язык программирования имеет ограничения. С его помощью нельзя сделать абсолютно все, что может потребоваться для выполнения проекта. Искусство программирования как раз и состоит в том, чтобы «умудриться» с помощью машинных языков, имеющих ограниченные возможности, создать то, что по замыслу авторов проекта, по замыслу его менеджеров, кто управляет программистами, должна делать будущая программа.
В этом смысле работа программиста более похожа именно на конструктора небывалых доселе аппаратов, чем на станочника универсала. Станочник делает то, что за него кто-то когда-то спроектировал. Он работает по кем-то созданной схеме, по чертежу, по технологии.
А вот программисту мало кто дает для работы «чертежи» и «технологии» будущих программных продуктов. Чаще всего программиста просят сделать нечто «по картинкам», по словесному описанию, а то и просто: «Ну, сделай, пожалуйста»…
Здесь уже нужно говорить не о сложности программирования, а о сложности постановки задачи программисту. Поэтому от квалификации менеджера проекта, где задействованы программисты, зависит очень многое, если не все вообще. Менеджеру нужно четко и ясно ставить задачи, тогда программирование становится простым и понятным, либо…
В случае же «либо» программист может спокойно сказать: «Теперь все от меня зависит!». И с этой минуты программирование станет сложным и непредсказуемым с точки зрения получения конечного результата, с позиции менеджера проекта.
И кто теперь виноват?! Кто создал условия будущей неопределенности для получения конечного результата проекта?
Миф о великом программисте
Программист — не Бог и не оракул, которого необходимо слушать, не перебивая, и со всем соглашаться. С виду любой, даже самый «средненький» программист, может создавать впечатление очень «продвинутого» человека, занимающегося непосильным умственным трудом и говорящем чаще всего на непонятном для окружающих языке.
Однако, при всем этом, на практике программист постоянно проявляет себя как подросток, не окончивший школу: говорит только часть правды, срывает сроки, проекты. Опять же все это верно, но на первый взгляд, без углубления в детали.
Такое «защитное», а не «детское» поведение программистов чаще всего связано с проблемами, возникшими еще на этапе постановки задачи. В проектах по созданию ПО далеко не все четко планируется.
Скажем, нужно разработать некое программное обеспечение для чего-либо. Сколько времени на это отводится в проекте? Сколько нужно для этого времени, программистов, языков программирования, технических средств для написания программного кода? А сколько на самом деле нужно, скажем, того же времени на написание кода, кто это может сказать?
Вот потому, что нет ответов на поставленные вопросы, идут к программисту, спрашивают у него. Ведь кто, кроме него, может сказать, если менеджеры проекта сами не программируют? Либо менеджеры проекта писали код когда-то в далеком прошлом на других вычислительных машинах и с помощью других языков программирования. И программист, не имея на руках четкого задания, – ведь еще только планируем работы, планы пишем, глядя в потолок, – дает свои примерные оценки, исходя из собственного опыта и предположений.
Оценки программиста, по сути исполнителя работ, тут же становятся «догмой», и заносятся в план. А потом: тут не получилось, тут потребовалось уточнить задание, тут возникли проблемы и тому подобное. А кто виноват? Конечно, программист, он же называл сроки, когда его спрашивали…
Здесь надо говорить не о «великости программиста», а о сложности планирования его работы. В Театре Оперетты в Москве есть спектакль, где один из его героев – композитор, зарабатывающий деньги «объемом», а не качеством своих музыкальных произведений – произносит «классическую фразу»: «Ну, никогда не писал столько нот за один час!». Так и с программистом: какой длины код он может написать, скажем, за день, за неделю, за месяц? Кто-то считал? И можно ли это сосчитать?
Со времен Тейлора, с начала прошлого века, менеджеры научились добиваться роста эффективности работников «физического труда». Но до сих пор никто так и не научился точно и однозначно определять возможную максимальную производительность работников «умственного труда». Программисты относятся к числу последних – это работники умственного труда, хоть они постоянно и «отчаянно» барабанят по клавиатуре и никогда не расстаются со своими гаджетами, подключенными к серверам, на которые к тому же постоянно «льется» различная техническая информация о работе создаваемых ими программ.
Получается, что программисты становятся «великими», если их таковыми создают сами менеджеры проектов. Спрашиваем у программистов о сроках разработки? Зависим от них в вопросах планирования проектов? Тогда приходится терпеть их «великость», хочешь или нет.
Ну, а если мы, менеджеры проектов, можем сами все спланировать, расставить по полочкам, сформировать команды программистов так, чтобы были какие-то перекрестные разработки, где есть возможность сравнивать качество работы, производительность труда и прочее – вот тогда великость программистов проходит сама по себе.
А если мы создали свою собственную технологию программирования – некий порядок работы программистов, когда пошагово можно проследить, как из технического задания создается программный код, и насколько он соответствует этому заданию – тогда нас можно называть Менеджерами программных проектов с большой буквы. Поскольку при такой постановке работ программисты становятся почти работниками физического труда, с возможностью нормировать их труд и точно рассчитывать время на разработку кода. Ведь основную интеллектуальную работу за них делает менеджер проекта в ходе автоматизации постановки задачи.
Но таких менеджеров, кто владеет технологиями программирования, автоматизированными системами управления проектами, предусматривающими разработку программного кода, маловато пока в природе. Чаще спрашивают у программиста о сроках разработки, со всеми вытекающими из этого, порой неприятными следствиями…
Разработчик программного кода не должен быть главным в проекте
Верный признак возможного краха проекта — когда менеджер или топ-менеджер, не IT-шник, с неуверенностью рассказывает руководителям о том, что все идет хорошо и данный этап проекта состоит из внесения важных внутренних технических улучшений, что позволит сделать на следующих этапах проекта настоящий прорыв.
Фактически, тем самым менеджер не только пытается спасти самого себя от критики и разборок со стороны начальства, но и, по сути, прикрывает программистов, которым он так и не смог четко поставить задачи и проконтролировать их выполнение.
Задержки в любом проекте – это потенциальная опасность не получить конечный результат. И следом проиграть конкуренцию. Для проектов, где есть программная составляющая, действуют те же самые законы рынка. Успеешь – завоюешь. Не успеешь – будешь догонять, соберешь в качестве доходов лишь малую толику того, что тебе оставили, по сути, позволили конкуренты.
А потому менеджерам проектов необходимо помнить, что программисты — это обычные инженеры, разве что «на ты» разговаривающие с компьютерами. Хотя и этого тыканья компьютерам не так мало, как может показаться с первого взгляда. А кто еще умеет «принудить» компьютер, гаджет, сервер, оборудование с программным обеспечением работать так, как требуется?!
Но заставить компьютер или оборудование «с мозгами» работать как надо – этого мало. Нужно все сделать вовремя, как минимум, и так, как задумано, а не так, «как у нас получилось». «Хотели как лучше, а получилось как всегда» – подобная, порой, привлекательная формула никак не годится для программных проектов. Как, впрочем, и для других проектов тоже не годится…
В любом бизнесе, в том числе и в HI-TEC бизнесе выигрывают не инженеры, а профессиональные бизнесмены и высококвалифицированные менеджеры. Как, собственно, и везде.
