Программное обеспечение и его разработка
Шрифт:
После подписания контракта спеси у вас должно поубавиться. Ваш подрядчик становится вашим партнером, а избавиться от партнера можно только с большим трудом. Вместе с организацией-разработчиком вы отныне составляете единую команду. Вы почти полностью теряете возможность воздействовать на подрядчика. Смена подрядчика, судебное преследование, простое обращение в суд — все это стоит больших денег.
Один из способов сохранить возможность воздействовать на события — ежемесячно звонить руководителю подрядной организации и предлагать ему вместе с вами еще раз обсудить проект, а может быть, просто позавтракать.
Это послужит стимулом для обсуждения проекта внутри подрядной организации на высоком уровне, что должно благотворно сказаться на всем проекте
Все эти методы я постарался суммировать в табл. 6.5.
Таблица 6.5. Как выбирать подрядчика
1. Необходимо собрать устные и письменные предложения
2. Крайне важна сама форма заключаемого контракта
3. Значение имеет не подрядная организация, а личность руководителя программистской группы
4. Стандарты — есть ли они у подрядчика? Опубликованы? Придерживаются ли их?
5. Достаточно ли людских ресурсов?
6. Назначения на руководящие должности
7. Опыт предыдущих разработок
8. Способность к напряженной работе и резервы
Единственным способом, который может применяться при заключении контракта на разработку крупных систем типов III, IV или V, нужно считать способ, при котором сумма контракта первоначально не фиксируется. Из этого правила может быть одно исключение, о котором будет сказано чуть позднее. Контракт без начальной фиксации суммы практикуется в Соединенных Штатах уже несколько десятилетий как основной вид контрактов на разработку. Он выдержал проверку временем, поскольку оказался выгодным как подрядчику, так и заказчику. Он используется в тех случаях, когда заранее не удается установить все необходимые требования и методику разработки в рамках жестко заданной суммы. Тем единственным исключением, которое может встретиться при заказе разработки систем типов III, IV или V, оказывается случай, когда строится в точности такая же система, какая в настоящее время уже используется на практике. Такое случается, хотя и редко.
Я не советую моим читателям настаивать на фиксации суммы заказа в тех случаях, когда требования не определены точным и исчерпывающим образом. Это может отпугнуть наиболее ответственных разработчиков и открыть путь для привлечения неопытного персонала или похуже того.
Когда нам становится ясно, что с разработкой программного обеспечения случилась беда, первое, что мы хотим узнать, — почему. Чаще всего причиной оказываются неверные предварительные оценки, довольно часто — нечетко установленные требования, а иногда в основе неприятностей лежит неправильное руководство. Мы обсуждали вопросы, как обращаться с требованиями и как проводить оценки.
Сменить руководителя легко, но это не всегда приводит к хорошим результатам. Это всегда большая неприятность. Новый руководитель часто бывает не лучше прежнего. Бывают, однако, случаи, когда другого выхода нет. Мне приходилось сталкиваться с руководителями, имевшими великолепные послужные списки, которые в результате каких-нибудь жизненных неприятностей тем не менее теряли свои прекрасные качества и не могли работать так же, как раньше. Иногда они просто достигали согласно принципу Питера, своего уровня некомпетентности, так что столь большая работа оказывалась им не по плечу. Удаление руководителя всегда оказывает сильное воздействие на всех остальных сотрудников. «Если это случилось с ним, значит, и со мной может произойти то же самое». Решаться на это нужно в самую последнюю очередь.
Прежде чем идти на крайние меры, попробуйте укрепить силы, обратившись за помощью к руководителю проекта. Подключите руководителя группы определения требований. Руководителя группы проектировщиков. Подключите даже руководителя производством! Иногда — и весьма часто — это помогает наладить дело.
Когда же этих мер недостаточно, то мы меняем руководителя, при этом хотим сделать правильный выбор. Нам совершенно не хочется возвращаться к такому же положению еще через год и снова делать перестановки на руководящих должностях.
Вероятность того, что проект, в котором заменяется руководитель, провалится, очень велика. Один руководитель в нем уже «поработал»; после этого остались очень серьезные проблемы. Кому захочется влезать в эти неприятные вопросы? Всякий, кто обладает высокой репутацией и блестящим послужным списком, знает, что это рискованно, вряд ли может привести к успеху, вообще полно подводных камней, что это положение чревато 80–100-часовой рабочей неделей, повышенной нервозностью, трениями и явной борьбой в коллективе. Новички могут воспринимать его как возможность составить себе имя, выдвинуться наверх, но ведь они — новички, т. е. люди непроверенные и неиспробованные. В настоящее время существует очень мало хороших, полностью оправдавших доверие руководителей разработкой программного обеспечения. Проблема эта не проста.
Огромный, неуправляемый проект подобен глухому омуту, в который бросаются очертя голову! Полный хаос! Сотрудники спят на работе, они почти помешались, стали вспыльчивыми, ссорятся, увольняются с работы — им предстоит прыжок в омут, — но они со всей очевидностью неспособны ничем управлять, кроме самых непосредственных, неотложных дел. Это случается нередко. График выдерживается только благодаря исключению некоторых функций. Это приводит к тому, что операторы должны выполнять большинство этих функций, только основываясь на собственных ощущениях, собственных рассуждениях и предположениях. Но работа движется! Проект объявляется успешно завершенным. А иногда случается так, что проект не работает, его приходится откладывать на год, а то и вовсе закрывать. Многие проекты были закрыты после того, как суммы затрат в них превысили 50 млн. долларов.
Иногда же, несмотря на успешное завершение, программное обеспечение оказывается в таком беспорядке, что его приходится переделывать. Группа разработчиков начинает работу заново непосредственно после сдачи программной системы.
Стандарты программного обеспечения необходимы группе разработчиков для всех крупных программных систем. Множество иерархически структурированных стандартов программирования нужно любому единому коллективу; это позволяет не вводить неоправданных ограничений. В каждой крупной организации должен быть директор по программному обеспечению. Все стандарты должны быть документированы, разосланы и введены в действие с проверкой исполнения. Существенную роль играет постоянное их изучение.
Если какая-нибудь достаточно крупная группа программистов не следует этим правилам, она не может гарантировать постоянно высокий уровень качества своей продукции. Случайные успехи, конечно, возможны, поскольку некоторые руководители все же знают, как надо работать, но надежной работы ожидать не приходится. Качество разработки программного обеспечения можно повысить, если обратиться к опыту технических дисциплин.
Методы, ставшие общепринятыми во всех других отраслях, в программном обеспечении кажутся абсолютными новинками. Фирма IBM выдала одному из своих служащих премию в 75 тыс. долларов за идею проведения обзоров состояния дел по проводящейся разработке с привлечением коллег и руководящих лиц — за так называемый «сквозной контроль», а ведь в промышленных отраслях этот процесс — обычное дело.