Об ответственности заказчика и исполнителя за проект по разработке системы учета
О чем статья? В предыдущей статье я рассказал о необходимости наличия технического задания и вскользь коснулся того, чем занимаются исполнитель и заказчик в проекте. В этой статье хочу рассказать про ответственность сторон и поведать свой личный опыт. Более чем уверен, что будь вы исполнителем или заказчиком — наверняка вы сталкивались с подобными ситуациями.
Начнем, пожалуй! Итак, представьте себе, что вы исполнитель и вам позвонил заказчик. И попросил сделать что-то такое, что закроет его потребности и хотелки. Ну, дело не хитрое — вы владеете инструментами и можете это сделать. И вы просите его сделать описание его хотелок в письменном виде. Он их вам присылает, а там фрагменты текста, что вот надо сделать то-то, а вот тут еще работает как-то так. Вы вчитываетесь в это и говорите, что да, сделать реально, но нужно сначала начать писать ТЗ. Ну, просто потому, что описательная часть хотелок — это не ТЗ, а лишь «то, чего я хочу» без конкретизации того, «как именно я это хочу». И, ясен пень, что на ТЗ заказчик захочет сэкономить и написать его как можно дешевле. Но после того, как ударили по рукам, начинается реальная работа. И вот тут начинают вылезать казусы….
Первый казус — клиент не хочет отвечать на вопросы письменно. Телефон, скайп — но только не письменно! А что в этом такого, спросите вы? Вроде по телефону все понятно объяснил и это реально сделать. Но засада в том, что по ходу создания базы данных выясняется, что есть справочники, информацию из которых надо тянуть куда в заказы (к примеру) и что сам заказчик не понимает толком, как именно это должно работать. Отмазка простая — вот у нас же это работает в старой системе! Ну да, криво, но считает. Но вы ведь спецы — потому к вам и обратились!
Реальный пример. Да, все это верно. Но разве исполнитель должен догадываться, как именно инфа из справочников должна переползать в заказ? Нет, конечно, в теории можно догадаться. Но это время и…не факт, что вариант, который реализует исполнитель, устроит заказчика. Был у меня как-то опыт работы с одним мед центром. Сделал им приличную скидку, разбил разработку базы на квартал, чтобы народ плавно въехал в то, чем он будет работать. И даже «забил» на звоночек, что после первого месяца мед центр не захотел перечислять второй платеж за второй месяц. Да, были и с моей стороны проволочки, но они касались того, что я не знал, как именно хочет видеть заказчик то, что ему надо (хотя я и не обязан был). А сам я всё пытался показаться хорошим и делал варианты отображения за него (заказчика). И знаете что? Заказчик был недоволен! Он проел мне мозг тем, что я затягиваю сроки и тем, что я плохо работаю.
А что же сам заказчик? Он желал со мной общаться по телефону в рабочее время и по скайпу по вечерам. На мои письма отвечал с недельной задержкой. И при этом, как потом выяснилось, вообще пользовался не той базой (не актуальной ее версией, а какой-то там, где были глюки и недочеты, ибо она создавалась в самом начале проекта). Последнее вскрылось вообще случайно, так как мне показалось странным, что у заказчика не работает то, что работает у меня. Опять же, я попытался быть хорошим и сам полез удаленно выяснять, что же не так — оказалось, что проблемы были в винде заказчика (при перезаписи файла базы, старая база никуда не удалялась и сохранялась в теневой копии Windows).
В итоге я поимел большой геморрой! Просто потому, что не понимал, где кончается моя ответственность и начинается ответственность клиента. Но у клиента есть и своя голова на плечах — разве он думать не обязан? Ведь он так же заинтересован в том, чтобы проект состоялся так, как он изначально хотел. Но это в теории. На практике не всегда так — клиент может впасть в детство и начать топать ножками, обвиняя исполнителя в том, что тот недоглядел и вообще он (клиент) хотел по-другому, а вышло через жопу и виноват в этом именно исполнитель (кто-то другой, короче — а я в домике).
Справедливо ли это или что делать? На практике я убедился в том, что клиент может быть небольшим, может быть крупным — проблемы с ответственностью остается те же. Масштаб просто разный, но суть одна — клиент часто пытается слить ответственность за свои действия и переложить ее на чужие плечи. Так удобнее. Да и в случае чего можно пнуть исполнителя и сказать ему — сам виноват, сам и выкручивайся. А не то я тебе денег не заплачу и в суд пойду…. И вот тут работает только одно правило — надо знать свою зону ответственность ДО начала проекта и сообщить ее клиенту ДО начала проекта. И это надо не просто оговорить между сторонами, но и подписать это кровью в договоре. А там, где клиент не понял, надо тормозить проект и клиент может тратить свое время сколько ему вздумается — время то уже его.
А что же исполнитель? Ну, со стороны заказчика картинка вроде прояснилась. А как обычно реагирует исполнитель? Оказывается, что в большинстве случаев исполнитель ведется на то, что транслирует заказчик! Он просто подыгрывает клиенту в игре. И я сам не был исключением — я пытался быть хорошим и дать заказчику максимум. Так как эта статья не про психологию, опустим момент мотивации — зачем я хочу быть хорошим или зачем я иду на поводу у клиента. Эта статья о том, что с этим делать. А делать исполнителю надо вот что:
Во-первых, иметь свою голову на плечах. Это означает, что необходимо четко понимать, за что отвечаю я, аки исполнитель, а что я не в ответе. Например, если с клиентом не было согласовано, что я ему базу перезаписываю на его компе — значит, этого делать не надо. Можно сказать, что работа с компом — это отдельная услуга за отдельные деньги и поедет отдельный человек. Или, скажем, если заказчик просит то, чего в ТЗ не было — это надо выносить за скобки, подразумевая новый проект с доработками. И надо понимать, что это как раз и делается на благо заказчика, а вовсе не во зло ему!
Во-вторых, надо готовить заказчика к тому, что будет ДО того, как это произошло. А иначе потом бегать будете от заказчика.
В-третьих, заказчику лучше сразу сказать, что работа стоит денег. И что если он хочет халявы, то это или не к вам или вы готовы предложить ему решение, которое будет работать через задницу, но что его это может устроить.
В-четвертых, надо понять, что не каждый клиент — ваш. И не потому, что вам не нужны деньги, а потому, что ваши деньги — это ваше время. И если проект за 50К сдается без сучка-без задоринки за месяц, то за месяц вы заработали 50К за месяц. А если ваш проект растягивается на три месяца, то и 50К так же растяните на три месяца….сколько вы там в итоге за месяц то заработали теперь? Верно — в три раза меньше, а времени потратили в три раза больше.
Резюме по статье про ответственность сторон
И вот если все выше перечисленное сложить, то получается, что за проект в ответе обе стороны. И если у вас «контрольный пакет» ответственности 51%, то стоит задуматься над тем, а нужен ли он вам — тогда у кого-то остается уже 49%….а когда у вас 90%, а у кого-то 10% — что тогда? И это работает в обе стороны. Да не подумают клиенты или исполнители о том, что я грешу в чью-то сторону. Задача этой статьи в том, чтобы показать, что слив ответственности часто обходится дороже, чем вы об этом думаете. И чтобы для любой из сторон это «дороже» не было подарком-нежданчиком, помните о том, что стороны делают общее дело и общий проект.
Не так давно узнал, что мед центр (о котором в качестве примера шла речь в статье) ушел к другим программистам. Но те работали по схеме «повременка» (в следующей статья я как раз расскажу про это), что означало, что вот есть рабочая неделя, за которую надо заплатить без гарантий того, что эта неделя не превратится в две, три и более недель. Желание заказчика сэкономить мне было понятно изначально, но итоге всей этой истории был предсказуем — мед центр заплатил за проект в два раза больше, чем предполагал изначально. И не факт, что он получил на выходе тот результат, который хотел. Но лично мне это уже неинтересно — я не в ответе за чужой выбор.
