Руководитель проекта -- это клей, соединяющий всякие части
работы в целое. Он также, если надо, и смазка, благодаря которой
не заедает механизм совместного действия при взаимном трении
движущихся деталей. Иногда он ещё и источник энергии, приводящий
в движение пассивные элементы механизма.
В управление программным проектом входит следующее:
1. Установление, обоснование, уточнение, корректирование
параметров проекта в целом: содержания, затрат, сроков,
сопряжений, основных технических решений и пр.
2. Установление, обоснование, уточнение, корректирование
параметров отдельных этапов и направлений работы.
3. Разделение совокупного объёма работ на части, установление
очерёдности между ними, определение ширины фронта работ
(количества одновременно задействованных сотрудников).
4. Подбор, обучение, расстановка кадров.
5. Распределение заданий между сотрудниками с учётом пожеланий,
способностей, плана отпусков и т. п.
6. Обеспечение полноты загрузки сотрудников.
7. Обеспечение технических и организационных условий для эффек-
тивной работы сотрудников.
8. Обеспечение эффективного взаимодействия между сотрудниками:
обмена сведениями, мнениями, решениями.
9. Обеспечение благоприятного психологического климата в
коллективе, в частности, 1) настраивание на творческое
отношение к работе, 2) гашение и предотвращение конфликтов.
Психологическая поддержка сотрудников.
10. Обеспечение единообразия технических решений, применяемых
в разных частях проекта.
11. Организация единообразного документирования выполняемых
работ.
12. Поддержание доброжелательных отношений с внешними субъектами
и эффективного обмена информацией с ними.
13. Выявление и устранение текущих препятствий нормальному ходу
работы.
14. Предвидение и предотвращение возможных проблем.
Надо регулярно анализировать процесс коллективной работы над
проектом на предмет различных препятствий: уже проявляющихся или
возможных в будущем. Задача руководителя -- обеспечить устранение
или обход этих препятствий. Сотрудники не всегда по собственной
инициативе высказываются о своих затруднениях, достижениях,
идеях, поэтому надо их специально об этом спрашивать.
Надо выявлять, систематизировать и делать легкодоступными для
участников проекта ключевые сведения о проекте и в связи с ним,
чтобы участники проекта могли быстро находить нужное и соответст-
венно подстраивать свои действия.
* * *
Менеджеры (не только в программировании) вынужденно мыслят
схемами, так как если они нагрузят себя деталями, то вообще не
смогут продуктивно работать. Особенность хороших менеджеров -- в
том, что они понимают ограниченность своих схем и охотно модифи-
цируют их: подгоняют под реальность. Особенность плохих менедже-
ров -- в том, что, раз составив себе набор схем, они уже не
интересуются соотношением их с реальностью и действуют только на
их основе.
Лучше всего использовать при разработке сложной программной
системы какой-нибудь прототип: схожую программную систему или
отлаженную заготовку программной системы (см. "Программирование
на основе прототипов").
Если делается какая-то нетиповая система и нет подходящего
прототипа, то бывает лучше сначала сделать пробный упрощённый
вариант системы -- макет -- а потом, после уточнения требований
к системе со стороны заказчика, не развивать макет до полноцен-
ной системы, а начать делать её заново -- с учётом опыта изготов-
ления макета. Если же выбирают путь наращивания макетного вариан-
та системы, то добавления к макету зачастую носят характер
"заплат", из-за чего архитектура системы становится нерегулярной,
запутанной, сложной для сопровождения и развития.
В проекте сложной программной системы неизбежны многочисленные
ошибки и недоработки, которые выявляются лишь тогда, когда начи-
нается непосредственно программирование. Поэтому в процессе реа-
лизации проекта всегда имеют место более или менее значительные
его переделки. Те, кто считает переделки надёжным признаком
недостаточной компетентности проектировщиков, -- мало понимают в
деле создания сложных систем.
Чтобы заказчик мог более чётко и обоснованно сформулировать
свои требования к будущей системе, он должен поэкспериментировать
с макетом системы или с частично реализованной системой. До того,
как он получит эту возможность, у него не будет некоторых сущест-
венных представлений, на которые можно было бы опираться в выра-
ботке требований. Обвинять заказчика в том, что он изначально не
сформулировал чёткие требования или переделал их по первым
результатам разработки системы, -- значит мало понимать в том,
как вырабатываются решения.
Чем раньше работающие части системы будут представляться заказ-
чику для ознакомления, тем лучше, потому что заказчик раньше
получит возможность пересмотреть или уточнить свои требования, и
это потребует меньших изменений в системе.
Все решения участников проекта, затрагивающие области деятель-
ности других участников проекта, должны согласовываться с этими
другими участниками. Кто к кому должен приспосабливаться в техни-
ческих решениях -- вопрос сложный. Иногда это должен делать тот,
кому проще, иногда тот, кто больше отклонился от оптимального
пути. Согласовывать решения надо ещё и потому, что в этом случае
есть возможность своевременно выслушать компетентную критику и
таким образом удержаться от ошибок.
На проекте должно быть 10% программистов высокого класса. Это
лидеры. Если их набирается больше, будут иметь место конфликты
из-за стремления каждого определять основные решения. Для мини-
мизации конфликтов надо каждому из этих программистов выделять
отдельный сложный участок.
Проект среднего размера может выдержать 10% новичков: людей
с подходящим образованием, но без опыта. Остальные программисты
проекта должны иметь средний уровень квалификации.
Программист высокого класса разрабатывает типовые технические
решения и самые сложные нетиповые части системы. Остальные про-
граммисты размножают типовые технические решения, а также разра-
батывают менее сложные нетиповые части системы.
* * *
Все "девелоперы" должны время от времени проходить стажировку
в качестве "суппортеров", причём "суппортеров" не самолично напи-
санных программ, а чужих. Только при таком подходе может поддер-
живаться чёткое представление о том, как надо писать программы,
чтобы потом легко было их сопровождать.
Почти любой программист при отсутствии принуждения к порядку
позволяет себе всё большее и большее количество технических и
технологических небрежностей. Поэтому любой проект должен под-
вергаться эпизодическому жёсткому нормоконтролю.
Существует тип программистов, любящих писать сложно, с исполь-
зованием всяких "дополнительных возможностей". Им представляется,
что они таким образом совершенствуют свои профессиональные качес-
тва, демонстрируют высокий уровень своей подготовки и своё пре-
восходство над более просто работающими коллегами. В конечном
счёте вред от таких знатоков может превышать пользу от них,
особенно если они плохо комментируют и плохо документируют свои
решения.
Компоненты программной системы:
структура данных;
архитектура системы;
пользовательский интерфейс;
интерфейсы с другими системами;
выполняемые действия с точки зрения пользователя;
алгоритмы (выполняемые действия с точки зрения программиста);
"запасы" в системе для облегчения её развития;
правила оформления программного кода:
соглашения об именах;
"шапки" программных модулей и подпрограмм;
правила комментирования изменений;
и т. п.
Можно создать очень сложную систему из простых и понятных
модулей, взаимодействующих простым и понятным образом. А можно
строить систему из сложных модулей, взаимодействующих сложным
образом. В первом случае надо напрягать мысль, во втором можно
блеснуть знанием тонкостей языка программирования и умением
разбираться в нагромождениях деталей.
Чтобы сложный программный проект состоялся, надо защититься от
очень многих вещей, но в первую очередь надо постараться, чтобы
никакие выдающиеся специалисты не загаживали продукт своими
вычурными и малопонятными штучками -- случайным образом
именованными и невнятно описанными (если описанными вообще).
Действительно хороший программист стремится к простоте и понят-
ности, а не к демонстрации своей незаурядности Он считаеи необхо-
димым максимально облегчить труд тех, ко будет сопровождать его
продукт.
Программный продукт должен быть ориентирован на сопровождение
его людьми со средним уровнем способностей, иначе придётся искать
таких же выдающихся специалистов, как те, что его разработали.
Компоненты программных модулей, превращающих совокупность этих
модулей в систему, то есть в пригодное к некоторой работе целое
(вдобавок удобное для сопровождения и развития), разработчикам
отдельных модулей причиняют в основном неудобство, потому что
мешают реализации алгоритмов, ради которых эти модули разрабаты-
ваются. Поэтому разработчики модулей стремятся минимизировать
присутствие "системообразующих" компонентов в своём продукте и
кто-то должен ЗАСТАВЛЯТЬ их расширять это присутствие до требу-
емой степени, иначе получится не система, а совокупность модулей,
в которой очень трудно разобраться, почему она не работает, хотя
каждый модуль в отдельности вроде бы показывает нужный результат.
Все сколько-нибудь существенные технические решения по проекту
должны фиксироваться письменно. Для каждого решения должны быть
указаны: название, содержание, инициатор, дата решения, основания
для решения, исполнитель, дата исполнения, старое состояние фраг-
мента системы, новое состояние фрагмента системы. Лучше записы-
вать эти данные в специальном журнале или хотя бы чётче оговари-
вать их в письмах по проблемам и в комментариях к изменяемому
коду программ. Фиксация нужна не только для поиска виновных в той
или иной ошибке, но также для требуемого иногда возвращения
фрагментов системы к прежнему состоянию или для освежения в
памяти тех оснований, на которых были сделаны измненения, или той
идеи, которая была в измненениях воплощена.
Фиксация изменений в специальном журнале, а не только в письмах
и в комментариях к программному коду, удобна тем, что 1) выражает
существенное, 2) облегчает поиск. Работа над проектом не есть
исключительно движение вперёд: иногда приходится возвращаться к
рассмотрению старых обстоятельств. Чтобы фиксация изменений не
отнимала много времени и оправдывала себя, надо всего лишь чётко
её организовать. Разумеется, фиксироваться должны только измене-
ния принципиального характера и исправления серьёзных ошибок,
зарегистрированных при прогоне тестов.
Психологический аспект проекта не менее важен, чем технический:
в том смысле, что проект вполне может потерпеть неудачу из-за
психологических причин. Проекты делаются людьми, а люди работают
хорошо только при определённом настроении и при определённых
поведенческих установках.
Значительная часть проблем, которые приходится решать в связи
с проектом, -- это проблемы межличностных отношений. Наиболее
частые из них:
"Почему руководитель не я?"
"Кто виноват в ошибке?"
"Почему я должен подстраиваться под NN, а не он под меня?"
"Почему NN такой бестолковый?"
"Почему NN на лучшем счету, чем я?"
Поскольку проблемы такого характера неизбежны, надо относиться
к ним спокойно, а не воспринимать их как признаки того, что
ситуация становится чрезвычайной.
Работа руководителя проекта -- это по меньшей мере на 1/3 рабо-
та психологическая: специалистов разного профиля хватает и без
него, но сложность в том, что надо наладить их взаимодействие.
Если изначально пренебрегать психологической работой, то потом ею
всё равно придётся заниматься, но в более напряжённой обстановке.
Проект, на котором плохо решаются психологические проблемы,
нередко проваливается, а если всё-таки доводится до завершения,
то никого не радует своим качеством, а его бывшие участники
вспоминают время совместной работы с содроганием.
Направления психологической работы в коллективе:
1) выявлять недовольство сотрудников и его причины;
2) прививать сотрудникам требуемый взгляд на вещи:
обеспечивающий минимум недовольства и максимум интереса
к работе;
3) помогать сотрудникам преодолевать личные проблемы
психического характера, возникающие в связи с работой
или не в связи с ней.
Проект (или какая-то его часть) может стопориться из-за негиб-
кости сотрудников, должных согласовывать свои усилия. К примеру,
один сотрудник неудачно задаёт вопросы другому и ждёт ответов, а
этот другой не отвечает, потому что считает, что ранее уже
довольно полно ответил или что можно самостоятельно найти ответ в
документации. Если эти сотрудники разрознены территориально и
вынуждены общаться через письма и телефонные звонки, задержка в
работе может быть значительная. Чтобы она не случалась, надо
поддерживать в людях мнение, что 1) лучше написать лишнее и,
возможно, глупое письмо, чем действовать в недостаточной уверен-
ности, что правильно понял ситуацию, или напрасно ждать, 2) надо
спокойно относиться к тому, что некоторые приходящие письма будут
неудачными и, возможно, выглядеть ненужными, и содержательно
отвечать даже на такие, а если повторять уже сказанное, то
другими словами, поскольку прежние слова, быть может, оказались
недопонятыми. Снисходительность к коллегам -- необходимое условие
совместного движения вперёд. Если кто-то слишком некомпетентен,
от него следует, конечно, избавляться, но если степень некомпе-
тентности умеренная и частью преодолимая, то лучше терпеть недо-
статки такого сотрудника, потому что замена его на другого, если
и избавит от каких-то проблем, то добавит новые: где есть люди,
там есть и проблемы, ими неизбежно порождаемые.
Более или менее значительные угрозы проекту существуют посто-
янно, то есть они -- норма, а не что-то особенное.
Разработка более-менее сложной системы -- это процесс, который
всё время рискует застопориться, как только ослабнут усилия по
разборке возникающих завалов и по вытаскиванию проекта из край-
ностей, в которые он норовит соскользнуть. Проект движется
вперёд лишь при условии сбалансированности различных малосовмес-
тимых между собой требований, различных взаимно противорчивых
интересов.
Полной гладкости на проекте не бывает никогда: всегда имеют
место какие-то недоделки, несовершенства, нелепые ошибки, недо-
вольные члены коллектива. С некоторыми несовершенствами разраба-
тываемой системы приходится мириться, потому что их исправление
требует больших затрат времени и грозит ошибками, а также другими
нежелательными последствиями, о которых можно строить только
неопределённые предположения.
Одна из самых существенных угроз проекту -- потеря стройности
системы. Зачастую бывает так, что одни программисты принимают
несогласованные решения или делают "заплаты" вместо того, чтобы
решать проблемы фундаментально, другие приспосабливаются к этим
несогласованным решениям и "заплатам" вместо того, чтобы доби-
ваться согласованности и фундаментальности. В результате система
всё больше превращается в нагромождение "интерфейсов" между
своими же частями и "заплат", накладывающихся одна на другую, и
становится очень трудно что-то исправить в ней или усовершенство-
вать.
Если потеря стройности системы произошла, существенно падает
скорость продвижения вперёд в разработке системы. Наступает
острая нехватка времени, становится некогда документировать
работу и комментировать программный код, решения оказываются всё
более заплаточными, и, если до конца разработки ещё далеко, то
наконец наступает момент, когда авторы кода уже не могут разо-
браться, где что делается и как можно исправить функциональный
дефект так, чтобы не привнести новых дефектов. Иногда даже
становится проще начать создание системы заново -- с учётом
приобретённого опыта -- чем доводить до работающего состояния то,
что получилось.
* * *
Всякий программный продукт -- "кривой" в той или иной степени:
представляющий собой более-менее слаженную совокупность компро-
миссов между тем, что нужно, возможно, хочется, практически
реализуемо. Нет продукта, в котором хорошие, блестящие, даже
гениальные решения не сочетались бы со всякими глупостями,
недоделками, "заплатами" на скорую руку.
Люди смотрят свысока на муравьёв, волокущих добычу в своё
жилище: беспорядочные подёргивания, каждый микротруженик тянет в
свою сторону, эффективность низкая, а движение в нужном направле-
нии получается чуть ли не случайно. На самом деле люди, работаю-
щие над общим не очень большим проектом, особенно в программиро-
вании, оказываются не намного эффективнее этих муравьёв: каждый
выступает со своим мнением, тянет на себя одеяло. Что-то переде-
лывается, что-то и вовсе выбрасывается, и если проект заканчива-
ется функционально пригодным продуктом, то чуть ли не вопреки
всему.
Александр Бурьяк.