Договор на разработку ПО.
17 февраля 2010 в 18:17

Договор на разработку ПО.

Хочу обсудить вопросы на опыте проекта, когда разработка была отдана на аутсорс. Полнота договора. Нужно ли подробно писать требования к каждому объекту договора? Довольно точно известна цель которую нужно достичь: переход на новое ПО без потери существующего функционала и без остановки подразделений предприятия более чем на несколько часов. Объекты договора: программный продукт, тесты (планы тестирования и автотесты), руководства пользователя, эскизный проект.
Как бороться с формальным отношением разработчиков к проекту? Разработчику не важно достичь конечной цели — передать работоспособный продукт. Он относится к договору, как религиозный фанат к библии. Если в договоре упустили (не указали) деталь, которая влияет на работоспособность всей системы, то это приводит к трениям между заказчиком и разработчиком. Возникает вопрос о полноте договора: что нужно указывать в договоре, а что нужно решать в рабочем порядке?
Какие должны быть критерии качества при разработке ПО? Разработчик стремиться переложить все тестирование на заказчика. Какие пункты нужно включить в договор, чтобы добиться от разработчика передачи уже протестированного ПО?

1299
  • Тема закрыта
Комментарии (22)
  • 18 февраля 2010 в 07:50 • #
    Евгений В. Молев

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

  • 18 февраля 2010 в 13:55 • #
    Андрей Стрюков

    К сожалению это было не возможно из-за сроков проекта. Как говориться, лошадей на переправе не меняют :)

  • 18 февраля 2010 в 18:20 • #
    Рушан Якубов

    И застревают на переправе :)

  • 18 февраля 2010 в 22:59 • #
    Евгений В. Молев

    Как сказал генерал Лебедь - На переправе коней не меняют, а ослов можно и нужно менять!

  • 18 февраля 2010 в 09:33 • #
    Константин Кардымон

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

    Посему: ТЗ должно однозначно разрабатываться по отдельному договору на проект со "слабыми" требованиями и заказчику в любой договор (в том числе и на ТЗ) стоит включать пункт типа: "После подписания настоящего Договора Стороны не могут вносить изменения и дополнения в их содержание. В случае возникновения у Заказчика дополнительных задач, идей и решений, для реализации которых необходимо затратить суммарно более 3% (Трех процентов) от общей стоимости Работ по настоящему Договору, указанной в пункте 3.1, они будут рассматриваться как дополнительные работы в соответствии с пунктами 2.3.5 и 2.4.2, настоящего Договора", ну а если в случае "менее", то милости просим.

  • 18 февраля 2010 в 13:51 • #
    Андрей Стрюков

    Константин, Вы говорите правильно, но в нашей ситуации у Заказчика не могло появиться дополнительных требований, мы просто переходили на более высокую версию платформы, с одним лишь условием - полностью повторить функционал старой версии. Да, у исполнителя был риск, но он был оправдан по двум причинам: 1. все риски можно было заложить в цену на тендере 2. Стать постоянным партнером очень крупной и весьма платежеспособной организации.

  • 18 февраля 2010 в 10:40 • #
    Юрий Романов

    Когда всё утрясётся, программа будет работать, (ОБЯЗАТЕЛЬНО!) регистрируйте и получайте Свидетельство об официальной регистрации.

  • 18 февраля 2010 в 11:41 • #
    Павел Подскребкин

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

  • Онлайн школа за 7 дней

    Цена: 1 000 руб.

  • 18 февраля 2010 в 18:24 • #
    Рушан Якубов

    Саморекомендация подойдет? :)

    Опыт в разработке и-нет магазинов есть, и довольно большой. Ориентировочная стоимость - 89 т.р. по ключ, срок 35 раб. дн. Доп функционал - за доп оплату (небольшую).

    Профессиональная команда разработчиков (узких специалистов).
    Гарантия - на все время эксплуатации сайта.

  • 18 февраля 2010 в 19:20 • #
    Павел Подскребкин

    можно подробнее на #

  • 19 февраля 2010 в 02:08 • #
    Рушан Якубов

    отправил Вам

  • 19 февраля 2010 в 00:49 • #
    Павел Алексеев

    Просто установить (например рекомендую PrestaShop) - установлю, настрою, базово обучу использовать - бесплатно - http://hosting-help.ru/site-fast-start (без подвохов, платите только за хостинг).

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

  • 18 февраля 2010 в 16:37 • #
    Виталия Лепехина

    Андрей, как Вам уже ответили, всех нюансов в договоре учесть невозможно, для этого разрабатывается техническое задание, технические требования к продукту и т.д. Вот в этих документах, которые являются неотъемлемой частью договора (также как и график выполнения работ, с указанным в нем сроками) Вы и прописываете все детали, тем более, если Ваш подрядчик столь "педантично" относится к "бумажному оформлению" Ваших договоренностей... Хотя, может, уже имеет смысл сменить подрядчика?

  • 18 февраля 2010 в 19:28 • #
    Рушан Якубов

    "Как бороться с формальным отношением разработчиков к проекту?" - Что значит "формальное отношение"? Договор есть договор, он, как известно, дороже денег. А потом, Вам же тут не семья, не благотворительная организация и не монастырь - договор - это и есть формальность.

    "Он относится к договору, как религиозный фанат к библии" - Так это ж хорошо - будет головой биться об стену, но сделает.

    "Если в договоре упустили (не указали) деталь" - простите, но это уже Ваши, как Заказчика поблемы. Если нужно что-то еще, кроме того, что указано в ТЗ и Договоре - оплачивайте дополнительно. Какие тут могут быть трения и вопросу?

    Кроме того, технические детали указываются в ТЗ, а не в договоре.

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

    Требования выставляете Вы, ТЗ пишет исполнитель (ну или как договоритесь).

    "Какие должны быть критерии качества при разработке ПО?" - Работает/ не работает.

  • 18 февраля 2010 в 22:25 • #
    Андрей Стрюков

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

  • 19 февраля 2010 в 01:13 • #
    Рушан Якубов

    Разработчик может стать партнером (семьей, на длительное время :) ), если сделает все КАЧЕСТВЕННО. Партнер - это тоже разработчик.

    "так что если чего в договоре и не было, это не должно влиять на цену и при чем здесь тогда доп оплата" - Я ИМЕЮ ВВИДУ, ЧТО ТО, ЧТО ЗАКРЕПЛЕНО В ТЗ ДОЛЖНО БЫТЬ ВЫПОЛНЕНО БЕЗ ВОПРОСОВ, А ВЫ - ДОЛЖНЫ ПРИНЯТЬ ЭТО, ТАКЖЕ БЕЗ ВОПРОСОВ. А ДОП ОПЛАТА ТУТ ПРИ ТОМ, ЧТО ЕСЛИ В ПРОЦЕССЕ РАБОТЫ НАД ПРОЕКТОМ У ВАС ПОЯВИЛИСЬ ДОП ТРЕБОВАНИЯ, ТО ПОДРАДЧИК ИМЕЕТ ПОЛНОЕ ПРАВО ЗАПРОСИТЬ ЗА ЭТО ДОП ОПЛАТУ.

    "не должно быть грамматических ошибок" - ЭТО ДА, ЭТО ДАЖЕ НЕ ОБСУЖДАЕТСЯ. ВСЕ ВУЗЫ ЗАКАНЧИВАЛИ, ЭКЗАМЕН ПО РУС ЯЗУ СДАВАЛИ, ТАК ЧТО ИЗВОЛЬТЕ. НУ ТАК И ПИНАЙТЕ ЕГО В ШЕЮ, ЕСЛИ ОН ВАМ НЕ НРАВИТЬСЯ!

    "что-то я этого в проекте не встретил, были обратные ситуации, когда разработчик говорил что у него нет, например сканера, поэтому без ошибок он сделать не может. Потом оказалось что у них нет и подобного нашему принтера." - ЭТО ПРОБЛЕМА ПОДРЯДЧИКА - ЧЕГО У НЕГО ТАМ ЕСТЬ, А ЧЕГО НЕТ. СОГЛАСИЛСЯ - ДЕЛАЙ. ПО МОЕМУ, ОН НА ВАС ПЫТАЕТСЯ "ЕЗДИТЬ", Т.Е. ПЕРЕВАЛИТЬ СВОИ ПРОБЛЕМЫ НА ВАС. ПУСТЬ КУПИТ ПРИНТЕР, СКАНЕР И ЧТО ТАМ ЕЩЕ НУЖНО, ВОЗЬМЕТ ИХ В АРЕНДУ. ВАС ЭТО ВООБЩЕ НЕ ДОЛЖНО ВОЛНОВАТЬ, МОЖЕТ ОН ЦИФРОВЫМ АППАРАТОМ ВСЕ СДЕЛАЕТ И НАПЕЧАТАЕТ В ПРИНТ-САЛОНЕ. ЭТО, КСТАТИ, К ВОПРОСУ О КРИТЕРИЯХ КАЧЕСТВА - ВОТ ПУНКТ В ТЗ - СДЕЛАНО? НЕТ. ШТРАФ. СРОК ВЫДЕРЖАН? НЕТ. ШТРАФ. ТРЕТИЙ ПРОКОЛ - ДО СВИДАНИЯ. МОЙ ВЕРДИКТ (И СОВЕТ ВАМ) - В ШЕЮ.

    "Я понимаю что разработчик всегда хочет чтобы ему написали ТЗ" - Я ТАКОЕ ВООБЩЕ ПЕРВЫЙ РАЗ СЛЫШУ! ТЗ ПИШЕТ ВСЕГДА ПОДРЯДЧИК, ЗАКАЗЧИК ТОЛЬКО ФОРМУЛИРУЕТ ТРЕБОВАНИЯ, БОЛЕЕ-МЕНЕЕ ВНЯТНО. А ЗАДАЧА ИСПОЛНИТЕЛЯ - ПЕРЕВЕСТИ ЭТО ВСЕ В ПОНЯТНЫЙ ТЕХНИЧ ЯЗЫК, ПОНЯТНЫЙ ВСЕМ, И ЗАКАЗЧИКУ, И ИСПОЛНИТЕЛЮ.

    "сменить разработчика было невозможно , т.к. очень сильно поджимали сроки." - НА ТАКОМ РАЗРАБОТЧИКЕ МОЖНО СОРВАТЬ НЕ ТОЛЬКО ЗАДАННЫЕ СРОКИ, НО И ДОПОЛНИТЕЛЬНЫЕ, А ТО И ВООБЩЕ СОРВАТЬ ВЕСЬ ПРОЕКТ К ЧЕРТОВОЙ БАБУШКЕ. МОЙ ВАМ СОВЕТ - МЕНЯЙТЕ. СТАРЫЙ КОНЬ БОРОЗДЫ НЕ ИСПООРТИТ. А ЕСЛИ НАЧАЛИСЬ ТАКИЕ ПРОБЛЕМЫ, КОТОРЫЕ УВАЖАЮЩИЙ СЕБЯ ПОДРЯДЧИК ДАЖЕ В МЫСЛЯХ НЕ ДОПУСТИТ, ТО ЭТО ВСЕ. ЭТО КАК КОМПЬЮТЕР - ОН ЛИБО РАБОТАЕТ СРАЗУ И ВСЕГДА, ЛИБО С НИМ НАДО НОСИТЬСЯ ПО РЕМОНТАМ. ОНО ВАМ НАДО?

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

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

    Выбор за Вами, конечно, просто Вы спросили - я ответил. Чем смог, тем помог. Мои рекомендации такие.

    (простите за крупный шрифт, хотелось как-то отделить цитаты от своих высказываний)

  • 19 февраля 2010 в 00:54 • #
    Павел Алексеев

    А было ли тестирование заложено в договоре или ТЗ? В том числе написание автоматических тестов, процент покрытия? Необходимая бизнес-логика? Чьими средствами?

    Какая была все же возложена формальная ответственность на исполнителя по устранению ошибок? Сроки? Гарантии?

    Я, как исполнитель, на то что делаю всегда гарантирую пожизненную гарантию - http://hosting-help.ru/insurance . Т.к. по ссылке скорее всего никто читать не будет и многие сочтут просто за саморекламу еще раз подчеркну, это разумеется не относится к случаям когда заказчик говорит "я передумал, давай лучше сделаем так", хотя в ТЗ было прописано по другому, но именно к ошибкам реализации.

  • 19 февраля 2010 в 13:45 • #
    Андрей Стрюков

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

  • 24 февраля 2010 в 10:38 • #
    Павел Алексеев

    Конечно просто слова и заверения на сайте к делу пришить очень сложно (хотя конечно можно, если уже в суде)

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

  • 20 февраля 2010 в 17:32 • #
    Георгий Куприянов

    "когда топ-менеджмент, полагаясь на знания исполнителя, доверяет тому сделать ТЗ для самого" . А платят только за кодинг при этом. Т.е., ты IT-директору/тимлиду приносишь тот кусок работы, за который деньги заплатят ему, а не тебе.
    Если ты, исполнитель, не дурак и не трус, то ты пошлёшь этих топов подальше и в крайнем случае найдёшь себе работу в конторе, в которой умеют ставить задачи и не так нагло пытаются прокатиться на подчинённых с ветерком....

  • 24 февраля 2010 в 17:53 • #
    Анна Бузова

    Как я понимаю, вопрос был задан именно в отношении оформления договора. Учесть все будущие проблемы с продуктом невозможно, все равно рано или поздно возникнет ошибка, которую никто не предполагал. А в процессе согласования требований можно увязнуть навечно.
    На самом деле, разработчик совершенно справедливо относится к договору, как «фанат к библии». На мой взгляд, решение Ваших проблем, или, по крайней мере, минимизация последствий нужно закладывать именно в договор. Когда речь касается денег, решать вопросы в рабочем порядке становится сложным. Любые исправления в ПО – это неучтенные расходы разработчика и логично, что он захочет за это денег. В договоре неотъемлемой частью обязательно должен быть указан срок гарантийной поддержки ПО и описан состав этой самой гарантийной поддержки:
    SLA – Service Level Agreement – Соглашение об уровне предоставления сервиса. Это табличка, в которой описано, за какое время какие виды проблем должны решаться. Например:

    Уровень критичности:
    Критический отказ (Critical)
    Описание ошибки:
    Ошибки при автономной работе прикладного программного обеспечения или при работе с прикладным программным обеспечением персонала. При этом работа производилась в соответствии с правилами, приведенными в эксплуатационной документации. Ошибки вызывают такой отказ прикладного программного обеспечения или такую потерю данных, которые не позволяют восстановить работоспособность программного или информационного обеспечения (данных), при этом затронуто более 50% всех пользователей системы
    Время восстановления:
    4 часа (режим: Рабочее время)

    Уровень критичности:
    Серьезный отказ (High)
    Описание проблемы:
    Невозможность выполнения основных функций прикладного программного обеспечения в соответствии с документацией. Отсутствуют альтернативные варианты выполнения этих основных функций прикладного программного обеспечения, при этом затронуто более 50% всех пользователей системы.
    Время восстановления: 1 рабочий день

    Уровень критичности:
    Средний отказ (Medium)
    Описание проблемы:
    Невозможность выполнения основных функций прикладного программного обеспечения, оказывающее серьезное влияние на рабочий процесс. Не существует приемлемого для пользователя "обходного" решения проблемы. Работа, хотя и с ограничениями, может продолжаться
    Время востановления: 5 рабочих дней

    Уровень критичности:
    Незначительный отказ (Low)
    Описание проблемы:
    Невозможность выполнения вспомогательных функций прикладного программного обеспечения. Проблема или продукт оказывают минимальное влияние на рабочий процесс
    Время восстановления: 21 рабочий день

    За невыполнение SLA должна применяться система серьезных денежных штрафов. Причем подробно описанная. Например, просрочка исправления инцидента с 1-м уровнем критичности на 2 часа – 0,1% стоимости контракта, на 12 часов – 0,5%. И т.д.

    Таким образом, Вам не нужно вникать в тонкости тестирования, разработчик будет сам мотивирован создать наиболее работоспособный продукт и будет деньгами отвечать за его качество.
    Про «гнать в шею» поставщика с приведенными выше высказываниями не согласна. Все разработчики одинаковы – все хотят меньше работать и больше зарабатывать. Нужно с любым поставщиком договариваться и навязывать ему свои правила игры в самом начале. Поэтому грамотно составленный контракт – это исключительно важный этап и Ваша компетенция. Что посеешь – то и пожнешь…

  • 2 марта 2010 в 19:39 • #
    Даниил Николаев

    Здравствуйте, в вашем случаи нужно первоначально произвести Аудит ПО, а после разрабатывать договор по Аутсорсингу. В этом случаи вы страхуете себя от неких сторонних обстоятельств, так как вы сами после Аудита готовите договор. Зная с чем вам работать и какими версиями. Вы их сами после Аудита должны установить.


Выберите из списка
2019
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970