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