Йордон пишет о том, что основная проблема создания программных систем заключается не в программировании или проектировании, а в управлении и он прав.

Начнем с того, что программирование можно рассматривать как некоторое искусство создания красивых программ или реализации алгоритмов, а можно --- как производство программного обеспечения. Обе эти точки зрения не исключают друг друга, но дают разные подходы за счет различных целей и средств их достижения. Если в первом случае интересно КАК реализована программа и, по сути, зачастую этот фактор становится определяющим (при таком подходе нередко приходится переписывать заново чуть-ли не весь программный комплекс только из-за того, что его реализация "сковывает" движения), то во втором важен конечный результат, определяемый сроком и количеством.

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

Проблема заключается в том, что никому доподлинно неизвестно, как надо управлять программистами, чтобы те были способны создать конечный продукт.

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

Рабочий за станком является частью производственного процесса; но его главное свойство заключается в заменяемости. Можно, не меняя станка, поменять рабочего за ним и работа в целом от этого не ухудшится.

Таким образом, схема управления рабочими достаточно проста и эффективна: следить за временем работы и за процессом ее выполнения. Тогда можно сказать, что количество работы будет близким к расчетным величинам, от чего управление становится несколько более простым: весь завод, вместе с людьми, можно рассматривать как большой черный ящик, в который с одной стороны текут материалы, с другой стороны --- рабочая сила, а вытекает готовая продукция. Все процессы внутри можно описать простыми законами: столько-то материалов в месяц будут загублены, текучка кадров составит N процентов, бой тары --- M единиц на километр.

�менно этот факт позволяет моделировать процессы при помощи различных автоматических средств (тот же ithink): можно задать несколько параметров системы, меняя которые можно изучить поведение системы в целом при различных условиях.

Я не хочу говорить о таком моделировании --- я никогда им не пользовался и не видел в жизни реальных примеров использования (а с некоторых пор я стал очень осторожен и всегда ищу то, что называется "success story" от реальных людей), но хочется отметить, что сам факт такого моделирования говорит о популярности представления заводов и цехов таким образом. Тем самым управление максимально упрощается: менеджера не волнуют проблемы токаря Васи и он готов заменить его на безработного токаря Петю с улицы, если Вася не будет выполнять своих обязанностей. Кстати сказать, социальная поддержка за рубежом строится исходя из этих же соображений, просто за счет добавления еще одной службы, которая будет следить за тем, чтобы рабочим (в частности, Васе) было бы приятно работать.

Такая методика управления существует очень давно и менеджеры всегда пытаются применить ее к руководству программистами. Обычно это не получается.

Во-первых, программист не является рабочим у станка. Точнее, нельзя просто взять и извлечь программиста из проекта, а потом посадить вместо него другого, программист заменяем только вместе с написанным им кодом. Как мне недавно заметили, все существующие методологии, нотации, технологии и правила в программировании служат как раз для того, чтобы дать возможность такой замены. "Программист на PHP" с легкостью заменяется другим таким же "программистом" просто по той причине, что PHP является отработанной технологией создания веб-сайтов, предоставляющей в распоряжение пользователя стандартный набор инструментов. Если один программист умеет ими пользоваться, то другой, с теми же знаниями, в большинстве случаев сможет поддерживать проект и расширять его возможности.

Различные корпоративные стандарты на программный код, которые встречаются в некоторых софтверных компаниях, служат той же цели. Мне приходилось их видеть: описывается то, как должны выглядеть все языковые конструкции внутри программ, указывается процент комментариев от текста программы, стиль документации. Все это позволяет, чисто теоретически, перекидывать программный код от одного программиста к другому.

Тем не менее, никакой корпоративный стандарт и технология не справится в общем случае с разным мышлением у программистов. Единственное, как показывает практика, разное мышление не так уж часто встречается.

Во-вторых, опять же, в большинстве случаев нельзя померять количество произведенного конечного продукта исходя из потраченного программистами времени. Т.е., если действует правило "приходить в 10, работать 9 часов с обеденным перерывом в 1 час", то никто не будет гарантировать, что за год работы в таком режиме программисты смогут сделать что-либо сложнее чем "Hello, world!" Мало того, оценить количество произведенного программистом программного кода относительно поставленной цели можно только изучив этот программный код. Таким образом, реальное положение своего "куска" программы знает только тот программист, который им занимается. Опустив те случаи, когда он ошибается, степень информированности менеджера о состоянии проекта зависит лишь от доверия программистов к менеджеру и, следовательно, честности программистов.

Менеджер, который всегда управлял заводом, будет исходить из того, что производственный процесс похож на черный ящик. Поэтому его волнуют только внешние проявления этого процесса, которые он может померять, как то: время прихода и ухода программистов, соответствие программного кода корпоративным стандартам, количество произведенных бумажек с красивыми диаграмками (IDEF, UML, ...) Ну и, конечно же, планирование времени...

Опять же, проблема заключается в том, что программисты, которые должны прийти в 10 часов и отработать 9, всегда уйдут в 19 часов. Чтобы при этом не случилось. Дело в том, что они тоже будут мерять свой труд по затраченному времени, бережно относясь к выходным и обеденному перерыву. Если же проект выходит за рамки сроков (а он выйдет, куда же он денется), программисты удивленно пожмут плечами перед менеджером, потому что все от них требуемое они сделали.

Нет, наверное оба этих моих возражения в некоторых случаях не существенны. Например, программисты не могут быть одинаково хорошими --- зато они могут быть одинаково плохими. Замена же одного плохого программиста на другого действительно возможна (просто потому, что ничего не меняет, все и так плохо). А при действии правила "от столба и до обеда" проявляются законы эволюции, в результате чего в проекте остаются только те, кто принимает подобный стиль работы. После подобного эволюционирования уже программисты прикидываются черным ящиком, чтобы менеджеру было бы удобнее им управлять.

Но это неправильно. Просто потому что, несмотря на существование плохих или просто необученных программистов (которых большинство), и которые, может быть, иначе просто не могут работать (хотя мне это очень сомнительно), в проекте должны обязательно присутствовать лидеры, которые могут не придерживаться корпоративных стандартов, приходить в 5 вечера и работать столько, сколько работается, включая или исключая обеденный перерыв, нарушать все принятые методологии и т.д. и т.п. �менно они задают общий стиль работы и способны оценить выполнение проекта. Эти люди никак не будут вписываться в общие правила управления и, в тоже самое время, сложный проект без подобных лидеров никогда не будет успешно завершен или развит.

Резюме

Существуют некоторые общие ошибки, которые постоянно допускаются различными менеджерами. Результат практически всегда одинаков: "традиционное управление" обычно приводит к полной несостоятельности менеджера в оценке проекта.

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

PS

Традиционный, для подобных статей, посткриптум. Тема не исчерпана и обязательно будет продолжена.